EP74 64 个 Claude：Bun 的 11 天重写

[00:00] 大家好这里是 AsyncTalk我是 AsyncTalk 主播 Annatar今天想跟大家来聊一个其实之前已经说过很多遍的话题是关于 Bun Bun 它在 8月21号的时候发布了一个 1.4 版本据作者 Jarred 他自己说这是一个Bun自发出以来最没有变化的一个版本但其实我相信大家如果你有关注他

[00:21] 以及他作者本人的一些 Twitter 账户之类的你会发现他说的改动最小的一个版本的意思是对于用户来说改动最小但是整个 bun 所有的代码框架它其实已经完全变掉了他之前是拿 zig 来写的 runtime写的一整个 bun 的系统来去做 Javascript 的一个 runtime你如果有看它的代码仓库它已经不是这个样子它是拿 rust 来去重写了

[00:46] 大概就在上个月的时候关于 rust 重写 Bun 这件事情其实引起了很大很大的争论到现在为止其实基本上已经尘埃落定了因为像你知道的 1.4 版本拿 rust 重写的这个版本它已经发布出来了所以我觉得我们 AsyncTalk可以先简单的来聊一聊这个 rust 重写 Bun 的这样一个内容其实 Jarred 他有写了一篇文章来去介绍他是怎么样

[01:15] 去拿 rust 重写 Bun 的这样一个过程这篇文章我看过他写的非常的好里边提供了非常多的经验这篇文章其实大家可以搜一下也自己读一遍我比较推荐大家去读这篇文章我觉得里面有很多点是非常有趣的所以我单独挑出来和大家聊一聊里面的一些内容那我觉得最有意思的第一点 就是 Bun 他其实是拿了 11 天

[01:38] 就整个把 JS 的 runtime它的 zig 的系统来去重写成了 rust 的一整套系统我可以说 11天这在之前是一个不可能发生的事情因为你非常难以想象一个互联网的一个基础设施建设一个 Javascript 的一个 runtime它可以拿 11 天就把它给重写完这是一个在 AI 之前是不可想象的事情但他放到 AI 之后 Bun 他做到了那我们就想来聊一聊

[02:08] 这个重写是怎么样的其实 Jarred 他有分享他是去拿 Fable 5开了 64 个 Claude 的线程去进行了重写按照 API 的计费是花了 16 万美金那首先我们要看一下Jarred 他有介绍这个动机我们可以看这张图 Bun 的它其实和 nodejs 一样它都是基于一种 Javascript 运行时上面的一种拓展

[02:30] 它拓展来去桥接各种比如说系统比如说网络这种来实现对应的能力来让你的 Javascript 代码能去运行能去和一些文件系统交互能去做很多的事情但是在下面一层它其实是 Javascript 的一个核心的Javascript 的运行时那这个运行时它不做任何其他像网络文件系统以及连接性的东西

[02:54] 它只负责一件非常具体的事情就是执行 Javascript对于 Bun 来说它用的不是 V8我们熟知的 V8 系统那 V8 就是像是 Chrome Nodejs它底层用的 V8 嘛但 Bun 为了更高的效率他用的不是 V8他选择的是 Safari 底下的 JavaScriptCore这样一种引擎其实去研究一下你会发现

[03:16] JavaScriptCore 它是一个有 GC 的运行时那 GC 就是 garbage collection你是不用去主动关注说我要删除某个对象我要去释放一块内存你是不需要主动这样做的但 Zig 它是手动管理内存它并不是一个那么智能那么现代的一个带 GC 的语言所以 GC 它和手动管理内存这个混合在一起对于Bun来说

[03:38] 他认为是一个比较 tricky 的问题因此引发了非常多内存相关的 bug对于Bun来说他处理这些问题很困难不如说大家都转到 rust 来去做这件事情当然 Jarred 他有说过这不是怪 zig这是针对于这种情况下的一个特有的问题然后我们来去讨论一下这个成本其实像一个 Bun 这样的系统它有 53 万行代码如果不修 bug不修安全问题

