04 · Plan → Execute → Review 的协作节奏
没 Plan 是赌博，没 Review 是幻觉。
开场比喻
对前端开发者，最贴切的类比是 TDD：
| TDD | Claude 协作 |
|---|---|
| ① 先写期望（测试） | Plan：先定义"做完长什么样" |
| ② 实现 | Execute：按期望干 |
| ③ 跑测试验证 | Review：看 diff、跑起来、验证 |
TDD 里跳过第一步直接写代码 → 你永远不知道写的对不对。Claude 协作跳过 Plan 或 Review 也一样——只是"感觉完成了"，没有"证明完成了"。
为什么这篇最重要
前三篇讲的都是配置（CLAUDE.md、记忆、skill），这篇讲对话节奏——是日常使用频率最高、也最容易翻车的地方。
两个典型翻车点：
| 翻车点 | 症状 |
|---|---|
| 跳过 Plan | "我说了'加个按钮'，它把整个表单重构了" |
| 跳过 Review | "Claude 说 tsc 通过了我就合并了，线上发现按钮位置错了" |
第 1 阶段：Plan
目的
对齐"做完长什么样"。不是把任务描述精细化，而是让 Claude 的理解和你的期望显式对齐。
产物
可评审的方案，三件套：
- 要改哪些文件（列表）
- 为什么这么改（理由）
- 有什么取舍（alternative 和放弃它们的原因）
怎么触发
A. Plan 模式（严格版）：按快捷键或说 "enter plan mode"，Claude 只能读不能写，直到你批准方案才切回执行。
B. 口头禅（轻量版）：
"先给我方案，别急着动代码。"
后者更灵活——不强制 Plan 模式那种完全冻结，但效果通常够用。
批准的节奏
读完 → 真的理解 → 认可，再说"开干"。
不要边看边说"行行行你做吧"——你没理解的方案，执行阶段出问题你也看不出来。
什么时候必须 Plan
| 场景 | 为什么 |
|---|---|
| 改动涉及 3+ 文件 | 改错面积大，回滚成本高 |
| 修改公共 API / 数据结构 | 影响调用方 |
| 数据库 migration / 权限 / 安全 | 不可逆 |
| 涉及不熟悉的库 | 先调研免瞎搞 |
| 有多种实现路线时 | Plan 阶段决策比写完再推翻便宜 |
什么时候可以跳过 Plan
- 改一个字符串、一个颜色
- 明确的 typo fix
- 探索性读取（
grep/read，不写代码） - 前提：你非常确定范围
第 2 阶段：Execute
目的
按 Plan 实现。不是探索阶段，不是调方向阶段。
关键纪律
批准了就放手
频繁打断 Claude 会破坏它的上下文连续性——它正按步骤 2 改文件，你插一句"对了步骤 5 改一下方向"，它很可能把步骤 2 做一半就跳去想步骤 5。
原则：有修正，记下来，等本轮执行完再说。
真的要改方向？→ 回 Plan，不是边做边改
❌ 错：接着说"不对，改成 X 吧" → 上下文混乱，半成品堆积 ✅ 对：说"停，回 Plan 阶段" → 让 Claude 先整理现状，重新出方案
第 3 阶段：Review
目的
验证。不是信任 Claude 的叙述，而是验证事实。
黄金原则
Claude 的自我总结不是事实，代码和运行结果才是。
Claude 说"已完成 X、Y、Z"只是它意图做的事。要看：
git diff：真改了什么- 测试：实际跑过吗
- 浏览器 / 实际运行：真的好用吗
三层验证（按任务重要度选）
| 层级 | 动作 | 适合 |
|---|---|---|
| 轻 | 读 diff、过眼 | 改字符串、小样式 |
| 中 | diff + 跑 typecheck + 跑单测 | 逻辑改动、重构 |
| 重 | diff + 全套测试 + 浏览器实际操作 + 跨浏览器 | UI 改动、上线前 |
UI / 前端的特别提醒
类型检查验证的是代码正确性，不是功能正确性。
Claude 说"tsc 通过、所有测试通过" ≠ "功能没问题"。每次 UI / 前端改动，必须在浏览器打开实际操作：
- Claude 不能代替你的眼睛
- 自动化测试覆盖不了"按钮对齐得好不好看"
- 即使你相信 Claude，用户会第一个发现你没发现的问题
判断速查表
信息 / 任务进来
↓
改动可能涉及多个文件？ ── 是 → 强制 Plan
或涉及数据 / API / 安全？
↓ 否
我完全知道要改哪一行吗？ ── 否 → 还是 Plan
↓ 是
跳过 Plan 直接 Execute
↓
执行中想改方向？ ── 是 → 回 Plan，不要边做边调
↓ 否
Execute 完
↓
Review：diff + 验证（按任务重要度选层级）三个真实翻车案例
案例 1：跳过 Plan
用户："给首页加个按钮跳转到设置页"
Claude：[直接改] 把导航栏抽成了
<NavBar>组件，把首页 layout 重构了，顺带加了按钮用户（看 diff）："我就想加个按钮……"
病根：用户以为"加按钮"就是改一行，没意识到 Claude 可能把它当"整理导航"的机会。Plan 阶段一句话就能避免。
案例 2：跳过 Review
Claude："已完成，typecheck 通过，单测全绿。"
用户：合并上线
QA：按钮文字在中文界面溢出了
病根：单测不测视觉，typecheck 不测文案。UI 改动必须眼睛看。
案例 3：Execute 阶段乱调方向
Plan：改 A 文件
Execute 到一半：用户说"顺便把 B 也改了吧"
Claude：A 改一半，跳去改 B，B 改完回来 A 已经忘了进度
最终：A、B 都半成品
病根：执行中加戏。正确做法是等 A 完成再说 B，或回 Plan 重新规划。
反模式
① 跳过 Plan
大改动不问方案，Claude 按自己理解干。
② Execute 中频繁插嘴
打断破坏上下文连续性。
③ 不看 diff
信任 Claude 的"已完成"叙述。
④ UI 改完不打开浏览器
自动化测试不能替代眼睛。
⑤ 边做边改方向
应该退回 Plan 阶段整理，不是直接推进。
一句话总结
Claude 的时间花在"想清楚"比"做"更值钱。
没有 Plan 的 Execute 是赌博；没有 Review 的"完成"是幻觉。