1
00:00:00,000 --> 00:00:12,200
本集節目由VOAI絕好生創技術支援。VOAI提供富有情緒的高擬真台灣口音AI聲音,並提供上傳圖片與音檔一鍵生成虛擬人的功能,是最具台灣味的AI平台。

2
00:00:12,800 --> 00:00:15,000
使用優惠碼 AI-LRB26。

3
00:00:15,000 --> 00:00:19,200
吉祥VOAI網站以及API方案95折優惠。

4
00:00:19,200 --> 00:00:23,800
大家聽到的這集Podcast是透過VOAI API生成的哦。

5
00:00:23,800 --> 00:00:25,800
更多資訊請下資訊欄。

6
00:00:25,800 --> 00:00:29,980
每天都有一堆新的AI工具冒出来

7
00:00:29,980 --> 00:00:32,600
是不是常常不知道该从哪里开始

8
00:00:32,600 --> 00:00:33,560
别担心

9
00:00:33,560 --> 00:00:35,300
这里是AI懒人报

10
00:00:35,300 --> 00:00:39,220
每天帮你精选五个最多人讨论的AI工具影片

11
00:00:39,220 --> 00:00:40,520
每天十分钟

12
00:00:40,520 --> 00:00:42,680
让AI走进你的生活中

13
00:00:42,680 --> 00:00:45,140
让你不知不觉成为效率大师

14
00:00:45,140 --> 00:00:47,280
今天这个工具最有趣的地方是

15
00:00:47,280 --> 00:00:50,260
它可能让你再也不用半夜起来

16
00:00:50,260 --> 00:00:51,300
修坏掉的Jason

17
00:00:51,300 --> 00:00:54,680
这对我们这些每天跟AI流程打交道的人来说

18
00:00:54,680 --> 00:00:55,480
简直是福音

19
00:00:55,480 --> 00:00:56,840
好,那我们刚开始吧

20
00:00:56,840 --> 00:01:00,180
先从一个很多人都有过的痛苦经验说起

21
00:01:00,180 --> 00:01:03,140
你花了好几个小时设计一个自动化流程

22
00:01:03,140 --> 00:01:04,700
测试的时候跑得很完美

23
00:01:04,700 --> 00:01:06,440
你觉得这次终于搞定了

24
00:01:06,440 --> 00:01:07,440
然后你把它排成

25
00:01:07,440 --> 00:01:09,280
让它每天早上自动跑

26
00:01:09,280 --> 00:01:10,640
第一天没问题

27
00:01:10,640 --> 00:01:11,400
第二天没问题

28
00:01:11,400 --> 00:01:12,900
第三天早上你打开电脑

29
00:01:12,900 --> 00:01:13,920
一堆错误

30
00:01:13,920 --> 00:01:14,400
为什么?

31
00:01:14,640 --> 00:01:15,780
因为AI今天心情好

32
00:01:15,780 --> 00:01:19,300
把一个应该是数字的栏位输出成字串了

33
00:01:19,300 --> 00:01:21,120
或者他觉得自己很聪明

34
00:01:21,120 --> 00:01:23,740
在Jason里多加了一个他觉得有用的栏位

35
00:01:23,740 --> 00:01:26,080
结果你的后端完全吃不下去

36
00:01:26,080 --> 00:01:27,980
所以你不是去改流程

37
00:01:27,980 --> 00:01:29,360
你是去写验证逻辑

38
00:01:29,360 --> 00:01:30,380
写从事机制

39
00:01:30,380 --> 00:01:31,600
写各种备缘处理

40
00:01:31,600 --> 00:01:32,820
花了整个周末

41
00:01:32,820 --> 00:01:35,560
结果整个系统变得比手动作还复杂

42
00:01:35,560 --> 00:01:36,300
说真的

43
00:01:36,300 --> 00:01:38,120
我觉得这是用AI做自动化

44
00:01:38,120 --> 00:01:39,580
最让人崩溃的地方

45
00:01:39,580 --> 00:01:40,960
你明明是为了省时间

46
00:01:40,960 --> 00:01:43,500
结果花更多时间在管理AI的输出

47
00:01:43,500 --> 00:01:45,300
这个问题的根源在哪

48
00:01:45,300 --> 00:01:48,240
在于现在主流的大型原模型

49
00:01:48,240 --> 00:01:50,080
包括Chattgpt Cloud

50
00:01:50,080 --> 00:01:52,940
还有最近很红的Astra跟Fable

51
00:01:52,940 --> 00:01:56,500
他們的設計邏輯都是預測下一個Token

52
00:01:56,500 --> 00:01:58,900
就算你在Prompt里寫得再清楚

53
00:01:58,900 --> 00:02:00,440
請只輸出JSON

