AI 功能的 RACI 模型：为什么四个绿色仪表盘组合在一起却是一个破碎的产品

一个 AI 功能在周二出现了回归。评估（eval）CI 是绿色的。护栏（guardrail）仪表盘很干净。检索（retrieval）P95 指标正常。模型供应商没有任何故障。然而，支持队列中挤满了用户，他们反映助手“本周感觉变差了”。产品经理（PM）是房间里唯一能说出哪里回归的人，但即便是她也无法告诉你哪个仪表盘能捕获到这个回归。欢迎来到“接缝 Bug”（seam bug）的世界——这种故障中，每个单独的产出物负责人（artifact owner）都能证明自己的部分没问题，但集成后的体验依然是坏的。

这是 AI 功能人员分配方式的必然结果。纸面上的负责人名单看起来很合理：提示词作者负责系统提示词，评估负责人负责离线测试集和 CI 门禁，工具/检索负责人负责函数调用和搜索索引，护栏负责人负责审核和策略过滤器。此外，还有一个模型选择决策，通常游离在这四者之外——有时归属于平台团队，有时归属于最近提交采购单的那个工程师。五个负责人，却没人对“这个功能对用户是否有用”负责。

这种模式在各个团队中都非常一致，以至于值得给它起个名字。称之为 集成负责人缺失（integration owner gap）。它是产生接缝 Bug 的组织设计根源：在最需要责任感的地方出现了明显的空白。下面将讨论这种缺失的代价、为什么通常的 RACI 练习会忽略它，以及如何在不创造冗余中间管理层的情况下，用最小化的结构来填补它。

四个产出物负责人及其共同的失败

打开任何生产环境 AI 功能的轮值 Wiki，你通常能找到按产出物划分的四个负责人：

• 提示词作者 —— 负责系统提示词、少样本示例（few-shot examples）以及注册表中的提示词版本。KPI 通常是某种形式的“提示词回归率”或“在固定测试集上相对于旧版本的胜率”。
• 评估负责人 —— 负责离线评估集、CI 质量门禁、LLM-as-judge 配置。KPI 是“故障模式的评估覆盖率”和“回归测试的误报通过率”。
• 工具/检索负责人 —— 负责函数调用 Schema、检索索引、分块（chunking）和嵌入（embedding）流水线。KPI 是“工具成功率”和“检索查准率/查全率”。
• 护栏负责人 —— 负责输入过滤器、输出脱敏、拒绝策略，有时还包括审核 API。KPI 是“策略违规率”和“误拦率”。

每一个都是合理的产出物。每一个都是可衡量的。每一个都有仪表盘。但没有一个衡量真实用户是否得到了有用的答案。这个缝隙就是接缝 Bug 滋生的地方，它是结构性的——而不是因为哪个负责人懒惰。评估负责人无法扩展测试集来覆盖尚未见过的 Bug；护栏负责人无法针对没人报告过的故障模式收紧策略；提示词作者无法针对仅在检索索引发生偏移时才出现的问题进行消融实验。每个负责人都是局部最优，但全局不足。

经典例子：周一进行了模型升级。提示词作者重新运行了黄金测试集，胜率超过了败率，于是签字通过。工具负责人注意到函数调用 Schema 依然有效，于是签字通过。护栏负责人看到策略过滤器的通过率没有变化，于是签字通过。评估负责人看到 CI 质量门禁在容差范围内，于是签字通过。到周五，支持工单显示助手在某一类问题上的建议变得微妙地糟糕，而这类问题没人放入评估集，因为在升级之前没人知道这类问题的存在。每个产出物负责人都能证明自己尽了职。但用户可见的质量还是下降了。

隐藏的第五个负责人：模型选择

模型升级本身通常没有明确的负责人。实际上，决策通常来自三个地方之一，且都不理想：负责采购和发布但不负责任何用户可见功能的平台团队；某位恰好关注了发布说明的高级工程师；或者一份自上个季度以来就没人更新过的“模型策略”文档。结果是，影响范围最大（同时触及提示词行为、工具可靠性、检索相关性和护栏误报率）的变更反而得到了最轻量级的审查。

