Claude Code 别再背命令了：一套真正能落地的高频工作流

摘要：这篇文章把 Claude Code 的常用命令按真实开发场景串起来：用 /init 建立项目上下文，用 /plan 先想清方案，用 /compact、/clear 和 /rewind 管理会话，再区分 Agents、Skills 与 MCP 各自的职责。最后用 /simplify、/code-review、测试和 git diff 做完整验收，并附上一段可直接复制的开发工作流 Prompt。

---

一、命令不是用来背的，是用来在正确的时候按下去

刚开始用 Claude Code，最常见的情况不是“没有命令”，而是命令摆在眼前，却不知道此刻该用哪一个。

• 上下文有点长了，应该压缩还是重开？
• AI 改了十几行，方向不对，能不能退回去？
• 复杂需求，是不是先让它规划一下更稳？
• /agents、Skills 和 MCP，到底分别解决什么问题？
• 代码能跑，是不是就算做完了？

这些问题其实都落在同一条开发流程上。先认识项目，再规划任务；遇到上下文问题就整理会话；写完后测试、审阅、检查改动，确认没问题才收尾。

命令只是流程里的按钮。先判断自己在哪一步，再去选按钮，比死记一份长长的清单实用得多。

1.1 先记住这条主线

看懂项目 → 想清方案 → 动手实现 → 验证结果 → 审查改动 → 完成任务

这条主线足够应付大多数日常开发。复杂的时候再往里面加工具，不需要一开始就把所有能力都用上。

还有一个小前提：Claude Code 迭代较快，不同版本、平台和套餐可用的命令不完全一样。输入 / 查看命令菜单，输入 /help 查看帮助，永远比对着旧清单猜更靠谱。

1.2 一份场景速查

场景	入口	该做什么
第一次进入项目	/init	建立项目上下文，再按需补充
忘记有什么命令	/、/help	查看当前环境里的命令与说明
当前任务没做完，上下文太长	/compact	压缩会话，保留任务主线
要开始一件无关的新任务	/clear	清空会话，重新开始
改到一半发现方向错了	/rewind	回到检查点，重试另一种做法
想调整当前模型	/model	打开模型选择；不同环境的菜单可能不同
复杂需求还没开始改	/plan	先探索并确认方案
需要拆分复杂分析	/agents	管理或创建子代理
同一套规则反复交代	/skills 或直接调用 Skill	将固定流程沉淀下来
需要连接外部工具或服务	/mcp	管理 MCP 连接与授权
想顺手问一个旁支问题	/btw	旁问，不把答案塞进主对话
做完代码想整理结构	/simplify	清理重复和过度复杂之处
想检查这次改动有没有 Bug	/code-review	按正确性重点审查 diff
需要周期检查部署或测试	/loop	按间隔重复执行任务

这张表可以先熟悉整体，下面再讲每一个入口背后真正的使用方法。

---

二、进入项目：先把上下文搭起来

2.1 /init 不是魔法，它先给你一张项目地图

第一次在仓库里使用 Claude Code，可以先运行：

/init

它会根据项目情况生成一份起手的 CLAUDE.md，用来告诉 Claude Code：这个仓库使用什么技术栈、怎么启动、怎么测试、目录大概怎么划分。它负责先搭骨架，不等于自动理解所有业务。

初始化后，不要立刻让它修改代码。先给一个只读任务，把真正影响开发的信息补齐：

请先分析当前项目，并补充 CLAUDE.md：

1. 使用哪些语言、框架和主要依赖
2. 本地如何安装、启动和测试
3. 核心业务模块分别在哪里
4. 哪些目录可以修改，哪些需要格外谨慎
5. 代码规范、错误处理和测试约定

先检查现有信息，再提出补充建议。
暂时不要修改业务代码。

这样比单纯写一句“请了解项目”有效。你要的是可用于决策的上下文，不是一段泛泛的项目简介。

2.2 先查命令，再记住命令

输入一个单独的 /，会打开当前环境的命令菜单。输入 /help，则查看帮助和可用命令。

命令菜单本来就比记忆更可靠：

• 忘了名字，输入 / 找；
• 不确定参数，用 /help 或者输入完整命令查看；
• 换了电脑或版本，以当前菜单为准。

真正值得记住的不是每个命令的拼写，而是“现在遇到了什么状态，应该去哪个入口”。

---

三、会话管理：别把所有问题都扔给 /clear

3.1 /compact 和 /clear，处理的是两类不同情况

这两个命令都跟上下文有关，但目标完全不同。

还在做同一件事，只是前面读文件、跑测试、讨论方案的记录太多了，可以：

/compact

它会把已有对话压缩成摘要，保留当前任务继续往前推进。如果担心摘要漏掉关键点，可以补一句重点：

/compact 重点保留目标、已修改文件、失败测试和尚未解决的问题

如果手上的任务已经完成，接下来要做的是完全无关的事情，就可以：

/clear

它会新开一段空白会话。上下文过长并不是自动等同于“清空”：同一个任务还没收尾，用 /compact 更连贯。

可以记成一句大白话：

同一件事没做完 → /compact
换一件无关的事 → /clear

