提示词所有权问题：当康威定律盯上你的 Prompt 时

每个复杂的 AI 产品最终都会产生一个谁也不敢碰的 prompt。它包含三个条件分支，两个在处理客户报告的事故时临时粘贴进去的内联示例，以及一个以 “IMPORTANT:” 开头的句子，后面跟着一段没人记得是谁写的语气指令。这个 prompt 长达 1,400 个 token。最后一次修改它的 PR 是由一名早已转岗的工程师审核的。当新模型发布时，没人敢保证这个 prompt 依然有效。当评估（evals）结果下降时，没人确定是 prompt、模型、检索流水线还是下游工具导致的。这个字符串被四个服务共享。每个团队都有自己的本地覆盖（override），而且这些覆盖都没有文档记录。

这就是 Prompt 所有权问题，它是多团队 AI 工程中讨论最少却最普遍的失效模式。这不只是一个技术问题，而是康威定律（Conway's Law）在 token 层面的体现。一个组织的 prompt 最终会反映出它的组织架构、RACI 缺口和协作成本——而模型并不关心你的 Jira 层级，它只会为同样不在乎这些的终端用户产生不连贯的行为。

Prompt 变得无人认领的速度之所以比代码快，是因为它们处于行为设计、模型推理和评估这三个领域的交汇点——而这三个领域通常由不同的团队负责，有着不同的指标和审核流程。一个 prompt 既是产品界面（助手该说什么），又是建模产物（如何引导模型），还是回归风险（一旦修改，评估系统就会报警）。当一个角色负责编写，另一个角色负责部署，第三个角色负责评估，第四个角色处理技术支持工单时，缓慢的质量流失就会被忽视，因为没有任何一个人拥有完整的闭环所有权。等到有人察觉时，责任早已分散到 “谁搞坏了它” 变成了一个考古学问题。

为什么 “在我的团队运行良好” 是一个支撑性的借口

在任何 prompt 评审中，最具启发性的一句话是：“它在我们团队的用例下运行良好。” 这句话的潜台词是，说话者已经针对符合其团队产品范畴的输入、预期和下游消费者分布测试了该 prompt，并暗示其他团队接受这一证据作为通用验证。

这种情况几乎从未实现过泛化。一个适用于账单相关问题的支持助手 prompt，可能会在退款流程中失效，因为其语气指令是针对投诉解决数据调优的，而非政策披露数据。一个适用于工程变更日志的摘要 prompt，在处理法律备忘录时可能会产生危险的、“自信满满”的总结。一个在某个团队的评估集上得分 94% 的 prompt，在另一个团队的评估集上可能只有 71%，这不是因为 prompt 变差了，而是因为数据分布不同，且评估集是由针对不同长尾场景进行优化的人编写的。

这句话之所以奏效，是因为它在局部是真实的，在社交上是可辩护的，而且如果不重新在另一个团队的数据上运行评估，就无法证伪。而大多数组织并没有一个共享的评估基础设施，能让这种证伪过程变得低成本。于是 prompt 发布了，其他团队的用户遭遇了无声的回归，而失效表现会在三周后的技术支持工单中出现，并被分派给第四个团队。

每个多团队 AI 组织都需要一个针对这句话的常规应对方案。答案不是 “证明我错了”，而是一个共享的评估框架（eval harness），让任何利益相关者都能在候选 prompt 变更生效前，用自己具有代表性的固定测试数据（fixtures）对其进行测试。如果没有这个，“在我的团队运行良好” 默认会赢得每一场争论。

RACI 缺口：四个角色，零个所有者

一个有用的练习是绘制生产环境中 prompt 的实际生命周期，并针对每个阶段询问谁是负责人（Responsible）、问责人（Accountable）、咨询人（Consulted）和知情人（Informed）。在大多数组织中，答案大致如下：