54
00:02:00,440 --> 00:02:04,040
他還是有一定機率會偷偷加一個Markdown的反引號

55
00:02:04,040 --> 00:02:06,080
或者換行多一個空格

56
00:02:06,080 --> 00:02:08,500
或者把Tru寫成加引號的Tru

57
00:02:08,500 --> 00:02:10,340
這並不是模型笨

58
00:02:10,340 --> 00:02:11,740
這其實是他的架構

59
00:02:11,740 --> 00:02:13,360
本質上就是機率性的

60
00:02:13,360 --> 00:02:15,160
沒辦法百分之百保證格式

61
00:02:15,160 --> 00:02:18,640
就像你請一個很會寫文章的朋友幫你填表格

62
00:02:18,640 --> 00:02:20,200
他可能會寫得很精彩

63
00:02:20,200 --> 00:02:22,300
但格式就不一定每次都對了

64
00:02:22,300 --> 00:02:24,540
Jerby就是衝著這個問題來的

65
00:02:24,540 --> 00:02:27,640
Jerby是Type Safe AI這家公司開發的

66
00:02:27,640 --> 00:02:30,240
他們把它歸類為System 1 Model

67
00:02:30,240 --> 00:02:33,440
跟我們熟悉的大型原模型是完全不同的東西

68
00:02:33,440 --> 00:02:35,240
他不是用來聊天的

69
00:02:35,240 --> 00:02:38,140
也不是用來寫文章或解釋概念的

70
00:02:38,140 --> 00:02:40,360
他只做一件事看你給他的資料

71
00:02:40,360 --> 00:02:42,160
對照你定義的schema

72
00:02:42,160 --> 00:02:45,360
輸出一個結構完全正確的決策結果

73
00:02:45,360 --> 00:02:48,900
你可以把它想像成一個非常嚴謹的表格填寫圓

74
00:02:48,900 --> 00:02:50,160
你給他什麼格式

75
00:02:50,160 --> 00:02:51,760
他就保證給你什麼格式

76
00:02:51,760 --> 00:02:54,300
这里最关键的技术概念叫做

77
00:02:54,300 --> 00:02:55,440
Constraint Decoding

78
00:02:55,440 --> 00:02:57,660
也就是在推理层面就做好限制

79
00:02:57,660 --> 00:02:59,200
一般的模型

80
00:02:59,200 --> 00:03:01,220
在生成每一个Token的时候

81
00:03:01,220 --> 00:03:02,940
理论上可以选任何字

82
00:03:02,940 --> 00:03:04,940
但Jav的做法是

83
00:03:04,940 --> 00:03:07,240
你传给他一个Schema

84
00:03:07,240 --> 00:03:10,020
你可以先把它想成资料格式规则

85
00:03:10,020 --> 00:03:12,080
他在生成每个Token的时候

86
00:03:12,080 --> 00:03:16,020
会直接把所有金会违反这个规则的选项

87
00:03:16,020 --> 00:03:17,600
从词汇表里遮掉

88
00:03:17,600 --> 00:03:21,200
如果这个栏位的形别是不灵质

89
00:03:21,200 --> 00:03:24,100
那他在那个位置能选的词就只有

90
00:03:24,100 --> 00:03:24,880
2跟false

91
00:03:24,880 --> 00:03:26,820
其他字根本不在选项里

92
00:03:26,820 --> 00:03:28,900
这并不是说他很努力不出错

93
00:03:28,900 --> 00:03:31,240
这是他在架构上就不可能出错

94
00:03:31,240 --> 00:03:33,460
这两件事的差别非常大

95
00:03:33,460 --> 00:03:35,500
前面那种你还是需要验证

96
00:03:35,500 --> 00:03:37,800
后面这种你可以直接信任输出

97
00:03:37,800 --> 00:03:40,400
就像你相信一个计算机算出来的结果一样

98
00:03:40,400 --> 00:03:43,220
TypeSafe AI把这个特性叫做schema safe

99
00:03:43,220 --> 00:03:46,780
意思就是输出永远符合你定义的行别结构

100
00:03:46,780 --> 00:03:49,000
即对开发者来说

101
00:03:49,000 --> 00:03:51,620
这意味着你可以把原本那些验证成

102
00:03:51,620 --> 00:03:52,680
从事逻辑

103
00:03:52,680 --> 00:03:54,560
得适修正的程式码

104
00:03:54,560 --> 00:03:55,780
大部分都砍掉

105
00:03:55,780 --> 00:03:56,980
你定义好行别

106
00:03:56,980 --> 00:03:57,860
交给Jeff

107
00:03:57,860 --> 00:04:00,580
就会拿到一个结构完全正确的结果

108
00:04:00,580 --> 00:04:01,220
每次都是

