WEBVTT

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

00:00:12.800 --> 00:00:15.000
使用優惠碼 AI-LRB26。

00:00:15.000 --> 00:00:19.200
吉祥VOAI網站以及API方案95折優惠。

00:00:19.200 --> 00:00:23.800
大家聽到的這集Podcast是透過VOAI API生成的哦。

00:00:23.800 --> 00:00:25.800
更多資訊請下資訊欄。

00:00:25.800 --> 00:00:29.980
每天都有一堆新的AI工具冒出来

00:00:29.980 --> 00:00:32.600
是不是常常不知道该从哪里开始

00:00:32.600 --> 00:00:33.560
别担心

00:00:33.560 --> 00:00:35.300
这里是AI懒人报

00:00:35.300 --> 00:00:39.220
每天帮你精选五个最多人讨论的AI工具影片

00:00:39.220 --> 00:00:40.520
每天十分钟

00:00:40.520 --> 00:00:42.680
让AI走进你的生活中

00:00:42.680 --> 00:00:45.140
让你不知不觉成为效率大师

00:00:45.140 --> 00:00:47.280
今天这个工具最有趣的地方是

00:00:47.280 --> 00:00:50.260
它可能让你再也不用半夜起来

00:00:50.260 --> 00:00:51.300
修坏掉的Jason

00:00:51.300 --> 00:00:54.680
这对我们这些每天跟AI流程打交道的人来说

00:00:54.680 --> 00:00:55.480
简直是福音

00:00:55.480 --> 00:00:56.840
好,那我们刚开始吧

00:00:56.840 --> 00:01:00.180
先从一个很多人都有过的痛苦经验说起

00:01:00.180 --> 00:01:03.140
你花了好几个小时设计一个自动化流程

00:01:03.140 --> 00:01:04.700
测试的时候跑得很完美

00:01:04.700 --> 00:01:06.440
你觉得这次终于搞定了

00:01:06.440 --> 00:01:07.440
然后你把它排成

00:01:07.440 --> 00:01:09.280
让它每天早上自动跑

00:01:09.280 --> 00:01:10.640
第一天没问题

00:01:10.640 --> 00:01:11.400
第二天没问题

00:01:11.400 --> 00:01:12.900
第三天早上你打开电脑

00:01:12.900 --> 00:01:13.920
一堆错误

00:01:13.920 --> 00:01:14.400
为什么?

00:01:14.640 --> 00:01:15.780
因为AI今天心情好

00:01:15.780 --> 00:01:19.300
把一个应该是数字的栏位输出成字串了

00:01:19.300 --> 00:01:21.120
或者他觉得自己很聪明

00:01:21.120 --> 00:01:23.740
在Jason里多加了一个他觉得有用的栏位

00:01:23.740 --> 00:01:26.080
结果你的后端完全吃不下去

00:01:26.080 --> 00:01:27.980
所以你不是去改流程

00:01:27.980 --> 00:01:29.360
你是去写验证逻辑

00:01:29.360 --> 00:01:30.380
写从事机制

00:01:30.380 --> 00:01:31.600
写各种备缘处理

00:01:31.600 --> 00:01:32.820
花了整个周末

00:01:32.820 --> 00:01:35.560
结果整个系统变得比手动作还复杂

00:01:35.560 --> 00:01:36.300
说真的

00:01:36.300 --> 00:01:38.120
我觉得这是用AI做自动化

00:01:38.120 --> 00:01:39.580
最让人崩溃的地方

00:01:39.580 --> 00:01:40.960
你明明是为了省时间

00:01:40.960 --> 00:01:43.500
结果花更多时间在管理AI的输出

00:01:43.500 --> 00:01:45.300
这个问题的根源在哪

00:01:45.300 --> 00:01:48.240
在于现在主流的大型原模型

00:01:48.240 --> 00:01:50.080
包括Chattgpt Cloud

00:01:50.080 --> 00:01:52.940
还有最近很红的Astra跟Fable

00:01:52.940 --> 00:01:56.500
他們的設計邏輯都是預測下一個Token

00:01:56.500 --> 00:01:58.900
就算你在Prompt里寫得再清楚

00:01:58.900 --> 00:02:00.440
請只輸出JSON

00:02:00.440 --> 00:02:04.040
他還是有一定機率會偷偷加一個Markdown的反引號

00:02:04.040 --> 00:02:06.080
或者換行多一個空格

