工作流与 Plan 模式

这一课你将能做到

1. 用 Shift+Tab 进入并退出 Plan 模式，先拿只读方案再放行实施
2. 按官方推荐的「探索 → 计划 → 编码 → 提交」节奏组织一次完整开发任务
3. 用 TDD 顺序让 Claude 先写失败测试、再写实现，保证改动有验证兜底

为什么要学

同一个模型，会用的人效率高一倍。区别不在提示词花哨，而在节奏：新手常见做法是把需求一句话丢进去，让它直接改代码——它确实会改，但方向可能错、范围可能大，改完你不敢合并。规范工作流的核心是「让它在只读状态下先想清楚，你确认后再动手」，这样每一大步都有你的决策点。

人话：把 Claude Code 当成一位新来的高级工程师。你不会让新人第一天就碰生产代码，而是先让他读代码、出方案、你拍板、他实现、你验收。Plan 模式就是「出方案」的正式流程。

先建立图像

官方推荐的四步工作流：

┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│  探索    │ → │  计划    │ → │  编码    │ → │  提交    │
│ Explore │   │  Plan   │   │  Code   │   │ Commit  │
│ 读代码   │   │ 出方案   │   │ 小步实现 │   │ git 收尾 │
│ 不改东西 │   │ 你来拍板 │   │ 每步验证 │   │ 随时回滚 │
└─────────┘   └─────────┘   └─────────┘   └─────────┘
   只读会话      Plan 模式      正常会话       正常会话

三种权限模式对应三个阶段：

模式	快捷键	能力	适用
默认	—	敏感操作逐次确认	编码阶段
自动接受编辑	Shift+Tab 一次	文件编辑不再逐次确认	高频小改动
Plan 模式	Shift+Tab 两次	只读，禁止一切修改	探索与方案

跟着做

以一个真实场景走全程：「订单列表接口在数据量大时很慢，要求优化到 200ms 以内」。

步骤 1：探索阶段——只提问，不下令

订单列表接口的调用链是什么？从 Controller 到 SQL 每层做了什么？
先只做调查，不要修改任何代码。

它会读代码、追调用链。明确加一句「不要修改」，它就只输出调查结论。

步骤 2：进入 Plan 模式出方案

按 Shift+Tab 两次，界面进入 Plan Mode。然后：

基于刚才的调查，给出优化方案：预计改动哪些文件、每步做什么、
如何验证性能达标。先给我计划，确认后再实施。

Plan 模式下它无法改文件、跑写命令，只能调用只读工具，所以可以放心让它大范围思考。它输出带编号步骤的计划。

步骤 3：审查计划并拍板

逐条看计划，直接用自然语言修订：

第 3 步不要动索引，DBA 那边有规范；先只做「加缓存 + 分页改游标」两步。

确认后切回默认模式（Shift+Tab 循环切换），说「按确认后的计划开始实施」。

步骤 4：小步实施 + 每步验证

要求它每完成一步就跑一次验证：

实施第 1 步，完成后运行现有单测，贴出结果再继续。

每次它想 Edit/Write 都会弹权限确认（默认模式下），你逐个把关。

步骤 5：TDD 变体——先写失败测试

对修复类任务，用测试先行：

先为「重复点击导致的重复下单」写一个单元测试，运行确认它失败；
把失败输出贴给我，确认后再写修复代码，最后让测试转绿。

红→绿的顺序保证：测试真的在测这个 bug，而不是写了个永远通过的摆设。

步骤 6：收尾——提交

看一下本次改动的 git diff，用符合项目风格的 message 提交，
只包含本次相关文件。

让它先展示 diff 再提交，养成「提交前必看 diff」的习惯。

讲清楚要点

1. Plan 模式的价值是零风险思考：它把「想」和「做」强制分离。复杂任务（重构、跨模块改动、不熟悉的代码）先进 Plan 模式，简单任务直接做即可。
2. 上下文要喂饱：方案质量取决于它看到的材料。相关报错日志、需求文档、设计稿（支持直接粘贴图片截图）都应在计划阶段给出，而不是编码中途。
3. 一次一个任务：让它同时改五个模块，等于让审查变成走过场。串行小任务 + 阶段性验证，比并行大任务又快又稳。
4. 纠偏靠打断，不靠重来：方向错了按 Esc 立即打断纠正；改坏了用双击 Esc 回退到之前的检查点（checkpoint），而不是推倒重聊。
5. 计划要落到文字：复杂任务的确认计划可以要求它写进 PLAN.md 或用 /compact 前固化，长会话上下文被压缩时方案不丢。

