diff --git a/public/subtitles/ep74.srt b/public/subtitles/ep74.srt new file mode 100644 index 0000000..6d779db --- /dev/null +++ b/public/subtitles/ep74.srt @@ -0,0 +1,1580 @@ +1 +00:00:00,000 --> 00:00:00,400 +大家好 + +2 +00:00:00,433 --> 00:00:02,066 +这里是 AsyncTalk + +3 +00:00:02,133 --> 00:00:03,933 +我是 AsyncTalk 主播 Annatar + +4 +00:00:03,966 --> 00:00:05,533 +今天想跟大家来聊一个 + +5 +00:00:05,533 --> 00:00:07,666 +其实之前已经说过很多遍的话题 + +6 +00:00:07,733 --> 00:00:08,933 +是关于 Bun + +7 +00:00:08,933 --> 00:00:11,400 +Bun 它在 8月21号的时候 + +8 +00:00:11,400 --> 00:00:13,233 +发布了一个 1.4 版本 + +9 +00:00:13,266 --> 00:00:14,766 +据作者 Jarred 他自己说 + +10 +00:00:14,833 --> 00:00:16,233 +这是一个Bun自发出以来 + +11 +00:00:16,233 --> 00:00:18,000 +最没有变化的一个版本 + +12 +00:00:18,033 --> 00:00:21,033 +但其实我相信大家如果你有关注他 + +13 +00:00:21,200 --> 00:00:23,833 +以及他作者本人的一些 Twitter 账户之类的 + +14 +00:00:24,033 --> 00:00:25,233 +你会发现他说的 + +15 +00:00:25,233 --> 00:00:27,733 +改动最小的一个版本的意思是 + +16 +00:00:27,733 --> 00:00:29,233 +对于用户来说改动最小 + +17 +00:00:29,266 --> 00:00:31,800 +但是整个 bun 所有的代码框架 + +18 +00:00:31,800 --> 00:00:33,433 +它其实已经完全变掉了 + +19 +00:00:33,500 --> 00:00:35,800 +他之前是拿 zig 来写的 runtime + +20 +00:00:35,866 --> 00:00:37,666 +写的一整个 bun 的系统 + +21 +00:00:37,666 --> 00:00:40,833 +来去做 Javascript 的一个 runtime + +22 +00:00:40,900 --> 00:00:42,533 +你如果有看它的代码仓库 + +23 +00:00:42,600 --> 00:00:43,633 +它已经不是这个样子 + +24 +00:00:43,666 --> 00:00:46,500 +它是拿 rust 来去重写了 + +25 +00:00:46,533 --> 00:00:48,400 +大概就在上个月的时候 + +26 +00:00:48,466 --> 00:00:50,666 +关于 rust 重写 Bun 这件事情 + +27 +00:00:50,666 --> 00:00:53,533 +其实引起了很大很大的争论 + +28 +00:00:53,600 --> 00:00:56,266 +到现在为止其实基本上已经尘埃落定了 + +29 +00:00:56,300 --> 00:00:57,933 +因为像你知道的 1.4 版本 + +30 +00:00:57,933 --> 00:00:59,900 +拿 rust 重写的这个版本 + +31 +00:00:59,933 --> 00:01:02,400 +它已经发布出来了 + +32 +00:01:02,466 --> 00:01:05,066 +所以我觉得我们 AsyncTalk + +33 +00:01:05,066 --> 00:01:06,766 +可以先简单的来聊一聊 + +34 +00:01:06,766 --> 00:01:10,133 +这个 rust 重写 Bun 的这样一个内容 + +35 +00:01:10,200 --> 00:01:13,366 +其实 Jarred 他有写了一篇文章 + +36 +00:01:13,366 --> 00:01:15,200 +来去介绍他是怎么样 + +37 +00:01:15,200 --> 00:01:17,966 +去拿 rust 重写 Bun 的这样一个过程 + +38 +00:01:18,000 --> 00:01:19,300 +这篇文章我看过 + +39 +00:01:19,333 --> 00:01:21,300 +他写的非常的好 + +40 +00:01:21,333 --> 00:01:23,233 +里边提供了非常多的经验 + +41 +00:01:23,300 --> 00:01:25,033 +这篇文章其实大家可以搜一下 + +42 +00:01:25,033 --> 00:01:25,900 +也自己读一遍 + +43 +00:01:25,933 --> 00:01:27,700 +我比较推荐大家去读这篇文章 + +44 +00:01:27,733 --> 00:01:29,733 +我觉得里面有很多点是非常有趣的 + +45 +00:01:29,800 --> 00:01:30,833 +所以我单独挑出来 + +46 +00:01:30,833 --> 00:01:33,066 +和大家聊一聊里面的一些内容 + +47 +00:01:33,100 --> 00:01:34,300 +那我觉得最有意思的 + +48 +00:01:34,300 --> 00:01:38,466 +第一点 就是 Bun 他其实是拿了 11 天 + +49 +00:01:38,500 --> 00:01:41,000 +就整个把 JS 的 runtime + +50 +00:01:41,000 --> 00:01:42,600 +它的 zig 的系统 + +51 +00:01:42,666 --> 00:01:46,633 +来去重写成了 rust 的一整套系统 + +52 +00:01:46,666 --> 00:01:48,466 +我可以说 11天 + +53 +00:01:48,466 --> 00:01:51,566 +这在之前是一个不可能发生的事情 + +54 +00:01:51,600 --> 00:01:53,466 +因为你非常难以想象 + +55 +00:01:53,533 --> 00:01:55,566 +一个互联网的一个基础设施建设 + +56 +00:01:55,600 --> 00:01:57,300 +一个 Javascript 的一个 runtime + +57 +00:01:57,366 --> 00:02:00,233 +它可以拿 11 天就把它给重写完 + +58 +00:02:00,300 --> 00:02:03,333 +这是一个在 AI 之前是不可想象的事情 + +59 +00:02:03,366 --> 00:02:06,733 +但他放到 AI 之后 Bun 他做到了 + +60 +00:02:06,766 --> 00:02:08,733 +那我们就想来聊一聊 + +61 +00:02:08,733 --> 00:02:10,766 +这个重写是怎么样的 + +62 +00:02:10,800 --> 00:02:12,033 +其实 Jarred 他有分享 + +63 +00:02:12,100 --> 00:02:13,533 +他是去拿 Fable 5 + +64 +00:02:13,533 --> 00:02:15,733 +开了 64 个 Claude 的线程 + +65 +00:02:15,733 --> 00:02:17,133 +去进行了重写 + +66 +00:02:17,166 --> 00:02:19,733 +按照 API 的计费是花了 16 万美金 + +67 +00:02:19,766 --> 00:02:21,333 +那首先我们要看一下 + +68 +00:02:21,333 --> 00:02:22,866 +Jarred 他有介绍这个动机 + +69 +00:02:22,933 --> 00:02:24,133 +我们可以看这张图 Bun 的 + +70 +00:02:24,166 --> 00:02:25,466 +它其实和 nodejs 一样 + +71 +00:02:25,533 --> 00:02:28,233 +它都是基于一种 Javascript 运行时 + +72 +00:02:28,233 --> 00:02:30,033 +上面的一种拓展 + +73 +00:02:30,100 --> 00:02:32,366 +它拓展来去桥接各种 + +74 +00:02:32,366 --> 00:02:33,766 +比如说系统 + +75 +00:02:33,800 --> 00:02:34,966 +比如说网络 + +76 +00:02:34,966 --> 00:02:37,233 +这种来实现对应的能力 + +77 +00:02:37,300 --> 00:02:40,166 +来让你的 Javascript 代码能去运行 + +78 +00:02:40,200 --> 00:02:42,100 +能去和一些文件系统交互 + +79 +00:02:42,166 --> 00:02:43,733 +能去做很多的事情 + +80 +00:02:43,766 --> 00:02:45,000 +但是在下面一层 + +81 +00:02:45,066 --> 00:02:47,333 +它其实是 Javascript 的一个核心的 + +82 +00:02:47,366 --> 00:02:49,033 +Javascript 的运行时 + +83 +00:02:49,100 --> 00:02:51,200 +那这个运行时它不做任何其他 + +84 +00:02:51,200 --> 00:02:54,566 +像网络文件系统以及连接性的东西 + +85 +00:02:54,600 --> 00:02:56,800 +它只负责一件非常具体的事情 + +86 +00:02:56,866 --> 00:02:58,333 +就是执行 Javascript + +87 +00:02:58,366 --> 00:02:59,066 +对于 Bun 来说 + +88 +00:02:59,133 --> 00:03:00,600 +它用的不是 V8 + +89 +00:03:00,666 --> 00:03:01,966 +我们熟知的 V8 系统 + +90 +00:03:02,000 --> 00:03:04,866 +那 V8 就是像是 Chrome Nodejs + +91 +00:03:04,933 --> 00:03:06,133 +它底层用的 V8 嘛 + +92 +00:03:06,166 --> 00:03:08,233 +但 Bun 为了更高的效率 + +93 +00:03:08,300 --> 00:03:09,400 +他用的不是 V8 + +94 +00:03:09,466 --> 00:03:13,066 +他选择的是 Safari 底下的 JavaScriptCore + +95 +00:03:13,066 --> 00:03:14,733 + 这样一种引擎 + +96 +00:03:14,833 --> 00:03:16,300 +其实去研究一下你会发现 + +97 +00:03:16,400 --> 00:03:18,800 + JavaScriptCore 它是一个有 GC 的运行时 + +98 +00:03:18,800 --> 00:03:20,933 +那 GC 就是 garbage collection + +99 +00:03:20,966 --> 00:03:22,766 +你是不用去主动关注 + +100 +00:03:22,800 --> 00:03:25,000 +说我要删除某个对象 + +101 +00:03:25,033 --> 00:03:26,300 +我要去释放一块内存 + +102 +00:03:26,366 --> 00:03:28,033 +你是不需要主动这样做的 + +103 +00:03:28,100 --> 00:03:30,333 +但 Zig 它是手动管理内存 + +104 +00:03:30,366 --> 00:03:32,133 +它并不是一个那么智能 + +105 +00:03:32,133 --> 00:03:34,433 +那么现代的一个带 GC 的语言 + +106 +00:03:34,500 --> 00:03:36,866 +所以 GC 它和手动管理内存 + +107 +00:03:36,866 --> 00:03:37,866 +这个混合在一起 + +108 +00:03:37,900 --> 00:03:38,700 +对于Bun来说 + +109 +00:03:38,733 --> 00:03:41,000 +他认为是一个比较 tricky 的问题 + +110 +00:03:41,033 --> 00:03:43,433 +因此引发了非常多内存相关的 bug + +111 +00:03:43,433 --> 00:03:44,200 +对于Bun来说 + +112 +00:03:44,333 --> 00:03:46,366 +他处理这些问题很困难 + +113 +00:03:46,433 --> 00:03:50,333 +不如说大家都转到 rust 来去做这件事情 + +114 +00:03:50,400 --> 00:03:52,833 +当然 Jarred 他有说过这不是怪 zig + +115 +00:03:52,833 --> 00:03:55,100 +这是针对于这种情况下的一个特有的问题 + +116 +00:03:55,100 --> 00:03:57,500 +然后我们来去讨论一下这个成本 + +117 +00:03:57,533 --> 00:04:00,433 +其实像一个 Bun 这样的系统 + +118 +00:04:00,500 --> 00:04:02,566 +它有 53 万行代码 + +119 +00:04:02,600 --> 00:04:03,566 +如果不修 bug + +120 +00:04:03,566 --> 00:04:04,266 +不修安全问题 + +121 +00:04:04,333 --> 00:04:05,800 +各种安全修复也不做 + +122 +00:04:05,833 --> 00:04:08,200 +大概要多久可以做出来呢 + +123 +00:04:08,233 --> 00:04:11,033 +那我觉得一个比较合理的操作是 + +124 +00:04:11,166 --> 00:04:13,600 +可能 3 到 5 个 senior + +125 +00:04:13,600 --> 00:04:16,933 +以及 senior principle 的一个 engineer + +126 +00:04:16,933 --> 00:04:17,833 +他非常的懂这套系统 + +127 +00:04:17,833 --> 00:04:20,333 +他们也许要一年的时间重写这个东西 + +128 +00:04:20,366 --> 00:04:23,666 +那你就可以想象这个成本 + +129 +00:04:23,733 --> 00:04:24,633 +所以在 AI 之前 + +130 +00:04:24,700 --> 00:04:27,000 +软件工程其实一般是不重写的 + +131 +00:04:27,066 --> 00:04:28,333 +要么你新开项目 + +132 +00:04:28,366 --> 00:04:29,633 +然后去做迁移 + +133 +00:04:29,700 --> 00:04:31,766 +但是看到 AI 之后 + +134 +00:04:31,833 --> 00:04:33,033 +它变得有可能了 + +135 +00:04:33,066 --> 00:04:34,633 +那现在我们来进入主题 + +136 +00:04:34,666 --> 00:04:36,566 +就是整个过程是什么样子的 + +137 +00:04:36,633 --> 00:04:39,433 +它对于我们上层来说是比较简单的 + +138 +00:04:39,466 --> 00:04:42,600 +那就是先跟现有的代码库去聊 + +139 +00:04:42,600 --> 00:04:43,733 +去做一个方案 + +140 +00:04:43,733 --> 00:04:45,066 +一个 porting 的方案 + +141 +00:04:45,066 --> 00:04:46,533 +还有一些 lifetime 的 + +142 +00:04:46,600 --> 00:04:48,400 +一个 TSV 的文件 + +143 +00:04:48,400 --> 00:04:49,566 +然后去生成它 + +144 +00:04:49,566 --> 00:04:51,933 +之后去做两份文档 + +145 +00:04:51,933 --> 00:04:53,900 +来做这种对抗性的 review + +146 +00:04:53,966 --> 00:04:55,166 +这种对抗性的 review + +147 +00:04:55,200 --> 00:04:58,700 +它以互相要挑出对方毛病为目的 + +148 +00:04:58,700 --> 00:05:01,166 +去进行的一个对抗进行 review + +149 +00:05:01,200 --> 00:05:01,866 +Review 之后 + +150 +00:05:01,900 --> 00:05:03,833 +那份文件其实很多时候 + +151 +00:05:03,833 --> 00:05:05,466 +相对来说质量还不错的 + +152 +00:05:05,500 --> 00:05:07,866 +那这个时候就先跑三个文件试一下 + +153 +00:05:07,900 --> 00:05:10,200 +接下来再进行一个大规模的迁移了 + +154 +00:05:10,266 --> 00:05:11,766 +其实在运行的时候 + +155 +00:05:11,833 --> 00:05:14,433 +这个对抗性 review 是有一个实现 + +156 +00:05:14,466 --> 00:05:16,366 +由两个 reviewer 来进行的 + +157 +00:05:16,433 --> 00:05:18,733 +他们的 context window 是完全隔离的 + +158 +00:05:18,800 --> 00:05:20,166 +因为你自己做开发 + +159 +00:05:20,200 --> 00:05:22,833 +自己去给自己测试是一个很明显的错误 + +160 +00:05:22,866 --> 00:05:25,066 +所以说我们需要 QA + +161 +00:05:25,100 --> 00:05:26,400 +那在重写 Bun 的过程中 + +162 +00:05:26,466 --> 00:05:28,300 +就是新开 reviewer + +163 +00:05:28,300 --> 00:05:31,166 +去校验之前的实现到底对不对 + +164 +00:05:31,166 --> 00:05:33,433 +在重写完成之后肯定是要进行编译的 + +165 +00:05:33,466 --> 00:05:35,133 +Rust 编译 现在大家都知道 + +166 +00:05:35,133 --> 00:05:36,233 +它是非常可怕的严厉 + +167 +00:05:36,266 --> 00:05:38,233 +你自己有试试过 + +168 +00:05:38,233 --> 00:05:39,533 +你大概会 get 到这个点 + +169 +00:05:39,600 --> 00:05:43,066 +编译错误对我们当然是非常的痛苦的 + +170 +00:05:43,066 --> 00:05:44,266 +因为我们要一个个处理嘛 + +171 +00:05:44,266 --> 00:05:45,300 +但是对于 AI 来说 + +172 +00:05:45,300 --> 00:05:46,666 +这其实是一件好事 + +173 +00:05:46,666 --> 00:05:48,400 +因为它告诉 AI 说这个地方错了 + +174 +00:05:48,433 --> 00:05:50,100 +那接下来 AI 它就可以继续 + +175 +00:05:50,100 --> 00:05:54,066 +再去进行针对这个错误来理解项目 + +176 +00:05:54,066 --> 00:05:54,733 +理解代码 + +177 +00:05:54,733 --> 00:05:55,900 +再去进行一些修复 + +178 +00:05:55,966 --> 00:05:56,533 +当然了 + +179 +00:05:56,566 --> 00:05:58,733 +在这个迁移过程中有没有什么问题呢 + +180 +00:05:58,766 --> 00:06:00,066 +那问题肯定非常多的 + +181 +00:06:00,100 --> 00:06:01,966 +那首先第一点就是一个提交 + +182 +00:06:02,033 --> 00:06:05,133 +你想想你自己有 64 个实例在写代码 + +183 +00:06:05,200 --> 00:06:07,566 +你也可以理解它不是 64 个 claude 实例 + +184 +00:06:07,600 --> 00:06:09,566 +而是 64 个开发 + +185 +00:06:09,566 --> 00:06:11,366 +在同一个 repo 来去做事情 + +186 +00:06:11,400 --> 00:06:13,166 +那你其实就可以想象到 + +187 +00:06:13,166 --> 00:06:14,166 +它肯定有非常多的代码冲突 + +188 +00:06:14,200 --> 00:06:17,600 +所以解决办法基本上就是拿 Git Stash + +189 +00:06:17,600 --> 00:06:18,933 +以及去加一些 rules + +190 +00:06:18,933 --> 00:06:20,366 +来去明确地告诉说 + +191 +00:06:20,366 --> 00:06:23,666 +不要提交那种不是自己范围内的代码 + +192 +00:06:23,700 --> 00:06:24,266 +还有一点 + +193 +00:06:24,300 --> 00:06:25,733 +如果说你们公司有 + +194 +00:06:25,733 --> 00:06:28,933 +比较稍微严厉的代码测试的要求 + +195 +00:06:29,000 --> 00:06:32,466 +你就会发现有些人他为了测试代码 + +196 +00:06:32,500 --> 00:06:34,666 +他会去改那个类型断言 + +197 +00:06:34,700 --> 00:06:35,500 +具体是什么意思呢 + +198 +00:06:35,566 --> 00:06:36,766 +大概就是右边这个代码 + +199 +00:06:36,800 --> 00:06:38,600 +那你怎么样去 + +200 +00:06:38,600 --> 00:06:41,466 +让一个 1+ 1= 3 的情况发生呢 + +201 +00:06:41,500 --> 00:06:42,000 +有一个办法 + +202 +00:06:42,066 --> 00:06:43,666 +就是说我去修改断言 + +203 +00:06:43,700 --> 00:06:46,433 +去把这个 1+1 这个 expect.toBe + +204 +00:06:46,500 --> 00:06:49,500 +就把它做成一个等于 3 + +205 +00:06:49,500 --> 00:06:50,766 +它永远返回 true + +206 +00:06:50,766 --> 00:06:51,266 +那这样的话 + +207 +00:06:51,333 --> 00:06:52,000 +它就完成了 + +208 +00:06:52,000 --> 00:06:52,266 +对不对 + +209 +00:06:52,300 --> 00:06:53,400 +另一个办法就是 + +210 +00:06:53,466 --> 00:06:55,700 +我怎么样让自己的代码不犯错呢 + +211 +00:06:55,766 --> 00:06:57,333 +答案就是不写代码 + +212 +00:06:57,366 --> 00:06:58,233 +只要不写代码 + +213 +00:06:58,233 --> 00:07:00,333 +我的代码就不会有 bug 对吧 + +214 +00:07:00,333 --> 00:07:02,300 +对于 AI 来说也是这样的 + +215 +00:07:02,300 --> 00:07:03,433 +它会写出大量的解释 + +216 +00:07:03,433 --> 00:07:05,466 +说这个地方我不写了 + +217 +00:07:05,466 --> 00:07:07,966 +我这个地方只是一个 Stub 放在这里 + +218 +00:07:08,000 --> 00:07:09,500 +这个代码肯定不是我们想要的 + +219 +00:07:09,500 --> 00:07:09,933 +对不对 + +220 +00:07:09,933 --> 00:07:11,600 +那所以当这种情况出现 + +221 +00:07:11,600 --> 00:07:13,066 +我们要在 rule 里面来去写 + +222 +00:07:13,100 --> 00:07:15,300 +如果说一段代码需要用 + +223 +00:07:15,300 --> 00:07:16,566 +加大量注释来去解释 + +224 +00:07:16,633 --> 00:07:19,733 +那我们其实可以认为说这段代码是错的 + +225 +00:07:19,800 --> 00:07:20,666 +让他再去想想 + +226 +00:07:20,700 --> 00:07:21,366 +再去改 + +227 +00:07:21,433 --> 00:07:23,666 +但还有一些其他各种各样的问题了 + +228 +00:07:23,666 --> 00:07:25,233 +那比如说像还有 IOPS + +229 +00:07:25,266 --> 00:07:28,600 +因为你写代码一定会大量的操作文件 + +230 +00:07:28,600 --> 00:07:31,066 +那这个文件写得实在太高了 + +231 +00:07:31,066 --> 00:07:32,166 +它把磁盘撑满 + +232 +00:07:32,166 --> 00:07:33,166 +其实我前面说了那么多问题 + +233 +00:07:33,233 --> 00:07:35,533 +它有一个最核心的点就在于 + +234 +00:07:35,533 --> 00:07:37,733 +在重写过程中是会 + +235 +00:07:37,733 --> 00:07:38,933 +发生各种各样的问题的 + +236 +00:07:38,933 --> 00:07:40,733 +就是还是那个出发点 + +237 +00:07:40,733 --> 00:07:41,766 +我们把 AI 当成人来去看 + +238 +00:07:41,800 --> 00:07:43,766 +一个人是可能会犯错的 + +239 +00:07:43,833 --> 00:07:45,466 +一个 AI 当然也是可能会犯错的 + +240 +00:07:45,466 --> 00:07:47,366 +那我问题在于说 + +241 +00:07:47,366 --> 00:07:50,100 +当人或者 AI 犯错的时候 + +242 +00:07:50,200 --> 00:07:50,633 +我们应该怎么做 + +243 +00:07:50,666 --> 00:07:52,666 +那我们就只能从自己身上找原因 + +244 +00:07:52,700 --> 00:07:56,866 +所以当具体问题出现的时候 + +245 +00:07:56,866 --> 00:07:59,500 +那我们其实不是说你把这个代码实现 + +246 +00:07:59,500 --> 00:08:00,733 +而是说我们要去改自己的规则 + +247 +00:08:00,800 --> 00:08:03,233 +去具体的告诉 AI 说 + +248 +00:08:03,233 --> 00:08:05,500 +不可以去做这样一种弄虚作假 + +249 +00:08:05,500 --> 00:08:06,633 +不可以去做 + +250 +00:08:06,633 --> 00:08:08,800 +像是 Stub 不实现代码这种事情 + +251 +00:08:08,866 --> 00:08:11,933 +而是应该要去怎么样去做 + +252 +00:08:12,000 --> 00:08:13,900 +现在非常流行的话来说 + +253 +00:08:13,900 --> 00:08:15,900 +就是 context not control + +254 +00:08:15,966 --> 00:08:18,400 +就是你给 AI 充足的上下文 + +255 +00:08:18,433 --> 00:08:20,133 +你告诉他说你应该 + +256 +00:08:20,133 --> 00:08:21,866 +以怎么样的原则去改代码 + +257 +00:08:21,900 --> 00:08:22,766 +那具体怎么改 + +258 +00:08:22,833 --> 00:08:24,200 +你可以自己看着办 + +259 +00:08:24,233 --> 00:08:25,400 +也就是说 + +260 +00:08:25,433 --> 00:08:27,200 +你让 AI 去写这段代码 + +261 +00:08:27,200 --> 00:08:28,800 +你让它去获取一份文件 + +262 +00:08:28,800 --> 00:08:31,900 +那它具体是通过 filesystem 去获取的 + +263 +00:08:31,900 --> 00:08:33,433 +还是通过网络去获取的 + +264 +00:08:33,433 --> 00:08:36,366 +还是找别人发聊天记录来去获取的 + +265 +00:08:36,433 --> 00:08:37,666 +其实并不重要 + +266 +00:08:37,666 --> 00:08:39,633 +我们只要告诉它我们想要什么东西 + +267 +00:08:39,666 --> 00:08:40,666 +AI 来自由发挥 + +268 +00:08:40,700 --> 00:08:41,800 +当 AI 犯错的时候 + +269 +00:08:41,866 --> 00:08:45,733 +我们不仅是要告诉 AI 做的不对 + +270 +00:08:45,800 --> 00:08:49,433 +同样的我们也要修改我们自己的流程 + +271 +00:08:49,466 --> 00:08:52,133 +自己的一个 rules 的规则 + +272 +00:08:52,133 --> 00:08:55,866 +来去尽量减少 AI 在接下来继续犯错 + +273 +00:08:55,900 --> 00:08:57,000 +那到最后一点 + +274 +00:08:57,066 --> 00:08:59,866 +为什么 bun 可以去做这个重写 + +275 +00:08:59,900 --> 00:09:00,966 +在我看来 + +276 +00:09:01,000 --> 00:09:02,533 +是因为 bun 它是一个比较特殊的项目 + +277 +00:09:02,600 --> 00:09:04,866 +它并不像我们大多数 + +278 +00:09:04,866 --> 00:09:06,500 +做的一些业务项目一样 + +279 +00:09:06,566 --> 00:09:09,433 +它是一个非常底层的一个运行时的项目 + +280 +00:09:09,466 --> 00:09:11,300 +所以对于这样的项目来说 + +281 +00:09:11,366 --> 00:09:15,600 +天生它就有巨大量级的测试用例 + +282 +00:09:15,633 --> 00:09:17,666 +同时它的这个测试用例 + +283 +00:09:17,666 --> 00:09:19,400 +不仅是 Bun 他们自己写 + +284 +00:09:19,400 --> 00:09:20,700 +或者 Jarred 写的 + +285 +00:09:20,766 --> 00:09:22,666 +同时它也是 + +286 +00:09:22,666 --> 00:09:26,066 +社区其他项目的一些测试用例 + +287 +00:09:26,066 --> 00:09:27,166 +也可以拿来去用 + +288 +00:09:27,200 --> 00:09:28,766 +那我举个例子 + +289 +00:09:28,766 --> 00:09:29,700 +再去用 Javascript + +290 +00:09:29,766 --> 00:09:32,100 +来去执行一段代码的时候 + +291 +00:09:32,100 --> 00:09:33,500 +1+ 1= 2 + +292 +00:09:33,500 --> 00:09:36,466 +它不仅是在Bun自己的代码里有 + +293 +00:09:36,466 --> 00:09:37,800 +那同样在 Lodash + +294 +00:09:37,800 --> 00:09:40,566 +或者说像是 underscore + +295 +00:09:40,566 --> 00:09:42,600 +这种库里边同样也要能实现 + +296 +00:09:42,633 --> 00:09:44,233 +那所以这就带来了Bun + +297 +00:09:44,300 --> 00:09:46,666 +它的测试用例是海量的 + +298 +00:09:46,700 --> 00:09:50,900 +它可以让 AI 来去运行测试用例 + +299 +00:09:50,900 --> 00:09:52,533 +来去纠正它自己的实现的问题 + +300 +00:09:52,566 --> 00:09:55,033 +然后让它来去理解自己写的不对 + +301 +00:09:55,100 --> 00:09:55,866 +接下来一个问题 + +302 +00:09:55,900 --> 00:09:57,333 +其实我相信大家 + +303 +00:09:57,333 --> 00:09:59,000 +看完这篇文章都会有的疑问 + +304 +00:09:59,033 --> 00:10:00,700 +就是我自己的项目 + +305 +00:10:00,700 --> 00:10:02,400 +能不能去拿 Rust 去重写 + +306 +00:10:02,433 --> 00:10:05,833 +我首先给出我的建议就是你不要这么做 + +307 +00:10:05,900 --> 00:10:08,100 +因为你和Bun这个项目是很不一样的 + +308 +00:10:08,133 --> 00:10:10,200 +Bun这个项目它是有非常 + +309 +00:10:10,200 --> 00:10:12,200 +大量的测试用例在去支持的 + +310 +00:10:12,233 --> 00:10:14,733 +所以当你一段问题写错的时候 + +311 +00:10:14,800 --> 00:10:18,900 +它可能有 30-50 个代码块 + +312 +00:10:18,900 --> 00:10:20,766 +去覆盖你这么一行 + +313 +00:10:20,766 --> 00:10:22,166 +看起来无足轻重的代码 + +314 +00:10:22,166 --> 00:10:23,000 +一旦有什么问题 + +315 +00:10:23,033 --> 00:10:25,833 +就很明显的可以看出错误 + +316 +00:10:25,900 --> 00:10:26,766 +大多数的观众 + +317 +00:10:26,766 --> 00:10:29,000 +我们写的都是一些上层业务代码 + +318 +00:10:29,000 --> 00:10:31,400 +首先我认为你测试用例可能并不多 + +319 +00:10:31,400 --> 00:10:33,533 +你有个 50% 的覆盖率 + +320 +00:10:33,566 --> 00:10:35,766 +我相信都已经是凤毛麟角了 + +321 +00:10:35,800 --> 00:10:36,700 +那另一方面 + +322 +00:10:36,700 --> 00:10:39,000 +他逻辑很多时候是写不了测试 + +323 +00:10:39,033 --> 00:10:40,466 +有时候你甚至问产品经理 + +324 +00:10:40,533 --> 00:10:42,966 +他都不知道这段逻辑应该是什么样子 + +325 +00:10:43,000 --> 00:10:44,366 +我相信这是大家 + +326 +00:10:44,366 --> 00:10:46,200 +平常工作生活的一个常态 + +327 +00:10:46,233 --> 00:10:49,500 +所以像 Bun 这种它有明确的预期的东西 + +328 +00:10:49,566 --> 00:10:52,466 +是有可能来去拿 AI 重写的 + +329 +00:10:52,533 --> 00:10:55,700 +那像我们现实应用中绝大部分产品 + +330 +00:10:55,700 --> 00:10:56,500 +其实不太能这么做 + +331 +00:10:56,533 --> 00:10:57,900 +它是一个非常危险的东西 + +332 +00:10:57,900 --> 00:11:00,133 +因为你不知道 AI 写出来是什么 + +333 +00:11:00,133 --> 00:11:01,800 +你也没办法去验证 AI 写出来是什么 + +334 +00:11:01,833 --> 00:11:04,200 +你要花非常大的精力 + +335 +00:11:04,200 --> 00:11:05,800 +来去靠人工来验证 + +336 +00:11:05,833 --> 00:11:09,866 +甚至你都不一定知道验证的是不是对的 + +337 +00:11:09,866 --> 00:11:10,633 +在现实生活中 + +338 +00:11:10,633 --> 00:11:14,000 +我并不建议大家去真的自己来做这个实现 + +339 +00:11:14,033 --> 00:11:15,633 +那另一方面就是成本 + +340 +00:11:15,700 --> 00:11:19,966 +是你要知道操作这个 AI 的这个人 + +341 +00:11:19,966 --> 00:11:21,333 +他需要相当高的技术能力 + +342 +00:11:21,366 --> 00:11:24,100 +他知道怎么样去组织 AI agent + +343 +00:11:24,100 --> 00:11:27,133 +他知道这个具体的业务逻辑是什么样 + +344 +00:11:27,133 --> 00:11:29,400 +他知道这个业务逻辑应该怎么运行 + +345 +00:11:29,433 --> 00:11:32,800 +找到这样一个人还是相当困难的 + +346 +00:11:32,833 --> 00:11:33,800 +同样呢 + +347 +00:11:33,800 --> 00:11:36,266 +这个 API Fable 5 的价格是非常夸张的高 + +348 +00:11:36,266 --> 00:11:36,633 +OK + +349 +00:11:36,633 --> 00:11:36,933 +想到这里 + +350 +00:11:36,933 --> 00:11:38,900 +你觉得自己非常有信心 + +351 +00:11:38,900 --> 00:11:39,566 +你有充足的财力 + +352 +00:11:39,633 --> 00:11:41,666 +你也对自己的这个能力有信心 + +353 +00:11:41,666 --> 00:11:43,466 +你真的要开始去重写 + +354 +00:11:43,466 --> 00:11:44,366 +那我就建议你说 + +355 +00:11:44,366 --> 00:11:47,533 +你其实可以采用 Jarred 这样的一种方法 + +356 +00:11:47,533 --> 00:11:49,033 +去做你的一个迁移 + +357 +00:11:49,100 --> 00:11:52,400 +那首先去跟现有代码库聊出来方案 + +358 +00:11:52,466 --> 00:11:54,866 +然后去通过对抗性的 review + +359 +00:11:54,866 --> 00:11:56,333 +互相找出问题 + +360 +00:11:56,366 --> 00:11:59,833 +然后做成一份完整的迁移的一个计划 + +361 +00:11:59,900 --> 00:12:01,600 +通过编译错误 + +362 +00:12:01,666 --> 00:12:03,733 +通过执行测试用例 + +363 +00:12:03,766 --> 00:12:06,433 +通过中间各种各样的对抗性 review + +364 +00:12:06,433 --> 00:12:08,466 +来最终的把它迁移出来 + +365 +00:12:08,466 --> 00:12:09,933 +你可以参考这个方案 + +366 +00:12:09,966 --> 00:12:11,166 +当然最重要的点就是 + +367 +00:12:11,166 --> 00:12:13,000 +当 AI 它犯错的时候 + +368 +00:12:13,000 --> 00:12:14,366 +你要把它当成一个人来去看 + +369 +00:12:14,433 --> 00:12:16,600 +不仅要说 coding agent + +370 +00:12:16,600 --> 00:12:16,833 + 这个实现有问题 + +371 +00:12:16,866 --> 00:12:19,033 +同样我们也要去反思 + +372 +00:12:19,033 --> 00:12:20,966 +自己的 rules 里边是不是哪里有问题 + +373 +00:12:20,966 --> 00:12:22,766 +我们需要改自己的规则了 + +374 +00:12:22,766 --> 00:12:25,833 +我们要去改自己的业务 + +375 +00:12:25,833 --> 00:12:28,866 +因为在做这样一个重写项目的时候 + +376 +00:12:28,866 --> 00:12:30,500 +其实我们不仅自己是实现者 + +377 +00:12:30,533 --> 00:12:33,133 +同样我们也是一个管理者 + +378 +00:12:33,133 --> 00:12:33,566 +好 + +379 +00:12:33,566 --> 00:12:36,733 +那今天关于Bun来重写的内容 + +380 +00:12:36,733 --> 00:12:38,200 +关于我的解读就大概到这里 + +381 +00:12:38,200 --> 00:12:39,900 +我很期望大家看一看这篇文章 + +382 +00:12:39,900 --> 00:12:41,166 +因为这篇文章挺有意义的 + +383 +00:12:41,233 --> 00:12:44,033 +它对于你自己构建自己的 Harness 项目 + +384 +00:12:44,033 --> 00:12:45,700 +是有非常大的帮助的 + +385 +00:12:45,733 --> 00:12:48,100 +那它同样的对于软件工程 + +386 +00:12:48,100 --> 00:12:50,300 +怎么样在 AI 时代的这个发展 + +387 +00:12:50,300 --> 00:12:51,200 +也是有大的用处的 + +388 +00:12:51,266 --> 00:12:52,700 +大家有空可以去看一看 + +389 +00:12:52,733 --> 00:12:54,633 +当然你看了之后 + +390 +00:12:54,633 --> 00:12:56,766 +你发现有什么和我聊的不对的地方 + +391 +00:12:56,766 --> 00:12:58,233 +或者说你有一些自己的想法 + +392 +00:12:58,233 --> 00:13:00,433 +也欢迎在评论区来留言讨论 + +393 +00:13:00,466 --> 00:13:00,733 +OK + +394 +00:13:00,866 --> 00:13:02,366 +那我们下期节目再见 + +395 +00:13:02,366 --> 00:13:02,800 +拜拜 + diff --git a/src/assets/ep74/cover.png b/src/assets/ep74/cover.png new file mode 100644 index 0000000..216d0b0 Binary files /dev/null and b/src/assets/ep74/cover.png differ diff --git a/src/content/posts/ep74.mdx b/src/content/posts/ep74.mdx new file mode 100644 index 0000000..f66dbd2 --- /dev/null +++ b/src/content/posts/ep74.mdx @@ -0,0 +1,57 @@ +--- +type: podcast-episode +status: published +slug: /posts/ep74 +guid: 74 +title: "EP74 64 个 Claude：Bun 的 11 天重写" +subtitle: "从 Zig 到 Rust，53 万行代码 11 天全量翻译，聊聊 AI 重写的成本结构与验证边界" +publicationDate: 2026-09-02 17:30:00 +author: AnnatarHe +season: 3 +episodeNumber: 74 +episodeType: full +excerpt: "Bun 1.4 把 53 万行 Zig 全量重写成 Rust：11 天、峰值 64 个 Claude、16.5 万美金账单。聊对抗性 review、编译器报错当任务队列，以及为什么你的项目不该照抄。" +url: https://youtu.be/05cX2jtlm0U +size: 0 +duration: 0 +explicit: false +xyzLink: https://www.xiaoyuzhoufm.com/episode/6a97ecdf1adab645ddbef882 +youtubeId: 05cX2jtlm0U +biliUrl: //player.bilibili.com/player.html?isOutside=true&aid=117196722279965&bvid=BV1WetG61Eh5&cid=41501659032&p=1 +cover: ../../assets/ep74/cover.png +srt: /subtitles/ep74.srt +categories: + - Bun + - Rust + - AI编程 + - Claude + - ClaudeCode + - Agent + - 前端 + - JavaScript + - Nodejs + - 程序员 + - AsyncTalk +--- + +### 📕 Shownotes + +Bun 1.4 发布了。作者 Jarred 说这是「变化最小的一个版本」——对用户来说确实是，但整个 runtime 底层已经从 Zig 换成了 Rust。 + +11 天，峰值 64 个 Claude 同时在同一个仓库里干活，53 万行 Zig 全量翻译成 Rust，API 账单约 16.5 万美金。放在 AI 之前，这种项目只有一个结局：不做。 + +这期挑了原文里我觉得最有意思的几点聊： + +- 为什么非要换 Rust —— JavaScriptCore 是带 GC 的，Zig 是手动管内存，两个混在一起，光 use-after-free 和内存泄漏就够喝一壶 +- 对抗性 review —— 写代码的 Claude 和挑刺的 Claude 上下文完全隔离，reviewer 只拿到 diff，并且被要求「默认这段代码是错的」 +- 翻车现场 —— 64 个实例互相 git stash、把编译不过的函数偷偷 stub 掉、写注释写到把磁盘 IOPS 打满 +- 编译器报错反而是 AI 最好的反馈信号，一万六千个 error 就是一个天然的任务队列 +- 最关键的一条：AI 犯错的时候，要改的不是那段代码，是你的 rules + +以及所有人都想问的那个问题：我自己的项目能不能也这么重写？ + +我的答案是别。Bun 有百万级断言的测试用例兜底，一行写错立刻有几十个 case 报警；而我们写的业务代码，覆盖率能到 50% 都算凤毛麟角，很多逻辑你去问产品经理，他自己都说不清预期是什么。没有验证手段的重写，跟 100 倍杠杆做空纳指有什么区别。 + +AI 改变的是重写这件事的成本结构，不是正确性的判定标准。 + +原文很值得自己读一遍，对你搭自己的 harness 帮助很大。有不同看法欢迎在评论区聊。