00:02:06.080 --> 00:02:08.500
或者把Tru寫成加引號的Tru

00:02:08.500 --> 00:02:10.340
這並不是模型笨

00:02:10.340 --> 00:02:11.740
這其實是他的架構

00:02:11.740 --> 00:02:13.360
本質上就是機率性的

00:02:13.360 --> 00:02:15.160
沒辦法百分之百保證格式

00:02:15.160 --> 00:02:18.640
就像你請一個很會寫文章的朋友幫你填表格

00:02:18.640 --> 00:02:20.200
他可能會寫得很精彩

00:02:20.200 --> 00:02:22.300
但格式就不一定每次都對了

00:02:22.300 --> 00:02:24.540
Jerby就是衝著這個問題來的

00:02:24.540 --> 00:02:27.640
Jerby是Type Safe AI這家公司開發的

00:02:27.640 --> 00:02:30.240
他們把它歸類為System 1 Model

00:02:30.240 --> 00:02:33.440
跟我們熟悉的大型原模型是完全不同的東西

00:02:33.440 --> 00:02:35.240
他不是用來聊天的

00:02:35.240 --> 00:02:38.140
也不是用來寫文章或解釋概念的

00:02:38.140 --> 00:02:40.360
他只做一件事看你給他的資料

00:02:40.360 --> 00:02:42.160
對照你定義的schema

00:02:42.160 --> 00:02:45.360
輸出一個結構完全正確的決策結果

00:02:45.360 --> 00:02:48.900
你可以把它想像成一個非常嚴謹的表格填寫圓

00:02:48.900 --> 00:02:50.160
你給他什麼格式

00:02:50.160 --> 00:02:51.760
他就保證給你什麼格式

00:02:51.760 --> 00:02:54.300
这里最关键的技术概念叫做

00:02:54.300 --> 00:02:55.440
Constraint Decoding

00:02:55.440 --> 00:02:57.660
也就是在推理层面就做好限制

00:02:57.660 --> 00:02:59.200
一般的模型

00:02:59.200 --> 00:03:01.220
在生成每一个Token的时候

00:03:01.220 --> 00:03:02.940
理论上可以选任何字

00:03:02.940 --> 00:03:04.940
但Jav的做法是

00:03:04.940 --> 00:03:07.240
你传给他一个Schema

00:03:07.240 --> 00:03:10.020
你可以先把它想成资料格式规则

00:03:10.020 --> 00:03:12.080
他在生成每个Token的时候

00:03:12.080 --> 00:03:16.020
会直接把所有金会违反这个规则的选项

00:03:16.020 --> 00:03:17.600
从词汇表里遮掉

00:03:17.600 --> 00:03:21.200
如果这个栏位的形别是不灵质

00:03:21.200 --> 00:03:24.100
那他在那个位置能选的词就只有

00:03:24.100 --> 00:03:24.880
2跟false

00:03:24.880 --> 00:03:26.820
其他字根本不在选项里

00:03:26.820 --> 00:03:28.900
这并不是说他很努力不出错

00:03:28.900 --> 00:03:31.240
这是他在架构上就不可能出错

00:03:31.240 --> 00:03:33.460
这两件事的差别非常大

00:03:33.460 --> 00:03:35.500
前面那种你还是需要验证

00:03:35.500 --> 00:03:37.800
后面这种你可以直接信任输出

00:03:37.800 --> 00:03:40.400
就像你相信一个计算机算出来的结果一样

00:03:40.400 --> 00:03:43.220
TypeSafe AI把这个特性叫做schema safe

00:03:43.220 --> 00:03:46.780
意思就是输出永远符合你定义的行别结构

00:03:46.780 --> 00:03:49.000
即对开发者来说

00:03:49.000 --> 00:03:51.620
这意味着你可以把原本那些验证成

00:03:51.620 --> 00:03:52.680
从事逻辑

00:03:52.680 --> 00:03:54.560
得适修正的程式码

00:03:54.560 --> 00:03:55.780
大部分都砍掉

00:03:55.780 --> 00:03:56.980
你定义好行别

00:03:56.980 --> 00:03:57.860
交给Jeff

00:03:57.860 --> 00:04:00.580
就会拿到一个结构完全正确的结果

00:04:00.580 --> 00:04:01.220
每次都是

00:04:01.220 --> 00:04:04.240
这就像你请了一个永远不会犯错的秘书

