1. 这套工作流到底在解决什么问题第一次听到“让强模型做总工让高性价比模型写代码”这个说法我脑子里立刻浮现出工地上的场景一个经验丰富的总工负责看图纸、定方案、验收关键节点而大量搬砖、砌墙、浇筑的活儿交给成本更低的施工队。这个比喻放在 AI 辅助编程领域精准得让人拍大腿。核心逻辑其实就一句话把“思考”和“执行”拆开分别交给不同档位的模型去做。强模型比如 Claude 系列的高端版本、GPT 系列的高推理档位负责需求拆解、架构设计、任务分派、代码审查和疑难杂症诊断高性价比模型比如各类轻量级代码模型、开源代码模型、低价 API 档位负责按照明确的指令批量产出代码、写测试、补注释、做格式化。为什么非要这么折腾因为实际用下来你会发现两个扎心的事实。第一强模型贵而且贵得离谱。如果你让一个顶级模型从头到尾写一个中等规模的项目token 消耗速度会让你怀疑人生尤其是当它反复读文件、反复改同一段代码的时候。第二强模型在“写具体代码”这件事上并不总是比专门优化过的代码模型强多少。很多代码模型在补全、生成样板代码、写单元测试这些任务上速度快、价格低效果还稳。所以这套工作流解决的核心痛点是在保证代码质量和架构合理性的前提下把整体成本压下来同时把速度提上去。它适合谁适合那些已经在用 AI 写代码、但被账单或者速度折磨过的开发者适合想搭建自己 Agent 工作流的技术人也适合团队里负责技术选型和成本控制的人。哪怕你只是一个人写 side project这套思路也能让你用更少的钱办更多的事。我踩过的坑是一开始我让强模型直接写完整模块结果它写得很漂亮但一个下午烧掉的钱够我吃一周午饭。后来我改成“强模型出方案 弱模型填代码”同样的功能成本直接降到原来的三分之一不到而且因为强模型把接口和边界定清楚了弱模型反而很少跑偏。2. 核心思路拆解为什么这样分工才合理2.1 强模型当“总工”到底管什么强模型在这个工作流里不是不写代码而是只在关键节点写代码。它的职责边界我总结为四件事需求翻译把模糊的人类语言“帮我做个用户登录”翻译成明确的技术任务清单“需要 User 表、密码哈希、JWT 签发、登录接口、错误处理”。架构决策决定用什么框架、什么目录结构、模块之间怎么调用、数据怎么流转。这一步如果让弱模型做它很容易给你一个能跑但结构稀烂的东西。接口定义把每个模块的函数签名、输入输出、异常情况定死。这是整个工作流最关键的一环后面会展开讲。审查与诊断弱模型写完代码后强模型负责 review找出逻辑漏洞、边界问题、安全隐患并给出修改指令。为什么不让强模型直接写完因为它的优势在于“判断”和“推理”而不是“打字速度”。你让它做决策它值这个价你让它重复写 CRUD那是浪费。2.2 高性价比模型写代码的边界在哪高性价比模型不是“随便什么便宜模型都行”。它需要满足几个条件代码能力过关、指令遵循能力强、支持足够的上下文长度、API 稳定且便宜。我实测下来一些专门针对代码微调的轻量模型在“给定明确函数签名和注释补全实现”这个任务上表现非常接近强模型但价格可能只有十分之一。它的职责就是在强模型划定的框框里把代码填满。包括写函数实现、写单元测试、写文档字符串、做代码格式化、补类型注解。这些活儿的特点是“目标明确、边界清晰、不需要太多创造性”正好是弱模型的舒适区。这里有个关键认知弱模型跑偏往往不是因为模型笨而是因为指令不够明确。如果你给它的任务是“实现用户登录功能”它可能给你写一个明文存密码的版本。但如果你给它的任务是“实现函数def login(username: str, password: str) - Optional[str]要求1. 从 users 表按 username 查询2. 用 bcrypt 校验密码3. 成功返回 JWT token失败返回 None4. 处理数据库连接异常”它就能写得八九不离十。2.3 为什么这种分工能同时省钱又保质从成本结构看一个项目的 token 消耗大致分为“思考类”和“产出类”。思考类包括读需求、分析代码、做决策、写审查意见产出类包括写具体代码、写测试、写注释。实际项目中产出类的 token 量往往是思考类的几倍甚至十几倍。把产出类交给便宜模型成本自然大幅下降。从质量角度看代码质量的上限由架构和接口决定下限由具体实现决定。强模型把控上限弱模型只要不突破下限整体质量就有保障。而且强模型做审查时是在“已经有一个完整实现”的基础上做判断比让它从零写要快得多也准得多。从速度角度看弱模型通常响应更快而且可以并行调用。比如强模型一次性派发 10 个函数实现任务你可以同时调用 10 次弱模型 API几分钟内全部完成。如果让强模型串行写光等待时间就够你喝两杯咖啡。注意这套工作流的前提是你能把任务拆得足够细、接口定得足够死。如果拆不细弱模型就会开始“自由发挥”这时候省下的钱会以 debug 时间的形式加倍还回去。3. 实操落地从零搭一套双模型工作流3.1 工具选型与基础环境准备先说工具。这套工作流不依赖某个特定平台核心是“能调用两个不同模型的 API并且能把它们串起来”。我目前用的是 CLI 工具 脚本编排的方式具体来说强模型侧用支持高推理档位的 API或者直接用官方 CLI 工具。我习惯用claude或codex这类 CLI 做交互式总工因为它们能直接读项目文件、理解上下文。弱模型侧用 OpenAI 兼容接口的代码模型通过 Python 脚本批量调用。选它的理由是便宜、快、支持并发。编排层一个 Python 脚本负责把强模型输出的任务清单解析成结构化数据然后分发给弱模型最后把结果汇总回强模型审查。环境准备很简单一个 Python 3.10 的环境装openai、rich、pydantic这几个库就够了。如果你用 CLI 工具确保它支持非交互模式比如--print或者-p参数这样才能在脚本里调用。pip install openai rich pydantic python-dotenvAPI key 放在.env文件里别硬编码。强模型和弱模型的 key 分开管理方便后面算账。3.2 第一步让强模型输出结构化任务清单这是整个工作流的起点也是最容易翻车的地方。你不能让强模型随便写一段话然后指望脚本能解析。必须让它输出严格的结构化数据我一般用 JSON。给强模型的提示词大概长这样你是一个技术总工。请分析以下需求输出一个 JSON 格式的任务清单。 需求{用户需求} 输出格式要求 { project_structure: 目录结构说明, tasks: [ { id: task_001, file: 相对文件路径, function_signature: 完整的函数签名, description: 这个函数要做什么, requirements: [要求1, 要求2], dependencies: [依赖的其他task_id], test_cases: [测试用例描述] } ] } 注意 1. 每个 task 只负责一个函数或一个类的一个方法 2. function_signature 必须完整包含类型注解 3. requirements 要具体到可以直接实现不要模糊描述 4. 如果有多个文件按依赖顺序排列实测下来强模型对这个格式的遵循度很高。如果它偶尔输出多余的文字用正则把 JSON 部分抠出来就行。我一般会加一句“只输出 JSON不要任何解释”能减少很多麻烦。拿到 JSON 后用 Pydantic 做校验确保每个 task 都有必要的字段。这一步别偷懒校验能帮你提前发现强模型“偷工减料”的地方。3.3 第二步把任务分发给高性价比模型分发逻辑的核心是依赖排序 并发执行。有依赖关系的 task 必须等前置 task 完成没有依赖的可以并行。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(api_keyWEAK_MODEL_KEY, base_urlWEAK_MODEL_BASE) async def implement_task(task, context): prompt f 请实现以下函数只输出代码不要任何解释。 文件{task[file]} 函数签名{task[function_signature]} 功能描述{task[description]} 具体要求 {chr(10).join(- r for r in task[requirements])} 已有代码上下文 {context} 要求 1. 严格遵循函数签名 2. 处理所有异常情况 3. 代码风格与上下文一致 4. 不要写测试测试单独处理 response await client.chat.completions.create( modelcode-model-name, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.content这里有几个细节值得说。temperature 设低一点0.1 到 0.3 之间代码生成不需要创造性稳定比惊喜重要。上下文要给够至少把同文件已有的 import 和相邻函数给它不然它可能用错库或者命名风格不一致。要求里明确“不要写测试”因为测试我建议单独一个 task让弱模型专门写这样职责更清晰。并发控制用asyncio.Semaphore别一次性发几百个请求容易被限流。我一般设 5 到 10 的并发度具体看 API 的 rate limit。3.4 第三步强模型审查与迭代修正弱模型写完的代码不能直接用必须过强模型这一关。审查的提示词要聚焦在“找问题”而不是“重写”你是一个严格的代码审查者。请审查以下代码实现对照原始需求找出问题。 原始需求{task[description]} 具体要求{task[requirements]} 代码实现 {generated_code} 请输出 JSON { passed: true/false, issues: [ {severity: high/medium/low, description: 问题描述, fix_instruction: 修改指令} ], corrected_code: 如果有 high 级别问题给出修正后的完整代码否则为 null }如果passed为 false 且有 high 级别问题把fix_instruction发回给弱模型重新生成最多迭代 3 次。实测下来80% 的 task 一次通过15% 需要一轮修正剩下 5% 可能需要强模型亲自下场写。这里有个省钱技巧审查时只给强模型看有问题的部分。如果代码很长先让弱模型或者一个简单的静态检查工具做初筛把明显没问题的过滤掉只把可疑部分送给强模型。这样能省不少审查成本。3.5 第四步组装、测试与最终验收所有 task 完成后按依赖顺序组装成完整文件。组装逻辑不复杂但要注意处理 import 合并、重复代码消除、命名冲突这些细节。我一般写一个简单的组装脚本按文件路径分组然后按 task 顺序拼接。测试环节我建议分两层。第一层是弱模型写的单元测试快速跑一遍看基本功能是否正常。第二层是强模型做的集成测试审查让它看整体代码判断模块之间的调用是否有问题、边界情况是否覆盖。最终验收时让强模型输出一份“验收报告”包括完成了哪些功能、有哪些已知限制、建议后续优化什么。这份报告直接可以当 PR 描述用省事。4. 常见问题与排查技巧实录4.1 弱模型跑偏的典型场景与修复场景一函数签名不匹配。弱模型有时候会“自作主张”改函数名或者参数。修复方法是在 prompt 里加一句“函数签名必须逐字符一致不得修改”并且在生成后做一次签名比对不一致直接打回。场景二异常处理缺失。弱模型倾向于写“快乐路径”不考虑数据库连接失败、参数为空这些情况。修复方法是在 requirements 里明确列出要处理的异常比如“必须捕获 DatabaseError 并返回 None”。场景三命名风格不一致。如果上下文用 snake_case弱模型可能给你写 camelCase。修复方法是在 prompt 里附上 2 到 3 个已有函数的例子让它模仿。场景四过度设计。弱模型有时候会引入不必要的抽象层或者设计模式。修复方法是在 requirements 里加一句“保持实现简单不要引入额外的类或模块”。4.2 成本失控的预警信号这套工作流虽然省钱但如果用法不对照样能烧钱。以下几个信号出现时说明你的成本在失控强模型的审查轮次超过 3 轮还在打回说明任务拆分有问题回去重新拆。弱模型的输出经常需要强模型重写说明 requirements 写得太模糊。单个 task 的代码超过 200 行说明拆得不够细一个函数不该这么长。强模型读的文件越来越多说明上下文管理没做好该做摘要或者分片了。我自己的经验是一个健康的 task 应该在 50 到 150 行代码之间requirements 在 3 到 6 条弱模型一次生成就能达到 80% 可用度。如果偏离这个范围先停下来调整拆分策略别硬跑。4.3 排查速查表问题现象可能原因排查动作修复方案弱模型输出无法解析提示词没强调只输出代码检查 prompt 是否有“只输出代码”加约束词加输出格式示例代码能跑但逻辑错requirements 描述模糊对照需求逐条检查把 requirements 改写成可验证的断言强模型审查总是不通过接口定义有歧义让强模型重新定义接口补充输入输出示例和边界条件并发调用被限流并发度太高看 API 返回的 429 错误降低 Semaphore 值加退避重试组装后 import 报错依赖顺序不对检查 task 的 dependencies 字段拓扑排序确保前置先执行成本比预期高强模型介入太多统计各模型 token 消耗把更多任务下放给弱模型4.4 几个我踩过的坑坑一让强模型写测试。一开始我觉得测试很重要让强模型写。结果它写得非常详尽但 token 消耗巨大。后来改成弱模型写测试、强模型审查测试成本降了一半覆盖率反而更高因为弱模型更愿意写“笨”测试覆盖更多边界。坑二忽略上下文长度。弱模型的上下文窗口通常比强模型小。如果你把整个项目文件都塞给它它可能截断或者忽略后半部分。我的做法是只给相关片段最多加上同文件的 import 和相邻函数。坑三没有版本控制。双模型工作流会产生大量中间产物task 清单、生成代码、审查意见、修正版本。如果没有 git 管理出了问题根本回不去。我现在的做法是每个 task 一个 commit审查通过后 squash 合并。坑四强模型“过度审查”。强模型有时候会提出一些“理论上更好但实际没必要”的修改建议比如“建议引入依赖注入”。这种建议如果全部执行会无限拉长迭代周期。我的做法是在审查提示词里加一句“只关注正确性和安全性问题不要提架构优化建议”。5. 进阶玩法让工作流自己跑起来5.1 用 Agent 框架做自动编排上面说的是脚本编排适合手动控制。如果你想让它更自动可以套一层 Agent 框架。核心思路是把“总工”和“写手”分别封装成 Agent用一个 Orchestrator Agent 来调度。Orchestrator 的职责是接收用户需求调用总工 Agent 拆任务然后按依赖顺序调用写手 Agent最后调用总工 Agent 审查。整个过程可以做成一个循环直到所有 task 通过审查。我用过的框架里轻量级的用LangGraph或者自己写状态机都行。关键是状态管理要清晰每个 task 有pending、in_progress、review、done几个状态Orchestrator 根据状态决定下一步动作。5.2 接入 CLI 工具做本地执行如果你用codex cli或者claude cli这类工具可以把它们封装成函数调用。比如codex --print 审查以下代码$(cat generated.py) review.json这样强模型可以直接读本地文件不用你手动复制粘贴。弱模型侧也可以用 CLI 工具但要注意 CLI 工具通常有交互式确认需要加--yes或者类似参数跳过。CLI 工具的好处是能直接操作文件系统坏处是输出格式不好控制。我的做法是让 CLI 输出 JSON然后用jq解析。如果 CLI 不支持 JSON 输出就用正则从文本里抠。5.3 扩展到多语言和多项目这套工作流不限于 Python。换成 JavaScript、Go、Rust 都一样核心是“强模型定接口弱模型填实现”。不同语言的差异主要在提示词上比如 Go 要强调 error handlingRust 要强调所有权和生命周期。多项目并行时注意隔离上下文。每个项目一个独立的 task 队列别混在一起。我一般用目录区分projects/project_a/tasks.json、projects/project_b/tasks.json脚本按项目路径加载。5.4 质量兜底静态检查与人工抽检不管工作流多自动最后一定要有兜底。我一般接三个静态检查工具ruff做 Python lintmypy做类型检查pytest跑测试。这三个都过了才进入人工抽检。人工抽检不用全看抽 10% 到 20% 的 task重点看核心逻辑和边界处理。如果抽检发现问题说明工作流某个环节有系统性缺陷回去调整提示词或者拆分策略。提示静态检查工具的输出也可以喂给弱模型让它自动修复 lint 错误。这样能省掉大量手动改格式的时间。6. 一些个人体会这套工作流我用了大概半年最大的感受是AI 辅助编程的瓶颈不在模型能力而在任务拆分和接口定义。你把任务拆得越细、接口定得越死弱模型的表现就越接近强模型。反过来如果你自己都没想清楚要做什么再强的模型也帮不了你。另一个体会是成本和质量不是零和博弈。很多人觉得用便宜模型就是牺牲质量其实不是。在接口明确的前提下弱模型写出的代码质量完全够用而且因为它的“创造力”有限反而不容易引入奇怪的抽象和过度设计。最后分享一个小技巧把强模型的审查意见存下来作为弱模型的 few-shot 示例。下次遇到类似任务时把之前的审查意见和修正后的代码一起放进 prompt弱模型的一次通过率会明显提升。这相当于让弱模型从强模型的反馈中“学习”越用越顺手。这套东西后续还可以扩展比如接入 CI/CD 流水线让每次 commit 自动触发审查或者做一个 Web 界面让非技术同事也能提交需求。但那是另一个话题了先把核心工作流跑通再说。 强模型当总工，高性价比模型写代码：AI编程降本增效实战
1. 这套工作流到底在解决什么问题第一次听到“让强模型做总工让高性价比模型写代码”这个说法我脑子里立刻浮现出工地上的场景一个经验丰富的总工负责看图纸、定方案、验收关键节点而大量搬砖、砌墙、浇筑的活儿交给成本更低的施工队。这个比喻放在 AI 辅助编程领域精准得让人拍大腿。核心逻辑其实就一句话把“思考”和“执行”拆开分别交给不同档位的模型去做。强模型比如 Claude 系列的高端版本、GPT 系列的高推理档位负责需求拆解、架构设计、任务分派、代码审查和疑难杂症诊断高性价比模型比如各类轻量级代码模型、开源代码模型、低价 API 档位负责按照明确的指令批量产出代码、写测试、补注释、做格式化。为什么非要这么折腾因为实际用下来你会发现两个扎心的事实。第一强模型贵而且贵得离谱。如果你让一个顶级模型从头到尾写一个中等规模的项目token 消耗速度会让你怀疑人生尤其是当它反复读文件、反复改同一段代码的时候。第二强模型在“写具体代码”这件事上并不总是比专门优化过的代码模型强多少。很多代码模型在补全、生成样板代码、写单元测试这些任务上速度快、价格低效果还稳。所以这套工作流解决的核心痛点是在保证代码质量和架构合理性的前提下把整体成本压下来同时把速度提上去。它适合谁适合那些已经在用 AI 写代码、但被账单或者速度折磨过的开发者适合想搭建自己 Agent 工作流的技术人也适合团队里负责技术选型和成本控制的人。哪怕你只是一个人写 side project这套思路也能让你用更少的钱办更多的事。我踩过的坑是一开始我让强模型直接写完整模块结果它写得很漂亮但一个下午烧掉的钱够我吃一周午饭。后来我改成“强模型出方案 弱模型填代码”同样的功能成本直接降到原来的三分之一不到而且因为强模型把接口和边界定清楚了弱模型反而很少跑偏。2. 核心思路拆解为什么这样分工才合理2.1 强模型当“总工”到底管什么强模型在这个工作流里不是不写代码而是只在关键节点写代码。它的职责边界我总结为四件事需求翻译把模糊的人类语言“帮我做个用户登录”翻译成明确的技术任务清单“需要 User 表、密码哈希、JWT 签发、登录接口、错误处理”。架构决策决定用什么框架、什么目录结构、模块之间怎么调用、数据怎么流转。这一步如果让弱模型做它很容易给你一个能跑但结构稀烂的东西。接口定义把每个模块的函数签名、输入输出、异常情况定死。这是整个工作流最关键的一环后面会展开讲。审查与诊断弱模型写完代码后强模型负责 review找出逻辑漏洞、边界问题、安全隐患并给出修改指令。为什么不让强模型直接写完因为它的优势在于“判断”和“推理”而不是“打字速度”。你让它做决策它值这个价你让它重复写 CRUD那是浪费。2.2 高性价比模型写代码的边界在哪高性价比模型不是“随便什么便宜模型都行”。它需要满足几个条件代码能力过关、指令遵循能力强、支持足够的上下文长度、API 稳定且便宜。我实测下来一些专门针对代码微调的轻量模型在“给定明确函数签名和注释补全实现”这个任务上表现非常接近强模型但价格可能只有十分之一。它的职责就是在强模型划定的框框里把代码填满。包括写函数实现、写单元测试、写文档字符串、做代码格式化、补类型注解。这些活儿的特点是“目标明确、边界清晰、不需要太多创造性”正好是弱模型的舒适区。这里有个关键认知弱模型跑偏往往不是因为模型笨而是因为指令不够明确。如果你给它的任务是“实现用户登录功能”它可能给你写一个明文存密码的版本。但如果你给它的任务是“实现函数def login(username: str, password: str) - Optional[str]要求1. 从 users 表按 username 查询2. 用 bcrypt 校验密码3. 成功返回 JWT token失败返回 None4. 处理数据库连接异常”它就能写得八九不离十。2.3 为什么这种分工能同时省钱又保质从成本结构看一个项目的 token 消耗大致分为“思考类”和“产出类”。思考类包括读需求、分析代码、做决策、写审查意见产出类包括写具体代码、写测试、写注释。实际项目中产出类的 token 量往往是思考类的几倍甚至十几倍。把产出类交给便宜模型成本自然大幅下降。从质量角度看代码质量的上限由架构和接口决定下限由具体实现决定。强模型把控上限弱模型只要不突破下限整体质量就有保障。而且强模型做审查时是在“已经有一个完整实现”的基础上做判断比让它从零写要快得多也准得多。从速度角度看弱模型通常响应更快而且可以并行调用。比如强模型一次性派发 10 个函数实现任务你可以同时调用 10 次弱模型 API几分钟内全部完成。如果让强模型串行写光等待时间就够你喝两杯咖啡。注意这套工作流的前提是你能把任务拆得足够细、接口定得足够死。如果拆不细弱模型就会开始“自由发挥”这时候省下的钱会以 debug 时间的形式加倍还回去。3. 实操落地从零搭一套双模型工作流3.1 工具选型与基础环境准备先说工具。这套工作流不依赖某个特定平台核心是“能调用两个不同模型的 API并且能把它们串起来”。我目前用的是 CLI 工具 脚本编排的方式具体来说强模型侧用支持高推理档位的 API或者直接用官方 CLI 工具。我习惯用claude或codex这类 CLI 做交互式总工因为它们能直接读项目文件、理解上下文。弱模型侧用 OpenAI 兼容接口的代码模型通过 Python 脚本批量调用。选它的理由是便宜、快、支持并发。编排层一个 Python 脚本负责把强模型输出的任务清单解析成结构化数据然后分发给弱模型最后把结果汇总回强模型审查。环境准备很简单一个 Python 3.10 的环境装openai、rich、pydantic这几个库就够了。如果你用 CLI 工具确保它支持非交互模式比如--print或者-p参数这样才能在脚本里调用。pip install openai rich pydantic python-dotenvAPI key 放在.env文件里别硬编码。强模型和弱模型的 key 分开管理方便后面算账。3.2 第一步让强模型输出结构化任务清单这是整个工作流的起点也是最容易翻车的地方。你不能让强模型随便写一段话然后指望脚本能解析。必须让它输出严格的结构化数据我一般用 JSON。给强模型的提示词大概长这样你是一个技术总工。请分析以下需求输出一个 JSON 格式的任务清单。 需求{用户需求} 输出格式要求 { project_structure: 目录结构说明, tasks: [ { id: task_001, file: 相对文件路径, function_signature: 完整的函数签名, description: 这个函数要做什么, requirements: [要求1, 要求2], dependencies: [依赖的其他task_id], test_cases: [测试用例描述] } ] } 注意 1. 每个 task 只负责一个函数或一个类的一个方法 2. function_signature 必须完整包含类型注解 3. requirements 要具体到可以直接实现不要模糊描述 4. 如果有多个文件按依赖顺序排列实测下来强模型对这个格式的遵循度很高。如果它偶尔输出多余的文字用正则把 JSON 部分抠出来就行。我一般会加一句“只输出 JSON不要任何解释”能减少很多麻烦。拿到 JSON 后用 Pydantic 做校验确保每个 task 都有必要的字段。这一步别偷懒校验能帮你提前发现强模型“偷工减料”的地方。3.3 第二步把任务分发给高性价比模型分发逻辑的核心是依赖排序 并发执行。有依赖关系的 task 必须等前置 task 完成没有依赖的可以并行。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(api_keyWEAK_MODEL_KEY, base_urlWEAK_MODEL_BASE) async def implement_task(task, context): prompt f 请实现以下函数只输出代码不要任何解释。 文件{task[file]} 函数签名{task[function_signature]} 功能描述{task[description]} 具体要求 {chr(10).join(- r for r in task[requirements])} 已有代码上下文 {context} 要求 1. 严格遵循函数签名 2. 处理所有异常情况 3. 代码风格与上下文一致 4. 不要写测试测试单独处理 response await client.chat.completions.create( modelcode-model-name, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.content这里有几个细节值得说。temperature 设低一点0.1 到 0.3 之间代码生成不需要创造性稳定比惊喜重要。上下文要给够至少把同文件已有的 import 和相邻函数给它不然它可能用错库或者命名风格不一致。要求里明确“不要写测试”因为测试我建议单独一个 task让弱模型专门写这样职责更清晰。并发控制用asyncio.Semaphore别一次性发几百个请求容易被限流。我一般设 5 到 10 的并发度具体看 API 的 rate limit。3.4 第三步强模型审查与迭代修正弱模型写完的代码不能直接用必须过强模型这一关。审查的提示词要聚焦在“找问题”而不是“重写”你是一个严格的代码审查者。请审查以下代码实现对照原始需求找出问题。 原始需求{task[description]} 具体要求{task[requirements]} 代码实现 {generated_code} 请输出 JSON { passed: true/false, issues: [ {severity: high/medium/low, description: 问题描述, fix_instruction: 修改指令} ], corrected_code: 如果有 high 级别问题给出修正后的完整代码否则为 null }如果passed为 false 且有 high 级别问题把fix_instruction发回给弱模型重新生成最多迭代 3 次。实测下来80% 的 task 一次通过15% 需要一轮修正剩下 5% 可能需要强模型亲自下场写。这里有个省钱技巧审查时只给强模型看有问题的部分。如果代码很长先让弱模型或者一个简单的静态检查工具做初筛把明显没问题的过滤掉只把可疑部分送给强模型。这样能省不少审查成本。3.5 第四步组装、测试与最终验收所有 task 完成后按依赖顺序组装成完整文件。组装逻辑不复杂但要注意处理 import 合并、重复代码消除、命名冲突这些细节。我一般写一个简单的组装脚本按文件路径分组然后按 task 顺序拼接。测试环节我建议分两层。第一层是弱模型写的单元测试快速跑一遍看基本功能是否正常。第二层是强模型做的集成测试审查让它看整体代码判断模块之间的调用是否有问题、边界情况是否覆盖。最终验收时让强模型输出一份“验收报告”包括完成了哪些功能、有哪些已知限制、建议后续优化什么。这份报告直接可以当 PR 描述用省事。4. 常见问题与排查技巧实录4.1 弱模型跑偏的典型场景与修复场景一函数签名不匹配。弱模型有时候会“自作主张”改函数名或者参数。修复方法是在 prompt 里加一句“函数签名必须逐字符一致不得修改”并且在生成后做一次签名比对不一致直接打回。场景二异常处理缺失。弱模型倾向于写“快乐路径”不考虑数据库连接失败、参数为空这些情况。修复方法是在 requirements 里明确列出要处理的异常比如“必须捕获 DatabaseError 并返回 None”。场景三命名风格不一致。如果上下文用 snake_case弱模型可能给你写 camelCase。修复方法是在 prompt 里附上 2 到 3 个已有函数的例子让它模仿。场景四过度设计。弱模型有时候会引入不必要的抽象层或者设计模式。修复方法是在 requirements 里加一句“保持实现简单不要引入额外的类或模块”。4.2 成本失控的预警信号这套工作流虽然省钱但如果用法不对照样能烧钱。以下几个信号出现时说明你的成本在失控强模型的审查轮次超过 3 轮还在打回说明任务拆分有问题回去重新拆。弱模型的输出经常需要强模型重写说明 requirements 写得太模糊。单个 task 的代码超过 200 行说明拆得不够细一个函数不该这么长。强模型读的文件越来越多说明上下文管理没做好该做摘要或者分片了。我自己的经验是一个健康的 task 应该在 50 到 150 行代码之间requirements 在 3 到 6 条弱模型一次生成就能达到 80% 可用度。如果偏离这个范围先停下来调整拆分策略别硬跑。4.3 排查速查表问题现象可能原因排查动作修复方案弱模型输出无法解析提示词没强调只输出代码检查 prompt 是否有“只输出代码”加约束词加输出格式示例代码能跑但逻辑错requirements 描述模糊对照需求逐条检查把 requirements 改写成可验证的断言强模型审查总是不通过接口定义有歧义让强模型重新定义接口补充输入输出示例和边界条件并发调用被限流并发度太高看 API 返回的 429 错误降低 Semaphore 值加退避重试组装后 import 报错依赖顺序不对检查 task 的 dependencies 字段拓扑排序确保前置先执行成本比预期高强模型介入太多统计各模型 token 消耗把更多任务下放给弱模型4.4 几个我踩过的坑坑一让强模型写测试。一开始我觉得测试很重要让强模型写。结果它写得非常详尽但 token 消耗巨大。后来改成弱模型写测试、强模型审查测试成本降了一半覆盖率反而更高因为弱模型更愿意写“笨”测试覆盖更多边界。坑二忽略上下文长度。弱模型的上下文窗口通常比强模型小。如果你把整个项目文件都塞给它它可能截断或者忽略后半部分。我的做法是只给相关片段最多加上同文件的 import 和相邻函数。坑三没有版本控制。双模型工作流会产生大量中间产物task 清单、生成代码、审查意见、修正版本。如果没有 git 管理出了问题根本回不去。我现在的做法是每个 task 一个 commit审查通过后 squash 合并。坑四强模型“过度审查”。强模型有时候会提出一些“理论上更好但实际没必要”的修改建议比如“建议引入依赖注入”。这种建议如果全部执行会无限拉长迭代周期。我的做法是在审查提示词里加一句“只关注正确性和安全性问题不要提架构优化建议”。5. 进阶玩法让工作流自己跑起来5.1 用 Agent 框架做自动编排上面说的是脚本编排适合手动控制。如果你想让它更自动可以套一层 Agent 框架。核心思路是把“总工”和“写手”分别封装成 Agent用一个 Orchestrator Agent 来调度。Orchestrator 的职责是接收用户需求调用总工 Agent 拆任务然后按依赖顺序调用写手 Agent最后调用总工 Agent 审查。整个过程可以做成一个循环直到所有 task 通过审查。我用过的框架里轻量级的用LangGraph或者自己写状态机都行。关键是状态管理要清晰每个 task 有pending、in_progress、review、done几个状态Orchestrator 根据状态决定下一步动作。5.2 接入 CLI 工具做本地执行如果你用codex cli或者claude cli这类工具可以把它们封装成函数调用。比如codex --print 审查以下代码$(cat generated.py) review.json这样强模型可以直接读本地文件不用你手动复制粘贴。弱模型侧也可以用 CLI 工具但要注意 CLI 工具通常有交互式确认需要加--yes或者类似参数跳过。CLI 工具的好处是能直接操作文件系统坏处是输出格式不好控制。我的做法是让 CLI 输出 JSON然后用jq解析。如果 CLI 不支持 JSON 输出就用正则从文本里抠。5.3 扩展到多语言和多项目这套工作流不限于 Python。换成 JavaScript、Go、Rust 都一样核心是“强模型定接口弱模型填实现”。不同语言的差异主要在提示词上比如 Go 要强调 error handlingRust 要强调所有权和生命周期。多项目并行时注意隔离上下文。每个项目一个独立的 task 队列别混在一起。我一般用目录区分projects/project_a/tasks.json、projects/project_b/tasks.json脚本按项目路径加载。5.4 质量兜底静态检查与人工抽检不管工作流多自动最后一定要有兜底。我一般接三个静态检查工具ruff做 Python lintmypy做类型检查pytest跑测试。这三个都过了才进入人工抽检。人工抽检不用全看抽 10% 到 20% 的 task重点看核心逻辑和边界处理。如果抽检发现问题说明工作流某个环节有系统性缺陷回去调整提示词或者拆分策略。提示静态检查工具的输出也可以喂给弱模型让它自动修复 lint 错误。这样能省掉大量手动改格式的时间。6. 一些个人体会这套工作流我用了大概半年最大的感受是AI 辅助编程的瓶颈不在模型能力而在任务拆分和接口定义。你把任务拆得越细、接口定得越死弱模型的表现就越接近强模型。反过来如果你自己都没想清楚要做什么再强的模型也帮不了你。另一个体会是成本和质量不是零和博弈。很多人觉得用便宜模型就是牺牲质量其实不是。在接口明确的前提下弱模型写出的代码质量完全够用而且因为它的“创造力”有限反而不容易引入奇怪的抽象和过度设计。最后分享一个小技巧把强模型的审查意见存下来作为弱模型的 few-shot 示例。下次遇到类似任务时把之前的审查意见和修正后的代码一起放进 prompt弱模型的一次通过率会明显提升。这相当于让弱模型从强模型的反馈中“学习”越用越顺手。这套东西后续还可以扩展比如接入 CI/CD 流水线让每次 commit 自动触发审查或者做一个 Web 界面让非技术同事也能提交需求。但那是另一个话题了先把核心工作流跑通再说。