LLMs 与表演式生产力

# 大语言模型与表演性生产力 来源：https://joshcollinsworth.com/blog/productivity **发表于：**2026年6月5日 当我从自己使用 AI 的场景中稍稍抽离出来，开始思考 AI ¹(https://joshcollinsworth.com/blog/productivity#footnote-1) 究竟让我个人变得多有效率时，我产生了疑问。 最初，当我开始在日常工作中使用智能体时，我被它们的能力以及它们如何提升我自身的能力所震撼。毫无疑问，下限被抬高了。我能做得更多、更快。这一点毋庸置疑。 凭借这种新获得的力量，我完成了一大堆以前要么没能力做、要么没时间做的任务： - 在工作中，我无需请求帮助就能上手新的代码库，并且更容易地为其做出贡献。 - 我以创纪录的速度更新、迁移或重构了一些项目（*包括一次特别棘手的 Nuxt 升级，我拖了好几年，本来要花我几天时间，结果大约一小时就搞定了*）。 - 我给几个应用到处添加了一些新功能，不然我是不会加的。 - 我以创纪录的速度搭建新东西，构建全新项目。 - 我比以往更快地写了更多测试。 - 我推出了大量错误修复。 当然，这一切听起来棒极了。感觉*也很棒*。 但当我做完这一切后，我不得不怀疑：**我真的能把其中任何一件事称为“高效”吗？** - 在工作中，我并不理解我正在处理的代码库，虽然我在为之做贡献，但我没有获得关于它们的真正上下文。我发起了 PR，但我无法真正为其中的内容辩护，也无法说明它们是否能与系统协同工作。我总担心自己搞砸了什么而不自知。 - 大多数其他更新其实并**不真正需要**，之后应用本身也毫无变化；这些改动只是让我自我感觉良好，对软件用户端几乎没有任何影响。 - 我构建的新功能很酷，但实际上没人用。 - 那些全新项目很快就废弃了。 - 我并没有那么迫切地需要那些测试，而且我也不太确定它们到底有没有什么价值。 - 我不知道那些 bug 的成因，也不知道修复是什么。 我主要只是打勾完成了一堆旧的待办事项，其中大部分之前没完成，根本上是因为它们一开始就没那么重要。 而即使在*确实*重要的地方，我也为做得更多、更快付出了代价。我在旧堆里添加了一堆废弃的副项目，但不像以前，我甚至没有获得任何新技能或经验。 要说有什么不同，似乎我懂的比以前**更少了**。 也许代码改进了，但我肯定没有。 而这一切还都是“**最佳情况**”——即智能体工作良好的时候。其他时候，我花在提示和重提示上的时间，本来自己动手做早就完成了——但到那时，我当然已经陷得太深，觉得继续挖下去反而更容易。 我不得不同：当尘埃落定，这真的是净收益吗？ 如果对自己诚实的话，我做的往往是表演性质多于实际生产力；声势浩大，成果寥寥。 但对自己诚实，原来比想象中要困难得多。 因为，尽管有上述种种……我**热爱**它。 我喜欢把自己的智能体当作一种罪恶的快乐来使用。只要有机会，我就想用它。 我用自己双眼**看到**我在用宝贵的东西换取廉价之物，就像孩子把零用钱都花在口香糖球机上。 但我仍然**想要**那机器里的东西。它触发了我大脑中的某些东西。我相信，也许只要我用得足够多，所有这些微不足道的无意义任务最终会积累成什么重要的东西。 有时我会感到一种冲动，想打开 Claude Code 让它做点什么，即使我没什么想完成的事。 我对这种冲动非常熟悉，当我抽身出来时，我立刻认出了它：我想**玩** AI，就像玩电子游戏一样。如果我没有理由或目标，我会试着编一个。我只想要更多那种**感觉**，好像我以难以置信的速度完成了什么。（实际上，和电子游戏没什么两样。） 我让 AI 为我做的所有工作，本来都可以是极好的学习机会。相反，我基本上只是用自己潜在的成长，换来了……一堆垃圾。而且我**乐在其中**，甚至是热情地。 这时我开始思考，AI 是不是更多在为我的情绪服务，而不是真正提升我的生产力。 ## 一个值得质疑的假设 也许你从未想过质疑“AI 让你更有效率”这一观点。 也许你从没想过要问，因为你用过这项技术，而且你**也感觉**这种差异明显且无可否认。 或者，也许你从未想过质疑这个假设，因为它似乎是这个行业广泛接受的事实²(https://joshcollinsworth.com/blog/productivity#footnote-2)。 无论如何：这个假设一直让我有点惊讶，因为它几乎完全来自传闻式的自我报告，或者来自销售 AI 的公司。很少有高质量、定量的研究或调查试图客观地检查：**AI 真的让软件工程师更有效率吗？** 在这些客观尝试中，据我所知，没有一个给出无条件的“是”。无论 LLM 可能带来什么收益，它们总是视情况而定，并且总是伴随着权衡。 更让情况模糊的是：这些研究中对“生产力”的定义差异很大。很少有人认为应该从整体视角，通过考察广泛影响来衡量。但越是这样做，他们能发现的益处就越少。 很多声称的 LLM 生产力提升，似乎都依赖于一个可疑的生产力定义。 那些报告最令人印象深刻的生产力提升的研究，**同时**也倾向于拥有最人为定义的概念。通常，他们只测量参与者完成一个简单编码练习或一个基本全新“hello world”应用的速度。 我想，这在某种程度上是部分准确的定义。但它遗漏了很多，包括任务完成得**如何**、为了速度可能牺牲了什么，以及这些发现是否能应用于真实场景等等。 但在此之前，我们先看看我提到的那些研究。 我整理了我所知道的所有值得注意的研究和调查，并在下面概括了它们的发现。 ## 关于 LLM 对开发者生产力影响的研究 - 今年早些时候，Anthropic 自身的一项研究³(https://www.anthropic.com/research/AI-assistance-coding-skills) 发现，使用 AI 带来的统计上不显著的益处，是以工作中培养的技能的巨大**牺牲**为代价的。其他领域的类似研究，比如这项研究⁴(https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/)，也注意到了同样的效应；无论 LLM 能带来多快的速度，都是以认知能力为代价的。 - 同样在今年早些时候的一项调查中，CEO 们绝大多数承认，AI 采用与公司范围的生产力提升之间几乎没有关联⁵(https://fortune.com/article/why-do-thousands-of-ceos-believe-ai-not-having-impact-productivity-employment-study/)。 - 一项 2025 年的研究⁶(https://arxiv.org/abs/2507.09089) 发现，使用 AI 让开发者**感觉**快了 24%——但实际上，却让他们慢了 19%⁷(https://joshcollinsworth.com/blog/productivity#footnote-4)。几个较小的、无关的后续实验也产生了类似的结果。 - 一项 2025 年末的研究（在此总结⁸(https://proxify.io/articles/stanford-study-of-100000-developers-on-engineering-productivity)）发现，最高可达 40% 的提升——但仅限于低复杂度的全新项目（并且以代码可维护性降低为代价）。在现有代码库和/或更高复杂度的任务中，这种提升会缩小、消失，甚至变为负值，**特别是**当考虑到需要返工之前发布的 LLM 代码时。 - 一项 2024–2025 年的研究⁹(https://dora.dev/research/2024/dora-report/) 发现，个人生产力有所提升，但也发现这种提升伴随着发布瓶颈以及已发布代码稳定性的下降。 - MIT 2024 年的一项研究¹⁰(https://mit-genai.pubpub.org/pub/v5iixksv/release/2) 声称有 10–20% 的提升，但前提是将生产力定义为打开的拉取请求（PR）的绝对数量——这个指标也许**可以**是生产力的信号，但也可能表明一个完全**适得其反**的瓶颈。（即便如此，该研究也承认其发现难以准确衡量，且几乎未达到统计显著性。）¹¹(https://joshcollinsworth.com/blog/productivity#footnote-5) - 微软 2023 年的研究¹²(https://www.microsoft.com/en-us/research/wp-content/uploads/2023/12/AI-and-Productivity-Report-First-Edition.pdf) 声称“对生产力有显著提升”，但实际上只测试了构建一个极其简单的“hello, world”样板应用，与真实世界的开发工作相去甚远。其中还附带几个关于工作质量下降的注意事项。 - 最近几份 Stack Overflow 开发者调查显示，开发者的 AI 使用率在增加，而对 AI 的信任度实际上却在**下降**。（事实上：现在不信任 AI 的开发者比信任的多。）在最近一次调查¹³(https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/) 中，AI 解决方案“差不多正确，但又不完全正确”是开发者提及的首要挫折，整整三分之二的开发者表示，他们现在花在修复 AI 生成代码上的时间比以往任何时候都多。 ### 主要收获 所有这些研究采取了不同的方法，但它们的发现中有几个共同的线索，我想指出： - **LLM 的生产力收益高度依赖于具体情况**。LLM 擅长直接、耗时的任务。它们在样板代码和全新项目上表现出色。而且，它们对经验较少的程序员帮助远大于经验丰富的。离这个最佳适用点越远，收益就越小。 - **感知与现实之间存在显著差距**。这证实了我的体验。LLM 用户**感觉**这个工具为他们做了比实际测量到的更多的事情。 - **即使收益是真实的，也是有代价的**。上述几项研究（以及在其他领域的其他研究）已经证实，LLM 的输出在多个方面通常质量较低。虽然有理由认为这种差距正在缩小，但还有另一个更令人担忧的代价： - **LLM 的使用抑制了认知和理解能力**。这当然说得通；你不能指望每天不练习就能上场比赛。你对系统的理解主要来自那些日常的小接触点。如果你把这些外包出去，你会迅速失去上下文并产生认知债务¹⁴(https://www.media.mit.edu/publications/your-brain-on-chatgpt/)¹⁵(https://joshcollinsworth.com/blog/productivity#footnote-6)。 - **迄今为止，大多数研究只在个人层面且脱离上下文测量生产力**。测量通常从编写代码开始，到合并 PR 结束。很少有人尝试从更广泛的视角，在组织范围内并随时间推移来测量影响。而当他们这样做时，积极的影响往往会消失。 在我看来，最后一点可能是最大的收获。 你越是采取宏观、整体的生产力视角，LLM 使用带来的收益就越会缩小，甚至变为负值。 公平地说：这些研究中有许多是在 2026 年之前进行的，也许有理由相信 LLM 已经发展得足够好，以至于某些结果可能已经改变。 即便如此，我们也需要非常小心地定义生产力以及测量方式。因为我觉得我们为了把 LLM 塞进去，已经接受了一个不完整、不充分的词语定义。 ## 定义生产力 在任何需要测量生产力的场景中，你不能只看速度或数量。这些都是短期指标，而好的工作往往是缓慢地、以小增量完成的，这样才能长期持续¹⁶(https://joshcollinsworth.com/blog/productivity#footnote-7)。 但似乎我们不再关心了。 事实上，感觉我们正在被积极地告知**停止**关心我们或许在 LLM 出现之前就已经达成的任何生产力定义——或者至少，要调整它。 我们被告知停止手写代码，不是因为我们的代码不够好，或者我们做错了什么，而仅仅是因为……它不够快。 LLM 代码是否和人类代码一样好，在这里是部分承重因素。毕竟，如果机器**能**写出和人类一样好（甚至接近）的代码，为什么**不**更快地做呢？ 但这实际上只是整体问题的一小部分。我们现在（也许是故意地）忽略了**实际生产力**所包含的更多内容。 ### 生产力不仅仅从“PR”开始 显然，LLM 可以极快地编写代码；没有人否认这一点。如果代码的绝对数量是你衡量生产力的方式，那么 LLM 毫无疑问会赢。 但我认为，任何在真实生产环境中工作过的人都不会同意，绝对代码行数是衡量生产力的有用代理。（事实上，不久之前，我们大多认为相反的情况往往是真的，并且**更少**的代码行数通常是更好的信号。） 类似地：如果你不考虑代码中包含的**质量**，那么你打开或合并了多少个 PR 其实并不重要——任何开源维护者都会告诉你。PR 数量可能从未如此之多，但平均质量可能从未如此之低。 我认为可以公平地说，LLM 生成的代码**并不总是**和人类代码一样好，原因有几个： - 首先：上述研究证实了这一点；它们压倒性地指出，相对于人类对照组，LLM 生成的代码在质量和可靠性上有所降低。也许未来会改变，但目前看来至少是事实。¹⁷(https://joshcollinsworth.com/blog/productivity#footnote-8) - 其次：LLM 是在平均水平的代码上训练的，因此通常产出平均水平的输出。 - 第三：LLM 的输出是非确定性的，虽然这在很多情况下可能不重要，但这意味着任何给定的实现每次都可能不同。你要么相信所有实现本质上是相等的（这似乎不合理），要么相信这很重要。 - 但主要是：人类将不可避免地更全面地理解组织、团队、问题空间、历史、用户等等。LLM 的上下文窗口只有那么宽，它不太可能可靠地考虑那些可能完全存在于代码库之外、现实世界中的事物。最好情况下：人类需要主动提供所有这些上下文，而这并不是一个可扩展的方法。 在这一点上，LLM 爱好者可能会争辩说人类也会犯错误。我们也不是一直完美。 这很公平。我们都搞砸过。大多数人都在某个时候把生产环境搞宕过。 但我对此有两个回应： 1. **没有人对待人类代码如此漫不经心**。在我打开过的成百上千个 PR 中，我从来没有 ——