你发布了一个新的平台级防护栏 (guardrail) —— 一条防止 AI 讨论竞争对手价格的规则。它在周一早上上线。到了周三，你最大的企业客户提交了一个支持工单：他们的销售助手 (他们曾精心调整该助手，以便为采购团队比较供应商选项) 停止工作了。他们没有更改任何东西。你更改了一些东西，而其影响范围 (blast radius) 在无形中波及了他们。
这就是多租户提示词问题 (multi-tenant prompt problem)。允许客户定制的 B2B AI 产品实际上是在运行一个分层指令系统，但大多数团队并没有将其视为一个系统。他们将其视为字符串拼接：获取平台提示词，附加客户的指令，也许再附加用户偏好，然后调用 LLM。模型会处理剩下的事情。
模型并不能处理好。它会默默地挑选一个赢家，而你直到有人投诉才会发现是哪一个。
每个严肃的工程团队在合并代码前都会运行一次 Lint 检查。ESLint 捕获未定义的变量，Prettier 强制格式规范，Semgrep 标记安全反模式。没有人会在不先运行至少一次静态检查的情况下将 JavaScript 发布到生产环境。
现在想想你的团队在发布一次提示词变更之前会做什么。如果你的团队和大多数团队一样，答案是：在 PR 里审阅一下，用肉眼扫描，也许手动测试几个输入用例，然后合并。你生产 AI 功能的系统提示词——控制模型如何为每一位用户表现的指令集——所受到的预部署审查比一次 CSS 改动还要少。
这个差距不是一个微小的流程疏漏。一项分析了 2,000 多个开发者提示词的研究发现，超过 10% 的提示词存在提示词注入攻击的漏洞，约 4% 存在可衡量的偏见问题——而这一切都在没有人察觉的情况下部署到了生产环境。自动捕获这些问题的工具已经存在，只是大多数团队还没有把它接入流水线。
你的 Agent 在 1 月份时运行良好。到了 3 月，它开始在 15% 的工具调用中失败。到了 5 月，它在另外 20% 的情况下会静默地产生错误输出。你的部署日志没有任何变化。没有人动过 Agent 的代码。工具定义看起来和六个月前一模一样——而这恰恰就是问题所在。
工具 Schema 并不需要被修改才会出错。它们所描述的服务在底层发生了变化。Enum（枚举）值增加了。后端重构使必填字段变成了可选字段。以前接受字符串的参数现在需要 ISO 8601 时间戳。Schema 文档保持冻结，而底层的 API 却在不断演进，你的 Agent 仍在自信地调用它，完全不知道契约（contract）已经发生了变化。
这就是 Schema 熵（Schema entropy）：你的 Agent 接受训练时所使用的工具定义与生产环境服务实际表现出的行为之间逐渐产生的差异。它是生产环境 AI 系统中最被低估的可靠性问题之一，研究表明，工具版本控制问题约占生产环境 Agent 故障的 60%。
这是一个几乎出现在每个生产 AI 部署中的模式：团队发布了一个能够处理 90% 查询的功能。然后开始收到投诉。某用户提了一个超出训练分布的问题，模型自信地给出了错误答案。RAG 流水线检索到一份过时文档，模型却将其当作最新信息来回答。一个法律查询触及了提示没有覆盖的边缘情况，模型靠猜测蒙混过关。在每一种情况下，修复方案都不是换一个更好的模型，而是让系统学会说"我不知道"。
弃权——有原则地决定不回答——是 AI 系统设计中最难、最被低估的能力之一。几乎所有产品工作都致力于让答案更好，几乎没有任何工作致力于让系统可靠地知道何时该拒绝作答。这种不对称是一种在生产环境中不断累积的设计债务。
到 2025 年，每家主流 LLM 服务商都已推出结构化输出的受约束解码功能。OpenAI、Anthropic、Gemini、Mistral——它们都允许你向模型传入一个 JSON Schema，并保证返回结果在结构上完整无误。各个团队纷纷采用这一功能，长舒一口气：解析错误消失了，重试循环缩短了，监控面板一片绿色。
然后，微妙的故障开始出现。
一个情感分类器在两周内对每个输入——包括乱码——都锁定在 0.99 的置信度，无人察觉。一个信贷风险智能体返回了合法的 JSON，批准了一笔本应被拒绝的贷款申请，风险分数高出了五十分。一条金融数据管道将 "$500,000"（字符串，技术上符合 Schema）强制转换为整数字段中的零，破坏了六周的风险计算数据。这些故障全部通过了 Schema 验证。
教训是：结构有效性是必要条件，但并不充分。你需要一个语义验证层，而大多数团队并没有这一层。
异步 AI 任务有一个传统后台 Worker 没有的问题：它们会静默而自信地失败。一个文档处理 Agent 返回 HTTP 200，输出格式规整的结果，然后继续执行——而实际输出却悄悄出错了：可能不完整，可能建立在三步前幻觉出的事实上。你的仪表盘依然绿色，值班工程师照常入睡，客户最终才发现异常。
这不是边缘情况，而是未经可观测性设计的异步 AI 系统的默认行为。让传统分布式系统中后台作业队列保持可靠的工具——死信队列、幂等键、Saga 日志——同样适用于 AI Agent。但失败模式足够不同，需要做一些"翻译"。
你的团队花了三天时间迭代系统提示词。评估分数从 82% 提升到了 85%。你上线了。三周后，生产指标毫无变化。发生了什么？
简短的答案是：你的评估欺骗了你。不是恶意为之，而是样本量不足加上忽视了方差。在 100 个样本的测试集上提升 3 个百分点，完全在大多数 LLM 系统的噪声底线以内。在这个规模下，你无法区分信号与随机性——但几乎没有人会在采取行动之前做这个数学验证。
这就是 LLM 评估中的统计功效问题，它正在悄无声息地腐蚀大多数 AI 产品团队的迭代循环。
最有望从 AI 中获益的团队，往往是最晚部署 AI 的。一家能够利用 AI 实时发现用药错误的医疗机构，其 AI 采纳率仅为 39%；而一家运行 AI 代码审查的软件公司，采纳率高达 92%。两者的 ROI 差距悬殊——然而采纳率却完全颠倒。这就是 AI 采纳悖论，而且它绝非偶然。
人们的本能是将这种差距解释为规避风险、监管恐惧或官僚惰性。这些因素确实存在。但更深层的原因是结构性的：在高风险领域释放价值所需的准确率阈值，从根本上高于自主部署所能证明合理的水平，而大多数团队尚未构建出弥合这一差距的架构。
每一项微调工作最终都会达成同样的直觉：更好的数据意味着更好的模型，而更好的数据意味着更高质量的样本。因此，团队会构建复杂的标注流水线，以过滤掉平庸的输出，只保留金标准回复，并基于让他们引以为傲的数据集进行训练。然而，由此产生的模型在那些最初推动项目启动的具体用例中表现不佳。这种失败如此普遍，以至于值得拥有一个专属名称：课程陷阱（curriculum trap）。
这个陷阱在于 —— 仅策划你最好、最自信、最权威的输出并不能教会模型变得更好。它教会模型的是无论是否合理都要表现出自信。你创造出的东西在演示中看起来令人印象深刻，但在生产环境中却漏洞百出，因为生产环境充满了你的策划过程系统性排除掉的混乱边缘情况。
大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。
称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。
一个团队上线了一条 JSON 提取流水线。在开发环境中运行完美：98% 的准确率、干净的结构化输出、可预测的 token 数量。他们推送到生产环境后，模型开始产生多余的空白字符，JSON 解析器开始报错，API 账单是原型阶段估算的 2.3 倍。模型没变。提示词没变。
是 tokenizer 变了——更准确地说，他们对它的假设从一开始就是错的。
分词（Tokenization）是你的输入经历的第一次转换，却是工程师在调试时最后才想到要检查的地方。大多数团队把它当作已解决的问题：文本进去，token 出来，模型完成其工作。但字节对编码（BPE，Byte Pair Encoding）——大多数生产级 LLM 背后的分词算法——在结构化输出生成、前缀缓存、成本估算和多语言部署中做出的决策，会产生连锁影响。一旦你知道该往哪里看，这些影响完全是可以预测的。
你上线了一个 AI 功能。模型表现良好——你量化过它。精确率达 91%，召回率扎实，P99 延迟低于 400ms。三个月后，产品分析给出了一个令人沮丧的数字：高级用户已将其完全关闭，而另一批用户则不加修改地接受每一条建议，包括那些明显错误的。
这就是信任校准差距。它不是模型问题，而是设计问题——而且比大多数 AI 产品团队愿意承认的更为普遍。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
