AI生成百万行代码，测试通过率100%——这是奇迹还是灾难？

Bun这个项目最近干了一件事。50个Claude Code并行跑，11天，生成了100万行Rust代码，把所有测试全部跑通，通过率100%。HashiCorp创始人Mitchell Hashimoto在X上说，以那个薪资水平，工程师绝对不可能在11天内达成这个里程碑。

看起来像奇迹。但Zig创始人Andrew Kelley看完之后，只说了一句话：没人把关的烂代码。

这不是第一次AI生成代码引发讨论了。过去几个月，AI编程工具圈的几件事放在一起看，能看出一些有意思的趋势。

模型和Harness开始分家了

事情要从一个开发者开始说起。

7月份，开发者Theo在X上发现一件事：同一个GPT-5.6 Sol模型，放在Claude Code里跑，部分任务上的表现比放在Codex里还好。模型没变，变的是外面的Agent框架。

OpenAI的Codex负责人Tibo看到了这条帖子，直接公开分享配置方法：保留Claude Code的官方CLI，在本机启动CLIProxyAPI，把模型请求转发给GPT-5.6。整个配置五分钟搞定。他在帖子里还留了一句：如果这个办法被封，我欠大家一次reset。

一个月后，开发者Alex真的照做了。他的Anthropic账号被暂停了，理由是"suspicious signals"。Tibo公开质疑Anthropic，Claude Code负责人Boris Cherny下场澄清：不会因为在harness里用其他模型就封号。Alex的账号后来恢复了。

这场风波最后演变成OpenAI和Anthropic两位负责人的公开"互怼"，甚至Tibo真的给所有ChatGPT Work和Codex用户重置了一次额度——虽然很多人发现，重置的时间刚好赶上每周额度正常刷新之后，有点表演性质的味道。

但真正值得看的不是闹剧本身，而是背后暴露的问题：模型和Harness正在解耦。

Codex官方介绍GPT-5.6技术架构时，专门把Agentic Harness单独拿出来讨论。Harness是连接模型、工具和用户环境的一层编排系统，负责管理上下文、工具调用、重复任务和整个Agent loop。模型决定推理能力，Harness决定模型能看到什么、可以调用什么工具、什么时候执行命令。

OpenAI让GPT可以跑在Claude Code里，等于自己削弱了客户端的锁定价值，却扩大了模型的分发范围。Anthropic说Claude Code足够好，好到用户即使不用Claude模型也希望继续使用——那Claude Code本身就成了一层独立于底层模型之外的入口。

这改变了Coding Agent的竞争逻辑。以前人们把"Claude Code"和"Claude"看成同一个东西，把"Codex"和"GPT"看成同一个东西。现在这两层可以拆开比较了。

100万行代码，谁在把关？

回到Bun的那次重构。

Bun是一套JavaScript工具集，包含运行时、包管理器、打包工具和测试运行器。它最初用Zig语言写的，为了提升速度用了苹果WebKit的JavaScriptCore引擎。

但用户发现的漏洞越来越多。Anthropic 3月份发生的那次51.2万行代码泄露事件，其实就是Bun的错——Bundler里有个漏洞，即使被明确禁止，构建过程中还是会生成源映射文件。

Sumner决定用AI重写。他启动了约50个动态Claude Code工作流，峰值时每分钟生成约1300行代码，11天生成超过100万行Rust代码，成本约16.5万美元（按API定价算）。基于Rust的Bun接受了自身超过100万条断言的测试套件检验，全部通过。

听起来很厉害。但Zig创始人Kelley不这么认为。

他在博文里说，甚至在Anthropic收购之前，"我们对Bun代码库里看到的编程实践就感到越来越震惊"。激进发布新功能，Bug堆积如山，错误处理代码拙劣，积累了大量技术债务。Kelley打趣道：早在获得大语言模型访问权限之前，Sumner就已经在写一团糟糕的代码了。

更关键的问题是：测试套件能发现所有Bug吗？Kelley指出，测试套件连Zig代码中的Bug都没能完全发现，凭什么相信它能发现100万行未经审核的Rust代码中的Bug？

