上周接了个库存预警后台的活儿，需求方给的原始描述就三行字，还带着两个错别字。要是放在半年前，我会自己憋着写PRD、写代码、再测试，整套下来三天起步。这次我换了打法：把 Claude、Codex、Grok 三个模型一起拉进一条流水线，上午拆需求，下午出代码，晚上走查修正，第二天中午就交付了可运行的初版。说句实话，这三个工具单独用我都吐槽过，但按“需求翻译—工程落地—逆向审查”的节奏串起来之后，确实是王炸级的体验。

这篇文章不聊抽象概念，只讲我实际跑通的协作流程、中间踩过的坑，以及为什么这三个模型搭配起来比任何单一“最强模型”都顺手。如果你平时也在用 AI 写代码、做项目，这套分工逻辑可以直接抄走。

1. 先是踩坑记录：让同一个模型干所有事，效率比想象低得多

很多人拿到一个好用的模型，第一反应是“那我就什么都让它干”。这种想法特别自然，但也是效率陷阱的起点。

1.1 “全能模型”的假象：什么都会，等于什么都不精

我之前有一段时间重度依赖 Claude，觉得它写文档、写代码、分析数据都能干，属于六边形战士。实际用下来发现，它最稳定的强项是“文本工程”：需求澄清、接口设计、方案对比、文档生成，这些事情它做得又快又好。但一旦进入真正的编码落地，问题就来了。

比如我让 Claude 直接生成一个带 Redis 连接池的完整服务端模块，它确实能写出来，代码结构也漂亮，注释也齐全。可真正跑起来的时候，缺少的就是“编译-运行-报错-修复”这个反馈闭环。它没有真实执行环境，只能凭经验和模式猜测。于是我陷入一种循环：把代码粘到编辑器，运行，看到报错，把报错贴回去，让它改，再运行，再贴。一个不复杂的模块，来回折腾了六七轮。

这不是 Claude 笨，是任务性质不对。它适合把“模糊的事情变清楚”，但不太适合在“已经清楚的事情上做高频迭代试错”。

1.2 单独用 Codex 的另一种失败：代码能跑，需求错位

Codex 给我的第一印象是“代码生成速度快得离谱”。给它明确的模块说明，它能在几分钟内生成结构工整、可读性强的代码片段，尤其是常见框架里的 CRUD、状态管理、数据转换这些脏活，它熟练得像一个干了很多年的熟手。

但问题出在需求端。Codex 默认不追问。有一次我给它一个模糊需求：“做个用户签到功能，连续签到给奖励。”它直接按照最常见方案生成了一套连续签到实现，思路没毛病，代码也能跑。但实际业务里，产品经理想要的是“自然周内凑满 5 天就算连续”，而不是“必须一天不落才算连续”。需求方看到成品后直接摇头。代码没问题，错的是需求理解。

这个教训让我意识到：Codex 是极优秀的施工队，但它不会自己画图纸。你把错误的图纸给它，它会盖出一栋漂亮但不被需要的房子。

1.3 单独用 Grok 的局限：能质疑，但工程连续性弱

Grok 在很多人印象里是个“聊天信息流助手”，但在技术场景里它的长处是“敢说、肯挑刺”。我拿代码给它做走查，它会直说这里边界没处理、那里依赖了新版本可能踩坑。这种逆向视角很难得，因为 Claude 和 Codex 都倾向于顺着你的话往下写，只有 Grok 会先质疑前提。

但让它从头到尾维护一个工程，也不行。它回答偏碎片化，像一位很聪明但课间才出现的顾问，每次都能指出问题，却很难持续记住两天前我们约定过的变量命名和模块边界。时间一长，它自己都会忘记最初的技术选型。

1.4 三个一起用之后的第一感受

