等待机器逐字稿

你保存了一个文件。

然后看向浏览器。

没有变化。

你又看回终端。那里有几行日志，光标停着，像是机器正在想事。 你知道这不是很久。也许十秒，也许三十秒，也许四十五秒。

从钟表上看，当然不久。

但从注意力上看，已经够久了。

够你切到另一个窗口。够你看一眼 Hacker News。够你打开 Twitter。够你突然想起一封没回的消息。也够你忘掉，刚才为什么要改那一行代码。

软件开发里有很多宏大的词：架构、性能、生态、平台、语言选择。但有时候，一个工具真正诞生的地方，不是白板，也不是论文。

而是这个很小的空白：保存文件之后，等它生效的那几秒。

这一期我们讲 Bun。

但不是从“Bun 是什么”开始。

我们从等待开始。

今天，一个程序员抱怨热更新慢，听起来几乎有点奢侈。

毕竟，大多数时候，我们只是坐在屏幕前等几秒。屏幕亮着。键盘在手边。机器就在桌上。等待被压缩成一个进度条，一个 spinner，或者终端里一行还没有结束的日志。

可是如果把镜头往后拉，这几秒背后，有一条很长的历史。

早期写程序，并不是打开编辑器、输入代码、回车运行。程序可能要先变成机器能读的介质。纸带，或者一叠打孔卡。每一张卡片上，孔洞的位置代表信息。

你把这些介质交出去，让机器读，让作业排队，让结果再回到你手里。

一个错误，不只是改一行代码。它可能意味着重新打孔，重新排队，重新提交作业，然后再等机器回答一次。

这是一种很远的反馈回路。

人在这头，机器在那头。中间隔着介质、机房、队列、操作员、输出纸。程序员的思路要在等待里保持完整。你不能随手试一下。

你要先在脑子里把很多事想对，因为机器不会马上告诉你错在哪里。

后来，人们不想再直接和数字地址、操作码打交道。于是有了汇编器。

汇编器的意义，不只是让代码看起来好一点。它把一部分机械翻译交给机器。人写助记符，机器把它变成更靠近硬件的指令。

再后来，高级语言和编译器继续把人的意图往上抬。Fortran 这样的语言，把数学和工程里的表达，翻译成机器能够运行的代码。

这里有一个很朴素、也很深的变化：程序员不再把全部精力花在“机器到底要哪个数字”上，而是能多花一点精力在“我到底想让它做什么”上。

每往上走一层，等待并不会消失。编译也要等。运行也要等。错误也还会回来。

但等待的形状开始变了。

它不再只是“我把作业交出去，等别人和机器处理完”。它慢慢变成“我写下更接近人类意图的东西，再等机器替我翻译和确认”。

然后是分时系统和交互式终端。

这一步很关键。

一台昂贵的大机器，仍然不是每个人桌上的个人电脑。但多个用户可以通过终端同时使用它。对用户来说，机器好像被拉近了。

不是你把一叠卡片交出去，等结果回来。而是你坐在终端前，输入一行，等待屏幕回你一行。

等待还在。

但它开始有了对话的样子。

再往后，解释器、R E P L、shell、脚本语言，把这种对话变得越来越日常。

你输入一小段，按下回车，机器马上回一句。你看结果，再输入下一句。编程不再只是提前写好一大块计划，交给机器一次性判决。

它也可以是试、看、改、再试。

这改变的不只是速度。它改变了思考方式。

当反馈很远，人会倾向于提前设计，谨慎提交，尽量一次做对。

当反馈很近，人会倾向于探索、试探，从机器的回应里继续想。

所以开发工具的历史，很大一部分就是在压缩一个距离：从“我改了一点东西”，到“我知道它有没有工作”。

到了前端开发，这个距离又被压得更短。watch mode、dev server、hot reload、Hot Module Replacement。这些词听起来很工具化，但它们保护的是同一个东西：

开发者脑子里还没散掉的上下文。

你正在改一个按钮。你知道它为什么错。你知道改完应该看哪里。只要反馈马上回来，你就能沿着那条思路走下去。

可是一旦等太久，思路就会散。

你会看别的窗口。你会读通知。你会忘记刚才那个小小的假设。

所以，几十年后，一个前端开发者看着 Next 点 J S 的热更新等待四十五秒，这件事并不孤立。

它是一个老问题的新版本。

