AI写代码越来越快，程序员为什么反而更累了？

执行摘要

AI 编程真正改变的，可能不是“程序员还要不要写代码”，而是程序员的工作正在从“生产代码”，转向“监督代码”。

GitHub Copilot 从 2021 年的代码补全，已经一路演进到可以自行修改文件、运行命令、创建 PR 的 Coding Agent；Claude Code、Cursor、Codex 也把 AI 从“给你建议”推进到了“替你执行任务”。[11]

效率提升是真实的，但它并不自动等于工作量下降。2023 年一项 GitHub Copilot 对照实验中，开发者完成一个标准化 JavaScript 任务快了 55.8%；但 METR 在 2025 年对资深开源开发者真实项目进行随机实验时，却发现允许使用 AI 的任务平均反而多耗时 19%。两组结果并不矛盾：AI 对“生成”的提升很明显，但越接近复杂、长期、需要上下文和交付责任的真实工程，验证成本越重要。 5

所以我越来越认同一句话：

AI降低了写代码的成本，却没有降低把代码安全地交付到生产环境的成本。

背景

老板：

“现在都有 AI 了，这个功能应该很快吧？”

业务：

“AI 都能写代码了，为什么还需要这么久？”

这两句话，我相信不少开发者已经听过。

问题在于，外界看到的往往是 AI 五分钟生成了几百行代码；开发者看到的却是后面的事情：这几百行到底改了什么？需求理解对了吗？边界条件覆盖了吗？会不会破坏旧逻辑？测试真的有效吗？上线以后出了问题谁负责？

过去几年，AI 编程工具本身也在迅速改变。2021 年 Copilot 的核心还是 IDE 内的行级、函数级补全；2023 年 Copilot X 把聊天和 PR 辅助带进开发流程；2024 年 Copilot Workspace 开始覆盖规划、构建、测试；到 2025 年，Claude Code、GitHub Coding Agent、OpenAI Codex 已经能够直接读取仓库、修改多文件、运行测试并提交 PR。2026 年，工具又进一步走向并行 Agent、Skills 和更长时间的自主执行。[11]

真正值得讨论的，已经不是“AI 会不会写代码”，而是：

当生产代码的速度突然提高几倍以后，我们有没有同步提高验证代码的能力？

现状

今天主流工具已经不只是“代码补全插件”，而是在逐渐成为可以行动的工程 Agent。[11]

工具	主要能力	集成程度	需要重点防范的问题
GitHub Copilot	补全、Chat、Agent、Code Review、云端 Agent	IDE + GitHub + CLI	语义错误、错误理解需求、安全漏洞、上下文不足。GitHub 官方明确要求人工 review 和 test。1
Claude Code	阅读仓库、跨文件修改、运行命令、测试、Agent 工作流	Terminal + IDE + Web	错误上下文、命令执行风险、Prompt Injection；Anthropic 明确把最终审查责任交给用户。2
Cursor	Agent 搜索代码库、修改多文件、运行终端、自动修错	AI 原生 IDE + CLI + Cloud Agent	缺少清晰规格、测试和 lint 等反馈信号时容易跑偏；官方最佳实践同样强调先规划和建立可验证目标。3
Codex	云端并行任务、功能开发、修 Bug、PR、Code Review	IDE + CLI + Cloud	输出仍需通过测试、日志和 review 验证；OpenAI 自己也把“验证”作为独立工程层处理。4

这其实意味着软件开发中出现了一种新的流水线：

过去：理解需求 → 写代码 → 调试 → Review → 测试 → 上线

现在：理解需求 → 描述任务 → AI 大量生成 → 阅读 AI 输出 → 找错误 → 修正 AI → 测试 → Review → 上线

中间的“手敲代码”少了，但监督、判断、验证的比例上升了。

问题分析

2026 年一项针对专业软件工程师的纵向研究，给这种变化起了一个很准确的名字：Supervisory Engineering Work，监督型工程工作。82% 的受访者表示自己写代码的时间下降，但工作的重点明显从“创造”转向了“指导、评估和纠正 AI 输出”。9

这正是很多人产生落差的地方。

AI 让“第一版”来得太快，于是组织很容易把生成速度误认为交付速度。

但是，一个 PR 从 50 行变成 500 行，并不代表 review 也能快十倍。反过来，AI 越容易生成更多代码，团队越可能面对更多 diff、更多测试、更多隐藏的上下文错误。Stack Overflow 2024 调查中，约 12% 的专业开发者已经直接把“产生更多需要 review 的代码/PR”列为团队使用 AI 的挑战；更大的问题则是缺乏代码库上下文和对输出缺乏信任。8

