首页科技快讯不用AI就被淘汰？国外工程师：“10倍生产力”太荒谬了

不用AI就被淘汰？国外工程师：“10倍生产力”太荒谬了

来源：晰数塔互联网快讯时间：2025年08月26日 12:01

当“AI 10 倍工程师”的论断在社交平台上泛滥，当“不用 AI 就会被淘汰”的焦虑如潮水般袭来，也许我们更该停下脚步，冷静地追问一句：AI 真能带来编程效率的指数级提升吗？

一起来看看国外工程师 Colton Voege 的现身说法。

几个月前，我陷入了一段心理低谷。过去，我一直对自己的工程能力充满信心，但当我在 LinkedIn 和 Twitter（现“X”）上不断刷到各种讨论时，却忍不住感到焦虑——我的技能，似乎正以一种令人绝望的速度落后。

如果这些信息可信的话，工程领域应该已经告别了“手写代码”的原始阶段。真正的工程师，如今的生产力可能已经是我的 10～100 倍了。我写下这些，希望能帮助那些正在经历类似焦虑的人。

我向来是一个怀疑论者，每次听到诸如“某种草药可包治百病”的类似说法，总会不以为然。但当这些“10 倍工程师”的论调无处不在时，我开始感到不安：

如果我错了呢？如果不立即学会使用 AI，会不会错过机会，再也找不到工作？毕竟，现在很多流传的花哨词汇，让他们口中的“AI”与我所熟悉的“AI”不同。

他们所说的是 Agentic AI，一种能够浏览网页、运行测试、纠正自身错误的思考（thinking）模型。当然，我也会在聊天窗口中让它写一些代码，但通常会在获取想法后，把大部分丢掉。然而，这些工程师却把工作完全交给 Claude，在他们喝早咖啡时，让 Agent 替他们提交 5 个PR。难道，我真成了那个跟不上时代的“恐龙”？

让我感到焦虑的部分原因是，也许 AI 已经在我不经意间发生了巨变，因为我很少使用 AI，也并不喜欢使用 AI，审查代码的过程，远不如编写代码有趣。难道正是这种固执地想要享受编码的想法，让我落在了后面？

AI编程工具，表现不尽人意

最终，我决定投身 AI 编程。我尝试了 Claude Code、Cursor、Roo Code 和 Zed，它们被认为可以实现 agentic 编码。我在各种项目中使用它们编写代码，比较它们的表现，甚至尝试完全不手动修改 AI 生成的代码。

然而，结果不尽人意。尽管有人声称 AI 正以惊人的速度进步，但它与以往相比并没有本质区别。它擅长编写模板代码，尤其在 JavaScript 中，特别是与 React 相关的。但它在代码库的标准和工具方面表现不佳，在处理 Terraform 这类语言时也会遇到困难，还会因为幻觉生成存在严重安全漏洞的库。

即便我输入了很详尽的 prompt 和 CLAUDE.md 文件，这些 AI 也仍难以理解更大代码库的上下文。如果使用的不是 StackOverflow 上的热门库，它就会搞砸，即便查阅文档也是如此。Agent 偶尔会表现得很棒，比如修复自己破坏的测试，但更多情况下只是在浪费时间和 token，在各种尝试之间来回切换，似乎也没有获得更深层次的知识。因此，对我而言，AI 的最佳应用场景仍是编写一次性脚本，尤其是当我对单个脚本的底层原理毫无兴趣时。

因此，那些声称“不立即使用 AI 就会被淘汰”的警告显然是错误的。使用 AI 编程并不难学。不过，AI 编程社区在一个问题上意见不一：AI 是让编程变得简单到连“原始人”都能做到，还是需要高级、专业的 prompt 工程师技能？我的体验是：确实需要学习一些东西，但掌握起来很快。例如，你需要学会将任务分解成更小的步骤，避免 AI 在上下文窗口中失去方向；像 Claude Code 这样的工具甚至能自行完成部分工作，但并不总是可靠；还要学会在识别到 AI 偏离过远时及时接管。

通常，一个合格工程师只需不到一周，就能熟悉如何与 AI 进行协作。而且，如果 AI 真可以随时变得比现在强 2 倍、10 倍甚至 100 倍，那么现在关于如何使用它的任何经验，都无关紧要。

每当我发现 AI 的表现“只是还行”，我反而更加焦虑，因为这意味着我找不到让其他人“高效 10 倍”的秘诀。我好像缺乏那种天赋，就像恐龙遇上了代表 AI 的小行星。

