# AI 真的让程序员更快了吗

> 一篇带着数据去挖的调查。结论只有一句话：**AI 到底让你快还是慢，取决于"你是谁、在哪写代码"——而绝大多数人恰恰错估了自己所处的那一格。** 更麻烦的是，你的"感觉"在这件事上系统性地不可靠。
>
> 本文所有关键数字都标了来源、样本和证据等级。我把证据分成四级，请边读边留意：**随机对照实验（RCT）> 大样本准实验/观察性研究 > 厂商代码扫描报告 > 问卷/自报数据**。等级越低，越可能掺了利益和错觉。

---

## 0. 一个让所有人不舒服的实验

2025 年 7 月 10 日，一家叫 METR（Model Evaluation and Threat Research）的非营利机构发了一篇论文，标题很朴素：《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》。

它做了一件别人很少做的事：**真正的随机对照实验**。

16 名资深开源开发者，在他们自己维护的、平均有 5 年经验的大型成熟项目上（平均 2.2 万+ stars、百万行量级代码），领取 246 个真实的 issue 和功能开发任务。每个任务被**随机**指派为"允许用 AI"或"禁止用 AI"——工具主要是 Cursor Pro 配 Claude 3.5/3.7 Sonnet，正是 2025 年上半年最好的组合。然后 METR 精确测量了每个任务的实际完成时间。

三个数字，构成了这篇调查的核心张力：

- 开工前，开发者预测 AI 会让他们**快 24%**。
- 干完后，开发者主观感觉 AI 让他们**快了 20%**。
- 而实际测量结果是：用 AI 的任务，完成时间**多了 19%**。

> "Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%... After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%—AI tooling slowed developers down."
> —— METR, arXiv:2507.09089

慢了 19%，但从头到尾都以为自己快了 20%。这不是估计偏差，这是**方向都搞反了**。资深工程师——那些自认为对自己效率最有判断力的人——集体、稳定地、错得离谱地感知了一件他们亲身经历的事。

这就是全文要挖的东西。不是"AI 有没有用"这种蠢问题，而是：**为什么"感觉更快"和"实际更快"能差出一个正负号？这个鸿沟在什么条件下出现、什么条件下消失？**

（先把严谨性交代清楚：METR 那个 19% 的 95% 置信区间是 +2% 到 +39%，即"变慢"这个方向本身是稳的，但幅度不精确。更重要的一件事放在第 4 节讲——METR 自己在半年后修正了这个数字。先按下不表，但请记住它。）

---

## 1. 先看看"卖 AI 的人"是怎么说的

要理解 19% 的冲击力，得先看看它对撞的是什么叙事。

厂商的叙事非常响亮。最常被引用的是 GitHub 官方 2022 年的研究：用了 Copilot 的开发者完成任务"快 55%"。

> "developers who used GitHub Copilot completed the task significantly faster—55% faster than the developers who didn't use GitHub Copilot."
> —— GitHub Blog / arXiv:2302.06590

这个数字本身没造假——它内层确实是个 RCT（95 名程序员随机分组）。但它有三个几乎从不被一起提及的前提：

1. **任务是"用 JavaScript 从零写一个 HTTP 服务器"**——一个干净、独立、有标准答案的玩具任务，跟"在百万行遗留代码里改 bug"是两个物种。媒体常把它贴上"样板代码"标签，但论文全文根本没出现 boilerplate 这个词。
2. **"快 55%"不是"省 55% 时间"。**"快 55%"约等于"耗时减少 35%"（71 分钟 vs 161 分钟）。这是个被反复误传的算术。
3. **置信区间是 21%–89%**——宽得能开卡车。且这是 GitHub 在自家博客上宣传自家产品，非同行评审。

一个独立第三方 Uplevel 用近 800 名开发者的**客观**指标（而非人造任务）去测，结论几乎相反：PR 吞吐量没改善，引入的 bug 反而多了约 41%。

