不, AI 并没有让工程师提升 10 倍的生产力

amc

修改于 2025-08-16 16:55:28

4620

这几天翻查了一些关于 AI 从需求理解到代码生成的论文、博客，意外看到了这一篇博客《No, AI is not Making Engineers 10x as Productive》，作者是 2025 年 8 月 5 日发布的，勉强新鲜出炉。也找到一些国内的小博客提及了这篇文章，但在 AI 至上的大环境下，这篇唱唱反调的博客传播度很低。好奇之下，我决定全文翻译这篇博客以飨读者。

再次说明：译者不完全赞同原作者的观点，同时译者认为原作者的行文有些偏执和矫枉过正。然而原作者泼出来的一些冷水，确实值得还没有长时间、深入使用 AI 编程工具的人们、以及被资本、被投资者们吹晕了的普通人了解一番。

现在，原文（包括译者注）开始：

前言

几个月前我的情绪有点低落。我一直对我作为工程师的能力非常自信，但当我在领英和 Twitter 上刷内容时，我不尽觉得自己的技能正无可救药地越来越落后。如何我看到的内容是真实可信的，那么在工程领域，往编辑器里敲代码已经是一种 “中世纪” 式的落后做法了，真正的工程师早就升级了，ta 们的工程效率已经比我高 10 到 100 倍。如果你也有类似的焦虑，希望我这篇文章能够帮助你

我是一个抱持怀疑论的人，因此我听到类似的说法，我通常不会马上听信和盲从。就像有人告诉我一个简单的草药包治百病，那我通常会对 ta 翻个白眼。但现在 “10倍工程师” 的说法铺天盖地，如果我错了呢？如果我现在不用 AI，那么我是不是就错过了最后的上车机会，从而丢掉我的饭碗呢？毕竟，对于我熟悉的 “AI” 和这些人所说的 “AI” 之间，被很多花哨的用词粉饰了起来：

这些在人使用 “智能体” AI，“会思考” 的模型，能在网上冲浪、运行测试、纠正他们自己的错误见解。当然我也时不时地会打开 AI 聊天窗口，并且要求它帮我写一些代码。一旦我获得我所需要的思路，我就会把模型大部份的输出丢掉。然而，这些工程师们却让 Claude 完全掌控他们的方向盘，让这些 “智能体”（agents）在他们还在煮晨间咖啡的时候就搞定 5 个 PR。难道我正在变成一只上个纪元的恐龙、一个只会对着天嚎叫的老古董？

让我感到焦虑的部分原因是，由于我不常使用 AI ，而且也不太喜欢使用它，AI 完全有可能在我不知情的情况下发生了重大的改变。Code Reviews 比写代码无聊太多了。难道我那种想要享受变成乐趣的执念和愿望，会让我被时代抛弃吗？

深入探索

最终，我到了一个突破点（译者注：不知道该怎么翻译），我决定我先深入 AI 编程。我尝试了 Claude Code、Cursor、Roo Code 和 Zed，因为它们都声称具备 agent 编码功能。我开始让 AI 在各种各样的项目中编写各种各样的代码。我尝试不同的模型，并作了比较。我甚至还进行了一些 vive coding，一点也没有修改 AI 生成的代码。

结果呢……也就那样。尽管有说法称如今的 AI 正在飞速进步，但我感觉和以前差不多。它擅长写样板（译者注：boilerplate，不是模板），尤其是在 Javascript 中，更尤其是在 React 中。但它不擅长遵循你代码库的标准和工具类。在像 Terraform 这样的语言上，它往往表现不佳。它仍然会“幻想”出一些库，从而导致严重的安全漏洞。

AI 仍然难以理解大型代码库的上下文，即便有了非常优秀的 prompt 和 CLAUDE.md 文件也一样。如果你使用的库不是在 StackOverflow 上的热门库，即使 agent 阅读了文档，也会把它用得一团糟。Agent 偶尔会做一些不错的事情，比如修复它们自己的失败测试代码。很多时候，它们只是在浪费时间和 token，来回折腾，每次失败后似乎都没有学习到更深层的知识。因此，对我来说，AI 最好的使用场景依然是仍然是编写一次性的脚本。特别是当我没兴趣为了单个脚本学习去深入学习相关知识时，比如编写自定义 ESLint 规则。