GitHub 自己的文档也明确承认，Copilot 可能生成“看起来正确”但语义错误、没有真正解决问题甚至存在安全漏洞的代码，因此关键应用必须 review 和 test。1 Anthropic 对 Claude Code 的要求同样直接：用户需要负责审查拟执行的代码和命令。2

所以“AI 都写完了，为什么还不能上线？”这个问题本身就混淆了两件事：

代码生成完成 ≠ 软件工程完成。

真正昂贵的部分越来越不是“把代码写出来”，而是证明这段代码值得被信任。

案例

下面三个案例是基于实际研发流程和公开研究综合出的典型场景，不对应某一家具体公司。

案例一：一个原本一天的小需求。 开发者让 Agent 修改权限模块，十分钟后 AI 改完七个文件，测试也通过。看起来已经完成 90%。但 review 时发现 AI 复用了一个旧权限判断，在普通场景完全正常，只有特定角色组合才会越权。最后真正耗时的不是生成代码，而是理解 AI 到底改了什么、补测试并重新验证。这类“代码看起来合理但意图理解错误”的风险，也是 GitHub 官方明确列出的限制。1

案例二：AI 让一个人同时开三个任务。 每个 Agent 都在后台工作，于是表面吞吐量明显提高。但一小时后三个任务同时回来，开发者必须连续切换上下文、读三个 diff、回答三个 Agent 的问题。代码生产并行了，人的注意力没有并行。2026 年纵向研究恰好观察到类似趋势：生产力感知保持较高，但 flow state 和 cognitive load 方面的体验出现恶化。9

案例三：管理层把 AI 效率直接折算成排期。 原本三天的需求被认为“有 AI 一天就够”。开发者确实第一天就拿出了可运行版本，但验证、联调和回归并没有同比缩短。最后出现的不是“AI 节省两天”，而是剩余两天被新的需求填满。这种“产出速度提高后同步提高工作节奏和产出预期”的风险，已经进入开发者福祉研究的讨论范围。9

研究与数据

目前关于 AI 编程效率的研究其实给出了一个非常有意思的答案：AI 提效是真的，但“提效多少”高度取决于你测量什么。

GitHub/Microsoft 2023 年的受控实验发现 Copilot 可让一个标准化 HTTP Server 任务完成时间缩短 55.8%。6 但 METR 2025 年让 16 名资深开发者处理自己长期维护的大型开源项目中的 246 个真实 issue 时，AI 组却平均慢 19%；而且开发者主观上仍认为自己快了约 20%。METR 特别强调，这一结果不能泛化成“AI 对所有开发者都无效”，但它很好地说明了主观的“写得很快”和端到端实际工时并不是一回事。5

DORA 的数据则进一步提醒管理者：AI 使用与个人生产力提升可以同时存在，但组织级软件交付未必同步改善。其报告发现，AI 使用增加与 delivery throughput 和 stability 下降存在关联，并认为更大的代码批次和 review 压力可能是原因之一。DORA 因而特别强调自动化测试、持续集成和快速反馈回路。7

心理层面的信号也开始出现。一项覆盖 442 名开发者的研究发现，GenAI 的使用可能通过增加 job demands 与 burnout 建立联系，而足够的工作资源、支持和正向使用体验能够缓和这种关系。10 另一项 2026 年纵向研究则发现，84% 受访者持续认为 AI 提升了生产力，但在匹配样本中，至少一个开发体验维度恶化的人群比例从 14% 增至 27%。9

换句话说：

“我产出得更多”与“我工作得更舒服”，完全可能同时朝相反方向发展。

对策建议

真正有效的做法，不是要求开发者“多学几个 Prompt”，而是把整个研发流程重新设计成适合 AI 高吞吐量的系统。

首先，排期不能按生成代码的速度估算，而应该按可验证交付的速度估算。需求分析、Review、QA、回归、灰度和生产观察仍然应该进入估时；所谓 SLA 也应该区分“AI 首版时间”“进入测试时间”和“可安全上线时间”，不能把三者混成一个指标。DORA 同样建议组织强化测试和快速反馈，而不是只追求生成速度。7

