AI编程工具真的提升效率了吗?一个开发者说了一句实话

大家好，我是Jacob。

最近一个开发者发了条推文，说了句大实话："用AI写代码反而更慢，但我写得更爽。"

然后整个人程序员圈都在讨论这件事。

那条让我意外的帖子

Nolan Lawson（一个前端开发者，之前在微软和Google工作过）在博客里写了一篇文章，说他最近用AI编程助手写代码，发现一个让他意外的事实：

AI确实让他写代码变得更慢了。

不是因为他不会用，恰恰相反，他很会用。他用Cursor用了三个月，配合 Copilot，每天都在用。熟练程度应该超过99%的开发者。

但他的感受是：写代码的速度确实快了，但完成一个功能的整体时间没有变快，甚至更慢了。

原因是：AI写代码很快，但review代码、纠正AI的错误、搞清楚AI写了什么——这些时间把"写代码"省下来的时间全部吃掉了。

2023年开始，整个行业都在说"AI让人效率提升10倍"。工具厂商在宣传，投资人在鼓吹，所有人都在说你要是不用AI你就要被淘汰了。

但 Nolan 的体验把这个叙事戳了一个洞。

他的观点是：AI编程工具在"写代码"这件事上确实快，但它不能独立完成工作。

它不能帮你理解业务逻辑。它不能替你做产品决策。它写的代码需要你review，需要你测试，需要你搞清楚它写了什么。

这些工作以前也存在，但现在加上AI之后，这些工作不是变少了，是变多了。

Nolan 提了一个很重要的概念区分：

代码产出速度 ≠ 完成任务速度

代码产出速度是指：你今天写了多少行代码。

完成任务速度是指：你今天交付了多少功能，解决了多少问题。

AI让第一个数字变大了，但它有没有让第二个数字变大？不一定。

他举了一个例子：以前他写一个功能需要1小时，代码量500行。引入AI之后，他写同样的功能只需要30分钟，代码量800行——AI帮他多写了很多边角情况和测试代码。

但这个功能交付的时间呢？1小时变成了1.5小时。因为他需要花额外的时间review AI写的代码，确认逻辑是对的，搞清楚AI写的那些他没想过的边界情况。

Nolan 不是一个AI怀疑论者，他说AI在很多场景下真的很好用。他的经验是：

AI编程的边界：

1. 简单、标准化的任务 ✓
写一个标准的数据校验函数，把API响应转成对象，写一个简单的CRUD接口——这类任务AI写得又快又不出错，基本不需要review。
2. 需要大量重复的模式 ✓
比如你要给100个字段写数据校验，AI帮你生成模板，然后你来填充具体逻辑。这种工作AI能省大量时间。
3. 你不熟悉的技术栈 ✓
第一次用某个新框架，不知道怎么写基本的Hello World，让AI给你出示例代码，效率提升明显。
4. 复杂业务逻辑 ✗
你做了一个五年的业务系统，里面有无数的历史包袱和微妙的业务规则。AI完全不理解这些，写出来的代码要么有隐藏的bug，要么和现有逻辑冲突。review的成本比重新写还高。
5. 需要深度领域知识的代码 ✗
比如一个金融风控系统，一个医疗影像处理模块。AI能生成看起来专业的代码，但它的"专业"是语言层面的，不是领域知识层面的。你需要花时间去验证它写的每一行逻辑。
6. 长期维护的项目 ✗
项目维护的时间维度越长，AI的问题越多。AI写的代码可读性差，三个月后你自己都看不懂它写了什么。

Nolan 提出了一个悖论：

AI让你写代码更爽了，但不一定让你工作更快。

他解释说，用AI写代码的时候，他进入了某种"流状态"——那种心无旁骛、沉浸其中的状态。因为他在扮演一个"指挥者"的角色，下指令、接收反馈、做决策，而不是埋头写代码。

这种体验让他更享受工作。

但享受工作不等于工作效率高。

我觉得Nolan说的不是AI不行，而是我们对AI的期待需要调整。

AI编程工具现在解决的问题是代码产出，而不是问题解决。

如果你用AI帮你产出代码，然后你负责解决问题——那这个组合是很强的。

如果你期待AI帮你解决问题，只让你产出代码——那现在还做不到。

用一个不一定恰当的比方：AI现在更像是一把更快的笔，而不是一个更聪明的产品经理。

你用更快的笔写字，你的字可能写得更好看了。但你写的东西有没有价值，还是取决于你想表达什么。

Nolan 的结论是："AI让我写得更慢但更爽。"

我的结论是：如果你正在用AI编程，但发现效率没有明显提升——你不是一个人。

这不是你的问题，这是工具的现实边界。

搞清楚这个边界，才能真正用好AI。