共享提示服务问题：多团队 LLM 平台与依赖噩梦

一个周二下午，某中型 AI 初创公司的平台团队合并了一个对共享系统提示的"小幅改进"。到周四，三个独立的产品团队相继提交了 bug。一个团队的评估套件准确率从 87% 跌至 61%。另一个团队的 RAG 流水线开始产生幻觉引用。第三个团队的安全过滤器完全停止拦截某类有害输出。四天后，没有人把这些问题联系起来。

这就是共享提示服务问题，任何拥有多个团队基于同一 LLM 平台进行开发的组织都会遭遇它。

这一底层动态并不新鲜。共享服务会产生依赖问题。LLM 场景之所以更糟，是因为提供者与消费者之间的契约是不可见的。当后端团队修改 REST API 时，类型系统会立刻报错。当平台团队编辑系统提示时，失败是静默的、概率性的、延迟出现的。你的 CI 流水线保持绿色，评估套件甚至可能捕捉不到问题。性能下降会在数天后通过用户反馈浮现——而此时你已经在损坏的版本之上又叠加了三次变更。

提示服务问题，本质上是一个行业尚未意识到的依赖管理问题。

为什么共享提示的失效方式与共享 API 不同

当工程团队共享一个微服务时，契约是明确的：这是模式，这是错误码，这是版本策略。消费者团队针对该契约编写集成测试，提供者团队在部署前运行这些测试，破坏性变更需要版本号升级和迁移指南。

共享提示基础设施中，这一切都不存在。系统提示通常存储在配置文件、数据库表或部署环境变量中。任何有访问权限的人都可以修改。提示变更与下游行为之间的关系是概率性的——同一变更可能让某些消费者退化，对另一些毫无影响，甚至意外改善第三个消费者。

这产生了软件团队无法应对的几种失效模式：

静默语义漂移。 一个细微的词汇变化——从"严格输出有效 JSON"改为"始终以整洁、可解析的 JSON 响应"——看起来表面无关紧要，能通过代码审查。但前者强制执行严格的模式一致性，后者允许尾随逗号和可选必填字段。下游的每个解析器都会出错，而这一变更直到生产环境才被发现。

不可见的消费者耦合。 A 团队的评估套件隐式依赖于共享系统提示在结论前生成结构化推理这一事实。B 团队将系统提示改为直接生成简洁答案而不展示推理过程。A 团队解析中间推理步骤的评估套件悄然失败——不是因为 B 团队有错，而是没有人知道 A 团队有这个依赖。

版本-模型交互失败。 当平台团队同时修改提示并升级底层模型时，回滚变得危险。回滚模型会让为升级后模型设计的新提示与旧模型配对——一个没人测试过的组合。

这些不是边缘情况。对数百个团队 LLM 生产事故的持续研究表明，提示变更是生产质量回归的主要驱动因素，且大多数在到达用户之前未被自动化测试发现。

面向 LLM 平台的消费者驱动契约测试

软件行业已经为服务间 API 解决了这一问题的变体。消费者驱动契约测试（CDC），由 Pact 框架推广，颠倒了依赖关系：不是由提供者定义它交付什么，而是由每个消费者定义它需要什么。提供者在自己的 CI 流水线中运行每个消费者的契约，任何破坏消费者契约的变更在部署前都会被阻止。

这一模式可以清晰地迁移到共享 LLM 基础设施中，令人惊讶的是，几乎没有平台团队实施过。

实践中的样子如下：

每个消费共享提示服务的团队注册一个行为契约。契约不仅仅是 JSON 模式——它是一组测试用例，规定：给定这种类型的输入，经共享服务处理后，输出必须满足这些属性。属性可以是结构性的（响应包含名为 rationale 的字段）、语义性的（响应不推荐不安全行动）或质量评分的（LLM 作为评判者的评估必须返回 ≥ 0.8 的相关性分数）。

当平台团队提议修改提示时，CI 会针对修改后的提示运行每个已注册的消费者契约。任何契约失败，变更即被阻止；所有契约通过，变更就可以安全部署——至少对于已注册要求的消费者而言如此。

这同时实现了两件事：保护消费者免受意外破坏；并使隐式依赖变为显式——编写契约的行为迫使团队明确表达他们实际依赖什么，这往往会揭示他们不知道存在的耦合。

提示的语义版本控制

一旦将提示视为有消费者的服务，版本控制就变得必不可少。语义版本控制——软件包中的 major.minor.patch 惯例——自然映射到提示变更上：

• Patch（1.0.0 → 1.0.1）：修复错别字，措辞重述但不改变行为。消费者无需更新任何内容。
• Minor（1.0.0 → 1.1.0）：增加能力或提升质量但不改变输出模式或破坏现有消费者测试的改进。消费者可按自己的节奏采用。
• Major（1.0.0 → 2.0.0）：需要消费者团队更新代码或评估的输出结构、推理方式或行为策略变更。

坚守这一分类的纪律有一个有用的副作用：它迫使平台团队严格思考对语言模型行为而言"向后兼容"意味着什么——这个问题没有简单答案，但团队需要明确而非通过期待来隐式回答。