[04:04] 各种安全修复也不做大概要多久可以做出来呢那我觉得一个比较合理的操作是可能 3 到 5 个 senior以及 senior principle 的一个 engineer他非常的懂这套系统他们也许要一年的时间重写这个东西那你就可以想象这个成本所以在 AI 之前软件工程其实一般是不重写的要么你新开项目然后去做迁移

[04:29] 但是看到 AI 之后它变得有可能了那现在我们来进入主题就是整个过程是什么样子的它对于我们上层来说是比较简单的那就是先跟现有的代码库去聊去做一个方案一个 porting 的方案还有一些 lifetime 的一个 TSV 的文件然后去生成它之后去做两份文档

[04:51] 来做这种对抗性的 review这种对抗性的 review它以互相要挑出对方毛病为目的去进行的一个对抗进行 review Review 之后那份文件其实很多时候相对来说质量还不错的那这个时候就先跑三个文件试一下接下来再进行一个大规模的迁移了其实在运行的时候这个对抗性 review 是有一个实现由两个 reviewer 来进行的

[05:16] 他们的 context window 是完全隔离的因为你自己做开发自己去给自己测试是一个很明显的错误所以说我们需要 QA那在重写 Bun 的过程中就是新开 reviewer去校验之前的实现到底对不对在重写完成之后肯定是要进行编译的Rust 编译 现在大家都知道它是非常可怕的严厉你自己有试试过你大概会 get 到这个点

[05:39] 编译错误对我们当然是非常的痛苦的因为我们要一个个处理嘛但是对于 AI 来说这其实是一件好事因为它告诉 AI 说这个地方错了那接下来 AI 它就可以继续再去进行针对这个错误来理解项目理解代码再去进行一些修复当然了在这个迁移过程中有没有什么问题呢那问题肯定非常多的

[06:00] 那首先第一点就是一个提交你想想你自己有 64 个实例在写代码你也可以理解它不是 64 个 claude 实例而是 64 个开发在同一个 repo 来去做事情那你其实就可以想象到它肯定有非常多的代码冲突所以解决办法基本上就是拿 Git Stash以及去加一些 rules来去明确地告诉说不要提交那种不是自己范围内的代码还有一点

[06:24] 如果说你们公司有比较稍微严厉的代码测试的要求你就会发现有些人他为了测试代码他会去改那个类型断言具体是什么意思呢大概就是右边这个代码那你怎么样去让一个 1+ 1= 3 的情况发生呢有一个办法就是说我去修改断言去把这个 1+1 这个 expect.toBe就把它做成一个等于 3

[06:49] 它永远返回 true那这样的话它就完成了对不对另一个办法就是我怎么样让自己的代码不犯错呢答案就是不写代码只要不写代码我的代码就不会有 bug 对吧对于 AI 来说也是这样的它会写出大量的解释说这个地方我不写了

[07:05] 我这个地方只是一个 Stub 放在这里这个代码肯定不是我们想要的对不对那所以当这种情况出现我们要在 rule 里面来去写如果说一段代码需要用加大量注释来去解释那我们其实可以认为说这段代码是错的让他再去想想再去改但还有一些其他各种各样的问题了那比如说像还有 IOPS

[07:25] 因为你写代码一定会大量的操作文件那这个文件写得实在太高了它把磁盘撑满其实我前面说了那么多问题它有一个最核心的点就在于在重写过程中是会发生各种各样的问题的就是还是那个出发点我们把 AI 当成人来去看一个人是可能会犯错的一个 AI 当然也是可能会犯错的那我问题在于说

[07:47] 当人或者 AI 犯错的时候我们应该怎么做那我们就只能从自己身上找原因所以当具体问题出现的时候那我们其实不是说你把这个代码实现而是说我们要去改自己的规则去具体的告诉 AI 说不可以去做这样一种弄虚作假不可以去做像是 Stub 不实现代码这种事情而是应该要去怎么样去做现在非常流行的话来说

[08:13] 就是 context not control就是你给 AI 充足的上下文你告诉他说你应该以怎么样的原则去改代码那具体怎么改你可以自己看着办也就是说你让 AI 去写这段代码你让它去获取一份文件那它具体是通过 filesystem 去获取的还是通过网络去获取的还是找别人发聊天记录来去获取的

