过去一年里，几乎所有工程负责人都被问过类似的问题：“你们的 AI 生产力提升了多少？”
提问者期待的往往是一个醒目而简单的数字，但现实远比这种叙事复杂得多。关于 GenAI 在软件工程中的影响，研究证据远没有新闻标题和厂商宣传所呈现得那样一致。因此，本周的问题是：关于 AI 与开发者生产力的那些流行观点，到底有哪些得到了研究支持？
背景
围绕 GenAI 的行业讨论，发展速度已经远远超过了相关研究的积累速度。
今天，许多企业的采购决策、人员规划以及季度 OKR，都在受到产品演示、个别案例以及少量受控实验的影响，而这些实验往往是在高度简化的任务环境中完成的。随后，工程负责人又被要求把这些零散信息转化成适用于自己团队的判断。
问题在于，许多最流行的论断实际上建立在并不成立的假设之上。
如果开发者一天的大部分时间根本不是在写代码，那么编程助手究竟能带来多大改变？如果仪表盘上显示的是“AI 生成代码行数”，那么这个指标究竟衡量了什么？随着越来越多研究者开始观察真实团队的工作方式，一些广为流传的叙事正在受到挑战。
研究发现
在最近发表于 ACM Queue 的一篇文章中，多位知名生产力研究者（其中包括 SPACE 框架的共同作者）系统梳理了软件工程领域关于 GenAI 最顽固的八个神话。
他们综合分析了近年来的大规模研究成果，其中包括微软于 2025 年开展的一项覆盖 450 多名工程师的研究、开发者访谈，以及大量现场研究（field research）的综合结果。
神话一：开发者大部分时间都在写代码
事实并非如此。
微软 2025 年的研究显示，开发者平均只有大约 14% 的工作时间真正用于编写代码。更早的研究结果也与此相符：状态较好的一天里，这个比例约为 18%；状态较差的一天里，则只有 11%。
换句话说，开发者一天的大部分时间实际上消耗在会议、设计讨论、代码审查、沟通协作以及各种非编码活动上。
神话二：写代码才是开发流程的主要瓶颈
如果编码本身只占工作时间的大约 15%，那么即使 AI 能把编码速度提升一倍，总体生产力提升也很难超过 15%。
更重要的是，加快代码生成速度往往只是把压力转移到了后续环节。代码审查、测试、集成和上线等流程仍然需要同样的时间，因此开发中的“外循环（outer loop）”并没有发生本质变化。
很多团队看到代码生成速度变快，却误以为整个交付流程都变快了，而实际情况往往并非如此。
神话三：代码行数是衡量 AI 价值的最佳指标
这是目前最流行、也最值得警惕的误区之一。
早在 2014 年，就有研究指出代码行数（Lines of Code，LoC）无法通过必要的有效性检验，因此作为生产力指标的价值十分有限。然而时至今日，包括微软在内的不少企业仍然公开追踪 AI 生成代码行数。
问题在于，这类指标天然鼓励错误行为。
当组织开始关注代码数量时，人们会倾向于写出更多代码，而不是更好的软件；与此同时，这类指标也很容易被人为操纵，并逐渐侵蚀团队对度量体系的信任。
从管理角度来看，更多代码从来不等于更多价值。
神话四：AI 对所有任务和所有工程师都同样有效
研究结果表明，事实恰恰相反。
微软 2024 年关于生产力的研究发现，对于开发者已经熟悉的任务，Copilot 带来的收益明显更高；而面对陌生领域时，提升幅度则显著下降。
更值得注意的是，一项针对资深开源开发者的 2025 年研究甚至发现，AI 工具使实际实现时间增加了 18%。
与此同时，研究人员还观察到一个令人意外的现象：即便只是把提示词改写成语义完全相同的另一种表达，生成代码也会有 46% 的概率发生变化，而正确性则有 28% 的概率发生变化。
这意味着 AI 输出的稳定性远低于许多人想象。
神话五：AI 会让普通开发者变成“10 倍工程师”
这一说法很大程度上源于那个被广泛引用的“55% 生产力提升”数字。
然而，这类研究大多是在受控环境下完成的，任务范围有限，而且通常聚焦于单个开发者完成的孤立工作。一旦进入真实团队环境，这种提升往往很难完整复现。
研究者指出，开发者表现差异中的很大一部分实际上来自任务本身，而非个人能力。
换句话说，一个困难任务不会因为配备了 AI 就自动变成简单任务，而一个简单任务也不会因为没有 AI 就变得异常困难。
因此，“10x Developer”这样的叙事很容易高估工具作用，同时低估工作内容本身的重要性。
神话六：让 AI 发挥价值是开发者个人的责任
论文在这里引用了 Cal Newport 的观点。
历史上真正改变生产力曲线的创新，往往来自系统性的工作流程重构，而不是给个人发放更好的工具。流水线如此，现代制造业如此，大规模企业软件同样如此。
然而，GenAI 的推广方式却几乎完全相反。
许多企业花费数百万美元购买许可证，却没有同步设计新的协作流程、管理机制或组织实践，结果每位工程师都只能自行摸索如何把 AI 融入工作流程。
研究者认为，这种做法实际上是在把组织层面的问题下放给个人解决，而历史经验表明，这通常不会产生最好的结果。
神话七：只要 AI 工具足够优秀，人们自然会采用
现实情况远比这复杂。
虽然约有 80% 的开发者已经开始使用 AI 工具，但真正信任其输出准确性的比例只有 29%。
大量开发者表示，他们经常需要花费比自己写代码更多的时间去调试和验证 AI 生成的结果。
研究还发现了一种被称为“能力惩罚（competence penalty）”的现象：即使两份工作成果完全相同，只要其中一份被标注为使用了 AI 辅助，人们往往会给予更低评价。
这种偏见在女性开发者和年长工程师群体中尤为明显。
因此，工具性能本身并不足以保证广泛采用，信任、组织文化以及评价机制同样会深刻影响最终效果。
神话八：有了 GenAI，企业也能像创业公司一样高速创新
这也是许多高管最容易产生误解的地方。
大多数创业公司使用的是流行的开源框架，而这些框架恰恰是 LLM 训练数据中覆盖最充分的内容。因此模型能够很好地理解相关代码，并提供有效帮助。
企业环境则完全不同。
企业系统往往建立在大量专有工具、历史遗留代码以及复杂兼容性要求之上，而这些内容通常从未出现在模型训练数据中。
除此之外，企业还必须面对合规要求、安全约束以及客户期望等问题，而这些负担很多创业公司根本无需承担。
因此，即使使用相同的 AI 工具，企业获得的收益也未必能够复制创业公司的体验。
对管理者意味着什么
贯穿这八个神话的共同线索在于：
GenAI 的价值更多取决于它如何被部署、衡量和支持，而不是组织是否购买了这项工具。
如果管理者把 AI 推广仅仅看作一次采购决策，那么最终得到的往往也只是采购决策层面的收益。
研究者据此提出了几条值得参考的实践建议。
在优化那 14% 之前，先审视剩下的 86%
如果开发者只有约 14% 的时间用于编码，那么继续增加 AI 使用率指标或者购买更多许可证，未必是最值得优先解决的问题。
更有效的做法，是先花一周时间认真分析团队时间究竟消耗在哪里。
在大多数组织里，真正影响交付效率的往往是代码审查排队、设计讨论、环境配置以及各种会议，而不是编辑器里节省下来的几个按键。
把 AI 用在一个明确的外循环瓶颈上
不要先衡量工具，而要先衡量业务结果。
选择一个具体瓶颈，例如：
- 代码审查周转时间；
- 新员工上手周期；
- 不稳定测试（flaky tests）的排查效率；
先建立基线数据，再有针对性地引入 AI，并持续观察真正重要的结果指标，例如：
- Cycle Time；
- Change Failure Rate；
- 首个 PR 的完成时间。
只有这样，才能判断 AI 是否真的改善了交付能力。
在追求生产力提升之前，先解决信任问题
研究建议团队主动调查以下问题：
- 哪些 AI 输出曾经浪费过时间？
- 哪些内容工程师必须手工重新验证？
- 哪些场景大家完全不愿意使用 AI？
基于这些反馈，团队应当建立明确规则，例如：
- 哪些任务适合使用 AI；
- AI 辅助代码需要达到什么审查标准；
- 管理者如何在绩效评估中公平看待 AI 辅助工作；
只有缩小信任鸿沟，AI 的潜在价值才有机会真正转化为实际收益。
归根结底，研究并没有否认 GenAI 的价值，但它揭示了一个经常被忽略的事实：影响软件工程效率的，从来都不只是写代码的速度。对于大多数团队而言，决定交付能力的瓶颈仍然存在于协作、设计、审查和组织流程之中。因此，与其执着于寻找一个能够概括一切的“AI 生产力提升百分比”，不如认真理解团队真正的工作方式，以及 AI 究竟改变了其中哪些环节。