FinOps 团队在一年前推出了 AI 内部计费（Chargeback）。仪表盘非常华丽。每个功能团队都能精确到分地看到上个月的推理账单，平台 PM 的幻灯片展示了 SKU 级别的业务线归因。相比一年前，组织拥有了更多的 AI 功能，但 AI 的质量却变差了。目前还没有人将这两个事实联系起来，但它们其实是同一件事。
用一句话概括这种失败模式：内部计费为推理 Token 定价，却悄无声息地忽略了评估 Token 的定价。因此，组织架构中的每一位 PM 都面临着一个奖励模型升级、惩罚评估规范的激励结构。12 个月后，评估覆盖率在萎缩，而账单却在增长——这与 FinOps 项目最初设想的激励效果完全背道而驰。这并不是仪表盘的漏洞，而是内部计费模型在严格执行其设计逻辑，只是在 AI 领域，源自云成本 FinOps 的设计假设已不再适用。
你的财务团队会要求你提供一份你写不出来的容量规划。这不是因为你缺乏经验，也不是因为模型是新事物，而是因为经典容量规划所依赖的两个假设——可衡量的负载分布和在季度维度上稳定的单位成本——在 AI 工作负载面前都失效了。你交给他们的数字从第一天起就会是错的，而当偏差出现时，随后的讨论将不仅仅关乎账单。
《2026 年 FinOps 现状报告》将 AI 列为增长最快的新支出类别，大多数受访者表示 AI 成本超出了最初的预算预测——对于许多企业来说，推理现在消耗了 AI 账单的大部分。用 SaaS 风格的容量规划来管理它的本能反应——选择一个峰值 QPS，乘以单位成本，再加上 30% 的缓冲——产生的数字看起来像预测，其实际预测能力却如同占星术。你真正需要的容量规划看起来更像是 FinOps 场景模型，而不是采购电子表格，而生成它所需的工程工作属于平台工作，会一直与功能开发竞争资源，直到财务部门失去耐心。
LLM-as-judge 是解放生产力的关键，它让评估覆盖率在不增加人工评分团队的情况下扩大了 10 倍。问题在于，这种解放效果在评分范围内并非均匀分布。裁判与人类的一致性在分布的“模糊中间地带”（muddy middle）最高——即那些没人会去纠结的答案——而在决定功能是发布、回滚还是在凌晨两点触发告警的关键长尾输出上，这种一致性会发生崩溃。在没人满意的评分范围内，仪表盘上的图表却始终保持绿色。
这就是 LLM 裁判的天花板：一种具有非均匀误差分布的测量工具，而团队却将其解读为一个单一的数字。与人类 80% 的总体一致性是大多数供应商在页面上打出的标题；这同时也是让团队在裁判信息量最低的地方最信任裁判的数字。
目前你的系统中有一个损坏的 prompt 影响了约 3% 的流量，但你的仪表盘根本察觉不到它的存在。p99 延迟图表是绿色的。错误率保持平稳。模型调用成功率指标高达四个九。唯一的故障迹象出现在一张平台团队无法复现的客户支持工单中，而等这张工单进入调试环节时，相关的 trace 已经因为采样而被丢弃了。
这不是监控缺失，而是一个分类错误。你正在运行的 APM 是为维度受限（如 endpoint、status_code、region、service）的世界设计的，在这种情况下，增加一个标签的成本最多只是增加几个新的时间序列。LLM 工作负载完全不符合这种模式。真正有趣的维度是用户的 prompt、检索到的 context ID、工具调用序列、模型版本、prompt 模板版本、租户（tenant）、语言区域（locale），以及请求所属的 eval bucket。每一个维度都是高基数（high-cardinality）的，只要你用其中任何一个子集来标记 span，指标存储瞬间就会爆炸。
打开任何交付 LLM 功能超过一年的团队的提示词库，你都会发现同样的情况：每个提示词都有三个略有不同的版本。一个是喜欢 Sonnet 及其指令遵循能力的工程师调优的。一个是由于延迟预算而切换到 Haiku 的工程师重写的。还有一个属于那个只在 Opus 上运行且从未迁移过的原型。每个版本都有略微不同的系统消息、不同的工具目录描述方式、不同的格式引导 —— 而且没有人追踪它们是如何产生漂移的。
""
这不是卫生问题。而是一种在每次模型升级时都会累积的协作税，它正在悄悄破坏你的评估套件与线上流量之间的关系。词库本应是共享资源。而在实践中，每个功能交付时都使用了作者最后测试的版本，评估套件运行的是评估作者偏好的版本，而路由层则根据成本而不是根据哪个变体实际通过了线上评估来选择。
那些没有察觉到的团队，已经在付出代价了。
成本仪表盘本身就很有说服力。60% 的流量是“简单”的，快速评估显示较小模型在全局准确率指标上仅落后几个百分点，路由层在同一周内通过特性开关（feature flag）上线。成本曲线开始下行。财务部皆大欢喜。团队继续推进后续工作。
没有人注意到的是，周二下午走廉价路径、周三上午走昂贵路径的客户，现在实际上在使用两种不同的产品。这两个模型的失败方式不同。格式化方式不同。拒绝的内容不同。它们以不同的默认逻辑处理歧义、追问和部分输入。从客户的角度来看，助手一夜之间失忆了，而且没人能告诉他们原因——因为在公司内部，这次变更被归档为一次 FinOps 的胜利，而不是一次产品发布。
在国际化发布的财务规划电子表格中，有一个清晰的项目：“将评估覆盖范围扩展到七个新语言区域 —— 假设为当前评估成本的 7 倍。”英语评估套件耗时两周，花费 4 万美元构建，因此七个语言区域将花费 28 万美元和一个季度的工程时间。CFO 签字了。产品 VP 签字了。发布启动了。
六个月后，实际的评估账单已经突破 31 万美元，团队仍在搭建最后两个语言区域。标注供应商在葡萄牙语（巴西）人员库中已经换了三批人，因为前两批产生的人员间一致性（inter-rater agreement）分数，任何诚实的审查都会称其为随机。德语裁判模型（judge model）在相同内容上的评分比英语模型低 6% —— 团队最初将其解读为德语模型的退化（regression），直到人工审核发现裁判模型本身才是退化的根源。评估负责人每周要花 40% 的时间处理一个没人预算过的问题：我们如何知道语言区域 A 的通过率确实比语言区域 B 差，而不是因为跨语言区域的测量比差距本身的噪声更大？
一位拥有 8 年事故响应经验的平台工程师打开了一条凌晨 2 点的报警信息：“AI 助手性能下降 —— 错误率 12%”。她检查了模型延迟仪表盘：绿色。检查了模型 API 状态页：绿色。检查了部署日志：过去 72 小时内没有任何变更。她做了任何称职的值班人员接下来会做的事 —— 呼叫 AI 团队。AI 工程师醒来，打开了平台工程师甚至不知道存在的追踪 (trace) 仪表盘，发现一个检索工具在过去 4 小时内一直超时，原因是一个下游搜索索引丢失了一个副本，并在 11 分钟内解决了事故。AI 工程师在凌晨 3:14 重新入睡。第二天早上的复盘记录写道：“AI 功能故障，由 AI 团队解决”。没有人写下真正的教训：如果这位值班工程师曾被教导过 AI 功能的故障面 (failure surface) 长什么样，她本可以在 5 分钟内完成分流 (triage)。
这是 AI 功能在过去两年中，向我合作过的每一个工程团队悄悄征收的“轮换税”。曾经完美适用于无状态服务堆栈和几个数据库的共享值班轮换，在其中一个“服务”变成由 LLM 驱动的功能时就会崩溃。你的 SRE 团队通过十年的事故复盘建立的值班手册，是为一个“某处出错了”可以分解为 CPU、内存、网络、部署和依赖超时的世界而校准的。AI 功能增加了三个维度 —— 模型、提示词 (prompt)、检索管道 —— 以及四种值班人员从未接受过识别培 训的故障形态，这些故障不会出现在他们习惯查看的仪表盘上。
上一季度发布的端侧 AI 演示在单台测试手机上运行了一个 4-bit Llama 变体，表现出色。六个月后，同样的功能却收到了一连串的一星差评，用户抱怨发热、耗电，或者更糟糕的是——无声的质量下降，用户只觉得“老手机上的 AI 变傻了”。模型没变，但机群（fleet）变了。那些原本以为是在交付模型的团队后来才发现，他们交付的其实是一个机群。
这就是导致大多数端侧 AI 发布失败的鸿沟：策略是围着选择“那个”模型转，而真正的难点在于如何为每类设备交付“合适的模型”，观察其运行情况，并在出问题时回滚。弥合这一鸿沟的学科更像是 CDN 运营，而非 ML 研究——清单驱动（manifest-driven）的交付、按分群的遥测、解耦的发布渠道，以及能从一个训练好的检查点生成 N 个量化分级的模型变体流水线。大多数团队并不具备这些，他们只有一个模型卡（model card）和一个构建产物。
系统提示词（system prompt）上一个四个词的修改——用 "respond using clean JSON"（使用干净的 JSON 响应）替换 "output strictly valid JSON"（输出严格有效的 JSON）——在评估（eval）中一度没有引起任何波动。它在周四发布，却在周五凌晨 4 点被回滚，因为结构化输出的错误率从 0.3% 飙升到了 11%。提示词并没有变糟。它只是变得“不同”了，而下游解析器在无人察觉的情况下，已经固化（pinned）在了 "strictly valid" 这个词组上。
这是大多数提示词工程（prompt-engineering）团队尚未建立工具来应对的失效模式：提示词被视为作者拥有的文本，而实际上它是与作者从未见过的消费者之间的一份合约。这些消费者中，有些是逐字引用原句的其他提示词；有些是 JSON 模式（JSON schema）字段锚定在特定形容词上的工具描述；有些是其评分标准（rubrics）要求裁判（judge）检查“严格有效格式”的评估（evals）；还有一些是解析器——最脆弱的一类——其正则表达式是根据模型输出的精确前导语（preamble）进行校准的。
一次“小小的措辞清理”会悄无声息地破坏解析器、导致裁判校准偏移，并使数周的评估运行失效。这些失败都不会在 PR（拉取请求）中显示出来，而是在一周后作为“偏移”（drift）出现在仪表盘上。
事故报告读起来就像一个单元测试的恐怖故事。一次 Prompt 编辑作为“前置说明清理（preamble cleanup）”的一部分，删除了一段五行的安全条款。测试套件中的每个 Eval（评估）都通过了。每个 Judge（裁判）评分都保持在容差范围内。两周后，一个面向客户的助手产生了一个本该被拒绝的响应，这种响应会在深夜 11 pm 触发信任与安全（Trust & Safety）页面的报警。复盘将这次回归追溯到了一个 PR 中的单处删除，而当时没有任何人标记它，因为负责捕捉回归的套件对安全条款是否存在没有意见——它只对模型在套件记得询问的情况下的表现有意见。
这就是行为评估（behavioral evals）与结构正确性之间的鸿沟。Eval 衡量的是模型生成的内容；它们不衡量 Prompt 本身是什么。而 Prompt 就像代码一样，有一个独立于行为而存在的结构层——必须存在的章节、必须解析的引用、必须插值的变量、必须遵守的长度预算、以及绝不能出现的弃用标识符。当结构层断裂时，行为表现通常会在一段时间内保持绿色，直到生产环境中的某个边缘情况将故障暴露为事故。
隐私审计员在 SOC 2 续期前两天提出了一个问题：“为什么你入门引导提示词示例中的电子邮件字段是一个真实客户的地址？”产品团队在脑海中回溯了整个流程。一年前，当他们发布 AI 摘要功能时，有人需要为 few-shot 模板找一个“看看它是如何工作的”示例。他们从预发布环境（staging）中选取了一条具有代表性的客户记录，清理了明显的字段——姓名、账户 ID、电话——并提交了文件。该客户在六个月后流失了。根据数据保留政策，他们的记录已从数据库中删除。但该记录并没有从提示词模板中删除，而该模板已发布到了生产环境中的每一个租户。
团队曾像大多数团队一样，认为隐私边界就是数据库。提示词模板是代码。代码要经过评审。评审并不会标记 PII（个人身份信息），因为评审人员不会在标记为 example_input: 的 YAML 字符串中寻找它。能在 Slack 消息和邮件附件中捕捉 PII 的 DLP（数据泄露防护）扫描器不会扫描提交的代码，即使扫描，它也不会将部分清理过的客户记录识别为个人数据，因为它知道要查找的字段已被移除。剩下的所有内容——公司规模、行业、稀有的职位名称、特定的城市——都是扫描器没有规则去处理的数据。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
