AI写代码：为什么我用Copilot反而更慢了？

上个月我在赶一个后端接口，逻辑不复杂，就是订单状态的流转。打开Cursor，噼里啪啦敲了几行注释描述需求，AI唰地一下给我生成了四十多行代码。

我盯着屏幕看了十五分钟。

不是在欣赏，是在debug。它把一个并发场景的竞态条件完全忽略了，而且用了一个我在项目里从来没见过的写法。最后那段代码我自己重写了，从头到尾。

关掉IDE之后我就开始想：这三个月用AI写代码，我到底变快了还是变慢了？

碰巧刷到了Nolan Lawson的博客。这哥们以前是Mozilla的工程师，开源项目在GitHub上拿了几千颗星，不是那种随便写写技术文章的人。他写了篇《Using AI to write better code more slowly》，核心观点就一句话：AI让他写出了更好的代码，但也让他放慢了脚步。

几千个Hacker News的点赞说明不止我一个人有这种感觉。我自己观察下来，AI拖慢速度的原因其实很具体，而且可以拆解成几个维度来看。

第一个成本：你需要花时间"读懂"AI的代码

最直接的，AI生成的代码你得读。不是扫一眼那种读，是真的去理解它的逻辑链。

你自己写代码的时候，脑子里已经有完整的推导过程，每一步都是你自己的。变量为什么这么命名、循环为什么从这里开始、为什么用map而不是forEach——这些决策在你写的时候就已经想清楚了。但AI给你一段代码，你面对的就是一个黑箱——你得花时间搞清楚它为什么这么写、有没有边界问题、跟你的代码风格是否一致。

这个过程有时候比自己写还费时间。我做了一个粗略统计：平均每次AI生成一段我需要修改的代码，我花在"读懂它为什么这么写"上的时间，大概占整个修改时间的三成。如果加上"确认它没有引入新问题"的时间，这个比例还会更高。

而且还有一个隐性成本：你需要足够的能力来审这段代码。说句不好听的话——如果你写不出这段代码，很可能你也审不出它的问题。这就是所谓的"达克效应"在AI编程时代的新表现。一个 junior 开发者用了 AI 工具之后，表面上产出提高了，但如果他跳过了真正理解的过程，长期来看他的能力并没有增长，反而可能退化。

我自己经历过一段很糟糕的时期：连续用了两个月的Copilot，有一次接手一个紧急需求想关掉AI自己写，结果发现脑子一片空白，写个简单的防抖函数都磕磕绊绊。那一刻我有点慌——AI是不是把我给"惯坏了"？后来我想了一个折中办法：AI生成的代码我不仅要看，还会在关键逻辑旁边手写注释，解释"为什么这么做"。这样既利用了AI的效率，又保留了自己的思考痕迹。

第二个成本：AI的质量真的不稳定

我同时用过Cursor、Copilot和Claude Code，体感上大概六七成的生成结果是能直接用的，剩下三四成需要改。有些改起来很快，但有些你得几乎重写。

我还做过一次更系统的对比。我找了10个常见问题，分别让GPT-4o、Claude 3.5 Sonnet和Gemini 2.5生成解决方案。结果很有趣：同一个问题——实现一个带缓存和重试机制的HTTP请求函数——三个模型的答案大相径庭。GPT-4o的答案最详细（127行），包含了完整的错误处理和日志记录；Claude的最精简（48行），但缺了两个重要的边界条件；Gemini的逻辑是对的，但用了已经废弃的API。

没有一个是完全可以直接投入生产的。

还有一个很多人忽视的问题：AI对"看起来对但实际有bug"的代码有一种天然的"自信"。它不会犹犹豫豫地说"我不确定"，它会非常流畅地给你一个有漏洞的答案。这比一个新手开发者更危险，因为新手至少知道自己可能不懂。

我见过最离谱的一次，AI给我生成的数据库查询有SQL注入漏洞，而且是一个最基本的字符串拼接问题。这要是没仔细看直接合进去了，后果不堪设想。后来我在代码review流程里加了一条：所有AI生成的代码必须标注，review时额外审查安全相关的逻辑。

第三个成本：上下文切换被严重低估

还有一个很容易被忽略的成本：上下文切换。写代码这件事需要进入深度思考状态，每次AI生成一段代码，你就得从"创造模式"切到"审查模式"。

