影子提示词库：治理一个无人拥有的资产类别

走进几乎任何一家拥有在线 LLM 功能的工程团队，问一个简单的问题：谁负责管理提示词（Prompts）？你会听到一阵停顿，然后是一个耸肩，接着是一个经不起推敲的回答。“产品经理写了第一个版本。”“PM 在上个迭代（Sprint）里改了一下。”“我觉得它在某个 Notion 文档里，或者可能是 agent.ts 里的那个 const SYSTEM_PROMPT。”提示词正在生产环境中运行。它决定了用户看到的内容，决定了智能体采取的操作，也决定了下季度收入图表中显示的数字。然而，它的治理覆盖面甚至不如那个没人愿意承认动过的 CSS 文件。

这就是影子提示词库：堆积如山的字符串——系统提示词、few-shot 示例、工具描述、路由规则、评估器准则——它们共同定义了产品行为，却集体缺乏代码审查、部署流水线、负责人、弃用策略和审计追踪。它们是你 AI 技术栈中最关键的承重构件，也是受监管最少的环节。

后果已不再仅仅停留在理论层面。现在有 98% 的组织报告存在未经授权的 AI 使用，近一半的组织预计在 12 个月内会发生影子 AI 事件。监管机构的步伐比治理速度更快：欧盟 AI 法案（EU AI Act）的高风险条款将于 2026 年 8 月生效，其中第 12 条明确规定，将输出结果与提示词及模型版本绑定的日志必须是自动生成的，而非设想中的。如果你的提示词散落在十几个代码库和一个 Slack 讨论串中，你拥有的不是审计追踪，而是隐患。

为什么提示词逃脱了治理网

代码之所以受到严格审查，是因为它存在“摩擦”。它存放在代码库中，通过拉取请求（PR）开启审查，运行 CI，部署流水线记录谁在何时发布了什么。而提示词绕过了每一个关口，原因往往是平庸而非恶意的。

提示词看起来就像一个字符串。字符串并不让人觉得具有架构意义。当一名 PM 提交了一个将 You are a helpful assistant that... 改为 You are a precise assistant that... 的 PR 时，差异审查者只看到了一个单词的微调并予以批准。没有人重新运行评估（Evals）。没有人检查下游分类器（它期望在推理追踪中看到“helpful”）是否仍能正确解析。这项更改在 30 分钟内发布。两周后，某个特定客群的留存率下降了 5 个百分点，却没人能解释原因。

提示词也存在于尴尬的接缝中。一半在代码里，一半在提示词管理 SaaS 里，一半被粘贴在配置文件里，还有一半被硬编码在模型会读取但审查流程不会覆盖的工具描述中。各部分的加总并不等于整体，因为每个团队都孤立地解决提示词存储问题，没有对整体负责。

最后，提示词会默默地腐化。一个在 gpt-4-0613 上运行完美的提示词，在后继模型上可能会性能下降，而无需任何代码更改——模型的指令遵循分布发生了偏移，突然间你的 few-shot 排序不再能固定输出格式。这里没有编译器警告。第一个信号通常是用户投诉或支持工单，而此时静默回归已经发生数周。

缺乏治理的词库的四种失败模式

在寻求解决方案之前，请准确定义失败模式。它们各不相同，需要不同的控制手段。

沉默的语义偏移。提示词的修改在不改变代码公开契约的情况下改变了行为。一个曾经用于分类“退款请求”的路由提示词，现在将其中一些分类为“账单问题”，导致两条下游路径发生分歧。代码审查者只看到了单词的变化，以为只是文案润色。

孤儿提示词。编写提示词的工程师离职了。定义它的 PM 调岗了。提示词仍在生产中运行，但没人再知道“正确”的输出应该是什么样，任何改进尝试都只是在猜测一个已经不在场的人的意图。

模型版本不兼容。你的提示词是针对某个模型调优的；供应商弃用了该模型，或者你为了节省推理成本而迁移模型。新模型在公开基准测试上表现“绝对更好”，但在你提示词的特定分布上表现“绝对更差”。没有人将提示词与它们校准过的模型进行映射。

