1. 这套工作流到底在解决什么问题第一次听到“让强模型做总工让高性价比模型写代码”这个说法我脑子里立刻浮现出工地上的场景一个经验丰富的总工坐在办公室里审图纸、定方案、把关关键节点而现场大量的砌墙、布线、搬砖活儿交给成本更低的工人去干。总工不需要亲自搬每一块砖但他得知道哪面墙是承重墙、哪根管线不能动。这个比喻放在 AI 辅助编程里简直再贴切不过。核心痛点其实很直白强模型贵弱模型便宜但容易跑偏。你让最强的模型从头到尾写一个完整项目token 消耗能让你肉疼你让便宜模型独立干活它又经常在关键决策上犯糊涂写出那种“看着能跑、一上生产就炸”的代码。所以这套工作流的核心思路就是分工——把“想清楚”和“写出来”拆成两个阶段分别交给不同档位的模型去执行。具体来说强模型负责的是架构设计、任务拆解、接口定义、代码审查这些需要深度推理的环节高性价比模型负责的是按照明确规格填充具体实现、写单元测试、补注释、做格式转换这些执行层面的活儿。中间靠什么衔接靠一份足够清晰的“施工图纸”——也就是结构化的任务描述和接口契约。这套东西适合谁我觉得三类人最该认真看看一是独立开发者预算有限但想用 AI 把项目推进下去二是小团队的技术负责人需要控制 API 成本的同时保证代码质量三是正在搭建 Agent 工作流的工程师想理解怎么用多模型协作来提升整体效率。如果你只是偶尔用 AI 补个函数那可能感受不深但只要你开始用 Agent 或 CLI 工具做稍微像样点的项目这套分工逻辑迟早会撞上。我实测下来的感受是同样的项目用这套分工模式总成本能压到全程强模型的 30% 到 40%而最终代码质量差距并没有想象中那么大。前提是你得把“总工”的指令写清楚别让施工队猜。2. 为什么非得这么分工不能一个模型干到底2.1 强模型和弱模型的真实能力差距在哪很多人以为强模型和便宜模型的差距是“聪明程度”的线性差异其实不是。我自己的观察是差距主要体现在三个维度上而且这三个维度的差距大小完全不同。第一个维度是长链条推理能力。你让强模型分析一个涉及五六个模块相互调用的需求它能一步步推下来中间不会丢线索便宜模型往往推到第三步就开始胡编把前面定义的接口名字都记错了。这个差距是质变级别的不是靠多试几次能弥补的。第二个维度是代码风格和边界处理。强模型写出来的代码异常处理、边界条件、命名规范通常都在线便宜模型写个 happy path 没问题但一到空值、超时、并发这些场景就开始糊弄。这个差距是量变级别的可以通过明确的规格说明来缩小。第三个维度是纯代码量产出速度。说实话在“给定明确函数签名和输入输出示例”的情况下便宜模型写出来的代码和强模型差距真不大但便宜模型快得多、便宜得多。这个维度上便宜模型反而有优势。所以结论很清楚把需要长链条推理的活儿留给强模型把规格明确的填充活儿交给便宜模型。这不是妥协这是资源的最优配置。2.2 成本账到底怎么算我拿一个真实的小项目算过账。项目大概 3000 行代码包含 8 个模块。全程用最强模型跑输入输出加起来大概消耗 120 万 token按当时的价格算下来接近 40 美元。后来改成强模型只做架构和审查便宜模型做实现强模型消耗降到 25 万 token 左右便宜模型消耗 90 万 token总成本降到 13 美元出头。方案强模型 token便宜模型 token估算成本代码可用率全程强模型120万0约40美元92%分工模式25万90万约13美元85%全程便宜模型0130万约5美元58%代码可用率是我自己定义的能直接进代码库不用大改的比例。分工模式比全程强模型低了 7 个百分点但成本只有三分之一。那 7 个百分点靠什么补靠强模型做最后一道审查把便宜模型写歪的地方揪出来。审查环节的 token 消耗远低于从头写这就是省钱的秘密。2.3 为什么 Agent 和 CLI 工具特别适合这套模式现在主流的 Agent 框架和 CLI 工具基本都支持多模型配置。你可以给不同的角色指定不同的模型端点。比如在配置文件里把 planner 角色指向强模型把 coder 角色指向便宜模型把 reviewer 角色再指回强模型。这种灵活性是这套工作流能落地的前提。CLI 工具的好处是上下文管理更可控。你可以把强模型产出的“施工图纸”存成文件然后让便宜模型在独立的会话里读取这个文件来干活避免把整个项目历史都塞进便宜模型的上下文里浪费 token。Agent 框架的好处是流程编排更顺你可以定义好“规划→实现→审查→修正”的循环让不同模型在各自环节自动切换。我试过纯手动在几个工具之间倒腾也试过用 Agent 框架串起来。手动的好处是每一步你都能看清楚坏处是累框架的好处是省心坏处是调试起来麻烦。新手建议先从手动开始摸清楚每个环节的输入输出长什么样再考虑自动化。3. 施工图纸怎么画强模型产出的规格说明该包含什么3.1 任务拆解的粒度控制强模型做总工第一件事就是把大需求拆成小任务。这里有个关键经验拆到“一个函数或一个类”的粒度最合适。太粗了便宜模型搞不定太细了强模型自己就把活儿干完了失去分工意义。我一般要求强模型输出这样的结构每个任务包含任务编号、功能描述、输入参数、输出格式、依赖关系、验收标准。其中验收标准最重要它决定了便宜模型写完之后怎么自测。比如“输入为空时返回空列表而不是抛异常”这种必须写清楚。拆解的时候有个坑别让强模型拆出跨模块的隐式依赖。什么意思就是任务 A 和任务 B 看起来独立但实际上 A 的实现细节会影响 B 的调用方式。这种隐式依赖便宜模型根本处理不了。解决办法是要求强模型在拆解阶段就显式定义所有接口签名把模块间的契约先定死。3.2 接口契约的写法接口契约是这套工作流的命脉。我通常要求强模型用类似下面的格式输出# 接口契约示例 # 模块user_service # 函数get_user_profile # 输入user_id (str, 必填UUID格式) # 输出dict包含 keys: id, name, email, created_at # 异常UserNotFoundError 当 user_id 不存在时抛出 # 依赖database.query, cache.get # 验收输入合法UUID返回完整字典输入不存在ID抛UserNotFoundError def get_user_profile(user_id: str) - dict: pass这种契约写清楚之后便宜模型要做的就是把 pass 替换成实现。它不需要知道这个函数在整个系统里怎么被调用只需要满足契约里的输入输出和异常约定。实测下来这种模式下便宜模型的一次通过率能到 80% 以上。注意接口契约里千万别写“参考某某模块的实现”这种模糊描述。便宜模型会去猜一猜就错。所有依赖必须显式列出函数名和所在模块。3.3 给便宜模型的提示词模板便宜模型不是不能干活是不能给它模糊指令。我总结了一个提示词模板实测效果比较稳你是一个代码实现助手。请严格按照以下规格实现函数不要添加规格之外的任何功能。 规格 [粘贴接口契约] 约束 1. 只实现规格中描述的功能不要自作主张添加日志、缓存、重试等逻辑 2. 异常类型必须与规格一致 3. 不要修改函数签名 4. 如果规格中有不清楚的地方在代码注释里标注 TODO 并说明疑问不要猜测 请输出完整的函数实现代码。这个模板的关键在于约束部分。便宜模型最大的毛病就是“过度热情”你让它写个加法它给你加上参数校验、日志、重试、缓存。这些额外逻辑往往就是 bug 的来源。明确禁止之后输出会干净很多。4. 施工队怎么干活便宜模型实现环节的实操细节4.1 单任务实现的完整流程我拿一个真实任务走一遍。假设强模型拆出来一个任务实现一个“滑动窗口滤波”函数用于处理传感器数据。接口契约如下# 函数sliding_window_filter # 输入data (list[float]), window_size (int, 必须为正奇数) # 输出list[float]长度与输入相同边界处用可用数据计算 # 异常ValueError 当 window_size 不是正奇数时抛出 # 验收输入 [1,2,3,4,5] window_size3 输出 [1.5, 2.0, 3.0, 4.0, 4.5]我把这个契约塞进提示词模板发给便宜模型。它返回的实现大概是这样的def sliding_window_filter(data, window_size): if window_size 0 or window_size % 2 0: raise ValueError(window_size must be a positive odd number) half window_size // 2 result [] for i in range(len(data)): left max(0, i - half) right min(len(data), i half 1) window data[left:right] result.append(sum(window) / len(window)) return result这个实现基本正确边界处理也对。但有个小问题验收标准里给的示例输出是 [1.5, 2.0, 3.0, 4.0, 4.5]而实际算出来第一个元素是 (12)/21.5对的第二个是 (123)/32.0对的最后一个 (45)/24.5对的。所以这个实现直接可用。但如果没有验收标准里的具体数值便宜模型很可能在边界处理上写出data[max(0,i-half):ihalf1]这种在末尾会越界的代码。验收标准里的具体示例就是给便宜模型的对答案有了它边界 bug 少一大半。4.2 批量任务的处理策略一个项目几十个任务不可能一个个手动发。我的做法是按依赖关系分批。没有相互依赖的任务可以并行发给便宜模型有依赖的必须等前置任务完成后再发。具体操作上我会把任务列表整理成一个表格标注每个任务的依赖任务编号功能依赖状态T001数据读取无待实现T002数据清洗T001待实现T003特征计算T002待实现T004结果输出T003待实现T001 先发拿到实现后把 T001 的代码作为上下文附在 T002 的提示词里以此类推。注意不要把整个项目的所有代码都塞进上下文只塞直接依赖的那部分。上下文越长便宜模型越容易分心。4.3 便宜模型写歪了怎么救便宜模型写歪是常态关键是怎么快速发现和修正。我的经验是分三步走第一步跑验收标准。每个任务都有验收标准写个简单的测试脚本跑一遍不通过的直接打回。这一步能拦下 60% 的问题。第二步看代码风格。有些代码验收能过但风格一塌糊涂比如变量名用 a、b、c或者嵌套五层 if。这种不用改逻辑直接让便宜模型按项目规范重写一遍就行成本很低。第三步强模型审查。前两步都过了的代码攒一批之后交给强模型做整体审查。强模型这时候不需要重写只需要指出问题并给出修改建议。我一般要求强模型输出“问题位置 问题描述 修改方案”的列表然后让便宜模型按列表改。实操心得强模型审查时提示词里要加一句“只指出会导致 bug 或维护困难的问题不要提风格偏好”。不然强模型会给你列一堆“建议用 f-string 替代 format”这种无关痛痒的东西浪费 token。5. 总工验收强模型审查环节的关键操作5.1 审查提示词的设计审查环节的提示词和实现环节完全不同。实现环节要的是“严格照做”审查环节要的是“挑毛病”。我常用的审查提示词是这样的你是一个资深代码审查员。请审查以下代码找出会导致运行时错误、逻辑错误、性能问题或维护困难的地方。 审查范围 [粘贴代码] 上下文 [粘贴相关接口契约和依赖模块的签名] 要求 1. 按严重程度排序先列会导致 bug 的问题 2. 每个问题给出位置、原因、修改建议 3. 不要提纯风格问题如命名偏好、注释格式 4. 如果代码没有问题直接说“通过”这个提示词的关键是限定审查范围和排除风格问题。不限定范围强模型会把整个项目都翻一遍不排除风格它会给你列几十条无关紧要的建议。5.2 审查发现的典型问题分类我统计过强模型审查便宜模型代码时最常发现的问题大概分四类第一类是边界条件遗漏占比最高大概 40%。比如空列表、None 值、除零、数组越界。便宜模型写 happy path 很顺一到边界就忘。第二类是异常处理不当占比 25%。要么该抛异常的地方吞掉了要么抛了错误的异常类型要么在 except 里只写个 pass。第三类是并发安全隐患占比 20%。共享状态没加锁、数据库连接没关、文件句柄泄漏。这类问题在单线程测试时看不出来一上生产就炸。第四类是逻辑与规格不符占比 15%。便宜模型有时候会“自作主张”改需求比如规格说返回列表它返回字典规格说抛异常它返回 None。针对这四类问题我在审查提示词里会特别强调让强模型重点看这几个方面。审查提示词不是一成不变的要根据便宜模型的历史表现动态调整。如果最近边界问题多就加重边界审查的权重。5.3 审查结果的落地方式强模型给出审查意见后怎么让便宜模型改我的做法是把审查意见转成新的任务契约。比如强模型说“第 15 行在 data 为空时会抛 IndexError应该先判断空列表返回空列表”我就把这个转成一条新任务任务修复 sliding_window_filter 的空列表处理 当前代码[粘贴原代码] 问题data 为空列表时第 15 行 data[0] 会抛 IndexError 要求在函数开头判断 data 为空时直接返回空列表 验收输入 [] 返回 []这样便宜模型拿到的是一个明确的修复任务而不是模糊的“改一下这里”。实测修复成功率比直接贴审查意见高很多。6. 常见问题与排查技巧实录6.1 便宜模型反复写不对同一个地方怎么办这是最让人抓狂的情况。同一个边界条件改了三次还是错。我的经验是别再让它改了直接让强模型写这一段。强模型写这十几行代码的 token 消耗比你反复让便宜模型试错要少得多。判断标准很简单同一个问题修了两次还没过就升级到强模型。不要有“再试一次说不定就好了”的侥幸心理试错成本累积起来很吓人。6.2 强模型拆的任务便宜模型理解不了有时候强模型拆出来的任务在强模型看来很清晰但便宜模型就是理解不了。这通常是因为任务描述里用了便宜模型不熟悉的抽象概念。比如“实现一个策略模式的上下文类”便宜模型可能不知道策略模式是什么。解决办法是让强模型把抽象概念展开成具体步骤。不要写“用策略模式”要写“定义一个基类包含 execute 方法定义三个子类分别实现 execute定义一个上下文类构造函数接收一个策略实例提供 set_strategy 方法”。抽象留给强模型具体留给便宜模型。6.3 上下文太长导致便宜模型跑偏便宜模型的上下文窗口通常比强模型小而且它对长上下文的注意力更差。我踩过的坑是把一个模块的所有代码都塞给便宜模型让它改其中一个函数结果它把其他函数也“顺手优化”了。现在的做法是只给必要上下文。改一个函数就只给这个函数的代码和它直接调用的接口签名。其他无关代码一律不给。如果便宜模型需要知道某个依赖的行为就在提示词里用一句话描述而不是贴代码。6.4 成本监控和异常告警这套工作流省钱的前提是你真的在监控成本。我有一次忘了关某个 Agent 的自动重试一晚上烧掉了十几美元。后来我加了几个简单的监控规则监控项阈值动作单任务 token 消耗超过预估 3 倍暂停并告警单任务重试次数超过 3 次升级到强模型日总消耗超过预算 80%邮件提醒审查不通过率连续 5 个任务不通过检查任务拆解质量这些规则用简单的脚本就能实现不需要复杂的监控系统。关键是养成看账单的习惯别等到月底才发现超支。6.5 什么任务不适合交给便宜模型不是所有任务都适合分工。我总结了几类必须强模型亲自写的任务涉及安全敏感逻辑的代码比如权限校验、加密解密、输入过滤。便宜模型在这类代码上容易留下漏洞。核心算法实现比如排序、搜索、动态规划。便宜模型写出来的算法经常有微妙的正确性问题。跨模块的胶水代码需要理解多个模块交互的。便宜模型看不到全局写出来的胶水代码经常对不上。性能关键路径需要精细优化的。便宜模型倾向于写直观但低效的实现。这几类任务占比不高但一旦出问题就是大问题。省这点 token 不值得。7. 工具链配置与自动化衔接7.1 多模型配置的基本结构不管你用 Agent 框架还是 CLI 工具多模型配置的核心都是角色到模型的映射。我常用的配置结构大概长这样roles: planner: model: strong-model-endpoint temperature: 0.2 max_tokens: 8000 coder: model: cheap-model-endpoint temperature: 0.1 max_tokens: 4000 reviewer: model: strong-model-endpoint temperature: 0.3 max_tokens: 6000planner 和 reviewer 用强模型temperature 可以稍高一点因为需要一些创造性coder 用便宜模型temperature 要低因为需要稳定复现。temperature 的设置经常被忽略但它对便宜模型的输出稳定性影响很大。我试过 coder 用 0.7 的 temperature同样的任务每次输出都不一样验收通过率直接掉了一半。7.2 任务队列和状态管理手动一个个发任务项目小的时候还行任务一多就乱。我的做法是用一个简单的 JSON 文件做任务队列{ tasks: [ { id: T001, status: done, spec: ..., implementation: ..., review: passed }, { id: T002, status: in_progress, spec: ..., implementation: null, review: null } ] }每完成一个环节就更新状态。这个文件既是进度追踪也是上下文来源——发下一个任务时从里面读依赖任务的实现代码。别小看这个简单的状态管理它能帮你避免重复劳动和上下文混乱。7.3 自动化衔接的边界自动化到什么程度合适我的建议是实现和审查可以自动化任务拆解和最终验收必须人工介入。任务拆解是整套工作流里最需要判断力的环节强模型拆得好不好直接决定后面顺不顺。最终验收则是你对代码质量的最后一道把关不能完全交给模型。我现在的流程是强模型拆解 → 人工审核拆解结果 → 自动实现 → 自动审查 → 人工抽查审查结果 → 自动修复 → 人工最终验收。人工介入的点不多但都是关键节点。8. 我踩过的几个印象深刻的坑第一个坑是过度信任便宜模型的“自我修复”能力。有次审查发现一个问题我让便宜模型自己改它改完之后我偷懒没重新审查结果它把原来的 bug 修了但引入了两个新 bug。后来我定了个规矩任何修改之后都必须重新走审查流程不管修改多小。第二个坑是任务拆解太粗。有次强模型拆出来一个任务叫“实现用户认证模块”我直接发给便宜模型结果它写了个只有用户名密码校验的函数什么 session 管理、token 刷新、权限检查全没有。后来我把拆解粒度要求写进强模型的提示词里每个任务不超过 50 行代码超过就继续拆。第三个坑是上下文里混入了过时的接口定义。项目迭代过程中接口改了但我发给便宜模型的上下文里还是旧版本导致它按旧接口写编译都过不了。现在的做法是接口契约统一放在一个文件里每次发任务前重新读取最新版本绝不手动复制粘贴。第四个坑是忘了给便宜模型设输出长度上限。有次它在一个简单函数里写了 200 行注释把 token 额度耗光了。后来我在配置里给 coder 角色设了 max_tokens并且提示词里加一句“注释不超过 3 行”。这套工作流跑顺之后我最大的体会是省钱的本质不是用便宜模型而是把强模型的 token 花在刀刃上。强模型每输出一个 token都应该是在做便宜模型做不了的决策。一旦你发现强模型在干重复性的填充工作就说明分工出了问题该调整了。