机器太慢。

反馈太远。

人的注意力在中间断掉。

Jarred Sumner 一开始并不是要做一个 JavaScript runtime。

他在做一个浏览器里的 voxel game。

你可以暂时把它想象成一种由许多小方块组成的游戏世界。重点不在游戏类型，而在那种很熟悉的创作状态：你脑子里有一个东西，你想把它做出来。

你改一点代码，看一下世界有没有按你想的方式变化。你再改一点，再看一下。

这本来应该是一种很短的循环。

可是项目变大以后，循环被拉长了。

根据 Bun 官方后来的回顾，也根据 Jarred 在播客和访谈里的说法，他遇到的不是一个抽象的行业问题，而是一个很具体的日常问题：

改一点东西，要等太久才能看到结果。

官方回顾里，那个等待被写成四十五秒。InfoWorld 访谈里也有相近的说法：保存以后到浏览器里看到变化，足够让人本能地去看 Hacker News。

这就是本期故事真正的入口。

不是“JavaScript 世界需要一个新的 runtime”。

而是一个人想做一个作品，结果先被工具链拦住了。

这段话重要的地方，不在于它解释了 Bun 的产品定位，而在于它保留了一个事故现场。

Jarred 想做游戏。

游戏变大。

Next 点 J S 的开发循环变慢。

他先去修 build tools。

为了让构建更快，他看向 esbuild。为了服务 Next 点 J S 的 server-side rendering，他又需要一个 runtime。runtime 又牵出 JavaScript engine、Node 兼容、npm 包、transpiler、bundler、test runner。

一开始，工具只是路上的石头。

后来，石头越来越多。

他开始铺路。

铺着铺着，路变成了作品。

这就是 Bun 故事里最有意思的地方。

它不是先有一个宏大商业计划，说我要重做 JavaScript 世界。它更像一个被等待一路推出来的东西。

等待把注意力撕开。为了把这个裂口缝上，Jarred 开始把一个又一个工具链环节吞进同一个项目里。

原来的游戏退到背景里。

工具自己站到了前景。

如果只用一句很干的产品描述，Bun 是一个 JavaScript 和 TypeScript 工具链。

它包括 runtime、bundler、transpiler、package manager、test runner，还有 script runner。

这个列表可以拆开听。

runtime，是代码真正跑起来的地方。它负责执行 JavaScript，也负责接住文件、网络、定时器、进程这些运行时能力。

bundler，是把散在各处的模块和依赖打包到一起。transpiler，是把 TypeScript、J S X，或者较新的 JavaScript 语法，转换成目标环境更容易执行的 JavaScript。

package manager，负责下载、安装和锁定依赖。test runner，负责找到测试、运行测试、告诉你哪里失败。script runner，则负责执行项目里那些 start、build、test 一类脚本命令。

但就算拆开解释，这也还是太干了。它像一张官网功能表。听完以后，你知道 Bun 有什么，却不知道为什么它会长成这样。

更准确的说法也许是：

Bun 试图把现代 JavaScript 开发里很多让人等待的地方，压进一个二进制里。

想象一个普通的开发循环。

你 clone 一个项目。先安装依赖。

继续等待。

你跑一个脚本。Node 启动，包管理器介入，环境变量加载。

继续等待。

你写 TypeScript，写 J S X。它们要被转换成浏览器或者 runtime 能理解的 JavaScript。

继续等待。

你启动 dev server。它扫描文件，建立依赖图，监听变化。

继续等待。

你改一个模块。开发服务器重新处理，浏览器更新。

继续等待。

你跑测试。

继续等待。

你打包，压缩，分发。

再等。

在 Node 生态里，这些环节往往由不同工具接力完成。npm 或 pnpm 安装依赖。T S C、Babel、swc、esbuild 处理语言转换。

webpack、Rollup、Vite 管打包和 dev server。Jest、Vitest 跑测试。Node 负责 runtime。

它们各自强大，也各自有自己的配置、进程、缓存、边界和等待点。

Bun 的姿态，是把这些接力尽量收束起来。

不是每个概念都重新发明。而是减少工具之间的交接。

少启动几个进程。少穿过几层配置。少在不同工具之间传递上下文。少让开发者在一个问题还没想完的时候，被另一个工具的日志打断。

这里有两个技术选择值得停一下。

第一个是 JavaScript Core。

