四个模型各司其职：日志揭示的AI分工实践

大多数开发者习惯找一个模型包揽所有工作。但当一个模型既要干活又要检查自己的产出时，问题就来了——它恰恰最不擅长审视自己的盲区。本文作者团队几个月前开始尝试让不同模型各司其职，并用一份持续记录的台账，量化了这场分工实验的真实效果。

分工架构：谁负责什么

这套工作流的分配逻辑很清晰：Claude 负责规划和检查，Grok 负责对 Claude 刚写出的内容发起"攻击"，Codex 构建大型模块，而团队自研的路由器 Tīrtha 则接手常规性的搭建任务。

设计初衷并不复杂——订阅额度总是撞上限，而让同一个模型既生产又自检，等于把最薄弱的环节放在了质量把关的位置上。把职责拆开，既缓解了额度压力，也让每个模型发挥各自的长处。

Tīrtha 是作者团队自研的模型路由器，其名称取自梵语，意为“渡口”或“通道”。在这套工作流中，它并不直接参与代码生成或审查，而是根据任务类型将请求分发给不同的后端模型。路由器本身通常不包含模型权重，而是依赖规则或轻量分类器决定“谁来做”。这种设计使得团队可以在不改变上层调用方式的前提下，灵活替换或增减底层模型。Tīrtha 接手常规搭建任务，正是利用其路由能力将简单、重复性工作导向低成本模型，从而为高成本模型保留额度。

Grok：便宜的第二意见

从 9 月 25 日到 10 月 17 日，Grok 共提出了 519 条发现。人工复核后，309 条站得住脚，其中 207 条是 Claude 初稿中完全没有的内容，59 条属于关键且全新的问题。

它当然也会出错：28 条发现纯属误报，另有 30 条错误源于任务简报本身缺失了信息。但按每次审查中位成本约 0.021 美元计算（最近 30 次共 2.32 美元），一个偶尔出错的审查者依然物超所值。

Grok 便宜的原因在于它从不接触完整代码库。它只拿到一份约 2300 token 的简短简报——包含主张和证据——任务就是"拆台"。作者举了一个当天的例子：Claude 构建的网关修复通过了 55 项测试，而一次花费 17 美分的 Grok 攻击发现了三处会导致正确答案被清空的情况。三处都是真实问题，现已全部修复。

中位成本（median cost）是指将所有单次审查成本按大小排列后处于中间位置的值，而非平均值。与平均值相比，中位数对极端值不敏感，能更稳健地反映“典型一次审查花多少钱”。文中提到 Grok 单次审查中位成本约 0.021 美元，意味着有一半的审查花费低于此数、一半高于此数。这种度量方式在成本波动较大的场景下尤其有用，可避免少数昂贵运行拉高整体印象。

Codex：读得最深的那一个

Codex 提出的发现少得多，只有 50 条，但 39 条成立，33 条对 Claude 而言是新的。最有价值的一条是：它发现线上网关在某些请求下根本没有写入用量记录，导致计费完全失明。这个问题不读代码是绝对看不到的。

深度是有代价的。Codex 单次运行中位数消耗约 84000 token，9 月 22 日至 10 月 14 日之间触发了 7 次用量上限，其中两次导致整日无法使用。每交给 Codex 一个常规任务，就消耗了留给难题的窗口额度。

Token 消耗量是衡量大模型使用成本的核心指标之一。模型处理文本时，输入和输出都会被切分为 token（约等于一个英文单词或半个汉字），每次调用消耗的 token 总数直接决定费用和速率限制的占用。Codex 单次运行中位消耗约 84000 token，远高于 Grok 的约 2300 token 简报，这解释了它为何更容易触发用量上限。订阅制服务通常按时间窗口（如每 5 小时或每日）限制 token 总量，深度代码阅读会快速耗尽窗口额度，导致后续无法处理难题。

Tīrtha：常规搭建的新尝试

这一部分作者坦承所知有限。Tīrtha 本周通过 OpenCode 接手了第一个真实任务，此前修复了一个工具调用以纯文本返回的 bug（修复前 0/2 会话可用，修复后 3/3 可用）。目前这只是个冒烟测试，真正的成绩单需要数周的真实任务才能积累。

背后的赌注很直接：让 Codex 只做非它不可的事，把常规搭建交给便宜且经过校验的构建器，从而延长订阅的使用寿命。团队在夏天曾跑过类似版本——一个免费的廉价层完成了 52 个舰队任务中的 36 个，且 6 月到 8 月没有出现 Codex 限额错误。时间线吻合，但同期还有太多其他变量变化，因此不能称之为证明。

尚无法证明的事

作者列出的局限同样值得关注：

• 整个团队是否优于 Claude 单打独斗，测试已搭建但尚未运行。
• 把搭建工作迁移到 Tīrtha 是否真能延长订阅寿命，将从现在开始测量。
• 台账本身存在缺陷：746 条记录中大部分是从已保存的审查中事后补录的，且由 Claude 判断哪些发现已存在于自己的初稿中。让模型评判自己的盲区，恰恰是 Grok 会揪住不放的那类问题。

这种坦诚本身就是这套方法的一部分——分工的价值不在于证明某个模型更强，而在于用可量化的方式看清每个环节的真实贡献与成本。作者最后抛出的问题也指向同一方向：你是一个模型包打天下，还是各给一份差事？有没有人测量过，一个便宜的审查者抓到的真问题，是否真的超过它误报带来的成本？

冒烟测试（smoke test）是软件工程中的术语，指在正式全面测试之前，用最少的操作快速验证系统核心功能是否基本可用。它不追求覆盖所有边界条件，只回答“能不能跑起来”。文中 Tīrtha 接手第一个真实任务、修复前后会话可用数从 0/2 变为 3/3，即属于冒烟测试范畴。冒烟测试通过仅代表系统未完全失效，距离证明长期稳定性和效率仍需数周的真实任务数据积累。