3 篇博文 含有标签「org-design」

两年前，组建 AI 卓越中心（CoE）是一项负责任的举措。当时没人知道如何评估模型，采购部门不清楚推理合同该是什么样，而法律部门则希望有一个明确的责任方。将那十个懂行的人集中到一个中心团队显然是正确的做法。

如今，正是这个团队导致你的产品工程师为了修改一个 Prompt 要等上六周。CoE 审查每一次系统消息（system-message）的修改，掌握着公司唯一的评估框架，并由一个每两周开一次会的委员会来把持模型升级。团队已经察觉到了这一点。他们开始使用个人 API 密钥发布产品，在 CoE 永远看不到的 Notebook 中运行评估，并将客户数据粘贴到任何响应最快的工具中。你并没有防止影子 AI —— 而是你创造了它，并给了它一个需要躲避的治理机构。

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

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

大多数 AI 功能都死在"在 notebook 中可行"和"在生产环境可行"之间的鸿沟里。不是因为模型不好，而是因为构建模型的团队和拥有产品的团队从未坐在同一间会议室里。AI 团队拓扑问题——AI 工程师在组织架构中的位置——悄然成为你的 AI 投资能否上线的最大预测因素。

数据印证了这一点。只有大约一半的 ML 项目能从原型走到生产环境，在成熟度较低的组织中，失败率高达 90%。与此同时，CircleCI 的 2026 年软件交付状态报告发现，尽管 AI 辅助代码生成使功能分支吞吐量提升了 59%，中位团队的生产分支产出实际上下降了 7%。代码写得前所未有地快，只是没有上线。