三天前，Jarred Sumner 发了一篇博客，讲他用 AI Agent 把 Bun 从 Zig 重写到了 Rust。
整个重写过程只用了几天。一个 JavaScript 运行时，从一种语言到另一种语言，由一个 AI Agent 完成了绝大部分工作。
这件事的震撼之处不在于"AI 能写 Rust 了"，而在于它彻底改变了我们对"理解代码"的定义。
过去，一个开发者要理解 Bun 的代码，需要花几个月时间读源码、跟 issue、写 patch。而现在，一个 AI 能在几分钟内遍历整个代码库，生成替换方案，甚至跑通全量测试。
问题来了：当 AI 写出代码的速度远超我们阅读代码的速度时，“理解"这件事还重要吗？
〇、元问题：当写代码不再稀缺，什么才是你的护城河？
2026 年 7 月初，AI Engineer World’s Fair 在旧金山召开。300 多场演讲中，Geoffrey Litt 的一个概念引发了广泛共鸣。
他说的不是 prompt engineering，不是 tool calling，而是一个看似老生常谈的话题——“理解”。
但他说法不一样。他用的词是 Understand to participate——「理解以参与」。
Geoffrey 面对的挑战是：当 Coding Agent 开始独立完成越来越大规模的代码变更时，你的理解会不可避免地偏离代码的真实状态。这种偏差积累起来，就是认知债务（cognitive debt）。
认知债务和技术债务不一样。技术债务是代码层面的——耦合过紧、测试缺失、命名混乱。认知债务是心智层面的——你对代码的理解和代码的真实状态之间出现了裂隙。
更可怕的是，认知债务没有编译器会报错。你不会收到一个 warning 说"你对这个模块的理解已过期 3 周”。你只会在三周后试图做一个看似简单的改动时，发现整个系统已经不是你想象中的样子。
Simon Willison 在转发 Geoffrey 的演讲时补充了一个关键观察：
“你需要足够深入的理解，才能成为一个积极的创造参与者。如果脑中缺乏足够丰富的概念，你在项目中的参与度就会被实实在在地限制。”
这句话如果翻译成工程师的语言就是：AI 能替你写代码，但不能替你思考架构。
一、「读代码」从基本功变成了核心竞争力
十年前，一个高级工程师和一个初级工程师的区别之一是"读代码的速度"。
高级工程师一眼扫过去就知道这段代码在干什么、哪里有问题、改动会影响到什么。初级工程师要一行一行啃。
现在，初级工程师的 AI 助手也能"读代码"了。你把整个仓库的 context 给 Claude Code，它能立刻告诉你任何一个函数的调用链、任何一个 bug 的可能根因。
于是「读代码」这个技能被劈成了两半。
一半是 AI 能做的：快速扫描、模式匹配、依赖分析。这一半被彻底商品化了。
另一半是 AI 暂时做不了的：判断什么重要、什么不重要。
Geoffrey 的原话是：
“You need a rich set of concepts in your mind to think creatively and fluently about how to move something forward.”
翻译过来就是：你脑子里得有一套概念网络，才能创造性地思考下一步。
这不是"记住 API 文档"——AI 做这个比你强一百倍。这是"知道什么时候该质疑一个设计决策，什么时候该接受一个 tradeoff，什么时候该推翻重来"。
经验一：AI 消灭了「能不能看懂」的门槛，把竞争焦点转移到了「知不知道什么值得看」。
二、Bun 的 Zig→Rust 重写：一个教科书级的案例
回到 Bun 的故事。Jarred Sumner 在博客里写了这样一句话：
“直到最近，编程语言的选择对于一个像 Bun 这样的项目来说都是一张单程票。所有人都知道你不应该停下来、从零重写一个大型软件。Joel Spolsky 在 2000 年就说过这是最不该做的事。”
但 Coding Agent 改变了这个等式。
Bun 团队面临的困境很具体：Zig 在处理 GC 和手动内存管理混合的场景时，use-after-free、double-free、error path 中"忘了 free"的 bug 层出不穷。
Jarred 说：“我厌倦了每晚担心 Bun 崩溃才去睡觉。”
这些 bug 在安全 Rust 中直接变成编译器错误。RAII 式的 Drop 自动清理机制天然解决了资源泄漏的问题。
但真正让重写成为可能的，是一个非技术因素：Bun 的测试套件是 TypeScript 写的。
这意味着测试套件和实现语言无关。把实现从 Zig 换成 Rust，测试照样跑。这个一致性套件成了 AI Agent 的自动化验收标准——“把这段 Zig 代码翻译成 Rust，跑测试，过不了就重来。”
经验二：测试套件在 Agent 时代的角色变了——它不再只是质量守卫，而是 Agent 的「自主学习反馈信号」。
Simon Willison 在他的博客中评价这件事时，指出了另一个关键点：
Jarred 把重写当作一个实验开始的——他只是想试一下当时还很早期的 Fable 模型。“一开始我不觉得能成功。几天后，一个高比例的功能已经能跑了。”
这说明了一个很微妙的心理变化：Agent 工程的核心不再是「我能不能做」，而是「我愿不愿意试一试」。
三、认知债务的三种面相
把 Geoffrey Litt 和 Jarred Sumner 的故事放在一起看，认知债务在 AI 编程中有三种表现形式：
| 类型 | 表现 | 解决方案 |
|---|---|---|
| 理解滞后 | AI 产出一堆代码，你来不及读 | Geoffrey 的「理解以参与」——不追求看懂每一行，追求看懂架构决策 |
| 决策外包 | AI 替你选方案，你不知道为什么 | 让 AI 解释 tradeoff，而不是直接给答案 |
| 信心泡沫 | 测试全绿你就放心了 | 让 AI 做 adversarial review——从攻击者视角审视自己的代码 |
第三种是 Bun 重写中用到的一个技巧：Jarred 让一个 Agent 写代码，另一个 Agent 做 adversarial review。让 AI 互相挑战，而不是只让 AI 配合你。
这其实回到了 Geoffrey 的核心论点：理解的目的不是「看懂」，而是「能参与」。
你不需要理解每一行代码。但你必须在关键决策点上——架构选择、接口设计、错误处理策略——有能力说"这个地方不对，换一种方案"。
经验三：「看懂」是被动的，「能参与」是主动的。AI 编程的胜负手不在于你学得多快，而在于你敢不敢在关键决策点说「不」。
四、你应该做的三件事
第一，把 Code Review 的方向从"找 bug"转向"找决策"。
过去 review 代码，我们盯着潜在的空指针、边界条件、性能热点。AI 写代码之后，这些低级错误反而变少了。但真正危险的是——AI 在某个地方做了一个看似合理、实则错误的架构假设，而这个假设影响了后续所有的实现。
Claude Code 的团队在 AIE 上分享过一个建议：让 Fable 用自己的判断决定什么时候写测试，而不是告诉它"只在大功能时写测试"。同样的逻辑适用于 review——不应该 review 每一行，而应该 review 每一个架构决策。
第二，把你的测试套件设计成 Agent 的学习环境。
Bun 的 TypeScript 测试套件是一个完美的例子。它独立于实现语言，给了 Agent 一个客观的对错标准。如果你正在做一个项目，确保你的集成测试不是绑死在当前实现上的——它们应该是"行为规范"，而不是"实现快照"。
第三，定期做一次「反向理解」检查。
Geoffrey 说的认知债务的核心问题是你不知道你不知道。一个实践方法是：每隔两周，挑一个你让 AI 写的模块，不看代码，用白板画出它的架构和数据流。如果画不出来，或者画的和实际不一样——那就是认知债务的利息在滚了。
总结
| 决策 | 回答的根本问题 |
|---|---|
| 把 review 焦点从 bug 转向决策 | 理解的目的不是找错，是参与 |
| 测试套件即 Agent 学习环境 | 给 AI 的反馈信号够不够客观？ |
| 反向理解检查 | 怎么知道自己不知道？ |
| Adversarial review | 信心是不是泡沫？ |
经验三：「看懂」是被动的，「能参与」是主动的。AI 编程的胜负手不在于你学得多快，而在于你敢不敢在关键决策点说「不」。
AI 编程带来的最大变化不是一个新工具。它把软件工程中最稀缺的资源从「写代码的时间」变成了「理解代码的心智带宽」。
过去，你的生产力取决于你能写多少代码。现在，你的生产力取决于你能在多大程度上和 AI 一起思考——而思考的前提是理解。
🎯 如果你也在用 Claude Code / Codex 做日常开发，却感觉越来越不了解自己的代码——
- 📬 关注「全栈之巅 - 梦兽编程」，每周更新 AI 编程工程实践
- 🔧 访问 AI 工具导航 获取最新 AI 开发工具
参考来源：
- Geoffrey Litt, “Understand to Participate”, AI Engineer World’s Fair 2026
- Simon Willison, Understand to participate , Jul 2 2026
- Jarred Sumner, Rewriting Bun in Rust , Jul 2026