“如果现在不开始使用 AI，就会远远落后” 的可怕告诫，我并没有体会到。学习用 AI 写代码并不难。很明显吧？AI coding 的社区似乎存在分歧，有人认为 AI 让编程变得简单到连猿人都能做到；也有人认为这需要高级的、专门的 prompt 工程师技能。确实有一些东西需要学习，但很快就能掌握。你要学会把任务分解成更小的部分，这样 AI 就不会在上下文窗口的后段 “精神失常”。像 Claude Code 这样的工具自己就能做到这一点，尽管并不总是可靠。而且你要学会判断什么时候 AI 已经跑题太远、是时候由自己来掌舵了。

一个合格的工程师在适度使用 AI 不到一周的时间后就能弄明白这些。再说了，如果 AI 随时都会变得好 2 倍、10 倍甚至 100 倍的话（就像每个人都在说的那样），那么我们现在学到的任何关于如何使用它的经验，未来也都没啥用。

每当我发现 AI 的表现 “还行” 时，奇怪的是，我反而更焦虑了。这意味着我找不到其他人所说的那么高效的神秘 “秘诀”。我就是没有那种天赋：恐龙遇到了陨石，这个陨石的名字叫 AI。最终，有几件事让我摆脱了这种情绪低落。其中之一是 Ludicity 的这篇文章，直接反驳了 AI 鼓吹者的说法。我写这篇文章是为了把帮助我摆脱 “10 倍 AI 工程化冒充者综合征” 的内容分享给大家。

数学

让我们从简单的 10 到 100 倍生产力数学开始。10 倍生产力意味着 10 倍的结果，而不是 10 倍的代码行数。这意味着你过去一个季度完成的工作现在一周半就能完成。这些数字应该让最狂热的 AI 信徒也停下来思考。传统的 3 个月工作中包含的产品构思、story 沟通、bug 修复、代码审查、部署、测试和 QA（译者注：质量保证, 不是 “问答” 的意思），现在在 7 个工作日内完成？要做到这一点，每一个瓶颈环节都必须同样有 10 倍的生产力提升。

任何在真实的企业中编写过实际代码的软件工程师都知道这是不可能的（译者注：人月神话）。你无法将 3 个月的 code review 压缩到 1.5 周。当进行 code review 时, 你需要：

给审查者打标签分类（译者注：不明白这是干什么）
希望开发者能尽快处理（这很难，因为显然他们要审查的代码量是以前的 10 倍）
等待的时候切换到其他事情
看到通知（可能是立即，也可能是审查者下线 2 小时后）
切换回审查工作
阅读他们的评论
做出相应的回应
如此反复

在一个有良好标准和沟通习惯的优秀公司里，这个过程可以相当高效。但如果你告诉我你把这个过程的效率提高了 10 倍，以处理 10 倍的工作？这根本不可能做到。

实际上，企业软件工程中涉及的认为流程并没有显著的版画。产品经理可能会用 ChatGPT 做 “研究”，但他们不会突然产出比以前多10倍的、经过充分审查、理由充分、估算合理的 story。他们无法同时进行 10 次用户访谈。设计师和 QA 测试人员也是如此。雇佣 10 倍的产品经理来跟上进度是不可行的（译者注：人月神话 again），因为随着网络效应和官僚主义的产生，每一次招聘都会产生边际效益递减。

即使假设人们的意思只是实际的代码编写过程快了 10 到 100 倍，我们也应该对这个计算结果持怀疑态度。当你写代码时，你真正花在敲键盘上的时间有多少？可能比你想象的要少，大部分宝贵的编码时间实际上是在阅读和思考，也可能常常是在等待编译、页面刷新或测试运行的时候。LLM 并不能让 rustc 运行得更快。

LLM 生成的内容往往是有问题的、虚构的，或者不符合代码库标准的。随着代码库规模的扩大，这些错误的发生频率也会增加。当这种情况发生时，你必须重新写 prompt，这么做也许能立即解决问题，也可能是浪费更多的时间。又或者你可以自己去修正代码。但这样你就回到了微不足道的 1 倍工程师状态，如果因为习惯了 “vibe coding” 而忘记了如何编程，情况可能更糟。如果你 “拥抱 vibe”，甚至不阅读生成的代码，那么一旦代码库足够大，你就会遇到生产力的瓶颈。到那时，你就不得不面对编码标准的缺失和适度抽象的问题。