109
00:04:01,220 --> 00:04:04,240
这就像你请了一个永远不会犯错的秘书

110
00:04:04,240 --> 00:04:06,940
他交给你的文件永远都是格式正确的

111
00:04:06,940 --> 00:04:08,620
你完全不用再检查一遍

112
00:04:08,620 --> 00:04:10,760
Jeff提供三个主要的功能界面

113
00:04:10,760 --> 00:04:12,240
第一个叫Choice

114
00:04:12,240 --> 00:04:13,520
你给他一个输入

115
00:04:13,520 --> 00:04:15,200
再给他一个选项清单

116
00:04:15,200 --> 00:04:17,520
他直接回传最符合的那个选项

117
00:04:17,520 --> 00:04:19,420
最多可以有255个选项

118
00:04:19,420 --> 00:04:21,460
这是像一个超级精准的选择题机器

119
00:04:21,460 --> 00:04:22,340
你问他问题

120
00:04:22,340 --> 00:04:24,420
他马上给你正确答案

121
00:04:24,420 --> 00:04:25,500
第二个叫score

122
00:04:25,500 --> 00:04:27,580
他会对输入打一个分数

123
00:04:27,580 --> 00:04:29,060
同时附上confidence

124
00:04:29,060 --> 00:04:30,420
也就是信心分数

125
00:04:30,420 --> 00:04:32,800
让你知道他对这个分数有多确定

126
00:04:32,800 --> 00:04:34,600
这就像一个很专业的评论员

127
00:04:34,600 --> 00:04:35,480
不只给分数

128
00:04:35,480 --> 00:04:36,300
还会告诉你

129
00:04:36,300 --> 00:04:38,520
他打这个分数的把握有多大

130
00:04:38,520 --> 00:04:40,360
第三个叫no-o

131
00:04:40,360 --> 00:04:41,180
这个比较特别

132
00:04:41,180 --> 00:04:44,060
他会输出一个0到1之间的几率值

133
00:04:44,060 --> 00:04:46,220
代表某件事发生的可能性

134
00:04:46,220 --> 00:04:48,460
而且這個機率是經過較準的

135
00:04:48,460 --> 00:04:49,980
不是隨便說說的

136
00:04:50,220 --> 00:04:53,160
意思是如果NO說退款機率是0.8

137
00:04:53,160 --> 00:04:54,860
就代表10封類似的信裡

138
00:04:54,860 --> 00:04:57,360
大概有8封真的會是退款需求

139
00:04:57,360 --> 00:04:58,520
這個數字是可靠的

140
00:04:58,520 --> 00:04:59,980
這三個功能合在一起

141
00:04:59,980 --> 00:05:01,280
你就可以做很多事了

142
00:05:01,580 --> 00:05:03,320
比如說你有一個客服系統

143
00:05:03,320 --> 00:05:04,860
每天收到幾千封信

144
00:05:04,860 --> 00:05:05,980
你想要自動分類

145
00:05:05,980 --> 00:05:07,160
判斷優先順序

146
00:05:07,160 --> 00:05:08,720
偵測有沒有退款需求

147
00:05:08,720 --> 00:05:10,520
用傳統的大型語言模型

148
00:05:10,520 --> 00:05:11,820
你要寫很長的prompt

149
00:05:11,820 --> 00:05:13,680
還要解析它輸出的文字

150
00:05:13,680 --> 00:05:15,480
然後還要擔心它今天心情不好

151
00:05:15,480 --> 00:05:16,540
输出格式跑掉

152
00:05:16,540 --> 00:05:17,440
用GF

153
00:05:17,440 --> 00:05:19,200
你就把信的内容传进去

154
00:05:19,200 --> 00:05:20,180
定义好schema

155
00:05:20,180 --> 00:05:21,540
他直接给你一个Json

156
00:05:21,540 --> 00:05:22,600
类别是什么

157
00:05:22,600 --> 00:05:23,740
优先顺序

158
00:05:23,740 --> 00:05:24,360
几分

159
00:05:24,360 --> 00:05:25,840
是不是退款请求

160
00:05:25,840 --> 00:05:27,100
信心分数多少

161
00:05:27,100 --> 00:05:28,360
全部结构完整

162
00:05:28,360 --> 00:05:29,160
直接可以用

163
00:05:29,160 --> 00:05:31,300
这就像你把一大堆文件

164
00:05:31,300 --> 00:05:33,060
丢给一个超级有效率的助理

165
00:05:33,060 --> 00:05:35,260
他马上就能把所有资讯整理好

166
00:05:35,260 --> 00:05:35,900
分门别类

167
00:05:35,900 --> 00:05:37,020
让你一眼就能看懂

168
00:05:37,020 --> 00:05:38,660
社群里有人做了一个测试