后来我开始尝试分工，用 Claude 做前置设计，用 Codex 做代码落地，用 Grok 做最终走查，结果一天之内就感受到了变化：不再有“某个模型硬扛所有事”的难受劲儿，每个模型都待在它最擅长的那一格里。更妙的是，三者之间的“不信任感”反而成了质量保障。Claude 写出的方案，Codex 会老老实实执行；Codex 写出的代码，Grok 会毫不客气地拆台。而我坐在中间，只需要在它们互相质疑的时候做最终决策。

2. 分工表：把任务按“人设”分给三个模型

这套打法不是随便分的。我试过好几轮才稳定下来，每个人设背后都有明确的原因和对应的提示词策略。

2.1 Claude 负责“需求翻译官”

Claude 最核心的能力，不是“聪明”，而是“把话掰开揉碎”。需求方说的话往往是立场、情绪和模糊期望的混合物，Claude 擅长把这里面隐含的假设一条条挑出来。

我现在的固定做法是：把需求方的原始描述原封不动丢给 Claude，然后加一句固定指令：

请把上面的需求描述拆解为“已确认信息”和“待确认问题”两个列表。待确认问题必须是能用“是/否”或具体选项回答的，禁止开放性问题。每个问题后面附上你的默认建议，供需求方快速拍板。

这个提示词的效果立竿见影。因为有了默认建议，需求方不用绞尽脑汁描述，只需要说“对”或者“不对”。决策成本降到最低。

Claude 产出的是一份结构良好的需求澄清文档，包括功能边界、验收标准、角色权限、数据字段清单。这份文档就是后面所有工作的地基。

2.2 Codex 负责“落地施工队”

Codex 的定位非常单纯：只负责把清晰的规格转成可运行的代码。这意味着我给它输入的时候，就必须是已经澄清好的内容。

给 Codex 的任务包有固定结构：项目背景一句话、技术栈限定、模块边界、输入输出定义、验收标准、禁止事项。其中“禁止事项”非常重要，能拦住很多自由发挥。比如：

技术栈固定为 Python 3.11 + FastAPI + PostgreSQL，禁止引入额外重型框架。数据模型严格以接口契约为准，不得新增字段。分页参数必须是 page 和 page_size，不能改成 offset 和 limit。

Codex 收到这种包之后，生成的代码基本不太需要大改。它不再是一个“理解需求”的角色，而是一个“执行规范”的角色。让擅长执行的去做执行，效果天差地别。

2.3 Grok 负责“逆向审查员”

Grok 的任务说难也难，说简单也简单：它不需要写代码，只需要挑问题。我通常把 Codex 生成的代码和 Claude 写的接口契约一起发给它，然后附上这样的指令：

你是一位代码审查员，请只输出问题，不要输出夸奖。按 P0/P1/P2 标注优先级。P0 是会导致线上事故或数据错误的问题，P1 是潜在风险，P2 是风格与可维护性建议。另外，请特别关注两个点：时间与时区处理、外部服务异常时的降级方案。

真实体验是，Grok 找出的问题里大概三分之一是真问题，三分之一是它过度敏感，还有三分之一是我确实没想到但在当前项目里不致命的隐患。但就算只有三分之一，也足够值回票钱。

2.4 判断依据清单：这个任务该给谁

我给自己整理了一份简单清单，遇到任务先对照：

• 任务目标是把模糊描述变清晰，产出文档或方案 → 给 Claude
• 任务目标是将清晰规格变成可运行代码，且边界明确 → 给 Codex
• 任务目标是验证已有东西有没有漏洞、风险、被忽略的角落 → 给 Grok
• 任务需要连续多天维护同一个工程记忆 → 不要交给任何单一模型，要借助交接文档

这套判断依据救过我很多次。最典型的反面案例是：我一度用 Claude 做代码走查，它确实也能发现问题，但它在提建议时会自动帮我改代码，改出来的东西风格和原工程不一致，反而添乱。术业有专攻，审查这种“带着敌意看成果”的活儿，交给 Grok 更顺手。

3. 三个模型之间的“交接文档”，是整个工作流的心脏

既然三个模型不能直接对话，那中间人是“交接文档”。这听起来很朴素，但实际操作中，文档写得好不好，直接决定这套流水线是顺滑还是卡壳。