00:04:04.240 --> 00:04:06.940
他交给你的文件永远都是格式正确的

00:04:06.940 --> 00:04:08.620
你完全不用再检查一遍

00:04:08.620 --> 00:04:10.760
Jeff提供三个主要的功能界面

00:04:10.760 --> 00:04:12.240
第一个叫Choice

00:04:12.240 --> 00:04:13.520
你给他一个输入

00:04:13.520 --> 00:04:15.200
再给他一个选项清单

00:04:15.200 --> 00:04:17.520
他直接回传最符合的那个选项

00:04:17.520 --> 00:04:19.420
最多可以有255个选项

00:04:19.420 --> 00:04:21.460
这是像一个超级精准的选择题机器

00:04:21.460 --> 00:04:22.340
你问他问题

00:04:22.340 --> 00:04:24.420
他马上给你正确答案

00:04:24.420 --> 00:04:25.500
第二个叫score

00:04:25.500 --> 00:04:27.580
他会对输入打一个分数

00:04:27.580 --> 00:04:29.060
同时附上confidence

00:04:29.060 --> 00:04:30.420
也就是信心分数

00:04:30.420 --> 00:04:32.800
让你知道他对这个分数有多确定

00:04:32.800 --> 00:04:34.600
这就像一个很专业的评论员

00:04:34.600 --> 00:04:35.480
不只给分数

00:04:35.480 --> 00:04:36.300
还会告诉你

00:04:36.300 --> 00:04:38.520
他打这个分数的把握有多大

00:04:38.520 --> 00:04:40.360
第三个叫no-o

00:04:40.360 --> 00:04:41.180
这个比较特别

00:04:41.180 --> 00:04:44.060
他会输出一个0到1之间的几率值

00:04:44.060 --> 00:04:46.220
代表某件事发生的可能性

00:04:46.220 --> 00:04:48.460
而且這個機率是經過較準的

00:04:48.460 --> 00:04:49.980
不是隨便說說的

00:04:50.220 --> 00:04:53.160
意思是如果NO說退款機率是0.8

00:04:53.160 --> 00:04:54.860
就代表10封類似的信裡

00:04:54.860 --> 00:04:57.360
大概有8封真的會是退款需求

00:04:57.360 --> 00:04:58.520
這個數字是可靠的

00:04:58.520 --> 00:04:59.980
這三個功能合在一起

00:04:59.980 --> 00:05:01.280
你就可以做很多事了

00:05:01.580 --> 00:05:03.320
比如說你有一個客服系統

00:05:03.320 --> 00:05:04.860
每天收到幾千封信

00:05:04.860 --> 00:05:05.980
你想要自動分類

00:05:05.980 --> 00:05:07.160
判斷優先順序

00:05:07.160 --> 00:05:08.720
偵測有沒有退款需求

00:05:08.720 --> 00:05:10.520
用傳統的大型語言模型

00:05:10.520 --> 00:05:11.820
你要寫很長的prompt

00:05:11.820 --> 00:05:13.680
還要解析它輸出的文字

00:05:13.680 --> 00:05:15.480
然後還要擔心它今天心情不好

00:05:15.480 --> 00:05:16.540
输出格式跑掉

00:05:16.540 --> 00:05:17.440
用GF

00:05:17.440 --> 00:05:19.200
你就把信的内容传进去

00:05:19.200 --> 00:05:20.180
定义好schema

00:05:20.180 --> 00:05:21.540
他直接给你一个Json

00:05:21.540 --> 00:05:22.600
类别是什么

00:05:22.600 --> 00:05:23.740
优先顺序

00:05:23.740 --> 00:05:24.360
几分

00:05:24.360 --> 00:05:25.840
是不是退款请求

00:05:25.840 --> 00:05:27.100
信心分数多少

00:05:27.100 --> 00:05:28.360
全部结构完整

00:05:28.360 --> 00:05:29.160
直接可以用

00:05:29.160 --> 00:05:31.300
这就像你把一大堆文件

00:05:31.300 --> 00:05:33.060
丢给一个超级有效率的助理

00:05:33.060 --> 00:05:35.260
他马上就能把所有资讯整理好

00:05:35.260 --> 00:05:35.900
分门别类

00:05:35.900 --> 00:05:37.020
让你一眼就能看懂

00:05:37.020 --> 00:05:38.660
社群里有人做了一个测试