169
00:05:38,660 --> 00:05:40,000
一次处理1000封信

170
00:05:40,000 --> 00:05:42,580
平均回应时间大约是200毫秒

171
00:05:42,580 --> 00:05:44,180
整批跑完费用是多少

172
00:05:44,180 --> 00:05:45,460
非常少

173
00:05:45,460 --> 00:05:47,160
因为JF的定价非常低

174
00:05:47,160 --> 00:05:49,580
输入是每百万Token四分美金

175
00:05:49,580 --> 00:05:50,740
输出是免费的

176
00:05:50,740 --> 00:05:53,240
这个价格跟主流的大型原模型

177
00:05:53,240 --> 00:05:54,480
比起来差距非常大

178
00:05:54,480 --> 00:05:55,800
简直是佛星价

179
00:05:55,800 --> 00:05:57,380
说到速度

180
00:05:57,380 --> 00:05:59,460
TypeSafe AI官方的说法是

181
00:05:59,460 --> 00:06:02,500
JF可以比传统Transformer模型

182
00:06:02,500 --> 00:06:04,220
快20到200倍

183
00:06:04,220 --> 00:06:06,300
便宜40到400倍

184
00:06:06,300 --> 00:06:09,000
我知道这种数字看起来像行销化数

185
00:06:09,000 --> 00:06:10,000
所以要说清楚

186
00:06:10,000 --> 00:06:10,980
这个速度优势

187
00:06:10,980 --> 00:06:13,460
是在特定的结构化决策任务上

188
00:06:13,460 --> 00:06:14,960
而不是在所有任务上

189
00:06:14,960 --> 00:06:16,900
你不能拿Jeff来写一篇文章

190
00:06:16,900 --> 00:06:17,620
他根本不会

191
00:06:17,620 --> 00:06:19,480
但如果你的任务是

192
00:06:19,480 --> 00:06:20,560
看这段资料

193
00:06:20,560 --> 00:06:22,500
告诉我他属于哪个类别

194
00:06:22,500 --> 00:06:25,200
那这个速度差距是真实存在的

195
00:06:25,200 --> 00:06:26,360
这就像你请一个

196
00:06:26,360 --> 00:06:28,100
短跑选手去跑马拉松

197
00:06:28,100 --> 00:06:29,320
他可能跑不完

198
00:06:29,320 --> 00:06:32,440
但如果你让他去跑100公尺

199
00:06:32,440 --> 00:06:33,780
他觉得是世界级的

200
00:06:33,780 --> 00:06:35,260
为什么Jeff可以这么快

201
00:06:35,260 --> 00:06:36,620
因为他根本不需要

202
00:06:36,620 --> 00:06:38,320
做一般语言模型做的那一事

203
00:06:38,320 --> 00:06:40,040
他不需要生成自然语言

204
00:06:40,040 --> 00:06:42,400
不需要维护复杂的上下文

205
00:06:42,400 --> 00:06:44,220
也不需要做什么深度推理

206
00:06:44,220 --> 00:06:45,780
他的工作就是看schema

207
00:06:45,780 --> 00:06:47,560
看输入输出

208
00:06:47,560 --> 00:06:49,380
一个符合schema的决策

209
00:06:49,380 --> 00:06:51,420
整个推理路径短很多

210
00:06:51,420 --> 00:06:52,300
所以快很多

211
00:06:52,300 --> 00:06:55,140
这就像一个专注于单一任务的机器人

212
00:06:55,140 --> 00:06:57,540
他只做他被设计来做的事

213
00:06:57,540 --> 00:06:58,860
所以效率极高

214
00:06:58,860 --> 00:07:02,020
这个速度差距在某些使用情境上

215
00:07:02,020 --> 00:07:05,060
会让整件事从可以用变成真正好用

216
00:07:05,060 --> 00:07:07,740
最明显的例子是浏览器自动化

217
00:07:07,740 --> 00:07:09,120
现在有很多工具

218
00:07:09,120 --> 00:07:11,160
可以让AI控制你的浏览器

219
00:07:11,160 --> 00:07:11,980
你给他一个目标

220
00:07:11,980 --> 00:07:13,680
他自己去点页面

221
00:07:13,680 --> 00:07:14,380
填资料

222
00:07:14,380 --> 00:07:15,300
跳到下一页

223
00:07:15,300 --> 00:07:17,060
但如果你真的试过用

224
00:07:17,060 --> 00:07:18,500
Astra或Fable做这件事

225
00:07:18,500 --> 00:07:20,000
你会发现他慢得很痛苦

226
00:07:20,000 --> 00:07:20,540
Agent

227
00:07:20,540 --> 00:07:22,120
结一张网页的截图

228
00:07:22,120 --> 00:07:23,160
传给模型

