AI 功能之间隐藏的边：当一次提示词编辑导致其他三个团队的性能回退时

一位平台工程师修改了公司“品牌风格”序言中的开场白——这是用于统一所有面向客户的助手语气的一行代码。这项改动通过 feature flag 发布。到了周二，搜索团队的相关性退化指标激增，支持机器人的评估通过率下降了四个百分点，入职引导 Agent 的重试率翻了一倍。这些团队中没有一个动过自己的代码。他们都没有收到任何预警。平台工程师对这一切一无所知，因为没人收到过类似的警报：“你的修改刚刚搞坏了三个下游功能。”

这就是定义 AI 团队成立第二年后的典型失效模式。第一年，每个团队都在各自的角落闭门造车。第二年，这些角落开始共享产物——这里一个提示词片段，那里一个种子评估集，或者一个被当作协议复用的工具 Schema。当这种共享变得隐性时，AI 功能之间的依赖图就变得不可见了。你现在拥有的是一个没人能叫出其边缘名称的分布式系统。

解决这一问题的方法论（discipline）并不是一个新平台，而是绘制这张图。

你的 AI 功能实际共享的产物

当工程师谈论服务依赖时，他们指的是 API。服务 A 调用服务 B 的 /v1/users 接口，这一事实会在 API 网关中被记录，依赖关系会作为服务目录中的一行存在，而破坏性变更会强制进行版本化迁移。这张图是可观测的。

AI 功能通过没人编目的产物进行组合。你应该已经在墙上画出来的产物包括：

• 提示词片段 (Prompt fragments)：一个“品牌风格”的序言，一个“保持简练”的指令，一个拒绝回答的模板。这些内容会被粘贴到多个系统提示词中。虽然副本是独立的——每个功能都有自己的副本——但事实来源是非正式的，通常是一个 Notion 页面或一条 Slack 消息。
• 评估种子 (Eval seeds)：功能 B 的评估集是通过采样功能 C 一个季度前的生产 Traces 引导构建的。功能 B 现在认为它拥有了自己的黄金数据集；实际上，它的校准结果与功能 C 在某个时间点的行为绑定在一起。
• 工具 Schema (Tool schemas)：功能 A 将功能 B 的意图分类器作为工具复用。该分类器的 JSON Schema 就是协议。当 B 重构一个参数名称时，A 的工具描述就会发生偏移，其 Agent 循环也会变得更加混乱。
• 判别标准 (Judge rubrics)：你的评估所调用的 LLM-as-judge 提示词是一年前从另一个团队那里派生出来的。现在两个副本都发生了偏移。两者都锚定在特定的短语上，而受测模型有时会机械地重复这些短语。
• 嵌入 (Embeddings)：功能 D 的检索索引使用另一个团队在生产环境中确定的嵌入模型。当该团队升级模型时，功能 D 的向量邻域（neighborhoods）就会发生偏移。
• Traces：你的一半评估覆盖范围是上个季度生产流量的快照。产品变了，但你的评估没变。

2015 年关于 ML 系统中隐藏技术债的论文命名了这种模式：产物产生了未声明的消费者 (undeclared consumers)。系统某个部分的输出被默默地用作另一部分的输入。那篇论文的 2026 年版本只需将“模型输出”替换为“提示词片段”或“评估种子”。同样的错误，只是换了新的产物。

边缘是如何形成的，以及为什么它们保持隐形

AI 功能之间的边缘并不是通过设计评审形成的。它们是通过三种完全人为的捷径形成的。

第一种是复制粘贴。团队 A 的一名工程师在编写系统提示词时，想起了助手团队使用的一个简洁序言。复制，粘贴，发布。现在团队 A 的提示词和助手的序言之间就产生了一个边缘——但这个边缘只是文本，而文本没有图形节点。

第二种是**“借用”消息**。团队 B 正在引导评估，并私信团队 C：“嘿，我能拿几百条你们的 Traces 来填充我们的黄金数据集吗？”团队 C 说没问题。这个边缘现在存在于一条六个月后就会从搜索结果中消失的 Slack 消息里。团队 B 的评估校准被锚定在了团队 C 某一时刻的分布上。当团队 C 修改其功能时，团队 B 的评估不会随之变化——它们被冻结了，导致评估集与现实之间的差距在无形中扩大。

第三种是惯例漂移。组织有一份每个人都应该遵守的“语音和语气”文档。三个团队在编写序言时，对其理解略有不同。六个月后，这三个序言变成了该文档的三个分支，各自独立演进，而一个新功能会将其中之一视为“权威版本”，因为它碰巧被链接到了最新的入职演示文稿中。

孤立来看，这些捷径都没有问题。问题在于这三者在每个季度、每个团队中都在并行发生。由此产生的图谱是真实的——每一个边缘都有可衡量的行为后果——但它不存储在任何人的大脑中，不在任何目录中，也不在任何 CI 中。

