2026 年 11 月 · 5 分钟阅读
AI 在部门内省钱，在部门之间卡住
关键定义
交接缝 两个职能之间的边界，价值在这里从一方的产出变成另一方的输入。它通常没有报表出口，也没有明确的主人，所以损耗不会被任何一方统计。
最老一件的年龄 队列里等待最久的那一件已经等了多久。它比平均等待时间更能反映真实影响，因为平均值会把长尾抹平。
返工率 下游退回上游的比例。它量的是上游产出是否可用，而不只是快不快；退回原因集中在同一类时，说明验收标准没有对齐。
凌晨两点，负责社交发布的定时任务醒来，打开自己的待办列表，最上面一条是十二天前上线的一篇文章。文章本身两天就写完了，中英文两版都过了验证，四个网址都返回 200。它等着被改写成几个平台的文案，而这件事不在写文章的那个人手上。
这条缝的存在不奇怪，工作本来就要交接。奇怪的是它十二天没人报出来。写文章的单元看自己的交付，按时上线，达标；做社交的单元看自己的产出，每天有量，也达标。两份周报都是绿的，那十二天不属于任何一个部门的指标，于是它在报表上不存在。
十月底哈佛商业评论发的一篇文章，把这个现象从直觉推到了证据。它的结论是多数企业在部门内部把 AI 用得很好，但没有跨过部门之间的边界，所以整体生产率数据看不到变化。这个判断值得每个正在算 AI 回报的人认真对待，因为如果它成立，问题就不在模型能力上，钱花在了错误的位置。
证据链有三段，指向同一个结论
Hastings、Syverson 与 Zimmerman 在十月二十一日的文章里整理了三个已经发表的调查。第一个是 2026 年初对近六千名高管的调查，其中 69% 说公司在积极使用 AI，超过三分之二的人自己在用，但约九成人报告生产率或就业没有任何可测量的变化。这个调查的原始工作论文编号是 NBER w34836。
第二段是麦肯锡 2025 年的结果，88% 的组织经常使用 AI，只有 39% 报告企业层面的息税前利润受到影响。第三段更窄，一份 2025 年的商业 AI 调查里，只有 5% 的试点产生了可以测量的底线影响。
三份调查的样本和方法都不同，结论却一致：使用率很高，结果很少。这种一致性通常说明存在一个结构性的原因，而不是执行层不够努力。HBR 作者给出的解释是：工具优化的是单个职能内部的工作，而价值要实现，必须跨过职能边界。
要标明这些数字的性质。它们都是企业自报的调查数据，不是审计过的财务结果，第三份报告的发布方是一家商业机构，样本代表性也弱于前两份。用它们的正确方式是把它们当成方向指示，而不是精确基准。
为什么部门内越快，整体越慢
有一个老结论可以解释这个悖论。Amdahl 定律说的是：只加速系统中的一个环节，整体速度的上限由没有被加速的部分决定。一个流程有十个步骤，你把其中一个步骤从十小时压到一分钟，整体时间几乎不变，因为剩下九个步骤还是九小时。
组织的流程就是这个形状，而交接处正是那些没有被加速的部分。AI 让部门内的产出变便宜：写代码、写初稿、翻译、整理数据、生成报告，这些动作的边际成本在下降。交接处没有一起变便宜，因为交接的成本不是生成成本，是等待成本和责任成本。等待要有人看队列，责任要有人签字。
于是相对成本发生了转移。过去生成占八成时间，交接占两成。现在生成压到三成，交接还是那两成，但它占的比例变成了四成。整条链的速度不会提升三四倍，能提升一倍就不错，这也是为什么很多企业报出的部门级效率数字很好看，企业级生产率数字不动。
还有一个反直觉的后果：部门内产出变快以后，交接处的压力会上升。上游每秒产出更多待处理件，下游的处理能力没变，队列就变长。等待时间拉长会吞掉上游省下的全部时间，甚至更多，因为队列里的每一件都有保质期，过期就要重做。
缝上有三个可以测量的量
交接这个说法容易变成空话，要落到数字上，缝上只有三个量值得看。
第一个是等待时间。一件东西从上一步交出来，到下一步开始处理，中间隔了多久。这个量在任何一个有队列的系统里都能取到，不需要新建平台。
第二个是返工率。下游退回上游的比例。这个量比等待时间更能说明问题，因为它量的是上游的产出是否真的可用。退回的原因如果集中在同一类，说明验收标准没有对齐，而不是执行不力。
第三个是归属。交接之后出了问题，谁的名字在记录上。这一条不是数值，但它决定了前两个量会不会被改善。三个量里最容易缺的是它，因为组织天然倾向于让交接处没有主人。
这三个量有一个共同的麻烦：它们在部门边界的中间，不在任何一份报表的出口。每个部门的系统都在自己的出口处统计，导出之后就是别人的数据。所以要么有人专门去跨系统拼一条链，要么就没人看。
拼一条链的成本其实不高。以文章到社交这条链为例，起点时间在内容系统里，终点时间在发布队列里，两边都有时间戳，拼起来是十分钟的活。不做这件事的原因不是技术，是没有人在考核里被要求看中间那段。
把等待换成钱也不难，只要两个假设：链上平均有多少件东西在等，以及每一件每多等一天损失多少。举例说，一条链上常驻三百件，每件每天的价值衰减按业务方估算是一百二十元，等待从三天拉长到十天，一年因为这条缝多出来的损耗大约九十二万元。这个数一算出来，要不要修就不再需要说服，因为它是从两个已经有争议的假设推出来的，而不是从某个人的判断推出来的。
争议本身也是有用的。如果业务方不肯给出每件每天的价值衰减，通常说明这条链上流的东西还没有被定过价，那么问题比交接更靠前，先定价再谈优化。
我们这条链的实测数字
把自己当成样本，比引用别人的调查更有说服力，也更难。我们这条链是：文章上线，进入衍生队列，由另一个单元改写成各平台文案，然后人工发布。队列里累计五十二条记录，已完成 43 条，未处理 5 条，跳过 4 条，最老的一条等了十二天。
四十三条完成、五条未处理的对比不算难看，八成的处理率在多数团队里能交差。但十二天这个数暴露了真实的机制：队列的消费速度由另一个单元的工作量决定，而那个单元没有被要求报告队列里最老的一条有多老。
还有一层更细的原因。文章的生命周期是两天写、当天上线，社交文案的生命周期是几小时的热度。两个周期差了一个数量级，而交接正是发生在周期的接口上。上游按周计划，下游按小时运作，中间的时差不会自己缩小，只会堆在队列里。
说清楚我们的局限。这条链的规模小，五十二条记录不足以支撑统计结论，十二天也可能是一次异常而不是常态。它的价值是提供一个可核对的例子：同一个组织，两个单元各自的指标都正常，中间那段烂了十二天。这不是技术问题，是组织没有把那段当成工作。
我们也没有完全修好它。现在做的是把最老一条的年龄放进每日检查，超过三天就升级。这是一个告警，不是修复。修复需要下游单元的人真的把队列当成自己的库存，而不是当成别人送来的订单。
修缝的三种做法，以及各自的判据
第一种是把验收搬到缝上。上游交付时，同时交付一份下游可以直接用的东西：不是任务描述，是判据。比如文章交付时带上核心判断的一句话、可引用的数据点、允许的改写边界。下游拿到这三样，改写不需要回头问，等待时间就掉下来。
判据是能不能在无沟通的情况下完成下游工作。如果下游必须问三个问题才能开工，说明上游交付的东西不完整，等待时间里有一半是上游造成的。
第二种是把队列深度做成告警。不测平均等待时间，测最老一条的年龄。平均值会掩盖长尾，一件压了三十天的东西和三十件压了一天的东西，平均都是差不多的一天，但对业务的影响完全不同。判据是这个告警有没有真的被响应过，只有被响应过一次的告警才算存在。
第三种是把返工率算进上游的指标。谁的产出被退回，退回率记在谁头上，而不是记在负责验收的那个单元。这一条最难推，因为它改变了考核，但它是唯一能让上游主动改善交付质量的做法。判据是退回原因有没有被归类，如果所有退回都记为质量问题，这个指标就失效了。
三种做法有顺序。先做第二种，因为最便宜，一周内能出数；再做第一种，因为它需要两个单元坐下来对齐，成本高一点；最后做第三种，因为它动考核。顺序反过来做，通常做不动。
不是所有缝都值得修
把跨职能优化说成普遍原则会制造浪费。有几类交接不该花钱去测。
低频交接。一个季度才发生一次，等待三天的成本可以忽略，为它建监控是负收益。低价值交接同理，上下游的产出本身不值多少钱，优化它省下的是零。
还有一类是延迟本身在设计里。跨监管边界的交接需要人工复核，等待是合规要求，把它压到零就是把风险放出去。这类缝的正确做法是明确写下可接受的等待上限，而不是消灭等待。
判断标准可以简化成一句话：这条缝一年造成的等待如果换成钱，能不能覆盖测量它的成本。算不出来就先别测，算得出来而且数字不小，那就值得一次专门的对话。
我们的判断
企业 AI 的回报差异，正在从模型能力的差异转成流程接口的差异。谁把交接处当成一个有人负责的工作对象，谁就能把部门内的效率换成企业级的结果；谁把交接处当成理所当然的空白，谁的效率提升就会停在报表的边界上。
这个判断有一个可以检验的推论：如果一家企业报出的 AI 收益集中在某些部门的内部指标上，而企业级的交付周期、库存周转、客户等待时间没有变化，那么它的 AI 投入大概率停在缝的左边。
给你的三个动作
第一，选一条你熟悉的跨部门链，把起点和终点的时间戳拼出来，算出最老一件的年龄。这件事一天能做完，不需要任何人批准。
第二，问下游一个问题：上游交付的东西，你开工前需要回头问几次。答案如果是三次以上，缝的问题在交付形态上，不在下游能力上。
第三，把这条链的等待上限写进一个岗位的职责，写进它的周报。缝上没有主人的时候，它会一直烂下去，而且没人报出来。
留一个问题给做预算的人：你们今年 AI 的收益，有多少是在单个部门的指标里被证明的，有多少是在两个部门之间的时间差里被证明的。前者的数字通常好看，后者的数字通常才是客户感受到的那个。
来源
外部数据均来自下列公开页面，内部数据来自公司衍生队列的运行记录。
NBER Working Paper w34836（近六千名高管调查的原始工作论文，由 HBR 文章引用）
McKinsey，The state of AI in 2025（88% 经常使用、39% 报告企业级息税前利润影响的出处）
MLQ，State of AI in Business 2025 Report（仅 5% 试点产生可测量底线影响的出处，商业机构发布，样本代表性弱于前两份）
常见问题
为什么部门内效率提升没有变成企业级生产率+
单点加速的收益被没有加速的环节封顶。交接的成本是等待与责任，AI 不降低成本，反而因为上游产出变多而拉长队列，把省下的时间吃回去。
三个调查的结论一致吗+
一致但性质不同。近六千名高管的调查说 69% 在用 AI、约九成报不出生产率变化；麦肯锡 2025 说 88% 常用、39% 有企业级利润影响；另一份报告说只有 5% 试点有可测底线影响。都是自报数据，方向可信，精度有限。
缝上最该测哪一个量+
最老一件的年龄。它最便宜，一周内能取到数，而且比平均值更能暴露真实影响。等待时间平均值会把一件压三十天的情况藏起来。
修缝应该按什么顺序+
先做队列年龄告警，再做交付判据，最后把返工率算进上游考核。顺序反过来的话，第一步就要动考核，通常推不动。
哪些缝不该花钱去测+
低频、低价值、以及延迟本身属于设计要求的交接，比如跨监管边界的人工复核。判据是这条缝一年造成的等待换成钱，能不能覆盖测量成本。
你们自己修好了吗+
没有完全修好。现在把最老一条的年龄放进每日检查，超过三天升级。这是告警不是修复，真正的修复要求下游把队列当成自己的库存。
拿你自己的执行日志跑一遍
交一份脱敏的近 30 天 agent 执行日志，48 小时内拿到八行表：八项技术项每项一行，每格带分子、分母和判据，缺口按是否要改 schema 排序。前三单 ¥8,000。
相关文章
提交涨了三成，关闭的需求没多一件
700 多家公司引入编码智能体后，代码涨 30%、提交涨 20%，需求关闭率没有统计显著变化。产量记在提交上，回报结在关闭上。
供应商撤场之后，智能体还改得动吗
到 2028 年，七成企业会弃用驻场工程建成的智能体。交出来的东西里没有判断对错的标准，改一条规则没人能证明没改坏。
我们自己就是第一个客户——OOMeta 如何用 AI 运营公司
我们自己就是第一个客户：1 个人类创始人 + 7 个 AI 阿米巴单元，每天协作运营一家真实公司。本文复盘数据流如何把信号变成行动，以及效率、覆盖面、一致性的实际结果与踩过的坑。
试点期那层人工审阅，就是你的评测集
78% 的企业有智能体试点，14% 扩到全公司。差别不在模型：试点期那层人工审阅同时充当了评测集、标准定义和异常兜底，扩量把它删掉了。