3.1 为什么模型之间不能直接对话：上下文隔离的现实

很多人天然以为“Claude 生成的东西可以直接喂给 Codex”，但实际不是这样的。每个模型的上下文是独立的，会话历史是隔离的。你可以把 Claude 的输出复制粘贴给 Codex，但这中间缺少的恰恰是“为什么要这样做”的上下文。

直接复制粘贴的后果是：Codex 只看到结论，看不到取舍过程。比如 Claude 在设计接口时，特意把某个字段放在了扩展信息里而没放在主表里，这是为了应对未来多业态扩展。但 Codex 只看到主表字段列表，它可能觉得这个字段多余，于是“优化”掉了。这个字段在短期运行里确实没用，但三个月后业态扩展时就麻烦了。

所以需要一份“交接文档”，把结论背后的理由、约束和边界都记录下来。

3.2 交接文档的字段模板

我目前使用的模板长这样，基本每次新建项目都会复制一份：

# 项目交接文档（版本：V1.2） ## 项目目标（不超过3句话） 一句话说明做什么，两句话说明做到什么程度算完成。 ## 范围与边界 已确定要做的事： - 列表 明确不做的事： - 列表 ## 已完成项 - 需求澄清完成，验收标准见文档 X - 接口契约定稿，版本 V1.2 ## 待办项 - 模块 A：待 Codex 生成 - 模块 B：待 Grok 审查 ## 关键决策与理由 - 决策1：数据导入采用增量模式，理由是不想每次全量重算。 - 决策2：不用消息队列，理由是目前量级用不上，避免复杂度。 ## 已知风险 - 风险1：Excel 列头偶尔带空格，需要做归一化处理。 - 风险2：邮件服务商对单日发送量有限制。 ## 禁止触碰项 - 数据库表名不要改，现有命名规则已经用于报表映射。 - 安全库存公式不要改动，业务方明确要求。 ## 验收标准 - 所有预警记录在数据更新后 10 分钟内生成。 - 邮件通知送达率不低于 99%。

这个模板看着不难，但真正起作用的是“关键决策与理由”和“禁止触碰项”。这两个字段能避免模型在后续步骤里拿着合理理由做出错误改动。

3.3 一次交接失败的复盘

我第一次跑这套流程时，偷懒没写“关键决策与理由”，只在文档里写了“已完成接口设计 V1.0”。结果 Codex 生成代码时，重新实现了 Claude 已经讨论过并主动放弃的一套方案，浪费了两个小时。

为什么？因为 Claude 在设计时纠结过“预警计算放数据库存储过程还是放应用层”，最后决定放应用层，理由是这个项目的数据库是 ERP 侧托管，不能随便加存储过程。但 Codex 没看到这段取舍，它觉得存储过程性能更好，“自作聪明”绕回了老路。

从那以后，我坚持在交接文档里写清楚“被否掉的方案”以及“否决原因”。给模型们立规矩：文档里没写的东西，默认不要自己发明。

3.4 几条实用的交接写作规则

写作上有几个小技巧：

• 只写结论，不写思考过程，思考过程放“关键决策”里单独记录，防止干扰执行。
• 用“验收标准”代替“实现建议”。比如写“预警邮件必须在数据更新后 10 分钟内发出”，而不是“建议在发邮件前先做数据校验”。前者是目标，后者是指导，两者对模型的约束力完全不同。
• 文档长度控制在 200 行以内。太长模型会丢掉重点，太短又不够约束。超过 200 行就该拆分文档，通过“引用主文档 + 增量说明”来控制上下文噪音。

这套文档实践了几轮之后，我还有一个意外收获：哪怕后期不用 AI，完全靠人接手，交接文档的存在也让协作变得清晰很多。

4. 实战记录：24 小时完成一个库存预警后台

光讲方法论容易飘，我拿最近一个实际项目复盘完整的协作链路。项目代号叫“模拟项目 X”，本质是一个内部库存预警后台，不算复杂，但足够展示流程细节。