• 创作。产品工程师或 prompt 工程师编写初始草案，通常是在应用程序代码的功能分支中。他们是负责人。目前还没有问责人，因为 prompt 尚未落地。
• 评审。PR 由同行评审，他们检查代码更改是否编译成功，以及 prompt 是否没有明显的冒犯性。评审人员很少是 prompt 专家。他们不为行为回归负责；他们只为代码差异（diff）负责。
• 部署。发布工程师交付构建版本。他们不知道 prompt 发生了变化。他们对可用性负责，不对输出质量负责。
• 评估。如果组织有评估团队，他们可能会对发布版本运行下一批预定的评估。等到他们标记出回归时，变更已经在生产环境中运行好几天了。他们是知情人，而非问责人。
• 事故响应。当出现问题时，技术支持工单降临，分派工程师进行调查，一个小型的作战室（war room）随之成立。作战室必须通过逆向工程找出谁拥有这个 prompt 才能进行修复。

这种模式下，四个不同的角色接触了 prompt，而问责方——即当 prompt 回归时被 call 醒的值班人员——往往根本不在其中。RACI 的黄金法则——即必须有且只有一个人负责问责——被悄悄违反了。责任在角色之间的缝隙中消散，而这些缝隙正是工作走向终结的地方。

解决这个问题不需要新工具。它需要为每个 prompt 指定一名明确的所有者。一个类似 CODEOWNERS 的文件，将每一个生产环境中的 prompt——不是包含 prompt 的文件，而是每一个 prompt 本身——映射到特定的个人和特定的团队。那个人负责审核每一次变更。那个人在发生回归时会被 call。那个人有权阻止变更，包括来自不同团队的变更。一旦你添加了这个文件，你会发现有一部分 prompt 竟然无人认领。通过这个练习，你对组织的了解将比过去六个月的回顾会（retros）还要深刻。

共享提示词库的失效模式

一旦一个组织有超过三四个产品在使用 LLM，通常会有人——通常是平台团队——建议建立一个共享提示词库。这听起来很正确。提示词的编写成本高，评估（eval）成本也高，而且具有通用价值。共享提示词库应该能减少重复工作，提高一致性，并让一小群提示词专家为所有人提升质量底线。

实际发生的情况是，从使用者的角度来看，共享库变成了一个只读的产物。每个团队都会 fork 它。fork 出来的版本留在团队自己的仓库里，并增加了团队特定的修改。原始库在它自己的仓库中继续演进，由它自己的维护者管理，与那些 fork 版本脱节。当上游库发布质量改进时，没有任何 fork 版本会同步，因为没有哪个团队有预算去重新对齐和重新评估。当上游库引入回归（regression）时，也没有任何 fork 版本能察觉到，因为它们已经偏离了主线。共享库同时产生了两种债务：分歧债务和维护债务。这两者在爆发之前都是不可见的。

另一种能在真实组织中生存下来的模式是：薄共享原语与厚团队所有组合 (thin shared primitives and thick team-owned compositions)。共享库拥有小的、可测试的构建块——例如安全前导词、结构化输出契约、多轮澄清模式。团队将这些原语组合成特定产品的提示词。共享库与使用者之间的契约是狭窄且版本化的。使用者按照自己的节奏进行升级。由于每个原语都有自己的评估套件，回归的影响范围很小。这并不能消除协调工作，但它将“只要共享库变动，一切都可能崩溃”的无限协调，转变为版本化依赖的有限协调。

更深层次的教训是，共享提示词库是一个产品，而不是一个公用事业。它需要自己的 PM、自己的弃用政策、自己的支持轮值以及针对使用者迁移的 SLA。那些在没有这些配套措施的情况下启动共享库的团队，实际上是在发布一项无人负责的免费服务，而无人负责的免费服务是得不到维护的。

评估所有权的不对称性

第二个所有权问题在更深一层。即使每个提示词都有明确的所有者，那些把关提示词变更的评估套件（eval suites）通常却没有。在大多数组织中，评估集是由恰好关注某个特定失效模式的工程师编写的，存储在最初编写它们的目录中，并由当前感到痛苦的团队临时维护。