如果你在读完本文后不做其他任何事，请将模型选择设为一个明确的 Accountable（负责）角色，而不是一个默认发生的决策。Accountable 是 RACI 中最容易被误解的部分；每个决策只能有一个 Accountable 负责人，且该负责人有权批准或否决。针对特定功能面的模型升级应当由指定的负责人负责，并且在发布前，每位产出物负责人都必须与其进行 Consulted（咨询）。

接缝 Bug：存在于组件之间的问题

接缝 Bug 是四个产出物仪表盘都无法检测到的故障类别。简要指南如下：

• 提示词-工具接缝： 提示词礼貌地要求模型“在有疑问时使用搜索工具”，但由于模型现在对更多问题变得更有信心，它停止了搜索并开始产生幻觉。工具成功率没有变化（只是调用次数变少了）。评估覆盖了模型过去搜索且现在依然搜索的情况。没人负责“模型搜索次数低于预期”这个问题。
• 工具-护栏接缝： 在嵌入模型升级后，检索系统开始呈现略有不同的分块（chunks），而针对旧分块分布调整的护栏现在拦截了它过去允许的响应。检索看起来很健康；护栏误拦率上升了 0.3%——远低于任何告警阈值——但集中在某一特定用户细分群体中。
• 评估-提示词接缝： 提示词作者在系统提示词中增加了一条新指令以解决最近的故障。评估集是在六个月前固定的，并没有测试新指令与旧指令之间的交互。新指令在针对的案例中胜出，却悄无声息地使与之冲突的其他所有部分发生了回归。
• 护栏-评估接缝： 护栏负责人收紧了策略。评估 CI 通过了，因为评估提示词没有触发新策略。在生产环境中，该策略在评估集未能代表的长尾合法请求中生效了。

注意其规律：这些回归都可以描述为“负责人 A 做了在负责人 B 的假设下是正确的变更，只不过那些假设已经发生了偏移”。回归是真实的，产出物是完好的，但接缝断裂了。接缝 Bug 不是一种 Bug，它们是负责人的缺失。

真正有效的 RACI 调整

天真的修复方案是每当发生变化时就召开工作组会议。这无法规模化扩展，并且会产生一种事事都要“咨询”每个人的文化，这在功能上等同于无人负责。修复方法是增加 一个指定的角色，并对其拥有的职责保持绝对的严苛：

角色	职责
集成负责人 (新角色)	对功能界面的 集成用户体验 负 责 (Accountable)。负责合并了用户可见指标的生产级仪表盘。当缝隙证据表明集成体验将出现退化时，有权阻止四个产物负责人中的任何一个进行发布。
Prompt 作者	对 Prompt 产物 负 责 (Responsible)。当集成负责人为了解决缝隙 Bug 而需要修改 Prompt 时，作为 咨询对象 (Consulted)。
Eval 负责人	对 Eval 产物 负 责 (Responsible)。当集成负责人希望添加跨产物边界的 Eval 时，作为 咨询对象 (Consulted)。
工具/检索负责人	对 工具和检索产物 负 责 (Responsible)。当变更影响到 Prompt 的工具使用分布时，作为 咨询对象 (Consulted)。
护栏 (Guardrail) 负责人	对 护栏产物 负 责 (Responsible)。当政策变更影响到 Eval 集的代表性时，作为 咨询对象 (Consulted)。
模型选择	由指定个人负 责 (Accountable)（通常由集成负责人兼任）。所有四个产物负责人均为 咨询对象 (Consulted)。产品经理 (PM) 在决策前（而非之后）被 知会 (Informed)。

集成负责人不是管理岗位。这是一个个人贡献者 (IC) 角色，其成功衡量标准与任何产物负责人都不相同。他们的 KPI 是某种形式的“集成体验的用户可见质量”——任务完成率、投诉率、定性审查，或者是产品关注的任何指标——并且这些指标明确涵盖了各个组件间的缝隙。他们的权力在于：如果他们有证据表明存在缝隙回归 (Seam Regression)，他们可以阻止 Prompt、Eval、工具或护栏的变更发布，而产物负责人无法绕过他们。

