这是什么

一份 LLM 账单悄悄多花了近 4 倍——团队最后才发现原因：某次校验规则微调，让"省钱路由器"的升级率（失败后从便宜模型切到贵模型的比例）从 18% 爬到 71%。代码没报错、监控没告警、用户没投诉，被吞掉的是预算和"为什么"。我们关心的是：当路由散落在 if/else 和 feature flag（功能开关）里，连"为什么这个请求走了贵模型"都没人能答。

解法叫 Policy-as-Code——把路由策略当代码管理：从 if/else 里抽出来，分四层。Facts（请求事实，如任务类型、用户等级、输入长度）、Constraints（硬约束，如单请求不超过 0.02 元）、Policy（选择规则）、Decision Log（决策日志）。最后一层最关键：没有日志的路由器，省钱没人知道为什么省，翻车也没人知道为什么翻。

附带一个可跑的 TypeScript 小骨架，把候选模型的价格、延迟、质量分写成模拟数据，演示每个路由决策都可解释、可回放。

行业怎么看

支持的声音：模型路由本质是分布式系统决策问题，业务代码和策略混在一起是反模式。Policy-as-Code 能做到版本化、可回滚、可 A/B 测试，对中大规模团队的 LLM 成本治理几乎是必选项。

反对/风险也有两条值得警惕。第一，工程门槛被抬高——骨架看起来轻巧，但落地需要稳定的评测数据、健康检查、网关 telemetry（运行指标远程采集），不是每个团队都有。强行上马可能让小团队的成本结构更乱。第二，决策日志本身也产生成本：请求量大时每条都打完整快照，存储和检索开销可能把"省钱路由"省下的钱吃掉。文章没展开这一层，是一个盲点。

更尖锐的判断：很多团队的真正问题不是"路由没写成代码"，而是"根本没有评测系统"。没有离线 eval（评估）和线上反馈，策略写得再漂亮也是在猜。

对普通人的影响

对企业的 IT/技术团队：成本治理从"账单来了一脸懵"走向"每条请求都能追到决策"，但前提是先有评测和遥测基建，否则只是把混乱从代码搬到 YAML。

对个人职场：AI 应用岗位的招聘要求可能从"会调 Prompt"延伸到"懂模型路由和成本工程"，这是一个正在浮现的新能力维度。

对消费市场：短期内直接影响有限，但当企业能更精细地控制 AI 成本，更多中小公司能把 AI 功能塞进原本算不过账的产品里，消费者将用上更便宜、更稳的 AI 服务。