21CTO导读：在 Bun 官方发布“AI 将数十万行 Zig 代码重写为 Rust”的长文后，Zig 语言创始人 Andrew Kelley 怒了，他撰写了一篇火药味十足的万字博文予以“回击”。

11 天百万行 AI 迁移工程引爆行业热论

此前， Bun 创始人 Jarred Sumner 发布完整复盘文章，披露了轰动底层开发圈的代码迁移工程：它依靠 Claude Code 搭建并行 AI 工作流，仅耗时 11 天，就将总计 53 万余行 Zig 源码完整机械转换为 Rust，全程累计 6502 次代码提交，峰值同时运行 64 个 Claude 实例协同生成、校验代码。整套流程配套对抗式人工审查、跨平台全量测试，最终推出基于 Rust 重构的 Bun v1.4.0 canary 版本。

就在这场 AI 大规模代码迁移的热度尚未褪去时，Zig 语言创始人 Andrew Kelley 发布长文《My Thoughts on the Bun Rust Rewrite》，直接针对 Bun 项目、团队工程模式展开尖锐批评。

整篇文章并未纠结 Rust 与 Zig 语言语法、借用检查器等技术细节，而是直指 Bun 长期存在的工程陋习、开发节奏问题，以及该项目给 Zig 社区带来的负面影响。

在文中，一句极具争议的论断迅速传遍技术社区：

早在大模型 LLM 普及之前，Jarred 就已经在写出粗糙劣质的堆砌式代码（slop）。这已经不再是简单两种编程语言的优劣之争，而是开源语言创作者、头部标杆项目之间关于工程规范、项目管理、社区边界的激烈对峙。

Zig 创始人核心批评：Bun 长期透支语言、软件工程纪律严重缺失

Andrew Kelley 在文章开篇先客观描述事实，早期 Jarred 依靠 Zig 快速完成 Bun 初代版本，没有 Zig 的底层能力支撑，Bun 不可能在短时间内成型，二者早期属于深度绑定、互相成就。

但随着 Bun 商业化、团队扩张、融资增长，项目开发节奏完全向产品上线、业务增长倾斜，埋下大量无法根除的技术隐患，Zig 团队长期查看 Bun 开源代码后，对其工程实践深感担忧，核心批评分为三点：

• 代码层层堆砌，大量粗暴底层 Hack
• Bun 内部充斥补丁叠补丁的临时解决方案，无长期架构规划，滥用断言机制规避完整异常处理；为追求迭代速度，频繁跳过 Bug 修复、技术债清理环节，只优先新增功能，代码质量持续失控。
• 人为拉大社区负面舆论
  
  

在 Andrew 视角中，本次全面切换 Rust，只是把长期积累的工程问题延后，语言无法弥补团队开发节奏、代码规范的根本漏洞。

Bun 团队视角：切换 Rust 根源是内存安全瓶颈，并非否定 Zig

Jarred 在复盘里并未将项目稳定性问题全部归咎 Zig语言，清晰点明核心痛点：Bun 需要同时对接 JavaScriptCore 垃圾回收、大量 C/C++ 第三方库，叠加 Zig 手动内存管理模式，持续频发 use-after-free、双重释放、路径漏释放等底层崩溃，长期消耗大量人力用于修复同类内存故障。

选择 Rust 的核心诉求，是依靠编译器、类型系统接管资源生命周期校验，从编译阶段拦截大部分内存安全缺陷，而非单纯追求语言新潮。

同时 Jarred 完整公开了这套 AI 迁移流水线标准流程，规避单纯 AI 生成代码带来的隐患：

• 先让 Claude 输出 Zig 与 Rust 语法、生命周期映射规范文档 PORTING.md、LIFETIMES.tsv；
• 小批量 3 个文件试点转换验证逻辑，再全仓库批量迁移；
• 每一段 AI 生成代码，配备至少两名独立审查人员对抗校验，专门查找行为偏差、隐藏 Bug；
• 复用原有 TypeScript 跨语言测试套件，全覆盖回归验证，保证新旧版本行为完全对齐；
• 人工持续迭代优化迁移工作流，而非一次性生成后不再维护。
  
  

Jarred 明确表示道：其他大量 Zig 生产项目并未出现 Bun 同类高频内存故障，项目问题具备特殊性，不能等同于 Zig 语言缺陷。这也恰好回应了 Andrew 的核心质疑：更换语言不等于根治工程陋习。

关键共识：Rust 不是清除技术债万能工具

行业内不少读者容易将本次事件简化解读为 “Zig 落败、Rust 完胜”，但两套方案的实践结果证明，编程语言只能改变出错形式，无法替代架构设计、代码评审、持续测试等基础工程流程。

• Rust 的借用检查、Drop 机制可拦截绝大多数内存错误，但 FFI 交互、unsafe 代码块、抽象设计失误、业务行为回归问题，依旧依赖人为管控；
• Bun 完成迁移后，官方文档明确记录 19 处迁移引入的功能回归，均需要人工逐一修复；对抗审查过程中，也发现大量编译正常、但异步逻辑、时间戳、惰性求值场景失效的 AI 生成代码；
• AI 可以大幅提升代码产出速度，但完整工程闭环 —— 测试隔离、多人交叉评审、变更可追溯、流程持续优化，缺一不可，否则只会加速堆积新型技术债。
  
  

这场百万行 AI 迁移像一次行业大型实验：大模型能够快速完成语法层面移植，但软件稳定、可维护的底层根基，依旧依靠人制定规范、持续校验。

Hacker News 社区激烈分化：技术讨论与人身评价界限引争议

Andrew 的文章登上 Hacker News 首页，讨论迅速偏离语言技术对比，转向开源维护者该如何公开批评标杆项目，社区观点分为两大阵营。

支持 Andrew 一方认可 Andrew 对底层基础设施代码质量的担忧，Bun 作为全球广泛使用的 JS 运行时、构建工具，直接影响海量开发者，理应接受严苛工程审视；AI 批量生成百万行代码的风险值得所有人警惕。

反对 Andrew 一方以知名开发者 Theo、Zig 社区开发者 Simon Klee 为代表，认为文章掺杂大量针对创始人的个人负面评价，情绪化措辞会模糊纯粹的技术讨论，反而疏远 Zig 潜在使用者与开源贡献者，不利于语言生态长期发展。

两种观点其实并不冲突：客观质疑 Bun 迁移方案、代码风险完全合理；但将工程问题和对个人、团队文化的指责糅合在一起，容易让大众只记住 “写垃圾代码” 这类情绪化标签，忽略百万行 AI 迁移背后完整的验证、测试体系设计。

结语

1. 底层系统编程语言只能优化错误类型，但无法抵消团队激进迭代、忽视技术债带来的长期风险，无论 Zig 还是 Rust 均无例外。
2. 
   
3. AI 大规模代码迁移具备落地可行性，但必须配套多层校验、全量回归测试，单纯依靠大模型自动转换存在大量隐性故障。
4. 
   
5. 开源语言维护者、头部标杆项目存在天然利益绑定与矛盾，公开批评需要区分客观工程分析与主观人身评价，避免撕裂社区生态。
6. 
   
7. Bun 与 Zig 的分道扬镳，也给所有使用小众底层语言的大型基础设施项目提供参考：语言特性、团队工程节奏、长期稳定性需求必须互相匹配，单一变量失衡就会引发大规模重构。
8. 
   

作者：场长

引用资料：Bun 官方 AI 迁移复盘博文、Andrew Kelley《My Thoughts on the Bun Rust Rewrite》原文