3.2 /rewind 是返回检查点，不是撤销魔法

AI 写代码时，最让人头疼的情况之一是：它很认真，但方向不对。这时候可以：

/rewind

它用于回到之前的对话或代码检查点，也可以选择从某条消息开始重新总结，而不是从零描述整个需求。

但 /rewind 不是版本控制的替代品。真正可靠的开发习惯依然是：

修改 → 测试 → 查看 diff → 确认 → 提交

会话检查点适合在“这次尝试不理想”的时候回退，Git 提交则负责记录你认为可靠的历史。两者解决的不是一个问题。

3.3 /btw：临时问题别拖住主任务

正在让 AI 修改支付模块，突然想知道某个依赖的最新版本，或者想顺便确认一个无关的小知识点，可以用旁问：

/btw 这个项目现在使用的 Node.js 版本是什么？

/btw 适合解决“顺手问一句”的需求。你不希望一个临时答案打乱当前对话的主线，也不想为了它重新开一段会话。

但旁问不是收件箱。真正需要落地的修改，依然要回到主任务里说清目标、范围和验收条件，否则 AI 可能知道答案，却没有把改动并入正确的工作流。

---

四、复杂需求：先看清，再规划，最后才动手

4.1 /plan 解决的是“想清楚再改”

对于重构、权限、支付、数据库变更这类牵一发动全身的需求，最稳的做法不是马上让 AI 开始编辑文件，而是先规划。

/plan 给登录模块增加双因素认证

命令后面可以带上一句任务描述，让它直接进入规划模式。规划阶段要弄清的是：

• 相关代码分布在哪些文件；
• 需要改数据结构还是接口；
• 有哪些权限和兼容性边界；
• 要补哪些测试；
• 有哪些不能忽略的风险。

不要把计划当成一串“准备修改 xxx”的愿望清单。好的计划应该能让另一个工程师照着它判断接下来怎么做。

4.2 Explore、Plan、Code 各干各的

先探索，再规划，最后实现：

请先只读分析登录模块：

1. 认证入口和核心数据流
2. 现有权限检查
3. 相关测试
4. 增加双因素认证可能影响的文件

暂时不要修改代码。

看完分析后，再确认实现方案；方案没问题，才进入编码。规划阶段会把不确定的地方暴露出来，比代码写完才发现选错方向便宜得多。

还有一个容易搞混的入口：你提到一个 Bug，但不一定需要从头做架构规划。范围清楚的问题可以直接做，复杂、跨模块、风险高的问题才更值得先 /plan。

4.3 /model 是任务配置，不是万能开关

不同任务需要的能力和成本不同。解释一个函数、补几行测试、分析整个认证系统，完全可以按需要调整模型：

/model

具体可选哪些模型、是否支持推理强度调整，以当前环境的菜单为准。不要因为“看起来更高级”就一直使用最重的配置，也不用为了省资源让复杂重构停在很薄的模型上。

切换模型解决的是执行配置问题。上下文杂乱、方案没确认、需求有冲突，这些问题不会因为换模型自动消失。

---

五、Agents、Skills、MCP：三个经常被混在一起的概念

这三个名词看起来都在扩展 Claude Code 的能力，但解决的问题很不一样：

• Agents / 子代理：把复杂工作拆开，让不同代理聚焦各自的范围；
• Skills：把一套反复使用的规则、流程或项目知识固定下来；
• MCP：让 Claude Code 连接外部工具、数据或服务。

5.1 /agents：把复杂任务拆开分析

大型项目里，一个问题可能同时涉及数据库、API、权限和测试。让一个代理从头到尾都抓，容易顾此失彼。

这时可以通过 /agents 管理或创建子代理。当前版本在不同环境里的交互可能不同，有的会打开管理界面，有的只提示你让 Claude 创建或直接编辑 .claude/agents/ 下的配置。

无论入口怎么变，核心都是把工作边界写清楚：

请分别检查这次订单改动的：

1. 数据库约束
2. API 参数校验
3. 权限检查
4. 测试覆盖

分工完成分析与验证，最后汇总冲突和风险。

子代理适合并行分析或多个互有边界的任务。仅仅为了多开几个代理而拆工作，通常只会增加汇总成本。

5.2 Skill：别再每次重新教一遍

如果你反复告诉 AI：

按照项目规范写代码。
提交前补测试。
接口错误必须包装成统一格式。
检查有没有无关修改。

那这套固定流程就适合沉淀成 Skill。项目级 Skill 的常见位置是：

.claude/
└── skills/
    └── api-development/
        └── SKILL.md

自定义命令已经并入 Skill 体系；技能的说明和流程会按需加载，不必每次会话都重新复制一遍长提示词。

查看已有 Skill：

/skills

调用项目里名为 api-development 的 Skill：

/api-development

它和 ~/.claude/skills/ 下的个人 Skill 是不同作用范围：前者适合跟着仓库和团队一起维护，后者适合你自己跨项目复用。

5.3 /mcp：从读代码走到调用外部服务

MCP 让 Claude Code 不只是“看文件和改文件”，还可以连接数据库查询、外部文档、设计工具或其他数据服务。管理连接与授权：

/mcp

