几个月前我接手了一个老项目的功能迭代。需求本身不算复杂就是在现有权限体系上增加一个角色维度。我打开常用的AI编程工具把需求一贴直接让它“帮我改代码”。结果不到两分钟AI就改完了编译也通过了。我还没来得及高兴一跑回归测试另外两个模块的鉴权逻辑全乱了——AI为了“复用权限判断”顺手改了核心过滤器顺带影响了所有走过滤器的接口。那次返工花了我整整一下午比我自己动手写还慢。从那之后我养成了一个习惯不管需求大小先进 Plan Mode把探索和规划放在执行前面。这里的 Plan Mode 不是什么高深的理论它就是很多AI编程工具里自带的一个工作模式——在执行任何实际修改之前让AI先读代码、理逻辑、列计划等你确认了再动手。这个模式解决的核心问题特别朴素AI直接动手改代码往往改错方向、改漏范围甚至把原本能跑的逻辑改得面目全非。这篇文章我就把 Plan Mode 从概念到实操完整拆一遍包括它解决了什么痛点、底层工作流程、完整操作步骤、以及我在真实项目里踩过的坑。不论你用的是哪款编码助手只要你的工具里带这个模式或者你愿意手动模拟这套流程今天的分享都能直接抄作业。1. Plan Mode是什么先弄清楚它到底解决什么问题1.1 没有Plan Mode时AI直接执行有多冒险很多人用AI编程助手的方式是“描述需求让它直接改”。这种用法方便是方便但风险完全不可控。我给AI下指令“在用户列表接口加一个按部门筛选的参数”它收到指令后的典型反应是直接打开Controller、Service、数据访问层按自己的理解开始改。改完告诉你“已完成”你也不确定它到底动了哪些地方。问题在于AI在直接执行模式下默认把“完成你提出的可见需求”作为唯一目标它不会主动去评估这个改动会不会影响其他调用方。比如上面的筛选需求正常做法是在原有查询方法上加一个可空参数大部分情况下兼容但AI可能为了让“筛选”更彻底改写了查询构建器导致所有调用这个查询构建器的地方行为都变了。这种问题编译期往往发现不了只有跑到特定业务路径上才会暴露等测试报出来的时候你已经很难定位是它改的那部分出了问题。再一个风险是“自我猜测”。直接执行模式下AI遇到模棱两可的需求不会停下来问你而是会挑一个它认为最合理的解释去实现。比如你说“优化一下这个接口的性能”它可能直接给数据库表加上索引或者把同步逻辑改成异步每一种解释都能自圆其说但很可能跟你想要的方向完全相反。改完之后你又得花时间解释为什么不对还不如一开始就让它先拿出方案。1.2 Plan Mode的核心工作流程探索、规划、确认、执行Plan Mode的工作流程说白了就是四个阶段探索、规划、确认、执行。探索阶段AI会主动读取项目结构、关键文件、相关模块的代码搞清楚它将要改动的那部分到底是怎么运作的规划阶段它把需求映射到具体的文件、函数、数据表上列出需要新增、修改、删除的地方以及每个改动点的影响范围确认阶段它把这份计划拿给你看等你同意或提出修改意见确认之后才切换到执行模式真正开始动代码。这四步里前两步是在Plan Mode内部完成的第三步是模式切换的关卡第四步是执行模式的事。很多人误以为Plan Mode只是让AI多问一句“你确定要这么做吗”其实完全不是。它的核心价值在于让AI在动手之前先对代码库形成完整认知再基于这个认知给出一个可评审的改动方案。你有没有发现这跟我们人写代码的思考过程是一样的——先读代码搞清楚现状再想方案然后才动手而不是拿到需求就敲键盘。1.3 一个容易被误解的点Plan Mode不是聊天记录里的“问一遍”我见过有人这样用Plan Mode把需求发给AIAI问“您确认要修改xxx文件吗”用户回“确认”然后AI就开始改了。这压根不是Plan Mode这只是对话里的一个普通确认。真正的Plan Mode应该是AI先花时间把相关代码读一遍输出类似“我发现了这些关联逻辑其中某模块调用了该方法如果直接改会影响到另外三个接口”这样的探索结论然后再输出一份结构化的改动清单比如“新增文件A、修改文件B中的C函数、更新测试用例D、需要关注缓存失效风险”最后才是你点击确认。判断你的工具是否真正支持Plan Mode就看两点第一它有没有主动扫描并理解代码库而不是只盯着你贴出来的那几行代码第二它给出的计划是“具体文件具体改动点风险说明”还是一句“我将修改相关代码以完成您的需求”。如果是后者那你只是拿Plan Mode的名字当了个确认按钮真正的探索和规划能力压根没打开。2. 为什么“先探索再规划”能显著降低执行风险2.1 代码探索是改代码的地基省了必踩坑做开发的人都知道改代码最怕的就是“没读透就动手”。AI也一样它比人更依赖对现有代码的完整理解因为它是基于概率生成代码的给它看越多的相关上下文它生成的内容越接近真实需求。Plan Mode里的探索阶段本质上就是强迫AI“多读一些文件再开口说话”。举个例子我当时给某业务模块加一个字段需求是“在订单列表新增一个支付渠道字段”。如果让AI直接干它很可能在订单实体、列表查询和详情页各加一个字段万事大吉。但在Plan Mode下它去读了订单模块的代码发现订单实体本身是从另一个微服务同步过来的本地加字段根本不会自动持久化真正的改动点在于消息消费时的映射逻辑以及同步任务里的字段转换。这两者相差十万八千里一个只是页面展示一个涉及数据落库。探索阶段AI具体会做什么它会比较有经验地读这几类东西入口文件路由、控制器、核心数据模型、数据库迁移脚本或建表语句、服务层或业务逻辑层的关键函数、配置文件。有些做得更细的AI还会去追踪依赖关系比如某个函数被谁调用了、某个表被哪些模块引用了。这一套下来它生成的计划才不是“想当然”而是建立在实际代码基础上的判断。2.2 规划阶段的本质把返工成本压到最低写代码这件事最贵的从来不是“敲键盘”而是“改方案”。一行代码写错改起来几秒钟但整个技术方向搞错了返工可能是一天甚至几天。规划阶段的作用就是在你投入任何实际编码之前先把技术方向和改动范围对齐把返工成本压在最低。我用装修来类比你要给家里加一个插座电工师傅到了现场先看电路走向、判断墙体结构然后给你说“我打算从这条线路引线在这里开口需要拆一小段踢脚线”你确认了他才动手。他绝对不会什么也不看直接在承重墙上开槽。Plan Mode之于代码就是电工师傅手里的图纸和现场勘察报告。有了这份计划你可以在“砸墙”之前提出“我不想拆踢脚线换个走线方案”代价几乎为零等墙砸完了再想改方案恢复原状的成本就大了。实际使用中我也确实遇到过计划阶段就发现问题的场景。有个需求是调整某报表的统计口径AI原本打算直接改查询SQL但在规划时进行了影响面检查发现这个SQL的结果被下游三个接口消费直接改口径会导致下游数据变化。于是计划变成了“新建一个查询方法保留原方法只让报表接口切换到新方法”。这个过程里一行业务代码没写就已经规避了一个线上风险。2.3 人机协作的分界线AI负责发散检索人负责收敛判断Plan Mode还有一个很微妙的价值它把人机协作的分界线划清楚了。AI的优势是全面检索快看代码快可以一口气列出几十个潜在关联文件人的优势是理解业务意图能做价值判断。Plan Mode正好让两者各司其职AI输出尽可能完整的候选方案和影响面清单你来做最终决策拍板“这个方向对那个不能动”。我强烈建议你在这个过程中把AI当成一个可以无限发散的下属而不是一个完美的专家。它列出的改动点你全部要过一遍它标注的“低风险”项你反而要多看一眼因为AI对风险等级的判断偶尔是乐观的。我习惯在它输出计划之后追问几个问题“这个改动会不会影响定时任务有没有可能破坏幂等新增字段的兼容性处理做了没有”这些问题AI通常能在规划阶段直接回答能答上来的执行时就踏实多了。3. Plan Mode的完整实操流程一步一步拆开3.1 需求怎么写Plan Mode才能产出高质量计划很多人忽略了一个关键环节给Plan Mode的任务描述质量直接决定计划质量。如果只写“帮我加个XX功能”AI就只能猜但如果你给的是“在订单列表中新增支付渠道筛选条件该字段来源于支付回调需要支持多选如果未传该参数则保持原有逻辑”AI的探索方向立刻变得清晰它知道去读哪几个文件也知道验收标准是什么。我总结了一个需求描述模板照着写基本不会跑偏功能背景一句话、具体的输入输出、边界条件、验收标准。举个例子我某个虚拟项目中需要给用户管理模块增加账号冻结功能我是这样描述的“现有用户管理模块位于某后台系统需要给非管理员用户增加冻结/解冻操作。冻结后用户无法登录已登录的Token在5分钟内失效。解冻后恢复正常。冻结操作需要记录操作人与时间。请先探索现有用户登录和Token校验逻辑输出改动计划。”这段话没有任何多余信息但每一句都在缩小AI的探索范围。如果项目里有明显的代码规范或者约定的架构模式最好也写进去比如“本项目数据库操作统一走DAO层不允许在Service里直接写SQL”之类。这会直接影响AI在计划里给出的技术方案是否贴合团队规范。我自己吃过亏没写结果AI按自己习惯写了全新的访问逻辑计划看着挺合理实际上跟项目里其他代码风格完全不一致。3.2 从需求到改动点AI是怎么拆解的AI在Plan Mode里接到需求后拆解改动点的方式其实跟资深程序员很接近。它会先定位入口然后沿调用链往下追接口控制器入参处理、业务逻辑处理、数据持久化层、再反向看返回值如何组装。拆解结果通常以文件维度呈现你可以要求它用表格输出这样一目了然。就拿“添加按部门筛选用户”这个需求举例我让AI输出拆解计划它给的是这样一份表改动点涉及文件具体操作风险等级接口入参用户查询控制层文件新增部门ID参数可空空值不影响原逻辑低业务过滤逻辑用户服务层文件在查询条件构建处追加部门条件中数据访问层用户数据访问接口及实现新增可选过滤条件不修改老方法签名中测试用例用户模块测试类补充带部门参数和不带部门的用例低文档与联调接口文档更新参数说明低这份表真正对我有用的不是前几行而是风险等级的分布。它把“数据访问层改动”标为中风险因为老方法被其他模块广泛调用直接用原来方法改签名容易出事。我看到这行立刻确认了“新增方法而非修改老方法”的设计倾向。这个判断逻辑恰恰是规划阶段最值钱的部分。3.3 多方案对比与副作用检查要不要一并在计划里做好的Plan Mode输出不止给一套方案。如果你给足上下文AI会列出两条甚至三条可行路径并逐一标注代价。比如改动来源可以是数据库查询优化、应用层过滤、或者引入新索引。每种方案对现有系统的影响不同实施成本也不同。这里我建议你在提示里主动加一句“如果存在多种实现方式请对比后给出推荐并说明理由”。例如某次我在一个报表功能里要加“只统计未删除订单”的条件AI给出两条路径一是修改现有统计SQL改动小但影响所有使用该报表的页面二是新建一个统计方法旧逻辑保持不变改动稍大但更安全。它推荐方案二理由就是影响面控制优先。这种情况下你只需要确认认可就可以比你自己对比半天再决定高效得多。副作用检查也是计划阶段必做的一环。我会刻意让AI检查这几类问题有没有定时任务或异步队列消费这些数据改动会不会破坏缓存键的生成逻辑新增参数在旧版本客户端调用时会不会报错有没有权限校验和审计日志的需要这些如果等执行完成后来补成本比计划阶段就识别出来高好几倍。3.4 计划确认之后怎么切换到执行模式才不出岔子当AI输出计划你也逐条确认过下一步就是切换到执行模式。这里有个容易翻车的操作直接说“开始执行”然后AI可能在执行过程中“自由发挥”偏离计划。我的经验是先把计划复述一遍作为执行的约束指令。例如“请严格按照上面的计划执行新增字段A、修改文件B中的C函数、不修改D模块的任何代码。如果执行中发现计划未覆盖的问题暂停并告诉我。”这一步极其重要。它是在给AI的执行阶段划边界。AI在直接执行时偶尔会顺手优化一些它觉得“不顺眼”的代码甚至重构掉一些关联逻辑这些都属于“越界动作”应该被禁止。你圈定了范围它shrink wrap起来输出的内容才高度可控。执行完不要直接收工。回到计划清单逐项核对哪些做了哪些没做有没有临时的偏差。我会让AI在执行完每一项后输出一个小结比如“已新增参数校验已补充测试未修改缓存逻辑”。全部完成后再跑一遍原有的测试用例看看有没有意外破坏。整个流程走完风险控制才算是闭环。4. 实操中的踩坑经验与排查技巧4.1 AI给出一份“看着很专业”的自嗨计划怎么办第一次用Plan Mode时最容易踩的坑是“AI输出了一份格式漂亮但内容空泛的计划”。它可能列了十个文件每个文件下面写“增加相关逻辑”但根本没说清楚具体怎么改、为什么改。这种计划看起来专业实际上没有信息量确认它等于没确认。我的排查方法是拿计划里列出的第一个文件自己打开看一眼核对AI描述的内容是不是这个文件里真实存在的。比如计划里写“在用户服务类的查询方法中增加过滤逻辑”我打开文件发现根本没有名为“查询方法”的函数那这个计划就是AI想象出来的不是探索出来的。遇到这种情况不要直接打回重做而是给AI补充反馈“这个项目的类和方法命名与你描述不符请重新读取XX目录下的文件再输出计划”。好的工具会立刻纠正并根据真实代码重新生成。还有一种自嗨计划表现为“过度设计”。比如加个筛选条件AI给出的方案是“引入新的查询框架、重构整个数据访问层、为后续扩展做好铺垫”。这种计划的风险很高因为它把一个小改动变成了大项目。我一般会要求它“基于最小改动原则输出计划不做额外重构”。4.2 探索不充分造成的“计划空转”怎么识别探索不充分的典型症状是计划覆盖的文件很少通常只包含你提到的那一两个所有改动点风险等级全是“低”没有任何一句话提到“该改动可能影响其他模块”。这说明AI大概率没有进行依赖追踪只是把你的需求映射到了一个它熟悉的模板上。之前我就遇到过让AI给某模块加一个日志字段它开开心心地给页面和接口加了字段但没有探索到数据入库前的转换逻辑导致字段值始终存不进去。后来排查发现这个模块走了一条数据转换管道所有字段都要在管道里注册才能持久化。这个管道才是真正的核心改动点偏偏不在计划里。从那以后我养成了一个习惯在探索指令中明确要求“找到从接口入口到数据落库的完整调用链并列出所有涉及的文件不要遗漏中间转换层”。4.3 边界与副作用检查清单我踩过的坑汇总副作用这种东西AI默认不会主动关心除非你明确提要求。我整理了自己的检查清单每次计划输出后照着过一遍检查项案例说明追问示例定时任务改了一个状态字段没发现定时任务也在更新它“这个字段是否被定时任务写入过”缓存机制加了新字段缓存里还是旧字段导致数据不一致“缓存是否需要升级版本号或删除旧键”消息队列/事件改动触发事件发布下游消费者可能出现未知行为“是否有事件或消息在数据变更后发出”权限体系新接口忘了加权限注解接口裸奔“新接口是否覆盖了权限校验”兼容性老版本客户端传旧参数新逻辑会不会直接报错“缺少新参数时旧调用是否能兼容”数据迁移字段类型改了存量数据会不会读取异常“存量数据需要做迁移或默认值填充吗”我甚至会在确认计划前故意追问两条“没头没脑”的边界问题“这个改动对空数据有什么影响”“并发场景下会不会有重复操作”AI有时候答不上来但这不重要重要的是它和你在同一份代码事实里做推理答不上来的时候它通常会主动再去读代码然后修正计划。这个过程比拿到一份三分钟生成的完美计划更令人放心。4.4 Plan Mode常见问题速查表最后放一个我实际使用中沉淀的速查表遇到症状可以直接对号入座症状可能原因排查方向对策计划太短只有几句话AI没深入探索代码库检查你是否限制了文件读取范围放开探索权限要求读取整个项目或关键目录计划文件清单与实际不符AI基于记忆而非代码生成打开文件核对关键函数是否存在给出具体路径要求重新读取全都是“增加逻辑”这种空话提示词缺少对输出的要求要求按“文件函数改动描述”的格式输出给一个我文中这样的表格模板方案激进改动面过大AI默认选择“最正宗”的重构方式检查是否缺少“最小改动”约束在提示词里明确“禁止重构无关逻辑”计划里没有风险提示探索不透彻追问影响范围、调用方、边界条件逐个追问直到AI能给出具体答案排查的思路大致是先判断计划是基于真实代码还是基于“通用经验”再判断其范围控制是否合理最后用副作用清单做一轮压力测试。三关通过这份计划才算合格。5. 把Plan Mode的思路延伸到日常开发里5.1 适合Plan Mode与不适合Plan Mode的场景Plan Mode不是万能的不是说任何改动都必须先规划。我自己的使用原则是改动影响面越小越不需要规划影响面越大越不能跳过规划。纯改文案、调整样式、重命名变量这类不影响逻辑的改动直接执行没问题。但凡是涉及接口签名调整、数据库结构变更、跨模块数据流改造、或者你接手一段完全陌生的老代码Plan Mode坚决不能省。还有一个容易被忽略的适合场景探索型需求。有时候你甚至没有任何改动需求只是想理解某个模块是怎么运作的。这时候直接让AI进入Plan Mode任务写成“帮我梳理某模块的主流程输出调用链路和关键类说明”它产出的其实就是一份带注释的代码地图比你人肉一行行读快得多。这种用法很多人没意识到其实价值极高。5.2 轻量级的个人计划模板不用工具也能用即使你的工具里没有Plan Mode甚至你平时根本不依赖AI编程我也建议你把这套思考方式搬进自己的开发流程。动手前花三分钟在草稿里列四个问题这个改动涉及哪些文件每个文件改什么有没有受影响的其他调用方怎么验证没有改坏就这四个足够了。我在不用AI工具时就是靠这个模板避免了很多低效返工。有次我改一个状态机逻辑列清单的时候发现有个接口文档里的状态定义和代码实现不一致如果我直接动手八成要按错误文档实现一遍然后被测试打回。列了清单我提前发现了这个矛盾先找相关负责人对齐了文档然后才动手整个过程顺畅得很。清单最大的作用不是约束人而是逼你在动手前把思路从“怎么写代码”切换到“改这里会影响谁”。5.3 团队协作里Plan Mode计划就是最好的评审底稿如果你在带团队或者经常做代码评审Plan Mode产出的计划还有一个意想不到的妙用直接当作评审前的讨论稿。让AI先把技术方案打成表格列出改动点和风险然后团队成员基于这份表争论比对着代码上下文讨论高效得多。评审过程也有了明确的检查对象不再是一句“我觉得这里不太行”的模糊反馈。我后来在团队里定了一条规矩改动涉及跨模块或数据层时先用Plan Mode跑一份技术方案贴在评审邀请里。这条看似繁琐的流程实际上把评审时间缩短了至少三分之一因为很多低级技术分歧在计划阶段就被AI的代码扫描结果给证伪了。最后再分享一点实际使用中的体会我个人用Plan Mode这段时间最大的收获不是“AI少犯错”而是我开始被迫养成了先想清楚再动手的习惯。过去我拿到需求就开敲总觉得想多了浪费时间后来发现一半时间都耗在返工上。Plan Mode这个机制最妙的地方在于它把“想清楚”这个特别抽象的要求变成了一个具体的操作入口——你不用靠自律只需要在工具里多按一下就会有一份计划在屏幕上等着你审阅。这种外部约束比内心提醒好使一百倍。如果你现在也经常被AI的擅自行动搞得头疼或者自己写代码时总觉得哪儿没考虑清楚下次无论大小改动都先进Plan Mode跑一轮。哪怕最后不执行哪怕只是让它帮你梳理一下现有代码也值回票价了。 
长河君 · 2026/10/21 3:19:38 · 阅读 1.2k AI编程工具Plan Mode实操指南：先探索规划再改代码
几个月前我接手了一个老项目的功能迭代。需求本身不算复杂就是在现有权限体系上增加一个角色维度。我打开常用的AI编程工具把需求一贴直接让它“帮我改代码”。结果不到两分钟AI就改完了编译也通过了。我还没来得及高兴一跑回归测试另外两个模块的鉴权逻辑全乱了——AI为了“复用权限判断”顺手改了核心过滤器顺带影响了所有走过滤器的接口。那次返工花了我整整一下午比我自己动手写还慢。从那之后我养成了一个习惯不管需求大小先进 Plan Mode把探索和规划放在执行前面。这里的 Plan Mode 不是什么高深的理论它就是很多AI编程工具里自带的一个工作模式——在执行任何实际修改之前让AI先读代码、理逻辑、列计划等你确认了再动手。这个模式解决的核心问题特别朴素AI直接动手改代码往往改错方向、改漏范围甚至把原本能跑的逻辑改得面目全非。这篇文章我就把 Plan Mode 从概念到实操完整拆一遍包括它解决了什么痛点、底层工作流程、完整操作步骤、以及我在真实项目里踩过的坑。不论你用的是哪款编码助手只要你的工具里带这个模式或者你愿意手动模拟这套流程今天的分享都能直接抄作业。1. Plan Mode是什么先弄清楚它到底解决什么问题1.1 没有Plan Mode时AI直接执行有多冒险很多人用AI编程助手的方式是“描述需求让它直接改”。这种用法方便是方便但风险完全不可控。我给AI下指令“在用户列表接口加一个按部门筛选的参数”它收到指令后的典型反应是直接打开Controller、Service、数据访问层按自己的理解开始改。改完告诉你“已完成”你也不确定它到底动了哪些地方。问题在于AI在直接执行模式下默认把“完成你提出的可见需求”作为唯一目标它不会主动去评估这个改动会不会影响其他调用方。比如上面的筛选需求正常做法是在原有查询方法上加一个可空参数大部分情况下兼容但AI可能为了让“筛选”更彻底改写了查询构建器导致所有调用这个查询构建器的地方行为都变了。这种问题编译期往往发现不了只有跑到特定业务路径上才会暴露等测试报出来的时候你已经很难定位是它改的那部分出了问题。再一个风险是“自我猜测”。直接执行模式下AI遇到模棱两可的需求不会停下来问你而是会挑一个它认为最合理的解释去实现。比如你说“优化一下这个接口的性能”它可能直接给数据库表加上索引或者把同步逻辑改成异步每一种解释都能自圆其说但很可能跟你想要的方向完全相反。改完之后你又得花时间解释为什么不对还不如一开始就让它先拿出方案。1.2 Plan Mode的核心工作流程探索、规划、确认、执行Plan Mode的工作流程说白了就是四个阶段探索、规划、确认、执行。探索阶段AI会主动读取项目结构、关键文件、相关模块的代码搞清楚它将要改动的那部分到底是怎么运作的规划阶段它把需求映射到具体的文件、函数、数据表上列出需要新增、修改、删除的地方以及每个改动点的影响范围确认阶段它把这份计划拿给你看等你同意或提出修改意见确认之后才切换到执行模式真正开始动代码。这四步里前两步是在Plan Mode内部完成的第三步是模式切换的关卡第四步是执行模式的事。很多人误以为Plan Mode只是让AI多问一句“你确定要这么做吗”其实完全不是。它的核心价值在于让AI在动手之前先对代码库形成完整认知再基于这个认知给出一个可评审的改动方案。你有没有发现这跟我们人写代码的思考过程是一样的——先读代码搞清楚现状再想方案然后才动手而不是拿到需求就敲键盘。1.3 一个容易被误解的点Plan Mode不是聊天记录里的“问一遍”我见过有人这样用Plan Mode把需求发给AIAI问“您确认要修改xxx文件吗”用户回“确认”然后AI就开始改了。这压根不是Plan Mode这只是对话里的一个普通确认。真正的Plan Mode应该是AI先花时间把相关代码读一遍输出类似“我发现了这些关联逻辑其中某模块调用了该方法如果直接改会影响到另外三个接口”这样的探索结论然后再输出一份结构化的改动清单比如“新增文件A、修改文件B中的C函数、更新测试用例D、需要关注缓存失效风险”最后才是你点击确认。判断你的工具是否真正支持Plan Mode就看两点第一它有没有主动扫描并理解代码库而不是只盯着你贴出来的那几行代码第二它给出的计划是“具体文件具体改动点风险说明”还是一句“我将修改相关代码以完成您的需求”。如果是后者那你只是拿Plan Mode的名字当了个确认按钮真正的探索和规划能力压根没打开。2. 为什么“先探索再规划”能显著降低执行风险2.1 代码探索是改代码的地基省了必踩坑做开发的人都知道改代码最怕的就是“没读透就动手”。AI也一样它比人更依赖对现有代码的完整理解因为它是基于概率生成代码的给它看越多的相关上下文它生成的内容越接近真实需求。Plan Mode里的探索阶段本质上就是强迫AI“多读一些文件再开口说话”。举个例子我当时给某业务模块加一个字段需求是“在订单列表新增一个支付渠道字段”。如果让AI直接干它很可能在订单实体、列表查询和详情页各加一个字段万事大吉。但在Plan Mode下它去读了订单模块的代码发现订单实体本身是从另一个微服务同步过来的本地加字段根本不会自动持久化真正的改动点在于消息消费时的映射逻辑以及同步任务里的字段转换。这两者相差十万八千里一个只是页面展示一个涉及数据落库。探索阶段AI具体会做什么它会比较有经验地读这几类东西入口文件路由、控制器、核心数据模型、数据库迁移脚本或建表语句、服务层或业务逻辑层的关键函数、配置文件。有些做得更细的AI还会去追踪依赖关系比如某个函数被谁调用了、某个表被哪些模块引用了。这一套下来它生成的计划才不是“想当然”而是建立在实际代码基础上的判断。2.2 规划阶段的本质把返工成本压到最低写代码这件事最贵的从来不是“敲键盘”而是“改方案”。一行代码写错改起来几秒钟但整个技术方向搞错了返工可能是一天甚至几天。规划阶段的作用就是在你投入任何实际编码之前先把技术方向和改动范围对齐把返工成本压在最低。我用装修来类比你要给家里加一个插座电工师傅到了现场先看电路走向、判断墙体结构然后给你说“我打算从这条线路引线在这里开口需要拆一小段踢脚线”你确认了他才动手。他绝对不会什么也不看直接在承重墙上开槽。Plan Mode之于代码就是电工师傅手里的图纸和现场勘察报告。有了这份计划你可以在“砸墙”之前提出“我不想拆踢脚线换个走线方案”代价几乎为零等墙砸完了再想改方案恢复原状的成本就大了。实际使用中我也确实遇到过计划阶段就发现问题的场景。有个需求是调整某报表的统计口径AI原本打算直接改查询SQL但在规划时进行了影响面检查发现这个SQL的结果被下游三个接口消费直接改口径会导致下游数据变化。于是计划变成了“新建一个查询方法保留原方法只让报表接口切换到新方法”。这个过程里一行业务代码没写就已经规避了一个线上风险。2.3 人机协作的分界线AI负责发散检索人负责收敛判断Plan Mode还有一个很微妙的价值它把人机协作的分界线划清楚了。AI的优势是全面检索快看代码快可以一口气列出几十个潜在关联文件人的优势是理解业务意图能做价值判断。Plan Mode正好让两者各司其职AI输出尽可能完整的候选方案和影响面清单你来做最终决策拍板“这个方向对那个不能动”。我强烈建议你在这个过程中把AI当成一个可以无限发散的下属而不是一个完美的专家。它列出的改动点你全部要过一遍它标注的“低风险”项你反而要多看一眼因为AI对风险等级的判断偶尔是乐观的。我习惯在它输出计划之后追问几个问题“这个改动会不会影响定时任务有没有可能破坏幂等新增字段的兼容性处理做了没有”这些问题AI通常能在规划阶段直接回答能答上来的执行时就踏实多了。3. Plan Mode的完整实操流程一步一步拆开3.1 需求怎么写Plan Mode才能产出高质量计划很多人忽略了一个关键环节给Plan Mode的任务描述质量直接决定计划质量。如果只写“帮我加个XX功能”AI就只能猜但如果你给的是“在订单列表中新增支付渠道筛选条件该字段来源于支付回调需要支持多选如果未传该参数则保持原有逻辑”AI的探索方向立刻变得清晰它知道去读哪几个文件也知道验收标准是什么。我总结了一个需求描述模板照着写基本不会跑偏功能背景一句话、具体的输入输出、边界条件、验收标准。举个例子我某个虚拟项目中需要给用户管理模块增加账号冻结功能我是这样描述的“现有用户管理模块位于某后台系统需要给非管理员用户增加冻结/解冻操作。冻结后用户无法登录已登录的Token在5分钟内失效。解冻后恢复正常。冻结操作需要记录操作人与时间。请先探索现有用户登录和Token校验逻辑输出改动计划。”这段话没有任何多余信息但每一句都在缩小AI的探索范围。如果项目里有明显的代码规范或者约定的架构模式最好也写进去比如“本项目数据库操作统一走DAO层不允许在Service里直接写SQL”之类。这会直接影响AI在计划里给出的技术方案是否贴合团队规范。我自己吃过亏没写结果AI按自己习惯写了全新的访问逻辑计划看着挺合理实际上跟项目里其他代码风格完全不一致。3.2 从需求到改动点AI是怎么拆解的AI在Plan Mode里接到需求后拆解改动点的方式其实跟资深程序员很接近。它会先定位入口然后沿调用链往下追接口控制器入参处理、业务逻辑处理、数据持久化层、再反向看返回值如何组装。拆解结果通常以文件维度呈现你可以要求它用表格输出这样一目了然。就拿“添加按部门筛选用户”这个需求举例我让AI输出拆解计划它给的是这样一份表改动点涉及文件具体操作风险等级接口入参用户查询控制层文件新增部门ID参数可空空值不影响原逻辑低业务过滤逻辑用户服务层文件在查询条件构建处追加部门条件中数据访问层用户数据访问接口及实现新增可选过滤条件不修改老方法签名中测试用例用户模块测试类补充带部门参数和不带部门的用例低文档与联调接口文档更新参数说明低这份表真正对我有用的不是前几行而是风险等级的分布。它把“数据访问层改动”标为中风险因为老方法被其他模块广泛调用直接用原来方法改签名容易出事。我看到这行立刻确认了“新增方法而非修改老方法”的设计倾向。这个判断逻辑恰恰是规划阶段最值钱的部分。3.3 多方案对比与副作用检查要不要一并在计划里做好的Plan Mode输出不止给一套方案。如果你给足上下文AI会列出两条甚至三条可行路径并逐一标注代价。比如改动来源可以是数据库查询优化、应用层过滤、或者引入新索引。每种方案对现有系统的影响不同实施成本也不同。这里我建议你在提示里主动加一句“如果存在多种实现方式请对比后给出推荐并说明理由”。例如某次我在一个报表功能里要加“只统计未删除订单”的条件AI给出两条路径一是修改现有统计SQL改动小但影响所有使用该报表的页面二是新建一个统计方法旧逻辑保持不变改动稍大但更安全。它推荐方案二理由就是影响面控制优先。这种情况下你只需要确认认可就可以比你自己对比半天再决定高效得多。副作用检查也是计划阶段必做的一环。我会刻意让AI检查这几类问题有没有定时任务或异步队列消费这些数据改动会不会破坏缓存键的生成逻辑新增参数在旧版本客户端调用时会不会报错有没有权限校验和审计日志的需要这些如果等执行完成后来补成本比计划阶段就识别出来高好几倍。3.4 计划确认之后怎么切换到执行模式才不出岔子当AI输出计划你也逐条确认过下一步就是切换到执行模式。这里有个容易翻车的操作直接说“开始执行”然后AI可能在执行过程中“自由发挥”偏离计划。我的经验是先把计划复述一遍作为执行的约束指令。例如“请严格按照上面的计划执行新增字段A、修改文件B中的C函数、不修改D模块的任何代码。如果执行中发现计划未覆盖的问题暂停并告诉我。”这一步极其重要。它是在给AI的执行阶段划边界。AI在直接执行时偶尔会顺手优化一些它觉得“不顺眼”的代码甚至重构掉一些关联逻辑这些都属于“越界动作”应该被禁止。你圈定了范围它shrink wrap起来输出的内容才高度可控。执行完不要直接收工。回到计划清单逐项核对哪些做了哪些没做有没有临时的偏差。我会让AI在执行完每一项后输出一个小结比如“已新增参数校验已补充测试未修改缓存逻辑”。全部完成后再跑一遍原有的测试用例看看有没有意外破坏。整个流程走完风险控制才算是闭环。4. 实操中的踩坑经验与排查技巧4.1 AI给出一份“看着很专业”的自嗨计划怎么办第一次用Plan Mode时最容易踩的坑是“AI输出了一份格式漂亮但内容空泛的计划”。它可能列了十个文件每个文件下面写“增加相关逻辑”但根本没说清楚具体怎么改、为什么改。这种计划看起来专业实际上没有信息量确认它等于没确认。我的排查方法是拿计划里列出的第一个文件自己打开看一眼核对AI描述的内容是不是这个文件里真实存在的。比如计划里写“在用户服务类的查询方法中增加过滤逻辑”我打开文件发现根本没有名为“查询方法”的函数那这个计划就是AI想象出来的不是探索出来的。遇到这种情况不要直接打回重做而是给AI补充反馈“这个项目的类和方法命名与你描述不符请重新读取XX目录下的文件再输出计划”。好的工具会立刻纠正并根据真实代码重新生成。还有一种自嗨计划表现为“过度设计”。比如加个筛选条件AI给出的方案是“引入新的查询框架、重构整个数据访问层、为后续扩展做好铺垫”。这种计划的风险很高因为它把一个小改动变成了大项目。我一般会要求它“基于最小改动原则输出计划不做额外重构”。4.2 探索不充分造成的“计划空转”怎么识别探索不充分的典型症状是计划覆盖的文件很少通常只包含你提到的那一两个所有改动点风险等级全是“低”没有任何一句话提到“该改动可能影响其他模块”。这说明AI大概率没有进行依赖追踪只是把你的需求映射到了一个它熟悉的模板上。之前我就遇到过让AI给某模块加一个日志字段它开开心心地给页面和接口加了字段但没有探索到数据入库前的转换逻辑导致字段值始终存不进去。后来排查发现这个模块走了一条数据转换管道所有字段都要在管道里注册才能持久化。这个管道才是真正的核心改动点偏偏不在计划里。从那以后我养成了一个习惯在探索指令中明确要求“找到从接口入口到数据落库的完整调用链并列出所有涉及的文件不要遗漏中间转换层”。4.3 边界与副作用检查清单我踩过的坑汇总副作用这种东西AI默认不会主动关心除非你明确提要求。我整理了自己的检查清单每次计划输出后照着过一遍检查项案例说明追问示例定时任务改了一个状态字段没发现定时任务也在更新它“这个字段是否被定时任务写入过”缓存机制加了新字段缓存里还是旧字段导致数据不一致“缓存是否需要升级版本号或删除旧键”消息队列/事件改动触发事件发布下游消费者可能出现未知行为“是否有事件或消息在数据变更后发出”权限体系新接口忘了加权限注解接口裸奔“新接口是否覆盖了权限校验”兼容性老版本客户端传旧参数新逻辑会不会直接报错“缺少新参数时旧调用是否能兼容”数据迁移字段类型改了存量数据会不会读取异常“存量数据需要做迁移或默认值填充吗”我甚至会在确认计划前故意追问两条“没头没脑”的边界问题“这个改动对空数据有什么影响”“并发场景下会不会有重复操作”AI有时候答不上来但这不重要重要的是它和你在同一份代码事实里做推理答不上来的时候它通常会主动再去读代码然后修正计划。这个过程比拿到一份三分钟生成的完美计划更令人放心。4.4 Plan Mode常见问题速查表最后放一个我实际使用中沉淀的速查表遇到症状可以直接对号入座症状可能原因排查方向对策计划太短只有几句话AI没深入探索代码库检查你是否限制了文件读取范围放开探索权限要求读取整个项目或关键目录计划文件清单与实际不符AI基于记忆而非代码生成打开文件核对关键函数是否存在给出具体路径要求重新读取全都是“增加逻辑”这种空话提示词缺少对输出的要求要求按“文件函数改动描述”的格式输出给一个我文中这样的表格模板方案激进改动面过大AI默认选择“最正宗”的重构方式检查是否缺少“最小改动”约束在提示词里明确“禁止重构无关逻辑”计划里没有风险提示探索不透彻追问影响范围、调用方、边界条件逐个追问直到AI能给出具体答案排查的思路大致是先判断计划是基于真实代码还是基于“通用经验”再判断其范围控制是否合理最后用副作用清单做一轮压力测试。三关通过这份计划才算合格。5. 把Plan Mode的思路延伸到日常开发里5.1 适合Plan Mode与不适合Plan Mode的场景Plan Mode不是万能的不是说任何改动都必须先规划。我自己的使用原则是改动影响面越小越不需要规划影响面越大越不能跳过规划。纯改文案、调整样式、重命名变量这类不影响逻辑的改动直接执行没问题。但凡是涉及接口签名调整、数据库结构变更、跨模块数据流改造、或者你接手一段完全陌生的老代码Plan Mode坚决不能省。还有一个容易被忽略的适合场景探索型需求。有时候你甚至没有任何改动需求只是想理解某个模块是怎么运作的。这时候直接让AI进入Plan Mode任务写成“帮我梳理某模块的主流程输出调用链路和关键类说明”它产出的其实就是一份带注释的代码地图比你人肉一行行读快得多。这种用法很多人没意识到其实价值极高。5.2 轻量级的个人计划模板不用工具也能用即使你的工具里没有Plan Mode甚至你平时根本不依赖AI编程我也建议你把这套思考方式搬进自己的开发流程。动手前花三分钟在草稿里列四个问题这个改动涉及哪些文件每个文件改什么有没有受影响的其他调用方怎么验证没有改坏就这四个足够了。我在不用AI工具时就是靠这个模板避免了很多低效返工。有次我改一个状态机逻辑列清单的时候发现有个接口文档里的状态定义和代码实现不一致如果我直接动手八成要按错误文档实现一遍然后被测试打回。列了清单我提前发现了这个矛盾先找相关负责人对齐了文档然后才动手整个过程顺畅得很。清单最大的作用不是约束人而是逼你在动手前把思路从“怎么写代码”切换到“改这里会影响谁”。5.3 团队协作里Plan Mode计划就是最好的评审底稿如果你在带团队或者经常做代码评审Plan Mode产出的计划还有一个意想不到的妙用直接当作评审前的讨论稿。让AI先把技术方案打成表格列出改动点和风险然后团队成员基于这份表争论比对着代码上下文讨论高效得多。评审过程也有了明确的检查对象不再是一句“我觉得这里不太行”的模糊反馈。我后来在团队里定了一条规矩改动涉及跨模块或数据层时先用Plan Mode跑一份技术方案贴在评审邀请里。这条看似繁琐的流程实际上把评审时间缩短了至少三分之一因为很多低级技术分歧在计划阶段就被AI的代码扫描结果给证伪了。最后再分享一点实际使用中的体会我个人用Plan Mode这段时间最大的收获不是“AI少犯错”而是我开始被迫养成了先想清楚再动手的习惯。过去我拿到需求就开敲总觉得想多了浪费时间后来发现一半时间都耗在返工上。Plan Mode这个机制最妙的地方在于它把“想清楚”这个特别抽象的要求变成了一个具体的操作入口——你不用靠自律只需要在工具里多按一下就会有一份计划在屏幕上等着你审阅。这种外部约束比内心提醒好使一百倍。如果你现在也经常被AI的擅自行动搞得头疼或者自己写代码时总觉得哪儿没考虑清楚下次无论大小改动都先进Plan Mode跑一轮。哪怕最后不执行哪怕只是让它帮你梳理一下现有代码也值回票价了。