用过AI编程助手的人应该都有过这种经历需求还没完全想清楚对话框里就已经打下了“帮我改一下某某模块”这样的指令然后看着大模型一顿操作猛如虎结果改出来的代码跟预期差了十万八千里甚至把原本正常的逻辑都给折腾坏了。我自己踩过几次这种坑之后开始认真对待一个看起来很简单、但实际操作起来并不容易的工作阶段——Plan Mode也就是在执行任何改动之前先把“探索”和“规划”这两件事做到位再谈动手。Plan Mode本质上是给开发过程加了一道“先想后做”的保险闸。它要解决的核心问题不是“怎么写得快”而是“怎么写得对”。在我们和AI协作开发的场景里这个模式尤其重要大模型再聪明它也不了解你项目的上下文不了解那些隐藏在代码背后的业务约束更不了解你这次改动会波及到哪个犄角旮旯。如果你不给它时间和机制去做探索它就只能靠猜。猜对了是本事猜错了就是事故。这篇文章我会从探索、规划、执行转换和问题排查几个角度把Plan Mode这套工作流的实操心得完整梳理一遍适合正在使用或准备使用AI辅助编程工具的人参考也适合那些想把自己团队开发流程做得更稳健的开发者。1. Plan Mode的整体思路为什么“先想后做”反而是最快的路径很多开发者包括我自己以前都有一个思维惯性拿到任务就开干。总感觉先跑起来才能暴露问题想太多是浪费时间。但在涉及代码变更的场景里这个直觉往往是错的。写代码的成本里真正的大头不是“把代码敲出来”而是“搞清楚到底要改哪里、怎么改才不会炸”。Plan Mode的核心思路就是把后者从潜意识动作提升为一个显式的、有步骤的工作阶段。1.1 用“施工现场”类比理解Plan Mode的价值想象一下你要给老房子改水电。一个鲁莽的师傅上来就砸墙砸完了发现水管走向跟图纸对不上承重墙不能开槽结果既要补墙又要重新设计材料和工期翻倍。一个靠谱的师傅会先做什么他会先拿到原始结构图到现场确认管线走向测量墙面厚度评估哪些墙能改哪些墙不能动然后跟你确认设计方案最后才让工人进场。这个“先看图、再勘察、后出方案”的阶段就是施工领域的Plan Mode。搞软件开发其实也一样代码库就是一个结构极其复杂的老房子你每一次改动都是动一次水电。没有前期勘察就开砸能不能改好全凭运气。Plan Mode强迫我们把“勘察”和“砸墙”分成两个独立的阶段。这样有一个很明显的好处探索阶段是可以随意试错的。你可以让AI读一百个文件去理解逻辑可以追问各种“如果这里改成这样会怎样”的假设性问题这些操作都是零成本、零风险的。但一旦进入执行阶段每一个改动都有代价。所以从效率角度看在探索阶段多花半小时搞清楚问题比执行阶段花半天收拾残局要划算得多。1.2 Plan Mode与直接执行的核心差异对比直接执行模式和Plan Mode最大的差异不在工具本身而在“上下文获取”的路径上。直接执行模式里AI收到指令后马上开始写代码它对你的项目了解可能只有当前打开的几个文件片段。Plan Mode则要求AI先系统性地理解项目结构、关键模块、现有约束再给出方案。比较维度直接执行Plan Mode上下文获取依赖当前片段容易遗漏系统性探索覆盖全局相关点试错成本高错误会写入代码低仅存在于分析过程变更预判弱常改一处漏一处强能梳理影响面结果可预期性波动大时好时坏稳定方案先行适合场景小改动、确定性强跨模块、需求模糊、风险高前面提到Plan Mode能带来更稳的结果但代价是它需要更好的驾驭技巧。接下来我会把整个工作流拆成几个阶段来详细说先聊探索阶段怎么做再聊规划阶段怎么把方案落到纸面上最后聊怎么切换到执行模式以及期间的常见问题。每个阶段我都会从实操角度给具体方法而不是停留在概念层面。2. 探索阶段实操怎么把项目“读透”又不被带偏探索是整个Plan Mode的地基。地基没打牢后面规划得再漂亮都是空中楼阁。探索阶段的产出不是代码而是对项目当前状态的一个完整认知相关模块在哪、数据怎么流转、现有实现有什么约束、你的改动会碰到哪些依赖。这些信息搞不清楚计划就无从谈起。2.1 探索阶段到底该看哪些东西我让AI进入Plan Mode之后第一件事永远是梳理目标功能的上游和下游。上游是指“谁调用了这段逻辑”包括入口、事件的触发方、外部系统的请求等下游是指“这段逻辑调用了谁”包括数据库表、外部接口、内部服务、缓存键等。这一上一下梳理清楚你就能画出一条完整的数据流路线而不是只盯着要改的那一个函数。具体操作上我会让AI依次完成四类信息的收集定位入口找到这个功能是从哪里被触发的。是HTTP接口、消息队列监听还是定时任务入口决定了你改动的暴露面。梳理核心链路沿着入口往下走记录主要的函数调用关系。不用到叶子节点但要覆盖主路径。标注共享依赖这个模块用到的工具函数、数据表、配置项还有没有别的模块在用这是最容易踩雷的地方。找出隐蔽约束比如某个字段有枚举值约束、某个接口有超时要求、某段逻辑依赖时序。这些往往是代码注释里不会写、但一碰就炸的东西。有一次我接手一个订单状态流转的功能优化需求本身很简单把“已支付”状态的订单允许用户主动取消。如果不多想一步直接改看起来也就是在cancel函数里加一个状态判断。但探索阶段让AI去查了“已支付”状态会被哪些地方消费结果发现至少有三个统计分析任务在轮询这个状态的数据还有对账系统依赖状态快照。如果改成允许取消但不做状态联动对账那边立刻就会出问题。这就是探索的价值——它告诉我们“不能只看眼前的代码”。2.2 不依赖项目文档的探索技巧现实里大部分项目的架构文档都是过时的代码才是唯一可信的事实来源。Plan Mode的探索阶段可以完全不依赖文档直接通过几个技巧快速定位关键信息从配置文件倒推技术栈让AI先读工程配置文件搞清楚这个项目用了什么框架、有哪些模块、启用了哪些特性。框架本身就会告诉它很多隐含约定。沿着错误信息和调试点反查如果这个功能之前出现过异常或遗漏让AI先找到相关日志处理逻辑和错误类型再向上反查触发路径往往比正着读代码更快。用“拟修改点”作为一个锚点展开先大致定位你要动的文件然后从该文件出发向外读出它的直属调用方和被调用方逐层扩散。这种“涟漪式”探索比从头读整个项目高效得多也更聚焦。需要有心理预期的是探索阶段得到的信息里大概有20%~30%最终和你的任务无关。这不叫浪费这叫排除法。AI刚开始读的很多文件是为了确认“这里不用改”这种确认本身是规划的必要输入。我见过有人抱怨“AI读了一大堆无关文件”其实恰恰是这些“无关”文件帮我们确认了边界在哪里后续执行时才能大胆下手。2.3 探索成果如何约束执行方向探索完成后我习惯让AI输出一份“探索结论摘要”包含目标相关的关键文件列表、核心数据流走向、已发现的风险点和未确认的假设。这份摘要会直接作为规划的输入。更重要的是这些内容会成为执行阶段“改动边界”的依据——哪些文件允许动哪些文件不允许动有时候比告诉AI要做什么更关键。探索阶段还有一个容易被忽略的作用就是提前排查那些导致方案不可行的前置条件。比如你想给某个查询加索引来加速但探索时发现这个表是另一个团队在维护的公共表索引变更需要走审批流程。如果跳过探索直接开干等你的计划做到一半才发现这个问题前面所有的规划都得推翻重来。3. 规划阶段落地把探索结论变成一份可执行的施工蓝图探索阶段搞清楚“现状是什么样”规划阶段就要回答“改成什么样”和“怎么改”。规划不是把需求复述一遍就完事而是要产出一份具体到文件级别、步骤级别、风险级别的实施方案。这项产出越清晰后续执行阶段就越不需要动脑越不容易跑偏。3.1 把模糊需求翻译成可验收的改动目标这是蓝图中最重要的部分。多数需求描述都是模糊的比如“优化一下首页加载速度”“让用户能导出报表”“加一个防重复提交”。规划阶段必须把这些模糊描述翻译成明确的技术改动目标。我的要求是每个目标必须包含“改动对象”、“预期行为”、“不做什么”三要素。举个例子“让用户能导出报表”翻译出来可能是改动对象报表查询服务、导出控制器、前端导出按钮预期行为用户点击导出后后台异步生成CSV文件完成后提供下载链接不做什么不改变原有在线预览的展示逻辑不做Excel格式导出不加导出权限控制“不做什么”边界很容易被忽略但它极其重要。很多AI执行到一半开始自作主张地“增强功能”比如顺带优化了一下代码风格、重构了一下附近的方法、或者补充了额外的校验这些都是计划外的隐患。在规划阶段明确“不做什么”等于给执行阶段划了一条红线。3.2 任务拆分怎么设计步骤之间的依赖关系有了改动目标接下来要把它拆成具体步骤。好的拆分方式是按照“依赖性”排序而不是按“难易程度”排序。也就是说先做那些被别人依赖的基础步骤后做那些依赖别人的上层步骤。这样做的好处是每一步完成后都能立刻验证不用憋到最后一次性调试。我常用的规划模板是准备阶段新增配置项、建表、加依赖库基础改造改数据结构/模型层、加工具方法逻辑修改改核心业务函数、插入新判断分支接口适配更新上游调用方、调整外部接口收尾清理删废弃代码、补充测试用例、更新文档每一条步骤都要标注涉及的文件路径和预计的影响面。这样后续执行时AI每完成一个步骤你可以对照规划一步一步核对而不是对着最终结果猜过程。3.3 风险预估哪些环节最容易爆雷规划阶段还必须对风险有预判。常见的风险源包括我的习惯是在规划文档里专门开一个“风险清单”小节用表格形式列出风险点、触发条件、应对策略。这样意味着不仅提前识别问题更重要的是为每一个风险都找一个兜底方案。比如“新增的状态值可能影响历史数据统计”应对策略就是“统计模块SQL里加状态过滤条件并在测试环境用生产数据抽样验证”。风险清单不是为了制造焦虑而是为了让执行阶段的你心里有底——最坏的情况下你知道该怎么收场。另外我要提醒一点规划阶段产出的方案不需要追求“一次完美”。方案是拿来指导执行的如果执行过程中发现更优解完全可以调整。但调整的前提是“有意识的修改”而不是“稀里糊涂跑偏”。Plan Mode给的是一张可修改的施工图不是一份不可违反的合同。4. 从规划到执行的切换怎么守住边界又不被计划绑死规划做完以后很多人会在切换阶段犯两个极端错误一是规划完毕立刻让AI执行连规划内容都没和AI对齐二是在执行过程中遇到计划外信息就完全抛开计划回到“边走边看”的老路。我自己的经验是切换也是一个独立动作要严肃对待。4.1 切换前需要确认的四个问题AI是否真正理解规划内容光把方案文本扔给它还不够最好让它复述一遍核心目标和步骤顺序确认理解一致。如果AI复述出来有偏差现在纠正成本最低。是否设置了明确的度量点即每完成一步用什么标准判断“这一步做对了”。没有度量点的话执行过程中很难判断进展是否正常。回滚条件是否明确有没有想清楚哪些情况出现时应该暂停甚至回滚比如测试数据异常增多、原来已验证的接口突然报错等。计划的执行顺序是否需要调整有时候探索阶段发现的新信息会导致原计划步骤需要微调。在切换前花两分钟审视一下计划比执行到一半再改要顺利得多。这轮确认做扎实了后面执行阶段就有了一种类似“自动驾驶”的感觉AI按计划逐步实现你按计划逐步验收。不是说可以完全撒手不管但需要你主动纠偏的频率会大幅降低。4.2 执行过程中如何对待计划外的发现执行阶段几乎必然会遇到计划外的信息。我的处理原则是区分“该不该现在处理”。有几种情况我是选择先记录下来、不打断主流程的发现了无关代码的质量问题、命名不规范、缺乏注释等发现了潜在优化点但当前改动不涉及发现有其他模块调用方式与自己预想不一致但不影响本次目标但也有几种情况我会毫不犹豫地暂停执行回到规划阶段重新讨论所以我的建议是在执行过程中给自己保留随时回到AcPlan Mode的权利。已开头的执行任务如果发现方向性问题果断放弃比硬撑着完成要好得多。不要觉得规划被推翻是浪费时间恰恰是规划帮你更早、更便宜地发现了问题。4.3 分步验收让执行过程始终处于可控状态执行阶段我强烈反对让AI一口气把所有步骤全部完成再给你看一个巨大的diff。因为那时候如果出问题你根本无法判断问题出在哪一个环节、哪一行改动。正确的做法是“分步验收”每一步执行完立即检查这一步的产出。比如说第一步是“加一个新的配置项”那你验收的内容就是配置项是否加在正确的地方命名是否符合项目规范是否有对应的默认值说明。只有这步验收通过才允许AI进入下一步。这样做的好处是AI出的偏差会被限制在一个很小的范围内不会滚雪球一样等到最后才爆发。在Plan Mode的语境下执行阶段不归Plan Mode管但真正好用的Plan Mode会让执行阶段变得极其顺利。因为当AI带着完整的项目认知和清晰计划进入执行时它写出来的代码质量要远高于“盲改”并且它知道自己每一步在做什么、为什么这样做。这就是规划的意义——不是为了约束AI而是为了让AI的动作始终在你的可预期范围内。5. 常见问题与排查技巧我在实操中踩过的坑和总结的经验用Plan Mode这套流程跑了一段时间之后我也积累了一堆失败经验。有些坑属于规划阶段思路不对有些属于执行阶段切换不得法还有些属于工具使用习惯的问题。这里整理成问答形式当作一份快速排查表供参考。5.1 规划做得很详细但执行结果还是不对怎么回事常见诱因排查方法规划文件没被AI阅读检查是否确认AI已吸收方案必要时让它复述计划中的文件路径与实际路径不符让AI在执行前确认每个文件都存在计划里遗留了模糊词汇检查“尽量”“优化”“合理”这类词是否已被量化执行过程中偏离计划观察AI是否有未在计划中的额外操作这个问题通常不是计划本身的错而是“计划与执行脱节”了。我遇到最多的情况是我自己以为把方案写清楚了但AI理解的执行路径和我预期的完全不一样。所以后来养成了习惯执行开始前必须让AI用自己的话把计划讲一遍讲到我能确认它理解的是对的为止。如果AI讲出来的计划和我写的不一致多半是我哪里表述模糊让它自由发挥了。还有一种情况是你给的规划文件路径时代码已经发生了变动。比如昨天规划的代码结构和今天实际代码不同如果AI按旧计划执行自然会对不上。这种时候最好的解决方式是直接更新探索结论和规划再执行而不是硬着头皮按原计划改。5.2 探索阶段信息过载怎么判断哪些信息该深挖哪些该跳过这需要靠“目标的紧迫性”来判断。好的探索不是把代码库全部读一遍而是围绕你要达成的目标判断哪些信息是“直接相关”、哪些是“间接相关”、哪些是“无需关注”。一个比较实用的判断标准是这条信息会不会影响你要改动的那段逻辑的正确性。如果不会跳过如果会深挖。宁可多读一些直接相关文件也不要被无关话题带偏。也有一种常见误区是探索时老想“顺便搞明白一个无关架构问题”。这种好奇心值得鼓励但不是现在的任务。我的做法是把闪过的疑问记录到“探索备注”里等主线任务完成后再回头研究。Plan Mode的精神是“聚焦”不是“发散”。5.3 项目太老、代码太乱探索阶段根本理不出头绪怎么办越是存量复杂的老项目Plan Mode越能发挥价值但也更考验探索技巧。遇到这种项目我会换一种探索策略不再追求把全链路理清楚而是先找出“最小可行理解”。也就是只要能回答这几个问题就够了目标功能对应的现有入口和存储是什么、改动需要牵涉几个核心文件、有没有明显未知的依赖风险。先做到这个程度把规划做起来然后在执行阶段边做边加深理解。这种方法牺牲了一定程度的全局掌控换来了可启动性。它不适合高风险核心模块但对中等风险模块是可行的。我的记录习惯是执行过程中的每轮新发现都会反向补全到规划文档里作为后续调整的依据。5.4 如何在团队中推广Plan Mode的工作习惯很多人会问Plan Mode是个人工具怎么让团队都受益说实话硬推是推不动的。我自己就把这套流程拆成三个轻量约定来引导第一凡是涉及跨模块改动必须先在讨论帖里输出一段“问题理解改动方案”再动手第二方案里必须标注“不做什么”第三允许任何人说“等一下先回Plan Mode”。这里面最关键的其实是第三点——它给了每个人承认“暂时没想清楚”的台阶。开发文化里说“我还没搞清楚”比说“我已经改完了但好像有问题”需要更大的勇气。一旦这个台阶被搭出来团队里因为盲目动手导致的返工就会少很多。在AI辅助编程普及之后开发者的核心竞争力已经不是“手速快”而是“判断方向准”。Plan Mode这套工作流说到底就是在训练我们每次改动前都强迫自己问清楚三个问题现在代码是什么样改了以后想达到什么效果这一步会不会伤到不该伤的地方我能坚持用Plan Mode就是因为它治好了我身上那种“刚接需求就急着敲键盘”的职业病。最后分享一个小技巧你可以把“Plan Mode执行步骤清单”沉淀成一份模板文件每次新任务直接套用而不是每次都从零开始设计探索方案。我自己的模板版本迭代了好几轮现在固定包含探索结论、目标定义、任务拆分、风险清单、验收标准这几块每次用起来都很顺手。模板化之后还有一个额外好处它会把“搞规划”这件事的成本从心理门槛变成流程惯性让你更愿意在动手前多花那15分钟想清楚。这15分钟省下来的是后面不知道多少小时的返工时间。 
长河君 · 2026/10/21 3:19:38 · 阅读 1.2k Plan Mode实操指南：AI编程助手如何“先想后做”避免改崩代码
用过AI编程助手的人应该都有过这种经历需求还没完全想清楚对话框里就已经打下了“帮我改一下某某模块”这样的指令然后看着大模型一顿操作猛如虎结果改出来的代码跟预期差了十万八千里甚至把原本正常的逻辑都给折腾坏了。我自己踩过几次这种坑之后开始认真对待一个看起来很简单、但实际操作起来并不容易的工作阶段——Plan Mode也就是在执行任何改动之前先把“探索”和“规划”这两件事做到位再谈动手。Plan Mode本质上是给开发过程加了一道“先想后做”的保险闸。它要解决的核心问题不是“怎么写得快”而是“怎么写得对”。在我们和AI协作开发的场景里这个模式尤其重要大模型再聪明它也不了解你项目的上下文不了解那些隐藏在代码背后的业务约束更不了解你这次改动会波及到哪个犄角旮旯。如果你不给它时间和机制去做探索它就只能靠猜。猜对了是本事猜错了就是事故。这篇文章我会从探索、规划、执行转换和问题排查几个角度把Plan Mode这套工作流的实操心得完整梳理一遍适合正在使用或准备使用AI辅助编程工具的人参考也适合那些想把自己团队开发流程做得更稳健的开发者。1. Plan Mode的整体思路为什么“先想后做”反而是最快的路径很多开发者包括我自己以前都有一个思维惯性拿到任务就开干。总感觉先跑起来才能暴露问题想太多是浪费时间。但在涉及代码变更的场景里这个直觉往往是错的。写代码的成本里真正的大头不是“把代码敲出来”而是“搞清楚到底要改哪里、怎么改才不会炸”。Plan Mode的核心思路就是把后者从潜意识动作提升为一个显式的、有步骤的工作阶段。1.1 用“施工现场”类比理解Plan Mode的价值想象一下你要给老房子改水电。一个鲁莽的师傅上来就砸墙砸完了发现水管走向跟图纸对不上承重墙不能开槽结果既要补墙又要重新设计材料和工期翻倍。一个靠谱的师傅会先做什么他会先拿到原始结构图到现场确认管线走向测量墙面厚度评估哪些墙能改哪些墙不能动然后跟你确认设计方案最后才让工人进场。这个“先看图、再勘察、后出方案”的阶段就是施工领域的Plan Mode。搞软件开发其实也一样代码库就是一个结构极其复杂的老房子你每一次改动都是动一次水电。没有前期勘察就开砸能不能改好全凭运气。Plan Mode强迫我们把“勘察”和“砸墙”分成两个独立的阶段。这样有一个很明显的好处探索阶段是可以随意试错的。你可以让AI读一百个文件去理解逻辑可以追问各种“如果这里改成这样会怎样”的假设性问题这些操作都是零成本、零风险的。但一旦进入执行阶段每一个改动都有代价。所以从效率角度看在探索阶段多花半小时搞清楚问题比执行阶段花半天收拾残局要划算得多。1.2 Plan Mode与直接执行的核心差异对比直接执行模式和Plan Mode最大的差异不在工具本身而在“上下文获取”的路径上。直接执行模式里AI收到指令后马上开始写代码它对你的项目了解可能只有当前打开的几个文件片段。Plan Mode则要求AI先系统性地理解项目结构、关键模块、现有约束再给出方案。比较维度直接执行Plan Mode上下文获取依赖当前片段容易遗漏系统性探索覆盖全局相关点试错成本高错误会写入代码低仅存在于分析过程变更预判弱常改一处漏一处强能梳理影响面结果可预期性波动大时好时坏稳定方案先行适合场景小改动、确定性强跨模块、需求模糊、风险高前面提到Plan Mode能带来更稳的结果但代价是它需要更好的驾驭技巧。接下来我会把整个工作流拆成几个阶段来详细说先聊探索阶段怎么做再聊规划阶段怎么把方案落到纸面上最后聊怎么切换到执行模式以及期间的常见问题。每个阶段我都会从实操角度给具体方法而不是停留在概念层面。2. 探索阶段实操怎么把项目“读透”又不被带偏探索是整个Plan Mode的地基。地基没打牢后面规划得再漂亮都是空中楼阁。探索阶段的产出不是代码而是对项目当前状态的一个完整认知相关模块在哪、数据怎么流转、现有实现有什么约束、你的改动会碰到哪些依赖。这些信息搞不清楚计划就无从谈起。2.1 探索阶段到底该看哪些东西我让AI进入Plan Mode之后第一件事永远是梳理目标功能的上游和下游。上游是指“谁调用了这段逻辑”包括入口、事件的触发方、外部系统的请求等下游是指“这段逻辑调用了谁”包括数据库表、外部接口、内部服务、缓存键等。这一上一下梳理清楚你就能画出一条完整的数据流路线而不是只盯着要改的那一个函数。具体操作上我会让AI依次完成四类信息的收集定位入口找到这个功能是从哪里被触发的。是HTTP接口、消息队列监听还是定时任务入口决定了你改动的暴露面。梳理核心链路沿着入口往下走记录主要的函数调用关系。不用到叶子节点但要覆盖主路径。标注共享依赖这个模块用到的工具函数、数据表、配置项还有没有别的模块在用这是最容易踩雷的地方。找出隐蔽约束比如某个字段有枚举值约束、某个接口有超时要求、某段逻辑依赖时序。这些往往是代码注释里不会写、但一碰就炸的东西。有一次我接手一个订单状态流转的功能优化需求本身很简单把“已支付”状态的订单允许用户主动取消。如果不多想一步直接改看起来也就是在cancel函数里加一个状态判断。但探索阶段让AI去查了“已支付”状态会被哪些地方消费结果发现至少有三个统计分析任务在轮询这个状态的数据还有对账系统依赖状态快照。如果改成允许取消但不做状态联动对账那边立刻就会出问题。这就是探索的价值——它告诉我们“不能只看眼前的代码”。2.2 不依赖项目文档的探索技巧现实里大部分项目的架构文档都是过时的代码才是唯一可信的事实来源。Plan Mode的探索阶段可以完全不依赖文档直接通过几个技巧快速定位关键信息从配置文件倒推技术栈让AI先读工程配置文件搞清楚这个项目用了什么框架、有哪些模块、启用了哪些特性。框架本身就会告诉它很多隐含约定。沿着错误信息和调试点反查如果这个功能之前出现过异常或遗漏让AI先找到相关日志处理逻辑和错误类型再向上反查触发路径往往比正着读代码更快。用“拟修改点”作为一个锚点展开先大致定位你要动的文件然后从该文件出发向外读出它的直属调用方和被调用方逐层扩散。这种“涟漪式”探索比从头读整个项目高效得多也更聚焦。需要有心理预期的是探索阶段得到的信息里大概有20%~30%最终和你的任务无关。这不叫浪费这叫排除法。AI刚开始读的很多文件是为了确认“这里不用改”这种确认本身是规划的必要输入。我见过有人抱怨“AI读了一大堆无关文件”其实恰恰是这些“无关”文件帮我们确认了边界在哪里后续执行时才能大胆下手。2.3 探索成果如何约束执行方向探索完成后我习惯让AI输出一份“探索结论摘要”包含目标相关的关键文件列表、核心数据流走向、已发现的风险点和未确认的假设。这份摘要会直接作为规划的输入。更重要的是这些内容会成为执行阶段“改动边界”的依据——哪些文件允许动哪些文件不允许动有时候比告诉AI要做什么更关键。探索阶段还有一个容易被忽略的作用就是提前排查那些导致方案不可行的前置条件。比如你想给某个查询加索引来加速但探索时发现这个表是另一个团队在维护的公共表索引变更需要走审批流程。如果跳过探索直接开干等你的计划做到一半才发现这个问题前面所有的规划都得推翻重来。3. 规划阶段落地把探索结论变成一份可执行的施工蓝图探索阶段搞清楚“现状是什么样”规划阶段就要回答“改成什么样”和“怎么改”。规划不是把需求复述一遍就完事而是要产出一份具体到文件级别、步骤级别、风险级别的实施方案。这项产出越清晰后续执行阶段就越不需要动脑越不容易跑偏。3.1 把模糊需求翻译成可验收的改动目标这是蓝图中最重要的部分。多数需求描述都是模糊的比如“优化一下首页加载速度”“让用户能导出报表”“加一个防重复提交”。规划阶段必须把这些模糊描述翻译成明确的技术改动目标。我的要求是每个目标必须包含“改动对象”、“预期行为”、“不做什么”三要素。举个例子“让用户能导出报表”翻译出来可能是改动对象报表查询服务、导出控制器、前端导出按钮预期行为用户点击导出后后台异步生成CSV文件完成后提供下载链接不做什么不改变原有在线预览的展示逻辑不做Excel格式导出不加导出权限控制“不做什么”边界很容易被忽略但它极其重要。很多AI执行到一半开始自作主张地“增强功能”比如顺带优化了一下代码风格、重构了一下附近的方法、或者补充了额外的校验这些都是计划外的隐患。在规划阶段明确“不做什么”等于给执行阶段划了一条红线。3.2 任务拆分怎么设计步骤之间的依赖关系有了改动目标接下来要把它拆成具体步骤。好的拆分方式是按照“依赖性”排序而不是按“难易程度”排序。也就是说先做那些被别人依赖的基础步骤后做那些依赖别人的上层步骤。这样做的好处是每一步完成后都能立刻验证不用憋到最后一次性调试。我常用的规划模板是准备阶段新增配置项、建表、加依赖库基础改造改数据结构/模型层、加工具方法逻辑修改改核心业务函数、插入新判断分支接口适配更新上游调用方、调整外部接口收尾清理删废弃代码、补充测试用例、更新文档每一条步骤都要标注涉及的文件路径和预计的影响面。这样后续执行时AI每完成一个步骤你可以对照规划一步一步核对而不是对着最终结果猜过程。3.3 风险预估哪些环节最容易爆雷规划阶段还必须对风险有预判。常见的风险源包括我的习惯是在规划文档里专门开一个“风险清单”小节用表格形式列出风险点、触发条件、应对策略。这样意味着不仅提前识别问题更重要的是为每一个风险都找一个兜底方案。比如“新增的状态值可能影响历史数据统计”应对策略就是“统计模块SQL里加状态过滤条件并在测试环境用生产数据抽样验证”。风险清单不是为了制造焦虑而是为了让执行阶段的你心里有底——最坏的情况下你知道该怎么收场。另外我要提醒一点规划阶段产出的方案不需要追求“一次完美”。方案是拿来指导执行的如果执行过程中发现更优解完全可以调整。但调整的前提是“有意识的修改”而不是“稀里糊涂跑偏”。Plan Mode给的是一张可修改的施工图不是一份不可违反的合同。4. 从规划到执行的切换怎么守住边界又不被计划绑死规划做完以后很多人会在切换阶段犯两个极端错误一是规划完毕立刻让AI执行连规划内容都没和AI对齐二是在执行过程中遇到计划外信息就完全抛开计划回到“边走边看”的老路。我自己的经验是切换也是一个独立动作要严肃对待。4.1 切换前需要确认的四个问题AI是否真正理解规划内容光把方案文本扔给它还不够最好让它复述一遍核心目标和步骤顺序确认理解一致。如果AI复述出来有偏差现在纠正成本最低。是否设置了明确的度量点即每完成一步用什么标准判断“这一步做对了”。没有度量点的话执行过程中很难判断进展是否正常。回滚条件是否明确有没有想清楚哪些情况出现时应该暂停甚至回滚比如测试数据异常增多、原来已验证的接口突然报错等。计划的执行顺序是否需要调整有时候探索阶段发现的新信息会导致原计划步骤需要微调。在切换前花两分钟审视一下计划比执行到一半再改要顺利得多。这轮确认做扎实了后面执行阶段就有了一种类似“自动驾驶”的感觉AI按计划逐步实现你按计划逐步验收。不是说可以完全撒手不管但需要你主动纠偏的频率会大幅降低。4.2 执行过程中如何对待计划外的发现执行阶段几乎必然会遇到计划外的信息。我的处理原则是区分“该不该现在处理”。有几种情况我是选择先记录下来、不打断主流程的发现了无关代码的质量问题、命名不规范、缺乏注释等发现了潜在优化点但当前改动不涉及发现有其他模块调用方式与自己预想不一致但不影响本次目标但也有几种情况我会毫不犹豫地暂停执行回到规划阶段重新讨论所以我的建议是在执行过程中给自己保留随时回到AcPlan Mode的权利。已开头的执行任务如果发现方向性问题果断放弃比硬撑着完成要好得多。不要觉得规划被推翻是浪费时间恰恰是规划帮你更早、更便宜地发现了问题。4.3 分步验收让执行过程始终处于可控状态执行阶段我强烈反对让AI一口气把所有步骤全部完成再给你看一个巨大的diff。因为那时候如果出问题你根本无法判断问题出在哪一个环节、哪一行改动。正确的做法是“分步验收”每一步执行完立即检查这一步的产出。比如说第一步是“加一个新的配置项”那你验收的内容就是配置项是否加在正确的地方命名是否符合项目规范是否有对应的默认值说明。只有这步验收通过才允许AI进入下一步。这样做的好处是AI出的偏差会被限制在一个很小的范围内不会滚雪球一样等到最后才爆发。在Plan Mode的语境下执行阶段不归Plan Mode管但真正好用的Plan Mode会让执行阶段变得极其顺利。因为当AI带着完整的项目认知和清晰计划进入执行时它写出来的代码质量要远高于“盲改”并且它知道自己每一步在做什么、为什么这样做。这就是规划的意义——不是为了约束AI而是为了让AI的动作始终在你的可预期范围内。5. 常见问题与排查技巧我在实操中踩过的坑和总结的经验用Plan Mode这套流程跑了一段时间之后我也积累了一堆失败经验。有些坑属于规划阶段思路不对有些属于执行阶段切换不得法还有些属于工具使用习惯的问题。这里整理成问答形式当作一份快速排查表供参考。5.1 规划做得很详细但执行结果还是不对怎么回事常见诱因排查方法规划文件没被AI阅读检查是否确认AI已吸收方案必要时让它复述计划中的文件路径与实际路径不符让AI在执行前确认每个文件都存在计划里遗留了模糊词汇检查“尽量”“优化”“合理”这类词是否已被量化执行过程中偏离计划观察AI是否有未在计划中的额外操作这个问题通常不是计划本身的错而是“计划与执行脱节”了。我遇到最多的情况是我自己以为把方案写清楚了但AI理解的执行路径和我预期的完全不一样。所以后来养成了习惯执行开始前必须让AI用自己的话把计划讲一遍讲到我能确认它理解的是对的为止。如果AI讲出来的计划和我写的不一致多半是我哪里表述模糊让它自由发挥了。还有一种情况是你给的规划文件路径时代码已经发生了变动。比如昨天规划的代码结构和今天实际代码不同如果AI按旧计划执行自然会对不上。这种时候最好的解决方式是直接更新探索结论和规划再执行而不是硬着头皮按原计划改。5.2 探索阶段信息过载怎么判断哪些信息该深挖哪些该跳过这需要靠“目标的紧迫性”来判断。好的探索不是把代码库全部读一遍而是围绕你要达成的目标判断哪些信息是“直接相关”、哪些是“间接相关”、哪些是“无需关注”。一个比较实用的判断标准是这条信息会不会影响你要改动的那段逻辑的正确性。如果不会跳过如果会深挖。宁可多读一些直接相关文件也不要被无关话题带偏。也有一种常见误区是探索时老想“顺便搞明白一个无关架构问题”。这种好奇心值得鼓励但不是现在的任务。我的做法是把闪过的疑问记录到“探索备注”里等主线任务完成后再回头研究。Plan Mode的精神是“聚焦”不是“发散”。5.3 项目太老、代码太乱探索阶段根本理不出头绪怎么办越是存量复杂的老项目Plan Mode越能发挥价值但也更考验探索技巧。遇到这种项目我会换一种探索策略不再追求把全链路理清楚而是先找出“最小可行理解”。也就是只要能回答这几个问题就够了目标功能对应的现有入口和存储是什么、改动需要牵涉几个核心文件、有没有明显未知的依赖风险。先做到这个程度把规划做起来然后在执行阶段边做边加深理解。这种方法牺牲了一定程度的全局掌控换来了可启动性。它不适合高风险核心模块但对中等风险模块是可行的。我的记录习惯是执行过程中的每轮新发现都会反向补全到规划文档里作为后续调整的依据。5.4 如何在团队中推广Plan Mode的工作习惯很多人会问Plan Mode是个人工具怎么让团队都受益说实话硬推是推不动的。我自己就把这套流程拆成三个轻量约定来引导第一凡是涉及跨模块改动必须先在讨论帖里输出一段“问题理解改动方案”再动手第二方案里必须标注“不做什么”第三允许任何人说“等一下先回Plan Mode”。这里面最关键的其实是第三点——它给了每个人承认“暂时没想清楚”的台阶。开发文化里说“我还没搞清楚”比说“我已经改完了但好像有问题”需要更大的勇气。一旦这个台阶被搭出来团队里因为盲目动手导致的返工就会少很多。在AI辅助编程普及之后开发者的核心竞争力已经不是“手速快”而是“判断方向准”。Plan Mode这套工作流说到底就是在训练我们每次改动前都强迫自己问清楚三个问题现在代码是什么样改了以后想达到什么效果这一步会不会伤到不该伤的地方我能坚持用Plan Mode就是因为它治好了我身上那种“刚接需求就急着敲键盘”的职业病。最后分享一个小技巧你可以把“Plan Mode执行步骤清单”沉淀成一份模板文件每次新任务直接套用而不是每次都从零开始设计探索方案。我自己的模板版本迭代了好几轮现在固定包含探索结论、目标定义、任务拆分、风险清单、验收标准这几块每次用起来都很顺手。模板化之后还有一个额外好处它会把“搞规划”这件事的成本从心理门槛变成流程惯性让你更愿意在动手前多花那15分钟想清楚。这15分钟省下来的是后面不知道多少小时的返工时间。