AI重写的真正启示不是效率，而是代码审查权的转移
2026年5月，Bun项目完成了一次在软件开发史上几乎找不到先例的大规模代码迁移：53.5万行Zig代码，11天，64个Claude并行工作，6778次提交，100万行代码变更。
API成本16.5万美元，相当于3名工程师一年的工作量。
这个数字在Hacker News上引发了激烈讨论——有人算账说划算，有人说这是在淡化真实投入。但他们都问错了问题。
真正的问题不是"16.5万美元值不值"，而是：这100万行代码，谁来审查？
一、流行叙事忽略了一个关键事实
Bun重写的故事，大多数报道的叙事是"AI写代码的效率革命"——你看，64个Claude同时工作，每分钟写1300行代码，11天干完人类一年的活。
这个叙事很诱人，但它忽略了一个关键细节。
Jarred Sumner在博客中坦诚地披露了一个数据：Bun的Rust代码中，大约有4%位于unsafe block内，约13,000个unsafe关键字，分布在约27,000行代码中。作为对比，uv约35万行代码，只有73次unsafe调用——Bun的unsafe数量是uv的178倍。
而且，安全Rust代码中也暴露了未定义行为。这比C++还难调试，因为你以为安全代码不可能出问题。
Sumner自己也承认，这次重写引入了19个已知的回归问题，大多数源于语法相同但语义不同的代码——Zig的assert是一个函数，参数在每次构建中都会运行；Rust的debug_assert!是一个宏，在发布版本中整个表达式都会被删除。两段看起来一模一样的代码，行为完全不同。
这些回归问题都已经修复了。但"已经修复"不等于"没有其他问题"。
100万行的变更，实际上没法由人类逐行审查。就算一分钟看一行，也要连续看11.7天；按实际的代码审查速度——一小时200行——要两年多才能看完。
这次PR的审查者主要是claude[bot]和coderabbitai[bot]。Sumner自己的审查方式是"检查对抗性审查agent是否正确捕获了差异，确保转换指南被遵守，同时自己也手动读了不少代码"。但"不少"是多少，他没说。
这是整件事最值得关注的信号：AI写的代码，最终只能由AI来审查。
二、Bun为什么必须重写——以及为什么以前做不到
要理解这个信号的分量，得先理解Bun为什么走到了这一步。
Bun的原始代码是Zig写的。Zig像C一样不自动管理内存，而JavaScriptCore（Bun嵌入的JS引擎）对GC和异常处理有极其严格的规则。当这两种范式在同一个进程中共存，每个内存分配都需要被逐行审查：这些字节在哪里释放？怎么确保只释放一次？这是GC内存还是手动管理的内存？
Bun团队不是没有努力。他们给Zig编译器加了Address Sanitizer支持，每次提交都在CI中运行ASAN测试，在Windows上使用ReleaseSafe构建，用Fuzzilli做24/7的模糊测试，还有大量端到端的内存泄漏测试。
即便如此，崩溃报告仍然源源不断。
"我们的bug修复列表让人感觉很糟糕，我厌倦了带着对Bun崩溃的担忧去睡觉。"Sumner写道。
Rust版本交出的答卷是：同样执行2000次Bun.build()，内存从6.7GB降到609MB。128个可复现的bug被修复，二进制体积减少约20%。
这不是一个"要不要重写"的问题——在GC与手动内存管理的根本矛盾面前，Bun没有选择。
但为什么以前做不到？因为重写意味着冻结一年的bug修复、安全修复和新功能开发。一个年收入为零的开源项目，不可能承受这样的代价。
Claude Fable 5的出现改变了这个等式。不是因为它"会写代码"，而是因为它让Sumner设计了一套全新的工作方法。
三、实现者/审查者分离：AI原生软件开发的方法论
这是Bun重写中最被低估的部分——Sumner的方法论，而不是AI的能力。
他把整个过程拆成了大约50个动态工作流（dynamic workflows），每个工作流都是一个循环：
- 一个Claude基于上下文（Jira ticket或GitHub issue）写出代码
- 两个审查者Claude审查代码
- 应用反馈
- 取下一条任务
峰值时期，Sumner同时运行了4个工作流，每个工作流里16个Claude，总共64个Claude同时在4个工作树中并行工作。
关键设计：实现者和审查者完全分离。
写代码的Claude想让代码被接受——这和人类工程师一样有偏见。所以审查者只看代码差异，不看实现者的推理过程，而且被明确告知"假设代码是错的"。每个实现者对应两个以上的对抗性审查者，审查者的唯一工作就是找bug。
这不是"让AI写代码"。这是设计了一个由AI组成的软件开发组织——有实现者、审查者、集成者，各自有明确的角色和约束。
Zig代码是单一编译单元，Rust要拆分成约100个crate。第一次cargo check输出了约16000个编译错误。对于一个人来说这是灾难，但对于64个并行工作的Claude来说，这是可以处理的工作队列。工作流把错误按crate分组，每个crate跑一遍cargo check，一个Claude修复，两个审查，一个应用修改。
两天后，Linux平台的失败测试从972个降到了23个。一天半之后，Linux全绿了。五天后，全部六个平台全部通过。
测试套件没有跳过或删除任何测试。
四、代码审查权的转移：一个正在发生的结构变化
Bun重写揭示了一个正在发生的结构性变化，我称之为"代码审查权的转移"。
传统软件开发中，代码审查是质量保证的最后防线。一个PR提交后，至少有一个（理想情况下两个以上）人类工程师逐行阅读代码，确认逻辑正确、没有安全漏洞、符合编码规范。这个机制假设了两件事：第一，人类有能力审查所有代码；第二，人类有时间审查所有代码。
Bun重写同时打破了这两个假设。
100万行代码，人类审查需要两年。但更根本的问题是：即使有时间，人类真的能审查AI生成的代码吗？
这不是一个修辞问题。Sumner在博客中提到，安全Rust代码中暴露的未定义行为"比C++还难调试，因为你会以为安全代码不可能出问题"。AI生成的代码遵循正确的语法和类型约束，但可能在语义层面做了你没想到的事情。人类审查者面对一段"看起来正确"的代码，很难像审查人类写的代码那样，凭直觉感知"这里可能有坑"。
这就是为什么审查者必须也是AI——而且必须被明确告知"假设代码是错的"。
这个转移可以分为三个阶段：
阶段1：AI辅助人类审查（当前主流）——AI做初步检查，人类做最终决策。GitHub Copilot、CodeRabbit等工具处于这个阶段。
阶段2：AI审查AI生成代码（Bun正在经历的）——AI生成代码，AI审查代码，人类审查AI的审查。Bun的PR中，claude[bot]和coderabbitai[bot]是主要审查者，Sumner的角色是"检查审查者的工作"。
阶段3：AI生成+AI审查+AI维护的闭环——代码从生成到审查到维护，全部由AI完成，人类只在关键决策点介入。Bun被Anthropic收购后，实际上已经部分处于这个阶段——真正能有效维护这套代码库的工具，基本只有Claude自己。
五、推演：这个框架还能解释什么
"代码审查权的转移"框架不只是关于Bun。它可以解释多个正在发生的现象。
开源项目的可维护性假设正在被颠覆。 传统开源的核心假设是：代码是公开的，所以任何人都可以审查、fork、贡献。但当代码库的规模和复杂度达到只有AI能理解的程度时，"公开"不等于"可维护"。社区里已经有人说，Bun"算不上传统意义上的开源项目了——你想给Bun提PR，得先订阅Anthropic"。
"AI原生代码"的归属问题。 如果代码是由AI生成的、由AI审查的、由AI维护的，那这个项目的"主人"是谁？是写prompt的人？是提供算力的公司？还是拥有最强大模型的那一方？Bun被Anthropic收购不是巧合——当你的代码库只有Claude能维护时，你实际上已经和Anthropic绑定在一起了。
跨领域的映射。 同样的逻辑适用于AI生成的法律文件、AI生成的财务报告、AI生成的医疗诊断建议。当AI生成的内容量级达到人类无法逐项审查时，谁来保证质量？答案可能和Bun一样：另一个AI。但"AI审查AI"的闭环带来了一个根本性的信任问题——如果两个AI串通了呢？如果它们共享了同样的训练数据偏差呢？
六、落到行动
Bun重写不是"AI替代程序员"的案例。它是一个警示：效率提升和可维护性之间，存在一个正在扩大的裂谷。
- 如果你是技术决策者，不要只看API成本。16.5万美元的API费用只是入场券。真正的成本是"可维护性负债"——当你的代码库只有特定AI能维护时，你的技术栈选择变成了模型选择。今天选Claude，明天换Gemini，迁移成本可能比从Zig到Rust还高。
- 如果你是开源维护者，认真考虑AI生成代码的审查策略。不要假设"PR通过了CI就安全了"。Bun的测试套件全部通过，但仍有19个回归问题和13,000个unsafe。考虑引入对抗性审查工作流——不是让AI帮你写代码，而是让AI帮你审查代码。
- 如果你是开发者，不要把注意力花在"学写更好的prompt"上。Bun重写最有价值的部分不是AI的能力，而是Sumner设计的工作流架构——实现者/审查者分离、对抗性审查、并行工作树。学会设计AI协作系统，比学会写prompt重要100倍。
Bun重写最终留下的不是16.5万美元的账单，也不是6778次提交的记录。它留下的是一个拷问：当代码不再需要人类理解时，我们还需要人类开发者吗？
答案也许是否定的——但前提是，我们愿意接受一个由AI维护的软件世界。
参考来源：
- Jarred Sumner, "Rewriting Bun in Rust" — bun.com/blog/bun-in-rust
- InfoQ/36氪报道，2026年7月