AI编程成本失控 大厂都在怎么省

Databricks 的这篇博客标题很直白：Managing AI Coding Costs at Scale。内容也直白——AI 编程工具在公司里铺开之后，成本曲线是指数级的，不加控制会反噬掉 AI 带来的效率提升。文章采访了 Stripe、Coinbase、Uber、Ramp 几家大厂的基础设施负责人，讲的是他们实际在用的省钱方法。

先说一个反直觉的结论：硬预算没用。几乎所有公司都试过"每人每月 X 美元，用超了禁用"，结果都不好。原因有两个——真用到预算上限的高支出用户，往往是产出最高的人，直接断供是自损；预算被切断对开发者生产力的打击，比省下的钱贵得多。大厂们普遍改成了"渐进式摩擦"：先让用户实时看到自己的花费，超过阈值弹出自清式提醒，再往上需要审批，最后才把用户降到低成本的替代模型，而不是直接停用。

省钱的核心是模型路由，不是砍用量

真正的大头省在模型选择上。文章提出了一个概念叫"效率前沿"——在某个智能水平下性价比最好的模型集合。日常编程大部分任务用不到顶级推理模型，所以"追效率前沿而不是智能前沿"是成本管理的第一原则。

具体做法是模型路由。Databricks 的 Unity AI Gateway 做请求级路由，按任务难度把请求分给成本最低且能胜任的模型；内部数据显示，Smart Router 能把平均任务成本降低 30% 以上，同时质量基本持平。还有任务级路由——元 harness（meta-harness）把整个任务分派给不同模型；以及升级模式——便宜的模型先跑，觉得搞不定再升级给贵模型。

这里有个容易被忽略的工程细节：路由的收益依赖"模型切换自由"。如果团队被绑定在某个 harness 上，而 harness 和模型又是深度绑定的（Claude Code 配 Claude、Codex 配 GPT 这种），那模型一换，工具链就得跟着换，切换成本高到没人愿意动。Stripe 的做法是直接拒绝上性价比倒退的新模型——他们发现 Opus 4.7 相对 4.6 质量没有明显提升但成本更高，就不让内部用。Databricks 在对比 Opus 5.0 和 4.8 时也发现了类似的成本回退。

真正的开销藏在上下文里

另一个省钱方向是 token 瘦身。用户输入一句"帮我查一下这个 bug"，Agent 随后会抓取大量上下文、调用一堆工具、翻整个代码库——最终喂给 LLM 的数据里，用户的原话占比微乎其微。成本大头是用户没显式提供的上下文。Databricks 的经验是，简单调一下 harness 的压缩策略和缓存设置，生成的 token 数量能降接近 50%，质量没有可观察的下降。

这些方法凑在一起，指向一个架构层面的变化：AI Gateway 正在成为企业基础设施里的标准组件——集中管理模型访问、预算策略、工具配置和会话日志。Databricks 把自家的 Unity AI Gateway 和 Omnigent 元 harness 开源了，说明他们判断这东西会是通用的。

对普通工程团队，这个案例的价值在于纠正一个常见误区：AI 编程成本问题不是"少用点"能解决的行政问题，而是可以工程化治理的技术问题。路由、缓存、上下文压缩、模型切换机制，每一项都是具体的系统设计决策。成本失控时先别急着砍人头，先看看流量有没有经过一个能路由、能记账、能降级的网关层。

还没解决的问题是：自动路由的评估依赖公司自建 benchmark，而大部分团队没有这个能力；缓存命中率调优高度依赖具体工作负载，没有一个放之四海皆准的设置。这些环节做得粗一点，省下的钱可能又会在别处漏掉。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

• 官网：https://framewiki.com
• Gitee：https://gitee.com/wiki-framework
• GitHub：https://github.com/wiki-framework
• 示例项目：https://gitee.com/cdkjframework/framewiki-example
• 📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）