工作流与 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 变体——先写失败测试

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