AI 功能依赖图：当提示词修改成为静默破坏性变更时

清单（Manifest）告诉你 谁 可能会崩溃。契约测试告诉你他们 是否 会崩溃。这种测试的天真形式是派生一个冻结的固定数据（Fixture）：下游功能的评估套件包含一个存储的上游功能输出示例，并针对该固定数据进行评估。这总比没有好，但这也是一个陷阱。固定数据只是上游功能在过去某个时刻输出分布的快照。六次提示词（Prompt）修改后，固定数据就成了虚构。契约测试通过了，生产环境却崩溃了；事后分析发现，测试针对的是上游功能已经好几个月没有实际产生的输出形态。

非天真的形式更难但也更重要：下游功能的评估套件针对上游功能的 当前 输出分布运行。你从上游功能最近的生产输出中提取代表性样本——过去七天，按流量加权——并将它们作为输入回放到下游功能的评估中。结果不是“下游功能在理想化输入下是否通过”，而是“下游功能在它目前实际接收的输入下是否通过”。

这将契约测试的成本从“几乎为零但毫无用处”转变为“不可忽视但却是捕捉真实失败模式的唯一测试”。它还重新定义了契约测试的 目的。它不再仅仅是下游功能的回归门控。它是一个耦合测试：当下游解析器变得更脆弱，或上游输出分布发生变化时，它都会触发。这两者都是团队需要了解的情况。而目前的评估工具在不费一番功夫的情况下都无法揭示这些问题。

能够做好这一点的团队通常会构建一个共享的基础设施：一个在调用点捕捉上游功能输出的服务，按流量权重将其采样到滚动语料库中，并将该语料库作为下游评估套件的固定数据端点公开。语料库按日期而不是按承诺进行版本化。下游评估像服务锁定依赖版本一样锁定到“上周的语料库”，而更新则成为一种刻意的行为——这正是正确的交互体验，因为更新就是重新运行契约的时机。

分布偏移警报是安全绊网​

清单和契约测试能捕捉到你预料中的损坏。分布偏移（Distribution-shift）警报则能捕捉到你意料之外的。原理很简单：对于依赖图中的每一个箭头，你对上游输出计算一组简单的统计指标——长度分布、拒绝率、JSON 解析率、键存在率、嵌入质心（embedding centroid）、实体提及率——并在这些统计数据漂移超过可配置的阈值时发出警报。

统计数据不需要很深奥。重点不是要刻画输出的完整语义，那是难以处理的；重点是检测输出分布的 某些方面 发生了移动，进而触发下游的重新评估。漂移警报不是质量警报。它是一个“昨天的契约测试结果已不再适用”的警报，唯一的正确响应是针对新鲜的上游样本重新运行下游评估。

关于漂移警报，在第一次构建时有两点实现注意事项：

• 阈值必须根据上游功能在无变化日的自然波动进行调整。即使没有人修改提示词，摘要生成器的输出分布也不是静态的——每日内容组合、用户量变化和路由转换都会影响它。警报应该在提示词修改导致的偏移上触发，而不是在“周二对周三”的波动上触发。
• 警报必须送达 下游 团队，而不是上游团队。上游团队没有破坏任何东西，他们的功能运行正常。下游团队才是那个评估结果不再可信的人。正确路由告警使这成为一个协作原语，而不是另一个被错误团队静音的嘈杂报警。

发布协调作为最后防线​

即使有了清单、契约测试和漂移警报，足够大的功能面最终也会产生合并后才显现后果的提示词修改。最后一块拼图是让合并回滚变得廉价，且让协调变得显式。在实践中，这表现为发布门控（Release gate）：如果一个功能的提示词 PR 在清单中有指定的消费者，那么在消费者签署同意之前，或者在该 PR 被标记为“非协调”并带有自动回滚路径的特性标志（feature flag）发布之前，该 PR 不能合并。

门控的目的不是为了减慢提示词的迭代速度。它是为了让协调失败的成本在 PR 阶段显现，而不是在事故发生时。搞错这一点的团队往往会走向两个极端。要么要求对每一次提示词修改都进行签署，这会导致积压并让人们养成敷衍了事的习惯；要么什么都不要求，这会导致清单原本要防止的失败模式。中间地带是仅对已声明消费者的功能的提示词要求协调，并将添加消费者关系变成一个开启门控的刻意行为。

将这一切整合在一起的架构认知虽然令人不安，但值得直接说出来：团队的 AI 功能已经组合成了一个有向图。没有人坐下来画过它。没有人声明过边缘。没有人拥有节点之间的接口契约。无论如何，这个图是存在的，每一次提示词修改都是对图中一个节点的更改。选择不在于是否拥有这个图。选择在于是在下一次停机事故为你画出它之前，还是由你先画出它。

路线图中的具体表现​

如果团队从零开始，先后顺序至关重要。清单（Manifest）排在第一位，因为它几乎没有成本，且能立刻让协作问题显现。漂移警报（Drift alerts）排在第二位，因为这是了解图中哪些边缘（edges）实际承重的最廉价方式。活语料库契约测试（Live-corpus contract tests）排在第三位，因为它们需要基础设施投入，且只有在清单和警报揭示了足够多的案例来证明其必要性后，才会产生回报。发布门禁（Release gate）排在最后，因为它是在有效工具之上的政策层，而没有底层工具支撑的发布门禁仅仅是一种官僚负担。

在 2026 年能够大规模交付 AI 产品的团队，并不是那些拥有最佳单一 Prompt 的团队。相反，是那些绘制了依赖图、针对实时分布运行契约测试，并且其漂移警报能准确呼叫对应值班人员的团队。对于这类团队，导致生产环境崩溃的第一次 Prompt 修改只是一个例行事件。而对于其他团队，导致生产环境崩溃的第一次 Prompt 修改则意味着要进入紧急作战室。