所以第一条规律浮出来了：**AI 的效率增益，高度依赖任务的"干净程度"。任务越接近"孤立、有标准答案、你不熟"的一端，AI 越神；越接近"耦合、无标准答案、你很熟"的一端，AI 越可能帮倒忙。** METR 测的恰恰是后一端，GitHub 测的恰恰是前一端。它们不矛盾，它们在描述同一根光谱的两头。

---

## 2. 那份最诚实的行业报告：Google DORA 的"放大器"结论

如果说 METR 是显微镜（16 人、精确计时），Google 的 DORA 报告就是广角镜（每年近 5000 名从业者的问卷）。证据等级低一档（自报问卷、相关非因果），但胜在规模和连续性。它的发现值得原样引用，因为它自己就在"打自己脸"地修正：

- **2024 年报告**：AI 采用率每上升 25%，交付吞吐量下降约 1.5%、稳定性下降约 7.2%。这是"AI 拖累交付"最硬的行业级证据。
- **2025 年报告**：吞吐量"由负转正"了，但稳定性问题**依然没解决**。原文措辞很不留情面：

> "AI adoption not only fails to fix instability, it is currently associated with increasing instability... AI's primary role is as an amplifier. AI does not automatically improve software delivery performance."
> —— DORA / State of DevOps 2025

**AI 是个放大器，不是加速器。** 团队底子好，它放大你的好；团队底子烂，它放大你的烂。这句话比任何单一百分比都更接近真相。（提醒：报道里若笼统说"DORA 证明 AI 拖累交付"，只符合 2024 版，2025 版吞吐量已转正——这种选择性引用正是这个领域的通病。）

---

## 3. 缺失的一环：为什么"感觉"会骗人

现在回到核心谜题。METR 的开发者慢了 19% 却感觉快了 20%。为什么？

METR 没直接回答，但把几个碎片拼起来，机制相当清楚：

**AI 把"苦"的部分变"爽"了，但没把"慢"的部分变快。** 盯着空白编辑器苦思、翻文档、敲重复代码——这些是主观上"累且慢"的时刻。AI 一键补全，这些时刻消失了，体感极爽。但代价转移到了别处：**读懂 AI 生成的一大段代码、判断它对不对、调试它似是而非的错误、把它跟既有架构缝合。** 这些新增的认知负担，恰恰不容易被感知为"我在花时间"——你在审查，不在"干等"，所以大脑不把它计入成本。

Stack Overflow 2025 年开发者调查（4.9 万人问卷，证据等级：自报）给了这个机制一个精确的注脚。开发者最大的挫败点是什么？

> "AI solutions that are almost right, but not quite" —— 66% 的开发者认同这是首要痛点。

"几乎对，但不完全对"——这是 AI 代码最阴险的地方。**完全错的代码你一眼扔掉，成本低；几乎对的代码骗你接受，然后在下游让你付出 debug 的代价，而这个代价你不会归因给 AI。** 同一份调查里，46% 的开发者**主动不信任** AI 输出的准确性，高于信任的 33%；对 AI 的整体好感度从 2023 年的 70%+ 一路降到 2025 年的约 60%。使用率在涨（84% 在用或计划用），信任度在跌——这个剪刀差本身就说明：**用得越多，越看清它的毛病。**

所以"感觉快 20%"不是错觉那么简单，而是**成本被系统性地记错了账**：省下的时间被高估（因为它爽），新增的审查/调试/返工时间被漏记（因为它不像"等待"）。

---

## 4. 但是——别急着站队：METR 自己推翻了一半

一篇诚实的调查，必须正面处理反对自己核心论点的证据。这里有三个，我不打算和稀泥，而是逐个称重。

**反证一（最重的）：METR 自己在 2026 年 2 月做了修正。** 换了实验设计、扩大到更大队列后，那个 -19% 的减速缩小到了约 -4%，置信区间 -15% 到 +9%——**跨过了 0，不再显著**。METR 坦承原实验有严重的选择偏差：越来越多的重度 AI 用户干脆拒绝参加"禁用 AI"的对照组，还有 30%–50% 的开发者承认会故意不提交某些任务，"因为不想在没有 AI 的情况下做"。

