LegalOn Codex 案例：按任务分配模型，控制开发成本

LegalOn 的 Codex 成本管理案例，按开发任务的复杂度分配 GPT-6 Luna、GPT-6.1 Sol 和 GPT-6 Astra，并按业务阶段设置预算。它提供了一个工程团队扩大 AI 使用后，怎样控制支出、同时观察交付质量的参考。

案例来源与时间

• OpenAI 官方案例发布：2026 年 10 月 8 日；本站核对：2026 年 10 月 13 日。
• 本文为官方案例的中文摘要与本站实施建议。成本和效率为客户披露，本站未复测。
• 阅读 LegalOn 官方案例。

官方披露的模型分工

团队用 Luna 执行要求清楚的实现任务，用 Sol 处理常规设计、分析和文档，用 Astra 处理复杂设计与协调。模型分工之外，还调整了 Fast 模式使用与部门、个人预算，并为新业务保留较大的探索空间。

官方报告，相比此前以 GPT-5.5 为主的方案，估算每日费用减少约 65%，开发速度保持。这个结果包含多项管理措施，不能归因于某个模型单独降价。团队计划按功能发布衡量 AI 投入与客户价值；该衡量流程仍在建设中。

开发团队怎样试用这套思路

以下为本站实施建议，并非 LegalOn 的内部制度。

先从一组真实工单开始，统一交付标准。每张工单记录模型调用、失败重试、人工审阅时间和修复时间。完成后比较合格交付成本，而不是只比较 Token 单价。

如果一个廉价模型反复失败，后续升级时应提供已查明的原因、文件位置和检查结果，让更强模型继续解决明确问题。对于需求不完整的任务，先澄清需求往往比直接增加推理预算更有用。

用什么指标判断降本是否值得

建议至少一起观察：每项合格交付的总费用、首次验收通过率、上线后缺陷、从开始到可发布的时间，以及维护者理解代码的难度。预算管理还应允许负责人处理紧急任务和新业务探索。

费用节省与商业回报属于不同指标。原文的 65% 是估算日成本变化，不能写成利润增长或通用于每个团队的收益保证。

继续选型

在模型目录比较 GPT-6 系列，或阅读cubic 的 Claude 代码审查案例。