Node 使用 V 八，也就是 Chrome 背后的 JavaScript engine。Bun 没有选择 V 八，而是选择 JavaScript Core，也就是 WebKit 里的 JavaScript engine。

这个选择让 Bun 在启动成本、嵌入方式和运行时设计上，走了一条不同的路。

这不是给听众补一个引擎百科。

它只是说明：Bun 从一开始就不是给 Node 打一个小补丁。它在更底层的位置重新选择了一遍。

第二个是 Zig。

Bun 早期大量使用 Zig。Zig 的叙事里有一种很强的控制感：少一点隐藏成本，少一点不透明抽象，更多事情在编译期解决。

Jarred 在早期访谈里也讲过，他曾经短暂考虑过 Rust，但当时在生产力、编译期能力和写代码的流畅度上，Zig 对他更合适。

这段很重要。

因为几年后，当 Bun 转向 Rust，它会形成一个强烈的回声。

但在二零二二年，Zig 对 Bun 的意义，不是一场语言信仰。

它是一个工具诞生初期的手感。

Jarred 想要快，想要控制，想要少等，想要把自己和机器之间那些看不见的中间层尽量拿掉。

所以 Bun 的“快”，不只是 benchmark 上一个更漂亮的数字。

它对应的是一种开发体验：

少开几个进程。

少接几段管道。

少等几个中间工具。

少把注意力交给工具链里看不见的缝。

Bun 后来还有一个很适合声音节目想象的能力：single-file executable。用 Bun 的文档语言说，它可以把入口、依赖和 Bun runtime，打成一个独立可执行文件。

这件事在这里先不急着讲 Claude Code。

我们先把它当成一个形象：

一整套工具链，被压成一个可以分发、可以移动、可以双击或运行的物件。

复杂性没有消失。

它被包进去了。

而当复杂性被包进一个更好用的物件里，它也会更快地被更多人拿起来。

故事到这里，还只是第一层。

因为工具越快被人看见，越快被人使用，它也越快从一个人的解法，变成很多人的问题集合。

二零二二年七月，Bun public beta 发布。

Hacker News 上的首波讨论很热。

根据当时讨论页的记录，那条 launch thread 有一千四百三十一 points，三百一十四 comments。官方后来的回顾说，发布第一周，Bun 达到两万 GitHub stars。

第三方 O S S Insight 的日级累计数据也显示，二零二二年七月十日接近两万，七月十一日超过两点二万。

这里要很小心。

stars 不是采用。

H N 热度也不是采用。

它们证明的是注意力。

注意力当然重要。没有注意力，一个新工具没有机会进入别人电脑。但注意力只是一道光。真正有意思的是，这道光很快照出了别的东西。

发布后第一周，GitHub 上新建了二百九十二个 issues，一百四十四个 P R。

到二零二六年七月二日回看，这批第一周 P R 中，有一百零四个最终被合并。issues 中大多数也已经关闭。

这说明什么？

不是说明 Bun 一夜之间被所有人用于生产。

不是。

二零二二年八月的外部报道还明确说，当时 Bun 离 production-ready 很远。

它说明的是另一件事：围观者开始动手了。

有人 clone。

有人 install。

有人跑 examples。

有人撞到 Windows 问题、Node A P I 兼容问题、点 npmrc 问题、timer 问题、bun add 问题、文档问题、模板问题。

接下来，是几条早期 issue 和 P R 标题。

setTimeout runs inconsistently.

setInterval takes one hundred percent C P U usage.

path 点 win 三十二 点 parse gives incorrect data.

Support reading from 点 npmrc.

bun add throwing JSON Lexer bug.

fs 点 stat returns native code instead of a Stats object.

Node 点 J S child process compatibility.

Make bun docs searchable and easy to navigate.

fix benchmark 链接 on landing page.

Fix Hono example template.

这些标题没有一个像发布视频里的口号。

它们很碎。

甚至有点无聊。

但正是这种无聊，说明一个工具真的被人拿起来了。

发布稿说：快。

用户说：我的 setTimeout 不稳定。

官网说：all in one。

用户说：点 npmrc 能不能读。

作者说：新的 runtime。

用户说：path 点 win 三十二 点 parse 不对。

这不是打脸。

这是开源工具从演示进入现实的那一刻。

stars 是掌声。

issues 是试用者撞到的墙。

P R 是围观者把手伸进机器。

