AI 旁观者效应：为什么五支团队协作发布却交付了无人问津的评估套件

1964 年，三十八个人在皇后区的公寓楼外目睹了 Kitty Genovese 遭到袭击。直到为时已晚，才有人报警。Latané 和 Darley 在接下来的十年里一直在解释其中的原因：看到问题的人越多，其中任何一个人采取行动的可能性就越小。他们称之为“责任分散效应”。在他们著名的癫痫实验中，当参与者认为只有自己和受害者在一起时，85% 的人会介入。当他们相信另外四个人也能听到受害者发病时，只有 31% 的人采取了行动。

现在想象一下你最近一次 AI 功能的发布。产品团队编写了 Prompt。工程团队选择了模型并连接了网关。数据团队整理了检索语料库。安全团队加上了输入和输出过滤器。客服团队起草了升级方案。房间里有五个团队。每个团队都按时完成了各自的部分。三个月后，该功能的准确率悄悄从 89% 滑落到 71%，评估套件自发布周以来就没运行过，当你询问谁负责处理这一回归问题时，每个团队都能点出另外三个比自己更有责任负责的团队。

这就是 AI 旁观者效应。它不是一个新的 Bug。它是社会心理学中最古老的 Bug，被移植到了一个新的基质中。这个基质很重要，因为 AI 功能失败的方式与组织在过去二十年中学着去配备人员的确定性软件不同。这些失败是无声的、渐进的、概率性的。它们不会给任何人发警报，也不会破坏构建。它们表现为客户满意度评分的缓慢漂移，最终季度业务复盘（QBR）将其追溯到一个几个月没人碰过的发布版本。

为什么 AI 功能的设计容易诱发旁观者效应

关于责任分散的文献指出，旁观者在未能采取行动之前会经历三个阶段：事件感知（注意到有问题）、社会扫描（观察周围人的反应）以及责任分散（结论是别人更有资格或更有义务介入）。

传统软件通过监控来攻克第一阶段。报警响起、仪表盘变红、发布被回滚。事件是明确的。相比之下， AI 功能的失败方式却很模糊，这恰恰触发了旁观者文献所警告的认知陷阱。4% 的有用性评分下降可能是季节性的。新的拒绝模式可能是模型提供商悄无声息的量化，也可能是没人记录的周末 Prompt 调整。长尾话题上幻觉的增加可能是语料库问题，或者是上下文窗口问题，亦或是温度参数的回归。信号是真实的，但原因却具有歧义，而歧义正是责任分散的催化剂。

第二个阶段被大家在 AI 工作中普遍采用的跨职能人员模型放大了。当回归出现时，每个团队都会扫描其他团队。产品团队看向工程团队。工程团队看向数据团队。数据团队看向模型提供商。安全团队看向最后触碰 Prompt 的人。集体性的扫视变成了集体性的耸肩。Latané 和 Darley 一眼就能认出这种模式。

第三个阶段——责任分散——才是真正的组织失败所在。每个团队都能构造出一个合理的理由来解释为什么回归不属于他们。产品团队拥有 Prompt 模板，但 Prompt 模板没变，是背后的模型变了。工程团队负责模型选择，但模型选择遵循了供应商的建议，评估的偏差是一个产品问题。数据团队拥有检索语料库，但语料库是静态的，分块（Chunking）是工程决策。安全团队负责防护栏，但防护栏的误报是一个 UX 问题。每个故事部分都是真实的。它们凑在一起，构成了不作为的完美 alibi（辩护）。

五个隐形的交接点

大多数生产环境中的 AI 功能至少有五个交接点，在这些点上，对输出质量的所有权会悄然消失。在发生时，没有一个看起来像是在交接。

第一点是 Prompt 与评估的割裂。产品团队编写 Prompt，因为 Prompt 最接近产品规格。评估套件（Eval suite）由工程团队编写，因为评估看起来像测试，而测试是工程交付成果。结果是，最清楚“什么是好结果”的人没有在运行套件，而运行套件的人却无法判断失败模式是否仍然符合产品对质量的实际定义。当差距扩大时——而且它总是会扩大——双方在技术上都在履行职责，只是输出结果不再按照任何人当前认为的标准来衡量。

第二点是模型与系统提示词（System Prompt）的割裂。工程团队负责“我们使用 Claude Sonnet 4.5”或“我们以这些延迟限制路由到 GPT-5”。包裹每一次用户对话的系统提示词存在于一个配置文件中，由最近处理客户升级的团队进行修改。变更日志（如果存在的话）就是一个 Slack 频道。当模型升级时，没有人针对新模型重新验证系统提示词。当系统提示词微调时，没有人重新运行跨模型评估。每一方都认为另一方才是把关环节。

第三点是语料库与分块（Chunking）的割裂。数据团队负责检索索引中的内容——摄取什么、何时摄取、使用什么过滤器。工程团队负责如何对其进行拆分、嵌入和检索。用户问题的一个糟糕回答可能是覆盖率缺口（数据问题），也可能是将相关段落分散在两次检索中的分块选择（工程问题）。诊断这种差异需要花费数小时。大多数团队只是将其归结为“RAG 很难”然后继续前进。