00:05:38.660 --> 00:05:40.000
一次处理1000封信

00:05:40.000 --> 00:05:42.580
平均回应时间大约是200毫秒

00:05:42.580 --> 00:05:44.180
整批跑完费用是多少

00:05:44.180 --> 00:05:45.460
非常少

00:05:45.460 --> 00:05:47.160
因为JF的定价非常低

00:05:47.160 --> 00:05:49.580
输入是每百万Token四分美金

00:05:49.580 --> 00:05:50.740
输出是免费的

00:05:50.740 --> 00:05:53.240
这个价格跟主流的大型原模型

00:05:53.240 --> 00:05:54.480
比起来差距非常大

00:05:54.480 --> 00:05:55.800
简直是佛星价

00:05:55.800 --> 00:05:57.380
说到速度

00:05:57.380 --> 00:05:59.460
TypeSafe AI官方的说法是

00:05:59.460 --> 00:06:02.500
JF可以比传统Transformer模型

00:06:02.500 --> 00:06:04.220
快20到200倍

00:06:04.220 --> 00:06:06.300
便宜40到400倍

00:06:06.300 --> 00:06:09.000
我知道这种数字看起来像行销化数

00:06:09.000 --> 00:06:10.000
所以要说清楚

00:06:10.000 --> 00:06:10.980
这个速度优势

00:06:10.980 --> 00:06:13.460
是在特定的结构化决策任务上

00:06:13.460 --> 00:06:14.960
而不是在所有任务上

00:06:14.960 --> 00:06:16.900
你不能拿Jeff来写一篇文章

00:06:16.900 --> 00:06:17.620
他根本不会

00:06:17.620 --> 00:06:19.480
但如果你的任务是

00:06:19.480 --> 00:06:20.560
看这段资料

00:06:20.560 --> 00:06:22.500
告诉我他属于哪个类别

00:06:22.500 --> 00:06:25.200
那这个速度差距是真实存在的

00:06:25.200 --> 00:06:26.360
这就像你请一个

00:06:26.360 --> 00:06:28.100
短跑选手去跑马拉松

00:06:28.100 --> 00:06:29.320
他可能跑不完

00:06:29.320 --> 00:06:32.440
但如果你让他去跑100公尺

00:06:32.440 --> 00:06:33.780
他觉得是世界级的

00:06:33.780 --> 00:06:35.260
为什么Jeff可以这么快

00:06:35.260 --> 00:06:36.620
因为他根本不需要

00:06:36.620 --> 00:06:38.320
做一般语言模型做的那一事

00:06:38.320 --> 00:06:40.040
他不需要生成自然语言

00:06:40.040 --> 00:06:42.400
不需要维护复杂的上下文

00:06:42.400 --> 00:06:44.220
也不需要做什么深度推理

00:06:44.220 --> 00:06:45.780
他的工作就是看schema

00:06:45.780 --> 00:06:47.560
看输入输出

00:06:47.560 --> 00:06:49.380
一个符合schema的决策

00:06:49.380 --> 00:06:51.420
整个推理路径短很多

00:06:51.420 --> 00:06:52.300
所以快很多

00:06:52.300 --> 00:06:55.140
这就像一个专注于单一任务的机器人

00:06:55.140 --> 00:06:57.540
他只做他被设计来做的事

00:06:57.540 --> 00:06:58.860
所以效率极高

00:06:58.860 --> 00:07:02.020
这个速度差距在某些使用情境上

00:07:02.020 --> 00:07:05.060
会让整件事从可以用变成真正好用

00:07:05.060 --> 00:07:07.740
最明显的例子是浏览器自动化

00:07:07.740 --> 00:07:09.120
现在有很多工具

00:07:09.120 --> 00:07:11.160
可以让AI控制你的浏览器

00:07:11.160 --> 00:07:11.980
你给他一个目标

00:07:11.980 --> 00:07:13.680
他自己去点页面

00:07:13.680 --> 00:07:14.380
填资料

00:07:14.380 --> 00:07:15.300
跳到下一页

00:07:15.300 --> 00:07:17.060
但如果你真的试过用

00:07:17.060 --> 00:07:18.500
Astra或Fable做这件事

00:07:18.500 --> 00:07:20.000
你会发现他慢得很痛苦

00:07:20.000 --> 00:07:20.540
Agent

00:07:20.540 --> 00:07:22.120
结一张网页的截图

