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
拜拜