Plan 模式深挖
系列入口：如何使用 Agent。为什么必须有人把关，看 你是驾驶员不是乘客。
一、Plan 模式到底值在哪
Plan（计划）模式的规则很简单：在这个模式下，Agent 可以读代码、做分析，但不会改动任何文件，它的产出是一份「我打算怎么做」的方案。很多新手嫌它多一道手续，喜欢直接开干，结果常常在错误方向上跑了十几轮才发现。
它真正的价值是把纠偏的成本降到最低。改代码之前纠正一个想法，只要一句话；改完十几个文件再回退，代价高得多。Plan 模式就是让分歧在最廉价的阶段暴露。
二、什么时候必须先 Plan
不是所有任务都要 Plan，简单明确的小改动直接做反而利落。但下面几类任务，先 Plan 几乎总是划算的：
- 跨多个文件/模块的改动：影响面不清，你需要先看它梳理出的范围。
- 不可逆或高风险操作：涉及删数据、迁移、改公共接口，先看它打算怎么兜底。
- 你自己也没想清楚的任务：让它先调研、列出几种方案和取舍，本身就是帮你理清思路。
- 它可能理解偏的任务：目标里有歧义或业务背景时，先对齐认知。
反过来，改个错别字、写个一眼能验证的小测试这类，不必走流程。判断标准就一句：错了之后返工贵不贵？ 贵，就先 Plan。
为了让这个判断更快，给你一张可以直接用的「要不要先 Plan」核对清单，命中任意一条就先出方案：
- 这次改动会不会碰到两个以上的模块，或者一个我还没完全摸清的区域？
- 有没有删除、迁移、改公共契约、外发数据这类难以撤销的动作？
- 我能不能在一句话里无歧义说清要什么？说不利索，说明我自己也需要它先帮我梳理。
- 这件事做错了，是只影响我本地，还是可能影响别人、影响线上？
- 它要动的东西里，有没有我没授权就绝不能碰的（生产配置、用户数据、核心接口）？
新手容易在两个方向上判断失误：一是低估返工成本，觉得「不就改几个文件」，等隐式依赖被破坏、调试半天，才发现当初花两分钟看方案更划算；二是把 Plan 当万能仪式，连改个文案都郑重出三页方案，反而拖慢节奏。记住 Plan 解决的是「方向和风险」问题，不是用来给简单任务增加仪式感的。一个粗略的量化直觉：预期返工成本如果超过五分钟，先 Plan；任务本身五分钟内就能做完并验证，直接做。
三、一份方案该怎么读
拿到方案，别被它的篇幅和自信带着走，按四个点检查：
- 它重述的目标对不对：看第一段，确认它理解的是不是你要的东西。
- 步骤是否覆盖、顺序是否合理：有没有漏掉关键环节，前后依赖对不对。
- 影响范围：会动哪些文件、哪些公共接口，有没有它列出的风险和回滚办法。
- 它标注的不确定点：拿不准的地方最值得你介入。
一个实用动作：专门挑你最不放心的那一点追问，让它展开或者给出替代方案，而不是笼统地点同意。
为了让你对「方案质量」有具体感觉，这里给你一个同任务的好坏对照。任务是「用户登录失败次数过多时锁定账户」。
一份偏弱的方案可能只有：「我会在登录方法里加一个计数器，失败五次就锁定，再加个测试。」它方向不算错，但几乎没回答关键问题：计数存在哪、按什么维度（用户名还是 IP）、锁多久、怎么解锁、并发下会不会计数错乱、会不会被人利用来恶意锁定正常用户。看到这种方案就放行，这些坑会在执行中一个个冒出来。
一份更扎实的方案大致包含：目标重述与不做的事（本任务不做管理员手动解锁后台）；现状（当前登录链路涉及哪两个文件、失败如何返回）；具体改动（计数放缓存、key 用用户名、设过期时间、锁定时长、连续成功后清零）；影响范围（只动登录服务和一个缓存，不改公共接口）；风险与取舍（可能被恶意锁定，因此限制判断维度并保留兜底）；验证方式（补并发与锁定/解锁用例、跑相关测试）。
两相对照你就明白，读方案不是看它写得长不长、语气稳不稳，而是看它有没有正面回答「改哪里、影响什么、风险怎么兜、怎么验证」。 如果你发现方案对这几点语焉不详，不要用「它应该懂」来安慰自己——它含糊的地方，往往就是等会儿出问题的地方。此时最有效的动作就是针对那个含糊点追问，把方案逼到具体。
四、方案不满意怎么办：让方案先迭代
发现方案有问题，不需要你自己重写，也别急着进 Act 硬改。直接在 Plan 阶段要求它调整：
- 「第 3 步不要动数据库层，只在接口层处理」
- 「这个方案太复杂，有没有不改公共接口的做法」
- 「你列的风险点，先把回滚方案写清楚」
方案在这个阶段可以反复迭代、成本极低，改到你放心为止。这正是 Plan 模式相比「边做边改」最大的优势。
迭代方案时，有几种比「这里改一下」更有效的提问方式，能把方案质量往上推：
- 要替代方案：「除了改公共接口，再给我两个不动接口的做法，并说明各自代价。」它很擅长在被明确要求时穷举，而你不追问，它往往只给最先想到的那一种。
- 要反对意见：「站在评审者角度，列出这个方案最可能被攻击的三个点。」这能把它从「努力证明方案可行」切换到「主动找漏洞」。
- 要前置假设：「这个方案成立依赖哪些前提？哪个前提一旦不成立，整个方案就要推翻？」让隐性假设浮上台面。
- 要回滚路径：「如果上线后出问题，怎么最快退回，退回会不会丢数据？」高风险任务这一条必须有。
要特别警惕一种「伪迭代」：你提了意见，它满口答应、在下一版里把方案写得更圆滑，但实质问题没有被正面回应，只是用更多肯定的措辞包裹起来。判断有没有真迭代，看你担心的那个具体问题是否被一条可执行的改动或明确的取舍回答了，而不是看它有多认同你。必要时让它把「针对我上一条意见，你具体改了什么」单独列出来。
五、从 Plan 到 Act 的节奏
方案确认后，再切到 Act 执行。几个让切换更稳的小习惯：
- 让它按方案分步做，而不是一口气全改完，便于在中途发现偏差。
- 执行中冒出方案外的新情况（比如发现还有个文件受影响），及时停下来，必要时回到 Plan 重新对齐，别让它自行扩大战线。
- 做完按方案里的验收标准核对，标准一致，验收才有据可依。
在你点头进 Act 的那一刻，最好确认方案里已经同时锁定了三样东西，它们决定了后面执行和验收是否顺：一是文件清单（明确会动哪些、不会动哪些），二是验收标准（哪些测试要过、行为变成什么样才算完），三是中途的检查点（复杂任务分几阶段、每阶段结束你要不要看一眼）。这三样如果在 Plan 里讲清楚了，执行阶段你就不需要临场拍脑袋；反过来，如果进 Act 时这三样还是模糊的，执行中你大概率会被迫在信息不全时做决定——那等于把 Plan 的好处又让了回去。哪怕花一分钟把这三点补进方案，也比带着含糊方案开工稳得多。
| Plan | Act | |
|---|---|---|
| 能做什么 | 读、分析、出方案 | 改文件、跑命令 |
| 目的 | 对齐方向、暴露风险 | 按确认方案落地 |
| 纠偏成本 | 一句话 | 回退代码 |
六、Plan 不只是防错，还在放大你的能力
很多人把 Plan 模式只理解成一道安全闸门，其实它还有一个更积极的作用：它把 Agent 从「埋头实现」拉到「先和你一起想清楚」，从而让你能驾驭更大、更模糊的任务。
当任务很明确时，你直接下指令就行；但真实工作里大量任务在一开始是含糊的——「这个功能体验不太好，你看看怎么改」「最近这个服务老出问题」。这类任务直接进 Act，Agent 只能挑一个它猜的方向狂奔。而在 Plan 模式下，它可以先读代码、先调研、把问题结构化，然后用方案和你对话：它发现的现状是什么、有哪几条路、各自代价如何、它建议哪条、为什么。此时你做的不再是「写每一步指令」，而是更高层的判断和选择。
这其实是在改变你的工作位置。直接指挥时，你像一个事必躬亲的执行者，价值被消耗在拆解和搬运上；借助 Plan，你更像一个评审和决策者——它负责把信息和选项铺好，你负责结合业务和长期影响拍板。你不需要比它更会写代码，也能做出比它单独干更好的决定，因为你掌握它不知道的上下文：团队的规划、成本的约束、哪些技术债可以接受、这次不能动什么。
随着你越来越会用「让它先调研、出多方案、列前提和风险」这套动作，你会发现自己敢接的任务规模在变大。以前觉得「太大、说不清、不敢交给它」的事，现在可以先让它在只读模式下把问题理清，变成几个可以讨论、可以分步的小决策。这就是 Plan 模式真正放大你能力的地方——它不仅在便宜的阶段防错，更让你和 Agent 的分工从「执行层」上移到了「思考层」。
也提醒一个边界：方案再完整，最终判断仍是你的。Plan 让决策更有依据，但不会替你承担决策后果。越是大任务、方案看起来越「专业完整」，你越要确认那些它无法替你掌握的前提（业务方向、团队能不能维护、长期成本）是否成立。把 Plan 当成高质量的决策支持，而不是免责声明。
七、执行中「回退再想」的纪律
从 Plan 进 Act 后，最容易失守的一条纪律是：执行中冒出方案外的情况，要不要让它继续。这里给你明确的判断原则。
- 新情况仍在原目标和原边界内，只是实现细节比预想复杂：可以让它继续处理，这属于正常的执行波动。
- 新情况需要扩大改动范围、动到方案之外的模块或接口：让它停下来，回到 Plan，把扩大后的方案重新讲清楚再继续。不要默许它「顺手一起改了」。
- 新情况暴露原方案的前提不成立：立即停止执行，这不是局部调整能解决的，需要重新规划，必要时先回退已做的改动。
一个常见的失控路径，就是一连串「就多改这一个文件」的小越界，等你回过神，改动面已经远超当初确认的方案，而每一步单看都好像合理。对抗它的办法很简单：范围是一条需要重新审批才能移动的线，而不是可以靠「顺手」不断蚕食的软边界。 只要新改动超出已确认的文件清单，就触发一次重新对齐，哪怕只超了一个文件。
分步执行也有助于守住这条线：让它按方案一个阶段一个阶段地做，每阶段结束你对照方案确认，再进入下一步。这比一口气全改完更安全，发现偏差时需要回退的东西也更少。
八、常见问题
Q：Plan 出来的方案看着都挺合理，我怎么判断它是不是漏了关键东西？ 用三个追问检验：让它列方案成立的前提、站在评审角度挑三个漏洞、说明回滚路径。一个真正想清楚的方案能接住这些追问；如果一追问就含糊、前后不一致，说明方案还没到位，别急着进 Act。
Q：方案我也看不太懂，怎么审？ 你至少能确认三件不依赖专业深度的事：它重述的目标和你要的是不是一回事、它要动的范围有没有明显超出、它有没有诚实标出拿不准的地方。再用复述法——让它用大白话把方案讲一遍，听懂了再放行。专业细节可以随经验补，这三条现在就能做。
Q：可以让它边做边给我看，而不必先出完整方案吗？ 对小任务可以，这本质上是把 Plan 做得很轻。但只要任务跨模块或有不可逆动作，边做边看会让你在信息不全时被迫做决定，且改动已经发生。高风险任务仍建议先有一份完整方案。
Q：Plan 模式会不会让 Agent 变得束手束脚、效率反而低？ 对简单任务会，所以简单任务不必用。Plan 不是默认全程开启，而是在「返工成本高」时使用的工具。该快的地方快、该停的地方停，本身就是成熟用法。
总结
把 Plan 模式当成「动手前的低成本对齐」：复杂、不可逆、或你也没想清楚的事先只出方案，方案对了再进 Act——在纸上改主意，永远比在代码里改便宜。