Claude Code 命令学习笔记-拓冰建站

这是我学习 Claude Code 时整理的一份笔记。
目标不是背命令，而是理解 Claude Code 的基本工作流：
初始化项目 → 建立记忆 → 规划任务 → 执行修改 → 检查结果 → 管理上下文。

1. 为什么要学 Claude Code 的斜杠命令？

刚开始接触 Claude Code 时，我以为它只是一个能在终端里写代码的 AI 工具。但看完官方文档和一些社区文章后，我发现它更像是一个可以参与项目开发流程的 AI 编程助手。

它可以读取项目文件、理解代码结构、修改代码，甚至运行命令。也正因为它能直接操作项目，所以不能只靠一句“帮我改一下”。如果没有规则、计划和检查，AI 可能会误改文件，或者改完之后我自己也看不懂。

所以我觉得 Claude Code 的斜杠命令可以理解为：

控制 Claude Code 工作方式的一组入口，而不是简单快捷键。

2. 命令总览

阶段	命令	我的理解
项目初始化	`/init`	让 Claude Code 先了解项目
项目记忆	`/memory`	管理长期项目规则
任务规划	`/plan`	复杂任务前先规划
模型与推理	`/model`、`/effort`	调整模型和推理强度
上下文管理	`/context`、`/compact`、`/clear`	避免对话过长、上下文混乱
修改检查	`/diff`、`/code-review`、`/verify`	查看改动、审查代码、验证运行
问题排查	`/doctor`、`/debug`	检查环境、配置或当前会话问题

我目前的学习顺序是：

/init → /memory → /plan → /effort → /diff → /code-review → /verify → /compact

这个顺序比较适合新手，因为它不是直接让 AI 修改代码，而是先理解项目，再规划任务，最后检查结果。

3.`/init`：第一次进入项目时先初始化

/init是我认为最适合新手先学习的命令。它的作用是让 Claude Code 分析当前项目，并生成或更新CLAUDE.md。

我把CLAUDE.md理解成：

给 Claude Code 看的项目说明书。

它通常会记录项目结构、运行命令、测试方式、代码规范和注意事项。

项目	内容
命令	`/init`
作用	初始化当前项目说明
产物	`CLAUDE.md`
适合场景	第一次进入项目、接手陌生项目、准备长期使用 Claude Code
注意	自动生成内容需要人工检查

`/init`后我会检查什么？

检查项	问题
项目结构	是否正确识别主要目录？
技术栈	是否识别 Python、JS 或其他框架？
运行命令	是否写清楚怎么运行？
测试命令	是否写清楚怎么测试？
隐私风险	是否写入私人路径、Token、API Key？

/init不是结束，而是开始。生成的CLAUDE.md需要自己再读一遍。

4.`CLAUDE.md`：项目记忆文件

CLAUDE.md可以理解为 Claude Code 的项目记忆文件。它不只是给人看的 README，也是在告诉 Claude Code：这个项目应该怎么运行，修改时需要遵守什么规则。

一个简单模板可以这样写：

# Project Notes ## Project Overview 这是一个用于学习和实验的 Python 项目。 ## Common Commands - 安装依赖：pip install -r requirements.txt - 运行程序：python main.py - 运行测试：pytest ## Coding Rules - 不要直接修改 raw data 文件。 - 生成图片保存到 figures/ 文件夹。 - 实验结果保存到 outputs/ 文件夹。 - 修改多个文件前，先说明计划。 - 不要随便新增依赖。

哪些内容适合写进`CLAUDE.md`？

适合写入	不适合写入
项目结构	API Key
运行命令	Token
测试命令	账号密码
输出路径规范	私人电脑路径
代码风格要求	未公开数据地址
哪些文件不要修改	内部资料或敏感信息

我的理解是：CLAUDE.md不是越长越好，而是越清楚越好。稳定、长期有效的规则适合写进去，临时任务不一定要写进去。

5.`/memory`：管理长期规则

/memory用来查看和编辑 Claude Code 当前加载的 memory。它适合保存长期有效的项目规则，而不是用来堆所有信息。

规则类型	是否适合放进 memory	例子
项目运行方式	适合	使用`python main.py`运行
输出路径	适合	图片保存到`figures/`
代码风格	适合	函数命名要清楚
数据保护	适合	不要修改原始数据
临时任务	不适合	今天只改一个函数
隐私信息	不适合	密码、Token、私人路径