审计追踪缺失。监管机构、企业客户的安全审查或内部事件响应询问：“这个输出是如何生成的？”你能找到模型名称和时间戳。但你无法检索到当时运行的准确提示词文本，因为提示词在那之后已经被修改了六次，而日志只捕获了提示词 ID，没有捕获内容。或者捕获了内容但没有版本。或者捕获了版本，但关联的是一个已被强制推送（force-push）覆盖掉的 git SHA。

每一个都是不同层面的治理失败：变更审查、所有权、兼容性和日志记录。单一工具无法解决所有四个问题。

提示词注册表作为基础

第一步是给提示词一个“家”。不是一个文件夹，也不是一个 Notion 页面——而是一个注册表（Registry），它具备容器注册表或模型注册表的核心属性：命名的组件、不可变版本、可查询的元数据以及稳定的检索 API。

一个有效的注册表在每个提示词版本中应包含四个基本字段：内容本身、作者和时间戳、解释变更的提交信息，以及该版本已知兼容的模型集。添加环境标签（dev、staging、prod），以便版本可以显式地进行提升，而不是通过部署隐式地进行。添加指向该提示词验证过的评估套件的指针，这样“已知兼容”就是一个可以验证的断言，而不是凭感觉。

注册表应该是生产环境代码读取提示词的唯一来源。这是有争议的一部分，因为它打破了将提示词硬编码到源文件中的便利模式。但只要提示词可以在不经过注册表的情况下被编辑，注册表就只是一个博物馆。强制执行这一路径——通过 Linter 标记生产代码中的内联提示词字符串，或者更务实地，通过运行时检查，如果提示词并非来自注册表，则拒绝调用模型。

团队通常会抗议这增加了延迟和失败模式。解决方法是缓存：在服务启动时拉取提示词，并订阅失效通知。这样你就能获得受注册表管控的治理能力，而不会产生任何请求路径上的开销。

真正改变行为的变更评审

注册中心能阻止熵增，但不能提高审美。为此，你需要一种将提示词（Prompt）编辑视为行为变更而非文案编辑的评审流程。

最小可行流程包含三道关卡。第一，由作者以外的 diff 评审人签字同意——这与你应用到代码上的规则相同。第二，在固定的黄金数据集（golden set）上自动运行回归评估；如果核心指标的波动超过了预设阈值，则阻止合并，或者要求提供书面正当理由进行显式覆盖。第三，“下游消费者”检查：任何依赖此提示词输出的智能体（Agent）或服务都必须重新运行其评估，而不不仅仅是拥有该提示词的服务。

大多数团队在第三道关卡上表现不佳。当一个提示词是多个智能体的上游依赖时，一个词的改动可能会悄无声息地改变属于不同团队的路由流量。如果没有下游消费者契约，作者就无法判断影响范围——他们是在黑暗中编辑并祈祷。应使依赖关系图显性化，并让评估运行自动化。

围绕这一流程最难的组织问题并非技术问题，而是：谁有权合并？如果只有工程师可以批准，那么 PM 和领域专家——这些真正理解预期行为的人——就会被排除在他们自己的创作之外。如果任何人都可以批准，评审就失去了意义。答案是按角色分权限的所有权：每个提示词都有一个声明的所有者负责批准内容变更，以及一名工程师负责批准该提示词暴露的检索或工具调用接口的任何变更。两个签名，关注点不同，但在同一个 PR 中。

模型兼容性标签与弃用生命周期

将每个提示词版本视为针对特定模型修订版进行的校准。记录它，检查它。除非工程师持签署过的迁移工单进行显式覆盖，否则拒绝针对不在兼容性列表中的模型运行提示词。

在你经历过一次没有任何兼容性数据的供应商弃用事件之前，这听起来可能很繁重。迁移时的混乱会演变成整整一周时间，针对后继模型重新调优每个提示词，没有优先级，没有回归预算，也不知道哪些提示词会崩溃。有了兼容性标签，你可以获得一份清晰的“针对即将弃用模型校准的提示词”列表，并根据流量大小和业务关键程度排列优先级。

提示词本身的弃用生命周期与 API 弃用类似。草案 → 已发布 → 已弃用 → 已移除，每个状态迁移都会在注册中心显现并传播给消费者。达到“已弃用”状态的提示词仍应运行——向后兼容性很重要，就像 API 一样——但新的消费者不能采用它，并且会有一个移除倒计时。Stripe 关于 12 到 24 个月 API 支持窗口的策略在这里可以完美借鉴。重点不在于具体数字，而在于生命周期是声明性的，而非随意的。