我觉得有时候人们忽略了 10 倍的规模有多大。10 倍就像是你的皮卡和创下速度记录的喷气式引擎的汽车之间的差距（译者注：好绕，直接跟超音速飞机对比就行了）。想象一下开着一辆 600 迈的车在马路上行驶，原来需要 10 分钟的通勤，你能在十分之一的时间内到达城市的另一边吗？不能，因为即使一个60秒的红灯也会耗尽你所有的时间预算。一级方程式赛车在普通弯道也要减速到小型货车的速度。事实证明，任何活动的大部分时间都不是以最高速度进行的。100 倍的提效意味着你现在用两天时间就能完成过去一年的工作。如此荒谬的数字，我甚至都不需要多做解释。（译者注：个人觉得作者这里太钻牛角尖了，非要扣这 100 倍的用词。其实重点不在几倍，对 AI 提升效率的迷信才是重点）

10 倍工程师真的存在吗？

我不想太多地讨论这个问题，但也不得不说几句。我的答案是，在某种情况下这是可以存在的。当我遇到那些价值是其他人 10 倍的工程师时，主要是因为他们有能力避免不必要的工作，比如说说服产品经理放弃一个根本不可行的任务；让另一个工程师不要去构建那个不必要的微服务；进行开发人员体验方面的投资，为每个人在每项任务上节省一点时间；把自己的工作记录下来，让以后接手的的每个工程师都能更快上手。这些事情随着时间的推移累积起来，一个工程师为公司节省的时间可能是他们构建这些东西所花费时间的 10 倍。（译者注：请珍惜你身边愿意大段写注释和文档的同事！！！）

这种性质的工作并不总是存在的，所以优秀的工程师只会在某些情况下发现自己的生产力是别人的 10 倍。大部分情况下，每名工程师都只需要构建功能逻辑。优秀的工程师可能比初级工程师快一倍，但他们仍然会遇到和以前（译者注：没有 AI 辅助开发以前）一样的瓶颈。尽管 stories 有缺陷（译者注：Flawed as story points are，不知道该怎么翻译），但是我从没见过一个工程师能够持续地以普通工程师 10 倍的速度实现 stories。

值得留意的是，AI 辅助编程助手在避免不必要的工作方面几乎没什么作用。相反，AI 似乎常常鼓励草率行事和过度构建（译者注：这个确实是社区共识，但是这个还好，一方面发展出了很多方案避免 AI 过度激进，另一方面不同的 LLM 取向也有所不同，需要专门调教）。当我提出架构方面的问题时，它常常会推荐一些我经过一夜思考、或者与优秀工程师交流后发现并不必要的东西。在其他条件相同的情况下，编码速度更快的工程师就是更好的工程师吗？是的，但这并不是造成 10 倍差距的原因，而且实际上你也很难让其他所有条件都保持不变（译者注：所谓的控制变量）。你越是专注于尽快完成任务，就越容易错过那些能减少总工作量的重要省时方法（译者注：这确实是研究 AI 提效的一个大盲区：专注于屎山的构建效率而忽略了不拉不必要的屎）。

那么那些 AI 宣传者是在撒谎吗？

我认为这些 AI 鼓吹者包含以下几种人，按恶意程度从低到高排列：

天性善良但对自己和他人的评估有误的人
在 AI 中投入了大量个人或财务资源的人（ AI 初创公司创始人、投资者等）
老板们公然试图让他们的工程师感到自己的地位岌岌可危，这样他们就不会辞职、寻找其他工作或要求加薪（译者注：简称 PUA）

数学不好但天性善良的工程师

根据我的经验， AI 带来 10 到 100 倍生产力提升的效果是罕见且短暂的。当我让 AI 在几分钟内为我编写一个自定义的 ESLint 规则时，如果没有它，我可能需要花几个小时查阅文档和教程，在这个场景下这确实是数量级上的时间和精力提升。这样的时刻在 AI 使用中确实会发生。许多非专业的程序员在使用 Lovable 快速搭建应用程序的最初几天里，都感受到了这种魔力。

问题是生产力无法规模化。我每年编写的 ESLint 规则不超过一个。这种生产力的爆发是因为我完全不在乎这段代码，也不会在意是否需要让下一个工程师能读懂它。如果持续编写 ESLint 的规则成为核心工作要求，我会投入一次性的成本去学习 ESLint 的内部工作原理。在那之后，“Vibe Coding”一条规则和自己编写一条规则，在时间耗费上就不会有太大差别了，特别是如果你为了让代码变得更加具有可读性而画上额外的时间，以便 6 个月后我再回头看这个文件时，我能读明白的时候。

最终，每个 “Vibe Coding” 的人都会达到收益大幅递减的点——他们的网站被黑客攻击，于是不得不再花时间去学习安全知识；应用程序大到超出了上下文窗口的范围（译者注：任何上下文工程，都无法包含完整的上下文），导致外观和功能变得不一致；然后，真正懂行的前端工程师会被雇来实现一致的设计系统和用户体验（译者注：看来作者是后端工程师 hhhhhh）。

