LegalOn 将 Codex 成本减半，开发速度不减

2026年10月8日，OpenAI 发布了一则客户案例：面向全球提供“Professional AI”的 LegalOn Technologies，在把 Codex 嵌入研发流程之后，通过按任务匹配模型、按业务阶段分配预算，将预估的每日成本降低了 65%，成熟业务领域的成本降低了 20%，而开发速度没有下降。这个案例的价值不在于某个折扣数字，而在于它回答了智能体编程进入规模化阶段后最现实的问题：当每个工程师都能无限调用最强模型时，账单会先于收益失控，而一刀切的限额又会把已经拿到的生产力白白丢掉。 故事的起点很典型。LegalOn 起初让开发者不限量地使用主力模型 GPT-5.5 的 Fast 模式，并把它从设计、实现推广到日常工作的各个环节。公司在这个阶段做的是一场大规模的实验：哪些工作交给人，哪些工作交给 AI，边界在哪里，都是在真实使用中摸索出来的。这种“先放开、后收敛”的节奏是合理的，因为在不了解模型能力边界之前就设限，等于在没有数据的情况下做决策。但随之而来的问题同样清晰：持续无上限地使用高性能模型，必然会超出年度预算。成本控制于是从一个财务问题，变成了一个必须由工程组织自己解决的产品问题。

LegalOn 的解法分成两层。第一层是模型选择的方法论。公司内部名为 AID CoE（AI 驱动开发卓越中心）的团队，负责制定模型选择指南，同时测试并持续监控各个模型的表现，再由各级经理把这些结论传达给自己的团队。这个分工很值得注意：测试与监控是集中的，判断与选择是分散的。指南的目标不是规定“某类任务必须用某个模型”，而是让每一位工程师都具备独立判断的依据，能够自己为手头的任务选出最合适的模型。最终的选择范围是 GPT-6 家族的 Astra 与 Luna，以及 GPT-6.1 Sol，依据是任务的复杂程度和所处的开发阶段。换言之，模型不再是一个全局默认值，而是像工具箱里的工具一样，随任务而取用。

第二层是预算的结构化管理。LegalOn 没有给所有团队设同一条线，而是让预算与各项业务所处的成长阶段相匹配。这一点解释了为什么成熟业务领域的降幅是 20%，而全公司预估日成本的降幅达到 65%：成熟业务的需求更稳定、更可预测，节省空间相对有限；增长阶段的业务则需要更多探索，预算安排自然不同。把成本与业务阶段挂钩，本质上是把 AI 支出当作一项有投资回报预期的资源来管理，而不是当作公共的、无差别的办公设备费用。需要说明的是，原文给出的是“预估”的每日成本降幅，并非经过完整周期核算的实际账单，读者在引用这个数字时应保持这一区分。

把这个案例放进更长的时间线里看，会更清楚它的意义。过去一两年里，企业评估编程智能体时最常问的是“它能不能写出可用的代码”，如今这个问题已经基本有了肯定的答案，新的问题变成了“它值不值得这个价钱，以及谁来为每一次调用负责”。LegalOn 的做法把这两个问题都落到了具体的角色上：AID CoE 负责证据，经理负责传达，工程师负责当下的选择，预算则由业务阶段来校准。没有任何一个环节依赖某个人的直觉，也没有任何一个环节需要把每次调用都送去审批，这正是它能够在不拖慢速度的前提下压低成本的结构性原因。另一个值得留意的细节是，模型家族本身提供了分层的可能：同一代产品里既有面向复杂任务的型号，也有更轻量、更经济的型号，组织只有在内部建立起判断标准之后，这种分层才会变成真实的节省。否则，分层只是菜单上多了几个选项，而每个人仍然会习惯性地点最贵的那一个。

还有一点常被忽视：这类机制需要定期复盘才能保持有效。新模型不断发布，旧结论会很快过期，所以 AID CoE 持续测试与监控的职责并非一次性工作，而是长期运营成本的一部分。把这部分成本算进去之后，节省依然成立，这才是对“降本”二字更诚实的理解。对于规模更小的团队，哪怕只指定一个人负责记录各模型在典型任务上的表现，也能得到类似的收益。 从行业角度看，这个案例传递出三层含义。其一，智能体编程的竞争正在从“谁的模型最强”转向“谁能把模型用得最划算”，模型分层和任务路由会成为企业的基本功。其二，治理的重点是组织机制而不是单纯的技术开关：有测试、有监控、有指南、有经理传达，才能让分散的个人决策保持一致。其三，限额与效率并非天然对立。LegalOn 的经验显示，只要选择依据足够清晰，降低单位成本和保持交付速度可以同时成立。对其他正在为 AI 编程账单发愁的团队来说，真正可借鉴的不是具体的模型名称，而是这套先观察、再分层、再按阶段配预算的顺序。