相关概念是兼容性矩阵：记录哪些提示版本已针对哪些模型版本和哪些下游流水线版本进行了测试。这很重要，因为给定提示可能已针对模型版本 A 验证，但未针对模型版本 B。该矩阵防止了在并发升级期间出现的"未测试组合"失效模式。

能赋能而不造成瓶颈的审查门控

对任何审查流程的标准反对意见是它会制造瓶颈。平台团队本已人手不足，增加审批工作流将拖慢依赖它们的团队。

正确答案是将门控设计为：仅阻止真正危险的内容，让其他所有内容自动通过。

以下是有效的三层方法：

第一层——确定性检查。 首先运行，失败立即阻止，无需人工审查。修改后的提示是否仍能生成格式良好的 JSON？是否仍能避免禁止的内容类别？是否仍能返回平台承诺的必填字段？这些检查只需几秒钟。

第二层——质量回归检查。 自动化评估套件针对一组代表性查询运行修改后的提示，并与基线分数比较。如果质量下降超过允许公差——比如任何跟踪指标下降五个百分点——变更在晋升前会被标记以供人工审查。这一层捕获了确定性检查遗漏的微妙行为漂移。

第三层——消费者契约验证。 这是 CDC 层。每个已注册的消费者契约针对修改后的提示运行。这里的失败不是标记——而是硬阻止。平台团队必须修复回归，或者如果变更是有意破坏性的，则与消费者团队协调进行主版本号升级并给予迁移时间。

结果是一个门控：几分钟内自动批准大多数补丁变更，对质量边缘案例需要人工判断，并防止破坏性变更在无消费者签字的情况下到达生产环境。平台团队可以在安全变更上快速迭代，消费者无需参与每次小更新的审查循环即可获得保护。

LLM 网关需要支持的内容

使这一切可行的工具层是 LLM 网关——应用层与模型提供商之间的代理，处理路由、速率限制和可观测性。大多数团队已经有了类似的东西，提示契约管理所需的额外内容很少：

版本感知的提示服务。 网关必须能够按请求提供特定提示版本。消费者团队明确固定到某个版本（prompt_version: "1.2.0"），网关将该版本注入每个请求。这让团队控制何时采用新版本，消除了"所有人同时获得新提示"的问题。

追踪中的版本标记。 每个推理请求都应记录使用了哪个提示版本和哪个模型版本。这使得事后将质量变化与特定提示部署相关联成为可能——这就是在不需要一周考古工作的情况下调试"上周二某些东西变了"事件的方式。

提示变更的金丝雀路由。 在将修改后的提示推广到 100% 流量之前，将一小部分请求路由到新版本并实时监控质量指标。如果指标下降，自动回滚。这以与代码部署相同的渐进式交付纪律对待提示部署。

消费者级访问控制。 并非每个团队都应该能够修改共享系统提示。网关强制执行哪些团队可以读取或写入提示定义，以及每个团队固定到哪个提示版本。

工具无法替代的组织层

实施提示版本控制和契约测试的平台团队会发现，工具解决了技术问题但暴露了组织问题：没有人明确定义谁拥有共享系统提示、谁批准主版本变更，以及当必须进行破坏性变更时平台团队对消费者团队承担什么 SLA。

这些不是工程问题，而是需要明确决策的治理问题：

• 所有权。 一个团队必须拥有共享系统提示并对其质量负责。共享所有权意味着无人拥有。
• 变更策略。 主版本变更需要消费者团队签字。次要变更需要通过所有已注册契约。补丁变更在第一层和第二层检查通过后自动发布。
• 迁移支持。 当必须进行主版本变更时，平台团队必须提供迁移时间表——通常是旧版本和新版本同时可用的双服务期——并支持消费者团队完成过渡。
• 契约注册作为前提条件。 希望免受破坏性变更影响的团队必须注册其契约。未注册的团队在提示变更意外影响它们时没有立场抱怨。这是正确的激励：注册契约成本低，被意外破坏代价高。

大多数组织不需要为此建立正式的 RFC 流程。一个共享文档、一个公告变更的 Slack 频道和一个 CI 门控，对大多数团队来说已是足够的基础设施。

改变你思维方式的洞见

根本性的转变是停止将系统提示视为配置，开始将其视为 API 契约。

配置是非正式的、可随时更改的，由任何有访问权限的人拥有。契约是明确的、有版本控制的，受消费者保护约束。你的团队应用于 REST API 版本控制的同样工程严谨性——向后兼容保证、变更日志纪律、迁移指南、弃用时间表——同样属于多个团队依赖的共享提示面。

这不是关于官僚主义，而是关于认识到：当五个团队隐式依赖一段控制模型行为的文本时，那段文本就是承重基础设施。它值得与数据库模式或消息队列格式变更同等的关注。

早期建立这种纪律的团队，将是那些共享 AI 平台能够快速推进而不会悄然破坏内部消费者的团队。没有建立这种纪律的团队将继续在事发四天后从用户投诉中发现提示回归——每个周四都在调试根本原因是周二下午配置变更的事件。