1. 这套工作流到底在解决什么问题第一次听到“让强模型做总工让高性价比模型写代码”这个说法我脑子里立刻浮现出工地上的画面一个经验丰富的总工负责看图纸、定方案、审关键节点而具体砌墙、绑钢筋、浇混凝土的活儿交给大批工人去干。总工不需要亲自搬砖但他得确保每一块砖都砌在对的位置。这套逻辑搬到 AI 辅助编程上其实就是在解决一个非常现实的矛盾——强模型能力顶尖但成本高、速度慢便宜模型量大管饱但容易跑偏。我自己在多个项目里反复试过全用强模型和全用便宜模型的方案结论很明确全用强模型钱包扛不住一个中等规模的重构任务跑下来账单能让你怀疑人生全用便宜模型代码质量参差不齐改着改着就发现它在同一个坑里反复横跳最后还得人工兜底。所以这套“总工工人”的分层协作模式本质上是一个成本、质量、速度三者之间的工程折中。具体来说这套工作流适合以下几类人一是手头有大量重复性编码任务但预算有限的独立开发者二是团队里需要批量处理代码迁移、补测试、改配置的工程负责人三是对 Agent 工作流感兴趣、想搞清楚怎么编排多模型协作的技术爱好者。它不要求你精通 Transformer 底层原理但你得对 CLI 工具、Agent 的基本运作方式、以及代码审查流程有基本概念。核心思路一句话概括用强模型做规划、拆解、审查和关键决策用高性价比模型做具体的代码生成、批量修改和重复劳动。强模型是大脑便宜模型是手脚中间靠一套清晰的接口和检查机制串起来。2. 为什么这么分工模型能力与成本的现实账2.1 强模型到底强在哪贵在哪强模型之所以强核心在于它的推理深度和上下文理解能力。你给它一个模糊的需求比如“把这个模块的错误处理统一一下”它能自己推断出你项目里用的错误处理模式、边界条件该怎么处理、哪些地方需要加日志、哪些异常应该往上抛。这种能力来自于更大的参数量、更充分的训练以及更精细的对齐调优。但代价也很直接。强模型的 API 调用成本通常是便宜模型的十倍甚至几十倍响应速度也慢不少。我实测过一个场景让强模型生成一个 200 行的数据处理脚本它思考了将近 30 秒才吐出完整代码而同样任务交给一个高性价比模型3 秒就出结果了。如果这个脚本只是做一些常规的格式转换便宜模型的结果完全够用那多花的 27 秒和几十倍成本就是纯浪费。所以关键判断点是这个任务需不需要“理解意图”和“做决策”。需要就上强模型不需要就交给便宜模型。2.2 高性价比模型的真实水平与适用边界现在市面上的高性价比模型在模式化、有明确输入输出规范的任务上表现已经相当能打。比如按照给定的函数签名补全实现把一段代码从一种风格转成另一种风格根据模板生成配置文件批量重命名变量、调整缩进写单元测试的骨架这些任务的共同特征是目标明确、约束清晰、不需要太多创造性推理。你只要把要求写清楚便宜模型基本能稳定输出。但它的边界也很明显。一旦任务涉及跨文件的架构调整、模糊需求的理解、或者需要权衡多个方案的取舍便宜模型就容易“自信地胡说八道”。我踩过最典型的坑是让便宜模型去重构一个模块的依赖关系它直接把几个不相关的文件合并了理由是“这样看起来更简洁”。这就是缺乏全局判断力的表现。2.3 分层协作的成本账怎么算假设一个中型项目有 50 个文件需要做一次统一的重构每个文件平均 100 行代码。如果全用强模型每个文件需要约 2000 token 输入 1500 token 输出强模型按每百万 token 输入 15 元、输出 60 元算总成本约 50 × (2000×15 1500×60) / 1000000 50 × (0.03 0.09) 6 元如果采用分层方案强模型只做一次整体规划约 5000 token 输入 3000 token 输出成本约 0.25 元强模型抽查 5 个关键文件做审查约 0.6 元剩下 45 个文件交给便宜模型按强模型 1/20 的价格算约 0.27 元总成本约 1.1 元成本降到原来的不到五分之一而质量因为有强模型把关实际差距并不大。这个账算下来分层协作的性价比优势非常明显。注意这里的 token 数和价格只是示意实际会因模型提供商、任务复杂度、上下文长度而有很大差异。但量级上的差距是真实存在的。3. 工作流的核心架构怎么搭3.1 角色划分总工、工头、工人我把这套工作流拆成三个角色比单纯的两层更实用总工强模型负责需求理解、任务拆解、方案设计、关键代码审查、疑难问题诊断。它不直接写大量代码而是输出“施工图纸”——也就是详细的任务描述、接口定义、约束条件。工头中等模型或强模型的轻量调用负责把总工的图纸翻译成具体的、便宜模型能执行的指令。比如总工说“统一错误处理”工头要把它拆成“在每个 catch 块里调用 logger.error并把异常包装成 AppError 类型”这样的具体步骤。工人高性价比模型负责按照工头的指令执行具体的代码生成和修改。它不需要理解全局只需要把当前这个文件、这个函数改对就行。这个三层结构的好处是总工的调用次数最少工头的调用次数适中工人的调用次数最多成本自然就压下来了。3.2 任务拆解的粒度控制拆解粒度是这套工作流成败的关键。拆得太粗便宜模型理解不了拆得太细总工和工头的开销就上去了。我的经验是以“一个函数或一个独立文件”为基本单位。每个任务应该满足输入输出明确给定什么产出什么依赖关系清晰需要哪些上下文产出会被谁用可独立验证改完之后能单独跑测试或检查比如“给 user_service.py 里的 5 个函数补上参数校验”就是一个合适的粒度。而“优化整个项目的性能”就太粗了总工得先把它拆成十几个具体任务才能往下派。3.3 上下文传递的接口设计便宜模型最容易出问题的地方就是上下文不足。它不知道项目用的什么框架、什么编码规范、什么错误处理模式就容易按自己的习惯乱写。所以总工在拆解任务时必须同时输出一份上下文包包含项目技术栈和版本相关代码片段不是整个文件而是必要的部分编码规范和命名约定本次任务的约束条件期望的输出格式这份上下文包会跟着任务一起传给工人模型。我通常把它写成一个结构化的 Markdown 或 JSON方便程序解析和注入。3.4 质量门禁怎么设工人干完活不能直接算数得有检查机制。我设了三道门第一道自动检查。语法能不能过、测试跑不跑得通、lint 有没有报错。这些用脚本自动跑不过的直接打回。第二道工头复核。工头检查产出是否符合总工图纸的要求有没有偏离约束。这一步可以用中等模型做成本可控。第三道总工抽查。总工随机抽 10%-20% 的产出做深度审查重点看逻辑正确性和边界处理。发现问题就反馈到工头让工头调整指令重新派活。这三道门下来大部分低级错误在早期就被拦住了不会流到最终代码里。4. 实操落地从零搭一套可运行的工作流4.1 工具选型与基础环境这套工作流不依赖特定平台核心是能调 API 的 CLI 工具 一个编排脚本。我目前用的是编排层Python 脚本负责调用各模型 API、管理任务队列、执行检查CLI 工具用于在本地执行代码修改、跑测试、跑 lint版本控制Git每个任务在独立分支上执行方便回滚如果你不想自己写编排也可以用现成的 Agent 框架但我觉得自己写更可控而且能精确控制每个环节的成本。基础环境准备# 创建项目目录 mkdir model-workflow cd model-workflow # 初始化 Python 环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖 pip install openai anthropic requests pyyaml提示API key 不要硬编码在脚本里用环境变量或配置文件管理。4.2 总工模块任务拆解与图纸生成总工模块的核心是一个精心设计的 prompt。我把它分成三段第一段角色设定。告诉模型它现在是总工负责规划和审查不直接写代码。第二段项目上下文。把项目结构、技术栈、关键文件列表喂进去。第三段任务描述。用自然语言描述本次要完成的目标。输出要求是结构化的 JSON包含任务列表、每个任务的上下文包、验收标准。import json from openai import OpenAI client OpenAI() def chief_engineer_plan(project_context, task_description): prompt f 你是一名资深技术总工负责把需求拆解成可执行的任务。 项目上下文 {project_context} 本次目标 {task_description} 请输出 JSON 格式的任务列表每个任务包含 - task_id: 唯一标识 - description: 具体要做什么 - files: 涉及的文件列表 - context: 执行该任务需要的上下文代码片段、规范等 - acceptance: 验收标准 - priority: 优先级 只输出 JSON不要有其他内容。 response client.chat.completions.create( modelgpt-4o, # 强模型 messages[{role: user, content: prompt}], temperature0.2 ) return json.loads(response.choices[0].message.content)这里 temperature 设低一点保证输出的稳定性。总工的任务是规划不需要创造性。4.3 工头模块指令细化与上下文打包工头拿到总工的任务列表后逐个细化。它的工作是把“统一错误处理”这种模糊描述翻译成便宜模型能直接执行的具体指令。def foreman_refine(task, project_context): prompt f 你是一名技术工头负责把总工的任务翻译成具体的执行指令。 总工任务 {json.dumps(task, ensure_asciiFalse)} 项目上下文 {project_context} 请输出一份详细的执行指令包含 - 具体要修改的文件和位置 - 每一步的操作说明 - 代码示例如果有参考模式 - 注意事项和禁忌 指令要足够具体让一个初级工程师能直接照着做。 response client.chat.completions.create( modelgpt-4o-mini, # 中等模型 messages[{role: user, content: prompt}], temperature0.3 ) return response.choices[0].message.content工头用中等模型就够了因为它的工作是基于总工已经拆好的框架做细化不需要太强的推理能力。4.4 工人模块代码生成与批量执行工人模块是调用最频繁的所以必须用便宜模型。它的输入是工头打包好的指令和上下文输出是具体的代码修改。def worker_execute(instruction, file_content, file_path): prompt f 你是一名执行工程师请严格按照以下指令修改代码。 指令 {instruction} 当前文件 {file_path} 的内容{file_content}请输出修改后的完整文件内容。只输出代码不要有其他说明。 response client.chat.completions.create( modelgpt-4o-mini, # 便宜模型 messages[{role: user, content: prompt}], temperature0.1 ) return response.choices[0].message.contenttemperature 设到 0.1尽量让输出稳定可预测。工人的任务不需要创意需要的是准确执行。4.5 质量检查与反馈闭环每个任务执行完后自动跑检查import subprocess def run_checks(file_path): results {} # 语法检查 result subprocess.run( [python, -m, py_compile, file_path], capture_outputTrue, textTrue ) results[syntax] result.returncode 0 # lint 检查 result subprocess.run( [pylint, file_path, --disableall, --enableE], capture_outputTrue, textTrue ) results[lint] result.returncode 0 # 测试如果有对应测试文件 test_file file_path.replace(.py, _test.py) if os.path.exists(test_file): result subprocess.run( [pytest, test_file, -q], capture_outputTrue, textTrue ) results[test] result.returncode 0 return results检查不通过的任务把错误信息反馈给工头让工头调整指令后重新派给工人。这个循环最多跑三次三次还不过就升级给总工处理。4.6 完整流程串联把上面几个模块串起来主流程大概长这样def run_workflow(project_context, task_description): # 1. 总工规划 tasks chief_engineer_plan(project_context, task_description) # 2. 逐个任务处理 for task in tasks: # 工头细化 instruction foreman_refine(task, project_context) # 工人执行 for file_path in task[files]: file_content read_file(file_path) new_content worker_execute(instruction, file_content, file_path) write_file(file_path, new_content) # 质量检查 checks run_checks(file_path) if not all(checks.values()): # 反馈重试逻辑 handle_failure(task, file_path, checks) # 3. 总工抽查 sample_tasks random.sample(tasks, max(1, len(tasks) // 5)) for task in sample_tasks: review_result chief_engineer_review(task) if not review_result[passed]: # 打回重做 pass这套流程跑下来一个 50 文件的重构任务总工调用 1 次工头调用约 50 次工人调用约 50-150 次含重试总成本能控制在个位数。5. 踩过的坑与排查技巧实录5.1 便宜模型“自作聪明”怎么办这是最常见的问题。便宜模型有时候会“优化”你的代码比如把显式的类型检查删掉理由是“Python 是动态类型”。或者把日志语句合并理由是“减少重复”。我的应对方法是在指令里明确列出禁止事项。工头细化指令时必须包含一段“不要做”的清单不要删除任何现有的错误处理不要改变函数签名不要合并或拆分文件不要引入新的依赖不要修改与任务无关的代码这段清单直接写进 prompt能挡掉大部分自作聪明的行为。5.2 上下文超长导致成本失控有时候一个文件几千行全塞给工人模型token 消耗巨大。我的做法是只传相关片段。工头在细化指令时要标注出需要修改的具体行号范围只把那个范围前后各 50 行传给工人。如果修改涉及多个不连续的区域就拆成多个子任务分别处理。这样既省 token又降低模型理解难度。5.3 任务拆解粒度不当的典型症状拆得太粗的症状工人模型输出一堆无关代码或者直接说“我无法完成这个任务”。拆得太细的症状总工和工头的调用次数暴增成本反而上去了而且任务之间的依赖关系变得复杂容易乱序执行。判断标准很简单如果一个任务需要工人模型做超过 3 个独立的决策就说明拆得不够细如果两个任务之间需要频繁传递中间状态就说明拆得太细了。5.4 常见问题速查表问题现象可能原因排查方法解决措施工人输出与预期完全不符上下文不足或指令模糊检查传给工人的 prompt让工头补充上下文和示例代码语法错误率高模型能力不足或 temperature 过高降低 temperature 到 0.1换更强的模型或增加重试任务执行顺序混乱依赖关系未标注检查任务列表的依赖字段在总工 prompt 里要求标注依赖成本超出预期上下文过长或重试过多统计各模型 token 消耗精简上下文限制重试次数总工规划不合理项目上下文不完整检查传给总工的项目信息补充项目结构和技术栈说明检查环节误报lint 规则太严或测试不稳定查看具体报错信息调整检查规则或跳过不稳定测试5.5 几个提升稳定性的实操心得心得一给工人模型提供“参考实现”。如果项目里已经有类似的代码模式把它作为示例放进上下文工人模型的输出质量会明显提升。比如你要统一错误处理就把项目里写得最好的那个错误处理函数贴进去当模板。心得二总工的审查要聚焦。总工抽查时不要泛泛地看而是带着具体问题去查边界条件处理了吗异常路径覆盖了吗与现有代码风格一致吗带着问题查效率高很多。心得三保留完整的执行日志。每个任务的输入、输出、检查结果、重试次数都记下来。出问题的时候翻日志比重新跑一遍快得多。而且日志积累多了你能看出哪些类型的任务容易失败提前优化。心得四先用小批量验证。不要一上来就跑全量任务。先挑 3-5 个代表性文件跑一遍看看总工的规划合不合理、工头的指令够不够具体、工人的输出能不能过检查。验证通过再放大规模。心得五版本控制是最后的防线。每个任务在独立分支上执行出问题直接丢弃分支。我习惯在任务开始前打一个 tag任务完成后对比 diff确认无误再合并。6. 这套工作流的扩展玩法6.1 接入 CI/CD 做自动化代码审查把这套工作流接到 CI 流程里每次提交代码时自动触发总工审查。总工检查代码是否符合项目规范、有没有明显的逻辑问题、测试覆盖是否充分。审查结果作为评论发到 PR 上人工只需要看总工的审查意见不用逐行读代码。这个玩法的关键是控制总工的调用频率。不是每次提交都跑全量审查而是只审查变更的文件而且可以设置阈值比如变更超过 50 行才触发。6.2 多总工并行处理不同模块如果项目足够大可以按模块拆分每个模块配一个总工。比如前端总工、后端总工、数据层总工各自负责自己领域的任务拆解和审查。工头和工人层可以共享也可以独立。这样做的好处是每个总工的上下文更聚焦规划质量更高。代价是总工之间的协调需要额外机制比如接口定义要提前对齐。6.3 结合本地模型进一步降本如果对数据隐私有要求或者想进一步压缩成本可以把工人层换成本地部署的小模型。现在一些开源模型在代码补全和模式化任务上已经够用了。总工和工头仍然用云端强模型工人用本地模型成本能再降一个数量级。不过本地模型的部署和维护有额外成本而且输出稳定性可能不如云端 API。适合对成本极度敏感、且有一定运维能力的团队。6.4 任务模板库的积累跑多了之后你会发现很多任务是重复的补测试、改配置、统一日志格式、迁移 API 调用方式。把这些常见任务的工头指令模板化下次直接套用能省掉工头细化这一步进一步降本提速。我目前积累了二十多个模板覆盖了日常开发中 80% 的重复性任务。新任务来了先匹配模板匹配不上再走完整的工头细化流程。这套工作流我用了大半年最大的体会是不要追求全自动要追求“人在关键节点上”。总工审查、质量门禁、最终合并这三个节点必须有人参与。模型再强也不能替你做最终决策。把重复劳动交给便宜模型把判断和决策留给自己和强模型这才是这套工作流真正的价值所在。 强模型做总工，高性价比模型写代码：多模型协作工作流实战
1. 这套工作流到底在解决什么问题第一次听到“让强模型做总工让高性价比模型写代码”这个说法我脑子里立刻浮现出工地上的画面一个经验丰富的总工负责看图纸、定方案、审关键节点而具体砌墙、绑钢筋、浇混凝土的活儿交给大批工人去干。总工不需要亲自搬砖但他得确保每一块砖都砌在对的位置。这套逻辑搬到 AI 辅助编程上其实就是在解决一个非常现实的矛盾——强模型能力顶尖但成本高、速度慢便宜模型量大管饱但容易跑偏。我自己在多个项目里反复试过全用强模型和全用便宜模型的方案结论很明确全用强模型钱包扛不住一个中等规模的重构任务跑下来账单能让你怀疑人生全用便宜模型代码质量参差不齐改着改着就发现它在同一个坑里反复横跳最后还得人工兜底。所以这套“总工工人”的分层协作模式本质上是一个成本、质量、速度三者之间的工程折中。具体来说这套工作流适合以下几类人一是手头有大量重复性编码任务但预算有限的独立开发者二是团队里需要批量处理代码迁移、补测试、改配置的工程负责人三是对 Agent 工作流感兴趣、想搞清楚怎么编排多模型协作的技术爱好者。它不要求你精通 Transformer 底层原理但你得对 CLI 工具、Agent 的基本运作方式、以及代码审查流程有基本概念。核心思路一句话概括用强模型做规划、拆解、审查和关键决策用高性价比模型做具体的代码生成、批量修改和重复劳动。强模型是大脑便宜模型是手脚中间靠一套清晰的接口和检查机制串起来。2. 为什么这么分工模型能力与成本的现实账2.1 强模型到底强在哪贵在哪强模型之所以强核心在于它的推理深度和上下文理解能力。你给它一个模糊的需求比如“把这个模块的错误处理统一一下”它能自己推断出你项目里用的错误处理模式、边界条件该怎么处理、哪些地方需要加日志、哪些异常应该往上抛。这种能力来自于更大的参数量、更充分的训练以及更精细的对齐调优。但代价也很直接。强模型的 API 调用成本通常是便宜模型的十倍甚至几十倍响应速度也慢不少。我实测过一个场景让强模型生成一个 200 行的数据处理脚本它思考了将近 30 秒才吐出完整代码而同样任务交给一个高性价比模型3 秒就出结果了。如果这个脚本只是做一些常规的格式转换便宜模型的结果完全够用那多花的 27 秒和几十倍成本就是纯浪费。所以关键判断点是这个任务需不需要“理解意图”和“做决策”。需要就上强模型不需要就交给便宜模型。2.2 高性价比模型的真实水平与适用边界现在市面上的高性价比模型在模式化、有明确输入输出规范的任务上表现已经相当能打。比如按照给定的函数签名补全实现把一段代码从一种风格转成另一种风格根据模板生成配置文件批量重命名变量、调整缩进写单元测试的骨架这些任务的共同特征是目标明确、约束清晰、不需要太多创造性推理。你只要把要求写清楚便宜模型基本能稳定输出。但它的边界也很明显。一旦任务涉及跨文件的架构调整、模糊需求的理解、或者需要权衡多个方案的取舍便宜模型就容易“自信地胡说八道”。我踩过最典型的坑是让便宜模型去重构一个模块的依赖关系它直接把几个不相关的文件合并了理由是“这样看起来更简洁”。这就是缺乏全局判断力的表现。2.3 分层协作的成本账怎么算假设一个中型项目有 50 个文件需要做一次统一的重构每个文件平均 100 行代码。如果全用强模型每个文件需要约 2000 token 输入 1500 token 输出强模型按每百万 token 输入 15 元、输出 60 元算总成本约 50 × (2000×15 1500×60) / 1000000 50 × (0.03 0.09) 6 元如果采用分层方案强模型只做一次整体规划约 5000 token 输入 3000 token 输出成本约 0.25 元强模型抽查 5 个关键文件做审查约 0.6 元剩下 45 个文件交给便宜模型按强模型 1/20 的价格算约 0.27 元总成本约 1.1 元成本降到原来的不到五分之一而质量因为有强模型把关实际差距并不大。这个账算下来分层协作的性价比优势非常明显。注意这里的 token 数和价格只是示意实际会因模型提供商、任务复杂度、上下文长度而有很大差异。但量级上的差距是真实存在的。3. 工作流的核心架构怎么搭3.1 角色划分总工、工头、工人我把这套工作流拆成三个角色比单纯的两层更实用总工强模型负责需求理解、任务拆解、方案设计、关键代码审查、疑难问题诊断。它不直接写大量代码而是输出“施工图纸”——也就是详细的任务描述、接口定义、约束条件。工头中等模型或强模型的轻量调用负责把总工的图纸翻译成具体的、便宜模型能执行的指令。比如总工说“统一错误处理”工头要把它拆成“在每个 catch 块里调用 logger.error并把异常包装成 AppError 类型”这样的具体步骤。工人高性价比模型负责按照工头的指令执行具体的代码生成和修改。它不需要理解全局只需要把当前这个文件、这个函数改对就行。这个三层结构的好处是总工的调用次数最少工头的调用次数适中工人的调用次数最多成本自然就压下来了。3.2 任务拆解的粒度控制拆解粒度是这套工作流成败的关键。拆得太粗便宜模型理解不了拆得太细总工和工头的开销就上去了。我的经验是以“一个函数或一个独立文件”为基本单位。每个任务应该满足输入输出明确给定什么产出什么依赖关系清晰需要哪些上下文产出会被谁用可独立验证改完之后能单独跑测试或检查比如“给 user_service.py 里的 5 个函数补上参数校验”就是一个合适的粒度。而“优化整个项目的性能”就太粗了总工得先把它拆成十几个具体任务才能往下派。3.3 上下文传递的接口设计便宜模型最容易出问题的地方就是上下文不足。它不知道项目用的什么框架、什么编码规范、什么错误处理模式就容易按自己的习惯乱写。所以总工在拆解任务时必须同时输出一份上下文包包含项目技术栈和版本相关代码片段不是整个文件而是必要的部分编码规范和命名约定本次任务的约束条件期望的输出格式这份上下文包会跟着任务一起传给工人模型。我通常把它写成一个结构化的 Markdown 或 JSON方便程序解析和注入。3.4 质量门禁怎么设工人干完活不能直接算数得有检查机制。我设了三道门第一道自动检查。语法能不能过、测试跑不跑得通、lint 有没有报错。这些用脚本自动跑不过的直接打回。第二道工头复核。工头检查产出是否符合总工图纸的要求有没有偏离约束。这一步可以用中等模型做成本可控。第三道总工抽查。总工随机抽 10%-20% 的产出做深度审查重点看逻辑正确性和边界处理。发现问题就反馈到工头让工头调整指令重新派活。这三道门下来大部分低级错误在早期就被拦住了不会流到最终代码里。4. 实操落地从零搭一套可运行的工作流4.1 工具选型与基础环境这套工作流不依赖特定平台核心是能调 API 的 CLI 工具 一个编排脚本。我目前用的是编排层Python 脚本负责调用各模型 API、管理任务队列、执行检查CLI 工具用于在本地执行代码修改、跑测试、跑 lint版本控制Git每个任务在独立分支上执行方便回滚如果你不想自己写编排也可以用现成的 Agent 框架但我觉得自己写更可控而且能精确控制每个环节的成本。基础环境准备# 创建项目目录 mkdir model-workflow cd model-workflow # 初始化 Python 环境 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装依赖 pip install openai anthropic requests pyyaml提示API key 不要硬编码在脚本里用环境变量或配置文件管理。4.2 总工模块任务拆解与图纸生成总工模块的核心是一个精心设计的 prompt。我把它分成三段第一段角色设定。告诉模型它现在是总工负责规划和审查不直接写代码。第二段项目上下文。把项目结构、技术栈、关键文件列表喂进去。第三段任务描述。用自然语言描述本次要完成的目标。输出要求是结构化的 JSON包含任务列表、每个任务的上下文包、验收标准。import json from openai import OpenAI client OpenAI() def chief_engineer_plan(project_context, task_description): prompt f 你是一名资深技术总工负责把需求拆解成可执行的任务。 项目上下文 {project_context} 本次目标 {task_description} 请输出 JSON 格式的任务列表每个任务包含 - task_id: 唯一标识 - description: 具体要做什么 - files: 涉及的文件列表 - context: 执行该任务需要的上下文代码片段、规范等 - acceptance: 验收标准 - priority: 优先级 只输出 JSON不要有其他内容。 response client.chat.completions.create( modelgpt-4o, # 强模型 messages[{role: user, content: prompt}], temperature0.2 ) return json.loads(response.choices[0].message.content)这里 temperature 设低一点保证输出的稳定性。总工的任务是规划不需要创造性。4.3 工头模块指令细化与上下文打包工头拿到总工的任务列表后逐个细化。它的工作是把“统一错误处理”这种模糊描述翻译成便宜模型能直接执行的具体指令。def foreman_refine(task, project_context): prompt f 你是一名技术工头负责把总工的任务翻译成具体的执行指令。 总工任务 {json.dumps(task, ensure_asciiFalse)} 项目上下文 {project_context} 请输出一份详细的执行指令包含 - 具体要修改的文件和位置 - 每一步的操作说明 - 代码示例如果有参考模式 - 注意事项和禁忌 指令要足够具体让一个初级工程师能直接照着做。 response client.chat.completions.create( modelgpt-4o-mini, # 中等模型 messages[{role: user, content: prompt}], temperature0.3 ) return response.choices[0].message.content工头用中等模型就够了因为它的工作是基于总工已经拆好的框架做细化不需要太强的推理能力。4.4 工人模块代码生成与批量执行工人模块是调用最频繁的所以必须用便宜模型。它的输入是工头打包好的指令和上下文输出是具体的代码修改。def worker_execute(instruction, file_content, file_path): prompt f 你是一名执行工程师请严格按照以下指令修改代码。 指令 {instruction} 当前文件 {file_path} 的内容{file_content}请输出修改后的完整文件内容。只输出代码不要有其他说明。 response client.chat.completions.create( modelgpt-4o-mini, # 便宜模型 messages[{role: user, content: prompt}], temperature0.1 ) return response.choices[0].message.contenttemperature 设到 0.1尽量让输出稳定可预测。工人的任务不需要创意需要的是准确执行。4.5 质量检查与反馈闭环每个任务执行完后自动跑检查import subprocess def run_checks(file_path): results {} # 语法检查 result subprocess.run( [python, -m, py_compile, file_path], capture_outputTrue, textTrue ) results[syntax] result.returncode 0 # lint 检查 result subprocess.run( [pylint, file_path, --disableall, --enableE], capture_outputTrue, textTrue ) results[lint] result.returncode 0 # 测试如果有对应测试文件 test_file file_path.replace(.py, _test.py) if os.path.exists(test_file): result subprocess.run( [pytest, test_file, -q], capture_outputTrue, textTrue ) results[test] result.returncode 0 return results检查不通过的任务把错误信息反馈给工头让工头调整指令后重新派给工人。这个循环最多跑三次三次还不过就升级给总工处理。4.6 完整流程串联把上面几个模块串起来主流程大概长这样def run_workflow(project_context, task_description): # 1. 总工规划 tasks chief_engineer_plan(project_context, task_description) # 2. 逐个任务处理 for task in tasks: # 工头细化 instruction foreman_refine(task, project_context) # 工人执行 for file_path in task[files]: file_content read_file(file_path) new_content worker_execute(instruction, file_content, file_path) write_file(file_path, new_content) # 质量检查 checks run_checks(file_path) if not all(checks.values()): # 反馈重试逻辑 handle_failure(task, file_path, checks) # 3. 总工抽查 sample_tasks random.sample(tasks, max(1, len(tasks) // 5)) for task in sample_tasks: review_result chief_engineer_review(task) if not review_result[passed]: # 打回重做 pass这套流程跑下来一个 50 文件的重构任务总工调用 1 次工头调用约 50 次工人调用约 50-150 次含重试总成本能控制在个位数。5. 踩过的坑与排查技巧实录5.1 便宜模型“自作聪明”怎么办这是最常见的问题。便宜模型有时候会“优化”你的代码比如把显式的类型检查删掉理由是“Python 是动态类型”。或者把日志语句合并理由是“减少重复”。我的应对方法是在指令里明确列出禁止事项。工头细化指令时必须包含一段“不要做”的清单不要删除任何现有的错误处理不要改变函数签名不要合并或拆分文件不要引入新的依赖不要修改与任务无关的代码这段清单直接写进 prompt能挡掉大部分自作聪明的行为。5.2 上下文超长导致成本失控有时候一个文件几千行全塞给工人模型token 消耗巨大。我的做法是只传相关片段。工头在细化指令时要标注出需要修改的具体行号范围只把那个范围前后各 50 行传给工人。如果修改涉及多个不连续的区域就拆成多个子任务分别处理。这样既省 token又降低模型理解难度。5.3 任务拆解粒度不当的典型症状拆得太粗的症状工人模型输出一堆无关代码或者直接说“我无法完成这个任务”。拆得太细的症状总工和工头的调用次数暴增成本反而上去了而且任务之间的依赖关系变得复杂容易乱序执行。判断标准很简单如果一个任务需要工人模型做超过 3 个独立的决策就说明拆得不够细如果两个任务之间需要频繁传递中间状态就说明拆得太细了。5.4 常见问题速查表问题现象可能原因排查方法解决措施工人输出与预期完全不符上下文不足或指令模糊检查传给工人的 prompt让工头补充上下文和示例代码语法错误率高模型能力不足或 temperature 过高降低 temperature 到 0.1换更强的模型或增加重试任务执行顺序混乱依赖关系未标注检查任务列表的依赖字段在总工 prompt 里要求标注依赖成本超出预期上下文过长或重试过多统计各模型 token 消耗精简上下文限制重试次数总工规划不合理项目上下文不完整检查传给总工的项目信息补充项目结构和技术栈说明检查环节误报lint 规则太严或测试不稳定查看具体报错信息调整检查规则或跳过不稳定测试5.5 几个提升稳定性的实操心得心得一给工人模型提供“参考实现”。如果项目里已经有类似的代码模式把它作为示例放进上下文工人模型的输出质量会明显提升。比如你要统一错误处理就把项目里写得最好的那个错误处理函数贴进去当模板。心得二总工的审查要聚焦。总工抽查时不要泛泛地看而是带着具体问题去查边界条件处理了吗异常路径覆盖了吗与现有代码风格一致吗带着问题查效率高很多。心得三保留完整的执行日志。每个任务的输入、输出、检查结果、重试次数都记下来。出问题的时候翻日志比重新跑一遍快得多。而且日志积累多了你能看出哪些类型的任务容易失败提前优化。心得四先用小批量验证。不要一上来就跑全量任务。先挑 3-5 个代表性文件跑一遍看看总工的规划合不合理、工头的指令够不够具体、工人的输出能不能过检查。验证通过再放大规模。心得五版本控制是最后的防线。每个任务在独立分支上执行出问题直接丢弃分支。我习惯在任务开始前打一个 tag任务完成后对比 diff确认无误再合并。6. 这套工作流的扩展玩法6.1 接入 CI/CD 做自动化代码审查把这套工作流接到 CI 流程里每次提交代码时自动触发总工审查。总工检查代码是否符合项目规范、有没有明显的逻辑问题、测试覆盖是否充分。审查结果作为评论发到 PR 上人工只需要看总工的审查意见不用逐行读代码。这个玩法的关键是控制总工的调用频率。不是每次提交都跑全量审查而是只审查变更的文件而且可以设置阈值比如变更超过 50 行才触发。6.2 多总工并行处理不同模块如果项目足够大可以按模块拆分每个模块配一个总工。比如前端总工、后端总工、数据层总工各自负责自己领域的任务拆解和审查。工头和工人层可以共享也可以独立。这样做的好处是每个总工的上下文更聚焦规划质量更高。代价是总工之间的协调需要额外机制比如接口定义要提前对齐。6.3 结合本地模型进一步降本如果对数据隐私有要求或者想进一步压缩成本可以把工人层换成本地部署的小模型。现在一些开源模型在代码补全和模式化任务上已经够用了。总工和工头仍然用云端强模型工人用本地模型成本能再降一个数量级。不过本地模型的部署和维护有额外成本而且输出稳定性可能不如云端 API。适合对成本极度敏感、且有一定运维能力的团队。6.4 任务模板库的积累跑多了之后你会发现很多任务是重复的补测试、改配置、统一日志格式、迁移 API 调用方式。把这些常见任务的工头指令模板化下次直接套用能省掉工头细化这一步进一步降本提速。我目前积累了二十多个模板覆盖了日常开发中 80% 的重复性任务。新任务来了先匹配模板匹配不上再走完整的工头细化流程。这套工作流我用了大半年最大的体会是不要追求全自动要追求“人在关键节点上”。总工审查、质量门禁、最终合并这三个节点必须有人参与。模型再强也不能替你做最终决策。把重复劳动交给便宜模型把判断和决策留给自己和强模型这才是这套工作流真正的价值所在。