百万行 Rust 代码、11 天、16.5 万美元：Anthropic 收购后，Bun 如何用 AI 亲手「处决」了自己的 Zig 内核

引言：一条推文，判了四年心血死刑

2026 年 5 月 11 日，Bun 创始人 Jarred Sumner 在 X 上发了一条推文：

"Bun v1.3.14 将于明日发布。如果我们合并 Rust 重写版本，这将是 Zig 的最后一个版本。"

就这么一句。没有发布会，没有 changelog，没有 RFC 讨论。四年前，Bun 因为选择了 Zig——一门没有 GC、系统级性能、与 C 代码互操作极为顺畅的编程语言——而显得在整个 JavaScript 生态里特立独行、鹤立鸡群。四年后，Zig 版本被它的创造者用一条推文宣告了终结。

但真正让整个技术社区睡不着觉的，不是「换语言」这件事本身，而是这次「换语言」是怎么完成的：

• 6 天，96 万行代码
• 64 个 Claude 实例并行运行
• 4000 多次 commit，全由 AI 自动生成
• API 费用 16.5 万美元（由 Anthropic 买单）
• 最终版本通过了原有测试套件的 99.8%

这个故事里，藏着 2026 年软件开发领域最值得深思的几个命题：为什么 Zig 不行了？Rust 带来了什么？AI 写代码的边界在哪里？当一家 AI 公司收购了一个运行时项目，然后让 AI 重写这个项目，这件事对整个开源生态意味着什么？

本文将从工程视角深度拆解这次迁移的前因后果、关键技术决策、以及它对整个行业的启示。

一、背景：Bun 为何选择 Zig，又为何「背叛」Zig

1.1 Zig 的初心与 Bun 的押注

Bun 项目诞生于 2023 年，创始人 Jarred Sumner 在当时做了一个在很多人看来非常大胆的决定：不用 C++，不用 Rust，而是用 Zig 来构建一个全新的 JavaScript 运行时。

Zig 的设计哲学极具吸引力：没有隐藏控制流、没有隐藏内存分配、没有宏、没有泛型糖衣，语言本身极度克制，编译器简单透明。C/C++ 能做的事，Zig 都能做，而且做得更安全。

对于 Bun 这样需要极致性能的项目来说，Zig 的几个特性极具吸引力：

• 与 C 的零成本互操作：Bun 需要集成 JavaScriptCore 引擎（WebKit 的 JS 引擎），这部分是 C++ 代码。Zig 在这方面的互操作体验远优于 Rust，甚至优于 C++。
• 编译速度：Zig 的编译速度比 Rust 快一个数量级，对于一个需要频繁编译的项目，这能极大提升开发迭代效率。
• 无 GC 延迟：Zig 是手动内存管理，没有 GC 暂停，适合对延迟敏感的运行时场景。
• 简单透明：没有复杂的 trait 系统和生命周期，代码可读性更好。

Bun 的早期成功也部分验证了这个选择——它确实是当时最快的 JavaScript 运行时，benchmark 数据相当漂亮。

1.2 问题的种子：4700 个 Open Issues

但问题也在悄悄积累。

到 2026 年初，Bun 的 GitHub 仓库已经积累了约 4700 个 open issues。作为对比，同样「驱动整个互联网」的 Node.js，大约只有 1700 个 open issues——而 Node.js 承担着远超 Bun 的全球级别工作负载，用户规模也完全不在一个量级。

波兰数字会员系统公司 Rewardo 的 CTO Wojciech Maj 曾在一次分析中指出：

"Node.js 承担着全球级别的工作负载，却维持着更小的 backlog；而仍处于早期阶段的 Bun，却已经被问题淹没了。"

更严重的是，这些 issue 并非都是「功能请求」或「文档缺失」，其中相当大比例是内存泄漏、崩溃、未定义行为——这些问题指向 Zig 语言本身的一些根本性缺陷。

1.3 Zig 的「原罪」：内存安全的隐形代价

Zig 的设计哲学是「显式优于隐式」，但这在内存安全方面是一把双刃剑。

Zig 提供了手动内存管理的所有工具，但没有 Rust 那样强大的编译时检查。当你在 Zig 里写一个指针操作、一个 slices 切片、或一个 union 访问时，编译器不会帮你检查你是否越界、是否使用了悬空指针。这些错误会在运行时以崩溃或内存损坏的形式暴露出来。