> "30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI."
> —— METR, 2026-02 更新

这意味着什么？意味着**"19% 变慢"不该被当成一个稳定的普适结论刻在墙上。** 任何拿它去证明"AI 没用"的人,都是在选择性引用。但反过来——那个把 19% 缩小到 4% 的机制本身也极有说服力：开发者对 AI 已经**上瘾到不愿意在没有它的情况下工作**。工具是否让你更快，和你是否离不开它，是两码事。第二件事，2025 到 2026 年间答案已经是响亮的"离不开"。

**反证二：这个结果作者自己说了不能外推。** METR 白纸黑字划了边界：结论**不适用于**"经验较浅的开发者，或在不熟悉代码库中工作的开发者"。它只描述了一个非常具体的情境：资深维护者 + 他们烂熟于心的大型成熟代码库 + 2025 上半年的工具。这恰恰是 AI 最难帮上忙的角落——代码库的上下文已经全在这个人脑子里了，AI 要追平这个上下文的成本，可能比它节省的还高。

**反证三（决定性地补全了光谱的另一端）：换一群人，结论直接反过来。** 一项发表于 *Management Science*（2026）的大规模田野实验，合并了微软、埃森哲和一家财富 100 公司的三个真实 RCT，**共 4867 名开发者**，随机发放 Copilot 权限。结果：

> "a 26.08% increase in completed tasks among developers using the AI tool... less experienced developers had higher adoption rates and greater productivity gains."
> —— Cui, Demirer et al., Management Science 2026

任务完成量**提升 26%**，而且**经验越浅的开发者获益越大**。这和 2023 年 GitHub 那篇 RCT 的异质性分析完全一致——"经验较少的程序员从 Copilot 获益最多"。

两个方向相反的 RCT，不是互相打脸，而是**共同拼出了那根光谱**：

| | METR（慢 19%→4%） | Management Science（快 26%） |
|---|---|---|
| 开发者 | 资深、5 年项目经验 | 混合，**新手占比高且获益最大** |
| 代码库 | 极熟悉的成熟大项目 | 企业日常任务，多样 |
| 上下文 | 已在脑中，AI 难追平 | AI 补足了缺失的知识 |
| 净效果 | 拖慢或持平 | 显著加速 |

**结论跟着证据走：AI 编程工具的价值，与"开发者已有上下文的多少"成反比。** 你越是新手、越是在陌生的领域、越是缺少那份藏在老工程师脑子里的隐性知识，AI 补的窟窿就越大，你就越快。你越是专家、越是在自己盖了十年的房子里，AI 能补的窟窿越小，而它带来的审查负担却是固定成本——于是净值可能为负。

这也顺带解释了一件反直觉的事：**最有资格评价 AI 工具的资深工程师，恰恰是最容易被它拖慢、又最容易高估它的那群人。** METR 的鸿沟不是巧合。

---

## 5. 代价被记在了别的账本上：质量与安全

就算 AI 让某些人写得更快，"更快"如果意味着"更烂"，那也只是把成本推迟到未来。这部分的证据最脏——**警示性大数字压倒性地来自有商业动机的厂商**，得格外小心地称重。

**代码 churn / 重复率——一个被夸大后又被反证的故事。** 卖代码分析软件的 GitClear 有个流传极广的结论："AI 让代码 churn（写完两周内就被推翻的代码）在 2024 年翻倍"。但翻开原文：那个"翻倍"是用**仅仅两个数据点**做二次回归外推出的**预测值**，报告自己都承认"两个点的二次回归会有很大误差"。等 2024 年真实数据出来，churn 只到 5.67%（同比 +26%），远没到预测的 7.1%。真实观察到的现象要温和得多：复制粘贴的代码行数首次超过了移动的代码行数，5 行以上的重复代码块频率上升。方向可能对，但那个"翻倍"的爆炸数字站不住。