监管机构真正接受的审计踪迹

“我们会记录提示词日志”并不等同于审计踪迹。当监管机构询问某个特定的用户侧输出是如何生成时，需要重构完整的链条：哪个提示词版本、哪个模型版本、哪些检索到的上下文、哪些工具响应反馈到了循环中，以及哪些策略标签处于激活状态。这种重构必须在事实发生六个月后依然有效，即使在那期间提示词已被编辑了八次，模型也迁移了两次。

实际的形式是：每次模型调用都记录一个提示词版本 ID（而非提示词字符串），该 ID 指向注册中心中不可变的内容，外加模型 ID、哈希后的检索上下文，以及一个将调用与用户行为及下游输出关联起来的请求 ID。日志必须具有防篡改特性——经过签名或仅限追加——因为可以被重写的审计踪迹不是真正的审计踪迹。日志还需要符合监管窗口的保留策略，在金融和医疗行业，这一期限可长达数年。

《欧盟人工智能法案》第 12 条并未规定具体模式，但其潜在要求非常严苛：系统本身必须自动生成这些记录，无需人工干预。事故发生后手动拼凑的日志是不算数的。这是一个塑造整个技术栈的设计约束——如果你后期才补丁式地加上日志，你很可能会通不过审计，因为这种补丁会漏掉那些通过带外方式更改提示词的情况，而这恰恰是审计员会问到的情况。

谁拥有注册中心

影子库（shadow-library）不断回归的问题归根结底是组织问题，而非技术问题。谁拥有注册中心？

在大多数组织中，有三个候选者在竞争。平台工程部门负责基础设施，希望注册中心表现得像个可靠的服务。AI 或 ML 团队负责模型和评估框架，希望注册中心能强制执行质量标准。法律或合规部门则要求保留政策、访问控制和审计踪迹保证。但他们谁都不想负责提示词的内容。

我见过的有效模式是联邦模型。平台部门负责“注册中心即服务”——可用性、访问控制、模式演变以及与部署流水线的集成。每个产品团队负责其命名空间下的提示词，由一名指定的负责人负责签署内容变更，以及一名产品负责人负责签署行为变更。AI 平台负责横向的评估框架和兼容性矩阵。法律部门设定保留和审计要求，但不批准具体变更。

当团队没有配备人员来履行其所有权职责时，这种联邦模式就会失败。一个没有提示词工程师或类似职位的团队，最终其命名空间下的提示词还是会发生漂移——影子库卷土重来，只是换了个更高级的马甲。唯一可持续的解决方法是将提示词的所有权视为一等公民的角色职责，就像测试所有权一样。如果一个团队发布了一个 LLM 功能，那么发布的同时必须有人对其中的提示词负责。

在被淹没前开始

完整的治理栈——包括注册表、评审工作流、兼容性标签、弃用生命周期、审计追踪和分级所有权——对于一个成熟的平台团队来说，意味着一整年的工作量。面对这份清单以及生产环境中三百个未分类 prompt 的团队，可以从小处着手，依然能获得大部分价值。

从发现开始：在代码库中 grep 明显的 prompt 字符串，从团队已有的 prompt 工具中导出数据，访谈团队负责人。哪怕只是整理出一份部分清单，也能改变对话的基调。“我们在七个服务中大约有 180 个 prompt，其中四个已上线生产且测试覆盖率为零” 是具有可操作性的。而 “我们在某些地方有 prompt” 则不是。

然后，仅针对新 prompt 强制推行注册表的使用，并为现有 prompt 的迁移设定一个日期。不要尝试在同一个季度内既清理影子库又构建注册表；一项任务会淹没另一项任务。接下来交付审计日志，因为这是第一个监管机构或企业安全审查会关注的内容，而且其交付边界非常清晰。

等到兼容性标签和下游消费者评估落地时，这个库将成为受管资产，而不再是风险暴露面。更重要的是，它将拥有明确的负责人。当 “谁负责这些 prompt？” 这个问题得到的不再是耸耸肩，而是一个具体的名字时，这才是影子库拥有未来的第一个真正标志。