对于一个每天处理数十亿次请求的 JavaScript 运行时来说，这类问题的调试成本极高。更要命的是，这类 bug 往往难以复现、难以定位、难以修复——它们可能在特定平台、特定并发条件下才会触发，一旦出现就只能靠经验和猜测去排查。

Jarred Sumner 本人在 2026 年 5 月接受采访时说出了那句被广泛引用的心声：

"我真的很厌倦为内存泄漏、崩溃和稳定性问题而担忧和花费大量时间进行修复。如果编程语言能提供更强大的工具来预防这些问题，那就太好了。"

这句话的潜台词很清楚：Zig 给不了这种工具，但 Rust 可以。

1.4 与 Zig 社区的裂痕

Bun 与 Zig 社区的关系，实际上在 Anthropic 收购之前就已经出现了裂痕。

Bun 团队曾经 fork 过 Zig，并在 macOS 和 Linux 上引入了 LLVM 并行代码生成，将 debug 编译速度提升了四倍。但这些优化始终无法 upstream 回 Zig 官方仓库。

其中一个关键原因，是 Zig 社区有一条极为严格的政策：禁止 AI 生成代码。

Zig 基金会成员 Loris Cro 公开表示，大量 LLM 贡献只会制造「幻觉 PR」「垃圾噪音」，以及动辄上万行、根本无法维护的提交。Zig 核心开发者对这类贡献持完全排斥态度。

但讽刺的是，Anthropic——AI 编码浪潮最激进的推动者之一——恰恰是收购 Bun 的那家公司。Zig 社区「全面封禁 AI 代码」的政策，与 Anthropic「用 AI 重写一切」的路线，形成了鲜明而荒诞的对比。

Bun 团队 fork Zig → 优化无法 upstream → 社区政策冲突 → 最终决定彻底迁移。这是技术与社区双重矛盾叠加的结果。

二、导火索：Claude Code 被 Bun 的内存泄漏坑了 14GB

2.1 Anthropic 为什么要收购 Bun？

2025 年 12 月，Anthropic 收购了 Bun。官方说法是「加速 Claude Code 能力」，本质上是让 Bun 成为 Claude Code 背后的运行时、包管理器、bundler 和测试工具。

Anthropic 将 Bun 定义为「AI 驱动软件工程的重要基础设施」。

Claude Code 负责人 Boris Cherney 曾在一次公开视频中解释了为什么选择 Bun：

"我们当初在开发 Claude Code 时，评估了很多运行时方案，Bun 几乎是毫无悬念的胜者。它的启动时间大概只有 3 毫秒，而 Python 要慢 15 倍左右。对于 CLI 工具来说，这意味着用户体验是『丝滑响应』，还是『明显卡顿』。"

但问题随之而来：Claude Code 是以 Bun 可执行文件的形式发布的。当你安装 Claude Code 时，你实际上也在运行 Bun。这并非简单的合作关系，而是紧密的深度依赖。

2.2 内存泄漏：Claude Code 的噩梦

2026 年 3 月，一个编号 #33453 的 Issue 被提交到 Claude Code 仓库：

"Claude Code 的主进程表现出严重的内存泄漏，RSS 内存在约 3 小时的短会话中从约 1.7GB 增长到 14GB 以上。泄漏位于 Bun 运行时的 WebKit Malloc 分配器中，而非用户空间的 JavaScript 分配。"

另一个 Issue #11377 记录得更夸张：运行 14 小时后，Claude Code 进程占用 23GB 虚拟内存，143.8% CPU，系统完全卡死。

罪魁祸首直指 Bun 的 WebKit Malloc——这是 Bun 使用的底层内存分配器，JavaScript 引擎层的问题直接拖累了 Claude Code 的稳定性。

这下问题就尴尬了：Claude Code 是 Anthropic 的核心产品，而 Claude Code 深度依赖的 Bun 运行时，却把 Claude Code 拖入了内存泄漏的泥潭。

2.3 一个荒诞的循环

事后复盘，整个局面形成了一个非常荒诞的循环：

1. Anthropic 开发 Claude Code，选择 Bun 作为运行时
2. Bun 的内存泄漏影响 Claude Code 的稳定性
3. Anthropic 收购 Bun
4. Anthropic 让 Claude agent 重写 Bun
5. 重写后的 Bun 继续支撑 Claude Code

用社区里一位开发者的话说："Claude Code 被 Bun 的内存泄漏坑惨了；然后 Anthropic 让 Claude 去重写 Bun；最后 Bun 再继续回头支撑 Claude Code。"