更要命的是**同行评审的研究给出了相反结论**。一篇分析真实仓库的研究（arXiv:2603.27130，预印本）发现："人类写的代码重复率反而显著高于 AI 生成代码"（重复行 25.89% vs 18.69%）。另一篇（arXiv:2507.10422）用"仓库明确声明用了 GenAI"这个更干净的信号去测，看到的是 churn **随时间下降**。所以老实说：**"AI 让代码更臃肿"目前是一个有争议的叙事，而非定论。** 谁要拍胸脯下结论，都是在替厂商带货。

**安全漏洞——这里的证据反而更硬，也更值得警惕。** 三项互相独立、方法各异的研究收敛到了同一个量级：

- **Stanford（CCS 2023，同行评审）**：用 AI 助手的参与者"写出的代码明显更不安全"，且更倾向于**误以为**自己的代码是安全的。又一次，感知与现实的鸿沟。
- **NYU（IEEE S&P 2022，同行评审）**：让 Copilot 在 89 个安全敏感场景生成 1689 个程序，约 **40% 含漏洞**。注意前提——这是**专门设计来诱发漏洞**的高风险场景，不等于日常代码 40% 不安全。
- **Veracode（2025，厂商扫描，规模最大、方法公开）**："只有 55% 的生成任务产出安全代码，也就是 45% 引入了已知漏洞"，且"更新更大的模型并没有显著更安全"。

> "in 45% of the tasks the model introduces a known security flaw... newer and larger models do not generate significantly more secure code."
> —— Veracode 2025 GenAI Code Security Report

把这三条和第 3 节的机制拼起来，一条完整的因果链就成型了：**AI 让写代码变爽 → 人倾向于接受"几乎对"的代码 → 审查负担被系统性低估 → 漏洞和技术债被记在了未来的账本上。** DORA 的"稳定性下降 7.2%"、Faros 报告里"31.3% 的 PR 无人审查就合并了"，都是同一条链在下游的显影。（顺带纠一个常见误引：网上流传的"Snyk 发现 40% AI 代码不安全"查无一手出处，建议弃用。）

---

## 6. 所以，什么时候该用，什么时候该关掉它自己写

这篇调查是写给重度 AI 用户看的，那就得给出能落地的判断，而不是"看情况"。把上面的证据压成一张决策表——**核心变量只有两个：你对这块代码的上下文有多熟，以及这个任务有多"干净"（独立、可验证、有标准答案）。**

**放手让 AI 写（它大概率真的让你更快）：**
- 你**不熟**的语言、框架、API——AI 补的是你缺的上下文，这正是它最大增益区（新手获益最大的 RCT 证据在此）。
- 样板代码、脚手架、配置、正则、一次性脚本——干净、独立、你一眼能验证对错。
- 跨语言翻译一段逻辑、把伪代码变成能跑的代码。
- **前提永远是：产出你能一眼看懂、并且验证成本远低于自己写的成本。**

**该关掉它、自己写（否则大概率被拖慢或埋雷）：**
- 你**烂熟于心**的复杂大代码库里的核心改动——上下文已在你脑中，AI 追平它的成本高于收益（这就是 METR 那 19% 的来源）。
- 需要深度业务上下文、跨多个模块的耦合改动——AI 给你"几乎对"的东西，缝合和调试的隐性成本会吃掉一切。
- 安全敏感代码（认证、加密、输入处理、权限）——三项研究一致警告，且你还会**高估**它的安全性。这类代码，AI 可以当你的 rubber duck，但不该当你的手。
- 你的目的是**学会**这块知识而不只是完成它——有 RCT 显示，把代码生成外包给 AI 的学习者，概念测验分数低了约 17%（相当于两个等级）。爽和学会，往往负相关。

最后，一条元规则，也是这篇调查最想让你带走的东西：

