你发布了一个新的平台级防护栏 (guardrail) —— 一条防止 AI 讨论竞争对手价格的规则。它在周一早上上线。到了周三，你最大的企业客户提交了一个支持工单：他们的销售助手 (他们曾精心调整该助手，以便为采购团队比较供应商选项) 停止工作了。他们没有更改任何东西。你更改了一些东西，而其影响范围 (blast radius) 在无形中波及了他们。
这就是多租户提示词问题 (multi-tenant prompt problem)。允许客户定制的 B2B AI 产品实际上是在运行一个分层指令系统，但大多数团队并没有将其视为一个系统。他们将其视为字符串拼接：获取平台提示词，附加客户的指令，也许再附加用户偏好，然后调用 LLM。模型会处理剩下的事情。
模型并不能处理好。它会默默地挑选一个赢家，而你直到有人投诉才会发现是哪一个。
模型卡会告诉你模型是否经过了针对CBRN误用的红队测试，以及它对哪些人群服务不足。但它不会告诉你：在10,000个并发请求下的p95 TTFT、性能在上下文窗口80%处出现的断崖、复杂JSON模式的格式错误率，或者自模型卡发布以来模型行为漂移了多少。
这种差距是结构性的，而非偶然。模型卡设计于2019年，用于公平性和安全性文档，目标受众是公民社会组织和监管机构。构建生产系统的工程团队并不是其使用场景。七年的推广之后，这一框架依然未变——而将模型卡视为部署规范的代价从未如此高昂。
2025年基础模型透明度指数（斯坦福CRFM + 伯克利）证实了这一遗漏的范围：OpenAI在100项透明度指标中得24/100，Anthropic得32/100，Google得27/100。平均分从58分降至40分，这意味着随着模型能力增强，AI透明度不升反降。四大主要实验室均不披露训练数据构成、能源使用情况或与部署相关的性能特征。
每个严肃的工程团队在合并代码前都会运行一次 Lint 检查。ESLint 捕获未定义的变量，Prettier 强制格式规范，Semgrep 标记安全反模式。没有人会在不先运行至少一次静态检查的情况下将 JavaScript 发布到生产环境。
现在想想你的团队在发布一次提示词变更之前会做什么。如果你的团队和大多数团队一样，答案是：在 PR 里审阅一下，用肉眼扫描，也许手动测试几个输入用例，然后合并。你生产 AI 功能的系统提示词——控制模型如何为每一位用户表现的指令集——所受到的预部署审查比一次 CSS 改动还要少。
这个差距不是一个微小的流程疏漏。一项分析了 2,000 多个开发者提示词的研究发现，超过 10% 的提示词存在提示词注入攻击的漏洞，约 4% 存在可衡量的偏见问题——而这一切都在没有人察觉的情况下部署到了生产环境。自动捕获这些问题的工具已经存在，只是大多数团队还没有把它接入流水线。
这是一个几乎出现在每个生产 AI 部署中的模式：团队发布了一个能够处理 90% 查询的功能。然后开始收到投诉。某用户提了一个超出训练分布的问题，模型自信地给出了错误答案。RAG 流水线检索到一份过时文档，模型却将其当作最新信息来回答。一个法律查询触及了提示没有覆盖的边缘情况，模型靠猜测蒙混过关。在每一种情况下，修复方案都不是换一个更好的模型，而是让系统学会说"我不知道"。
弃权——有原则地决定不回答——是 AI 系统设计中最难、最被低估的能力之一。几乎所有产品工作都致力于让答案更好，几乎没有任何工作致力于让系统可靠地知道何时该拒绝作答。这种不对称是一种在生产环境中不断累积的设计债务。
到 2025 年，每家主流 LLM 服务商都已推出结构化输出的受约束解码功能。OpenAI、Anthropic、Gemini、Mistral——它们都允许你向模型传入一个 JSON Schema，并保证返回结果在结构上完整无误。各个团队纷纷采用这一功能，长舒一口气：解析错误消失了，重试循环缩短了，监控面板一片绿色。
然后，微妙的故障开始出现。
一个情感分类器在两周内对每个输入——包括乱码——都锁定在 0.99 的置信度，无人察觉。一个信贷风险智能体返回了合法的 JSON，批准了一笔本应被拒绝的贷款申请，风险分数高出了五十分。一条金融数据管道将 "$500,000"（字符串，技术上符合 Schema）强制转换为整数字段中的零，破坏了六周的风险计算数据。这些故障全部通过了 Schema 验证。
教训是：结构有效性是必要条件，但并不充分。你需要一个语义验证层，而大多数团队并没有这一层。
你的团队花了三天时间迭代系统提示词。评估分数从 82% 提升到了 85%。你上线了。三周后，生产指标毫无变化。发生了什么？
简短的答案是：你的评估欺骗了你。不是恶意为之，而是样本量不足加上忽视了方差。在 100 个样本的测试集上提升 3 个百分点，完全在大多数 LLM 系统的噪声底线以内。在这个规模下，你无法区分信号与随机性——但几乎没有人会在采取行动之前做这个数学验证。
这就是 LLM 评估中的统计功效问题，它正在悄无声息地腐蚀大多数 AI 产品团队的迭代循环。
每一项微调工作最终都会达成同样的直觉：更好的数据意味着更好的模型，而更好的数据意味着更高质量的样本。因此，团队会构建复杂的标注流水线，以过滤掉平庸的输出，只保留金标准回复，并基于让他们引以为傲的数据集进行训练。然而，由此产生的模型在那些最初推动项目启动的具体用例中表现不佳。这种失败如此普遍，以至于值得拥有一个专属名称：课程陷阱（curriculum trap）。
这个陷阱在于 —— 仅策划你最好、最自信、最权威的输出并不能教会模型变得更好。它教会模型的是无论是否合理都要表现出自信。你创造出的东西在演示中看起来令人印象深刻，但在生产环境中却漏洞百出，因为生产环境充满了你的策划过程系统性排除掉的混乱边缘情况。
大多数 AI 产品复盘都聚焦于同一个故事：模型错了，用户发现了，信任瓦解了。修复方法显而易见——提高准确率。但有一种更隐蔽的失败模式，复盘很少能捕捉到，因为标准的准确率指标无法反映它：模型是正确的，但原因却是错误的，而那些检查了推理逻辑的高级用户再也没有回来。
称之为“过度声明陷阱”（overclaiming trap）。在这种失败模式下，正确的最终答案是由捏造的、事后修补的或结构不合理的推理链支撑的。它比普通的错误更危险，因为它看起来像是成功，直到你最专业的用户开始悄悄离开。
一个团队上线了一条 JSON 提取流水线。在开发环境中运行完美：98% 的准确率、干净的结构化输出、可预测的 token 数量。他们推送到生产环境后，模型开始产生多余的空白字符，JSON 解析器开始报错，API 账单是原型阶段估算的 2.3 倍。模型没变。提示词没变。
是 tokenizer 变了——更准确地说，他们对它的假设从一开始就是错的。
分词（Tokenization）是你的输入经历的第一次转换，却是工程师在调试时最后才想到要检查的地方。大多数团队把它当作已解决的问题：文本进去，token 出来，模型完成其工作。但字节对编码（BPE，Byte Pair Encoding）——大多数生产级 LLM 背后的分词算法——在结构化输出生成、前缀缓存、成本估算和多语言部署中做出的决策，会产生连锁影响。一旦你知道该往哪里看，这些影响完全是可以预测的。
在你最优秀的提示词工程师转岗到新项目六个月后，一个面向客户的 AI 功能开始出现异常。响应质量下降了，输出格式偶尔损坏，还有一个说不清道不明但持续存在的语气问题。你打开提示词文件，里面是 800 字的自然语言。没有变更日志，没有注释，没有测试用例。写下它的人确切地知道每一段话存在的意义。但那份知识已经消失了。
这就是提示词考古问题，它已经让团队付出了真金白银的代价。一家全美抵押贷款机构最近发现，文档分类的准确率下降了 18%，原因可以追溯到三周前有人在所谓的“常规工作流优化”中向提示词添加的一句话。两周的调查，大约 340,000 美元的运营损失。而那次修改的作者早已离开了。
对语言模型进行微调能给你带来竞争优势——直到提供商在你的适配器之下更新了基础模型。此时，两种情况之一会发生：你的服务因形状不匹配错误而崩溃，或者——更危险的是——它开始静默输出降级结果，而你的监控系统毫无异常。大多数团队发现第二种情况，往往是在用户投诉"AI 变蠢了"之后。
这就是适配器兼容性悬崖。你在模型版本 N 上训练了一个 LoRA 适配器，提供商发布了版本 N+1，你的适配器现在运行在一个从未为之设计的基础上，且没有任何迁移路径。
在大多数 RAG 架构中都存在这样一种信念：如果检索返回了正确的区块（chunks），LLM 就会生成正确的答案。团队在嵌入模型选择、混合检索策略和重排序流水线方面投入了巨资。然而，在部署到生产环境三个月后，回答质量悄然下降——这不是因为模型变了，也不是因为查询模式发生了剧变，而是因为底层的语料库腐烂了。
企业级 RAG 的实施失败率约为 40%，而从业者最容易低估的失败模式既不是幻觉，也不是检索召回率低，而是文档质量。一项分析发现，通过引入文档质量评分，一个实施方案在不改变嵌入模型或检索算法的情况下，将搜索准确率从 62% 提高到了 89%。语料库是唯一的变量。语料库一直都是变量。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