有研究说每次打断之后重新进入心流平均要二十多分钟。一天来来回回切个几次，时间就没了。而且AI编程的上下文切换不是简单的"看一下再回来"——你需要快速在大脑里重新加载业务逻辑、代码框架、之前的决策理由，然后对照AI的输出判断对不对。这种认知负担比你想象的要大得多。

我的做法是这样的：每天上午9点到11点是"纯人工时间"，关掉所有AI辅助，专门处理复杂的核心逻辑。下午用AI辅助来处理重复性工作和代码重构。这样一天下来，深度思考的时间有保障，AI也能发挥它最擅长的部分。

第四个成本：你变得更犹豫了

这一点是我最近才意识到的。在不用AI之前，写代码遇到问题，我会立刻决定一个方向然后动手。但用了一个月的AI之后，我开始犹豫了："AI会不会有更好的写法？""我是不是应该等AI生成然后比较一下？"

这种犹豫在简单任务上特别明显。比如写一个日期格式化的工具函数，不用AI我5分钟就搞定了，用AI的话我会先问AI看看它怎么写的，然后比较自己的和AI的哪个更好，然后又想"如果换个思路呢"——一个5分钟的事愣是拖了20分钟。

这在心理学上有个名字叫"选择悖论"——选项越多，决策越难。AI就是那个不断给你增加选项的东西。

但你说AI没用吗？肯定不是

说了这么多"AI让你变慢"的理由，但不代表AI没有价值。准确地说，AI的价值不在"加速"，而在"转换"——它把你从一种任务转换到另一种任务，至于总体是快了还是慢了，取决于你怎么分配。

我认识一个做电商后端的开发者，他们团队去年引入了Copilot。他跟我说，用了两个月之后，PR数量没变，但线上bug率降了大概两成，代码review的轮次也少了。速度没快，但质量好了。他自己也说不清这算成功还是失败。

另一个独立开发者的体验就不同了。他一个人负责整个产品，前端后端数据库运维全干。他说Cursor帮了大忙，因为AI能理解整个项目的上下文，他描述一个需求，前后端代码一起生成，接口格式还是匹配的。这种场景下效率提升确实明显。但一旦遇到非常规的问题，比如他要实现一个自定义的数据库分片策略，AI生成的代码完全不能用，最后还是自己写。

所以事情就很清楚了：AI能不能让你变快，取决于你在做什么。

标准任务 vs 非标准任务的区别：

理解AI的天花板

说到底，AI代码生成的机制决定了它的天花板。它做的事情本质上是根据上下文预测下一个token——统计学上最可能的代码，不是逻辑上最优的代码。

它不知道你的产品要求微信登录还是邮箱登录，不知道你的安全团队对密码存储有什么特殊规定，不知道你的用户量级需不需要考虑性能。这些只有你自己知道。

而且AI不懂"为什么"。它可以告诉你"这段代码这么写会出错"，但不知道为什么这么写的人会犯错。它能补全你的代码，但补不了你的认知盲区。

我现在的做法

用了三个月之后，我慢慢找到了一套跟AI协作的方式：

第一，简单重复的代码放手让AI写，但生成之后一定会仔细看一遍。 定义是"我闭着眼睛都能写出来但懒得写"的代码，交给AI，但审核标准不降低。

第二，复杂的业务逻辑自己先想清楚，顶多用AI帮我想想有没有遗漏的边界情况。 我会先写好伪代码或思路注释，然后让AI帮我在这个框架下检查和补充。

第三，核心逻辑不依赖AI。 涉及金额计算、权限控制、数据安全的部分，老老实实自己写。不是不信AI，是这份信任不该放在这里。

第四，每天保留一段"无AI时间"。 通常是一个小时左右，用来处理最需要深度思考的问题。这不仅是为了保障代码质量，更是为了保住自己的编程直觉。

Nolan Lawson那篇文章结尾有句话我特别喜欢："也许我们不需要更快地写代码，我们需要更好地写代码。"

写代码这件事，速度从来不是唯一的衡量标准。一段写得好的代码能用三年，一段烂代码三天就可能出bug。AI给了我们一个机会，让我们从"赶紧写完"的节奏里稍微慢下来，去想清楚到底要写什么、怎么写才靠谱。

这不是反AI，这是在用AI的过程中想明白了一件事：工具是工具，脑子还是自己的。