我的原则是：

只有下次还会用到的规则，才值得写进 memory。

6.`/plan`：复杂任务前先规划

我以前用 AI 工具时，经常会直接说：

帮我重构一下这个项目。

现在想想，这样其实不太安全。因为“重构”可能涉及多个文件、多个函数和多个依赖。如果 Claude Code 直接开始改，我可能不知道它为什么这么改，也不知道有没有破坏原来的逻辑。

所以复杂任务前可以先用/plan。

任务	是否建议先`/plan`	原因
修改一个 typo	不一定	改动很小
修复简单报错	视情况	可能只涉及一个文件
重构多个文件	建议	影响范围大
添加新功能	建议	需要先确认设计
修改数据处理流程	建议	可能影响结果复现
调整项目结构	强烈建议	容易破坏路径和依赖

示例：

/plan 我想整理这个 Python 项目的结构，请先分析当前目录和文件，说明你准备修改哪些地方，暂时不要直接改代码。

对我来说，/plan的意义不只是防止乱改，也能帮助我学习任务拆解。

7.`/model`和`/effort`：调整模型与推理强度

/model用来切换模型，这部分我目前还没有深入实践。

我更想先记录的是/effort。这里容易写错，不是/effect，而是：

/effort

它表示 reasoning effort，也就是推理强度。

effort 等级	我的理解	适合任务
low	较低推理强度	简单解释、轻量修改
medium	中等推理强度	普通代码修改、一般 debug
high	较高推理强度	跨文件分析、复杂 bug
xhigh / max	更高推理强度	大型重构、关键代码审查

我目前的想法是：平时不用一直开最高 effort。简单任务用 medium 就够了，复杂任务再提高。

8.`/context`、`/compact`、`/clear`：管理上下文

AI 工具用久了，经常会出现一个问题：前面聊得很清楚，后面越聊越乱。原因之一就是上下文太长。

Claude Code 也需要管理上下文。

命令	我的理解	适合场景
`/context`	查看上下文占用	对话已经很长，想知道是否快满
`/compact`	压缩上下文	当前任务还没结束，但上下文太长
`/clear`	清空当前上下文	当前任务结束，准备新任务

我自己的理解：

命令	比喻
`/context`	看桌面有多乱
`/compact`	整理桌面，保留重要东西
`/clear`	换一张新桌子

如果任务还没做完，用/compact；如果已经准备换任务，用/clear。

9.`/diff`、`/code-review`、`/verify`：改完之后必须检查

Claude Code 可以改代码，但它改完不代表一定正确。尤其是新手，如果 AI 改了很多文件，而自己没有看懂，就很容易出问题。

所以我准备把下面三个命令作为固定检查流程：

/diff /code-review /verify

命令	作用	我需要看什么
`/diff`	查看具体改动	改了哪些文件？有没有误删？
`/code-review`	审查当前改动	有没有逻辑问题、边界问题？
`/verify`	验证代码是否可运行	测试是否通过？程序是否能跑？

我的检查清单

检查项	问题
文件范围	是否只改了应该改的文件？
逻辑正确	是否符合原本目标？
数据安全	是否修改了原始数据？
依赖变化	是否新增了不必要依赖？
测试运行	是否通过测试或正常运行？
自己理解	我是否看懂了主要改动？

我的原则是：

AI 可以帮我写代码，但我不能把验收责任完全交给 AI。

10.`/doctor`和`/debug`：出问题时排查

Claude Code 出问题不一定是代码问题，也可能是安装、权限、配置或当前 session 的问题。

命令	更像检查什么	适合场景
`/doctor`	安装、配置、权限、环境	启动异常、命令运行不了
`/debug`	当前会话或工具调用	某个命令不生效、输出异常

这两个命令我目前还没有深入实践，后面遇到具体报错时再补充案例。

现阶段最重要的是先养成几个习惯：

习惯	对应命令
进入项目先理解结构	`/init`
长期规则写清楚	`/memory`
复杂任务先规划	`/plan`
根据任务难度调整推理强度	`/effort`
改完代码先看差异	`/diff`
重要修改要审查	`/code-review`
最后验证能不能运行	`/verify`
对话太长要整理	`/context`、`/compact`