00:07:22.120 --> 00:07:23.160
传给模型

00:07:23.160 --> 00:07:24.600
然后你等2秒

00:07:24.600 --> 00:07:25.220
3秒

00:07:25.220 --> 00:07:25.900
有时候5秒

00:07:25.900 --> 00:07:27.420
模型才决定要点哪里

00:07:27.420 --> 00:07:28.720
这段时间里

00:07:28.720 --> 00:07:30.200
网页可能已经更新了

00:07:30.200 --> 00:07:31.500
或者跳出一个弹窗

00:07:31.500 --> 00:07:33.660
然后Agent的动作就失效了

00:07:33.660 --> 00:07:35.900
这就像你请一个动作很慢的人

00:07:35.900 --> 00:07:37.240
帮你抢限量商品

00:07:37.240 --> 00:07:38.520
等到他反应过来

00:07:38.520 --> 00:07:39.940
商品早就被抢光了

00:07:39.940 --> 00:07:42.880
这就是为什么浏览器自动化到现在

00:07:42.880 --> 00:07:45.580
还是很难真正稳定部署的原因之一

00:07:45.580 --> 00:07:46.620
延迟太高

00:07:46.620 --> 00:07:49.100
反映跟不上动态网页的节奏

00:07:49.100 --> 00:07:51.680
但如果你把决策层换成JF

00:07:51.680 --> 00:07:54.100
延迟从秒级将到毫秒级

00:07:54.100 --> 00:07:56.300
Agent看到DOM结构

00:07:56.300 --> 00:07:57.640
马上对照Schema

00:07:57.640 --> 00:07:59.820
马上输出下一个动作

00:07:59.820 --> 00:08:00.660
他不需要思考

00:08:00.660 --> 00:08:01.520
他就是执行

00:08:01.520 --> 00:08:03.980
这样的速度才能让浏览器自动化

00:08:03.980 --> 00:08:05.700
从一个很酷的示范

00:08:05.700 --> 00:08:08.980
变成一个可以真正跑在生产环境的东西

00:08:08.980 --> 00:08:12.460
这就像你给机器人装上超快速反应晶片

00:08:12.460 --> 00:08:15.360
它能瞬间判断并执行任务

00:08:15.360 --> 00:08:17.260
让整个流程顺畅无比

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

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

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

00:08:31.654 --> 00:08:33.854
我把這個架構叫做雙腦架構

00:08:33.854 --> 00:08:35.054
概念很直觀

00:08:35.054 --> 00:08:37.994
你用大型語言模型做需要深度推理的事

00:08:37.994 --> 00:08:40.434
用Jav做需要快速執行的事

00:08:40.434 --> 00:08:42.054
舉個具體的例子

00:08:42.054 --> 00:08:44.874
假設你在建一個自動化的軟體開發agent

00:08:44.874 --> 00:08:46.094
他可以看需求

00:08:46.094 --> 00:08:46.974
寫程式

00:08:46.974 --> 00:08:47.834
跑測試

00:08:47.834 --> 00:08:48.634
修bug

00:08:48.634 --> 00:08:50.954
當一個新的功能需求進來的時候

00:08:50.954 --> 00:08:53.014
你先把它交給Fable或Astra

00:08:53.014 --> 00:08:55.634
這些模型有深度的推理能力

00:08:55.634 --> 00:08:58.454
它們可以分析整個專案程式碼

00:08:58.454 --> 00:08:59.874
理解依賴關係

00:08:59.874 --> 00:09:01.434
想清楚要怎麼實作

00:09:01.434 --> 00:09:04.334
然后产出一份详细的执行计划

00:09:04.334 --> 00:09:06.434
就是慢的贵的但值得

00:09:06.434 --> 00:09:09.234
因为这个阶段真的需要深度思考

00:09:09.234 --> 00:09:12.554
这就像一个公司的策略长

00:09:12.554 --> 00:09:14.954
负责制定整体方向和计划

00:09:14.954 --> 00:09:16.374
计划出来之后

00:09:16.374 --> 00:09:17.134
Fable退场

00:09:17.134 --> 00:09:18.034
Jeff接手

00:09:18.034 --> 00:09:20.114
Jeff比较适合负责

00:09:20.114 --> 00:09:21.854
判断下一步要做什么

00:09:21.854 --> 00:09:23.754
输出固定格式的指令

00:09:23.754 --> 00:09:25.254
如果测试失败了