一个工具原本是为了替别人省时间，现在开始吸进别人的时间，也吸进维护者自己的时间。

用户等待修复。

维护者等待复现。

P R 等待 review。

C I 等待通过。

一个为了缩短等待而生的工具，开始长出自己的等待队列。

二零二二年七月二十日，Bun 有一个公开的 priorities issue。

标题很直接：Bun's priorities。

它把 stability 和 Node 点 J S compatibility 放在最前面。Bun should not segfault。bun install should work reliably。bun run should not crash。bun dev should not freeze or crash。

Node 点 J S compatibility 还有太多 missing function 和 underperform 的地方。

这很关键。

因为这说明，社区最初的疑虑没有停留在评论区。

稳定性、兼容性、安装可靠性，这些问题很快进入了项目自己的维护语言里。

一个工具要想结束等待，首先要学会处理等待它的人。

这时可以问一个很自然的问题：

如果 Node 已经存在这么多年，npm、esbuild、Vite、pnpm 这些工具也都在，为什么还需要重做一套？

为什么不是让 Node 更快一点？

这个问题，会成为全期的一个回声点。

因为二零二二年，Jarred 面对的是 Node 和 JavaScript 工具链：要更快，好像就要重写很多东西。

到了二零二六年，Bun 自己也被重写。

这不是讽刺。

或者说，不只是讽刺。

它更像软件工程里非常常见的循环：

今天的新工具，明天会变成别人的兼容对象。

今天的重写，明天会变成新的遗产代码。

今天你为了逃离一个系统而造出另一个系统，几年后，别人又要在你的系统上处理兼容、迁移、测试、release、文档、用户习惯。

轮子不是被造出来就停在那里。

轮子会转。

转久了，它会带上别人的重量。

二零二五年底，Bun 宣布加入 Anthropic。

第二天，Anthropic 也发布了收购新闻稿，把这件事放进 Claude Code 的增长叙事里。

这不是一个普通的“开源工具被公司收购”的节点。

它改变了 Bun 的角色。

在最初的故事里，Bun 是给人类开发者省时间的工具。

你安装依赖更快，运行脚本更快，开发服务器更快，打包更快。快的对象，是坐在屏幕前的人。

这个人会等。

会分心。

会被一个构建卡住。

会在几十秒里失去刚才的上下文。

但在 Anthropic 的叙事里，Bun 进入了 AI coding infrastructure。

Bun 官方博客说，Claude Code 以 Bun executable 的形式分发给大量用户。Anthropic 的新闻稿也把 Bun 放进 Claude Code 的增长和基础设施扩展里。

这时，Bun 不再只是一个人类开发者本地装的快工具。

它开始像某种底座。

Claude Code 的安装链条很适合成为这一段的物证。

根据 Claude Code setup docs，官方推荐的是 native install。通过 npm 安装时，安装的也是同一个 native binary。

平台 binary 通过 optional dependency 和 postinstall 放置。安装后的 claude binary 本身不调用 Node。

这里必须拆开说。

我们不能说 Claude 官方文档证明这个 binary 是由 bun build compile 生成的。现有证据还不够。

我们能说的是两段事实。

第一，Bun 官方明确把 Claude Code 和 Bun executable 联系起来。

第二，Claude Code 官方文档显示，它的用户安装体验已经从传统 Node 脚本启动，转向 native binary。

这两段事实合在一起，说明 Bun 已经不只是一个开发者本地工具。

它开始进入 AI coding tool 的分发层、执行层、基础设施层。

而当工具的使用者从人变成 agent，“快”的含义也变了。

人类开发者等四十五秒，可能会分心。

AI agent 不会以人的方式分心。

它不会无聊到打开 Hacker News。

它不会突然想起一封没回的消息。

可是它会放大另一种东西：

运行次数。

测试次数。

安装次数。

修复次数。

P R 数量。

C I 成本。

review 压力。

在拉取下来的二零二六年七月二日的 GitHub 队列调查里，Bun 主仓库有五千一百三十个 open issues，一千七百零六个 open P R。

近三十天里，issues 新增三百六十七个，关闭二百九十个。P R 新增一千一百九十九个，合并三百六十四个，未合并关闭九百七十三个。

open P R 里有很大一批带着 claude label。

这些数字必须小心。

它们是一个时间点的快照，不是永久状态。

