AI 真的让程序员更快了吗
一篇带着数据去挖的调查。结论只有一句话：AI 到底让你快还是慢，取决于"你是谁、在哪写代码"——而绝大多数人恰恰错估了自己所处的那一格。 更麻烦的是，你的"感觉"在这件事上系统性地不可靠。<br><br>本文所有关键数字都标了来源、样本和证据等级。我把证据分成四级，请边读边留意：随机对照实验（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."<br>—— 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."<br>—— GitHub Blog / arXiv:2302.06590
这个数字本身没造假——它内层确实是个 RCT（95 名程序员随机分组）。但它有三个几乎从不被一起提及的前提：
- 任务是"用 JavaScript 从零写一个 HTTP 服务器"——一个干净、独立、有标准答案的玩具任务，跟"在百万行遗留代码里改 bug"是两个物种。媒体常把它贴上"样板代码"标签，但论文全文根本没出现 boilerplate 这个词。
- "快 55%"不是"省 55% 时间"。"快 55%"约等于"耗时减少 35%"（71 分钟 vs 161 分钟）。这是个被反复误传的算术。
- 置信区间是 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."<br>—— 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."<br>—— 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."<br>—— 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."<br>—— 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，因果金标准）
- 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/
- Cui, Demirer et al.，Management Science(2026)｜三个企业 RCT 合并 4867 人｜任务完成量 +26%，新手获益最大｜https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566
- Peng, Kalliamvakou et al.(2023)｜95 人｜写 HTTP server 快 55.8%（CI 21–89%），新手获益最多｜https://arxiv.org/abs/2302.06590
- Perry et al.（Stanford, CCS 2023）｜47 人｜用 AI 者写的代码明显更不安全，且误以为更安全｜https://arxiv.org/abs/2211.03622
- Anthropic《AI assistance and coding skills》(2026)｜52 人｜外包代码生成的学习者概念测验低约 17%｜https://www.anthropic.com/research/AI-assistance-coding-skills
B 级 · 大样本准实验 / 观察性研究
- Pearce et al.（NYU, IEEE S&P 2022）｜1689 个程序｜安全敏感场景约 40% 含漏洞｜https://arxiv.org/abs/2108.09293
- Wu et al.（FSE 2025，同行评审）｜商业 AI 代码生成器克隆率最高 7.5%｜https://dl.acm.org/doi/10.1145/3729397
- arXiv:2603.27130 (2026, 预印本)｜真实仓库中 AI 代码重复率反而低于人类（18.69% vs 25.89%）｜反证
- Faros AI Engineering Report 2026｜2.2 万开发者遥测｜审查时间中位数增 5 倍、31.3% PR 无审查合并（含 AI 审查干扰，单一厂商）
C 级 · 厂商代码扫描报告
- Veracode 2025 GenAI Code Security Report｜80 任务 ×100+ 模型｜45% 引入已知漏洞｜https://www.veracode.com/wp-content/uploads/2025GenAICodeSecurityReport_Final.pdf
- Georgetown CSET(2024-11)｜形式化验证｜约 48% 代码片段含影响性 bug｜https://cset.georgetown.edu/publication/cybersecurity-risks-of-ai-generated-code/
- GitClear AI Code Quality(2024/2025)｜1.5–2.1 亿行代码｜churn/复制粘贴上升（"翻倍"为 2 点外推预测，实测更温和）｜https://www.gitclear.com/aiassistantcodequality2025_research
D 级 · 问卷 / 自报数据（测感知与行为，不测效率或漏洞率）
- Google DORA / State of DevOps(2024/2025)｜近 5000 人｜2024 稳定性 -7.2%，2025 吞吐转正、稳定性仍降｜https://dora.dev/research/2024/dora-report/
- GitHub《Quantifying Copilot's impact》(2022)｜"快 55%"，厂商自报，非同行评审｜https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
- Stack Overflow Developer Survey 2025｜4.9 万人｜信任 33% < 不信任 46%，好感度降至约 60%，66% 苦于"几乎对"的代码｜https://survey.stackoverflow.co/2025/ai/
注：所有数字均由联网检索一手来源（arXiv 摘要、官方 PDF、报告页）逐字核对。方法、样本、置信区间与各研究自陈的局限性已在正文对应处标注。凡"翻倍""40% 不安全""5 倍审查"等易被误引的数字，均已还原其前提或标注争议。