这个循环不仅是技术问题，也是商业问题。Anthropic 意识到，如果不从根本上解决 Bun 的稳定性问题，Claude Code 的口碑会持续受损。

三、迁移策略：一份 576 行的「宪法」，AI 按规矩办事

3.1 PORTING.md：不是随便重写，有规矩才行

当决定用 Rust 重写 Bun 之后，Jarred Sumner 没有让 AI「随便写」。他首先创建了一份长达 576 行的 PORTING.md 文档，这份文档相当于整个迁移项目的「宪法」。

核心策略是分两阶段执行：

Phase A：Claude 逐文件忠实保留 Zig 的逻辑，即使 Rust 代码暂时不能编译也没关系。这个阶段的目标是「语义等价」，而不是「编译通过」。

Phase B：逐个 crate 解决编译错误、构建问题和运行时问题。

文档里还有大量具体的工程规范：

• 文件命名：Rust 文件的命名必须与 Zig 文件一一对应，方便后续比对和审查
• Crate 引用：明确了各模块的依赖关系和包边界
• 禁止使用 tokio/rayon/hyper/futures：这是一个非常有意思的限制——意味着重写时不能引入大型异步生态，避免引入新的复杂性
• 禁止 async fn：运行时层面不使用 async/await 语法，保持同步模型
• unsafe 必须写 SAFETY 注释：每个 unsafe 块必须附带安全性的严格论证
• 遇到不确定逻辑时宁可留下 TODO，也不让 AI 自行猜测：宁可代码不完整，也不要 AI 自行「脑补」行为

这种「先翻译、再优化」的两阶段策略，非常类似人类工程师在处理大规模代码迁移时的惯用手法。Jarred 把这种工程经验系统化地写进了 AI 的指令里。

3.2 迁移的技术挑战：Tagged Pointer 的 Rust 化

整个迁移过程中，最棘手的技术问题之一是 tagged pointer 的处理。

Zig 版本中，Bun 大量使用 tagged pointer（标记指针）来处理 event loop task、进程退出回调、非阻塞文件 I/O 等底层接口。Tagged pointer 是一种将额外信息编码进指针本身的技巧——例如，在指针的低位 bit 存储一个 tag，表示这个指针实际上是一个不同类型的数据。

Zig 的内存模型和 Rust 的借用检查器对这类技巧的处理方式差异很大。在 Rust 中，如果直接用 trait 或函数指针来替代 tagged pointer，可能会引入额外的运行时开销。

Jarred 曾在 X 上公开向 Rust 社区请教：「有没有一种既不影响性能、又更适合 Rust 的 tagged pointer 实现方式？」

这个问题实际上反映了系统级语言在处理低级抽象时的根本差异：Zig 的「显式控制」哲学让这类优化更容易实现，而 Rust 的「安全抽象」要求则需要更多的设计权衡。

3.3 六天的进度日志

以下是这次迁移的实际进度时间线：

Day 1（5月5日）：GitHub 仓库出现 claude/phase-a-port 分支，数十万行 AI 生成的 Rust 代码与原始 Zig 实现并排存在。同一天，Jarred 在 Hacker News 上发帖，称这是「一堆根本还跑不起来的代码」，并估计「最后被全部扔掉的概率非常高」。

Day 3（5月7日）：Jarred 发推称，迁移已涉及约 4000 次 commit、96 万行代码，当时只剩下 3 个编译错误。Rust 版本已经可以显示 help menu，bun run 和 package.json scripts 也能跑起来——这意味着 JSON parser、AST、logger、module resolver、文件系统遍历等一整串基础能力都已经被迁过去了。

Jarred 还发了一句标志性的话："JavaScript runtime runs JavaScript."

Day 5（5月9日）：Rust 重写版本在 Linux x64 glibc 环境下通过了 Bun 既有测试套件的 99.8%。

Day 6（5月10日）：Jarred 发推宣布合并，Zig 版本宣告终结。

Day 11（5月14日）：Bun v1.4.0 正式发布（Canary 渠道），包含 6755 个 commit，修复了 128 个 bug，性能提升约 2%-5%，二进制体积缩小 3-8 MB。

四、架构分析：Rust 版 Bun 继承了哪些设计哲学？

4.1 「相同架构，不同语言」

Jarred 在合并公告中反复强调了一个核心原则：Rust 版本保持了与 Zig 版本相同的架构设计，相同的数据结构。