claude label 也不能单独证明这些 P R 都由 Claude Code 生成，更不能说明质量。

但它们可以作为一个可见痕迹：

AI coding 的生产力，已经不是一个抽象口号。它会以 P R、C I、review、label、关闭理由、长期队列的方式，进入开源项目的日常维护流。

过去是人等工具。

后来是工具帮人少等。

现在，工具要承受 agent 生成出来的更多工作。

等待者换了。

等待没有消失。

然后，故事出现了最戏剧化的一幕。

二零二六年五月八日，Jarred Sumner 创建了一个 P R。

标题很短：

Rewrite Bun in Rust。

五月十四日，这个 P R 合并。

P R 元数据显示：六千七百五十五个 commits，二千一百八十八个 changed files，超过一百万(hang2) additions。

这个数字很容易让人想把它当成奇观。

百万(hang2)。

六千多个 commit。

两千多个文件。

一个以 Zig 出圈的 runtime，几天之间在 GitHub P R 页面上变成 Rust。

但如果只把它当成奇观，反而会错过重点。

重点不是“哇，一百万(hang2)”。

重点是，一个为了压缩等待而生的工具，几年后自己变成了需要被迁移、被审查、被重新信任的巨大系统。

P R body 里给出的理由，不是一个简单的“Rust 更快”。

它说通过了 Bun 原有测试套件。修复了若干 memory leaks 和 flaky tests。二进制变小。benchmark 大致持平到更快。

但更重要的，是 compiler-assisted tools。

用更直白的话说：

让编译器和工具帮忙抓住、预防那些在系统语言里很难靠人一直盯住的内存问题。

这和 Bun 早期的 Zig 叙事形成了一个非常好听的回声。

二零二二年，Jarred 为了生产力、控制感、编译期能力，选择 Zig。

那时的控制感，是少一点隐藏成本，少一点等，少一点大工具链挡在面前。

二零二六年，Bun 转向 Rust。

这时的控制感，是另一种控制感：

让编译器介入。

让类型和所有权帮忙保存一些人会忘、review 会漏、迁移会弄错的东西。

一个工具从“我要把控制拿回来”，走到“我要把一部分控制交给编译器”。

这不是简单反转。

这是工具长大以后，信任方式变了。

这次迁移还有一份很有意思的 porting guide。

标题是 Zig 到 Rust 的 porting guide。

它像一份翻译手册。

第一句话就不是“把项目重写成 Rust”，而是：

你正在把一个 Zig 文件翻译成 Rust。先读完整份文档。

它把迁移分成 Phase A 和 Phase B。

Phase A 的目标，是在点 zig 旁边生成同名点 r s 草稿，忠实捕捉逻辑，不要求编译。

Phase B，再按 crate 一个个让它编译。

这就很有意思。

因为它承认：一次大迁移不是按下按钮，等机器吐出正确代码。

第一步甚至不是“编译通过”。

第一步是把结构、意图、控制流、危险点先搬过去。

像翻译一本文本。

先要让意思站起来，再谈句子是不是顺。

porting guide 还写了很多规则。

不要发明 crate layouts。

不要用 tokio、rayon、hyper。

不要用 async fn。

Bun 有自己的 event loop 和 syscalls。

如果 Zig 里本来就是 unsafe，Rust 里可以 unsafe，但每个 unsafe block 都要写 SAFETY 注释，解释为什么安全。

不能确定的地方，留下 T O D O port。

性能相关的折中，留下 PERF port，Phase B 再 grep，再 benchmark。

这些规则很适合被读出来。

does not need to compile.

No async fn.

SAFETY: why.

T O D O port: reason.

PERF port: profile in Phase B.

这不是简单改写。

它更像翻译。

把一种语言里的结构、习惯、危险和意图，搬到另一种语言里。

不能只做词语替换。

你要知道一个 out-param constructor 在 Rust 里该怎么变。要知道 deinit 该不该变成 Drop。要知道字节是不是能被当成 U T F 八。

要知道 Zig 的 allocator、slice、error set、comptime，在 Rust 里分别该落到什么形状。

最有意思的是，这份文档很像是在同时写给人和机器。

它给出格式。

给出禁令。

给出命名规则。

给出不确定时该留下什么标记。

这很适合 AI-assisted 迁移的语境。

但这里仍然要谨慎。