最后一点是团队最容易出错的地方。如果集成负责人可以被四个产物团队中任何一个的高级工程师否决，那么这个角色就变成了咨询性质，缝隙 Bug 就会卷土重来。只有当权力是真实存在的时候，这个角色才能发挥作用。

覆盖界面而非产物的值班机制

这种组织架构体现的另一个地方是值班 (On-call)。大多数 AI 功能的值班轮换仍然隐含地以产物为导向：Prompt 团队处理 Prompt 事故，Eval 团队处理 CI 失败，工具团队处理函数调用故障，护栏团队处理政策事故。当告警内容是“X 分层的用户反馈助手自周二以来变得更糟了”时，这些轮换小组都不知道该怎么办。

最简单的修复方法是建立 集成值班轮换——每班由一名工程师负责集成界面，他拥有所有四个产物仪表盘以及用户质量仪表盘的读取权限，并且他在处理缝隙 Bug 告警时的首要工作是 不要立即将其分配给某个产物负责人。过早分配正是缝隙 Bug 被忽视的原因。集成值班人员的首要工作是以用户可见的方式描述回归特征，然后决定涉及哪些产物。通常答案是“不止一个”。

一个有用的模式：每一次缝隙 Bug 的复盘 (Postmortem) 都要产生至少一个跨产物边界的新 Eval 案例——例如，一个只有在检索出正确内容、且 Prompt 正确使用该内容、且护栏没有拦截响应时才能通过的 Eval 案例。纯粹的单一产物 Eval 案例是必要的，但它们无法检测缝隙回归。跨产物 Eval 属于集成负责人，而不属于 Eval 负责人，因为当没有任何 KPI 取决于这些 Eval 时，Eval 负责人没有动力去维护它们。

规划产物：将变更映射到缝隙

另一个值得投入的结构化工具是单页的“变更影响矩阵”，对四个产物中的任何一个进行的任何变更都必须填写该矩阵。问题很简短：

1. 此变更直接触及四个产物中的哪一个？
2. 此变更可能扰动哪些缝隙？（矩阵列出了六个两两组合的缝隙，加上“模型升级”这一横切案例。）
3. 此变更需要咨询 (Consulted) 哪些产物负责人？
4. 是否需要集成负责人签字？（对于任何涉及两个或更多产物的变更，默认需要。）

如果你将其作为没人看的 Jira 模板来实现，那就是官僚主义。如果你将其作为在代码审查中强制执行的五行 PR 描述块来实现，它就是核心支撑。重点不在于形式，而在于强制每个产物负责人在发布 之前 思考缝隙问题，而不是在生产环境中才发现它们。采用这种做法的团队报告称，最常未通过矩阵检查的变更就是模型升级，这恰恰是默认决策对他们伤害最大的案例。

领导层的决策

这一切都不需要重组。它需要 AI 功能界面的工程负责人有意识地以书面形式做出四个明确的选择：

1. 谁是该界面的集成负责人？ 指定个人，而非团队。
2. 他们的 KPI 是什么？ 必须衡量集成体验的用户可见质量，且不能简化为任何产物级的指标。
3. 他们拥有什么权力？ 具体来说：他们能否阻止四个产物负责人中任何一人的发布？如果不能，该角色就无法发挥作用。
4. 谁是模型选择的问责 (Accountable) 负责人？ 通常由集成负责人兼任；无论哪种方式，都必须指定到人。

之所以必须明确，是因为默认状态——没有集成负责人、模型升级默认落地、值班按产物划分——就是失效模式。AI 功能在软件工程中之所以特殊，正是因为它们的质量是四个移动部件的交叉产物，而这个交叉产物不属于任何人的自然领地。发布出色 AI 功能的团队已经通过艰苦的方式明白了这一点，有时是在经历了第二次或第三次“Eval 指标是绿色的但用户很讨厌它”的事故之后。尚未意识到这一点的团队也即将面临这一刻。

下次当你团队的 AI 功能出现回归而每个产物仪表盘都是绿色时，不要先去找 Bug。先去看看组织架构图。回归所在的缝隙，正是角色缺失的缝隙。