幸运的是，几件事让我走出了低谷，其中之一是阅读了 Ludicity 的一篇文章——它直接反驳了 AI 吹捧者的论调。

我写下这篇文章，就是想分享更多帮助我摆脱“AI 10倍工程师冒名顶替综合征”的经验。

“10倍工程师”有多荒谬？

让我们先看看“10 到 100 倍生产力”的简单数学逻辑。

所谓 10 倍生产力，意味着成果增加十倍，而不是代码行数增加十倍。这意味着过去需要一个季度完成的工作，现在只需不到两周的时间。

即便是最坚定的 AI 信徒，也该停下脚步思考：传统上需要 3 个月才能完成的工作，真能在 7 个工作日内完成？这几乎要求整个开发流程的每一个环节都实现十倍效率的提升。

任何参与过实际代码开发的软件工程师都知道，这根本不可能。单是代码审查流程，就无法从 3 个月缩短到 1.5 周内。代码审查流程包括：

标记审查者；

希望他们尽快完成审查（这非常困难，因为他们显然需要审查的代码量是之前的 10 倍）；

等待期间切换到其他任务；

收到通知（可能立即收到，也可能在审核人员下班后 2 小时才收到）；

切换回代码审查；

阅读他们的评论；

做出相应的回复；

重复上述步骤。

在管理规范、沟通良好的公司，这个流程可以很高效。但要说将这个流程的效率提升 10 倍来处理 10 倍的工作量？绝无可能。

实际上，企业软件工程中涉及的人为流程并未发生显著变化。产品经理或许会用 ChatGPT 进行“调研”，但不可能突然产出比之前多 10 倍的经过严格审核、合理论证、准确估算的需求文档，他们无法一次性完成 10 次用户访谈。设计师和质保测试人员的情况也一样。至于雇佣 10 倍数量的产品经理来跟上进度，不仅不现实，而且在沟通成本和组织官僚化的限制下，边际回报会迅速递减。

即便假设人们所说的只是编写代码的过程快了 10 到 100 倍，我们仍应对这种说法持怀疑态度。编写代码时，你真正花在敲键盘上的时间有多少？可能比想象的少得多。大部分编码时间其实用在阅读、思考以及等待编译、页面刷新或测试运行上。LLM 并不能让 rustc 运行得更快。

更重要的是，LLM 生成的代码往往存在缺陷、幻觉或不符合代码库标准，且代码库规模越大，这类错误发生得越频繁。这时，你需要重新 prompt，可能可以立即解决问题，也可能浪费大量时间；或者你亲自修改代码，但这样就回到了普通工程师的水平，甚至可能更糟——你习惯了氛围编程（vibe coding），忘记了如何编写代码。如果你根本不查看生成的代码，一旦代码库足够大，就会遇到生产力瓶颈，不得不面对完全缺乏标准和适当抽象的问题。

我认为人们有时会忽视 10 倍提升的规模。10 倍的差距就像小型货车与创纪录的超音速陆地喷气机之间的差异。

想象一下，你试图用一辆时速 600 英里的汽车在城市街道上完成 10 分钟的通勤，能以十分之一的时间到达城市另一端吗？显然不能，因为即使一个 60 秒的红绿灯也会耗尽全部时间预算。F1 赛车在基本转弯时也要减速到小型货车的速度。事实证明，任何活动的大部分时间都不是以最高速度进行的。

100 倍生产力，则意味着现在能在两天内完成过去需要一年的工作。这样的数字有多荒谬，无需多言。

“10倍工程师”真的存在吗？

我本不想参与这场辩论，但或许不得不说几句。我的答案是：有时，可能会有一点点。当我遇到生产力比别人高出十倍的工程师时，通常不是因为他们写代码更快，而是因为他们能阻止大量不必要的工作：说服产品经理放弃根本不可行的功能，让另一位工程师别再去构建多余的微服务，推动开发者体验改进，使所有人都能在日常任务中节省时间，并认真记录工作，方便未来的工程师更快上手。这些积累下来的成果，往往能让公司节省的时间远超他们个人投入的时间，甚至达到十倍之多。

但这并非时时存在，因此优秀的工程师只会在某些情况下达到 10 倍生产力。到了某个阶段，每位工程师都必须专注于开发功能，而优秀工程师可能比初级工程师快两倍，但仍会遇到与之前相同的瓶颈。尽管“故事点”这一衡量方式存在缺陷，但我从未见过工程师能持续完成比平均工程师多 10 倍的工作量。

