AI 写代码有多厉害？——快了 55%，但错多了 75%
这是 「AI是怎么回事」 系列的第 15 篇。我一直很好奇 AI 到底是怎么工作的，于是花了很长时间去拆这个东西——手机为什么换了发型还能认出你，ChatGPT 回答你的那三秒钟里究竟在算什么，AI 为什么能通过律师考试却会一本正经地撒谎。这个系列就是我的探索笔记，发现了很多有意思的东西，想分享给你。觉得不错的话，欢迎分享+关注。
第一次看到这个系列？从第1篇开始最顺畅，直接读这篇也没问题。
上一篇，我们总结了四条和 AI 协作的原则——让 AI 做它擅长的事、验证大于信任、迭代而非一次到位、用 AI 放大你的优势而非替代你的思考。
文章结尾留了一个悬念：写代码是 AI 最擅长的事之一，但如果 AI 能写代码，那不会编程的人是不是也能”写”代码了？
今天，让我们一起来探索这个问题。
先从一句话说起。
2023 年 1 月，Andrej Karpathy（OpenAI 联合创始人、前 Tesla AI 总监，领导过 Tesla 自动驾驶团队的 AI 开发）在社交媒体上发了一条推文：
“最热门的编程语言是英语。”
这条推文被超过 900 万人看到。两年后的 2025 年 2 月，他又发了一条更具体的推文：
“有一种新的编程方式，我称之为’VibeCoding’（氛围编程）——你完全跟着感觉走，拥抱指数级增长，忘记代码的存在……我就是看看效果、说说想法、跑跑程序、复制粘贴一下，然后它就大概能用了。”
VibeCoding——这个词后来入选了维基百科词条。它描述的是一种全新的编程方式：你不写代码，而是用日常语言（中文或英文）告诉 AI 你想要什么，AI 来生成代码。你甚至不需要看懂代码——看结果就行。
这听起来像科幻。但 Karpathy 描述了自己的真实工作流程：他用语音输入（一款叫 SuperWhisper 的语音工具）跟 AI 说话，连键盘都很少碰。他会说”把侧边栏的内边距减半”这种大白话，因为懒得自己去代码里找具体位置。AI 生成的代码改动？他全部直接接受，连看都不看。遇到报错？把错误信息直接复制给 AI，通常 AI 就能修好。
不过，Karpathy 自己也补了一句：”用来随手做点周末项目还不错。”
他这句轻描淡写的话，其实藏着很深的含义。让我们慢慢拆解。
Part1：为什么 AI 特别擅长写代码
在搞清楚 AI 编程能做到什么之前，先来 理解一个更根本的问题：为什么编程恰好是 AI 最擅长的领域之一？
上一篇我们已经知道，三问判断法三项全满的任务是 AI 的黄金场景。写代码恰好就是。但这一篇我们不只是确认这个结论——我们要展开看：它到底有多满，以及这种”满”本身又会制造什么问题。
先来拆解”满”在哪。
第一，模式极其明确。
编程语言不像人类语言那样模糊。它有严格的语法规则：if 后面必须跟条件，for 后面必须跟循环变量，函数必须有输入和输出。每种编程语言都像一本规则手册，所有代码都在遵循这些规则——形成了极其规整的模式。对于一个”超级模式匹配器”来说，这简直是完美的工作对象。
第二，训练数据极其充足。
互联网上有海量的公开代码。GitHub（全球最大的代码托管平台，开发者把自己的代码存放在上面供他人查看和使用）一个平台就托管了超过 5 亿个代码仓库，超过 1.5 亿开发者在上面协作。Stack Overflow（全球最大的编程问答社区）上有超过 2300 万个编程问答——每一个都是一对”问题-解决方案”的模式。AI 在训练过程中见过的代码模式，比几乎任何其他领域都要丰富。
第三，结果容易验证。
代码能不能跑，一试便知。不像写散文——好坏见仁见智。代码的对错通常是确定性的：要么运行成功，要么报错。这意味着 AI 的输出可以被立刻检验——这正是三问判断法里最关键的 ”可验证”条件。
所以，AI 写代码不是什么”魔法”。它和 AI 识别人脸（第 1 篇）、AI 通过律师考试（第 9 篇）是同一个道理——当模式明确、数据充足、结果可验证时，模式匹配器就能发挥最大威力。 而编程恰好是三个条件全满的黄金场景。
这也解释了为什么 AI 编程工具的增长速度如此惊人——
GitHub Copilot（GitHub 推出的 AI 编程助手，在你写代码时实时给出建议和补全）在 2025 年 7 月突破了1500 万付费用户，超过 77000 家企业和组织都在使用它。Cursor（Karpathy 自己用的那个 AI 代码编辑器，可以直接用自然语言对话来写代码）更是创造了软件行业的增长奇迹——成立仅两年就达到了 3 亿美元的年化收入，成为有史以来达到这个里程碑最快的软件产品之一，到 2025 年底估值达到约 90 亿美元。
数字背后的驱动力，就是三问判断法：编程是 AI 最完美的应用场景之一。
Part2：AI 编程到底能做到什么——一起来看看
光说数据可能还不够直观。让我们来看看 AI 编程在实际中长什么样。
Karpathy 的亲身描述
Karpathy 在他那条著名的推文里详细描述了自己的 VibeCoding 工作流：
他用 Cursor 这个代码编辑器里内置的 AI 助手。他不用打字，而是用语音跟 AI 说话。他会说一些非常随意的话——“把侧边栏的内边距减半””给这个按钮加个悬浮效果”——完全是日常口语，不是编程术语。AI 理解他的意思后，直接修改代码文件。他看都不看修改的内容，直接全部接受。遇到报错，把报错信息复制给 AI，”通常这样就修好了”。
他说：”代码的规模已经超出了我通常理解的范围——如果要仔细读一遍，得花好一会儿。”
换句话说，他在做一个他自己都不完全看懂的程序——但程序跑起来了。
非程序员的真实案例
更令人惊讶的是，这不只是顶级 AI 专家才能做的事。
在菲律宾，一位名叫 Pablo 的女士用 Microsoft PowerApps 的 AI 功能，为自己的社区建了一个资源共享应用。她不是程序员，在农村长大，直到搬到马尼拉才第一次接触电脑。她只是用日常语言描述了她的需求，AI 就帮她生成了可用的程序。
Y Combinator（硅谷最有影响力的创业孵化器）的 CEO Garry Tan 在 2025 年 3 月透露了一个惊人的数字：他们最新一批创业公司中，有四分之一的代码库几乎完全由 AI 生成。而且这些公司的创始人都是技术背景出身——他们选择让 AI 写代码，不是因为自己不会写，而是因为 AI 写得又快又好。
Replit（一个在线编程平台）的 CEO 则分享了另一个数字：他们平台上有大量非程序员用户通过自然语言描述来构建应用——他们只描述想要什么，AI 来实现。
效率数据：到底快了多少？
一项覆盖 4800 名开发者的研究给出了最具体的数字：使用 GitHub Copilot 的开发者完成一个编写 HTTP 服务器的任务，平均用时 1 小时 11 分钟，而未使用的对照组平均用时 2 小时 41 分钟——快了 55%。
GitHub Copilot 现在平均贡献了活跃用户约 46% 的代码——几乎一半的代码是 AI 写的。而且这些代码中 88% 被保留在了最终版本里，说明质量确实达到了可用水平。
埃森哲（全球最大的咨询公司之一）做了一项更严格的随机对照实验：使用 Copilot 的开发者，代码提交量提升了 8.69%，代码合并率提升了 11%，而成功构建次数更是提升了 84%。
这些数字很漂亮。
但如果故事在这里结束，它就不完整了。
Part3：模式匹配器写代码，会遇到什么问题
Part2 里我们看到了标题的前半句——“快了 55%”。现在来看后半句——「错多了 75%」。
记得 Karpathy 说的那句”用来随手做点周末项目还不错”吗？这句话暗示了一个重要的分界线。
让我们来看看，当 AI 编程从”周末小项目”走向真实世界时，会发生什么。好在这方面已经有了大量公开的研究数据，我们不需要猜测。
问题一：表面能跑，逻辑有错
CodeRabbit（一个 AI 代码审查平台）在 2025 年 12 月发布了一份《AI 与人类代码生成现状报告》，分析了 470 个开源项目的代码提交。结果发现：
- AI 生成的代码平均包含的问题数量是人类代码的 1.7 倍
- 「逻辑和正确性错误高出 75%」——算法错误和业务逻辑错误的出现频率是人类的 2 倍多
- 关键级别的问题多了 1.4 倍，主要级别的问题多了 1.7 倍
- 过度 I/O 操作（输入输出，即程序读写数据的操作）的问题更是高出近 8 倍
这意味着什么？AI 写的代码经常”看起来能跑”，但内在逻辑有问题。
为什么会这样？用第 9 篇的知识来解释：AI 是在”续写代码”，不是在”理解你要什么”。 它从训练数据中匹配最常见的代码模式，然后输出——但”最常见的模式”不等于”在你的具体场景中最正确的做法”。
举个例子：如果你让 AI 做一个记账工具，需要把金额加在一起，AI 很可能用”浮点数”（计算机中表示小数的常见方式）来做加法。在大多数场景下这没问题。但处理金额时，浮点数会有精度误差——15.1+30.2 在计算机里可能等于 45.300000000000004，而不是精确的 45.3。任何有经验的程序员都知道，处理金额应该用整数（以”分”为单位计算）。AI 不知道这个区别，因为它不”理解”你在做记账工具——它只匹配”数字相加”的最常见写法。
代码能跑，不代表代码正确。这是 AI 编程最隐蔽的陷阱。
问题二：不理解你的业务需求
Qodo（一家 AI 代码质量平台）在 2025 年对超过 600 名开发者进行了《AI 代码质量现状调查》。结果很说明问题：
- 78% 的开发者认为 AI 提高了他们的工作效率
- 但 65% 的开发者说 AI 最大的问题是”缺失上下文”——AI 不知道你的项目全貌，不理解你的业务规则
这个”缺失上下文”具体长什么样？Qodo 的报告指出，在代码重构、测试生成和代码审查这些关键任务中，约 60-65% 的开发者都遇到过 AI 因为缺少上下文而犯错的情况。有趣的是，上下文缺失被开发者认为比 AI”幻觉”（编造不存在的东西）还要严重——因为幻觉容易发现（代码直接报错），而上下文缺失导致的错误往往隐藏很深（代码能跑，但做的不是你想要的）。
用第 7 篇和第 9 篇的知识来解释：AI 在”续写”代码时，依据的是训练数据中的统计模式，而不是对你业务的理解。它不知道你的用户是谁，不知道你的产品逻辑，不知道哪些边界情况需要特殊处理——因为这些信息不在训练数据里，甚至可能不在你给它的对话上下文里。
问题三：项目大了，AI 就”迷路”了
还记得第 6 篇讲的”上下文窗口”吗？这是 AI 一次能”看到”的信息长度限制。
当一个项目只有几个文件、几百行代码时，AI 可以”看到”全貌，表现很好。但当项目增长到几十个文件、几万行代码时——这在真实的软件开发中非常常见——AI 就开始出现一种特有的错误：前后矛盾。
比如，它在 A 文件里把日期格式定义为”2025-01-15”，但在 B 文件的统计功能里用了”01/15/2025”。两边不一致，程序就出了问题。因为修改 B 文件时，A 文件可能已经超出了 AI 的上下文窗口——对 AI 来说，窗口之外的内容就像不存在一样。
这和人类记忆力有限是一个道理——只不过 AI 的”记忆”不是真正的记忆，而是当前对话窗口里的文字。窗口装不下的，它就顾不上了。
最有趣的一个实验
以上三个问题叠加在一起，会产生什么效果？还记得 Part2 里那个”快了 55%”吗？接下来这个实验的结论可能会让你大吃一惊。
2025 年 7 月，METR（一家 AI 安全研究机构）发布了一项严格的随机对照实验，给出了一个出人意料的答案。
他们找了 16 名经验丰富的开源开发者——这些人平均在自己的项目上工作了 5 年——随机决定每个任务是否允许使用 AI 工具。246 个任务做下来，结果是：
使用 AI 工具的开发者反而慢了 19%。
更有趣的是感知和现实的差距：开发者在做任务之前预估 AI 会让他们 快 24%；做完任务之后，他们仍然觉得 AI 让自己快了 20%。但实际测量的结果是——慢了 19%。
自己觉得快了 20%，实际慢了 19%。
为什么？因为在大型真实项目中，AI 生成的代码需要大量的检查、调试和修改。这些隐性成本抵消了（甚至超过了）AI 带来的速度提升。但因为”敲代码”这个动作本身确实变快了，开发者产生了”我变快了”的错觉。
研究中一位开发者的反馈很说明问题：”AI 在代码的其他部分做了一些奇怪的修改，我花了不少时间去找到并撤销这些改动。”
把三个问题串起来
让我用一张表来总结，注意每个问题的根源都可以追溯到我们前面章节的知识：
| 问题 | 表现 | 根源（回溯前文） |
|---|---|---|
| 表面能跑，逻辑有错 | AI 代码逻辑错误高出 75% | AI 匹配最常见的代码模式，不理解具体业务语境（第 9 篇：模式匹配 vs 理解） |
| 不理解业务需求 | 65% 开发者反映 AI 缺失上下文 | AI 在”续写”代码，没有你的业务全局视角（第 7 篇：续写 vs 回忆） |
| 项目大了前后矛盾 | 大型项目中 AI 反而拖慢 19% | 超出上下文窗口，AI 无法”看到”全部信息（第 6 篇：上下文窗口的限制） |
这三个问题不是意外。它们是”超级模式匹配器”的必然局限——当匹配所需的信息超出了训练模式或上下文窗口，AI 就开始出错。
这也和 Karpathy 的话完美呼应：VibeCoding 适合”周末小项目”—— 因为小项目模式简单、需求明确、代码量小，恰好在 AI 的能力范围之内。一旦项目变大、需求变复杂，AI 的局限就暴露了。
Part4：正确的姿势——AI 编程适合做什么
知道了 AI 编程的优势和局限后，正确的使用方式就清晰了。这和第 14 篇的四条原则完全一致——不是巧合，而是因为底层逻辑相同。
适合交给 AI 的
原型开发和快速验证。 你有一个想法，不确定可不可行？让 AI 先做一个粗糙版本出来，看看效果。业界的经验显示，使用 AI 后，原型开发时间可以缩短 50% 到 70%。这就是 Karpathy 说的”周末项目”——快速试验一个想法，不需要完美，能跑就行。
学习新语言和新框架。 你可以告诉 AI”用 JavaScript 实现这个功能”，然后对照 AI 生成的代码来学习。比翻文档快得多——因为 AI 给你的是一个可运行的具体例子，不是抽象的语法说明。
写重复性的样板代码。 编程中有大量高度固定的模式：数据库连接、接口定义、配置文件。这些是模式匹配的完美场景——模式极其明确，训练数据极其丰富。让 AI 来写，你来检查。
修 bug 和理解报错。 遇到一个看不懂的报错信息？丢给 AI。报错信息在训练数据中大量出现，AI 见过无数”错误-原因-解法”的模式对，这是典型的模式匹配强项。
仍然需要人做的
架构设计。 “这个应用应该分成几个模块？数据怎么流动？用什么技术方案？”——这些需要理解整个项目的目标、约束和取舍。没有两个项目的架构是完全相同的，模式匹配在这里力不从心。
业务逻辑判断。 “修改了旧数据后要不要重新触发校验？””用户删除账号后历史数据保留多久？”——这些不是代码问题，是业务问题。AI 不知道你的用户是谁、他们怎么使用产品、什么行为对他们来说是合理的。
代码审查。 AI 写的每一行代码，都需要有人审查。CodeRabbit 报告显示，AI 代码中的安全漏洞数量是人类代码的 1.5 倍。Qodo 的调查显示，只有 3.8% 的开发者对 AI 代码有足够信心直接发布——96.2% 的人认为仍然需要人类审查。
性能优化。 让代码”能跑”容易，让代码”跑得快”则需要理解计算机底层的工作方式。CodeRabbit 的数据最直观：AI 代码中过度 I/O 操作的问题是人类代码的近 8 倍——AI 倾向于用最简单直白的方式写代码，而不是最高效的方式。
分界线在哪？就是三问判断法。 模式明确、数据充足、可验证的部分交给 AI；需要理解具体场景、做独特判断的部分，你来。
读者可能会问的两个问题
“程序员会不会失业？”
这个问题几乎每个人都在问。我查了大量数据，给你一个尽可能完整的回答。
先看长期趋势：整体需求在增长。
美国劳工统计局（BLS）预测，软件开发岗位到 2033 年将增长约 17%，远超所有职业平均 4% 的增长率。BLS 的分析逻辑是：AI 确实提高了程序员的生产力，但更高的生产力会降低软件的开发成本，进而刺激更多的软件需求——总体效果是需要更多而不是更少的开发者。而且 AI 系统本身也需要大量的开发者来构建和维护。
摩根士丹利的分析与此一致：AI 不会减少软件行业的整体就业，而是会重新定义开发者的角色——从”写代码”转向”设计系统和管理 AI 工具”。
但短期有一个值得关注的信号：入门级岗位在收缩。
斯坦福数字经济实验室的研究发现，自 2022 年 AI 工具普及以来，30 岁以下年轻程序员的就业率下降了约 6%；而 30 岁以上程序员的就业反而增长了 6-13%。Signal Fire 的报告显示，15 家最大科技公司的入门级招聘从 2023 到 2024 年下降了约 25%。
这意味着什么？不是程序员变少了，而是”只会写代码”的岗位在减少，”能驾驭 AI”的岗位在增加。 AI 替代的是”敲代码”这个动作，不是”解决问题”这个能力。
历史给了我们一个有用的类比。
1980 年代，电子表格软件（如 Excel）普及后，很多人预言会计职业将会消亡。确实有大量簿记员的工作岗位消失了——手工记账这个具体动作被自动化了。但会计行业不仅没有萎缩，反而大幅增长，因为电子表格让财务分析变得更快更便宜，企业对财务分析的需求因此暴涨。会计师的工作从”算数”转向了”分析和决策”——更有价值、也更难被机器替代。
AI 编程工具和电子表格是同一个故事的新版本。它消灭的是”手敲代码语法”这个动作，但让”设计系统””判断质量””理解需求”变得更加重要。
“我该不该学编程？”
如果你之前因为”语法太难记”而对编程望而却步，AI 时代的好消息是：语法门槛确实大幅降低了。
Karpathy 自己说过：VibeCoding 让”编程不再是经过严格训练的专业人士的专属——而是任何人都能做的事”。
但这里有一个关键的转变。当 AI 处理了语法层面的事情后，编程真正的难点反而暴露出来了——逻辑思考。
想清楚一个工具应该怎么工作、考虑到用户可能遇到的各种情况、决定不同功能之间怎么配合、在”做得更完善”和”差不多就行”之间做取舍——这些是编程真正的核心能力，也是 AI 帮不了你的部分。
所以，如果你想学编程，AI 时代的建议是：重点从”记语法”转向”练逻辑”。 你不需要背诵 for 循环的写法——AI 会替你写。但”这个循环为什么要跑 10 次而不是 20 次””这里应该用什么数据结构””这两个功能之间的依赖关系是什么”——这些判断需要你自己来做。
AI 降低了编程的入口，但没有降低编程的天花板。入门更容易了，但要做好，仍然需要深入的思考能力。
个人锚点
如果你也试过让 AI 写代码，你可能会注意到一件事：当你清楚知道自己要什么时，AI 表现惊人；当你自己都没想清楚时，AI 给出的东西怎么改都不对。
这背后的道理，和我们整个系列一直在探索的核心发现一致：模式匹配的部分可以被自动化，需要理解的部分永远需要人。
代码语法是模式，可以被自动化。但”这个产品应该解决什么问题””这个功能的边界在哪里””这段代码的逻辑对不对”——这些是理解，需要人来做。
如果你再仔细想想， 会发现这不只是编程的事。翻译如此，写作如此，几乎所有 AI 擅长的领域都如此。AI 自动化掉的永远是那个”模式匹配”的部分，而暴露出来的永远是那个”真正需要人的思考”的部分。
编程的本质不是写语法，而是想清楚要做什么。 这可能是 AI 编程给我们最大的启示。
一句话回顾
AI 让写代码快了 55%，但逻辑错误也多了 75%。模式匹配的部分被自动化了，需要理解的部分永远需要人——AI 降低的是编程门槛，不变的是对逻辑的思考。
下一篇预告
从第 1 篇”你的手机是怎么认出你的脸”到现在，我们走了很长一段路。拆开了 AI 的黑箱，画出了它的能力边界，学会了怎么和它一起工作，还一起看了它在编程这个最擅长的领域里的表现和局限。
最后一个问题，也是最大的一个问题——
AI 会取代我们吗？
下一篇，也是这个系列的最后一篇，让我们一起认真聊聊这个问题。答案可能会出乎你的意料。
参考资料
- Karpathy, A. (2023). “The hottest new programming language is English.” X (Twitter). https://x.com/karpathy/status/1617979122625712128
- Karpathy, A. (2025). “There’s a new kind of coding I call ‘vibe coding’…” X (Twitter). https://x.com/karpathy/status/1886192184808149383
- Wikipedia. Vibe coding. https://en.wikipedia.org/wiki/Vibe_coding
- Electroiq. (2025). GitHub Statistics And Facts, By Users, Security And Repos. https://electroiq.com/stats/github-statistics/
- Quantumrun Foresight. (2026). GitHub Copilot Statistics 2026. https://www.quantumrun.com/consulting/github-copilot-statistics/
- About Chromebooks. (2026). GitHub Copilot Statistics [2026]. https://www.aboutchromebooks.com/github-copilot-statistics/
- Sacra. (2025). Cursor Revenue, Valuation & Funding. https://sacra.com/c/cursor/
- Cursor. (2025). Series D Announcement. https://cursor.com/blog/series-d
- Peng, S., et al. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv. https://arxiv.org/abs/2302.06590
- Panto. (2026). GitHub Copilot Statistics 2026: Productivity, Risk & Impact. https://www.getpanto.ai/blog/github-copilot-statistics
- Microsoft Source. (2025). Vibe coding and other ways AI is changing who can build apps and how. https://news.microsoft.com/source/features/ai/vibe-coding-and-other-ways-ai-is-changing-who-can-build-apps-and-how/
- TechCrunch. (2025). A quarter of startups in YC’s current cohort have codebases that are almost entirely AI-generated. https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
- Glance. (2025). Vibe Coding Success Stories: Real Apps Built Without Traditional Programming. https://thisisglance.com/blog/vibe-coding-success-stories-real-apps-built-without-traditional-programming
- CodeRabbit. (2025). State of AI vs Human Code Generation Report. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
- Qodo. (2025). State of AI Code Quality in 2025. https://www.qodo.ai/reports/state-of-ai-code-quality/
- METR. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- U.S. Bureau of Labor Statistics. (2025). AI impacts in BLS employment projections. https://www.bls.gov/opub/ted/2025/ai-impacts-in-bls-employment-projections.htm
- Morgan Stanley. (2025). AI in Software Development: Creating Jobs and Redefining Roles. https://www.morganstanley.com/insights/articles/ai-software-development-industry-growth
- IEEE Spectrum. (2025). AI Shifts Expectations for Entry Level Jobs. https://spectrum.ieee.org/ai-effect-entry-level-jobs
- FloQast. (2025). Will Robots Take Our Jobs if Accounting is Automated? https://www.floqast.com/blog/will-robots-take-our-jobs-if-accounting-is-automated
- Opsera. (2025). Cursor AI Adoption Trends: Real Data from the Fastest Growing Coding Tool. https://opsera.ai/blog/cursor-ai-adoption-trends-real-data-from-the-fastest-growing-coding-tool/