P R 分支和提交记录里能看到 claude slash phase A port 这样的线索。社区也围绕 AI-assisted、vibe port、Zig 和 Rust 选择、百万(hang2) diff 的可信度展开讨论。

我们可以说：这次迁移发生在 AI coding infrastructure 的语境中。它留下了与 Claude 相关的可见痕迹。社区也确实把它当成一个关于 AI 迁移代码、信任大规模 diff 的事件来讨论。

我们不能说：这次重写就是 AI 完成的。

除非有更直接的来源。

这已经足够有意思了。

因为它把 Bun 的故事折回了开头。

最初，Jarred 为了不等工具链，开始造工具。

几年后，这个工具进入 AI coding 的基础设施。

再后来，它自己变成一个巨大的、需要被迁移、被审查、被重新信任的代码库。

二零二六年五月，P R 合并时，P R body 还明确提醒：要尝试可以走 bun upgrade canary。进入 non-canary 版本前，仍有优化和清理工作。

截至二零二六年七月五日，公开 GitHub Releases、Bun 官网安装页和 npm 页面，仍显示 latest stable 是一点三点十四，发布时间早于 Rust rewrite P R 合并。

所以现在还不能说 Rust rewrite 已经进入 stable release。

只能说：它已经合并到主线，处在 canary 和后续清理优化的叙事里。后续 stable 状态，需要以最新发布页为准。

所以，等待到底被消灭了吗？

当然没有。

等待只是换了地方。

早期程序员等纸带、等卡片、等批处理作业。

后来的程序员等编译、等链接、等测试、等 C I。

前端开发者等热更新、等依赖安装、等 bundler 重新打包。

Bun 把一部分等待压短了。

它让 install 更快，让脚本启动更快，让 TypeScript 和 J S X 的开发体验更轻，让工具链中许多分散的环节合到一起。

但当它成功以后，新的等待出现了。

用户等 bug 修复。

维护者等复现。

P R 等 review。

社区等 stable release。

AI 生成的代码等人类判断。

一个 runtime 等下一次被重写。

今天，当人们使用 Claude Code 这样的 AI 编程工具时，等待又换了一种形状。

你不一定是在等 bundler，也不一定是在等编译器。你可能是在等 L L M 推理，等它读文件、改代码、跑测试，再修掉一个失败。

屏幕上不再只是 spinner，或者一行卡住的日志。它可能是一段一段生成的文字，一条一条 tool call，一串正在执行的任务。

这仍然是等待。

只是机器看起来更像在工作。

于是新的工程习惯也在出现。

人不再总是坐在电脑前，看着任务一点点跑完。他可以把任务交给 AI agent，让它执行、检查、整理结果。

等任务结束，再通过 Slack、Telegram 这样的 I M 工具，把结果主动推回来。

等待从“我守着机器”，变成“机器完成以后来找我”。

这不是一个小小的交互细节。

它说明人类想消除的，不只是慢。

也是被机器占住的生命时间。

人的注意力有限，人的一天有限，人的生命也有限。

我们当然愿意等待某些东西。等一朵花慢慢开，等孩子一点点长大，等朋友和亲人下一次相聚。

但我们很难甘心，把这些时间交给一个终端窗口，交给一条还没有结束的日志，交给一台迟迟不回答的机器。

Bun 的故事好看，不是因为它终于做出了一个更快的轮子。

而是因为它让我们听见，轮子转起来以后，整个工程世界也被带着一起转。

开发工具的历史，很大一部分就是把“修改”和“确认”之间的距离不断压短。

但每一次压缩，都会把复杂性推到另一个地方。

打孔纸带变成汇编器。

批处理变成交互式终端。

编译等待变成脚本语言。

脚本语言变成工具链。

工具链变成 runtime。

runtime 变成 AI coding infrastructure。

AI coding infrastructure 又把代码、测试、P R、review、信任，全部推到一个更高频的循环里。

我们造轮子，是为了逃离等待。

但当轮子足够重要，它就会变成新的等待机器。

你正在收听的是《原代码》，一档关于软件开发世界的声音批评节目。

这一期，我们讲的是 Bun，和它背后那台不断转动的等待机器。

本期资料会整理在 show notes 里，包括 Bun 官方博客、Anthropic 收购新闻稿、P R 三零四一二、Bun porting guide、Claude Code setup docs 和 H N 讨论。

感谢你的收听。

我们下期再见。