他写道："支持发布这100万行未经审核代码的论点是，测试套件足够完善。但它连Zig代码中的Bug都无法完全发现，却足以发现100万行未经审核的粗制滥造的代码中的Bug吗？"

Zig项目之前就拒绝过Bun团队的一次AI辅助贡献。Bun维护过一个Zig分支，据称调试编译速度提高了四倍，但Zig项目以"不接受基于AI的贡献"为由拒绝了。Kelley对Reg杂志说，Zig此前涌入大量LLM生成的提交代码，大部分质量堪忧。

"写代码从来都不是难点"到底对不对

这场争论的背景里，还有一篇在开发者社区引爆的文章。

有人写了一篇长文，核心观点是：大语言模型很擅长写代码，但软件开发的难点从来不在写代码。还有人说，写代码很容易，真正困难的是弄清楚该写什么。

这篇文章在Hacker News上吵翻了。

支持者说，大多数时候程序员的工作就是把网络功能连接到已有的UI元素上，真正难的是写GPU着色器和优化性能。反对者则认为，如果写代码很容易，为什么程序员长期供不应求，为什么会有《代码整洁之道》《程序员修炼之道》这样的书，为什么传奇程序员卡马克的成就只算碰巧赶上了好时候。

最有趣的评论来自一个有40年编程经验的老程序员。他说自己维护着一套25年前写的金融系统核心算法，每晚处理数十亿美元的资金流转。代码从FORTRAN 77转成C语言，只有十来屏，却充斥着goto、复杂分支和二十多个并行数组，运行极快，人却几乎读不懂。

这套系统要解决的实际问题，用三句话就能概括。但真正写出来非常困难，因为上下文管理极其复杂。客户宁愿长期支付授权费也不愿自行开发。

他的结论是：编程真正的难点一直在于管理上下文，而我们需要管理的上下文本身也在不断变化。擅长管理上下文的人，会擅长使用LLM编程；不擅长管理上下文的人，依然不会。

这句话恰好呼应了Claude Code团队在NDC Copenhagen演讲里的核心观点：2026年的核心转变，是从"把信息输入模型"转向"把信息从模型输出给用户"。人的注意力才是系统中最小的盒子。

当Harness成为核心竞争力

把这几件事放在一起看，AI编程工具行业的竞争重心正在发生位移。

过去两年，大家都在拼模型能力——谁的代码生成更准、谁的推理更强、谁的token价格更低。但现在，模型和Harness开始分层了。

模型是引擎，Harness是变速箱。 同样的引擎装在不同变速箱里，开出来的感觉完全不同。同一个GPT-5.6 Sol，放在Claude Code里和放在Codex里表现不同，就是这个道理。

这带来了几个变化：

第一，用户开始自己搭配。不再接受"一个模型必须绑定一个官方客户端"的组合。用户可以选择最适合的模型+最擅长的Harness，自己组装编程环境。

第二，Harness的工程价值被重新认识。Claude Code的插件设计、上下文工程、多Agent工作流，这些不再是锦上添花的功能，而是决定模型能力能否被充分释放的关键。Daisy Hollman在演讲中说，定制化就是知识，定制化是在弥合模型天生所知与团队所知之间的差距。

第三，代码质量监管成为新课题。100万行AI生成的代码，测试通过率高不代表质量好。当Harness能让AI以人类无法企及的速度生成代码，谁来保证这些代码是可维护的、安全的、符合工程规范的？

Bun的重构给了一个激进的实验答案：让AI自己把关，用测试套件验证。Kelley给出了相反的警告：没有人为质量兜底，速度越快，债务越多。

这两种观点都不会在短期内分出胜负。但可以确定的是，Harness层的竞争已经开始了。谁能设计出更好的上下文管理机制、更灵活的插件抽象、更可靠的代码质量守护，谁就能在AI编程工具的下一轮竞争中占据优势。

至于模型本身，可能会变得越来越像基础设施——重要，但不再是最关键的差异化因素。