这不是一次架构重构，而是一次语言迁移。Bun 的核心设计——JavaScriptCore 引擎集成、事件循环模型、包管理器、bundler、测试工具——全部保留，只是底层实现语言从 Zig 换成了 Rust。

这种「平移」策略的好处是显而易见的：

• 风险可控：不会同时引入架构变化和语言变化两种风险
• 行为一致：测试套件可以直接复用，99.8% 的通过率证明了迁移质量
• 可对比性：性能数据可以直接与 Zig 版本对比，排除架构因素的干扰

4.2 依然不用 tokio：为什么 Bun 坚持同步模型

在这次迁移中，一个非常有意思的决策是：依然不引入 tokio、rayon、hyper、futures 等大型异步生态。

Bun 的事件循环本身就是异步的（基于 libuv），但 Rust 版本的 Bun 依然采用同步编程模型，在 Rust 层不使用 async/await。

这个决策背后有几层考量：

运行时嵌套问题：Bun 内部嵌入了 JavaScriptCore 引擎，而 JS 引擎本身有自己的事件循环。如果 Rust 层引入 tokio 等异步运行时，就会面临两个事件循环嵌套的复杂性——这与 Node.js 早年面临的 libuv + V8 嵌套问题如出一辙。

性能优先：对于极致性能要求的场景，同步代码的调度开销为零，更容易做出精确的性能预测。

工程复杂度：引入 tokio 意味着引入一套新的错误处理模型、新的并发原语、新的调试工具链，对于一个正在做语言迁移的项目来说，这些都是额外的认知负担。

4.3 unsafe 的代价：13,000 个 unsafe 说明了什么？

迁移完成后，开发者社区最大的质疑来自 t3.gg 创始人 Theo。他在 X 上指出：

"uv（另一个 Rust 项目）包含 35 万行 Rust 代码，以及 73 个 unsafe 调用。Bun Rust 移植版已经有 68.1 万行 Rust 代码，并且有超过 13,000 个 unsafe 调用。"

73 vs 13,000，差了接近 180 倍。

Jarred 几乎立刻回应：

"今天已经下降了大约 2000。我预计它会稳定在 1 万左右，因为 Bun 的大部分内容都是用 C 和 C++ 编写的，这种情况不会改变。"

从技术角度看，这个对比确实不完全公平。uv 是一个相对纯粹的 Rust 项目，而 Bun 需要与大量底层 C/C++ 代码打交道——文件系统、网络、JavaScript 引擎集成，这些都绕不开 unsafe。

但网友的担忧并非没有道理：unsafe 意味着编译器无法检查内存安全，1 万个 unsafe 就是 1 万个潜在的事故隐患点。

这个数字最终稳定在什么水平，将是衡量这次迁移是否真正成功的重要指标之一。

五、社区争议：AI 重写代码的质量与流程

5.1 「vibecoded disaster」：社区的主要批评

当 Bun 的 Rust 重写完成后，社区反馈呈现出两极分化的态势。

批评者的核心论点是「流程问题」：

• "uv 的代码是由真正的开发人员编写的，每一行都经过了审查。Bun Rust 由 Agents 编写，由 Agents 审核，并由 Agents 批准和合并。"
• "完全在意料之中的结果。"
• "uv 不是 vibecoded 的垃圾，而且开发它的人对 Rust 非常了解。但 Bun 就完全不同了，它简直是一场风格灾难。用 Deno 吧。"

「vibecoded disaster」（AI 随手生成的灾难）这个词精准地刺中了许多人的不安：六天、96 万行、AI 生成、AI 测试，最后带着 1 万个 unsafe 直接合并——这在传统软件工程里是完全无法想象的流程。

支持者的论点则是「结果说话」：

• 99.8% 的测试通过率
• 128 个 bug 被修复
• 性能提升 2-5%
• 二进制体积缩小 3-8 MB
• 多个长期悬而未决的内存泄漏问题被彻底解决

5.2 Jarred 的回应：「没人逼我这么做」

面对「Anthropic 强迫 Bun 重写」的猜测，Jarred 亲自下场否认：

"没人逼我这么做。我只是很好奇：一个真正可运行的版本到底会是什么样、用起来感觉如何、性能如何，以及让它通过 Bun 的测试套件、并真正变得可维护，到底会有多难。"

他还透露，Anthropic 收购 Bun 是在 2025 年 12 月，而他决定用 Rust 重写是在 2026 年 5 月——中间有五个月的时间差，说明这个决定并非收购的附产物，而是团队在评估了所有选项之后的主动选择。

