治愈你的“AI 10 倍工程师冒名顶替综合症”
几个月前，我经历了一段小小的精神低谷。我一直对自己的工程师能力充满信心，但在刷领英和推特时，我禁不住感到自己的技能正无可救药地落后。如果这些地方说的都是真的，那么工程界早已告别了那种在编辑器里敲代码的中世纪做法。真正的工程师现在的生产力是我望尘莫及的 10 到 100 倍。我写这篇文章，是希望能帮助那些和我有类似焦虑感的人。
我是一个多疑的人，所以当我听到这样的说法时，通常不会立刻信以为真。我只会翻个白眼，就像有人告诉我一种简单的草药能包治百病一样。但是，眼下这种“10 倍工程师”的论调声势浩大，开始让我坐立不安。万一我错了呢？如果我现在不学着用 AI，会不会错过这班车，然后变得无人问津？毕竟，现在流传着很多花哨的词汇，把这些人谈论的“AI”和我所熟悉的“AI”区分开来。
这些人用的是*✨AI 智能体✨。他们用的是✨会思考✨*的模型，这些模型能上网、跑测试、还能自己纠正错误。当然，我偶尔也会在聊天窗口里让它写点代码，然后在领会了所需思路后，就把大部分输出结果扔掉了。但那些工程师却让 Claude 这样的工具完全掌控方向盘，他们的 AI 智能体在他们泡晨间咖啡的时候，就已经为他们提交了 5 个拉取请求（PR）。难道我正在变成一个食古不化的老顽固，一个对着云朵咆哮的老头吗？
让我如此焦虑的部分原因是，AI 完全有可能在我不知情的情况下发生了改变，因为我并不怎么用 AI。因为我并不怎么喜欢用 AI。审查代码远不如编写代码来得愉快。难道我那份对享受编程的执着，反而让我落后于时代了吗？
投身其中
终于，我到了一个临界点，决定必须一头扎进 AI 编程的世界。我试用了 Claude Code、Cursor、Roo Code 和 Zed，因为它们都承诺提供 AI 智能体编程功能。我开始让 AI 在各种项目中编写各式各样的代码。我尝试了不同的模型并进行比较。我甚至有几次完全“凭感觉编程”，一次都没有手动编辑过代码。
结果……还行吧。尽管有人声称如今的 AI 正在飞速进步，但给我的感觉和以前大同小异。它擅长编写样板代码，尤其是在 Javascript 领域，特别是在 React 中。但它不擅长跟上你代码库的标准和实用工具。它在处理像 Terraform 这样的语言时往往很吃力。它仍然会胡乱编造一些库，导致严重的安全漏洞[2]（英文维基百科链接：词糊侵占）。
AI 仍然难以吸收大型代码库的上下文，即使有很好的提示和一个 CLAUDE.md 文件也无济于事。如果你使用一个不是 StackOverflow 上的宠儿的库，即使 AI 智能体查询了文档，它也还是会把代码写得一塌糊涂。AI 智能体偶尔会做一些巧妙的事情，比如修复它们自己弄坏的测试。但它们常常只是在浪费时间和 token，在失败后与自己来回拉扯，似乎并没有从中获得任何更深层次的认知。因此，对我来说，AI 的最佳用例仍然是编写一次性脚本。尤其是在我完全没兴趣为了一个脚本去学习更深层基础知识的时候，比如在编写自定义的 ESLint 规则时。
那些黑暗的警告——如果我现在不开始使用 AI，我就会无可救药地落后——被证明是毫无根据的。学习使用 AI 编程并不难。这不是很明显吗？嗯，AI 编程社区似乎在这个问题上存在分歧：一方认为 AI 让编程变得像原始人也能做一样简单，另一方则认为这需要一套先进、专业的提示工程师技能。你需要学习的东西确实有一些，但很快就能上手。你会学会如何将任务分解成更小的部分，这样 AI 就不会在长篇大论的后期精神错乱。像 Claude Code 这样的工具甚至能自己完成一部分分解工作，虽然不总是那么可靠。你还会学会识别 AI 何时偏离得太远，以及何时该由自己接管。
一个称职的工程师在中度使用 AI 不到一周的时间里，就能搞定这些事情。此外，如果 AI 即将（像每个人不断说的那样）在任何时候变得好上 2 倍、10 倍或 100 倍，那么现在学习如何使用它的任何经验对未来都毫无意义。
每次我发现 AI 的工作表现只是“还行”时，都奇怪地让我更加焦虑，而不是宽慰。这意味着我找不到那种能让其他人如此高效的秘密武器。我就是没有那个本事：恐龙，遇见你的小行星吧，你的名字叫 AI。最终，有几件事把我从这种低谷中拉了出来。其中之一是 Ludicity 博客上的这篇文章[3]，它直接反驳了那些 AI 鼓吹者的说法。我写下这篇文章，是为了分享更多帮助我走出“AI 10 倍工程师冒名顶替综合症”的东西。
算笔账
让我们先来看看 10-100 倍生产力的简单算术。10 倍生产力意味着十倍的产出，而不是十倍的代码行数。这意味着你过去一个季度才能交付的工作，现在一个半星期就能完成。这些数字应该让最狂热的 AI 信徒都停下来想一想。传统上需要 3 个月工作量才能完成的产品构思、故事点谈判、错误修复、代码审查、等待部署、测试和质量保证，现在 7 个工作日就搞定了？要实现这一点，这些瓶颈中的每一个环节也必须实现 10 倍的生产力提升。
任何在真实公司里写过实际代码的软件工程师都知道这是不可能的。你不可能把 3 个月的代码审查来回沟通压缩到 1.5 周内完成。当你进行代码审查时，你会：
1. 标记你的审查者 2. 希望他们能尽早处理（这会很困难，因为他们显然在审查比以前多 10 倍的代码） 3. 在等待时切换到其他事情上 4. 看到一条通知（可能立刻，也可能在你的审查者下线两小时后） 5. 切换回审查任务 6. 阅读他们的评论 7. 做出相应回应 8. 周而复始。
在一个有良好标准和沟通实践的称职公司里，这个过程可以变得相当高效。但你告诉我，你为了处理 10 倍的工作，把这个过程的效率提高了 10 倍？这根本办不到。
实际企业软件工程中涉及的人为流程并没有发生重大变化。产品经理可能会用 ChatGPT 做“研究”，但他们并不会突然产出比以前多十倍的、经过充分审查、理由充分、估算准确的用户故事。他们不可能同时进行 10 场用户访谈。设计师和 QA 测试员也是如此。为了跟上进度而雇佣 10 倍数量的产品经理是不可行的。随着网络效应和官僚主义的滋生，每一次招聘带来的回报都会递减。
即使我们假设人们的意思只是实际的编码过程现在快了 10-100 倍，我们仍然应该对这个算术结果持怀疑态度。当你写代码时，你真正花在敲击键盘上的时间有多少？可能比你想象的要少。你大部分的黄金编程时间实际上是在阅读和思考，常常是在等待编译、页面刷新或测试运行时度过的。大语言模型并不能让 rustc 编译器跑得更快。
大语言模型生产的东西常常是坏的、胡编乱造的，或者低于代码库标准的。这些错误的频率随着代码库规模的增大而增加。当这种情况发生时，你必须重新提示，这可能立刻解决问题，也可能是在浪费大量时间。或者你可以自己动手修复代码。但那样你就又回到了区区 1 倍工程师的状态，甚至可能更糟，如果你已经习惯了“凭感觉编程”以至于忘记了如何编码[4]的话。如果你“拥抱感觉”，连生成的代码看都不看一眼，那么一旦代码库变得足够大，你就会撞上生产力的南墙。而一旦你撞上南墙，你就必须面对完全缺乏标准和适当抽象的烂摊子。
我觉得有时候人们对 10 倍提升到底有多大失去了概念。10 倍的差距，好比是你的面包车和创纪录的超音速陆地喷气车[5]之间的区别。想象一下，你想用一辆时速 600 英里（约 965 公里）的汽车在你城市的街道上开完 10 分钟的通勤路程。你能在原来时间的十分之一内到达城市的另一边吗？不，因为哪怕一个 60 秒的红灯都会耗尽你所有的时间预算。F1 赛车在普通转弯时也要减速到面包车的速度。事实证明，任何活动的大部分时间都不是在以最高速度进行的。
100 倍的生产力意味着你现在用两天时间就能完成过去一年的工作。对于这种规模的数字，其荒谬之处我甚至无需赘言。
10 倍工程师存在吗？
我本不想介入这场辩论，但或许我不得不说几句。我的答案是：有时存在，某种程度上。当我有幸遇到那些价值是他人 10 倍的工程师时，这主要归功于他们防止不必要工作的能力。说服产品经理放弃一个根本不可行的任务。让另一位工程师不去构建那个不必要的微服务。进行开发者体验方面的投资，为每个人在每项任务上都节省一点时间。记录你的工作，以便未来的每一位工程师都能更快地上手。随着时间的推移，这些事情累积起来，一个工程师就能为整个公司节省下比他构建这些东西所花时间多 10 倍的时间。
这种性质的工作并不总是唾手可得，所以优秀的工程师只有在特定情况下才能发挥出 10 倍的生产力。到了一定阶段，每个工程师都需要开发功能，一个优秀的工程师可能会比一个初级工程师快两倍，但他们仍然会遇到和以前一样的瓶颈。尽管故事点有其缺陷，但我从未见过哪个工程师能够持续地完成比普通工程师多十倍的故事点。
值得注意的是，AI 编程助手在防止不必要工作方面几乎无所作为。恰恰相反，AI 似乎常常鼓励草率行事和过度构建。当我询问架构问题时，它经常推荐一些在我睡了个好觉或与一位优秀工程师交谈后，才意识到并非必要的东西。在所有其他条件相同的情况下，一个编码更快的程序员是更好的工程师吗？是的，但这并不是产生 10 倍差异的关键因素，而且很难保持所有其他条件都不变。你越是专注于尽可能快地完成任务，就越容易错过那些能减少总工作量的重要的省时机会。
那么，那些鼓吹 AI 的人是在说谎还是怎么了？
我认为那些鼓吹 AI 的人是以下几种情况的混合体，按恶意程度从低到高排列：
• 善意的人们，他们错误地衡量了自己和他人 • 在个人或财务上与 AI 的成功深度绑定的人（AI 初创公司创始人、投资者等） • 老板们，他们公然试图让工程师感到朝不保夕，这样他们就不会辞职、寻找其他工作或要求加薪
数学不好的善意工程师
根据我的经验，AI 能带来罕见的、短暂的 10-100 倍生产力爆发。当我让 AI 在几分钟内为我编写一个自定义的 ESLint 规则时，如果自己动手，这可能需要花费数小时查阅文档和教程，这确实是数量级上的时间和精力提升。这样的时刻确实会随着 AI 的使用而发生。许多职业生涯中非程序员的人在用 Lovable 这样的工具搭建起一个应用后的头几天里，也感受到了这种魔力。
问题在于，生产力并不会线性扩展。我每年写的 ESLint 规则不超过一条。这次生产力的爆发，完全是因为我不在乎这些代码，也不打算费力让它对下一位工程师可读。如果不断编写 ESLint 规则成为我的核心工作要求，我就会花一次性成本去学习 ESLint 的内部工作原理。在那之后，“凭感觉编程”写一条规则和我自己写一条规则所需的时间就不会有太大差别，特别是当你还要加上额外的时间来让代码对人类可读，以便 6 个月后我再回来看这个文件时能看懂。
最终，每个“凭感觉编程”的程序员都会达到一个回报急剧递减的点。他们的网站被黑了[6]，他们需要真正花时间去学习安全知识是如何运作的。应用变得太大，超出了上下文窗口的限制，东西开始看起来和用起来都不一致了。真正懂行的前端工程师被雇来实施一致的设计系统和用户体验。
还有很多简单的偏见和盲点也可能造成生产力幻觉。如果你离开大公司的深渊去一家初创公司，你会真切地惊讶于每个工程师的生产力有多高。很容易把这归功于 AI。有些人真的非常享受 AI 编程的技术新奇感，而当你在一个新事物上工作时，你常常会感觉自己比以往任何时候都做得更多。我知道我第一次使用 Python 时，感觉自己就像在“吸火箭燃料”，但是，和所有其他技术一样，它总会回归现实。
我认为很多更真诚的 10 倍 AI 炒作来自于那些正处于蜜月期，或者还没有坐下来认真思考 10 倍提升在数学上意味着什么的人。如果 AI 能帮助许多工程师在某些任务上快 20-50%，我不会感到惊讶，但软件瓶颈的性质意味着这并不会转化为 20% 的生产力提升，更不用说 10 倍的提升了。
激励至关重要
听着，我不是 AI 初创公司的黑粉。如果你想把 OpenAI 的 API 接入你的医疗健康创业公司，我可能会对其中的风险挑一挑眉毛表示担忧，但对于任何想在医疗领域“快速行动，打破常规”的创业公司，我都会有同样的担忧。我这里的目的不是说 AI 初创公司的创始人或投资者是邪恶的，甚至是不诚实的。我的观点是，用你高中经济学 101 教授那种单调的声音说：“激励至关重要”。
如果你正在运营一家 AI 初创公司，而其他所有 AI 初创公司都在告诉投资者，他们借助 AI 实现了 10 倍以上的生产力，那么激励机制就显而易见了：你也应该在公开和私下场合说同样的话。如果你的公司是建立在 AI 的基础之上的，你就有动力把 AI 宣传成生活中方方面面的奇迹解决方案。如果你是 AI 初创公司的一名工程师，而你的老板问你：
“嘿，你现在借助 AI 生产力提高了 10 倍，就像所有其他工程师一样，对吧？”
你就有强烈的动机说是。而当其他所有工程师都出于同样的原因说是的时候，那位 CEO 并没有说谎[7]，他只是在转述他听到的情况。
我想向那些和我一样感到焦虑的人强调的是，这并不是什么新鲜事。CEO 们并不是不带偏见的信源。高管们一直在声称，从敏捷开发到迈尔斯-布里格斯性格测试，各种东西都释放了无限的生产力。领英上总会有新的协同增效流行词，别让它让你沮多吉少。实际上，干脆别再刷领英了。那是个愚蠢的地方。
赤裸裸的恶意
当有人说了一些让人们感到焦虑的话时，至少在某些时候，你应该得出结论，那正是说话者想要达到的效果。老板们试图让他们的工程师感到自己的职位岌岌可危，这也并非新鲜事。我们都记得那种说法：一个为期 3 个月的编程训练营就能培养出与四年制学位质量相当的工程师，所以你最好别太嚣张，否则你就会被一个转行的文科学士取代。然后几年过去了，人们意识到训练营的毕业生通常对实际的软件工程准备严重不足[8]，因为他们没有得到适当的基础。
训练营和 AI 都只是一长串试图将软件工程这个高度昂贵、高度专业化的领域商品化的拙劣威胁中的例子。它们是旨在暗示不稳定性的修辞手段。你的老板实际上不能解雇你然后用 AI 取代你，但他可以让你感觉他可以，这样你或许就不会要求加薪了。
“10 倍 AI 工程师”的故事，有一部分可能就是由那些纯粹想让你为此感到难受的人讲述的。这部分占多少，我不知道。尽管在当今这个时代我们彼此之间变得高度不信任，我仍然相信大多数人本质上是正派的，所以我不倾向于相信这个比例很高。
隔着一层
我注意到，所有这些 AI 编程炒作文章中的角色，几乎总是与实际的生产力效益隔着一层关系。发帖的人是创始人、经理或投资者，他们对别人的生产力大加吹捧。二手信息本身没有错，但如果你找不到一手信息源，你可能就要开始质疑信息的可靠性了。
而来自真正工程师的演示，展示他们如何用 AI 提高生产力，其内容则更加多样化，赞誉之词也更加克制。这些演示所展示的 AI，基本上还是你我在变得如此焦虑之前所熟悉的那个技术：一个不错的文本生成器，有时能变出魔术，但常常需要你亲自接管。
AI 在开源项目上的使用，其生产过程可以被公开见证，结果却出了名的惨不忍睹[9]。我确实从一些 YouTube 视频中学到了一些如何更好地使用 AI 的知识。上面那篇 Ludicity 的文章中引用了一个不错的视频，链接在这里[10]。不过我还是给你剧透一下吧，这位工程师并没有找到编码生产力的青春之泉。
生产力低一点也没关系
即使在我克服了那种“存在一个秘密工程师部落，他们现在比我生产力高十倍、更强壮、更高大、更性感”的想法之后，我仍然对一件事感到有些焦虑：我依然不怎么喜欢使用 AI。一旦魔力消退，“凭感觉编程”就变得极其乏味。阅读大语言模型生成的代码很痛苦。礼貌地请求它不要使用胡编乱造的库是一种折磨。但如果，尽管如此，我“凭感觉编程”的生产力比常规编程高出 20% 呢？如果有一条产出更高的路径可走，我选择“正常”编程会是错的吗？
不。为了让工作变得愉快而牺牲一些生产力是可以的。不仅可以，这在我们的领域里是至关重要的。如果你强迫自己用一种你讨厌的方式工作，你只会精疲力竭。编码中只有一部分是写代码，其余的是解决问题、进行系统设计、思考抽象，以及与其他人沟通。当你感觉良好时，你在所有这些方面都会做得更好。为自己的工作感到自豪，欣赏这门手艺，这都没关系。从长远来看，你的代码库会因此受益。
数字音乐听起来是否客观上比黑胶唱片好并不重要。翻动唱片是否比让流媒体服务在百分之一秒内自动播放下一首歌更“低效”也不重要。如果听一张 70 年前的唱片让你更快乐，那就去做吧。这样做，你会比强迫自己使用更“高效”的流媒体服务听更多的音乐。如果你用自己喜欢的方式写代码，你会花更多的时间写代码，而且会写出更好的代码。
哦，这个论点反过来也完全成立。如果你觉得用 AI 编程感觉很好，那就去做吧。如果你因此感到兴奋，编码比以往任何时候都多，那太棒了。我希望每个人都能有这种感觉，无论他们通过什么方式达到。
如何成为一名优秀的 AI 领导者
让你的所有工程师对他们的表现感到持续焦虑，对你的公司是有害的。这会让你的工程师不想为你工作。这只会导致短视思维，鼓励工程师们去最大化像代码行数这样的糟糕指标。代码审查会被忽视，技术债务会累积，从长远来看，整个公司都将为这些错误买单。
不切实际的 10 倍期望，毫无疑问会导致工作仓促，从而质量低下。工程师需要有喘息的空间。需要有时间多花一点点功夫把事情做对。优秀的代码库和优秀的公司都建立在为今天和明天思考的健康平衡之上。我很庆幸现在能在这样一家公司工作，但许多人没有这么幸运。
不要因为工程师没有使用足够的 token 而责备他们。你的工程师是在一个竞争极其激烈的领域里受过高等教育的专业人士。软件工程师们早已因其对新语言和工具过度热情的拥抱与抛弃循环而“臭名昭著”。如果你付给这些人这么多钱，你就应该相信他们，如果一个超级惊人的生产力提升工具出现了，他们会主动来找你要求购买专业版套餐。如果你担心错过其他所有人似乎都在获得的 AI 编程收益，那就注册一个大语言模型团队套餐，举办一次培训，然后看看结果如何。这就是你需要做的全部。
结论
没有什么秘密的草药能包治百病，就摆在那里，只要你关注了正确的 Facebook 群组就能找到。也没有什么 AI 编程革命，只要你开始“凭感觉”就能获得。你并没有错过任何东西。相信自己。你已经足够优秀。
哦，还有，别刷领英。也别刷推特。永远别。