接入外部工具后，权限边界同样重要。只读查询、修改数据、发布内容是不同的风险等级，不要把“已经连上”当成“可以随便操作”。

遇到一个任务，先问自己：它需要拆开工作、复用固定流程，还是接入额外的数据与工具？想清这一层，再决定要不要加 Agents、Skills 或 MCP。

---

六、代码写完，验收才刚开始

6.1 /simplify 和 /code-review 不要混用

这两条命令都能“看代码”，但有一个关键区别：

• /simplify 关注重复、复杂、可复用性和抽象层级，会把这些整理建议付诸修改；
• /code-review 关注 diff 中的正确性 Bug，不会把“代码更漂亮”当成主要目标。

审阅时可以直接交给 AI 的检查任务：

请检查这次修改：

1. 是否引入了功能回归
2. 边界条件和错误处理是否完整
3. 是否有权限或数据一致性问题
4. 测试是否覆盖关键路径
5. 是否混入无关改动

先列出问题，再修复确认过的问题。

这里还有一张值得记住的“验收顺序”：

功能测试 → 真实运行 → /code-review → /simplify → /diff → 提交

/simplify 不应该在关键 Bug 还没找出来之前先改结构。正确性优先，可维护性随后。

另外，Claude Code 还有 /security-review 专门检查这次改动中的安全风险。它不能替代完整的安全审计，但适合作为敏感功能提交前的额外一道检查。

6.2 测试通过不等于任务完成

对 UI、命令行工具、服务端应用，值得要求的验收通常是三层：

1. 单元测试和相关测试通过；
2. 实际启动或运行，确认关键路径真的可用；
3. 审阅 diff，确认没有无关修改、调试代码或敏感信息。

可以这样交代 AI：

请运行与本次修改相关的测试。

如果失败：
1. 先分析原因
2. 修复实现或补全测试
3. 重新运行

不要删除或跳过测试来绕过失败。
完成后，汇报修改文件、验证结果和剩余风险。

最后自己检查：

git diff

这一步很朴素，但能抓住很多“测试过、AI 说没问题”却藏着的多余改动。

6.3 /loop：持续观察，但不替你验收

部署之后想定时检查状态，可以用：

/loop 5m 检查当前部署状态，并报告新的失败信息

/loop 适合持续观察测试、部署或日志这类需要重复检查的任务。它会按指定间隔在当前会话中重复执行，也可以不给间隔，让它根据任务自行安排。

但周期检查不能替代最终验收。会话结束后，它不会留在后台替你完成所有事情。持续任务的关键仍然是：触发条件明确、报告可读、停止时机清楚。

---

七、完整工作流：从新需求走到可提交

把前面的内容串起来，日常开发可以走这样一条路：

第一阶段：认识项目

新仓库先 /init，再补一份自己项目的启动、测试、模块边界和限制。老项目已经有 CLAUDE.md 时，先读它，按需要更新，不需要每次机械重做。

第二阶段：探索和规划

先只读分析相关文件、接口、数据模型和测试。复杂需求用 /plan 把方案、风险与验证方式说清楚，再开始修改。

第三阶段：实现与验证

按方案改代码，同步补测试，运行测试和真实场景。完成后先查正确性，再整理结构，最后检查 diff。

第四阶段：会话收尾

任务还没结束但上下文太长，用 /compact。工作已经做完，换到无关任务，用 /clear。发现实现方向错了，用 /rewind 回到检查点重试。最终确认内容后，再通过 Git 提交。

7.1 可直接复制的完整 Prompt

你现在作为我的 AI 编程助手。请按以下流程处理这个需求。

【Explore】
先分析项目结构、技术栈、相关模块、数据模型、API、
权限和测试。只读检查，暂时不要修改代码。

【Plan】
给出实现方案，说明：
1. 需要修改哪些文件，以及原因
2. 是否需要数据库或接口变更
3. 需要补哪些测试
4. 有哪些兼容性和权限风险

方案确认后再编码。

【Code】
遵循现有项目结构，不做无关重构，保持代码风格一致，
同步补充测试。

【Test】
运行与本次修改相关的测试和必要的真实运行验证。
失败时先分析原因、修复问题，再重新运行。
不要删除或跳过测试来规避失败。

【Review】
检查正确性 Bug、边界条件、安全问题、测试覆盖、
重复代码和无关修改。

最后说明：
1. 修改了哪些文件
2. 验证了什么
3. 还有哪些残余风险

这段 Prompt 并不依赖某个特定版本。它的价值在于把“先看懂、再规划、后实现、要验证”固定下来。

---

八、最后留一张“不背命令也能开始”的记忆卡

如果刚开始使用 Claude Code，先抓住三件事：

第一步：Explore —— 先看懂项目
第二步：Plan    —— 再确认做法
第三步：Code + Test —— 做完要验证

之后按需要补上会话管理、代码审阅、子代理、Skill 和 MCP。别让扩展能力抢在基本流程前面。

真正高效的使用方式，不是每遇到一个问题就换一条命令，而是知道任务现在在哪一步、下一步需要什么证据。这样即使命令菜单变了，工作流依然稳。

感谢阅览。