第四点是防护栏（Guardrails）与回归预算的割裂。安全团队拥有输入和输出过滤器。没有人负责这些过滤器允许误判的预算。一个拦截了 0.3% 合法用户查询的防护栏对安全团队来说不像是问题，因为误报率符合规范。对产品团队来说，这看起来像是 0.3% 的转化拖累，但转化仪表盘并不显示防护栏的遥测数据，因此这种拖累在原本会关注它的团队面前是不可见的。

第五点是发布与观察期（Soak）的割裂。产品团队负责发布。工程团队负责部署。没有人负责发布后的四周窗口期，在这个窗口期内，随着用户行为偏离受控的灰度发布，需要对功能进行观察。一旦发布复盘完成，该功能就进入了运维真空。下一次有人查看评估分数是在下一次季度业务复盘时，到那时，回归已经累积了九十天。

90 天模式的真正含义

行业内有一种观察：生产环境中的 LLM 功能往往在 90 天内出现明显的性能下降。这种现象通常被归结为模型漂移（model-drift）或提示词漂移（prompt-drift）问题。但更准确地说，这其实是一个注意力漂移（attention-drift）问题。模型和提示词的漂移速度与以往基本持平。在 90 天这个时间点上真正发生的变化是：上线团队已经完全解散并回到了各自的原部门，评测套件（eval suite）不再针对每个版本运行，而客户支持团队也开始习惯性地将早期性能下降视为“这个功能的常态”。

行业调查显示，约三分之二的企业在部署后的 12 个月内发现了可衡量的 AI 性能下降，而其中只有极少数组织能在用户发现之前察觉到问题。这背后的逻辑很简单：当责任分散时，回归（regression）开始与组织正式注意到它之间的时间差，等同于该回归与某个职业生涯直接受此影响的人之间的时间差。如果没有指派这样的人，这个时间差的唯一上限就是最终客户投诉的响亮程度。

这并非工具层面的缺失。持续评测、漂移监控和回归告警的工具已经随处可见且迭代迅速。瓶颈在于，这些工具输出的信号没有传递给一个对输出质量承担最终责任的人。它们只出现在仪表盘（dashboard）上。而仪表盘是不会被开除的。

组织设计的解决方案：指定一名质量 DRI

在有关“旁观者效应”的文献中，被公认为最有效的干预措施就是通过指定个人来打破责任分散。“你，那个穿红衣服的——快打 911。”同样的机制也适用于 AI 功能。输出质量必须成为一个一等公民角色，并对应一个具体的名字，而不是一个由五个团队协作产生的共同责任。

这个角色既不是某种新型的工程经理，也不是换汤不换药的 ML ops 主管。它更接近于传统软件交付中的质量工程（QE）组织，但针对概率性的 AI 场景做了三点修正。DRI 拥有作为产品的评测套件，包括其覆盖范围、随失败模式演进的过程以及执行频率。他们拥有回归预算（regression budget）——即功能被视为不健康的明确阈值，以及一旦超过该阈值后的明确应对方案。此外，他们拥有跨团队的升级处理权（escalation），有权将功能回退到之前的提示词、模型或护栏（guardrail）配置，而无需与五个不同的工程经理反复协商决策。

这个角色并不是阻碍发布的质量警察。真正行之有效的纪律更接近于轮值（oncall）：由指定的个人轮班，负责当周的输出质量，并配备清晰的交接流程和操作指南（runbook）。评测套件就是他们的传呼机。回归预算就是他们的 SLO。那种让五个团队在发布时允许有缺陷的评测套件上线的分散责任心理，与让常规软件轮值生效的心理是一样的：当有一个具体的名字时，旁观者的认知阶段就会坍缩。你无法再寄希望于他人。

要避免的错误是让现有员工兼任此职。一个“顺便负责 AI 质量”的产品经理其实并不对 AI 质量负责，因为当回归问题需要做出一个不受欢迎的决定时——比如撤回功能、停止模型升级、阻止提示词更改——兼职 DRI 更有动力去顺从他们正在阻碍进度的那个团队。这个角色存在的意义恰恰是为了承担这些决策带来的社交成本。将角色分散化会把社交成本重新摊派回那些因相互推诿而产生问题的团队。

在下次 AI 功能上线前要问的问题

在下一个 AI 功能发布之前，诊断性的问题不是“我们有评测套件吗”或“我们的护栏调优了吗”。而是：在报告回归问题的会议上，幻灯片上写的负责修复该问题的具体姓名是谁？如果答案是一个团队、一个工作组、一个专项行动，或者“我们会在发布后搞定它”，那么这次发布就存在旁观者问题，而回归问题已经提上日程了。模型会漂移，提示词会被微调，语料库会过时，评测套件会落灰——这并不是因为任何一个团队失职，而是因为只要组织容忍这种模糊性，谁该负责的问题就永远无法定论。

解决方案不在于更多的流程。而是一个具体的名字。