[08:36] 其实并不重要我们只要告诉它我们想要什么东西AI 来自由发挥当 AI 犯错的时候我们不仅是要告诉 AI 做的不对同样的我们也要修改我们自己的流程自己的一个 rules 的规则来去尽量减少 AI 在接下来继续犯错那到最后一点为什么 bun 可以去做这个重写在我看来是因为 bun 它是一个比较特殊的项目

[09:02] 它并不像我们大多数做的一些业务项目一样它是一个非常底层的一个运行时的项目所以对于这样的项目来说天生它就有巨大量级的测试用例同时它的这个测试用例不仅是 Bun 他们自己写或者 Jarred 写的同时它也是社区其他项目的一些测试用例也可以拿来去用那我举个例子

[09:28] 再去用 Javascript来去执行一段代码的时候1+ 1= 2它不仅是在Bun自己的代码里有那同样在 Lodash或者说像是 underscore这种库里边同样也要能实现那所以这就带来了Bun它的测试用例是海量的它可以让 AI 来去运行测试用例来去纠正它自己的实现的问题然后让它来去理解自己写的不对

[09:55] 接下来一个问题其实我相信大家看完这篇文章都会有的疑问就是我自己的项目能不能去拿 Rust 去重写我首先给出我的建议就是你不要这么做因为你和Bun这个项目是很不一样的Bun这个项目它是有非常大量的测试用例在去支持的所以当你一段问题写错的时候它可能有 30-50 个代码块去覆盖你这么一行

[10:20] 看起来无足轻重的代码一旦有什么问题就很明显的可以看出错误大多数的观众我们写的都是一些上层业务代码首先我认为你测试用例可能并不多你有个 50% 的覆盖率我相信都已经是凤毛麟角了那另一方面他逻辑很多时候是写不了测试有时候你甚至问产品经理他都不知道这段逻辑应该是什么样子

[10:43] 我相信这是大家平常工作生活的一个常态所以像 Bun 这种它有明确的预期的东西是有可能来去拿 AI 重写的那像我们现实应用中绝大部分产品其实不太能这么做它是一个非常危险的东西因为你不知道 AI 写出来是什么你也没办法去验证 AI 写出来是什么你要花非常大的精力来去靠人工来验证甚至你都不一定知道验证的是不是对的

[11:09] 在现实生活中我并不建议大家去真的自己来做这个实现那另一方面就是成本是你要知道操作这个 AI 的这个人他需要相当高的技术能力他知道怎么样去组织 AI agent他知道这个具体的业务逻辑是什么样他知道这个业务逻辑应该怎么运行找到这样一个人还是相当困难的同样呢这个 API Fable 5 的价格是非常夸张的高OK

[11:36] 想到这里你觉得自己非常有信心你有充足的财力你也对自己的这个能力有信心你真的要开始去重写那我就建议你说你其实可以采用 Jarred 这样的一种方法去做你的一个迁移那首先去跟现有代码库聊出来方案然后去通过对抗性的 review互相找出问题然后做成一份完整的迁移的一个计划

[11:59] 通过编译错误通过执行测试用例通过中间各种各样的对抗性 review来最终的把它迁移出来你可以参考这个方案当然最重要的点就是当 AI 它犯错的时候你要把它当成一个人来去看不仅要说 coding agent这个实现有问题同样我们也要去反思自己的 rules 里边是不是哪里有问题

[12:20] 我们需要改自己的规则了我们要去改自己的业务因为在做这样一个重写项目的时候其实我们不仅自己是实现者同样我们也是一个管理者好那今天关于Bun来重写的内容关于我的解读就大概到这里我很期望大家看一看这篇文章因为这篇文章挺有意义的它对于你自己构建自己的 Harness 项目是有非常大的帮助的

[12:45] 那它同样的对于软件工程怎么样在 AI 时代的这个发展也是有大的用处的大家有空可以去看一看当然你看了之后你发现有什么和我聊的不对的地方或者说你有一些自己的想法也欢迎在评论区来留言讨论OK那我们下期节目再见拜拜