4.1 项目背景和最初需求

需求方是某零售团队的运营负责人，原始描述是：

“搞一个库存预警后台，数据来源是 ERP 导出的 Excel，每天更新，低于安全库存的显示红牌，自动给店长发邮件提醒。”

就这么一段话，缺少的信息多到数不清：安全库存的规则是什么？按单店安全库存还是按全局库存？红牌在什么入口展示？邮件提醒频率是每天汇总一次还是实时触发？店长邮箱谁来维护？我直接把这段话连同澄清指令发给 Claude。

4.2 第一棒：Claude 输出需求清单和接口契约

Claude 干活很快，半小时内产出了一份需求澄清文档，列出了 17 个待确认问题，每个都附了默认建议。需求方大概花了十五分钟回答完，其中真正需要改默认建议的只有三处：安全库存需要支持按品类差异化配置、预警级别分“警告”和“紧急”两档、邮件只发给店长不带抄送。

接着 Claude 产出了接口契约，明确模块边界。

模块清单： - 数据导入模块：读取 ERP Excel，清洗并写入库存表 - 预警计算模块：按安全库存配置计算状态并生成预警记录 - 通知模块：按预警记录发送邮件 - 看板展示模块：提供查询与红牌展示接口

接口契约里最核心的表结构如下，我用简化的字段来描述：

库存快照表 - id - sku - store_id（门店维度） - current_stock（当前库存） - safe_stock（安全库存） - stock_date（数据日期） - updated_at 预警记录表 - id - sku - store_id - level（warning / urgent） - status（pending / sent） - created_at - sent_at

这个阶段给我最大的感受是：以前自己写需求文档会漏掉大量隐含假设，Claude 至少能把问题摊开摆到桌面上，人类只需要做判断题。

4.3 第二棒：Codex 分模块生成代码

我把交接文档和契约发给 Codex，按模块一个一个生成。这里有个经验：不要一次性把整个项目丢给 Codex，让它按单模块生成，每生成完一个模块，立刻人工过一遍再进入下一个。这样可以尽早发现问题。

以预警计算模块为例，Codex 生成的简化版核心代码大致是这个样子：

def calculate_alerts(items, safe_stock_map): alerts = [] for item in items: current = item["current_stock"] safe = safe_stock_map.get(item["sku"], 0) if current < safe: gap = safe - current level = "urgent" if current < safe * 0.5 else "warning" alerts.append({ "sku": item["sku"], "store_id": item["store_id"], "current_stock": current, "safe_stock": safe, "gap": gap, "level": level, }) return alerts

代码本身不复杂，但它把“预警级别”的判定逻辑落到了具体参数上，紧急档的阈值是后来和需求方确认过的。把规则写清楚之后，后续接邮件模板、看板展示都很顺。

这里我要补充一句：Codex 生成的代码不是直接就能上生产的，至少要进行一次代码走查和安全检查。但它把最花时间的脏活干完了，剩下的是我来确认边界条件。

4.4 第三棒：Grok 审查出的三个隐患

Codex 完成所有模块之后，我把完整代码和接口契约一起发给 Grok。它最终产出了一份审查意见，其中最关键的三个问题值得记录。

一是时区问题。Excel 里的日期没有时区信息，邮件发送时间如果按服务器本地时间处理，跨区门店可能在深夜收到“紧急预警”邮件。解决方案很简单：统一按门店所在时区计算营业时间，非营业时间不发送即时通知，转为次日汇总。

二是邮件发送失败的重试机制。Codex 生成的代码里，邮件发送失败只打了日志，没有重试。Grok 指出，SMTP 服务不稳定时，预警通知发不出去等同于预警系统没做。补了一个简单的重试队列，失败三次后再标记异常。

三是大批量数据的内存风险。如果 ERP 导出的 Excel 有几十万行，一次性全量读入内存再计算，很可能把内存打爆。需要改成流式读取，分批写入数据库再计算。

