模型卡会告诉你该模型在 MMLU 上得分 88.7 分。但它不会告诉你：该模型会系统性地将责任归咎于可能性列表中最先出现的技术，导致约 10% 的归因答案在事实正确的情况下语义却是错误的。它不会告诉你：在系统提示中加入"你是一个有帮助的助手"，与留空系统提示相比，会降低结构化推理任务的性能。它不会告诉你：在高负载下第 99 百分位延迟是中位数的 4 倍，也不会告诉你：模型在法律和金融查询上的行为，会因你是否包含合规免责声明而发生明显变化。
这些内容都不在模型卡里。你需要将系统部署到生产环境，然后亲眼看着问题出现，才能学到这些。
你升级到了最新模型，结果产品却变差了。不是灾难性的崩溃——新模型在基准测试中得分更高，能处理更难的问题，拒绝的不该拒绝的内容也更少了。但你的产品实际需要的那项能力？退化了。你精心调优的提示现在产出的是模棱两可、过度修饰的输出，而你需要的是明确的断言。你的领域特定格式指令被"贴心地改进"成了通用格式。那种让工作流程可靠运行的严格指令遵从感，现在像是在自动驾驶。
这就是能力激发差距：模型在原则上能做什么与它在生产环境中你的提示下实际做什么之间的鸿沟。而随着每一轮以安全为重点的训练循环，这个差距系统性地扩大。
你的语言模型告诉你，它有 93% 的把握认为 Geoffrey Hinton 在 2010 年获得了 IEEE Frank Rosenblatt 奖。然而实际的获奖者是 Michio Sugeno。这不是传统意义上的幻觉——模型生成了一个听起来合情合理的答案，并给它附上了一个高置信度分数。问题在于，这个置信度数字本身就是谎言。
这种声称的置信度与实际准确率之间的断层，就是所谓的校准差距。它是生产 AI 系统中被严重低估的故障模式之一。那些在原始模型置信度分数之上构建路由逻辑、升级触发器或用户可见置信度指示的团队，是在沙滩上建楼。
大多数团队发现模型局限性的方式和用户一样 —— 在生产环境中，通过工单。客户反映提取流水线悄悄丢失了嵌套地址。内部用户注意到摘要器在超过 8,000 个 token 后开始虚构日期。合规审查发现分类器自信地为模糊案例打上标签，而不是选择放弃判断。
这些都不是意外。它们是一直存在的能力边界，只是在等待合适的输入来暴露它们。你要么在部署前绘制这些边界，要么让用户替你绘制 —— 一次一个事故。
系统性地发现这些边界的方法就是能力探测 —— 语言模型的故障注入。你不会在没有对接缝进行负载测试的情况下交付一座桥梁。同样的逻辑适用于任何面向用户的模型。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
