10 倍 AI 工程师神话:别信营销,看清工程物理学
别再为“10 倍 AI 工程师”的鬼话焦虑了。AI 是个有用的副驾驶,但它无法改变软件工程的基本物理定律:真正的瓶颈是思考和沟通,不是打字。
- 工程瓶颈在人类,不在机器: 软件开发最大的耗时是产品构思、代码审查和团队协作。AI 无法 10 倍加速这些人类沟通的物理极限。
- AI 目前只是个高级脚本小子: 它擅长生成样板代码和一次性脚本,但在理解大型、非标代码库的上下文和标准时,表现极其拙劣,甚至引入安全漏洞。
社交媒体上到处都是关于 AI 让工程师效率提升 10 倍甚至 100 倍的鼓噪。我周围的每个人,从顶级工程师到 VC,都在谈论这件事。这让我一度陷入了严重的自我怀疑:难道我错过了什么根本性的变革?我是不是要被淘汰了?
作为一个工程师,我习惯于用第一性原理思考。所以,我决定亲自下场,做个实验,把市面上所有号称能“代理编码”的工具——Claude Code, Cursor, Roo Code——全都深度用了一遍。
结论很简单:也就那么回事。
AI 的真实能力:一个不错的副驾驶,仅此而已
AI 现在能做什么?它很擅长写样板代码,尤其是在前端框架如 React 中。对于那些你懒得深入学习、只需要一次性使用的东西,比如写一个自定义的 ESLint 规则,它确实能省下你几个小时查文档的时间。这在某些孤立任务上,可以称得上是 10 倍的效率提升。
但问题在于,这种“爆发式”的生产力无法扩展。你一年会写几个 ESLint 规则?一旦任务进入一个真实、庞大、有历史包袱的代码库,AI 的弱点就暴露无遗:
- 上下文理解能力为零: 即使你给它喂了详细的
CLAUDE.md
,它仍然无法真正理解你代码库里的抽象和设计哲学。如果你用了一个非主流的库,它会无视你的文档,固执地用 StackOverflow 上最常见的方式去瞎搞。 - 代码质量堪忧: 它生成的代码往往不符合你团队的标准,充满了“魔法数字”和糟糕的抽象。你 review 它代码的时间,可能比你自己写一遍还长。
- 安全风险: AI 会“幻觉”出一些根本不存在的库,这直接导致了严重的安全漏洞,比如依赖混淆攻击。
所以,目前 AI 的最佳用途,仍然是作为一个代码片段生成器和一次性脚本的撰写工具。它是个副驾驶,能帮你处理一些导航和切换音乐的琐事,但方向盘必须牢牢握在你手里。
10 倍效率的数学谬误
让我们用物理学常识来分析一下“10 倍效率”这个说法。
10 倍的产出,意味着你过去一个季度(约 60 个工作日)完成的工作,现在需要一个星期(5 个工作日)搞定。这意味着产品构思、需求评审、设计、开发、代码审查、测试、部署这些环节,每一个都要快 10 倍。
这可能吗?
一个工程师都知道,写代码的时间可能只占整个开发周期的 20%。更多的时间花在了等待编译、刷新页面、跑测试、和同事开会、跟产品经理吵架上。大型语言模型并不能让rustc
的编译速度变快。
代码审查这个环节就是个不可逾越的物理瓶颈。一个 10 倍工程师提交了 10 倍的代码,他的同事就需要审查 10 倍的代码。这个来回沟通、上下文切换的过程,你告诉我怎么压缩 10 倍?除非你的公司能同时雇佣 10 倍的产品经理、设计师和 QA 来跟上这个节奏,但这又会因为组织复杂度的指数级增长而产生新的瓶颈。
把一个 10 倍的效率提升比作将你的通勤车换成一辆超音速陆地喷气车。你从家到公司需要 10 分钟,换车后理论上只需要 1 分钟。但只要路上有一个 60 秒的红灯,你的全部时间预算就被吃掉了。现实世界的工程,就充满了这样的“红灯”。
真正的 10x 工程师做什么?
在我看来,真正有 10 倍价值的工程师,他们的价值体现在阻止不必要的工作上。
他们能说服产品经理放弃一个不切实际的需求;他们能阻止另一个工程师搭建一个过度设计的微服务;他们会花时间改进开发者体验,让整个团队的每个人在每个任务上都节省一点时间。
这种工作需要的是深度思考、系统设计能力和出色的沟通技巧。而 AI,恰恰最不擅长这个。它只会鼓励草率和过度构建。
谁在鼓吹这个神话?
- 善意的误算者: 很多工程师在体验到 AI 带来的局部效率爆发后,错误地将其外推到全部工作中。
- 利益相关者: AI 创业公司的创始人和投资者,他们的商业模式建立在“AI 是奇迹”这个叙事上。他们必须鼓吹这一点。
- 别有用心的管理者: 创造一种“你再不拥抱 AI 就会被淘汰”的焦虑感,是一种管理手段,目的是为了让你不敢要求加薪或跳槽。这和当年鼓吹“三个月训练营毕业生就能取代科班工程师”的论调,如出一辙。
所以,别再焦虑了。你没有掉队。专注于提升解决复杂问题的能力、系统设计能力和工程品味。这些才是真正稀缺且无法被 AI 替代的东西。至于那些 AI 工具,把它们当成一个更聪明的代码补全器就行了,别让它 PUA 你。
To Do list
当你感到技术焦虑时,亲自深入实践以形成你自己的第一手判断。
将 AI 视为一个编写一次性脚本和样板代码的有用工具,而非全能代理。
学会快速识别 AI 何时偏离轨道,并果断地由自己接管控制权。
用基本的数学和逻辑来审视那些关于生产力提升的夸张说法。
认识到软件工程中最大的时间成本,是思考和与人沟通。
将你的职业发展重点放在阻止不必要的工作上,这才是真正的 10 倍价值。
在评估关于 AI 的说法时,要考虑信息来源的潜在动机和激励因素。
停止或减少浏览那些可能引起职业焦虑的社交媒体平台,如 LinkedIn。
优先考虑你工作的乐趣和满足感,因为这对于避免职业倦怠至关重要。
作为领导者,信任你的团队,并为他们提供学习新工具的资源。
不要强迫自己或你的团队以一种令人不快的方式工作来追求虚幻的生产力。
如果你对 AI 编码感到兴奋和高效,那就继续做下去,找到适合你的方式。
不要因为 AI 的出现,而放弃学习技术的基础原理和最佳实践。
当一个任务变得重要和常规时,投入时间去学习它,而不是一直依赖 AI。
从一线工程师的演示和反馈中学习,而不是从创始人和投资者的宣传中。
记住,历史上总有新的技术被吹捧为生产力的灵丹妙药,要保持冷静。
不要因为别人都在谈论某件事,就轻易放弃自己的怀疑和批判性思维。
如果你想成为一名优秀的 AI 领导者,请为你的工程师创造一个可以呼吸的空间。
不要用消耗的 token 数量来衡量工程师的生产力,这是个糟糕的指标。
请记住,你没有错过任何秘密,相信你自己的能力和判断。
Title: No, AI is not Making Engineers 10x as Productive
Paper: https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/