00:09:25.254 --> 00:09:28.034
Jeff不需要重新思考整个架构

00:09:28.034 --> 00:09:30.094
他只需要看错误讯息

00:09:30.094 --> 00:09:31.514
对照行别定义

00:09:31.514 --> 00:09:33.774
修掉那个行别不符的地方

00:09:33.774 --> 00:09:36.274
再跑一次几毫秒就完成

00:09:36.274 --> 00:09:40.314
真正写大段程式码还是交给Fable或Extra

00:09:40.314 --> 00:09:42.074
这就像公司的执行长

00:09:42.074 --> 00:09:43.734
负责把策略长的计划

00:09:43.734 --> 00:09:46.294
分解成一个个具体任务

00:09:46.294 --> 00:09:47.914
并快速高效的执行

00:09:47.914 --> 00:09:50.914
你把昂贵的推理集中在规划阶段

00:09:50.914 --> 00:09:53.394
把执行交给一个高速低成本

00:09:53.394 --> 00:09:55.094
格式保证正确的引擎

00:09:55.094 --> 00:09:59.454
这样的组合才能让多A-系统真正规模化

00:09:59.454 --> 00:10:02.774
以前这种架构的问题是成本和延迟

00:10:02.774 --> 00:10:06.094
如果一个复杂的任务需要50个为决策

00:10:06.094 --> 00:10:08.294
每个决策要2秒花3分美金

00:10:08.294 --> 00:10:10.014
整个流程就要花1分多钟

00:10:10.014 --> 00:10:11.954
1块多美金单次执行

00:10:11.954 --> 00:10:15.074
这样的单位经济学根本没办法做自动化

00:10:15.074 --> 00:10:16.694
因为跑几次就亏了

00:10:16.694 --> 00:10:19.974
但Jeff把每个为决策的成本和延迟

00:10:19.974 --> 00:10:21.754
都压到几乎可以忽略的程度

00:10:21.754 --> 00:10:23.734
这个架构才真正变得可行

00:10:23.734 --> 00:10:27.094
这就像以前你需要请好几个顾问来做决策

00:10:27.094 --> 00:10:29.194
现在你只需要请一个策略顾问

00:10:29.194 --> 00:10:32.694
然后把执行交给一个超便宜又超快的机器人

00:10:32.694 --> 00:10:35.834
那实际上怎么把JAB接近你现有的流程

00:10:35.834 --> 00:10:37.534
有几个很具体的切入点

00:10:37.534 --> 00:10:42.414
最直接的方式是找出你现有AI流程里最容易坏掉的节点

00:10:42.414 --> 00:10:47.294
通常就是那些让LLM从非结构化的资料里抽取资讯

00:10:47.294 --> 00:10:49.774
然后格式化成某个固定格式的步骤

00:10:49.774 --> 00:10:52.494
比如说从一封信里抓出客户名称

00:10:52.494 --> 00:10:53.474
订单编号

00:10:53.474 --> 00:10:54.554
问题类别

00:10:54.554 --> 00:10:56.194
然后写进CIM

00:10:56.194 --> 00:10:59.294
这种步骤犯成Jav是最直接的

00:10:59.294 --> 00:11:01.514
你定义好schema让Jav做抽取

00:11:01.514 --> 00:11:03.034
格式问题直接消失

00:11:03.034 --> 00:11:05.854
这就像你把一个经常出错的环节

00:11:05.854 --> 00:11:08.794
换成一个永远不会出错的自动化机器人

00:11:08.794 --> 00:11:10.374
瞬间解决了所有问题

00:11:10.374 --> 00:11:12.694
另一个很适合的使用情境是

00:11:12.694 --> 00:11:13.414
vibe coding

00:11:13.414 --> 00:11:16.534
就是你用AI辅助快速开发的那种模式

00:11:16.534 --> 00:11:18.654
现在的vibe coding流程通常是

00:11:18.654 --> 00:11:20.694
让AI生成程式码

00:11:20.694 --> 00:11:21.374
你去跑

00:11:21.374 --> 00:11:22.374
跑出错误

00:11:22.374 --> 00:11:23.834
把错误贴回去给AI

00:11:23.834 --> 00:11:24.454
等它修

00:11:24.454 --> 00:11:25.134
再跑

00:11:25.134 --> 00:11:27.014
这个回圈很慢而且很烦