5.3 AI 重写 vs. 人工重写：效率对比

Jarred 本人给出了一个令人震惊的数据：

• 2020 年手工移植 esbuild（Go → 其他语言）：花了三周
• 2026 年用 Claude 迁移 Bun（Zig → Rust）：6 天

这个对比揭示了一个重要的趋势：对于大规模代码迁移类任务，AI 的效率已经远超人类。

但「快」不等于「好」。关键问题是：AI 迁移的代码，可维护性如何？长期稳定性如何？这些问题需要时间来回答。

六、性能与稳定性：数字告诉我们什么？

6.1 v1.4.0 性能数据

Bun v1.4.0（Rust 版 Canary）的官方性能数据：

2%-5% 的性能提升初看之下不算惊艳，但考虑到这是「第一天」的迁移版本——代码从 Zig 翻译成 Rust，架构完全没有优化——这个数据其实是相当正面的。

6.2 内存泄漏修复：这次是来真的吗？

最关键的问题是：Rust 版 Bun 是否真的解决了内存泄漏问题？

从 v1.4.0 的 changelog 来看，多个长期内存泄漏问题被列为已修复。社区的一些早期测试也报告了正面结果。

但真正有说服力的数据，需要等 Canary 频道积累足够的生产环境使用量之后才能得出。从历史经验看，大型语言迁移后的稳定性验证通常需要 3-6 个月的持续观察。

6.3 多平台支持：迁移的完整性

值得注意的是：目前 Rust 版本的测试覆盖主要集中在 Linux x64 glibc 环境。macOS 和 Windows 的支持程度尚未完全达到 Zig 版本的水平。

这对于 Bun 的用户群体来说是一个现实挑战——Bun 的很大一部分用户是 macOS 开发者。如果 Rust 版本在这些平台上的稳定性不如 Linux，可能会影响用户升级意愿。

七、AI 重写软件的大趋势：Bun 只是个开始

7.1 不仅是 Bun：多个项目正在被 AI 重写

Bun 的案例并非孤例。类似的 AI 驱动极限重写正在多个领域同时发生：

• Cloudflare：在一周内借助 AI 重新实现了 Next.js API 的大部分能力
• Ladybird 浏览器：在两周内将 JavaScript 引擎从 C++ 迁移到 Rust
• 多个 VC 支持的开源项目：正在建立类似的「AI 重写 pipeline」

Jarred Sumner 本人在 2026 年 5 月初发过一条推文：

"这种 pipeline，任何 VC 支持的 OSS 或者有大量 GitHub issues 的公司都能搭建。更普遍地说，它可以用于自动修复用户报告的 bug。"

更早之前，他甚至预言过：

"我预计开源软件会走向完全相反的方向——未来甚至可能变成『禁止人类贡献代码』。人类依然会负责讨论问题、决定优先级，但真正写代码、提交 PR、回复和处理反馈、完成实现的工作，最终都会由 LLM 来完成。"

Bun 的这次重写，正是这句话的第一次大规模公开演练。

7.2 速度 vs. 信任：工程的永恒张力

Bun 案例暴露了 AI 重写代码最核心的矛盾：

速度上去了，信任怎么建立？

传统软件工程建立信任的方式是：人工代码审查 → CI/CD 测试 → 生产环境灰度 → 社区反馈循环。每一步都需要人类参与，每个环节都有明确的问责链条。

但 AI 重写的代码，代码审查这一环消失了——因为审查代码的也是 AI。当「写代码的是 AI，审代码的也是 AI，合并代码的还是 AI」时，传统的质量保证链条彻底断裂。

社区对 Bun 的质疑，本质上是对这种新范式的信任焦虑。

7.3 对开源生态的深层影响

Bun 案例对开源生态的深层影响，可能比我们想象的更大：

上游 vs. Fork 的博弈：Bun 曾经 fork Zig 并做了大量优化，但因为社区政策冲突无法 upstream。Rust 版本会重蹈覆辙吗？还是说 Rust 社区会更包容？

开源许可的新问题：当代码全由 AI 生成，版权归属如何认定？训练数据来源是否合规？这些在法律层面尚无定论的问题，正在悄悄逼近开源社区。

「有钱任性」的工程模式：16.5 万美元的 API 费用，对大多数开源项目来说是天文数字。当 AI 重写变成了「烧钱游戏」，开源社区的公平性如何保障？

