AI 功能依赖图:当提示词修改成为静默破坏性变更时
一个团队负责摘要生成器。另一个团队负责摄取这些摘要的搜索排序器。第三个团队负责一个路由,根据排序器的置信度分数在不同的智能体人格之间进行选择。这些团队都没有共同的值班轮换,也没有人参加同一个站会,他们之间唯一的契约就是“上一个功能的输出是下一个功能的输入”。周二,摘要团队收紧了一个提示词,以修复销售演示中反馈的幻觉问题。六小时后,搜索排序器的质量骤降。到周三早上,路由开始将任务交给错误的智能体人格。复盘报告会将原因记录为“提示词变更”,但实际原因是团队的 AI 功能已经悄然组成了一个没人绘制过的有向图。
这是最常见的 AI 故障形式,它不会触发你为 AI 故障构建的任何警报。模型没有宕机。被修改功能的评估套件显示为绿色。Token 成本曲线很平稳。真正断裂的是两个功能之间的接口,你的依赖工具将其视为纯文本,因为在 API 边界它确实只是纯文本——并且将其视为惰性的,因为纯文本不携带版本、Schema 或弃用策略。
这类失败之所以迟迟未得到重 视,是因为初看起来,它就像普通的回归。一个变更发布了;某处的质量下降了。自然的反应是归咎于变更作者或下游所有者。这两种反应都是错误的。变更作者在他们自己的评估范围内交付了一个正确的修复。下游所有者则在为一个他们从未同意维护的固定项负责。真正坏掉的东西是契约的缺失。
你已经拥有的隐性图
走查一个典型的 AI 产品界面并计算消费关系。分类器为路由提供输入。摘要为搜索索引提供输入。智能体的计划步骤为其执行步骤提供输入,执行步骤的工具输出又为下一轮推理提供输入。检索提示词的输出为生成提示词的上下文提供输入。安全提示词的判决为后处理重写提供输入。每一个箭头都是一个功能的功能输出分布转化为另一个功能的输入分布的地方。
在传统的服务架构中,这个图是可见的。Protobuf 文件在版本控制中,服务网格记录调用,SLO 仪表盘标明消费者,Schema 的破坏性变更会导致 CI 失败,因为消费者的生成客户端拒绝编译。在 AI 产品中,存在同样的图,但每个箭头都是一段自由格式的字符串。输出 Schema 就是模型上周发出的任何内容。消费者的解析器是一个正则表达式或一个设置了 additionalProperties: true 的 JSON Schema。“破坏性变更”的受影响面是上游模型的整个后验分布,而不是数据库中的列名。
这就是为什么“提示词编辑作为破坏性变更”的问题比“服务 API 作为破坏性变更”的问题更难,而不是更容易。Protobuf 大约有五种损坏方式,而且它们都可以通过 Linter 枚举出来。自然语言输出有成千上万种偏移方式——平均长度、拒绝率、套话频率、引用密度、命名实体的隐式排序、列表中的要点数量、待办事项的动词时态。每一个分布轴都可能是下游消费者的提示词正在悄悄依赖的东西,而下游团队往往自己都没有意识到这种依赖。
最近关于已部署 LLM 系统中分布偏移的研究报告称,在提示词行为发生中度偏移的情况下,性能下降幅度超过 70%,而最痛苦地暴露出这一点的部署场景正是那些一个功能的输出是另一个功能的输入的逐级流水线。这种下降不是模型回归,而是组合回归。模型正在履行职责,但流水线没有。
清单必须显式化
只有当依赖图不再是隐性的时候,如此脆弱的流水线才会变得可控。最轻量级的版本是清单(manifest)——每个功能一个文件,声明两个列表:“我消费这些功能的输出”和“我被这些功能消费”。它并不华丽,也不必是一个复杂的工件。一个签入仓库的 YAML 文件,指明上游来源和下游消费者,就足以实现清单的实际目的:将提示词编辑从单个团队的决策转变为多团队的协调事件。
在清单中,PR 模板可以机械地询问:“谁消费此功能的输出,他们是否审查过此变更?”在清单中,发布流程可以拒绝合并,直到指定的消费者确认了提示词的差异。在清单中,当复盘询问“是否有人知道排序器依赖于摘要平均长度保持在 40 个词以下”时,答案要么是“是的,这在清单里”,要么是“不,这正是我们现在要弥补的差距”。
清单中三个具有实际价值的属性:
- 它命名功能,而非文件。 功能是一种契约:由单个团队拥有的用户可见行为。提示词文件是该契约的实现细节。命名功能而非文件可以使清单在重构过程中保持稳定,即便一个功能被拆分为多个提示词,反之亦然。
- 它声明了消费者依赖的输出面。 不是完整的提示词——而是下游提示词敏感的分布属性。“摘要长度在 60 个词以内。”“输出恰好是一个带有这些键的 JSON 对象。”“置信度分数校准在 0.0–1.0 范围内,而不是 1–5 的序数。”清单是对“如果上游输出发生变化,什么会破坏我的功能”这一问题的回答。
- 它是发布协调的输入。 没有清单,提示词 PR 只是一个团队的工件,消费者只能从生产环境中发现问题。有了清单,PR 模板会列出消费者,要么自动将他们标记为审核者,要么要求通过检查进行签收。
针对现实而非固定数据的契约测试
- https://arxiv.org/abs/2604.17650
- https://agenta.ai/blog/prompt-drift
- https://arxiv.org/abs/2311.11123
- https://dev.to/temurkhan13/5-silent-failure-patterns-i-keep-finding-in-production-ai-systems-4fl0
- https://www.mindstudio.ai/blog/ai-agent-failure-pattern-recognition
- https://adversa.ai/blog/cascading-failures-in-agentic-ai-complete-owasp-asi08-security-guide-2026/
- https://www.digitalocean.com/community/tutorials/model-silent-versioning-problem
- https://docs.base14.io/blog/llm-prompt-lifecycle/
- https://www.productmanagement.ai/p/prompt-optimization-guide
