AI 用了一年，效率到底提升了多少？这个问题在季度会上越来越难答。这篇拆一份 1560 人的开发者调查：时间省在哪，又被什么吃掉。写给要向上汇报的 IT 负责人，和要拍板的老板。六分钟。
季度经营会。老板问：AI 推了一年，研发效率提升了多少。
IT 负责人翻开报表：95% 的开发者在用，87% 说交付变快了。
老板接着问：那上个月那个版本，为什么还是延期两周。
会议室安静了一下。不是没人想答，是没人答得上来。
这个场景我们见过不止一次。报表没造假。问题在于，报表量的是"用没用 AI"，老板问的是"交付有没有变快"。这两件事中间隔着一整条链路，而那条链路里，没人统计过。
数据来自 Atlassian《2026 年开发者体验现状报告》，调查了 1155 名开发者、405 名工程负责人。两个数字要放在一起看。
87% 的开发者说，AI 帮助他们更快交付软件。80% 说，在不延长工作时间的前提下完成了更多工作。这部分是真的：局部环节确实提速了。
但同一份报告里，只有 28% 的人说，与使用 AI 之前相比，工作中的摩擦明显减少。50% 的人说摩擦程度基本相同。报告对这个现象的描述是：摩擦没有消失，只是换成了"与使用 AI 之前不同类型的摩擦"。
对老板的意义：单看"AI 有没有用"，答案永远是有用。但你要的答案是"交付周期有没有缩短"，那是另一道题。这两道题用同一份数据回答，就会得出一个都对的结论，和一个都错的判断。
最能说明问题的是这组对照。过去一年里，每周靠 AI 省下 10 小时以上的开发者比例，从 68% 降到 26%，降了一半多。同期 AI 使用率已经推到 95%。用得更多，省得更少。
时间去哪了？报告里的三组数指向同一个方向：
49% 的开发者每周花 4 小时以上管理 AI 工具；
65% 要花时间纠正没能理解原始意图的 AI 产出；
29% 把审查、管理 AI 生成的代码直接列为工作摩擦来源。
工程负责人这边更高：管理 AI 工具、纠正 AI 产出的比例分别是 57% 和 72%。本该盯着交付的那层人，被 AI 的产出盯住了。
Atlassian AI 与团队协作部门 CTO 的判断很直白：瓶颈已经转移到管理 AI 的工作上。注意"转移"这个词，不是消失。
我们见过的项目里，这件事的形态很具体：一个人原来一天写两百行，现在一天能产出八百行。评审的人没变，还是那两个。结果不是交付提前，是评审排队。AI 提速的收益，先卡在了下一个环节的吞吐量上。
再看这张障碍榜。过去三年，开发者自报的工作障碍几乎没变化：查找信息 51%，排第一；会议 50%；上下文切换 45%；技术债 44%。
编码从来没有出现在这张榜上。
这句话值得说两遍。开发者最大的障碍一直不是写代码。所以，AI 在编码环节提的速，很难如实体现在交付周期上——它加速的那一段，本来就不是堵点。
延期的真实原因通常是另一套：需求口头改了三次，没落进文档；接口等对方排期；测试环境和生产环境不一致；验收标准到上线前一周才定。这些环节，AI 一个都碰不到。
对甲方的含义很实际。如果你的延期原因写下来是"等"和"改"，那 AI 提效不会改变你的交付周期，只会让中间环节更快地产生更多需要对齐的东西。原来一周攒一次争议，现在一天攒三次。
报告里还有一组数，值得直接发给管理层看：
60% 的开发者说，所在组织把 AI 使用情况当作生产力指标；
41% 说，有时会因为觉得组织有所期待而过度使用 AI；
42% 的工程负责人认为，自己手上有能区分"实际收益"和"活动量"的正确指标。
一位做企业级 Agent 的工程师给这种现象起了个名字：表演式吞吐量。AI 使用量被算进生产力，而清理这些产出的工作，落到了别人的日程上。
另一位从业者的说法更像一条验收标准：要衡量被接受的工作成果，而不是使用量。
这条规律不新。当年统计代码行数，就得到过又长又碎的代码。区别在于，AI 让造数据变便宜了：一次对话、一次生成，都能计入"使用"。
同一份报告里分了两群人对比，差距很明显。
17% 的开发者、23% 的工程负责人说，所在组织在整个交付链路上有明确、且正在实施的 AI 战略。这群人里，41% 说与用 AI 之前相比摩擦明显减少。在认为组织战略不一致、沟通不充分的那群人里，这个比例只有 22%。差了近一倍。
还有一条趋势在恶化。认为领导层没有充分理解自己所面临挑战的开发者，2024 年是 44%，2025 年 63%，2026 年 66%。
这不是"老板不懂技术"的问题。是 AI 这件事在组织里没有落到具体的人头上：工具买了，账号开了，然后就没有然后了。谁用、用在哪、出了问题谁负责，全靠各团队自己领会。
四件事可以一个月内定完，不额外花钱：
一、划范围。哪些环节允许 AI 直接产出，哪些必须人工过一遍。写成清单，别靠个人自觉。
二、定人。谁负责审查 AI 的产出，这活算不算工时。不算，就等于让审查的人用自己的时间补贴项目。
三、定数。用什么判断有没有效。返工率、缺陷逃逸数，不是调用次数。
四、签字。出了问题谁签。AI 不承担责任，责任必须落在人。
报告的边界也得说清楚，否则这些数字容易被用坏。它是开发者自报的体验数据，不是系统遥测；2025 年样本是六国 3500 人，2026 年是 1560 人；报告自己也写明，数据里的相关关系不能当作因果。所以这些数字适合用来提问，不适合用来下判决。
这个季度，把"AI 使用率"从周报里删掉，换成一个数：AI 产出的代码和文档，被接受之后一个月内的返工比例。
这个数降不下来，用多少 AI 都没意义。这个数降下来了，你不用再向任何人解释 AI 有没有用。
你们团队现在用哪个数衡量 AI 的效果？是使用率，还是返工率？留言说说，我一条条回。
回复「清单」，领《SaaS 上线 90 天采纳率自查清单》。里面有一页就是"上线后该盯哪几个数"，可以直接抄进周报。
拜腾科技 · 帮企业把 AI 接进业务系统的开发团队