> **每次用完 AI，问自己一句："我刚才是真的快了，还是只是没那么难受？"** METR 那 16 个人栽的跟头，就是把"不难受"错记成了"快"。你的体感在这件事上是不可靠的仪表——真正靠得住的，是你敢不敢诚实地看时钟。

---

## 附录：证据分级清单（从强到弱）

写作时对每个数字的称重依据。等级越靠前，越该信；越靠后，越该带前提引用。

**A 级 · 随机对照实验（RCT，因果金标准）**
1. METR《Measuring the Impact of Early-2025 AI...》(2025-07)｜16 人/246 任务｜实测慢 19%（后续修正至约 -4%、不显著）｜https://arxiv.org/abs/2507.09089 ｜后续更新 https://metr.org/blog/2026-02-24-uplift-update/
2. Cui, Demirer et al.，*Management Science*(2026)｜三个企业 RCT 合并 4867 人｜任务完成量 +26%，新手获益最大｜https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566
3. Peng, Kalliamvakou et al.(2023)｜95 人｜写 HTTP server 快 55.8%（CI 21–89%），新手获益最多｜https://arxiv.org/abs/2302.06590
4. Perry et al.（Stanford, CCS 2023）｜47 人｜用 AI 者写的代码明显更不安全，且误以为更安全｜https://arxiv.org/abs/2211.03622
5. Anthropic《AI assistance and coding skills》(2026)｜52 人｜外包代码生成的学习者概念测验低约 17%｜https://www.anthropic.com/research/AI-assistance-coding-skills

**B 级 · 大样本准实验 / 观察性研究**
6. Pearce et al.（NYU, IEEE S&P 2022）｜1689 个程序｜安全敏感场景约 40% 含漏洞｜https://arxiv.org/abs/2108.09293
7. Wu et al.（FSE 2025，同行评审）｜商业 AI 代码生成器克隆率最高 7.5%｜https://dl.acm.org/doi/10.1145/3729397
8. arXiv:2603.27130 (2026, 预印本)｜真实仓库中 AI 代码重复率反而低于人类（18.69% vs 25.89%）｜反证
9. Faros AI Engineering Report 2026｜2.2 万开发者遥测｜审查时间中位数增 5 倍、31.3% PR 无审查合并（含 AI 审查干扰，单一厂商）

**C 级 · 厂商代码扫描报告**
10. Veracode 2025 GenAI Code Security Report｜80 任务 ×100+ 模型｜45% 引入已知漏洞｜https://www.veracode.com/wp-content/uploads/2025_GenAI_Code_Security_Report_Final.pdf
11. Georgetown CSET(2024-11)｜形式化验证｜约 48% 代码片段含影响性 bug｜https://cset.georgetown.edu/publication/cybersecurity-risks-of-ai-generated-code/
12. GitClear AI Code Quality(2024/2025)｜1.5–2.1 亿行代码｜churn/复制粘贴上升（"翻倍"为 2 点外推预测，实测更温和）｜https://www.gitclear.com/ai_assistant_code_quality_2025_research

**D 级 · 问卷 / 自报数据（测感知与行为，不测效率或漏洞率）**
13. Google DORA / State of DevOps(2024/2025)｜近 5000 人｜2024 稳定性 -7.2%，2025 吞吐转正、稳定性仍降｜https://dora.dev/research/2024/dora-report/
14. GitHub《Quantifying Copilot's impact》(2022)｜"快 55%"，厂商自报，非同行评审｜https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
15. Stack Overflow Developer Survey 2025｜4.9 万人｜信任 33% < 不信任 46%，好感度降至约 60%，66% 苦于"几乎对"的代码｜https://survey.stackoverflow.co/2025/ai/

*注：所有数字均由联网检索一手来源（arXiv 摘要、官方 PDF、报告页）逐字核对。方法、样本、置信区间与各研究自陈的局限性已在正文对应处标注。凡"翻倍""40% 不安全""5 倍审查"等易被误引的数字，均已还原其前提或标注争议。*