和AI编码工具磨合了2000个小时我最近终于把工作流从“一个大模型从需求一路写到代码”改成了“两个模型分段合作”战略型模型只负责规划执行型模型只负责编码。这套做法的核心听起来很朴素就是把AI也当成团队里两种性格完全不同的同事来用。可我会在这篇里把为什么要这么做、边界怎么画、任务怎么交接、踩过哪些坑全部摊开来讲。标题里的“模型分化”不是玄学而是我在大量真实项目中反复验证过的一条路径。适合正在用AI写业务代码、或者搭Agent工作流的人参考。尤其是当你发现“一个模型全包”经常卡在方向明确了、细节却疯狂翻车、或者代码补全很强但让你把架构定得一塌糊涂的时候这套玩法大概率能救你。1. 模型分化的出发点为什么要拆成两段走1.1 一个模型干完所有事为什么会卡壳最早的时候我也是“单模型流”把项目背景、需求、相关代码路径全部丢给一个AI让它从接口设计一路写到函数体。小项目还能凑合一旦项目超过三五个模块问题就开始冒头。最典型的现象是“两头好中间垮”。你让模型先规划整个模块的结构它能输出一份看起来很漂亮的方案类名、方法名、数据流向都头头是道。可等你让它顺着这套方案去写实现代码它就容易在原方案上“自由发挥”把当初定的函数签名改了或者自己加了一个根本不存在的数据表字段。反过来你让一个擅长补全代码的模型去负责全局架构它又会给出那种“局部很精致、整体很散装”的设计——每个文件都写得有模有样凑在一起互相不认接口。出现这种情况本质上是因为规划和执行是两套完全不同的上下文需求。规划需要的是全局面项目边界、依赖关系、业务约束、验收标准。而执行需要的是局部面某一个文件的现有代码、某个函数的入参出参、某条报错信息。这两类信息量级不同、抽象度不同、冗余度也不同。你硬塞给同一个模型只会让它的注意力在“看全局”和“写局部”之间来回跳。另一个我在实际中特别有体会的原因是经济账。战略型思考通常要调用推理能力更强、上下文窗口占用更狠的模型价格更贵、延迟更高。你让它去写一百行样板代码纯属拿大炮打蚊子。执行型模型往往速度快、单价低、代码补全手感顺滑你让它去反复权衡“这个功能该放哪个层”它也干不来。把两者拆开以后我不光代码质量更稳月度账单也明显降了一截。1.2 规划与执行为什么是两种活很多人觉得规划不就是“先想一想”执行不就是“动笔写”既然都是同一个大模型在跑拆不拆有什么本质区别我磨合多了以后发现区别比想象中大得多。规划活的核心矛盾是“不确定性”。你面对的往往是一个残缺的需求描述中间缺了一大段业务逻辑。战略型模型的强项在于它能在缺失信息中补出一个合理的推断并且把这个推断显式地表达成风险点而不是默默替你做了决定。它能画出“A方案和B方案分别的代价”能告诉你“这里如果再不改迟早要重构”。规划需要的不是一次到位的精准而是试错空间里的方向感。执行活的核心矛盾是“精确性”。代码能不能编译、边界条件对不对、变量名和现有代码风格是否一致、有没有引入多余副作用这些全是0和1的问题。执行型模型不需要多会天马行空它需要按照既定的签名、既定的风格、既定的测试条件把每一行写到位。这种任务对错误容忍度极低但好在目标非常清晰。把两种活拆开还有一个隐藏收益上下文长度不再打架。规划模型要看的东西基本是需求文档、接口约定、架构草图。执行模型要看的东西基本是具体文件、类型定义、报错栈。你不用再费劲把十几万字的全局资料和历史代码全部塞进同一段对话里。这一点直接决定了你能不能长期稳定地跑复杂项目。2. 实操前的准备模型选型、分工边界与本地部署2.1 战略型模型和执行型模型怎么选说“战略型”和“执行型”只是角色定位落到具体工具上怎么选我总结了四个维度推理深度、上下文长度、代码手感、成本延迟。战略型模型优先看推理深度和上下文长度。你需要它在长对话里记住前面的决策同时遇到多个可选方案时不急着出结果而是先分析利弊。我自己日常会选强化过思维链能力的大模型不一定是参数最大的那个但一定要在中文需求理解和抽象分层上表现稳定。有些模型代码能力一般可你让它写“技术方案评审”它反而比代码天才型模型好使因为它会拆解风险。执行型模型优先看代码手感和响应速度。代码补全的准确性、对主流语言语法约束的掌握、对本地项目风格的适配能力这些比“它会不会设计系统”重要得多。实操中很多任务是高频增量修改你今天写一个接口实现明天改一个Bug后天补一个工具函数。执行模型等着出活等不起太多思考时间。我把选型维度整理成表格方便你照着画瓢选型维度战略型模型执行型模型核心能力推理、分层、风险评估语法准确、局部修改、风格统一关注上下文需求文档、架构、决策记录具体代码文件、报错栈、接口签名输出产物任务包、验收标准、风险清单可编译代码、单元测试、补丁对延迟的要求可以慢但要有深度越快越好最好秒回成本敏感点按输出质量计贵一点能接受按调用量计便宜耐用是关键2.2 任务分工的边界怎么定选好模型之后最让你头疼的其实是“边界”。我早期踩过的坑就是角色分得太含糊规划模型偶尔想表现一下编码能力执行模型也开始擅自改接口设计最后两边一起制造混乱。我的经验是先把产出物彻底区分。战略型模型只允许输出这几样东西技术目标、模块边界、接口签名草案、数据流描述、风险点清单、验收条件。它不许直接写实现代码就算它想写你也不要收。尤其接口签名草案这种东西它一旦开始思考“这个函数里面怎么实现”就会把实现细节混进接口设计导致执行模型的发挥空间被锁死。执行型模型的权限范围严格限定在实现一个已有签名的函数、修一个被明确定义的Bug、补一个测试用例、重构一小段内部代码。它不许跨文件改动结构不许新增公共接口不许私自改动数据存储方案。出格一步就立刻终止对话重开因为一旦让它跑偏后续的验收成本大得离谱。边界问题的本质是“决策权”归属。谁决定要不要加参数谁决定错误处理策略谁决定性能瓶颈的解决方向这些在任务包里就要写清楚。执行模型只有执行权没有否决权。哪怕它发现自己所处的局部代码绕不过去正确做法是停下来报“阻塞点”而不是自己改需求。2.3 服务地址、本地模型和自定义配置细节模型分化的前提是你能同时驱动两个不同类型的模型。有人用的是同一家云端服务的两个版本有人则把一个模型部署在本地、另一个走云端API。我建议至少在配置层面把服务地址独立开别把两个模型绑在同一个调用链里否则后面出故障时你连降级都难。这里给一个最小拆分方案。战略模型走云端大模型接口环境变量里单独配一层key和地址执行模型优先考虑本地部署或者选走独立的服务端。尤其你如果用类似vLLM、Ollama、TensorRT-LLM的推理服务来托管模型每个服务实例的地址是独立可以绑定的。我在实测里是让执行模型跑本地小模型战略模型挂云端强推理模型两边互不抢资源。配置细节上提醒三件事。其一启动本地模型时显式指定上下文长度别用默认值我习惯设成能覆盖“一个文件全量加两个相关文件”的长度即可。其二自定义模型服务地址要单独写一份配置文件不要和业务代码的配置混在一个对象里否则你每次调参都会牵连到无关模块。其三超时时间分开设置。战略模型允许30秒以上等待推理执行模型超时设短一点比如10秒超了就重试一次再超就降级到更小参数量的替代模型。有个热搜索词叫“gpustack部署模型windows”我顺手提一句。如果你要在Windows上用GPU Stack这类方案托管本地模型注意显存分配别吃满留出20%给浏览器、IDE和编译进程。我见过太多次本地推理服务把整机卡到鼠标都动不了因为显存占用率拉到了95%实际稳定跑模型应该控制在70%到80%。3. 工作流搭建从需求分解到编码落地的完整链路3.1 第一步让战略型模型输出“任务包”整个工作流的关键产物是“任务包”。它相当于一份技术任务书执行模型拿不到原始需求只看任务包。这样设计有两个好处一是需求不会在传递中变形二是执行模型的上下文可以保持干净。任务包里必须包含六块内容目标描述、边界约束、接口签名草案、依赖关系、验收条件、风险提示。我会给战略型模型固定的提示词结构你直接用也没问题请基于以下需求产出可执行任务包。 需求背景{粘贴需求} 项目现状{简述涉及模块、已有接口、数据表结构} 输出要求 1. 用200字以内解释这次要解决的核心目标。 2. 列出不允许改动的模块和现有接口。 3. 给出新增或修改的函数签名包括参数名、返回类型以及是否允许额外抛错。 4. 说明本次改动依赖哪些已有代码文件。 5. 写清楚验收条件要求可验证。 6. 标出你认为最可能踩坑的两个风险点。 禁止输出任何函数实现代码。这套模板我反复调过。加“禁止输出实现代码”这个约束一开始显得多此一举后来发现没有它战略模型就会忍不住输出半截代码而执行模型拿到半截代码之后往往直接照抄完全跳过理解。写清楚“验收条件可验证”也很重要。比如“返回结果正确”就不合格要写成“输入[1,2,3]和窗口3时输出序列每个元素都等于对应窗口均值”。3.2 第二步把任务包交给执行型模型去写代码拿到任务包之后我会把相关的代码文件路径、类型定义、少量日志或报错信息一起整理好再交给执行型模型。执行会话的提示词我也固定了结构你只负责完成下面的任务包不要改动任务包之外的代码。 任务包{粘贴战略模型任务包} 相关文件 {paste相关代码片段而不是整个仓库} 约束 - 只实现任务包中要求的新增或修改函数 - 保持现有代码风格使用项目中已有的工具函数 - 不要新增公共接口不要改动数据库结构 - 如果发现任务包和现实代码冲突立刻停下来输出“阻塞点”不要自行判断执行阶段我强烈建议坚持“一次只改一个文件或一个紧密相关的文件组”。别贪多。让执行模型同时改六个文件的后果是要么上下文被撑爆要么改到第三个文件时忘了第一个文件的约束。反过来一次一个文件虽然多跑几轮但每轮都能保持高质量发现问题也能精准回退。在执行模型输出代码后不要急着把它并入主分支。我会要求它顺带补一个最小验证方案通常是一段可以本地跑的测试命令或测试用例。就算你的项目测试覆盖率很低这一步也别省。执行模型自己写的最小验证能逼它自检一次能挡掉大概一半的接口参数名错误。3.3 第三步回传战略型模型做验收而不是自己看代码代码写完后的验收环节是我这套工作流里最容易被忽视的。很多人的习惯是执行模型写完代码人肉读一遍觉得没问题就过了。但战略型模型规划时心里有一套完整的目标体系它能更快发现“这段代码虽然漂亮但和验收条件中某个隐藏约束冲突了”的情况。我的做法是把执行模型的输出、测试结果、以及原始任务包一起回传给战略型模型让它做三件事逐条核对验收条件、指出代码和任务包之间不一致的地方、如果验收不过则输出问题清单而不是直接给修改后代码。这里的关键是“问题清单”而不是“改写的代码”。一旦战略模型开始输出修复代码角色就又混了它会陷入局部实现细节失去全局审查能力。当验收通过后我会让战略模型顺带生成一段提交说明内容包括这次改动解决的核心问题、涉及的文件列表、尚未覆盖的风险。这段说明既方便后面发合并请求也能在下次维护时帮新接手的人快速进入状态。3.4 完整示例实现一个“滑动窗口滤波”任务我用一个非常具体的小任务串一遍流程便于你直观感受。假设项目里已有一个工具文件现在需要新增一个滑动窗口滤波函数需求描述是“对输入数组做窗口均值滤波窗口大小为参数边界部分允许输出nan”。战略型模型输出的任务包核心目标实现滑动窗口均值滤波输入Float数组和窗口大小输出等长Float数组窗口越界位置填nan。 边界约束不允许改动调用方现有逻辑工具文件里不得引入第三方依赖。 接口签名草案def sliding_window_mean(data: list[float], window: int) - list[float] 依赖关系仅依赖当前文件无跨模块调用。 验收条件 1. 输入[1, 2, 3, 4]窗口为3时输出[NaN, 2.0, 3.0, NaN] 2. window 0时抛ValueError 3. 不修改原数组返回新列表 风险提示注意float精度建议用Python内置sum而不是累计误差实现。执行模型拿到的上下文只有工具文件的已有代码和这个任务包。它最终写出的函数假设有NaN模块差异、边界判断、空数组处理。如果它输出窗口为0时没有抛异常那么战略模型在验收时就会发现并在一轮问题清单里指出任务包要求ValueError当前代码是窗口为0时返回空列表。这种情况下我会让执行模型基于问题清单重新交付通常一次就能改对。这个小例子看起来很简单但它是整个工作流的微缩版本。哪怕你的项目是几十个模块的大型系统运行逻辑完全一样需求压缩成任务包任务包分发给执行层执行层交付代码验收层基于任务包做核对。这套闭环越跑越顺磨合成本也主要花在这里。4. 2000小时磨合之后常见问题与排查技巧实录4.1 两个模型“互相打架”怎么办最常见的问题是执行模型说“任务包里的接口和实际代码对不上”战略模型坚持说“按现有代码逻辑必须改接口”然后两边开始来回踢皮球。这是角色混线的典型症状。解决办法是我前面提到过的“阻塞点”机制。执行模型发现冲突后必须原样输出冲突细节包括任务包里的原文、当前代码里的原文、以及它认为存在矛盾的具体位置然后停下来。接下来由人工或者顶层流程决定是回退任务包还是顺带调整代码而不是让两个模型自行化解矛盾。这个规则刚开始会频繁触发但坚持几个星期之后战略模型给出的任务包质量明显变高因为所谓的“对不上”有很大一部分是规划时没把已有代码的约束写清楚。另外要记住两个模型的对话历史不要共享。战略模型的对话里长期保留的是需求演进和决策记录执行模型的对话里保留的是具体代码文件一旦共享前后的上下文会互相污染。角色打架的根源往往不是模型笨而是你让它们在一个context里和稀泥。4.2 模型繁忙、超时与重试策略真实使用中“模型繁忙”这四个字出现的频率比想象中高。公共API高峰期经常排队本地模型偶尔也出现过载。我早期遇到这种情况会陪着笑脸重新点击运行结果有时候连着折腾十几分钟。后来我干脆做了一个轻量级的模型调度层把重试逻辑固定下来。具体参数建议是这样的调用超时时间设为15秒战略模型可以放宽到45秒连续失败超过2次自动切到备用模型。备选不必是同类最强找一个能力稍弱但稳定的模型顶上先保住流程不中断。等主模型的繁忙期过了再把手头这个任务重新投喂给它。这里有个很容易忽略的细节备用模型顶上以后它收到的任务包必须和主模型收到的完全一致千万不能让它从头看需求原文。因为备用模型的处理风格可能不一样一旦它自己重新理解需求输出的任务包或者代码就会走样。单独给备用模型套一层“只按任务包执行不许重新规划”的约束能帮你省下无数对比成本。4.3 上下文爆掉和信息丢失执行模型一次塞太多东西进去最常见的表现不是报错而是“失忆”。前面文件里已经明确写的函数名到后面它就自己重新拼了一个新的。排查这类问题我养成了一个习惯检查输出中和任务包有关但多出来的函数名。只要发现执行模型输出里凭空出现了任务包外的公开函数基本可以断定它的上下文已经撑不住或者已经跑偏。应对方案不是无限扩大上下文窗口而是切割。执行模型每次只带两类信息当下要改的文件内容、与改动直接相关的少量接口定义。其余信息通过向量检索或grep临时获取用完了就丢。我在自己的工作流里接了一个本地向量模型来做代码检索不是让它生成内容而是定期把项目的关键模块索引一遍需要哪个文件就检索出来局部注入这样执行模型永远不需要背整个项目。如果你不用向量检索也有更土但有效的办法代码仓库里用一个“上下文清单文件”手动维护每个模块的入口、职责、对外接口和注意事项。执行模型动手前只给清单对应的那几行既能控住上下文又能帮助不同模型快速对齐项目约定。4.4 常见问题速查表问题现象可能原因解决步骤执行模型擅自改了函数签名任务包里接口约束写得不够硬强调“禁止修改签名”出现即回退战略模型输出一半代码一半方案没有显式禁止输出实现提示词里明确“禁止写代码”代码能跑但结果和预期不符验收条件没量化用具体输入输出示例替代模糊描述模型频繁报“模型繁忙”公共API过载或本地推理队列堆积设重试和备用模型别死等上下文超过限制或失忆塞了太多无关代码每轮只喂一个文件的局部信息执行模型和规划模型结论互相矛盾两者对话历史被共享两个模型的会话隔离用任务包交接这张表是我实际排查时反复用到的模板。你会发现大部分问题最后都指向同一个根因角色的产物边界没守住。一旦你自己心里清楚“战略模型出方案执行模型出代码验收模型出结论”很多故障都能快速定位到是哪一环越权了。4.5 容易被忽略的三条细节经验先说说角色命名。我在同一个系统里跑多个模型会话时会给每个会话起固定的名字比如“规划师”“编码员”“审查员”。这不是仪式感而是为了在排查日志时能快速区分每个会话到底做了什么事。不然等模型轮换、会话重开你根本看不出某段输出是谁产出的。再说说版本管理。执行模型每次交付的代码我都要求打成一个单独的提交提交信息必须引用任务包编号。这样一旦某个功能出了回归我能直接找到“当时战略模型规划的任务包长什么样”而不是对着一个巨大的合并提交发呆。这套习惯大概坚持了一个月就把一个困扰很久的“代码越改越乱”问题给治了。最后说说怎么应对模型“一本正经地乱写”。执行模型如果发现自己缺信息它的本能是补一个看起来合理的默认值。这在普通对话里是优点在编码执行里就是灾难。我会在任务包和提示词里反复声明遇到不确定信息必须输出“不确定项”而不是自行假设。宁可让流程停下来也不要让错误假设混进代码。结尾这套“战略规划执行编码”的模型分化工作流是我2000小时磨合下来最满意的一次结构调整。它不解决所有问题但解决了我最头疼的“方向对吗”和“代码对吗”两个问题被混在一起纠缠的困境。如果你也正处在“单模型一把梭”的阶段我建议花两周时间试一试任务包模式不需要什么复杂框架一个角色分工表、一套提示词、一个严格的交接清单就够了。我个人在实际操作中最深的一个体会是AI模型真正的上限往往不取决于单个模型聪明不聪明而取决于你是否敢于给它们明确的分工并且狠得下心不让它们越界。规划和编码分开以后我在每个环节的验收压力小了很多也终于不用再指望同一个脑袋既当设计师又当流水线工人了。这套流程还能怎么升级我目前的下一步是给任务包加“工作量预估”让战略模型在规划阶段顺带估算每个任务的执行轮次和成本用来决定哪些任务值得交给模型、哪些还是人写更快。这个玩法等我再多跑几百个小时再来分享。