上周四晚上刷到 Bun 创始人 Jarred Sumner 的博客时我第一反应是看日期——不是愚人节吧。他只用11 天把 Bun——这个被几十万开发者天天用的 JavaScript 运行时——从53.5 万行 Zig 代码整个重写成了 Rust。而且写这 100 万行代码的不是人类是 Claude。64 个 Claude 实例并行跑了 11 天产生59 亿uncached 输入 token、6.9 亿输出 tokenAPI 账单16.5 万美元。没有让团队冻结一年做重写没有漫长的迁移期一个人盯着 50 个动态 workflow11 天后 100% 测试通过128 个 bug 全部修复。说实话看到这些数字时我一方面觉得震撼一方面想起了去年用 AI 写过的那 10 万行代码和后来花两周删掉的 6 万行。AI 写的代码到底能不能信任100 万行未经全部人工审查的代码直接合并进生产环境这合理吗1. 不是 Zig 不好是 GC 和手动内存管理混在一起真的太痛了Bun 当初选 Zig 是有充分理由的。Sumner 在博客里写了一句话我特别认同:如果不是 ZigBun 根本不可能做出来。2021 年他在奥克兰一间逼仄的公寓里没有任何 AI 辅助用一年时间从零写出了 Bun 的第一版。Zig 给了他对底层内存的完全控制权这是 Go 和 JavaScript 都给不了的。Bun 要做的是比 Node.js 快 4-5 倍的 JS 运行时在几百微秒内启动、每秒处理数万请求。只有 Zig 级别的底层控制能做到。但三年半跑下来问题开始积压。Bun 的架构里有一个很难绕过去的矛盾: 它同时用了Boehm 垃圾回收器和 Zig 的手动内存管理。Boehm 是一个保守式 GC——它不知道哪些指针是真正的引用只能通过扫描堆栈来猜测存活对象。当 GC 和手动管理混合使用时就会出现一类特别恶心的 bug——你手动 free 了一块内存但 GC 认为它还在用或者 GC 回收了内存但你的 Zig 代码还持有指针。Bun 的用户报告过不少随机崩溃重启后消失这类最难排查。Sumner 的原话很直接:我们的 bugfix 列表让我很痛苦我厌倦了每天睡前还在担心 Bun 的崩溃。截至重写前Bun 在 GitHub Issues 里积累了128 个已知 bug其中近一半是内存相关的——use after free、double free、segfaults。而且修复一个往往引出两个新的因为 Zig 的编译期保障不足以覆盖跨 GC/手动边界的错误。核心问题是: Zig 不是为带 GC 的运行时设计的Bun 的需求超出了它当初选择的舒适区。Rust 的所有权系统和 borrow checker恰好能在编译期截住这类问题。同样的 bug在 Zig 里可能要跑数小时压力测试才能抓到在 Rust 里直接编译报错。Bun 的用户测试过 Rust 版本后发现 128 个 bug 中相当一部分在 Rust 版本中根本不可能出现——编译期就卡住了。这不是语言好坏的问题是语言匹配度的问题。Bun 的核心矛盾手动内存 GC 共存在选择 Zig 时还不明显跑了三年后变成了结构性负担。2. 一个实验: 从试一下到决定了全部重写Sumner 最初并没有计划重写。他当时在测试 Anthropic 的预发布模型——后来的Claude Fable 5——能不能做代码迁移的自动化工作。Zig 到 Rust 最初只是一个实验他甚至没预期能跑通。实验的目的很简单: 看看让 AI 理解一段 Zig 代码然后输出对应的 Rust 代码质量能不能接受。结果让他自己都意外。实验开始后几天测试套件的通过率快速爬升。他描述那个时刻:最开始我觉得值得试试几天后看到越来越多测试通过想法变成了我打算把这个合并进去。从实验到决定合并大概用了不到一周。这个测试套件是整件事的基石。Bun 的测试是用TypeScript 写的超过 100 万个断言覆盖了全部核心功能。因为 TypeScript 测的是运行时的外部行为——API 响应是否正确、文件读写是否正常、HTTP 请求能否处理——不是内部实现它天然就是语言无关的。只要 Rust 版本通过了同样的测试就意味着对外行为一致。这套策略在其他案例中也反复被验证:测试套件越完备AI 重写的成功率越高。如果你的项目测试覆盖率只有 20%AI 生成的代码你不敢合。但如果你有上万条断言精确定义了正确行为AI 的输出就有了可验证的准绳。Bun 成功的关键不是 Fable 5 多强而是那个百万级断言套件给了验证这个环节足够的置信度。Bun 的测试从 2021 年就开始积累三年半的 TypeScript 测试代码比 Zig 代码本身还庞大。3. 64 个 Claude 并行跑 11 天——不是有钱任性是有策略的并行化很多人看到新闻的第一反应是16.5 万美元换 11 天有钱任性。我读完技术细节后发现这钱花得比想象中聪明。Sumner 不是开了 64 个独立的 Claude 实例各写各的。他用了大约50 个动态 workflow——Claude Code 的特性。每个 workflow 内部维持多个子 agent各自负责一个小模块的转换root agent 统筹接口对齐和依赖管理。峰值时4 个 workflow 同时运行每个 16 个 Claude总共 64 个并发。每分钟产出约1300 行代码11 天总计超过 100 万行 Rust产生了6502 个 commit峰值每小时 695 个 commit。这个架构的关键在于隔离: 每个子 agent 在独立的 git worktree 里运行。如果一个 workflow 的某个模块转换出了问题不影响其他模块的进度。Sumner 可以单独暂停有问题的 workflow修改 prompt重启而不干扰整个流水线。这比一个 AI 帮你写一整天要可靠得多。更值得关注的是 token 消耗:59 亿 uncached 输入 token、720 亿 cached token reads、6.9 亿输出 token。为什么写出 100 万行代码需要读 59 亿 token每个子 agent 写代码前要先读取对应模块的 Zig 源码来理解逻辑。Bun 有 1448 个 .zig 文件覆盖 53.5 万行代码。每次 agent 要把整个模块读完才能翻译。长文件还要分段读取——Agent 的上下文窗口有限超过窗口的内容无法一次性处理文件越长分段越多token 消耗成倍增加。11 天里 Sumner 本人做的事情不是等着。他大部分时间在手动检查 workflow 的输出——读 diff、看测试报告、判断模块转换质量。如果发现某个模块有系统性问题比如某类 Zig 惯用法被翻译成了低效的 Rust他不是逐行改代码而是修改 workflow 的 prompt 或修复循环让 agent 下次自动用正确方式生成。他修的是过程不是结果。此外还要处理 64 个 agent 并行时的协调问题——不同的子 agent 可能对同一个 Rust crate 版本产生冲突两个 workflow 同时修改同一个接口定义——这些问题在自动化生成中比手写更突出。4. 代码可以编译通过但不代表它就是好代码这件事在 Rust 和 Zig 社区掀起了激烈讨论。Zig 创始人Andrew Kelley的回应尤其尖锐。他直接把这批 100 万行新代码称为未经审查的垃圾代码。核心论点: 测试套件能验证行为不能验证代码质量。一个实现可以通过所有测试但内部结构、错误处理一致性、性能特性可能完全是乱的。Kelley 讽刺地说:如果测试套件好到足以抓住 Zig 版本里漏掉的所有 bug那为什么它不足以让你信任经过人工 review 的 Zig 代码相同的测试套件没有阻止 128 个 bug 进入 Zig 版本凭什么相信它能兜住 Rust 版本我仔细想了想这个逻辑。一方面Kelley 说的有道理——测试通过不意味着代码没问题。但另一方面Sumner 切换语言的目的正是一类 bug 从运行时移到编译期。从结果看Rust 版本跑了一个月新 bug 数量显著下降。Claude Code 自己就在用 Rust 版 Bun——如果真有大问题Anthropic 自己先受害了。更棘手的问题在长期维护。535 496 行 Zig 分布在 1448 个 .zig 文件中每块都有对应的 agent 生成的 Rust 版本。100 万行代码里可能不到 5% 被人类完整读过。Sumner 读了 workflow 输出、看了差异、跟踪了测试——但他没有逐行 review。这带来的问题是: 测试覆盖了已知行为模式但 AI 可能在边缘路径上生成了一段人类不会写的代码——逻辑对但难以维护。如果过几个月需要修改某个模块接班的人面对的是一段看起来正常的 Rust 代码但没人记得它是怎么来的。不过 Sumner 的回应也有道理: Bun 的 100 万个断言是手写的 TypeScript每一条背后都有人的意图。AI 生成了 Rust 版本但这些断言是人类的签名。Bun 的新版本上线一个月Claude Code 从 v2.1.181 开始切换到 Rust 版 Bun启动快 10%几乎没人注意到这个变化128 个 bug 全部消失。工具变强了但判断好代码的标准不能跟着降。5. 这件事到底意味着什么——不是技术问题是信任机制的问题我不觉得 Bun 的做法可以直接复制到每个项目上。Fable 5 不对外开放16.5 万美元预算不是每个团队都有百万级测试套件是多年积累的硬资产。但这件事揭示了一个正在发生的深层转变:AI 已经开始承担模块级重写的任务。一个工程师加 50 个 workflow11 天完成小团队一年的工作量——已经不是效率提升是量级变化。我自己从这件事拿走的一个操作: 这周给项目的测试套件加了 CI 门槛——任何新功能必须先写测试再加代码。不是因为 KPI是因为看到了一个现实:测试套件的质量决定了你能在多大程度上信任 AI 生成的代码。你不需要现在就决定要不要用 AI 重写但你今天可以决定我的测试套件够不够强。如果有一天你也面临让 AI 重写一个模块的决策你的测试套件就是你的底气。当 AI 生成的代码量从辅助补全走向模块级重写整个行业需要新的验证机制。我们不可能逐行 review AI 生成的百万行代码——那不是 review是通读。也许答案是更严格的编译期检查。也许答案是自动化的形式化验证。也许答案是 AI 代码专用的审查流水线——就像人类代码从直接上线进化到 CI/CD review staging 一样。Ponytail 在做反过度工程审查OMO 在做 agent 验证层Bun 的 100 万个断言本质上也是同一件事: 让验证从人工检查每一行变成自动验证所有行为。这件事对开发者工具的启发可能比表面上的故事更深。当 64 个 agent 能在 11 天内完成语言迁移我们离AI 参与架构决策还有多远测试驱动的范式质量保障的自动化流程即代码——这些概念其实早在 Bun 之前就存在了但 Bun 把它推到了一个新的量级: 不是 AI 辅助人类而是人类设计流程、AI 执行流程、测试验证结果。这个三角关系可能是未来几年软件工程的核心模式。我不知道最终答案是什么。但我知道: 64 个 Claude 并行重写这个方案一年前不存在现在它存在了而且被验证过了。剩下的问题——怎么信任 AI 生成的代码——是我们整个行业要去适应的。这个适应过程可能比想象中更快。毕竟 11 天前Bun 还在用 Zig。回到最初那个问题: 64 个 AI 同时工作生成 100 万行代码一个人 11 天完成一年的工作量这到底是好消息还是坏消息我的答案是: 既是好消息也是坏消息。好消息是我们以前不敢做的事——大规模重写、全量迁移、彻底重构——现在可以做了。坏消息是那些以前靠读一遍所有代码来保证质量的做法已经不再适用了。而我现在每天在终端里敲 claude已经习惯了通过 workflow 批量处理任务的节奏——等我真正需要做一次模块级迁移时希望我的测试套件已经准备好了。因为当 AI 能每天产出百万行代码的时候测试套件就是你和灾难之间的那道闸门。回到最初那个问题: 64 个 AI 同时工作生成 100 万行代码, 一个人 11 天完成一年的工作量, 这到底是好消息还是坏消息? 我的答案是: 既是好消息也是坏消息。好消息是, 我们以前不敢做的事——大规模重写、全量迁移、彻底重构——现在可以做了。坏消息是, 那些以前靠读一遍所有代码来保证质量的做法, 已经不再适用了。当生成代码的速度远超审查代码的能力时, 信任必须从人工检查转移到自动验证。
