开发者每周借助 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 直接把问题摆了出来：比例下降到底是因为审查工作多了，还是因为组织对开发者的期望抬高了？报告没有区分这两种情况。