还有很多简单的偏见和盲区会造成生产力的错觉。如果你从大型企业跳槽到初创公司，你会真正惊讶于每个工程师的生产力竟然能高出这么多，于是就很容易把这归功于 AI。有些人真的很喜欢 AI 编码的技术新奇感，当你在做新事物时，往往会觉得自己做得比以往任何时候都多。我记得第一次使用 Python 的时候，感觉自己像是 “在喝火箭燃料” 一般。但就像所有其他技术一样，这种感觉总会回归实际。

我认为很多更真诚的 10 倍 AI 宣传都来自那些正处于 “蜜月期” 或者没有坐下来认真思考 10 倍改进在数学上意味着什么的人。我并不惊讶于 AI 能帮助许多工程师在某些任务上快20%-50%，但软件瓶颈的性质意味着这并不会转化为20%的生产力提升，更不用说10倍了。(译者注：我觉得这是作者对 AI 辅助编码能带来提效效果的观点，就是 < 20%)

激励机制很重要

请注意，我并不是 AI 初创公司的反对者。然而如果你想把 OpenAI 的 API 接入你的医疗初创公司，我可能会对其中的风险皱起眉头。对于任何想要在医疗领域快速行动并突破常规的初创公司，我都会有同样的反应。我的目的不是说 AI 初创公司的创始人或投资者是邪恶的，甚至是不诚实的。我的观点是：用你高中经济学 101 教授（译者注：high school Econ 101 professor，这是什么？）那种平淡的语气说：“激励机制很重要”。

如果你经营着一家 AI 初创公司，而其他所有的 AI 初创公司都在告诉投资者，由于 AI ，他们的生产力提高了 10 倍，那么激励机制很简单：你应该在公开和私下场合都这么说。如果你的公司是建立在 AI 的基础上，你就有动力把 AI 推销成生活各个方面的奇迹解决方案。如果你是一名工程师，你的老板问你：“嘿，你借助 AI 的生产力提高了10倍，就像其他所有工程师一样，对吧？” 你会非常乐意说：是的。当其他所有工程师出于同样的原因也说是的时候，这位首席执行官并不是在撒谎，他们只是在转述自己听到的话。

我想向那些和我一样感到焦虑的人强调，这并不是什么新鲜事。首席执行官们并不是没有偏见的信息来源。高管们一直声称，从敏捷开发到迈尔斯-布里格斯性格分类法，一切都释放了无限的生产力。LinkedIn 上总会有新的时髦词汇，别让它们影响你的心情。事实上，干脆别刷 LinkedIn 了。那是个无聊的地方。

（译者注：我完全看不明白这一段作者想说什么。我个人猜测，作者可能想说一个 “声称” 应该是表里如一的，对外画的饼，应该是团队私底下也认可的指标，并且也是团队在私底下非常愿意安利的案例。就比如说，我个人是 Cursor 的长期付费用户，你问我好不好用，我是绝对安利的。但是你问我提高了多少？我可不会跟你说 10 倍，我会说：看情况）

公然的恶意

当某些言论让人感到焦虑时，至少在某些时候，你应该得出这样的结论：这正是说话者想要的结果。老板们试图让他们的工程师感到自己的职位岌岌可危，这也不是什么新鲜事。我们都记得这样一种说法：一个3个月的编程训练营就能培养出相当于4年学位水平的工程师，所以你最好别太傲慢，否则你就会被一个正在转行的文学学士取代。几年过去了，人们意识到，训练营的毕业生通常对实际的软件工程工作准备不足，因为他们没有得到适当的基础培训。

训练营和 AI 只是一系列旨在将高薪、高度专业化的软件工程领域商品化的、缺乏根据的威胁中的例子。它们是用来暗示不稳定的修辞手段。你的老板实际上不能解雇你，用 AI 取代你，但他可以让你觉得他可以，这样你可能就不会要求加薪了。

“10倍 AI 工程师”的说法中，有一部分可能是那些只想让你感觉不好的人编造的。具体有多少，我不知道。尽管在这个时代，我们彼此之间变得极度不信任，但我仍然相信大多数人本质上是正派的，所以我不认为这个比例很高。

信息差（译者注：原文 Degrees of Separation，理解下来我觉得这就是一种信息差）