这三个问题，单个看都不大，但都藏在最容易被忽略的角落。如果是人肉 review，大概率能发现，但需要额外的时间成本。Grok 把这一步压缩到了十分钟内。

4.5 我在中间做的最小干预

整套流程走下来，我发现自己做的事非常少但很关键：合并各模块代码、统一命名规范、把接口文档和数据库脚本对了一遍版本号、跑通一条端到端测试链路。全程下来，从需求澄清到交付初版，用了不到一个工作日。

对比以前，这样一个项目我一个人从零写至少需要三到四天。多出来的时间不是被偷走了，而是被分配到了更值得关注的决策上，比如和需求方确认判定规则、评估重试策略是否合理。这些才是人真正不可替代的部分。

5. 这套组合真正的边界：什么时候别用

任何工具组合都有适用范围。用多了之后，我慢慢摸清了它的边界。

5.1 探索型创新项目：容易产出“平庸的正确”

如果一个项目还在探索期，连需求方自己都不知道想要什么，比如“试试做一个社交裂变的新玩法”，这时候三个模型的组合反而可能坏事。Claude 会把模糊需求梳理得很顺，Codex 会把方案实现得很漂亮，Grok 会找补一堆边界问题，最终产出一个逻辑自洽、技术上没毛病，但完全没有惊喜的普通方案。

模型组合擅长的是“在明确边界内做到极致”，而不是“从无到有地打破边界”。真正的创新探索，还是需要人先去撞墙，找到那个说不清但有意思的方向，再让模型上场。

5.2 涉及高度敏感数据的场景：不要赌

库存预警这个项目里的数据是模拟脱敏过的，所以可以放心交给模型。但如果是用户真实身份信息、财务数据、医疗数据这类内容，我不建议放进任何外部模型，哪怕做了匿名化处理也一样。原因很简单：你无法控制数据在模型侧的留存和使用方式。这不是技术能力问题，是风险底线问题。

如果确实需要在受限环境里用 AI 辅助开发，我建议只让模型处理数据结构定义，真实数据只在本地脱敏后使用，同时裁剪掉所有可识别字段。

5.3 长期维护的老项目：上下文继承问题很致命

这套组合更擅长“从 0 到 1”的新项目启动期，而不是“在几万行老代码上打补丁”的维护期。模型对工程没有持久记忆，每次会话都要重新读一遍上下文。老项目里的隐含约定往往写在不只一个文件里，交接文档难以覆盖所有细节。让模型改老代码，很容易改出“局部正确、全局破坏”的副作用。

如果是维护老项目，我更推荐的做法是：让模型做代码解读和影响面分析，而不是直接让它改代码。先把改动方案写成人能看懂的草案，再由人工落地，这样更稳。

5.4 成本问题：token 消耗比想象中快

三个模型一起上，不是免费的午餐。每次交接文档全文复制粘贴，加上多轮代码走查，token 消耗量比单独用一个模型至少翻两三倍。如果是个人项目或预算敏感的小团队，需要提前评估成本，别等项目做到一半才发现账单超标。

我的省 token 经验是：交接文档精简到 200 行以内，代码走查时只发“核心代码文件 + 重点模块”，不要一次性把所有代码全贴进去。按模块走查，比整体走查省得多，效果也更聚焦。

最后分享一点个人体会

每次开工前，我会先花十五分钟把交接文档的头部写好，哪怕今天只有我一个人用模型也照写。这个习惯帮我理清了很多思路：写项目目标的那三句话，本身就是最好的需求澄清；写“禁止触碰项”的时候，我相当于把过去踩过的坑提前标记了一遍。

三个模型各司其职这套打法，说破天也就是“让专业的人做专业的事”。模型本身再强，如果被放错了位置，效果可能还不如一个平庸但专注的工具。反而是这种朴素的协作分工，能让每一分算力都花在刀刃上。下次再看到所谓“单模型王炸”的评测文章，你可以试着想想：这个模型最适合哪段流程？剩下的流程又该交给谁？想明白了这件事，你的项目就已经赢了一半。