AI 写代码翻车，八成不是模型能力不够，而是它在没确认要做什么之前就动手了。把”先出方案再落地”变成强制流程，也就是 Plan/Act 分离，是提升 AI 编程成功率性价比最高的一个改动。
什么是 Plan/Act 分离
Plan/Act 分离指的是把一次 AI 改动拆成两个互不混在一起的阶段：Plan 阶段只许读代码、提问、输出方案，不许写文件；Act 阶段拿着你已经确认过的方案去执行。两个阶段的权限不同、产出物不同、验收方式也不同。
它对应的是人类工程里最基本的分工——先做设计评审，再写代码。很多 AI 编程工具已经内置了类似的只读模式（部分工具叫 Plan Mode 或审批模式），本质都是同一件事。
为什么这一步能挡住大部分返工
| 失败模式 | 不分离时的表现 | 分离后被拦在哪 |
|---|---|---|
| 改错文件 | 基于错误假设直接改了三四个文件 | 方案阶段暴露出候选文件清单，人能一眼看出不对 |
| 过度设计 | 顺手加了抽象层和配置项 | 方案里的改动范围可以被明确压缩 |
| 方向跑偏 | 写到一半才发现理解错了需求 | 方案阶段必须先复述需求，理解偏差当场暴露 |
| 无法回滚 | 一堆散落的改动难以分辨 | 改动按方案分块提交，每块可单独撤销 |
分离的价值不在”慢”，而在把纠错前移。方案阶段改一句话，成本是一秒；Act 阶段发现方向错了，成本是回滚一整轮改动。
标准五步工作流
- 投喂完整上下文：把报错原文、相关文件路径、期望行为一次性给全，缺上下文是方案出错的第一原因。
- 要求先出只读方案：明确说”先不要改任何文件”，让它输出：要动哪些文件、每个文件改什么、可能产生什么副作用。
- 你做三件事：核对文件清单、砍掉超出需求的部分、补充它没问到的约束（比如必须兼容的旧版本）。
- 切到执行模式：让它按确认后的方案逐块实现，一次只推进一个逻辑块，每块结束跑一次校验。
- 用验收命令收尾：让它给出可复制的验证命令与回滚命令，而不是口头承诺”应该没问题”。
让 Plan 阶段真的产出一句话结论
很多人的方案字段是空的，原因是提示词太松。一个有效的 Plan 阶段提问模板应该强制包含四段内容：
- 结论：要不要改、一次性还是分批。
- 证据：引用的具体文件与行号，而不是”大概是某某模块”。
- 风险：哪些改动不可逆、会影响哪些调用方。
- 待确认：它不确定的地方，明确列出来等你回答。
强制”待确认”这一段尤其关键：它给了 AI 一个可以不瞎猜的出口，避免了为了显得确定而硬编一个答案。
什么时候可以跳过 Plan 阶段
四类可以直接进 Act 的场景
- 改动局限于单个文件、且行为肉眼可验证（改文案、调样式变量）。
- 纯机械性重复操作（批量重命名、批量补类型标注）。
- 已经跑过一轮、方案仍然有效的后续增量。
- 有完整测试覆盖、失败可以立即发现并回滚的任务。
反过来说，涉及认证、支付、数据库结构、删除操作的改动，无论多小都应该强制走一遍 Plan 。这类改动的共同特征是不可逆。
和更大范围的实践怎么衔接
Plan/Act 是单次会话级的纪律，再往上还有两个层级：把方案固化成文档就是规格驱动开发；给 Act 阶段加上边界限制就是沙箱与权限控制。三层叠加起来，AI 才敢在真实项目上放开手脚。如果是重构类任务，方案阶段还应该额外输出一份受影响的调用方清单，具体做法参考遗留代码 AI 重构的流程。
延伸阅读：把方案固化成规格Plan 阶段 AI 还是偷偷改了文件怎么办？
用工具内置的只读模式或审批模式强制限制写权限；没有这类功能的工具，就在会话开始时明确”未经我确认不得写任何文件”，并在方案确认前不提供文件路径外的任何执行许可。
每次都要出方案会不会太慢？
小改动可以直接进 Act，按上面的四类场景判断。真正耗时的大任务是那些改到一半发现方向错的，Plan 恰恰省的是这部分时间。
看不懂它给的方案怎么办？
这本身就是信号——说明方案不够具体。要求它把”结构调整”翻译成”改哪个文件的哪一段”，看不懂就打回重写，不要带着模糊方案进 Act 。
方案确认后它又自行加东西怎么办？
在 Act 阶段明确”严格按方案执行，超出范围先停下来问我”，并让它每完成一个块就报告改动了哪些文件，便于及时发现。
评论 (0)