00:11:27.014 --> 00:11:29.094
因为Jeff速度过快

00:11:29.094 --> 00:11:31.374
对程式语法的理解是原生的

00:11:31.374 --> 00:11:34.454
你可以在IDE里设定一个背景监听器

00:11:34.454 --> 00:11:37.034
每次有编译错误或测试失败

00:11:37.034 --> 00:11:38.594
自动把错误丢给Jeff

00:11:38.594 --> 00:11:40.634
让他在背景直接修掉

00:11:40.634 --> 00:11:42.414
你甚至不需要手动介入

00:11:42.414 --> 00:11:43.274
他已经修好了

00:11:43.274 --> 00:11:46.454
这就像你身边有一个超级程式码修正助手

00:11:46.454 --> 00:11:47.514
在你写程式的时候

00:11:47.514 --> 00:11:49.634
他随时帮你检查并修复错误

00:11:49.634 --> 00:11:51.634
让你专心在创作上

00:11:51.634 --> 00:11:53.494
这个部分说完

00:11:53.494 --> 00:11:54.494
我要讲一个很重要

00:11:54.494 --> 00:11:56.814
但很多人在兴奋的时候会忘掉的是

00:11:56.814 --> 00:11:57.934
速度越快

00:11:57.934 --> 00:11:59.714
出错的代价越高

00:11:59.714 --> 00:12:01.054
当你有一个模型

00:12:01.054 --> 00:12:03.574
可以在毫秒内生成并执行程式码

00:12:03.574 --> 00:12:06.554
你根本来不及在他出错之前阻止他

00:12:06.554 --> 00:12:09.054
如果Jeff在自动化流程里

00:12:09.054 --> 00:12:10.994
有权限存取你的档案系统

00:12:10.994 --> 00:12:12.394
执行终端机指令

00:12:12.394 --> 00:12:13.354
更新资料库

00:12:13.354 --> 00:12:15.574
而他以200倍的速度在跑

00:12:15.574 --> 00:12:16.674
那出了问题的时候

00:12:16.674 --> 00:12:18.194
你看到的已经是结果

00:12:18.194 --> 00:12:18.874
不是过程

00:12:18.874 --> 00:12:21.254
这就像你开一台超级跑车

00:12:21.254 --> 00:12:22.114
速度很快

00:12:22.114 --> 00:12:23.294
但如果失控

00:12:23.294 --> 00:12:25.354
造成的损害也会非常巨大

00:12:25.354 --> 00:12:27.834
所以安全边界必须跟着调整

00:12:27.834 --> 00:12:29.054
几个原则要记住

00:12:29.054 --> 00:12:29.654
第一

00:12:29.654 --> 00:12:31.534
就算是高准确定的模型

00:12:31.534 --> 00:12:32.934
AI生成的程式码

00:12:32.934 --> 00:12:35.514
预设要当成不信任的来处理

00:12:35.514 --> 00:12:37.294
不要因为它很少出错

00:12:37.294 --> 00:12:38.354
就给它最高权限

00:12:38.354 --> 00:12:39.474
第二

00:12:39.474 --> 00:12:42.034
如果你要在本机跑Jab做自动化

00:12:42.034 --> 00:12:45.254
Docker容器把执行环境隔离起来

00:12:45.254 --> 00:12:46.994
给它最小必要的权限

00:12:46.994 --> 00:12:48.054
不要给root

00:12:48.054 --> 00:12:49.134
第三

00:12:49.134 --> 00:12:51.694
如果Jab在做浏览器自动化

00:12:51.694 --> 00:12:54.674
不要用你平常已经登录的浏览器设定档

00:12:54.674 --> 00:12:57.614
用独立的一次性的工作阶段

00:12:57.614 --> 00:13:00.254
这样就算它误判了某个DOM元素

00:13:00.254 --> 00:13:02.114
也不会动到你的生产环境

00:13:02.114 --> 00:13:05.074
这就像你使用任何强大的工具一样

00:13:05.074 --> 00:13:06.814
必须先做好安全防护

00:13:06.814 --> 00:13:08.694
才能避免不必要的风险

00:13:08.694 --> 00:13:10.974
Jeff帮你省下了写程式码的时间

00:13:10.974 --> 00:13:12.574
但这些省下来的时间

00:13:12.574 --> 00:13:16.134
你要拿去建更完善的自动化测试和安全验证