2015 年论文中的 CACE 原则——牵一发而动全身 (Changing Anything Changes Everything)——最初是关于 ML 模型纠缠（entanglement）的论述。在 LLM 时代的架构中，它可以推广到产物图谱。触动一个共享产物，就会改变依赖它的每一个功能。不同之处在于，在模型纠缠中，模型至少是一个你可以进行版本控制的显式对象。而 AI 功能团队中的共享产物大多是文本，除非有人专门编写，否则文本是没有版本的。

生产环境中的“未声明消费者”失效模式

这种失效看起来像什么？它看起来像是一个你无法归因的回归（regression）。

助理团队的一名资深工程师发布了一个对通用风格前置提示词（preamble）的“微小措辞清理”。两天后，支持机器人的人工介入升级率开始攀升。支持团队进行调查。他们的模型没有改变。他们的提示词没有改变。他们的评估（evals）结果显示为绿色。他们的工具调用（tool calls）触发正常。他们花了一周时间追查，最终耸耸肩，将其归咎于“模型波动”。三周后，他们不得不削减一个功能来恢复指标。

这种依赖是真实存在的。措辞的清理改变了模型解读下游指令的方式，而该指令引用了前置提示词曾经用来锚定的短语。下游提示词并没有引用前置提示词——它只是依赖于前置提示词已经塑造了模型的先验认知。修复方法本可以是一个一行的回滚（revert）。但没人知道要回滚。那一周的调查成本甚至超过了拥有该前置提示词的团队编写原始更改所花费的成本。

将此类事件乘以每个季度。可见的成本是花费在调试无法归因的回归上的工程时间。不可见的成本是寒蝉效应：团队停止重构共享产物，因为他们无法预测其爆炸半径。现在，你的提示词库中充斥着过时的废弃用语，因为每一次清理的发布风险都太高了。

这正是 2015 年那篇论文警告过的动态。未声明的消费者极大地增加了更改源产物的成本。最终，产物会僵化（ossify）。组织失去了进化自身提示词的能力。

必须落实的纪律

绘制依赖图是一项包含五个部分的纪律。这些步骤都不需要新平台。它们只需要你像对待共享服务一样对待共享产物。

1. 将产物编目为一等公民。 每个提示词片段、评估种子、工具模式（schema）、评委标准（rubric）、嵌入模型（embedding model）和共享追踪数据集都要有名称和记录行。每一行都有负责人。在第一个季度，目录可以只是一个 Notion 表格；形式并不重要，重要的是它的存在。重点在于，你可以用一个名字而不是通过 Slack 搜索来回答“谁拥有这个前置提示词”。

2. 命名边（Edges）。 当团队 A 重用团队 B 的工具作为依赖时，这条边就是由某人拥有的契约。契约规定了 A 依赖什么（这个参数存在、这个输出形状、这个行为）以及 B 允许在不协调的情况下更改什么。这是应用于 AI 产物的消费者驱动契约测试。边就是契约，而契约有维护者。

3. 对共享产物的更改运行 CI 检查。 当一个共享产物被修改时，CI 步骤会查找它的消费者，如果消费者的评估套件没有针对新版本重新运行，则 PR 失败。这是最类似于服务网格（service-mesh）集成测试的做法。这也是现代提示词管理工具体现其价值的地方——那些用于版本控制、测试和对比提示词的工具之所以有用，正是因为它们让跨消费者的回归检查变得可执行。

4. 在 AI 架构流程中加入依赖评审。 当团队发布新的 AI 功能时，评审会问与微服务相同的问题：什么依赖于你，你又依赖于什么？ 团队在发布前画出产物的边。这些边进入目录。发布的条件是这些边已被命名。

5. 每季度审计依赖图。 边会老化。从旧追踪（traces）中生成的评估种子不再具有代表性。派生的评分标准会产生偏差。季度评审会遍历依赖图，标记那些源已更改但消费者未重新校准的边，并安排清理工作。这是 AI 时代等同于服务所有权评审的操作。

这项投资是实打实的——必须有人维护目录、编写 CI 并进行评审——但如果不这样做，代价就是每个季度都在叠加的回归归因税。

当你绘制依赖图时，你实际交付了什么

这一切背后的架构认知是，AI 功能是通过团队未追踪的产物进行组合的。提示词、评估、追踪、嵌入、评委标准。其中的每一个环节，未声明的消费者都可能挂载到未声明的生产者上，而这些边对你的服务目录（service catalog）来说是不可见的，因为你的服务目录仍然认为依赖关系只存在于 HTTP 调用中。

没有绘制产物图谱的组织，距离一次谁也无法归因的多功能回归只差一次共享编辑。而绘制了图谱的组织则能同时获得两样东西：它可以进化其共享产物而不破坏下游功能；并且在面对复盘问题“为什么三个功能同时回归”时，它能给出一个名字和一份差异对比（diff），而不是一个耸肩。

从小处着手。挑选三个重用频率最高的产物——通常是通用风格前置提示词、LLM 即评委的评分标准，以及一两个被高度共享的工具模式——并命名它们的消费者。当你第一次发现一个没人知道存在的边时，你就会明白这为什么重要。当 CI 第一次在合并前拦截了一个共享产物的更改时，你就会知道它奏效了。

图谱已经存在。唯一的问题是，它是存在于你的目录中，还是存在于你的复盘报告中。