计划贵在「可执行」，不是「好看」
上一节讲了计划模式是什么。这一节解决：怎么让 Claude Code 产出一份真正高质量的、可执行的计划。
一份空话套话的计划毫无价值，比如「我们要认真优化系统、提升质量」——说了等于没说。真正的计划要具体到能照着做。
对 codex-review 来说，「评审计划」的好坏直接决定评审质量：一份可执行的评审计划，审出来的是能照着修的报告；一份空话计划，审出来的也是空话。 这一节把「好计划的四要素」套到评审规划上。
一份好计划的四个要素
1. 目标明确
一句话说清「做完后是什么样」。要可验证，而不是形容词。
❌ 「提升性能」 ✅ 「让首页首屏加载时间从 2s 降到 1s 以内」
对评审，目标不是「认真审一遍」，而是「明确审出哪几类问题」：
❌ 「把这次改动审一遍」 ✅ 「对 src/ 本次 30 个文件改动，审出逻辑、安全、风格三类问题，输出按『必须改 / 建议改 / 可不改』分档、可直接照着修的清单」
2. 步骤可执行
每一步都要有「怎么做」和「怎么验证」。不行的步骤，等于没计划。
❌ 「优化首页」 ✅ 「第1步：用 Chrome 性能面板找出首屏瓶颈；第2步：对图片做懒加载；第3步：用 Lighthouse 复测首屏时间」
对评审，步骤要具体到「谁、审什么、怎么审、怎么算审完」：
❌ 「并行审一下」 ✅ 「第1步：派逻辑子 Agent，扫 src/ 业务改动，重点查边界和异常，输出三档清单；第2步：派安全子 Agent，扫输入和敏感信息，输出触发路径；第3步：派风格子 Agent，查命名格式；第4步：三路汇总并做冲突对账」
3. 涉及文件清单
明确「会碰哪些文件」，让你提前预判风险——尤其别让它动不该动的文件。
涉及文件：
- src/index.html (加懒加载属性)
- src/assets/img/ (图片处理)
- 不动：src/api/、数据库
对评审，就是明确「审哪些文件、范围到哪里为止」：
评审范围：
- 审：src/ 下本次改动涉及的 30 个文件
- 也扫一眼：package.json 的依赖安全（旁路）
- 不审：test/ 下已有测试文件、docs/ 文档
明确「不审什么」，防止子 Agent 把无关文件也翻一遍、浪费 token。
4. 风险与回滚
写清「哪里容易出问题、出了问题怎么办」。
⚠️ 懒加载可能影响首屏图片闪动；如出问题，回滚到上一步、保留原图属性。
对评审，风险不是「改坏了回滚」，而是「审漏 / 审偏了怎么办」：
⚠️ 三路并行可能因读同一批文件导致上下文拥挤、审漏；如发现某路结论明显单薄，让该路子 Agent 单独重审该范围；如审偏（审了不该审的模块），重新限定范围再审一次。
判断一份计划好不好
拿到计划后，用三个问题审它：
- 我能照着做吗？每一步都具体可执行吗？
- 会不会碰错东西？文件清单合理吗？有没有越界？
- 出问题有退路吗？风险点有没有写、回滚方案有没有？
三个都通过，才放行。有一个含糊，就让它改。
对评审计划，把三个问题翻成评审语境再问一遍：
- 照着这个计划审，能审出可修的问题吗？ 每路的范围和重点够具体吗？
- 会不会审错范围？ 该审的审到了吗？「不审什么」写清楚了吗？
- 审漏了 / 审偏了有补救吗？ 风险与回滚写了没？
让 Claude Code 出高质量计划
你可以直接给出「计划要求」，引导它产出规范的计划：
请按下面格式出计划，先不要动手：
【目标】……
【步骤】1… 2… 3…
【涉及文件】……
【风险与回滚】……
给它一个模板，它更容易给出可执行的计划，而不是泛泛而谈。
对评审，给一个「评审计划模板」尤其有效——它能逼 Claude 把范围、分工、验收都写清楚：
请按下面的评审计划格式出计划，先不要开审：
【评审目标】要审出哪几类问题、输出什么格式
【评审步骤】派几路子 Agent、每路审什么、重点查什么、怎么验收
【评审范围】审哪些文件 / 目录；明确不审什么
【风险与回滚】可能审漏/审偏什么、发现后怎么补救
把模板固化下来，就成了 codex-review 的「评审计划」雏形——到模块 03，我们会把这个模板做成一个技能。
落地练习
② 怎么判断做对了：计划的每一步都有「怎么审 + 怎么验收」；范围里明确写了「不审什么」；你能照着这份计划预判「审出来大概是什么样子」，而不是两眼一黑。
③ 卡住了怎么办：如果某步还是笼统（比如「审一下逻辑」），让它「把重点拆成具体检查点（分支、边界、异常、数据一致性）」；如果范围没写清「不审什么」，直接补一句「请明确列出不审的目录和文件」。
常见坑：目标写成形容词，验收就没抓手
评审计划最常见的败笔，是把目标写成形容词——「确保代码质量」「认真审一遍」。这种目标没法验收：审完了，你凭什么说「审好了」？没有明确的、可验证的目标，你连「这次评审到底做没做完、做得好不好」都判断不了。
对策是把目标写成可勾选、可量化的验收项：明确「要审出哪几类问题、输出什么格式、每路要覆盖哪些检查点」。目标一旦落到「能对着打勾」，评审计划就真正可执行了。
小结
- 好计划四要素：目标明确、步骤可执行、文件清单、风险回滚
- 用三问审计划：能做吗？会碰错吗？有退路吗？
- 给 Claude Code 一个计划模板，引导它规范输出
- 评审计划要写清「范围 + 不审什么 + 可验收目标」，并可固化成一个模板
下一节，看从计划到执行的完整链路——把评审计划真正落地成一次评审。