1. 为什么同样用AI编程别人交付快一倍先把想和做分开我大概有大半年时间用AI编程的方式只有一种把需求一扔让它直接写代码。后来被返工折腾到怀疑人生才开始认真实践Plan模式——在模型动手写代码之前强制它先产出一份可审查、可讨论、可调整的实施计划。这个转变带来的效率提升比我换任何一个更强的模型都明显。先说一个真实场景。有一回我让AI重构一个数据导出模块它痛快地把代码改了功能测试也过了。结果第二天同事跑过来说导出数据的格式全乱了我一看代码它把公共函数的签名改了下游六个调用点全崩编译错误刷了一屏。问题出在哪出在我从来没要求它在动手之前想清楚这个函数的调用方有哪些、签名变了影响谁、数据格式变更要不要兼容旧版本。Plan模式的本质就是把想和做分开。我们人写代码的时候天然会先构思结构、评估风险、排好顺序再动手但到了用AI的时候这个环节被大部分人省掉了。结果就是你相当于给一个能力很强的实习生直接开了生产环境的写权限没有设计文档、没有改动清单、没有验收标准全靠边写边想。这篇文章不是什么特定工具的教程而是我在多个AI编程场景里反复试错之后沉淀出来的Plan模式实践小结。适合正在用AI辅助写代码、但对产出质量不稳定的开发者也适合团队想统一一套AI协作流程时做参考。先给结论把规划和执行拆成两个阶段让AI先交付一份合格的计划再基于计划动手改代码单次修改的返工率在我这边至少降了一半。2. 我的Plan工作流四个回合缺一不可很多人以为Plan模式就是写代码前加一句先给我一个计划这其实是个误解。一份真正能指导实施的计划不是AI一拍脑袋写出来的而是通过四轮对话逐步收敛出来的。整个流程可以概括成下面这张表回合核心目标关键产出需求澄清收敛需求、消除隐性假设信息缺口问题清单与补充后的完整需求现状锁定精确理解现有代码受影响文件、函数、数据流清单方案选型对比多条实现路径方案对比表与技术/业务风险清单任务拆解整理可执行顺序带验收标准的任务序列四个回合每个都有自己的使命跳步或者合并都容易在后面的执行阶段付出代价。下面逐个说清楚。2.1 第一回合需求澄清让AI先提问第一轮对话我会明确禁止AI给方案只要求它提问。Prompt大概长这样先不要给任何方案或代码。你只需要做一件事根据我提供的需求描述列出所有影响后续设计的信息缺口。包括但不限于业务规则、性能要求、兼容性范围、失败场景、数据量级预期、现有代码的关联位置。如果有不确定的地方用问题清单的形式列出来不要自己假设。这一步看起来很反直觉——明明是让AI干活怎么反而让它提问但它的价值非常大。AI的假设越少计划的可靠性越高。我见过太多因为假设错误导致整个方案推倒重来的案例它默认用户一定登录了、默认并发量不超过两位数、默认某个字段一定非空。这些假设在你的真实项目里可能全是错的而它一旦基于错误假设写出计划后面所有环节都是在错误的地基上盖楼。通常我会在这一轮结束时把AI提的问题逐条回答然后把回答合并进需求描述的原文里。等AI不再有疑问再进入下一个回合。如果需求本身就很复杂这个回合可能需要来回两三次我建议你耐心一点这里的每一分钟都是为后面省时间。2.2 第二回合锁定现状要求AI引用真实代码计划要做得好必须建立在对现状的准确理解上。第二个回合我要求AI做的不是了解大概而是精确到文件和函数。我的要求通常是这样在给出计划前请先梳理当前代码库中与本需求相关的部分。对每个受影响的文件说明它的职责、关键函数、现有的数据流方向以及本需求与它的耦合点。所有结论必须标注文件路径和行号禁止泛泛而谈。这里有个容易被忽视的细节AI在计划阶段给出的文件清单往往是它以为要改的文件而不是实际要改的文件。如果计划里写清了路径你作为长期维护者一眼就能看出哪里离谱。我自己有一次靠这一招提前发现AI计划里要改的配置文件路径跟真实工程结构差了整整一级目录——要是直接让它写代码改完项目可能都跑不起来。第二个容易被忽视的点是数据流方向。改一个函数容易改一条数据流很难。我要求计划里明确写出数据从哪里来、经过哪些转换、到哪里去、失败时走什么分支。只要这个做扎实了执行阶段基本就是按图施工AI不太容易跑偏。2.3 第三回合方案选型至少给两个选项需求收敛了、现状摸清了这时候才轮到真正的方案设计。我的要求是不许只给一个方案最少两个而且必须给出对比维度通常包括改动范围、现有行为风险、性能影响、可维护性、测试成本。AI天然倾向于给一个看起来最合理的方案但很多情况下它有明显的路径依赖倾向于尽量少改代码结果往往是拿一种别扭的方式把新需求硬塞进旧结构里。我要求它输出方案对比时会特别加一句对每个方案说明它在什么具体场景下会失效或产生问题。这句话逼着它思考反例而不是只罗列优点。计划阶段发现的反例越多执行阶段踩的坑越少这笔账怎么算都划算。选型决定权一定要在你手里。AI可以给建议但不要让它默默选完就往下走。你需要看到清晰的A方案 vs B方案然后根据自己的业务判断拍板。这是计划审查的核心动作之一也是Plan模式比直接让AI写代码更可控的关键原因。除了方案对比这一轮我还会强制要求AI输出风险清单格式不限但要包含风险描述、触发条件、影响程度、缓解措施。注意风险要分两类技术风险和业务风险后面会专门展开讲。2.4 第四回合任务拆解与验收标准最后一个回合是把选定的方案变成可执行的任务序列。这一回合的质量直接决定了执行阶段你是不是需要反复打断AI。我的通用要求是将实现步骤拆解为按顺序执行的任务。每个任务必须包含目标、涉及的具体文件与函数、关键实现思路、如何自测、完成标志。任务粒度以每次只改一个逻辑模块且可独立验证为准。任务之间如果有依赖关系必须显式说明。任务粒度的把握是个经验活。太粗执行时容易掩盖大量细节问题太细计划本身变得臃肿审查成本比写代码还高。我的经验是单个任务控制在改动1到3个文件、可运行或可单测验证的量级比较合适。比如一个完整的用户认证模块改造拆成数据结构与存储层、鉴权逻辑、接口层、迁移与兼容四五个任务就够了再往下拆到修改第几行这种程度没必要。验收标准是大多数人忽略的地方。每个任务必须能回答我怎么知道它做完了而不是实现登录功能这种模糊表述应该是新用户可以通过邮箱密码注册并收到欢迎邮件旧用户的Token在改造后仍能通过校验这种可验证的表述。验收标准写不清楚执行阶段就一定会出现AI说改完了你根本没法验证的尴尬状况。到这里一份真正可用的计划才算完成。整个过程往往需要三四轮对话总耗时可能比直接让AI改代码多半小时但这半小时通常会从后期的排错时间里成倍省回来。3. 让AI写出靠谱计划的关键Prompt写法计划阶段的产出质量很大程度取决于Prompt怎么写。我把常用的写法拆成几个核心要素可以套用到不同场景。3.1 角色与目标声明Prompt的第一句话要同时声明三件事AI的角色、要交付的产物、产物的质量标准。我常用的模板是你是一名资深系统设计师现在承担本项目某功能模块的方案设计工作。本次会话只负责设计阶段不产出任何业务代码。你的交付物是一份结构化的实施计划文档包含需求理解、现状分析、方案对比、风险清单、任务拆解五大部分。文档质量以可以直接据此开工为标准。这段声明有三个作用。第一只负责设计阶段是给AI划定行为边界避免它聊着聊着突然开始写代码。第二交付物结构明确AI就不会给你一段流水账。第三可直接开工这个质量标准能显著提高AI自查的严格程度。我对比过加不加这句话产出计划的细节密度差很多。3.2 约束条件与输入材料计划的可执行性依赖于你喂进去的材料。我的习惯是把以下内容原样粘贴进Prompt需求描述已经过澄清轮收敛的版本相关接口说明、数据库表结构、旧版本行为描述本次迭代的范围边界明确不做什么团队已有的技术规范或编码约定有一条经验值得专门说明确告诉AI这次不用考虑什么往往比告诉它需要做什么还重要。比如做性能优化时如果不说清楚不许改现有接口签名它极有可能为了性能把对外API改了引发下游一堆问题。范围边界写得越清楚AI越不容易自作主张。3.3 迭代式追问而不是一次到位很多人期望第一条Prompt就拿到完美计划这不现实。我一般至少做两轮追问。第一轮追问集中在计划的盲区让AI自己指出计划里可能的隐患、缺少的信息、以及它做了哪些隐性假设。第二轮追问集中在执行边界条件数据量翻十倍怎么办、并发上来怎么办、需要回滚怎么办。追问的Prompt不需要多复杂我常用的就两句你刚才的计划里哪些结论是建立在假设上的这些假设如果被推翻计划的哪些部分需要重写如果这个模块上线后立刻收到线上反馈说数据丢了你的计划里哪个环节最可能出问题第二句听起来有点吓人但它非常有效。它逼着AI从故障视角回看自己的方案经常能问出来这里少了日志、那里缺了一道数据校验这种计划漏洞。这类追问往往能让计划的质量在最后阶段再上一个台阶。4. 计划审查我把这五个问题固定成检查清单计划生成之后真正的分水岭是审查环节。AI给的计划不一定烂但你不审查再好的计划也会在执行中变形。我的做法是把审查固定成五个问题每次逐条过。第一个问题计划是否真的对应了原始需求的最核心目标这条听起来像废话但实际项目里经常出现AI把需求理解偏了导致整份计划精雕细琢地解决了一个错误的问题。审查时把原始需求和计划里的需求理解部分并排对比看它有没有加入需求里没有的隐含目标或者丢掉关键约束。第二个问题文件清单是否对得上真实代码库核对计划里每个文件路径和模块名跟工程结构对一遍。对不上的直接打回。这一步能拦截掉绝大多数AI在凭想象做计划的情况成本极低收益极高。第三个问题风险清单里有没有业务风险而不只是技术风险AI默认只会识别技术风险比如接口变更、性能下降但它基本不会识别业务风险比如用户改了邮箱之后旧邮箱还能收到通知这种逻辑漏洞。这部分必须用你的业务视角逐条补。第四个问题验收标准能不能在五分钟内验证不能快速验证的任务执行阶段很容易糊弄。如果AI写的是任务完成后待测试那就等于没有验收标准打回重写。第五个问题任务的先后顺序是否考虑了依赖和回滚比如数据库迁移和数据清理的顺序反了会有什么后果AI很少主动想。计划的执行顺序应该保证任意一个中间节点停下系统都处于一个可恢复的状态。我在本地维护着一个Markdown检查表每次审计划就打开逐条过。一开始很花时间熟练之后五分钟就能审完一份计划。看多了之后甚至能靠手感闻出计划里不对劲的地方——那种感觉跟审代码是一样的经验积累起来之后会非常可靠。5. 从计划到执行怎么保证AI不乱跑计划做完了真正开工时还有一个经典问题AI进入执行阶段后逐渐放飞自我改着改着就跟计划脱节了。我总结了三层防护措施缺一不可。5.1 把计划变成上下文的锚点我要求AI先把最终版计划写入一个固定文件比如项目根目录的PLAN.md之后的每一轮编码对话都让AI先读这个文件再动手。这个做法本质上是给AI装一个外置记忆。AI会话之间没有真正的记忆把计划写进文件相当于给它的长期记忆做了备份每次新会话都能从锚点重新对齐。实际操作中我每次会加上这句话在开始任何修改前先阅读项目根目录的PLAN.md。你后续的所有实现都必须与其中的任务拆解保持一致。如果实现过程中发现计划需要调整先停下来说明原因不要直接改。不要小看这一步。没有锚点的AI很容易在前几轮对话之后忘记自己最初承诺的方案越改越离谱。有了PLAN.md至少每次对话开始时它知道自己原本打算干什么。5.2 一次只执行一个任务执行阶段我允许AI做的事非常有限一次只处理计划里的一个任务完成自测后再进入下一个。绝不允许一口气把五个任务全做完。这个限制看起来很啰嗦但它能保证你在每个节点都能介入检查而不是AI一口气改了二十个文件后你根本不知道从哪里开始review。一次一个任务还有个额外好处出错定位成本低。AI如果在第二个任务里引入了回归你只需要回滚第二个任务的改动不会波及整个迭代。对长周期项目来说这个习惯省下的排错时间非常可观。5.3 偏差处理的三条原则执行过程中发现计划与实际代码不符是很正常的事。真正拉开差距的是处理偏差的方式。我给自己定了三条原则第一技术性偏差比如某个API参数实际不存在、某处依赖版本不对可以由AI当场修正但需要在最后的总结里说明。第二结构性偏差比如发现需要动计划之外的第三个模块必须停下来回到计划层面讨论不许顺手就改。第三需求性偏差比如发现原来理解的需求有误必须重新走需求澄清流程禁止在代码层面硬凑。这三条原则看起来很严格其实是在保护AI不在错误方向上跑太远。我不止一次因为偷懒允许AI顺手改了计划外的模块结果那部分代码成了整个项目里最没人敢碰的地方。严格一点短期看是麻烦长期看是省事。6. 我踩过的坑五个典型的Plan模式失效场景任何方法论都不能只讲理想状态。下面五个失效场景是我自己踩过、也看团队其他人反复踩过的逐个说出来能帮你省不少学费。6.1 计划与代码库脱节症状是AI给的计划洋洋洒洒但引用的文件路径、函数名跟真实代码完全对不上或者提到的模块在当前版本里已经被重构掉了。根因是计划阶段没有实际去读代码库而是基于训练时的记忆在写。应对方法就是2.2里说的强制要求所有涉及现有代码的结论必须标注文件路径和行号审查时随机抽两三个路径核对。这条太常发生了所以值得反复强调。6.2 过度规划症状是计划细致到每一行代码怎么写任务清单列了三十项结果真正改起来二十分钟就完成了审查计划倒是花了两小时。根因是把Plan模式用成了文档生成忽略了它在信息收敛层面的真正价值。应对方法是把任务粒度锚定在一次一个可独立验证的逻辑模块不要拆到函数内部。过度规划还有个隐蔽危害计划越长越没人认真看最后沦为一堆漂亮的摆设。6.3 计划通过后AI执行偏离症状是审查计划时一切正常执行阶段AI却走了另一条路用了计划里没讨论过的方案或者改动范围悄悄扩大。根因是计划在执行阶段只被当成背景材料而不是必须遵守的行动准则。应对方法就是第5节的三层防护——锚点文件、逐任务执行、偏差处理原则就是专门为这个场景设计的。6.4 验收标准不可验证症状是计划里的每个任务都写着完成但没有任何验证手段执行阶段只能靠AI自说自话。根因是第四回合拆解任务时偷懒了。应对方法是严格执行五分钟内可验证原则任何无法快速验证的任务打回重写。这个原则还有一个副作用它会倒逼你把任务拆得更合理因为一个庞大的任务几乎不可能有五分钟内可验证的标准。6.5 计划完美但需求一开始就错了症状是计划本身无可挑剔但方向就是错的——需求理解的关键假设从一开始就不成立。根因是跳过了2.1的需求澄清回合直接让AI基于模糊需求产出计划。应对方法是无论如何都不跳步需求没有收敛之前绝不进入方案设计。这条看起来最基础实际执行中却是最容易被砍掉的特别是你自认为需求已经很清楚了的时候。7. 什么情况下不适合用Plan模式Plan模式不是银弹有些场景硬套反而浪费时间。我自己的判断标准很朴素小改动不用。改一行配置、加一个字段、修一个文案直接改代码比写计划快得多Plan模式的固定成本不划算。探索性工作不用。你在做技术Demo、验证思路可行性明知代码很快会被扔掉还花半小时写计划就本末倒置了。反过来重探索轻实现的任务反而适合。比如评估引入某个新组件的可行性这种任务的核心产出本来就是一份分析或计划恰好能发挥Plan模式的强项。还有一种情况需要灵活处理当AI已经在一个大型改动的执行途中时不要临时起意让它切换Plan模式。要么按原计划走完当前任务再规划新任务要么显式开一个新会话做规划。混着用不仅会让模型困惑还会让整个会话的上下文被计划内容污染。我个人最常用的判断句式是如果这个改动失败之后要花超过一小时来回滚或排查就值得先用Plan模式。按这个标准执行了半年多我这边因为AI改代码引发的线上事故和返工确实肉眼可见地少了。AI本身不会变好但只要工作流对了它每次犯错的代价都会被压在计划阶段而不是直接烧到生产环境里。
