# 编码代理能草拟补丁，但谁来承担验证成本？

**Summary:** 编码代理降低了实现成本，但团队仍需为每个被接受的变更支付验证和所有权成本。我会根据发现并回滚错误的成本来决定委托范围。

- Canonical: https://markhuang.ai/zh/news/coding-agents-patch-proof-cost
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-28
- Section: News
- Tags: 编码代理, 软件工程, 代码审查, AI 可靠性, 开发者生产力
- Source: [Alex Ewerlöf Notes](https://blog.alexewerlof.com/p/coding-is-not-solved)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![Mark 正在检查一条快速自动化生产线上的组件，背后是一个规模大得多的测试实验室](https://cdn.markhuang.ai/news/coding-agents-patch-proof-cost/hero.webp)

*补丁几秒就能送到，但背后的验收环节，还是得有人来扛。*

Alex Ewerlöf 9 月 26 日的文章《[编码尚未被解决](https://blog.alexewerlof.com/p/coding-is-not-solved)》反驳了“更好的编码代理已经终结软件工程”的观点。他做了一个很有用的区分：生成代码的成本已经大幅下降，但维护、可靠性、安全性和责任归属仍然占了大头。

我的看法比标题温和一些。编码代理确实砍掉了大量实现层面的摩擦，这很重要。但补丁出得快，和变更被接受，是两回事。我判断该委托什么任务，看的是答案出错后发现和回滚要花多少钱，而不是第一版看起来有多惊艳。

## 原文准确指出了成本转移

Ewerlöf 认为，个人软件和概念验证可以容忍医疗、金融、航空等关键系统无法承受的风险。我不会只按行业来划这条线。一个小型内部脚本也可能删掉关键数据，而受监管公司内部一个经过严格隔离的工具，反而很容易验证。更靠谱的边界是验收测试。

变更有清晰的规范、靠谱的测试、可回滚的上线方式，再加上一个了解周围系统的审查者——这种情况下，廉价的代码生成就是实打实的收益。反过来，需求还在变，或者 bug 只有上了负载才冒出来，那代理加速的只是原本就最显眼的部分。

“编码已解决”这句话之所以惹麻烦，是因为它把敲代码、设计、集成、运维和责任归属全揉成了一件事。原文有时也用同样笼统的说法来反击，断言模型做不了某些事。两个极端我都不需要，我想知道的是：证据到底在哪里停住。

## 跑通一次会话，不等于有人为系统负责

[Anthropic 对约 40 万次 Claude Code 会话的研究](https://www.anthropic.com/research/claude-code-expertise)提供了有力证据，表明代理已经完成了大量工作。典型会话里，人类做了大约 70% 的规划决策，Claude 做了大约 80% 的执行决策。领域专业知识越强，成功率也越高。

这已经远超高级自动补全的范畴，但 Ewerlöf 的担忧依然成立。研究自己也承认，它没法追踪生成的代码后来是被用了、扔了，还是真变成了有经济价值的东西。它的成功指标来自会话记录，来自测试通过、代码提交这类信号。这些指标有用，但生产环境的责任归属，恰恰从这些信号之后才开始。

我倾向于把这个规划分工看成一份岗位说明：代理多干实现的活，人守住问题定义、权衡取舍和验收标准。专业知识在这些会话里并没有消失，只是改变了用户可以放心交出去的那部分。

> **Info:**
>
> 出错代价低、回滚容易的事，我会放手让代理去做。任一成本上去了，我就要更窄的范围、更硬的证据，以及一个明确担责的人。

## 战线拉长，账单就藏不住了

短期任务容易让人忽略：第一个测试通过之后，代码库到底变成了什么样。[SlopCodeBench](https://arxiv.org/abs/2603.24755) 让代理在 20 个问题、93 个检查点上不断扩展自己的方案。结果没有一个代理能端到端跑通，单个检查点的最高通过率也只有 17.2%。作者还发现，80% 的运行轨迹里代码结构在恶化，89.8% 的轨迹里输出越来越啰嗦。

一项基准测试定不了编码的未来。但它确实点出了我最在意的那种失败：每一个局部看起来都合理的补丁，叠在一起却让下一次改动更难。审查成本就这样滚雪球，尤其是代码涌进来的速度，远快过维护者把它读懂的速度。

连衡量标准本身也得审。2026 年 2 月，[OpenAI 发现数据污染和测试缺陷后，停报了 SWE-bench Verified](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/)。在它抽查的子集里，那些频繁失败的题目中，至少 59.4% 的测试会把功能正确的提交拒掉。基准测试可能在补丁正确时判它失败；生产测试也可能在补丁错误时放它过去。“测试都过了”是证据，不是免罪符。

## 最有力的反对意见是工具已经进步

原文反对过早庆祝是对的，但容易把能力现状拍成一张定格照。METR 2025 年初的随机试验发现，16 名资深开源开发者用了 AI 工具反而慢了 19%。到[年底的后续研究](https://metr.org/blog/2026-02-24-uplift-update/)看到了加速迹象，却不敢给一个确定数字——因为那些离开 AI 就干不了活的开发者，已经自己退出了实验。工具确实在进步，但这个实验已经说不清进步了多少。

[Hacker News 上围绕 Ewerlöf 文章的讨论](https://news.ycombinator.com/item?id=49877988)把分歧摊开了。有人说编码和软件工程根本不是一回事；有人说更好的编排框架已经自动化了大头工作，又或者人类本来就不一致，拿"可问责性"来对比太过理想化。我觉得第一种说法有道理，第二种只说了一半。人不需要做到确定性，也照样可以为系统和上线决策负责。

代理会持续把边界往前推。正如我在[《更强的编码代理，更少的工具》](https://markhuang.ai/news/stronger-coding-agents-fewer-tools)里讨论的，更好的上下文管理、规划和工具链，可以在底层模型不变的情况下改变结果。所以不管往哪个方向下永久结论，都有风险。

## 我会优先预算验证成本，而非 token 成本

每委托一个任务，我会先把验收路径写下来：什么证据能拦下一个看着对但其实有问题的补丁？谁对代码熟到能发现需求漏了？改动能不能在不弄脏状态的前提下回滚？后面有多少工作会绑在它引入的设计上？

然后我算的是每个被接受变更的总成本——审查、重试、回归、后续修补都算进去。这个指标在代理真省了时间的时候会给它满分，也能把那些被低 token 账单悄悄甩给审查者的活计抓出来。

编码还没被解决——但这句话太粗，带不了团队。实现确实在变便宜，也确实在变得更自主。可团队还是得证明变更靠得住、判断它该不该进、对上线以后发生的事情负责。只有当工作流真正降低了这笔总账，而不是把活悄悄挪给审查者，我才会采纳它。