Atlassian报告：AI省时超十小时的开发者占比一年从68%降到26%

Atlassian 发布的《2026 年开发者体验现状报告》给出了一组对比数据：过去一年里，每周靠 AI 省下十小时以上的开发者，占比从 68% 掉到了 26%。AI 本身倒是铺得很快，95% 的开发者和 96% 的工程负责人称，自己所在组织已经在工程工作中用上了 AI。

这份报告调查了 2026 年的 1,155 名个人贡献者和 405 名工程负责人。Atlassian 对数据含义的说明相当直白：研究结果“反映的是受访者自我报告的体验和感知，而非部署频率、周期时间或收入影响等系统级遥测数据”，数据中的相关性“不能被解释为因果关系的证明”。

Atlassian AI 与团队协作部门 CTO Taroon Mandhana 这样概括变化：“瓶颈已经转移到管理 AI 的工作上”。

局部的好处并没有消失。87% 的开发者说 AI 让自己交付软件更快，80% 的开发者表示，借助 AI，工作时间没有拉长，活却干得更多了。

可日常干活时的磕绊没见少。只有 28% 的开发者觉得，跟用 AI 之前比，工作里的摩擦明显少了；50% 的人说摩擦程度差不多，报告把这形容为“与使用 AI 之前不同类型的摩擦”。

有些新麻烦就来自 AI 自己。49% 的开发者现在每周要花 4 小时或更多时间去管理 AI 工具，65% 的开发者说，得花时间纠正那些没理解原始意图的 AI 生成内容。工程负责人这边比例更高，分别是 57% 和 72%。还有 29% 的开发者直接把审查或管理 AI 生成的代码列为工作摩擦的来源。

另一些障碍过去三年几乎没动过。查找信息以 51% 排在首位，会议 50% 紧随其后，然后是上下文切换 45%、技术债务 44%。查找信息在 2025 年报告里也是第一，2024 年报告里排第二。编码这件事，从来没进过这份障碍清单。

报告对工作效率衡量方式的批评很直接。60% 的开发者表示，所在组织把 AI 使用情况当成生产力指标；41% 的开发者说，有时候会因为觉得组织有所期待而过度使用 AI。另一边，只有 42% 的工程负责人认为自己手上有能区分实际收益与活动量的正确指标。

为企业工作流构建生产级 AI Agent 的 Shan Huang 回应 Mandhana 时，把其中两个数据连了起来：

如果有人因为觉得组织有所期待而过度使用 AI，那么每周花 4 小时以上管理 AI 输出的那 49% 开发者里，有一部分人碰到的就不是工具问题，而是指标问题。

他把这种现象叫作“表演式吞吐量”：AI 使用量被计入生产力，而清理这些输出的工作却落在了别人的日程上。

Athena Intelligence 的 Taylor Johnson 用一句话给出了替代方案：

AI 活动量不等于实际影响；我们要衡量被接受的工作成果，而不是使用量。

把 AI 战略写清楚的组织还不多，但表现似乎更好。17% 的开发者和 23% 的工程负责人称，所在组织在整个软件交付生命周期中有一套明确且正在积极实施的 AI 战略。这些人里，41% 表示跟用 AI 之前比工作摩擦明显减少；而在认为组织战略不一致或沟通不充分的开发者中，这个比例只有 22%。

Atlassian DevOps 布道负责人 Andrew Boyagi 把这处差距称为关键的区分因素，不过报告自己也提醒，这种关联证明不了因果关系。

过去三年还有一个趋势一直在恶化：认为组织领导层没充分理解自己所面临挑战的开发者，2024 年是 44%，2025 年升到 63%，2026 年到了 66%。

设计师、前 AWS 员工 Cam Turner 提了个实际问题，报告和相关讨论都没给出答案：“一年内从 68% 降至 26%，说明工作已经从创造转向审查。有人在设计审查环节了吗？还是团队只是在默默承担这部分工作？”

关于标题里的数据，有两点要留意。一来，这是一项由开发者工具供应商做的研究，而该公司最终得出的结论，有利于推动 AI 交付流程的正式化。二来，调查样本规模变了：2025 年覆盖六个国家的 3,500 名开发者和管理者，今年只有 1,560 名受访者。另外，两份报告都没公布调查的具体实施日期。

自我报告的工作时间本来就说不准，可能高估，也可能低估。评论者 Harshit Jain 直接把问题摆了出来：比例下降到底是因为审查工作多了，还是组织对开发者的期望抬高了？报告没有区分这两种情况。