229
00:07:23,160 --> 00:07:24,600
然后你等2秒

230
00:07:24,600 --> 00:07:25,220
3秒

231
00:07:25,220 --> 00:07:25,900
有时候5秒

232
00:07:25,900 --> 00:07:27,420
模型才决定要点哪里

233
00:07:27,420 --> 00:07:28,720
这段时间里

234
00:07:28,720 --> 00:07:30,200
网页可能已经更新了

235
00:07:30,200 --> 00:07:31,500
或者跳出一个弹窗

236
00:07:31,500 --> 00:07:33,660
然后Agent的动作就失效了

237
00:07:33,660 --> 00:07:35,900
这就像你请一个动作很慢的人

238
00:07:35,900 --> 00:07:37,240
帮你抢限量商品

239
00:07:37,240 --> 00:07:38,520
等到他反应过来

240
00:07:38,520 --> 00:07:39,940
商品早就被抢光了

241
00:07:39,940 --> 00:07:42,880
这就是为什么浏览器自动化到现在

242
00:07:42,880 --> 00:07:45,580
还是很难真正稳定部署的原因之一

243
00:07:45,580 --> 00:07:46,620
延迟太高

244
00:07:46,620 --> 00:07:49,100
反映跟不上动态网页的节奏

245
00:07:49,100 --> 00:07:51,680
但如果你把决策层换成JF

246
00:07:51,680 --> 00:07:54,100
延迟从秒级将到毫秒级

247
00:07:54,100 --> 00:07:56,300
Agent看到DOM结构

248
00:07:56,300 --> 00:07:57,640
马上对照Schema

249
00:07:57,640 --> 00:07:59,820
马上输出下一个动作

250
00:07:59,820 --> 00:08:00,660
他不需要思考

251
00:08:00,660 --> 00:08:01,520
他就是执行

252
00:08:01,520 --> 00:08:03,980
这样的速度才能让浏览器自动化

253
00:08:03,980 --> 00:08:05,700
从一个很酷的示范

254
00:08:05,700 --> 00:08:08,980
变成一个可以真正跑在生产环境的东西

255
00:08:08,980 --> 00:08:12,460
这就像你给机器人装上超快速反应晶片

256
00:08:12,460 --> 00:08:15,360
它能瞬间判断并执行任务

257
00:08:15,360 --> 00:08:17,260
让整个流程顺畅无比

258
00:08:17,654 --> 00:08:21,654
好,現在來到我覺得最有意思的部分,也就是第二個重點。

259
00:08:21,654 --> 00:08:27,654
Jeff的定位很特別,他並不是要取代Astra或Fable,他其實是要跟他們一起用。

260
00:08:27,654 --> 00:08:31,654
你可以把它想像成一個團隊裡的兩個角色,一個負責策略,一個負責執行。

261
00:08:31,654 --> 00:08:33,854
我把這個架構叫做雙腦架構

262
00:08:33,854 --> 00:08:35,054
概念很直觀

263
00:08:35,054 --> 00:08:37,994
你用大型語言模型做需要深度推理的事

264
00:08:37,994 --> 00:08:40,434
用Jav做需要快速執行的事

265
00:08:40,434 --> 00:08:42,054
舉個具體的例子

266
00:08:42,054 --> 00:08:44,874
假設你在建一個自動化的軟體開發agent

267
00:08:44,874 --> 00:08:46,094
他可以看需求

268
00:08:46,094 --> 00:08:46,974
寫程式

269
00:08:46,974 --> 00:08:47,834
跑測試

270
00:08:47,834 --> 00:08:48,634
修bug

271
00:08:48,634 --> 00:08:50,954
當一個新的功能需求進來的時候

272
00:08:50,954 --> 00:08:53,014
你先把它交給Fable或Astra

273
00:08:53,014 --> 00:08:55,634
這些模型有深度的推理能力

274
00:08:55,634 --> 00:08:58,454
它們可以分析整個專案程式碼

275
00:08:58,454 --> 00:08:59,874
理解依賴關係

276
00:08:59,874 --> 00:09:01,434
想清楚要怎麼實作

277
00:09:01,434 --> 00:09:04,334
然后产出一份详细的执行计划

278
00:09:04,334 --> 00:09:06,434
就是慢的贵的但值得

279
00:09:06,434 --> 00:09:09,234
因为这个阶段真的需要深度思考

280
00:09:09,234 --> 00:09:12,554
这就像一个公司的策略长

281
00:09:12,554 --> 00:09:14,954
负责制定整体方向和计划

282
00:09:14,954 --> 00:09:16,374
计划出来之后

283
00:09:16,374 --> 00:09:17,134
Fable退场

284
00:09:17,134 --> 00:09:18,034
Jeff接手

