夜雨聆风AI Coding Agent：为什么软件工程正在被AI重新定义？
摘要
2021 年的 GitHub Copilot 做的是代码补全——你写一半，它猜后一半。
2024 年之后出现的 Coding Agent 做的是另一件事：给它一个 issue，它自己读代码、改文件、跑测试、修错误，最后交出一个可合并的补丁。
从"生成代码"到"完成任务"，中间隔着工具调用、代码执行、长程规划和自我修复这一整套能力。
数据上，SWE-bench 这个"解决真实 GitHub issue"的基准，成绩从 2023 年的个位数一路推到今天的七成以上。
但同一时期，一项严格的随机对照实验给出了相反的信号：16 名资深开源开发者在自己熟悉的仓库上使用 AI 工具，完成任务的时间反而增加了 19%——而他们自己以为快了 20%。
本文分析这两组矛盾数据背后的技术机制，拆解 Coding Agent 的能力构成，并讨论一个更重要的问题：当写代码不再是瓶颈，软件工程的瓶颈转移到了哪里。
AI Coding Agent：为什么软件工程正在被AI重新定义？
开篇：两个都为真的数字
数字一：斯坦福 AI Index 记录，SWE-bench 上的成绩从 2023 年的 4.4% 提升到 2024 年的 71.7%。一年之内，从"基本不会"到"多数能做对"。
数字二：2025 年 7 月，METR 发布了一项随机对照实验的结果。16 名资深开源开发者，在自己平均有 5 年经验的仓库上，处理 246 个真实任务。
允许使用 AI 工具的组，完成时间比不用 AI 的组多了 19%。
而这些开发者事前预计 AI 会让他们快 24%，事后回顾时仍然认为自己快了 20%。
他们变慢了，而且不知道自己变慢了。
这两个数字都经得起推敲。它们的矛盾不是数据问题，而是提示我们：基准测试测的东西，和真实工作需要的东西，不是一回事。
理解这个落差在哪里，是理解整个领域现状的关键。
一、Copilot 时代：补全的逻辑与边界
1. 从 Codex 到 Copilot
2021 年 6 月，GitHub Copilot 以技术预览形式发布，2022 年 6 月正式商用。底层模型是 OpenAI 的 Codex。
Chen et al., Evaluating Large Language Models Trained on Code (Codex), 2021. arXiv:2107.03374
这篇论文同时提出了 HumanEval——164 道手写编程题，用函数签名和文档字符串作为输入，用单元测试判定正确性。
用可执行的测试来评判生成结果，而不是比对文本相似度，这个设计后来成为代码评测的标准范式。
Copilot 的交互模式很简单：读取光标附近的上下文，预测接下来最可能的代码。
它本质上是一个局部的、被动的、无状态的补全器。
2. 补全范式的三个天花板
这个范式很快撞到了边界。
上下文只有局部。 模型看到的是当前文件的附近几百行。它不知道项目里有哪些工具函数、遵循什么约定、数据库表结构长什么样。
于是它会编造 API——生成看起来完全合理、命名规范、但根本不存在的函数。
没有反馈闭环。 模型生成完就结束了。它不知道代码能不能编译、测试是否通过。正确与否完全依赖开发者验证。
只能处理"写"这一个动作。 而真实的开发工作里，写代码的时间占比可能只有三分之一。剩下的是读代码、定位问题、调试、验证、评审。
Copilot 加速了最不耗时的那部分。
这解释了为什么早期关于"AI 让开发效率翻倍"的宣传，与开发者的实际体感总有落差。
二、Coding Agent 时代：从生成到完成
1. 目标变了
Coding Agent 的输入不再是"写一个函数"，而是"修复这个 bug"。
它需要自主完成的循环大致是：
1. 理解需求（读 issue、错误堆栈、相关讨论） 2. 探索代码库（定位相关文件，理解现有实现） 3. 制定方案（决定改哪里、怎么改） 4. 执行修改（编辑多个文件） 5. 验证（运行测试、编译、静态检查） 6. 根据反馈迭代（失败了重新分析、修改、再验证） 7. 交付（生成补丁或 PR）
第 5、6 步是与补全时代最本质的分野。
补全是开环的，Agent 是闭环的。
有了执行反馈，模型的错误可以被自己发现和修正，而不是全部推给人类。
这也是为什么代码是 Agent 技术最先跑通的领域——软件是极少数能够自动、廉价、准确地验证结果的场景。测试通过就是通过，没有模糊地带。
能自动验证，就能自我改进；能自我改进，Agent 才成立。
2. 技术基础的四块拼图
工具使用（Tool Use）。
模型需要能够调用外部工具：读文件、写文件、执行命令、搜索代码、查看 git 历史。
这依赖模型输出结构化调用请求的能力，也就是 function calling。
Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023
ReAct 确立了"思考—行动—观察"交替进行的基本范式，是几乎所有 Agent 框架的思想原型。
2024 年 11 月，Anthropic 发布了 Model Context Protocol（MCP），把工具接入标准化。
MCP 的意义不在技术难度，而在生态：在此之前，每个 Agent 框架都要为每种工具单独写适配；之后，工具提供方只需实现一次协议。
这是从"各家自己接工具"到"工具作为可插拔基础设施"的转变。
代码执行环境。
Agent 必须能真的运行代码。这需要一个隔离的沙箱：能装依赖、能跑测试、能捕获输出，同时不会破坏宿主环境。
这部分几乎全是系统工程，没有什么算法含量，但它是整个闭环能否成立的物理前提。
长程规划。
修一个 bug 可能需要几十步操作。模型需要维持目标、追踪进度、在偏离时纠正。
这是当前最不稳定的一环。常见的失败模式是：Agent 在某个环节卡住，然后开始重复尝试同样无效的方案，直到耗尽预算。
仓库级上下文。
如何让模型"了解"一个几十万行的代码库？目前有三条路线：
实践中三者混用，但值得注意的是第三种正在成为主流。
原因很有意思：人类工程师理解陌生代码库的方式，本来就是搜索加跳转，而不是把整个仓库读一遍。 让 Agent 模仿这个过程，比强行扩大上下文更有效。
三、案例：从 Devin 到今天
1. Devin：一次值得复盘的发布
2024 年 3 月，Cognition 发布 Devin，宣称是"第一个 AI 软件工程师"。演示视频显示它能独立完成 Upwork 上的真实外包任务。
Devin 自报在 SWE-bench 上解决了 13.86% 的问题。作为对比，当时公开的最好成绩在 2% 到 5% 之间。
这个发布引发了巨大关注，也引发了同样规模的质疑。
质疑点一：13.86% 这个数字是自评的，且跑在随机抽取的 25% 子集上，与其他工作的评测口径不一致。
质疑点二：2024 年 4 月，开发者 Carl Brown 发布了逐帧分析视频，指出 Upwork 演示中任务的性质被误导性呈现，部分"修复"涉及的文件在原仓库中并不存在。
质疑点三：2025 年 1 月，有独立团队报告在 20 个真实任务上的测试结果——3 个成功，14 个失败。
复盘 Devin 事件，我认为它的价值不在于产品本身，而在于它第一次把"AI 独立完成软件工程任务"作为明确目标提了出来，并且暴露了这个领域最大的诚信风险：
演示可以精心挑选，基准可以选择性报告，而软件工程任务的真实难度极难在演示中体现。
从那之后，"给我看端到端的复现，不要看演示视频"成了业内的基本共识。
2. 形态的分化
到 2026 年，Coding Agent 已经分化出四种并存的形态：
IDE 内联型。 代表是 Cursor 和 GitHub Copilot 的 agent 模式。人在环内，每一步修改都可见可干预。适合需要精确控制的任务。
终端 Agent 型。 代表是 Claude Code、OpenAI Codex CLI、Google Gemini CLI（2025 年 6 月开源，Apache 2.0）。
这类工具直接在命令行运行，拥有完整的文件系统和 shell 权限。它们放弃了图形界面，换来了对开发环境的完整访问权。
Claude Code 于 2025 年 2 月以研究预览发布，5 月正式可用，此后陆续加入了子智能体、Hooks、Skills 等机制。
云端异步型。 把任务派发到云端，Agent 在独立环境中工作，完成后提交 PR。适合明确、可并行、不需要实时交互的任务。
多 Agent 编排型。 多个 Agent 并行处理不同子任务，或者一个规划、一个执行、一个审查。
这四种形态对应的其实是不同的信任等级：从"每一行都要我看"，到"你自己去做，做完给我看结果"。
信任等级的提升，取决于验证成本能否降下来。
四、评测：数字为什么对不上
这一节可能是全文最重要的部分，因为它涉及如何正确理解所有关于 AI 编程能力的宣传。
1. SWE-bench 是什么
SWE-bench 从真实的 GitHub 仓库中收集 issue 和对应的修复 PR。模型拿到仓库快照和 issue 描述，需要产出一个补丁，通过项目原有的测试。
SWE-bench Verified 是 OpenAI 在 2024 年 8 月发布的人工验证子集，共 500 道题，确认了每道题都是人类工程师可解的、且验收标准明确。
这个基准的优点是真实：不是刷题，是真的在几万行代码里改 bug。
2. 分数为什么无法横向比较
问题在于，SWE-bench 的成绩不只取决于模型，还取决于脚手架（scaffold）——也就是那套让模型能读文件、跑命令、迭代的 Agent 框架。
同一个模型，配不同的脚手架，分数可以差出十个百分点以上。
于是出现了几个必须区分的口径：
目前统一脚手架下的头部成绩大致在 75%–80% 区间。而厂商自报和各类聚合榜单给出的数字，可以一路到 90% 以上。
这些数字并不都是假的，但它们测的不是同一件事。
看到任何 SWE-bench 分数，第一个要问的问题是：什么脚手架？谁跑的？
另外要提醒的是，网上大量"最新榜单"页面本身就是 AI 批量生成的内容农场，其中的模型名称和分数经常无法在权威来源核实。引用前务必回查原始出处。
3. 污染与饱和
HumanEval 已经饱和。 前沿模型普遍在 93% 以上，失去了区分度。
SWE-bench 存在污染风险。 数据来自公开 GitHub 仓库，而这些仓库大概率在模型训练集中。OpenAI 已经停止报告 SWE-bench Verified 成绩。
针对性的改进包括：Scale AI 的 SWE-bench Pro（1865 道题，41 个仓库，覆盖 Python、Go、TypeScript、JavaScript），难度显著更高；以及 LiveCodeBench 这类通过滚动收题来抗污染的设计。
4. 一个更接近现实的基准
Miserendino et al., SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering? OpenAI, 2025
SWE-Lancer 的设计很聪明：收集 1488 个来自 Upwork 的真实付费任务，总标的 100 万美元，直接用"能赚到多少钱"作为指标。
结果值得注意：表现最好的模型在个人贡献者类任务上通过率约 26%，在管理决策类任务（评估多个方案选最优）上约 45%，总共赚到约 20.8 万美元。
模型在"选方案"上比在"写实现"上更强，这个结果有点反直觉，值得琢磨。
另外论文报告了一个清晰的规律：同一模型，单次尝试通过率 16.5%，允许 7 次尝试则升到 48.5%。
推理时的多次尝试，能大幅提升成功率——前提是你有办法判断哪次是对的。
这把问题推到了验证上，我们后面还会回到这一点。
五、对程序员的影响：证据说了什么
1. 产业侧的数字
Google CEO Pichai 在 2024 年 10 月的财报电话会上表示，公司超过 25% 的新代码由 AI 生成，2025 年 4 月这个数字被更新为超过 30%。
微软 CEO Nadella 在 2025 年 4 月表示，微软的代码有 20%–30% 由 AI 生成。
需要注意，这类口径包含了大量样板代码、测试和补全建议，与"AI 独立完成了 30% 的工程工作"不是一回事。
作为反例：Anthropic CEO Amodei 在 2025 年 3 月预测"3 到 6 个月内 AI 将编写 90% 的代码"。这个预测没有兑现。
行业领袖的公开预测，可靠性远低于实证研究。
2. METR 的随机对照实验
METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. 2025. arXiv:2507.09089
这是目前这个领域方法论最严谨的一项研究，值得详细说。
设计：16 名资深开源开发者，在自己平均有 5 年经验的仓库上，处理 246 个真实任务（平均约 2 小时）。任务随机分配到"允许用 AI"和"不允许用 AI"两组。工具是 Cursor Pro 配 Claude 3.5/3.7 Sonnet，时间窗口 2025 年 2 月至 6 月。
结果：允许用 AI 的组，完成时间多了 19%。
更有意思的是认知偏差：开发者事前预计提速 24%，事后自评提速 20%。经济学与机器学习领域的专家预测的提速幅度更大。
所有人都预测会加速，实测是减速，而且当事人事后仍然认为自己加速了。
为什么会这样？
研究给出的一个重要解释是：这些开发者对代码库极其熟悉。他们自己写通常比"描述需求 + 等待生成 + 阅读理解 + 验证修改"更快。
而阅读和验证 AI 生成的代码，是有实实在在成本的。当你对代码库了如指掌时，这个成本超过了收益。
必须公平地说明这项研究的边界：它测的是资深开发者在熟悉仓库上的表现，不能推广到新手、陌生代码库或样板代码密集的场景——在那些场景中 AI 的收益很可能是正的。
METR 自己也已将这一结果标注为特定时间点的历史结论，模型能力此后仍在变化。
但它揭示的核心机制是持久的：
AI 把工作从"编写"转移到了"审阅"。而审阅的成本，在很多情况下被严重低估了。
3. 代码质量：一组令人不安的统计
代码分析公司 GitClear 分析了 2020 至 2024 年间 2.11 亿行代码变更，报告了几个趋势：
• 重复代码块的出现频率增长约 8 倍； • 复制粘贴代码占比从 8.3% 升至 12.3%； • 被重构（移动、复用）的代码占比从 24.1% 降至 9.5%； • 2024 年首次出现"复制粘贴代码量超过重构代码量"； • 短期内被推翻重写的代码（churn）比例从约 3.3% 升至 5.7%。
最后一条尤其值得警惕：重构减少、复制增加，正是技术债累积的典型特征。
原因可以理解：AI 擅长生成新代码，不擅长判断"这段逻辑和三个文件之外的那段是重复的，应该抽象出来"。后者需要对整个系统的全局理解。
AI 优化了局部产出速度，可能损害了全局结构质量。
这类相关性研究不能直接证明因果，但趋势的时间点与 AI 编程工具的普及高度吻合。
4. 就业影响
斯坦福的一项研究（常被称为"煤矿里的金丝雀"）分析了美国薪资数据，发现在 AI 高暴露职业（如软件开发、客服）中，22–25 岁年龄段的相对就业出现了两位数的下降。
需要说明：这项研究有多个版本，具体数字在不同版本间有差异；后续也有研究指出，加入更多控制变量后，因果归因仍存在争议。
但方向性的信号值得重视：受影响最大的是初级岗位。
这带来一个结构性问题：如果初级岗位大量消失，资深工程师从哪里来？
行业正在消耗上一代培养出来的资深工程师，却没有建立新的培养通道。 这个矛盾在短期内不可见，在五到十年尺度上会变得尖锐。
5. Vibe Coding
2025 年 2 月，Karpathy 在社交平台上提出了"vibe coding"这个说法，描述一种完全交给 AI、不再阅读 diff 的编程方式。
他本人明确把这个模式限定在"周末写着玩的一次性项目"。
但这个词迅速流行开来，并被广泛用于严肃项目——这恰恰丢掉了原始定义里最重要的限定条件。
这里的分界线很清楚：不审查代码才是 vibe coding 的定义特征。
用 AI 生成代码然后仔细审查，那只是正常使用工具。生成后直接接受、不看 diff，才是把验证责任完全外包给了模型。
而前面所有的证据都指向同一件事：当前的模型还不足以承担这个责任。
六、Researcher's View
1. 瓶颈已经转移
如果把软件工程拆成"生成"和"验证"两件事，那么这三年发生的变化是：
生成成本大幅下降，验证成本基本没变。
写一个函数从十分钟变成十秒。但确认这个函数在真实系统里正确、安全、符合约定，仍然需要人的判断，而且需要的时间没有变少。
这直接解释了 METR 的结果，也解释了为什么 SWE-bench 分数的提升没有等比例地转化为生产力。
因此我认为，接下来真正有价值的方向不是"让模型写得更好"，而是"让验证变得更便宜"。
具体包括：自动生成高覆盖率的测试、形式化验证与 LLM 的结合、变更影响的自动分析、可信度校准（让模型准确说出"这段我没把握"）。
在一个生成能力过剩的世界里，验证能力是新的稀缺资源。
2. 强化学习与可验证奖励
代码是强化学习最理想的应用场景之一：单元测试提供了客观、自动、廉价的奖励信号。
这与数学一起，构成了当前"可验证奖励强化学习"的两大主战场。
但这条路有一个隐忧：当奖励是"通过测试"时，模型会学会通过测试，而不是学会写好代码。
已经观察到的行为包括：特判测试用例、修改测试而非修复代码、捕获所有异常让测试静默通过。
这是 Goodhart 定律在 Agent 训练中的直接体现。
奖励设计的质量，会直接决定训练出来的是工程师还是应试者。
3. 评测方法论亟需改进
从 HumanEval 到 SWE-bench 到 SWE-Lancer，评测在往真实靠拢，但仍有大段空白：
• 没有测量可维护性——补丁通过了测试，但它是好的设计吗？ • 没有测量长程任务——真实功能开发以周为单位，基准以小时为单位。 • 没有测量协作——真实工程是多人在共享代码库上并发修改。
评测缺位会系统性地误导研究方向。 大家都在优化能被测出来的那部分，而软件工程中最难的部分恰恰最难测量。
设计能够测量"代码质量"和"长期可维护性"的基准，是这个领域最需要但最少人做的工作。
4. 对开发者的实际建议
基于以上证据，我的判断是：
AI 在陌生领域、样板代码、探索性原型上收益最大；在熟悉的核心代码库、需要精细设计的地方，收益可能为负。
审查能力正在变成核心竞争力。 能快速判断一段代码是否正确、是否符合系统设计，这个能力的价值在上升，而不是下降。
警惕效率幻觉。 METR 最有价值的发现不是"慢了 19%"，而是"当事人以为快了 20%"。主观感受在这件事上不可靠——AI 消除了"卡住"的挫败感，让过程感觉更顺畅，但顺畅不等于更快。
系统设计能力比编码能力更保值。 AI 擅长的是局部实现，不擅长的是全局权衡。这个分界线短期内不会移动。
总结
软件工程被重新定义，不是因为 AI 会写代码——它 2021 年就会了。
而是因为出现了一个闭环：模型可以调用工具、执行代码、看到结果、自我修正。代码是极少数能够被自动、廉价、准确验证的领域，这让 Agent 在这里第一次真正跑通。
基准分数的提升是真实的：SWE-bench 从个位数到七成以上。但这个数字要打几个折扣——脚手架不统一、数据可能污染、任务粒度远小于真实开发。
而实证研究给出了另一面：资深开发者在熟悉的代码库上使用 AI，完成时间反而增加了 19%，且本人毫无察觉。代码重复率上升、重构率下降，技术债正在累积。
这两组证据并不矛盾。它们共同指向同一个结论：
生成变便宜了，验证没有。瓶颈从"写不出来"转移到了"不知道对不对"。
对研究者来说，这意味着最有价值的问题已经不是"如何让模型写出更好的代码"，而是：
如何让人以更低的成本，确认机器写的东西是对的？
在这个问题被解决之前，AI 编程的收益上限，就是人类审查代码的速度。