值得注意的是，AI 编码助手对减少不必要工作几乎毫无帮助，反而常常鼓励草率决策和过度开发。当我抛出架构性问题时，它给出的答案，往往在我冷静思考一晚或与优秀同事交流后，就会发现根本没必要去实现。若其他条件完全一致，编码更快确实意味着更高的产出，但这并不是决定性的十倍差异，更难在实践中保持“其他条件不变”。而且，越是执着于以最快速度完成任务，就越容易忽略那些真正能节省总体工作量的关键环节。

这些AI-posters在说谎？

我认为这些 AI-posters 可以按恶意程度从低到高分为以下几类：

心地善良的人，但他们对自己和他人都有误判；

在 AI 成功上投入了大量个人或财务资源的人（如 AI 初创公司创始人、投资者等）；

明目张胆地试图让工程师感到不安，以免他们辞职、寻找其他工作或要求加薪的老板们。

1. 数学较差的工程师

根据我的经验，AI 能带来罕见、短暂的 10 到 100 倍生产力提升。当 AI 能在几分钟内为我生成一个自定义的 ESLint 规则时，确实实现了数量级的效率提升——否则我需要花数小时翻阅文档和教程。这样的时刻确实会发生，许多非编程背景的从业者在使用 Lovable 启动应用的头几天就感受到了这种魔力。

但问题在于生产力无法规模化。我一年写不出超过一条 ESLint 规则。这种生产力爆发仅因我对这段代码并不在意，且不会花时间让它对下一位工程师可读。若持续编写 ESLint 规则成为核心工作要求，我会投入一次性成本学习 ESLint 内部机制。之后，编写规则与亲自编写代码所需的时间差异将不再显著，尤其是在考虑为确保代码在 6 个月后重新查看时易于阅读而额外花费的时间后。

最终，每个代码生成工具的用户都会达到回报大幅递减的阶段。他们的网站遭到黑客攻击，不得不花时间学习安全机制；应用程序变得过于庞大，无法在上下文窗口中显示，界面和功能开始出现不一致；真正了解前端工程的工程师会被聘请来实现一致的设计系统和用户体验。

还有许多简单的偏见和盲点会造成生产力错觉。从大型企业跳槽到初创公司，你会惊讶地发现每位工程师的生产力都高得多，很容易将此归功于 AI。有些人真的很享受 AI 编程的技术新奇感，从事新事物时，往往会觉得自己做得比以往更多。我记得第一次使用 Python 时，感觉像在“畅饮火箭的燃料”，但与所有其他技术一样，最终都会回归现实。

我认为，许多关于 AI 的 10 倍提升的炒作，其实源于人们正处于蜜月期，或是尚未静下心来认真思考 10 倍提升在数学上的具体含义。我不会惊讶于得知 AI 能帮助许多工程师将某些任务的完成速度提升 20%～50%，但软件瓶颈的本质意味着这并不会转化为 20% 的生产力提升，更不用说 10 倍的提升了。

2. 激励机制至关重要

我并非 AI 初创企业的反对者。如果你想将 OpenAI 的 API 集成到医疗健康初创企业中，我可能会对潜在风险表示担忧，但对于任何希望在医疗领域快速推进并打破常规的初创企业，我都会持同样态度。我的目的并非指责人工智能初创企业的创始人或投资者是邪恶或不诚实的。用高中经济学 101 教授的调侃语气说：“激励机制至关重要”。

如果你运营着一家 AI 初创公司，而其他所有人工智能初创公司都在向投资者宣称 AI 使生产力提升了 10 倍，那么激励机制很简单：你应该在公开和私下场合都做出同样的表态。如果公司业务建立在 AI 基础上，你就有动力将 AI 吹捧为生活中各个领域的万能解决方案。如果你是一名工程师，老板问你：

“嘿，你借助 AI 实现了 10 倍的生产力提升，和其他工程师一样，对吧？”

你会有很强的动力说“是”。而当其他工程师也出于同样原因说“是”时，CEO 并非在说谎，他们只是在转述自己听到的内容。

我想向那些和我一样感到焦虑的人强调，这并非新鲜事。CEO 并非客观的信息来源，高管们一直声称从 Agile（敏捷开发）到 Meyers-Briggs（迈尔斯-布里格斯性格分类指标）都能释放无限生产力。LinkedIn 上总会有新的协同效应热词，别让它影响你。事实上，干脆别再刷 LinkedIn 了，那是个愚蠢的地方。

3. 蓄意恶意

