实验组之所以上线，是因为仪表盘显示“转化率 +4%，p < 0.01，n = 2.3M”。但在全球推行 6 周后，这一增长消失了。由于没有其他合理解释，团队将这次复盘报告归类为“规模效应”。然而，真正的原罪一直潜伏在提示词组装器（prompt assembler）中：决定实验分组的路由哈希（routing hash）派生自一个用户层级（user-tier）属性，而三行代码后，同样的属性被插值到了提示词模板中。模型直接在带内（in band）读取了分组分配。所谓的“实验干预”（treatment）并非提示词的改变，真正的干预是提示词改变后所吸引的用户群体。
这是一种在团队从 Web 时代继承的实验手册中并不存在的失效模式。按钮颜色不会读取用户层级并决定表现不同，但提示词会。一旦你的实验干预是一个由模型解释的字符串，那么任何触及路由决策且同时触及提示词的输入，都会变成实验无法关闭的后门。
六个月前，你的团队上线了一个处理退款的支持智能体（support agent）。当时有一份一页纸的 Notion 文档描述了它应该做什么。如今，文档的内容依然如旧，但智能体的行为却已大相径庭。提示词（prompt）的历史记录中有 47 次修改。新增了三个工具——其中一个悄悄绕过了文档中仍坚称存在的财务核查。模型被更换了两次。在一次没人记录的事故之后，重试策略被加强了。而当数据团队的人问起“这里处理退款的具体规则到底是什么”时，诚实的回答是：去读系统提示词和工具注册表吧，因为那才是现在的规范。
这是智能体系统在生产环境中的隐性失败模式：智能体的行为就是那份没人写的操作手册（runbook）。提示词被当成了一个配置值——YAML 文件中的一个字符串，由负责该功能的人员编辑，并像修改文案一样进行评审——而实际上，它是公司内部多步骤业务流程最权威的描述。组织积累流程逻辑的方式就像遗留代码库积累行为一样：通过修改，而非设计。而那些历来负责该流程的人——产品经理、合规主管、运营总监——从未意识到他们已经丢失了交付物，因为根本就没有一份可以丢失的文档。
浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。
这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。
问任何一个 AI 工程团队是否测试了他们的提示词，他们都会说"是的"。再问一句：一个有问题的提示词能否让 PR 失败并阻断合并？房间里会安静很多。对大多数团队而言，诚实的答案是否定的 —— 他们偶尔会跑一些评估笔记本，也许有一份记录已知提示词问题的共享 Notion 文档，以及一种模糊的感觉：事情比以前更糟了。那不是测试，那是在碰运气。
这个差距的存在，是因为提示词测试在感觉上与单元测试有本质区别。代码要么行为正确，要么不正确。提示词的输出处于一个连续谱上，输出是非确定性的，而且运行足够多的样本以建立信心会花费真金白银。这些都是真实的约束，但没有一个是无法克服的。那些建立了真正阻断合并的提示词 CI 的团队，并不是在每次构建上花费五十美元 —— 他们在三分钟以内、花费不到一美元的情况下完成运行，这得益于几个让这个问题变得可处理的设计决策。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