00:13:16.134 --> 00:13:17.974
你的角色从写程式的人

00:13:17.974 --> 00:13:21.374
变成设计系统架构和做安全审计的人

00:13:21.374 --> 00:13:23.694
这就像以前你需要自己造车

00:13:23.694 --> 00:13:27.514
现在你只需要设计好车子的功能和安全系统

00:13:27.514 --> 00:13:29.174
然后让机器人去制造

00:13:29.174 --> 00:13:32.714
最后来说说我对Jeff这件事的整体看法

00:13:32.714 --> 00:13:35.674
过去一年多AI产业的主旋律

00:13:35.674 --> 00:13:37.694
是把模型做得越来越大

00:13:37.694 --> 00:13:38.834
越来越聪明

00:13:38.834 --> 00:13:39.774
越来越贵

00:13:39.774 --> 00:13:41.674
每个人都在追AGI

00:13:41.674 --> 00:13:44.734
都在比谁的模型推理能力更强

00:13:44.734 --> 00:13:47.974
Extra跟Fable在这条路上做得很好

00:13:47.974 --> 00:13:48.894
他们真的很厉害

00:13:48.894 --> 00:13:51.874
但真正在用AI做产品的人

00:13:51.874 --> 00:13:52.774
工程师

00:13:52.774 --> 00:13:54.274
独立开发者

00:13:54.274 --> 00:13:55.134
小团队

00:13:55.134 --> 00:13:57.774
我们不是每天都在解历史难题

00:13:57.774 --> 00:14:00.154
我们大部分时间需要的是

00:14:00.154 --> 00:14:02.274
这个资料是不是不领值

00:14:02.274 --> 00:14:05.554
这个请求应该要分派给哪个服务

00:14:05.554 --> 00:14:07.274
这封信的优先顺序

00:14:07.274 --> 00:14:08.534
是高还是低

00:14:08.534 --> 00:14:10.934
这些问题不需要深度推理

00:14:10.934 --> 00:14:12.454
需要的是快

00:14:12.454 --> 00:14:13.234
准

00:14:13.234 --> 00:14:14.454
格式正确

00:14:14.454 --> 00:14:16.174
这就像我们日常生活

00:14:16.174 --> 00:14:18.314
大部分时候我们需要的不是哲学家

00:14:18.314 --> 00:14:21.174
而是一个能快速精准回答问题的工具人

00:14:21.174 --> 00:14:23.834
Jeff代表的是AI执行层的工业化

00:14:23.834 --> 00:14:25.414
他承认一件事

00:14:25.414 --> 00:14:27.694
未来的自动化不会是一个超级大脑

00:14:27.694 --> 00:14:28.994
慢慢把所有事情都做完

00:14:28.994 --> 00:14:31.874
而是一堆高度专门化的引擎分工合作

00:14:31.874 --> 00:14:35.214
各自在自己最擅长的部分做到最好

00:14:35.214 --> 00:14:37.374
这就像一个现代化的工厂

00:14:37.374 --> 00:14:39.614
每个环节都有专门的机器人负责

00:14:39.614 --> 00:14:40.814
协同合作

00:14:40.814 --> 00:14:42.394
达到最高的效率

00:14:42.394 --> 00:14:43.994
对那些花了无数个夜晚

00:14:43.994 --> 00:14:46.454
在除错Jason格式问题的人来说

00:14:46.454 --> 00:14:48.534
这个东西出现的时机真的很刚好

00:14:48.534 --> 00:14:50.654
如果你觉得今天的内容让你有点收获

00:14:50.654 --> 00:14:52.794
那就帮我到Apple Podcast按赞追踪

00:14:52.794 --> 00:14:53.974
留个五星好评吧

00:14:53.974 --> 00:14:56.334
FB IG Flats

00:14:56.334 --> 00:14:58.554
收AI懒人报就找到我了

00:14:58.554 --> 00:15:00.794
你的支持是我持续优化

00:15:00.794 --> 00:15:02.354
内容的最大动力

00:15:02.354 --> 00:15:05.034
最近的AI发展依然快的让我害怕

00:15:05.034 --> 00:15:07.034
不想出过明天再继续

00:15:07.034 --> 00:15:08.594
收听AI懒人报啰

00:15:08.594 --> 00:15:09.674
我是汤懒懒

00:15:09.674 --> 00:15:10.574
我们明天见

00:15:10.574 --> 00:15:11.014
拜拜