其次，限制 AI 一次产生的变更规模。一个 100 行、目标清晰、测试明确的 Agent PR，通常比一个横跨二十个文件的“自动重构”更容易验证。GitHub Cloud Agent 本身也建议复杂任务拆成更小、更聚焦的任务；Cursor 的官方实践则强调先建立计划、测试、类型检查和 lint，让 Agent 获得明确的成功信号。[1,3]

再次，不要让写代码的 AI 自己成为唯一的审查者。可以使用第二模型做 Code Review、静态扫描、单测、集成测试、SAST 和依赖检查，把“验证”也自动化，但最终仍应保留责任人。OpenAI 的实践很有启发性：它甚至把代码生成和代码审查视为两个不同的优化问题，并明确警告“clean review”不能被当成安全保证。4

最后是最容易被忽略的一点：给开发者正式的 AI 学习时间，而不是默认“工具给你了，你自然就应该更快”。 DORA 的组织研究发现，在工作时间内提供专门学习时间与更高的团队 AI 采用率相关，而把学习压力转嫁到个人时间更容易带来挫败和 burnout。7

因此团队真正应该衡量的，不只是“AI 写了多少代码”，而是：从 issue 到 PR 的周期、AI PR 返工次数、review feedback cycles、测试覆盖变化、线上缺陷率和回滚率。 GitHub 自己在 Copilot 最佳实践中也建议围绕 issue-to-PR、迭代次数、review 周期和测试改善来衡量效率。1

结论

我并不反对 AI 编程。恰恰相反，我现在越来越难想象完全不用 AI 写代码的工作方式。

但我反感的是另一种逻辑：

“AI 都能写代码了，所以开发应该很简单。”

AI 确实让生成代码变得越来越简单。2026 年的研究甚至已经观察到，软件工程价值正在从 routine coding 向 specification quality、architecture reasoning 和 oversight 转移。9

可需求不会因为 Claude Code 出现就自动变清晰，系统不会因为 Copilot 写得快就自动变稳定，生产事故也不会因为代码是 AI 生成的就由 AI 承担责任。

所以未来程序员最重要的能力，也许真的会发生变化。

以前我们花大量时间证明：

“我能把代码写出来。”

以后我们可能要花更多时间证明：

“我知道什么应该让 AI 写，我知道它哪里可能错，而且我有能力为最终结果负责。”

AI 降低了代码的生产成本。

但在一个代码越来越廉价的时代，判断、验证和责任，反而会越来越贵。 [9,10]

参考资料

1 GitHub. GitHub Copilot 文档：能力、使用限制与人工 Review / 测试要求. GitHub Docs. https://docs.github.com/en/copilot

2 Anthropic. Claude Code 文档：用户需负责审查拟执行代码与命令. https://docs.anthropic.com/en/docs/claude-code

3 Cursor. Cursor 文档与最佳实践：先规划、建立可验证目标、测试与 lint 反馈. https://docs.cursor.com

4 OpenAI. Codex 文档：将“验证”作为独立工程层；“clean review” 不能作为安全保证. https://openai.com/index/codex

5 Becker, J., Rush, N., Barnes, E., & Rein, D. (METR). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 2025. https://metr.org/blog/2025-07-10-early-2025-AI-experienced-os-dev-study

6 Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590 (2023). https://doi.org/10.48550/arXiv.2302.06590

7 DORA (Google Cloud). 2024 Accelerate State of DevOps Report 与 2025 State of AI-Assisted Software Development Report. https://dora.dev

8 Stack Overflow. 2024 Developer Survey：AI/ML 洞察（采用挑战与信任问题）. https://stackoverflow.co/labs/2024-developer-survey-insights-for-ai-ml

9 Vella, A., & Blincoe, K. The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. 2026（提出“监督型工程工作 / Supervisory Engineering Work”；82% 写代码时间下降，84% 感知生产力提升但匹配样本中 27% 体验恶化，价值向规格质量 / 架构推理 / 监督转移）. arXiv: https://arxiv.org/abs/2605.23135

10 IEEE/ACM ICSE 2026 研究（n=442 名开发者，PLS-SEM）：GenAI 采用通过提升 job demands 增加 burnout（β=0.398, p<.001），自主性 / 学习机会等工作资源可显著缓和（β=-0.360, p<.001）. arXiv: https://arxiv.org/abs/2510.07435（DOI: 10.1145/3786581.3786934）

[11] AI 编程工具演进综述：Copilot（2021 补全 → 2025 Coding Agent）、Claude Code / Cursor / Codex 多文件自主执行、2026 并行 Agent 与 Skills。综合自 1–4 各工具官方发布与文档。