本文探讨了“十倍工程师” （10x engineer）的概念，即那些工作效率远超普通工程师的个人。
首先提到了 AI 工具在提高工程师效率方面的潜力，并以作者的亲身经历为例，说明了 AI 如何帮助他在开发 Chaterm 项目时提高了两到三倍的效率。
引言
“十倍工程师”（10x engineer）这个说法，是指那些工作效率远超普通工程师的个人。这个概念最早可以追溯到 20 世纪 60 年代的研究，特别是 Frederick P. Brooks 在他的著作《人月神话》（The Mythical Man-Month）中提到的观点。Brooks 指出，在软件开发领域里，某些程序员的工作效率比其他程序员高出很多，甚至能达到十倍之多。这一观察后来被广泛引用，并逐渐演变成今天我们所熟知的“十倍工程师”的概念。
如今有越来越多的 AI 工具宣传能够提高工程师 10 倍的工作效率，包括但不限于 Anthropic、Trae、Devin 等知名 AI 公司。 
我最喜欢的吴恩达老师，也曾发表过长文来探讨 AI 如何使“10x”成为可能。吴恩达认为，随着越来越多的工作受到人工智能的支持，不只是“10 倍工程师”，会有更多的“10 倍市场营销人员”“10 倍招聘人员”“10 倍金融分析师”这样的“10 倍专业人士”出现。 
https://x.com/AndrewYNg/status/1887919658201960807?s=20
如果从 chatGPT 发布（2022 年 11 月 30 日）算起，Gen-AI 的风已经吹了 3 年了，Cursor 发布也已经有 2 年了，AI 真的给我们带来了 10 倍的效率吗？如果目前还没有，那要怎么做，才有机会更接近“十倍工程师”呢？
一个真实的案例
我想先从我自身出发，聊聊 AI 到底为我带来了多少效率提升。
在谈效率提升之前，我想先谈一谈如何去衡量效率。我们可以首先给效率下这样一个抽象定义：做同一件事，所花费的时间越短，效率越高。但是这样定义是不够的，这样只规定了“时间”，没有规定“质量”。对于软件工程的效率我觉得可以这样定义：做同一件事，以最小代码量实现并且做到 bug free 的情况下所花费的时间越短，效率越高。这样定义多了两个额外的要求，避免“垃圾代码”和“有问题的代码”。如果不做这两点规定，“提效”从何谈起呢。
我们在这里讨论的开发特指以团队形式开展的大型软件工程项目，不讨论个人项目或者玩具项目。以我参与的一个开源项目 GitHub - chaterm/Chaterm: Open source AI terminal and SSH Client for EC2, Database and Kubernetes.（一款 AI Terminal 工具）为例，这个项目的总计代码量在 8W 左右。原始项目的复杂度对于评估效率很重要，在 10W 代码量的项目中添加 1K 行代码，跟在 100W 代码量的项目中添加 1K 代码量难度是完全不一样的。 
最近我要开发一个新的需求——支持 MCP。为完成这个功能，我前后进行了大约 10 次 commit。其中最关键的是下面这两次提交，这两次提交涉及的功能更新共计 5000 行有效代码。
- feat:Add MCP support part1:UI & McpHub · chaterm/Chaterm@cc2be7a · GitHub
- feat:Add MCP support part2:integrate MCP tools into agent · chaterm/Chaterm@44e4b8e · GitHub
由于项目已经上线三个星期，并未发现 bug，所以我单方面判定这 5000 行代码为合格的代码（如果感兴趣的朋友也可以点开链接帮我 review 一下）。如果没有 AI 的帮助，完成这样一个功能我需要花费多少时间呢？我预计大概要一个月左右，算法很简单，假设手敲代码的情况下一天的有效代码量为 200~300 行，5000 行差不多需要一个月时间。
有了 AI 帮助，我花了多长时间呢？答案是一个多星期，不到两个星期。所以 AI 对我的提效大概是两到三倍左右。离十倍工程师还有很远的距离。如果想要做到十倍效率，那么完成这次功能应该只需要花费 2~3 天的时间。这有可能吗？经过复盘，答案是可能的。
下面我将阐述如何成为“十倍工程师”： 整体上可以分成几块：先选择一个顺手的工具，其次调整编程范式，然后是一些 AI coding 的小技巧，最后通过长期的刻意练习把这些提升沉淀成长期能力。
挑选自己最喜欢的 AI 工具
正所谓“工欲善其事必先利其器”，成为十倍工程师的第一步就是挑选适合自己的 AI 工具。如今的 AI coding 产品真的是琳琅满目、遍地开花。
目前市面上已有的 AI coding 产品主要分为四大类：
- IDE：Cursor、Windsurf、Kiro、Trae、CodeBuddy、Lingma
- CLI：Claude Code、OpenAI Codex
- IDE 插件：GitHub Copilot、Cline、Agument
- 网页端：Lovable、Replit
对于工具的选择，适合自己的才是最好的，基本上各家都做出了自己的特色。最好的选择方法是都去试一试，看看哪个用起来最顺手。不要看网上那些大 V/媒体一天天在那里吹，Claude Code 出来就吹 CC，Codex 出来又吹 Codex。这就像有人告诉你在 Vim 里编程效率很高一样，得实际体验了才知道。
如果你压根就不习惯在 terminal 里面“敲代码”，那 CLI 类的产品就不在你的选项范围内。如果你不是专业开发者，那么网页端的产品可能才是你的最佳选择。就我实际体验下来各家产品之间在 AI 能力方面压根没有那么大差异，所以选一个你用得最顺手的即可。
就我个人而言，偏爱 Cursor，核心原因就一个——Cursor 的 IDE 方便我审查代码。其他家的产品这一点做得并不是很好。最近我发现字节的 Trae 做得也很不错，而且价格也比 Cursor 便宜，下个月准备切过去试试。
做好代码审查
在谈及 AI 提效时，如果让我选一个原则的话，那一定是“做好代码审查”。这就像在使用辅助驾驶时“不要把你的双手脱离方向盘/不要把你的双眼移开路面”一样，AI coding 时尽量不要完全放弃对代码的最终决定权。
我知道现在有越来越多的人在使用 AI coding 时，都不再审查代码。他们的做法通常是这样的：给 AI 下达指令->AI 执行 coding->运行项目->查看功能是否实现->然后开始跟 AI battle：“我要的是这个，不是那个”、“我想要这种实现，不是那种实现”.....“你是傻逼吗”。如果你是一名 AI coding 实践者，多半也经历过这样令人崩溃的时刻。这是程序猿/攻城狮驯服 AI 必然会经历的痛苦过程。
我观察到推荐这种方式写代码的，很多都是非专业背景的开发者，而且主要以个人开发者为主，在推特上做 build in public（公开构建）的人尤其推崇这种方式。并且通常伴随着他们的“战绩”：从零开始使用 AI coding，在多么短的时间内，推出产品，并且做到了多少 MRR（月度经常性收入）。
可是大多人不是在做独立开发，而是在企业里做工程师。这两者不都是敲代码，有什么本质区别吗？这里面的区别可大了，如果你是独立开发，我认为你至少要用 50%的时间去“卖产品”，用剩余的 50%时间去“做产品”，产品做得好不好只决定了你成功的一半，甚至在我看来不到一半。而如果是在企业里面做工程师，你将用绝大部分的时间来“做产品”，而不太需要关心“卖产品”。并且企业中通常是以团队形式进行工程开发，这就使得“代码审查”变得更加重要。
除了代码的质量问题外，代码审查要格外注意一点：代码复用性。目前 AI 在这个方面还不算擅长，碰到问题，往往会随手写个新的函数出来，而不会优先去考虑代码中已经有可复用的函数，或者相似的逻辑。如果不够慎重，项目就会变得越来越臃肿，最终沦为 shi 山。
Spec 编程
在我们最开始接触 AI coding 时，通常的做法是“给 AI 下达指令->AI 执行 coding->运行项目->查看功能是否实现”，不断循环这个过程，直到实现我们想要的效果。在业界有一个专有名词来形容这种编程方式——Vibe Coding（氛围编程）。
经过几个月的实践，我发现 Vibe Coding 并非最佳的 AI coding 姿势。那么正确的姿势是什么呢？这里给大家介绍最近社区很火的另外一种 AI coding 理念/范式——Spec 编程。
Spec 编程的全称是“Spec-Driven Development”，规范驱动开发，Spec 是单词 specification 的缩写。它的核心思想是：把 “规格（spec / specification）” 作为开发的核心驱动力。
如果你上过大学的软件工程课，一下就明白这是什么意思了。软件工程课的大作业要求小组完成一个项目（通常是 xxx 管理系统），最后不仅需要提交一份代码，还需要提交 4 个文档，分别是：需求分析、概要设计、详细设计和测试文档。 
开源社区有一个项目GitHub - github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development专门帮助人们采用 SSD 进行开发。而亚马逊的 Kiro 直接将 Spec 设计为一种模式，Spec 模式下，在执行代码之前它会为你生成三个文档：
- requirements.md
- design.md
- task_list.md
讲到这你以为我是来向你推销 Kiro 的？哎，猜错啦！spec 编程只是一种理念，可以把这种理念运用在任何一款开发工具上。就像面向对象编程一样，用 C 语言也可以面向对象编程。
我们再来重看 Spec 编程，思考一下为什么要先有三个文档？
我想用这句话来解释是最贴切的：Plan first, then build。文档是一种指导，通过文档，我们可以事先知道后面做的事情是不是符合预期。如果不是就提前纠正，如果是就开始执行。至于有没有文档，其实不重要。文档的更新最好是事后的，统一的，而不是事先的，零散的。
下面我将演示如何在 Cursor 中进行 Spec 编程。
最近我将 Chaterm 的 AI 功能从单任务模式扩展到了多任务模式（也就是同时可以执行多个任务）。重构之后出现了一个 bug：回传结果时，无法把结果传回到发起请求的 Tab。 
选择 plan mode，将问题描述丢给 AI。它会给出问题的分析和解决方案。 
看起来 AI 分析得没毛病，但如果这个时候直接点 build，那就完蛋了。这样还是会陷入之前的“审查代码->否定方案->不断与 AI 校准”的循环中。这个时候我们可以理解为 AI 给出了一个“需求文档”，但是压根没有说“实现方案”。要知道 AI 最擅长：一本正经的胡说八道，即便模型已经迭代多年，但这样的情况还是经常发生。所以不仅要看它怎么说，还要看它怎么做。这个时候要求 AI 给出实现方案：
给出每一个实现的关键细节
在 AI 给出实现细节之后，不要着急点 build。这个时候应该去审查实现细节，现在审查要比修改代码之后再审查容易得多。关键就审查两个方面：首先是：数据结构和算法，只要这两点没有问题，那么程序基本上就不会有什么问题；其次是：代码复用性，看看 AI 是不是又写了一堆原本就有的新函数。 
AI 的实现细节大体上已经没有问题了，但遗漏了一些细节，就是资源清理。AI 每一次发送消息，都会将消息映射关系存下来，最后程序终止时才去销毁。假设用户发起了 500 次交互，就会保留 500 条映射关系。这显然是不合理的。 
给出下列指令（指令遵循三段论做什么？怎么做？为什么要这么做？ ）：
映射关系的清理需要提前。每一个消息回传之后，立刻清理。不然会堆积越来越来的映射关系 
一切就绪点击 build，一把就成功。修复这样一个 bug 只需要 10 分钟就搞定。如果不这样做，但凡跟 AI 多 battle 两轮，花费的时间就要成倍增加。并且这样写出来的代码，质量有保障。
看着这里，不知道你有没有感到奇怪，说好的 AI 干活呢？为啥感觉很多事情都是自己在做？AI 给出的方案需要自己来确认，AI 做错的地方需要自己来纠正，最后 AI 给出的代码还要自己来审核。这就对了，“十倍工程师”的瓶颈，很大程度上不在 AI，而在于使用 AI 的人。在我看来 AI 是一个资质普通，但悟性极高的工程师。只要你能告诉它正确的做法，它就能立刻将其实现。在现实中属于那种一点就透的人。
善用 User Rules & project rules
目前基本上所有的主流编程软件都支持自定义规则（User Rules 和 Project Rules），这是一个被严重低估的功能。通过在项目中设置明确的编码规范、架构约束、命名规则等，你可以让 AI 在生成代码时自动遵循这些约定。例如,你可以指定特定的设计模式、代码风格、甚至是你团队的最佳实践。这样一来,AI 生成的代码质量会显著提升,减少后期审查和修改的工作量。善用这些规则,相当于给 AI 配备了一个"编码指南",让它更懂你的项目需求。
通常而言，User Rules 会被置于最高优先级，例如放在 System Prompt 的最开头或者结尾。以保证 AI 尽可能遵循用户指令。所以当我们发现 AI 的回复不符合我们的预期。通过 User Rules 加以限制是最佳的解决方式。
我的 rules 中添加了以下几条限制 
MCP
MCP（Model Context Protocol）是 Anthropic 推出的一项强大功能，它允许 AI 直接与外部工具、数据库、API 进行交互。通过 MCP，你可以让 AI 访问项目文档、查询数据库、调用第三方服务等。
MCP 的使用有许多值得探索的地方，很多人觉得 MCP 没用。其实用好 MCP 能够极大的自动化工作流程。后面我会再写一篇文章单独来讲如何用好 MCP。
这里，我只举一个非常实用的例子。使用 AI coding 时，我经常会碰到这样一种情况：AI 扩展了我的认知边界，也就是 AI 解决了一个我都不懂的问题。很多人碰到这种情况，接受了 AI 的代码之后就算结束了。但其实，这恰恰是深入了解和学习新知识的好机会。"干中学"是对王阳明“知行合一”理念的很好诠释。有 AI 这个老师，可以让它把每一行代码拆开来讲解。搞懂了还不算结束，真正的高手总是善于总结。我们不是高手，总结也嫌麻烦，但是现在有了 AI 这个好帮手。
通过 MCP，让 AI 把问题总结好，并写入到自己的知识库中。可以使用 Notion/语雀/obsidian，这里我使用的是我们自己开发的 Confluence MCP server，用于连接企业的知识库。
以后隔一段时间，把笔记拿出来看一看，温故知新。 
反直觉的建议
很多人以为在 AI 时代，工程师应该把精力放在“如何更好地使用 AI 工具”上，比如 Prompt Engineering。PE 很重要，但不是根本。真正能让你脱颖而出的，仍然是你作为软件工程师的基本功。
以下这些乍看“反直觉”的建议，才是迈向“十倍工程师”的关键：
比以往任何时候都更深入理解你所使用的语言 不是泛泛地“会用”，而是深入到语言的类型系统、运行时机制、内存模型、并发模型等底层细节。 原因很简单：当 AI 给出一段代码时，你需要有能力判断其是否正确、是否高效、是否踩了底层机制的坑。AI 真的太容易写出看似正确的代码了。稍不注意就会被带入坑里。每次纠正它时，它只会说：你说得太对了！
比以往任何时候都更深入理解你所使用的框架 理解框架的运行机制、生命周期、数据流、性能瓶颈，你才能指导 AI 写出“符合框架最佳实践”的代码。如果对框架的理解不够深入，就只能接受 AI 写出的看似 work 的代码。这方面也是踩了很多坑。
掌握好数据结构和算法 即使 AI 能写代码，数据结构和算法仍是软件工程的“终极底层逻辑”。 你需要知道什么结构适合什么场景、复杂度如何。这样你才能判断 AI 是否给了你一个不错的解法，而不是由 if else 堆砌起来的 shi 山代码。
熟读设计模式 设计模式本质是一套“如何写出可维护代码”的经验总结。当需求变更、功能增加时，一个结构清晰、职责明确的模式可以让你改动最少的代码，而不是把整个系统拆掉重来。正如我前面所说，AI 真的很容易写出 if else 垃圾代码。AI 能写代码，但 AI 不会替你做架构决策，不会为你考虑项目未来的可扩展性。设计模式正是这种结构性思考的核心能力。未来的工程师角色将会变成：你负责思考结构，让 AI 去实现细节。
做这一切为了：更好的审查 AI 的代码、更好的指导编写代码。终极目标只有一个：成为架构师。未来的开发工作模式就是一个人指导一堆 Agent 干活。
成本
最后我想谈一谈成本。过去一个月，我在 Cursor 上的花费大约是 60~70 $，还未达到 Cursor 和 Claude 设定的最高档 200 $。这可能也是我没有成为"十倍工程师"的原因之一——用量没有达到十倍，效率自然也无法达到十倍。
这里说的“用量”，不是为了刷额度而瞎问，而是尽可能让 AI 多参与真实的工程任务：写代码、查问题、改设计，然后由自己认真审查和纠偏。高用量的本质，其实是你和 AI 之间形成了高频的反馈循环——你越会用它，它也就越能帮你把效率拉高。
我知道有些很厉害的工程师很早之前就已经达到 200 $配置限制。当时我并没意识到他们对 AI 的利用已经达到何种程度。大家可以试一下，就算不审查代码，仅以实际运行来判断 AI 生成代码的可靠性这种方式来使用 AI，要达到 200 $的使用限额，都是一件非常困难的事。
等到我的用量达到 200 $一个月时，我会再写一篇文章阐述我的实践。
展望
想要成为“十倍工程师”，不管有没有 AI 都不是一件容易的事情。但 AI 的出现确实为我们提供了一种可能，将 AI 作为放大你能力的杠杆。关键在于，你要先成为一个优秀的工程师，才能借助 AI 成为"十倍工程师"。在此基础上通过刻意练习，来无限地接近这一目标。
如果你做的是大型软件工程项目，预计在未来三到五年内，可能都无法做到“脱手”让 AI 自己去干。在这段时间里，我们能做的是把 AI 擅长的发挥到极致，并借此提升自身的能力以适应未来世界对工程师的要求。
拥抱时代的人，永远不会被时代抛弃