我注意到一个问题：所有这些 AI 编程宣传文章中的人物，在作者和实际的生产力收益之间，几乎总是存在一定的信息差。写文章的人是创始人、经理或投资者（译者注：还有产品经理、销售经理），他们对别人的生产力做出夸张的声明。二手资料并没有什么问题，但如果你找不到第一手的资料，你可能就要开始质疑这些信息的可靠性了。

真正的工程师会展示他们如何借助 AI 提高生产力的演示则更加多样化，而且他们的赞美也更加温和（译者注：就像我，我整理过一个 PPT，我有时间会非常愿意脱敏后开放出来。而且优秀的用例会越来越多）。这些演示表明，AI 在很大程度上和我们在感到焦虑之前所熟悉的技术是一样的：一个不错的文本生成器，有时会创造奇迹，但往往需要你自己来掌控。（译者注：还是比以前的生成器强的～～）

在开源项目中使用 AI，其生产力过程是可以公开看到的，但这显然是一个可笑的失败。我从一些 YouTube 视频中学到了一些更好地使用 AI 的方法。这里有一个在上面提到的 Ludicity 文章中引用的不错的视频。不过我可以剧透一下，这位工程师并没有找到编码生产力的源泉。

效率低一点也没关系

不过即使在我克服了那种 “存在一群效率比我高 10 倍、更高、更强、更性感的工程师” 的想法之后，我仍然因为不太喜欢使用 AI 而感到一些焦虑。因为一旦那种魔力消失，Vibe Coding 就变得非常无聊。阅读大型语言模型生成的代码很糟糕。礼貌（译者注：想想一下憋着火保持礼貌的感觉）地要求它使用一个真实存在的库是很痛苦的事情。但如果尽管如此，Vibe Coding 仍然比常规编码的效率高 20%，那我选择 “正常” 编码是不是错了？

不，为了让工作变得愉快而牺牲一些生产力是没关系的。而且不仅没关系，而且这在我们这个领域是必不可少的。如果你强迫自己以一种讨厌的方式工作，你只会 burnout。编码的工作中，只有一部分是写代码，其余的是解决问题、进行系统设计、思考抽象概念以及与其他人交流（译者注：so，这部分能被 AI 替代吗？）。当你感觉良好时，你在所有这些方面都会做得更好：为自己的工作感到自豪，欣赏这门手艺，这是没关系的。从长远来看，你的代码库会从中受益。

（译者注：这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到快乐一样——《人月神话》）

数字音乐听起来客观上是否比黑胶唱片好，这并不重要；翻唱片是否比让流媒体服务在 100 倍短的时间内自动播放下一首歌更 “低效”，也不重要。如果听一张 70 年代的老唱片能让你更快乐，那就去做吧，这样你听的音乐可能会比强迫自己使用更 “高效” 的流媒体服务更多。如果你用自己喜欢的方式编码，你会花更多时间写代码，而且会写出更好的代码。

当然了，而且这个论点反过来也成立。如果你觉得用 AI 编码很开心，那就去做吧。如果你因为它而感到非常兴奋，编码比以往任何时候都多，那太棒了。我希望每个人都能有这种感觉，不管通过什么方式。

（译者注：现在我已经能够区分出什么时候我自己写代码很开心、什么时候用 AI 帮我写代码很开心了。如果谁想要剥夺我两者之中的任意一个，我都会很沮丧）

如何成为一个优秀的 AI 领导者

让所有工程师都不断为自己的表现感到焦虑，这对公司是不利的，这会让工程师不想为你工作；这会导致短视思维，从而促使工程师把大部份的精力投入到提升没有意义的（译者注：但是可以量化的）指标上，比如代码行数。代码审查会被忽视、技术债务会累积。从长远来看，整个公司都将为这些错误付出代价。

不切实际的 10 倍期望必然会导致工作仓促且质量低下。工程师需要有喘息的空间，需要有花多一点时间把事情做好的空间。良好的代码库和优秀的公司是建立在兼顾当下和未来的健康平衡之上的。我很庆幸现在能在这样的一家公司工作，但很多人就没这么幸运了。

不要因为工程师没有消费足够多的 tokens 而责骂他们。你的工程师是在一个竞争极其激烈的领域里受过高等教育的专业人士。软件工程师们已经因过度热衷于接受和抛弃新语言和工具而声名狼藉，如果你花这么多钱雇佣这些人，你就应该相信，如果真的有能极大提高生产力的方法，他们会来找你要求升级计划的。如果你担心错过了其他人似乎都在获得的所有 AI 编码收益，那就去购买一个团队的 AI 编程工具序列号、举办一次培训课程，看看会有什么结果。这就是你需要做的全部。