这造成了严重的不对称。修改提示词的人要对其负责，而当提示词变更触发评估警报时，评估集的作者充其量只是被咨询一下。评估作者通常甚至不知道他们的评估已经运行了。因此，当评估出现回归时，提示词所有者有两个不讨好的选择：修复提示词，或者调试别人的评估。调试别人的评估是一项缓慢、地位低且没有明确成功标准的工作，因为评估本身可能是错误的。许多提示词变更会悄悄忽略评估回归，将其归为“不稳定 (flaky)”或“已知失败”，因为做其他任何事情的成本都高得令人望而生畏。

解决办法是将评估集作为像提示词一样的一等公民资产来管理。每个评估集都有一个维护者。评估集捕获的每个失效模式都应该链接到引发该模式的事件或工单。当评估不稳定时，维护者在限定时间内修复它；当它出现回归时，提示词所有者会联系维护者。这在组织层面类似于传统软件工程中的测试所有权，不同之处在于 LLM 的评估更嘈杂、更主观，这提高了协调的门槛。

如果组织将评估视为一种共享基础设施的杂活，最终必然会得到一套没人信任的评估套件，这在功能上等同于没有评估套件。信任是长期可见维护的产物。没有指定维护者，就没有维护，信任也就无从谈起。

重构组织以闭合循环

如果这一切听起来更像是组织问题而不是 AI 问题，那正是我要表达的核心观点。康威定律指出，系统架构会反映组织的沟通结构。在提示词工程中的实际应用是，你应该先设计沟通结构，然后让提示词架构顺势而为。

一些在实践中有效的具体重构模式：

• 每个生产环境提示词都有一个明确的负责人，并记录在提交至仓库的文件中。没有歧义，没有分散的责任。
• 带有团队贡献测试用例 (fixtures) 的共享评估框架。任何利益相关者都可以添加回归案例。任何提示词变更在合并前都要运行完整的框架。
• 提示词变更与评估差异 (eval diffs) 同行。修改提示词的 PR 必须在 PR 描述中展示哪些评估案例发生了变化以及变化了多少，作为合并的门槛。
• 由事件生成评估，而不仅仅是修复补丁。每一个与提示词相关的事故都必须产生一个能捕获该问题的评估案例。这能将部落知识转化为机构记忆。
• 共享原语的指定管理员。共享提示词库及其组件拥有具备弃用权限的在岗所有者。
• 设立一个单一的跨职能角色——称之为提示词管理员、行为主管或模型产品工程师——来掌控整个闭环。一个人能够编写提示词、阅读评估、与模型研究员交谈，并回复支持工单。这个角色是解决“提示词在我的团队能用”这类组织问题的答案，因为现在有人专门负责发现它在其他地方是否不能用。

那些在发布 AI 产品时没有严重的长期质量问题的组织，通常都已经吸取了教训。他们的组织架构图中有一个职位的头衔包含“提示词”、“行为”或“模型”，且具有跨职能属性。他们的代码仓库中有一个 PROMPT_OWNERS 文件。他们的部署流水线中有一个评估关卡。他们的事故回顾中包含“什么样的评估能捕获此问题”的部分。这并不神秘，这就是传统软件工程在 2010 年代学会的纪律，现在被应用到了一种新的资产类别中。

核心要点

提示词不仅仅是字符串。它们同时是生产界面、建模产物和回归风险。当提示词的编写、评估、部署和支持分属于四个不同的团队，并使用四种不同的指标时，康威定律（Conway's law）确保了提示词会映射出这些团队之间的协作成本——而你的用户，他们将助手视为一个统一的声音，最终会感受到这种不一致性。解决办法不是寻找更好的工具。解决办法是指定一个负责人，构建一套共享的评估体系（eval），并设立一个专门的岗位，其全部职责就是负责维护这个闭环。这样做，提示词就不再是组织的负债。忽略这一点，每一次模型升级、每一次功能发布以及每一次团队重组，都将成为静默回归（silent regression）降临在用户身上的契机，而用户根本不知道为什么助手突然变难用了。