你可能会懵的地方

• Plan 模式和普通模式下说「先别改代码」有区别吗？ 有。「口头要求」靠模型自觉，存在忽略的可能；Plan 模式是权限层面的硬限制，修改类工具根本无法执行。重要场景永远用硬限制。

• 它给出的计划太粗/太细怎么办？ 计划质量可用追问打磨：「这一步的回滚方案是什么」「预期影响哪些调用方」。把计划当成 code review 的对象，逐条质询。

• 改到一半发现方向不对怎么办？ Esc 打断 → 双击 Esc 回退 checkpoint → 重新描述。不要在错误方向上继续「打补丁」，上下文会越来越乱。

• 探索和计划能合并吗？ 小任务能。判断标准：如果你能一眼说清改哪里，直接说；如果需要先调查才知情，就分开。计划阶段多花 2 分钟，通常省掉 20 分钟返工。

• TDD 每次都有必要吗？ 修 bug 强烈建议（防止修了个寂寞）；写 CRUD 可以简化为「实现后补测试」。关键是测试必须真实运行过、且修复前确实失败过。

• 能把截图、设计稿直接喂给它吗？ 能。把图片粘贴或拖入输入框即可，Read 工具支持图像。报错截图、UI 设计稿、架构草图配上文字说明，是高质量输入；纯文字描述视觉问题时，远不如一张截图高效。

• 任务做到一半需求变了怎么办？ 先 Esc 停止当前动作，把新需求与已完成部分的关系说清楚（「刚才的前两步保留，第三步改为…」）；若改动范围跨越原方案，重新进 Plan 模式对齐，避免缝合式开发。

错法对照

错法	问题	正解
复杂重构不进 Plan 模式直接动手	大 diff 无法审查，方向错了代价高	先 Plan 出方案，确认后实施
一句话丢需求，不给报错日志	它全靠猜，来回返工	贴日志、复现步骤、期望行为
让它「同时优化这五个接口」	改动纠缠，一处失败全盘卡住	逐个接口串行处理
计划确认后全程不再看 diff	错误累积到无法合并	每步 git diff，问题当步解决
测试只是让它「写测试」不运行	测试可能是永远通过的摆设	明确要求：先跑失败再实现

卡点急救

1. 它不理会「先别改」直接动手了：立即 Esc 打断，切 Plan 模式重来；口头约束只作辅助。
2. 长会话后它忘了最初的方案：上下文被压缩所致。把关键决策写进 CLAUDE.md 或 PLAN 文件，或 /compact 时保留重点。
3. 计划很好但实施跑偏：把确认过的计划原文重新贴给它，并要求「严格按第 N 步执行」，一次只放行一步。

面试常问

• 为什么要区分 Plan 模式和执行模式？ 对应软件工程里「设计评审」与「实施」的分离。只读阶段能大幅降低不可逆操作风险，且让人类在成本最低的时点（方案期）介入纠偏，比代码写完再改便宜得多。

• 如何让 coding agent 的产出可控、可审查？ 要点：小步任务拆解、Plan 模式先行、每步以测试/git diff 验收、权限规则限制改动范围、用 TDD 提供客观验证信号。核心是把人类审查点嵌入工作流。

• agent 改错方向时你的处理流程？ 立即中断（Esc）→ 回退到检查点或 git restore → 复盘是上下文不足还是指令歧义 → 补充约束后重试，而不是在错误产物上继续修。

自测三问

1. Shift+Tab 循环切换的三种模式分别是什么？各自适合什么阶段？
2. TDD 工作流中，为什么必须先看到测试失败再写实现？
3. 长会话中如何防止关键方案因上下文压缩而丢失？

小结一句话

高效协作的秘诀是节奏：探索只读、计划拍板、编码小步验证、提交前看 diff——Plan 模式是这条流水线上的安全阀。

延伸

• 常见工作流官方文档
• 下一课：CLI 与会话——吃透启动参数、斜杠命令、快捷键与会话管理，把日常操作提速一档。