当有人说出让人们感到焦虑的话时，至少有时你应该得出结论，那是因为说话者就是想让这种情况发生。老板试图让工程师觉得自己的职位不稳固，这也不是什么新鲜事。我们都记得那个说法：一个为期三个月的编程训练营就能培养出与四年制大学毕业生质量相当的工程师，所以你最好别太得意，否则会被一个转行做软件工程的文学学士取代。几年后，人们意识到训练营毕业生通常对实际软件工程工作准备不足，因为他们没有良好的基础。

编程训练营和 AI 只是众多试图将高度专业化、高成本的软件工程领域商品化的失败尝试中的两个例子。它们是修辞手段，旨在暗示不稳定性。你的老板实际上无法解雇你并用 AI 取代你，但他可以让你觉得他可以这么做，也许这样你就不会要求加薪了。

关于“10 倍 AI 工程师”的故事中，有一部分可能是那些仅仅想让你感到不安的人在讲述。具体有多少，我不知道。尽管在这个时代，我们彼此之间变得高度不信任，但我仍然相信大多数人本质上是善良的，所以我倾向于认为这个比例不高。

隔阂

我注意到，在所有关于 AI 编程的炒作文章中，作者与实际生产力提升之间几乎总是存在某种隔阂。发帖者可能是创始人、经理或投资者，他们对他人生产力做出夸张的声明。使用二手资料本身没有问题，但如果你找不到一手资料，你可能会开始质疑信息的可靠性。

来自实际工程师的演示，展示他们如何通过 AI 实现更高生产力，要多样化得多，赞誉也低调得多。这些演示大多将 AI 视为我们熟悉的同一技术：一个有时能施展魔法但常常需要你亲自掌控的文本生成器。

在开源项目中使用人工智能，其生产过程可被公开见证，这一尝试曾以滑稽的失败告终。我从几个 YouTube 视频中学习到了如何更好地使用 AI。

效率低下也没关系

即使我已经接受了有一群神秘的工程师，他们的效率、力量、身高和魅力都比我高出十倍这一事实，我仍然对一个事实感到焦虑：我仍然不喜欢使用 AI 。一旦魔法消失，编码就变得索然无味。阅读 LLM 生成的代码很糟糕，礼貌地要求它使用一个没有产生幻觉的库是痛苦的。但如果我，尽管有这些缺点，在 AI 编程方面比常规编程高效 20%，那我做“正常”编程是否错误？如果存在更高产出的路径，我是否应该放弃？

不。牺牲一些效率以使工作愉快是可以的。不仅可以，在我们的领域中，这是必要的。如果你强迫自己以一种你讨厌的方式工作，你最终会 burn out。编码中只有一部分是写代码，其余的是解决问题、进行系统设计、思考抽象概念以及与他人沟通。当你感到愉快时，你会在这方面做得更好。对自己的工作感到自豪并欣赏这门手艺是可以的。从长远来看，你的代码库会因此受益。

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

哦，而且这个论点也适用于反向情况。如果你觉得做 AI 编程很开心，那就去做吧。如果你感到如此兴奋，以至于比以往任何时候都写更多的代码，那太棒了。我希望每个人都能感受到这种快乐，无论他们是如何达到的。

如何成为优秀的AI领导者

让所有工程师始终对自己的表现感到焦虑，这对公司不利。这会让工程师不想为你工作。这种短期思维会鼓励工程师追求糟糕的指标，如代码行数。代码审查会被忽视，技术债务会不断累积，长期来看，整个公司将为这些错误买单。

不切实际的 10 倍预期必然导致仓促且质量低下的工作。工程师需要有喘息的空间，有时间把事情做好。良好的代码库和优秀的公司都建立在对当下与未来平衡思考的基础上。我很幸运能在这类公司工作，但许多公司并不如此幸运。

不要责怪工程师没有使用足够的 tokens。工程师是在极具竞争力的领域中受过高等教育的专业人士。软件工程师早已因过度热衷于拥抱和放弃新语言与工具而臭名昭著。如果你支付给他们如此高的薪资，就应该信任他们：一旦出现能带来超级生产力提升的工具，他们会主动向你申请专业版计划。如果你担心错过其他人似乎都在获得的 AI 编码收益，那就注册一个 LLM 团队计划，举办一次培训 session，看看会有什么结果。这就是你需要做的全部。

结论

只要你加入正确的 Facebook 群组，你就会知道没有一种神奇的草药能预防所有疾病。只要你开始尝试氛围编码，你就会知道现在还没有所谓的AI编程革命可言。你没有错过任何东西。相信自己。你已经足够好了。

哦，还有，不要刷 LinkedIn。或者 Twitter。永远不要。

本文来自微信公众号：学术头条