开放使用之后，成本成了新的工程问题

LegalOn Technologies是一家面向全球提供专业AI的公司，也把Codex引入自己的开发流程，并逐步扩展到组织内部的日常工作。公司一开始让开发者不限量使用GPT-5.5 Fast，鼓励团队在设计、实现和日常任务中摸索人和AI各自适合承担什么。这样做先解决了采用问题，却也让使用范围和支出随实践一起增长。

LegalOn随后遇到的冲突很具体：高性能模型如果一直不限量开放，可能超过年度预算；如果用统一禁令或粗暴限额回应，开发者又可能失去已经形成的效率收益。公司披露，在调整使用方式后，估算的每日Codex成本下降65%，同时维持开发速度。标题把结果概括为“成本减半”，但现有材料没有解释这一概括与65%数字的测算关系，因此两者不能被视为口径完全一致的指标。

模型分工不是排行榜，而是升级路径

公司的核心改变，是不再把最强模型设为所有任务的默认选项，而是从轻量模型开始，随着任务复杂度上升再切换。GPT-6 Luna负责需求明确的代码实现、日常自动化和相对简单的分析，也可以作为子代理执行较简单的工作。GPT-6.1 Sol承担常规设计、数据分析和文档准备，材料还把它用于希望比Luna更快完成的任务。

GPT-6 Astra则留给复杂分析、架构设计和协调多个代理等需要更多判断的工作。这样的分工说明，模型选择不只是比较谁的能力更强，而是要决定何时值得为更强能力付出资源。若需求清楚、任务边界稳定，先用轻量模型可能足够；遇到架构判断或复杂协调，再升级模型，才有机会让额外能力对应到真实工作价值。

把选型经验变成团队可执行的规则

这套路由并非材料所说的全自动调度系统。LegalOn的AI-powered Development CoE，也就是AID CoE，负责测试和监控模型，并把观察到的适用场景整理成指南，再由管理者分享给团队。工程师据此为具体任务选择模型，内部测试也帮助公司把选择标准逐步说得更具体。

这套组织安排的价值，在于让模型选择不只依赖个别开发者的经验。团队可以围绕“需求是否明确”“是否需要复杂判断”以及“是否涉及代理协调”等任务特征形成共同语言。不过，指南能否长期有效，仍取决于模型与业务变化后是否继续测试和更新。材料描述了监控与调整的职责，却没有提供选择准确率、升级频率或不同模型输出质量的比较数据。

速度与预算由两层控制共同承担

除了按任务选模型，LegalOn还把Fast模式从默认使用改为按需开启。团队担心这会拖慢开发，公司披露他们使用并行运行任务等做法维持性能，并平稳完成调整。这里的机制不是证明较慢模式不会影响工作，而是把使用速度变成可以按请求调整的选项，并让团队尝试用执行方式弥补等待。

另一层控制是预算权限。管理员为部门和个人设置月度用量上限，AID CoE监控使用情况，并可随业务需要调整额度。模型指南回答“这项工作适合什么能力”，月度限额则回答“谁可以使用多少资源”。两者配合，避免只靠工程师自我克制，也给管理者留下了按实际需求校准预算的空间。

业务阶段不同，预算目标也不该相同

LegalOn没有把同一套成本目标平均分配给所有业务。成熟业务被要求提升成本效率，目标约为20%；处于启动阶段的新业务则获得较宽裕的预算，以鼓励积极使用AI。这不是简单地给新团队更多、给成熟团队更少，而是把支出的用途放回业务阶段判断：成熟业务需要关注效率，新业务可能需要保留试用和探索空间。

这种差异化也有代价。若预算一味向成熟业务收紧，可能让有效的开发工作受阻；若启动业务的额度长期宽松，却不观察产出，也可能让支出脱离实际价值。材料没有披露各业务的具体额度或如何判定阶段，因此可借鉴的是按业务需要调整资源的原则，而不是直接复制某个额度比例。统一削减看起来容易管理，却未必能让钱花在最值得保留的任务上。

65%是公司披露的结果，不是通用节省公式

LegalOn呈现的是一组相互配合的管理动作：按复杂度分配模型、收紧Fast模式的默认使用、对部门和个人设置月度限额，再依据业务阶段分配预算。公司称估算日成本下降65%，并维持开发速度，但材料没有说明估算日成本如何计算、比较了多长时间，也没有给出任务完成时间、质量变化、返工率或实际账单的对照。因此，这一结果是公司披露的经验，不能据此推断其他团队也能得到同样降幅。

技术负责人若要借鉴，更稳妥的做法是先建立任务级基线，而不是先照搬Luna、Sol和Astra的分工。记录每类任务使用的模型、花费、耗时和结果质量，同时注明模型版本与运行模式，再观察升级模型是否减少返工、并行执行能否补偿速度变化，以及不同业务的预算差异是否对应真实需求。若这些指标没有持续记录，成本下降可能只是估算口径改变，速度看似不变也可能掩盖质量或工程师负担的转移。判断标准应是每次能力升级能否由任务价值解释，而不是追求一个固定的节省比例。