285
00:09:18,034 --> 00:09:20,114
Jeff比较适合负责

286
00:09:20,114 --> 00:09:21,854
判断下一步要做什么

287
00:09:21,854 --> 00:09:23,754
输出固定格式的指令

288
00:09:23,754 --> 00:09:25,254
如果测试失败了

289
00:09:25,254 --> 00:09:28,034
Jeff不需要重新思考整个架构

290
00:09:28,034 --> 00:09:30,094
他只需要看错误讯息

291
00:09:30,094 --> 00:09:31,514
对照行别定义

292
00:09:31,514 --> 00:09:33,774
修掉那个行别不符的地方

293
00:09:33,774 --> 00:09:36,274
再跑一次几毫秒就完成

294
00:09:36,274 --> 00:09:40,314
真正写大段程式码还是交给Fable或Extra

295
00:09:40,314 --> 00:09:42,074
这就像公司的执行长

296
00:09:42,074 --> 00:09:43,734
负责把策略长的计划

297
00:09:43,734 --> 00:09:46,294
分解成一个个具体任务

298
00:09:46,294 --> 00:09:47,914
并快速高效的执行

299
00:09:47,914 --> 00:09:50,914
你把昂贵的推理集中在规划阶段

300
00:09:50,914 --> 00:09:53,394
把执行交给一个高速低成本

301
00:09:53,394 --> 00:09:55,094
格式保证正确的引擎

302
00:09:55,094 --> 00:09:59,454
这样的组合才能让多A-系统真正规模化

303
00:09:59,454 --> 00:10:02,774
以前这种架构的问题是成本和延迟

304
00:10:02,774 --> 00:10:06,094
如果一个复杂的任务需要50个为决策

305
00:10:06,094 --> 00:10:08,294
每个决策要2秒花3分美金

306
00:10:08,294 --> 00:10:10,014
整个流程就要花1分多钟

307
00:10:10,014 --> 00:10:11,954
1块多美金单次执行

308
00:10:11,954 --> 00:10:15,074
这样的单位经济学根本没办法做自动化

309
00:10:15,074 --> 00:10:16,694
因为跑几次就亏了

310
00:10:16,694 --> 00:10:19,974
但Jeff把每个为决策的成本和延迟

311
00:10:19,974 --> 00:10:21,754
都压到几乎可以忽略的程度

312
00:10:21,754 --> 00:10:23,734
这个架构才真正变得可行

313
00:10:23,734 --> 00:10:27,094
这就像以前你需要请好几个顾问来做决策

314
00:10:27,094 --> 00:10:29,194
现在你只需要请一个策略顾问

315
00:10:29,194 --> 00:10:32,694
然后把执行交给一个超便宜又超快的机器人

316
00:10:32,694 --> 00:10:35,834
那实际上怎么把JAB接近你现有的流程

317
00:10:35,834 --> 00:10:37,534
有几个很具体的切入点

318
00:10:37,534 --> 00:10:42,414
最直接的方式是找出你现有AI流程里最容易坏掉的节点

319
00:10:42,414 --> 00:10:47,294
通常就是那些让LLM从非结构化的资料里抽取资讯

320
00:10:47,294 --> 00:10:49,774
然后格式化成某个固定格式的步骤

321
00:10:49,774 --> 00:10:52,494
比如说从一封信里抓出客户名称

322
00:10:52,494 --> 00:10:53,474
订单编号

323
00:10:53,474 --> 00:10:54,554
问题类别

324
00:10:54,554 --> 00:10:56,194
然后写进CIM

325
00:10:56,194 --> 00:10:59,294
这种步骤犯成Jav是最直接的

326
00:10:59,294 --> 00:11:01,514
你定义好schema让Jav做抽取

327
00:11:01,514 --> 00:11:03,034
格式问题直接消失

328
00:11:03,034 --> 00:11:05,854
这就像你把一个经常出错的环节

329
00:11:05,854 --> 00:11:08,794
换成一个永远不会出错的自动化机器人

330
00:11:08,794 --> 00:11:10,374
瞬间解决了所有问题

331
00:11:10,374 --> 00:11:12,694
另一个很适合的使用情境是

332
00:11:12,694 --> 00:11:13,414
vibe coding

333
00:11:13,414 --> 00:11:16,534
就是你用AI辅助快速开发的那种模式

334
00:11:16,534 --> 00:11:18,654
现在的vibe coding流程通常是

335
00:11:18,654 --> 00:11:20,694
让AI生成程式码

336
00:11:20,694 --> 00:11:21,374
你去跑

337
00:11:21,374 --> 00:11:22,374
跑出错误

338
00:11:22,374 --> 00:11:23,834
把错误贴回去给AI

339
00:11:23,834 --> 00:11:24,454
等它修