八、程序员的视角：我们应该从这次事件中学到什么

8.1 系统语言选型的新思考

Bun 从 Zig 迁移到 Rust，给我们提供了一个难得的对比案例——同一个项目，在两种系统级语言下的表现如何。

Zig 的优势：编译速度快、与 C 代码互操作极顺畅、语言设计哲学极简。对于编译器工具链、嵌入式系统、操作系统内核这类场景，Zig 依然是极好的选择。

Rust 的优势：编译时内存安全保证、强大的类型系统、活跃的生态、优秀的工具链（cargo、rustfmt、clippy）。对于长期维护、生产级基础设施类项目，Rust 的「前期投入」在后期会获得丰厚回报。

关键教训：没有最好的语言，只有最适合场景的语言。Bun 的 Zig 版本积累了 4700 个 open issues，很大程度上是因为 Zig 的特性与「长期维护一个生产级 JavaScript 运行时」这个需求之间，存在系统性错配。

8.2 AI 时代程序员的不可替代性

Bun 的案例告诉我们，在「代码翻译」这件事上，AI 的效率已经远超人类。但在以下几个维度，人类工程师的价值反而更加凸显：

系统设计：AI 可以翻译代码，但很难凭空设计出一个好的系统架构。Bun 选择保留原有架构，是人类工程师的决策。

工程规范：PORTING.md 里那 576 行规范，是人类工程师经验的结晶。没有这些规范，AI 的翻译质量会大打折扣。

信任建立：最终决定合并代码的，依然是 Jarred Sumner 本人。人类在决策链条中扮演的角色，从「写代码」变成了「决策和把关」。

长期维护：迁移完成后的优化、bug 修复、平台适配，依然需要人类工程师的深度参与。

换句话说，AI 接管了「搬砖」，人类负责「设计图纸和验收」。这对程序员的能力模型提出了新的要求：更强的系统设计能力、更强的工程质量意识、更强的代码审查能力——而不是更快地写代码。

8.3 面对 AI 重写浪潮，团队应该做什么

如果你的团队正在考虑用 AI 重写某个模块，以下是 Bun 案例提供的几个可操作的经验：

第一，制定详细的迁移规范。不要让 AI 随便写。PORTING.md 模式值得借鉴：明确「先语义等价、再优化」的两阶段策略；规定 unsafe 使用规范；设置明确的边界和禁区。

第二，保留原有测试套件。Bun 的 99.8% 测试通过率，是建立在完整测试套件的基础上的。如果你的项目没有足够的测试，重写的质量将无从验证。

第三，设置明确的合并门槛。比如测试通过率 ≥ 99%、性能无显著退化、unsafe 数量在预期范围内。只有达到这些门槛，才考虑合并。

第四，计划后续优化阶段。语言迁移只是第一步，后续的性能优化、代码重构、平台适配同样重要。不要把迁移当成终点。

九、总结：这是一次实验，也是一个信号

Bun 从 Zig 到 Rust 的迁移，是 2026 年软件工程领域最引人注目的事件之一。

从技术角度看，这是一场成功的迁移：6 天完成、99.8% 测试通过、128 个 bug 修复、性能小幅提升。但它也暴露了 AI 重写代码的典型问题：unsafe 泛滥、代码质量争议、流程缺乏人类审查。

从行业角度看，这更像是一个信号：AI 接管大规模代码迁移的时代，已经正式到来。以后当你的 CTO 说「我们要把代码库从 X 语言重写成 Y 语言」时，他不会再问「需要几个月」，而是会问「Claude 需要几天」。

速度上天的时代，信任只能自己想办法落地。

对于程序员来说，这个故事的启示既不是「AI 无所不能」，也不是「AI 写的代码不能用」——而是：在 AI 越来越擅长执行的同时，人类的系统设计能力、工程判断力和质量把关能力，正在变得比以前任何时候都更重要。

Jarred Sumner 在合并 Rust 版本的公告里说了一句话，我觉得值得所有程序员记住：

"我真的很厌倦为内存泄漏、崩溃和稳定性问题而担忧。如果编程语言能提供更强大的工具来预防这些问题，那就太好了。"

Rust 提供了这样的工具，但代价是更陡峭的学习曲线和更复杂的类型系统。Zig 更容易上手，但在长期维护中会积累难以解决的技术债。

没有免费的午餐，只有适合的选择。 这句话在任何时代都不过时。