分享一个最近的实践：让 Codex、Gemini、GLM 三个模型协同做 AI-assisted 软件工程。

核心思路不是"谁最强就用谁"，而是给每个模型定角色、定边界、定流程。

三个角色的分工：

Codex -- 指挥官、规划者、审计员。最强推理能力，拥有产品判断权、架构保护权、任务拆解权和最终验收权。但它不写生产代码，只做决策和审查。

Gemini -- 快速执行者和审核员。推理能力仅次于 Codex，写代码和报告都很快。但配额有限，所以主要用在速度敏感、高杠杆的任务上：架构审查、复杂调试、高风险实现。配额紧张时降级到轻量变体做低风险审核。

GLM -- 耐久执行者。推理能力弱于 Gemini，速度也慢，但订阅制无配额限制。适合长线实现、机械性重构、验证脚本、补全和回填。Gemini 配额耗尽时，GLM 兜底。

任务生命周期是严格的链式流转：

Codex 写任务包 -> Gemini/GLM 执行 -> 工人写报告包 -> Codex 审计 -> 验收或退回重做。

没有 Codex 验收，任何阶段都不算完成。GLM 不能在等 Gemini 审查时动手。两个工人可以并行，但前提是 Codex 显式指定了不重叠的文件所有权 -- 否则默认串行。

每个任务包有固定的结构：目标、非目标、目标文件、禁止编辑文件、层级归属、验收标准、验证命令。每个报告包必须提供行为证据，不能只说"works as expected"，要有具体命令、实际输出、截图路径或测试结果。弱证据直接驳回。

我还在协议里写进了四条 Boris Cherny 风格的操作定律：观察隐性需求而非只听显性请求；为半年后的更强模型做简单设计；同一个错误犯两次就必须沉淀为规则或检查脚本；每个实现任务必须给工人一条可关闭的验证路径。

多模型协作的本质不是选好模型，是设计好规则。模型能力决定天花板，协议治理决定你能不能摸到天花板。