340
00:11:24,454 --> 00:11:25,134
再跑

341
00:11:25,134 --> 00:11:27,014
这个回圈很慢而且很烦

342
00:11:27,014 --> 00:11:29,094
因为Jeff速度过快

343
00:11:29,094 --> 00:11:31,374
对程式语法的理解是原生的

344
00:11:31,374 --> 00:11:34,454
你可以在IDE里设定一个背景监听器

345
00:11:34,454 --> 00:11:37,034
每次有编译错误或测试失败

346
00:11:37,034 --> 00:11:38,594
自动把错误丢给Jeff

347
00:11:38,594 --> 00:11:40,634
让他在背景直接修掉

348
00:11:40,634 --> 00:11:42,414
你甚至不需要手动介入

349
00:11:42,414 --> 00:11:43,274
他已经修好了

350
00:11:43,274 --> 00:11:46,454
这就像你身边有一个超级程式码修正助手

351
00:11:46,454 --> 00:11:47,514
在你写程式的时候

352
00:11:47,514 --> 00:11:49,634
他随时帮你检查并修复错误

353
00:11:49,634 --> 00:11:51,634
让你专心在创作上

354
00:11:51,634 --> 00:11:53,494
这个部分说完

355
00:11:53,494 --> 00:11:54,494
我要讲一个很重要

356
00:11:54,494 --> 00:11:56,814
但很多人在兴奋的时候会忘掉的是

357
00:11:56,814 --> 00:11:57,934
速度越快

358
00:11:57,934 --> 00:11:59,714
出错的代价越高

359
00:11:59,714 --> 00:12:01,054
当你有一个模型

360
00:12:01,054 --> 00:12:03,574
可以在毫秒内生成并执行程式码

361
00:12:03,574 --> 00:12:06,554
你根本来不及在他出错之前阻止他

362
00:12:06,554 --> 00:12:09,054
如果Jeff在自动化流程里

363
00:12:09,054 --> 00:12:10,994
有权限存取你的档案系统

364
00:12:10,994 --> 00:12:12,394
执行终端机指令

365
00:12:12,394 --> 00:12:13,354
更新资料库

366
00:12:13,354 --> 00:12:15,574
而他以200倍的速度在跑

367
00:12:15,574 --> 00:12:16,674
那出了问题的时候

368
00:12:16,674 --> 00:12:18,194
你看到的已经是结果

369
00:12:18,194 --> 00:12:18,874
不是过程

370
00:12:18,874 --> 00:12:21,254
这就像你开一台超级跑车

371
00:12:21,254 --> 00:12:22,114
速度很快

372
00:12:22,114 --> 00:12:23,294
但如果失控

373
00:12:23,294 --> 00:12:25,354
造成的损害也会非常巨大

374
00:12:25,354 --> 00:12:27,834
所以安全边界必须跟着调整

375
00:12:27,834 --> 00:12:29,054
几个原则要记住

376
00:12:29,054 --> 00:12:29,654
第一

377
00:12:29,654 --> 00:12:31,534
就算是高准确定的模型

378
00:12:31,534 --> 00:12:32,934
AI生成的程式码

379
00:12:32,934 --> 00:12:35,514
预设要当成不信任的来处理

380
00:12:35,514 --> 00:12:37,294
不要因为它很少出错

381
00:12:37,294 --> 00:12:38,354
就给它最高权限

382
00:12:38,354 --> 00:12:39,474
第二

383
00:12:39,474 --> 00:12:42,034
如果你要在本机跑Jab做自动化

384
00:12:42,034 --> 00:12:45,254
Docker容器把执行环境隔离起来

385
00:12:45,254 --> 00:12:46,994
给它最小必要的权限

386
00:12:46,994 --> 00:12:48,054
不要给root

387
00:12:48,054 --> 00:12:49,134
第三

388
00:12:49,134 --> 00:12:51,694
如果Jab在做浏览器自动化

389
00:12:51,694 --> 00:12:54,674
不要用你平常已经登录的浏览器设定档

390
00:12:54,674 --> 00:12:57,614
用独立的一次性的工作阶段

391
00:12:57,614 --> 00:13:00,254
这样就算它误判了某个DOM元素

392
00:13:00,254 --> 00:13:02,114
也不会动到你的生产环境

393
00:13:02,114 --> 00:13:05,074
这就像你使用任何强大的工具一样

394
00:13:05,074 --> 00:13:06,814
必须先做好安全防护

395
00:13:06,814 --> 00:13:08,694
才能避免不必要的风险

396
00:13:08,694 --> 00:13:10,974
Jeff帮你省下了写程式码的时间

397
00:13:10,974 --> 00:13:12,574
但这些省下来的时间

398
00:13:12,574 --> 00:13:16,134
你要拿去建更完善的自动化测试和安全验证

