法律科技企业 LegalOn Technologies 披露其在内部研发中整合 Codex 的成本控制细节。面对全员敞开使用顶级大模型带来的算力账单压力，该公司通过设立 AI 驱动开发卓越中心（AID CoE）制定选型规则，将此前无限制调用 GPT-5.5 Fast 模式的粗放习惯，调整为在 GPT-6 Luna、GPT-6.1 Sol 与 GPT-6 Astra 之间阶梯选型，并默认停用 Fast 加速功能与设置层级配额。这套组合拳使团队在维持原有开发速度的同时，预估单日成本降低约 65%。
在外界普遍将模型降本归结于黑盒自动化路由算法（Model Router）的背景下，LegalOn 的案例展现了另一种现实。企业在研发效能深水区的算力节流，本质上是一场依靠组织指引、工程习惯妥协和部门财权划分的管理纠偏，而非纯粹的技术替代。
从顶配滥用到三级梯队：Luna、Sol 与 Astra 的算力再分配
技术团队引入生成式 AI 辅助编程时，往往先经历一段不计代价的效能红利期。LegalOn 最初向全体工程师开放顶配模型 GPT-5.5 的 Fast 模式，用于软件设计、代码编写与日常工作。随着使用频次上升，顶级算力的无节制消耗迅速触及年度预算红线。如果采取一刀切式的全面限流，前期积累的研发速度又会被打回原形。
负责推进内部治理的 AID CoE 最终放弃全员顶配策略，转而根据研发阶段与任务复杂度，将模型分拆为三层梯队：
在底层分工中，GPT-6 Luna 作为最轻量的模型，专门处理需求已经明确的代码实现、日常自动化任务，并作为子 Agent 承担局部操作；GPT-6.1 Sol 负责相对标准的设计、常规数值分析以及技术文档编写；顶配的 GPT-6 Astra 则退守到复杂软件架构设计、高阶判断与核心 Agent 编排调度工作。工程师不再默认向最强模型抛出所有 prompt，而是先由轻量模型承接，仅在复杂度升级时逐级向上申请算力。
默认关闭 Fast 模式与成熟业务「抠出 20%」
除了模型本体降配，LegalOn 还砍掉了隐形的高价溢价项：默认关闭所有账号的 Fast 加速模式，仅允许工程师针对偶发特殊场景按需单独申请。
失去加速特权后，推理等待时间的延长一度引发团队对研发节奏被拖慢的担忧。为了维持原有开发交付水平，团队被迫重塑协作习惯，依靠并行任务执行（parallel task execution）等工程实践来抵消等待延迟——即在等待模型生成代码的间隙，交替推进测试准备或文档梳理。这表明，部分算力账单的削减并非来自模型效率提升，而是通过工程师自适应地调整工作流和心流状态来补足系统降速。
在系统后台，公司同时对部门、小组和个人设立了三级月度使用上限。不同业务线的预算基准并未实行平均主义：
成熟的既有业务被硬性要求提升约 20% 的成本效率，通过严格的硬额度压减调用频次；而处于启动孵化阶段的新业务线则获得了相对宽裕的算力倾斜。高级工程经理 Yuta Tokitake 解释，新业务的核心诉求在于抢夺市场节奏而非死抠成本，因而被允许以消耗算力为代价换取功能交付速度。成熟业务挤出来的利润空间，实际上填补了新业务狂奔时的算力消耗。
供应商案例滤镜之外：未闭环的 ROI 迷思
OpenAI 在 2026 年 10 月 8 日以客户案例形式发布该实践时，标题定为“成本减半”，而文内披露的核心财务依据是预估单日成本较 GPT-5.5 降低约 65%。对于关注研发效能的组织而言，在借鉴该数字时需要辨清其中的多重变量：
65% 的降本基准建立在过往全员滥用顶级模型的粗放历史之上，它更多是对前期放纵的止血。
更为关键的治理短板在于评估体系本身。行业普遍认可 AI 能缩短软件开发与更新的周期，但开发提速是否真正转化为了客户愿买单的商业价值，业界至今缺乏量化标准。
- 风险.代码产出变快极易演变成功能堆砌的伪敏捷，如果缺乏业务转化度量，省下来的算力成本会被徒劳的无效研发吞噬。
Tokitake 坦言，现阶段企业能够清晰追踪单个技术任务消耗了多少 token 与费用，但一个完整的业务功能上线到底投入了多少综合 AI 成本、最终换回多少客户价值，在大部分组织内部依然是一个黑盒。LegalOn 试图将评估颗粒度收拢至以单次功能发布为单位，打通 AI 投入与客户价值之间的关联管道。但这项被寄予厚望的 ROI 度量体系，目前在企业内部仍处于构建阶段，属于规划中的蓝图而非已跑通的既定事实。
- 结论.在没有成熟的模型自动路由器介入前，仅凭 AID CoE 的制度约束与人工自主选型，对工程师团队的自觉性构成了长期考验；而当算力成本从失控被压缩至常态，真正考验 AI 原生团队的考题，才刚刚从代码行数转向商业账面。