399
00:13:16,134 --> 00:13:17,974
你的角色从写程式的人

400
00:13:17,974 --> 00:13:21,374
变成设计系统架构和做安全审计的人

401
00:13:21,374 --> 00:13:23,694
这就像以前你需要自己造车

402
00:13:23,694 --> 00:13:27,514
现在你只需要设计好车子的功能和安全系统

403
00:13:27,514 --> 00:13:29,174
然后让机器人去制造

404
00:13:29,174 --> 00:13:32,714
最后来说说我对Jeff这件事的整体看法

405
00:13:32,714 --> 00:13:35,674
过去一年多AI产业的主旋律

406
00:13:35,674 --> 00:13:37,694
是把模型做得越来越大

407
00:13:37,694 --> 00:13:38,834
越来越聪明

408
00:13:38,834 --> 00:13:39,774
越来越贵

409
00:13:39,774 --> 00:13:41,674
每个人都在追AGI

410
00:13:41,674 --> 00:13:44,734
都在比谁的模型推理能力更强

411
00:13:44,734 --> 00:13:47,974
Extra跟Fable在这条路上做得很好

412
00:13:47,974 --> 00:13:48,894
他们真的很厉害

413
00:13:48,894 --> 00:13:51,874
但真正在用AI做产品的人

414
00:13:51,874 --> 00:13:52,774
工程师

415
00:13:52,774 --> 00:13:54,274
独立开发者

416
00:13:54,274 --> 00:13:55,134
小团队

417
00:13:55,134 --> 00:13:57,774
我们不是每天都在解历史难题

418
00:13:57,774 --> 00:14:00,154
我们大部分时间需要的是

419
00:14:00,154 --> 00:14:02,274
这个资料是不是不领值

420
00:14:02,274 --> 00:14:05,554
这个请求应该要分派给哪个服务

421
00:14:05,554 --> 00:14:07,274
这封信的优先顺序

422
00:14:07,274 --> 00:14:08,534
是高还是低

423
00:14:08,534 --> 00:14:10,934
这些问题不需要深度推理

424
00:14:10,934 --> 00:14:12,454
需要的是快

425
00:14:12,454 --> 00:14:13,234
准

426
00:14:13,234 --> 00:14:14,454
格式正确

427
00:14:14,454 --> 00:14:16,174
这就像我们日常生活

428
00:14:16,174 --> 00:14:18,314
大部分时候我们需要的不是哲学家

429
00:14:18,314 --> 00:14:21,174
而是一个能快速精准回答问题的工具人

430
00:14:21,174 --> 00:14:23,834
Jeff代表的是AI执行层的工业化

431
00:14:23,834 --> 00:14:25,414
他承认一件事

432
00:14:25,414 --> 00:14:27,694
未来的自动化不会是一个超级大脑

433
00:14:27,694 --> 00:14:28,994
慢慢把所有事情都做完

434
00:14:28,994 --> 00:14:31,874
而是一堆高度专门化的引擎分工合作

435
00:14:31,874 --> 00:14:35,214
各自在自己最擅长的部分做到最好

436
00:14:35,214 --> 00:14:37,374
这就像一个现代化的工厂

437
00:14:37,374 --> 00:14:39,614
每个环节都有专门的机器人负责

438
00:14:39,614 --> 00:14:40,814
协同合作

439
00:14:40,814 --> 00:14:42,394
达到最高的效率

440
00:14:42,394 --> 00:14:43,994
对那些花了无数个夜晚

441
00:14:43,994 --> 00:14:46,454
在除错Jason格式问题的人来说

442
00:14:46,454 --> 00:14:48,534
这个东西出现的时机真的很刚好

443
00:14:48,534 --> 00:14:50,654
如果你觉得今天的内容让你有点收获

444
00:14:50,654 --> 00:14:52,794
那就帮我到Apple Podcast按赞追踪

445
00:14:52,794 --> 00:14:53,974
留个五星好评吧

446
00:14:53,974 --> 00:14:56,334
FB IG Flats

447
00:14:56,334 --> 00:14:58,554
收AI懒人报就找到我了

448
00:14:58,554 --> 00:15:00,794
你的支持是我持续优化

449
00:15:00,794 --> 00:15:02,354
内容的最大动力

450
00:15:02,354 --> 00:15:05,034
最近的AI发展依然快的让我害怕

451
00:15:05,034 --> 00:15:07,034
不想出过明天再继续

452
00:15:07,034 --> 00:15:08,594
收听AI懒人报啰

453
00:15:08,594 --> 00:15:09,674
我是汤懒懒

454
00:15:09,674 --> 00:15:10,574
我们明天见

455
00:15:10,574 --> 00:15:11,014
拜拜