WEBVTT
Kind: captions
Language: zh

00:01:25.633 --> 00:01:27.566
嗨欢迎来到灵姐说AI

00:01:27.666 --> 00:01:29.900
GPT5.6终于更新了

00:01:29.900 --> 00:01:30.400
可以说啊

00:01:30.433 --> 00:01:34.400
这一次Openai是把Codex和chatgpt合体了

00:01:34.600 --> 00:01:37.233
Codex正式变成了chatgpt的

00:01:37.233 --> 00:01:39.233
work模式和Codex模式

00:01:39.366 --> 00:01:40.933
并且啊你在更新的时候

00:01:40.933 --> 00:01:44.033
如果你选择不保留Codex图标的话

00:01:44.033 --> 00:01:46.133
可以统一为chatgpt的图标

00:01:46.500 --> 00:01:48.200
其中最大的变化主要

00:01:48.200 --> 00:01:50.066
表现为以下三个点

00:01:50.066 --> 00:01:52.233
第一个你可以根据是编程

00:01:52.233 --> 00:01:53.933
任务还是工作任务

00:01:53.933 --> 00:01:56.566
在左上角进行切换和选择

00:01:56.766 --> 00:01:58.100
选择之后就会有

00:01:58.100 --> 00:01:59.866
相应的倾向性的调整

00:01:59.866 --> 00:02:00.300
第二点

00:02:00.366 --> 00:02:04.200
你可以直接在Codex里面去点击聊天

00:02:04.200 --> 00:02:07.666
就可以进入chatgpt最传统的聊天模式

00:02:07.833 --> 00:02:10.666
第三点我觉得也是非常重要的一点

00:02:10.666 --> 00:02:12.600
就是你在聊天模式

00:02:12.600 --> 00:02:14.933
里面可以选择add to task

00:02:15.566 --> 00:02:17.766
这个时候你就可以将上下文

00:02:17.766 --> 00:02:20.533
合并到Codex的执行任务中去

00:02:20.900 --> 00:02:22.400
特别是第三点

00:02:22.400 --> 00:02:24.433
它让任务和我们人类的

00:02:24.433 --> 00:02:27.300
聊天的对齐过程和Codex的

00:02:27.366 --> 00:02:30.333
任务进程实现了无缝的链接

00:02:30.533 --> 00:02:32.033
这样子就可以把我们

00:02:32.033 --> 00:02:33.966
设计一个任务去实现

00:02:33.966 --> 00:02:36.133
我们一直在推荐的loop的

00:02:36.133 --> 00:02:39.333
方式变得非常的游刃有余了

00:02:39.333 --> 00:02:41.000
现在相当于可以把多个

00:02:41.000 --> 00:02:44.166
上下文加到同一个当前任务里面

00:02:44.433 --> 00:02:46.466
也可以把同一个上下文

00:02:46.500 --> 00:02:48.433
加到不同的任务里面

00:02:48.866 --> 00:02:52.033
GPT的这次更新是具有划时代意义的

00:02:52.200 --> 00:02:54.733
这期视频我会给大家详细的

00:02:54.733 --> 00:02:57.933
解读一下GPT5.6的这次更新

00:02:58.666 --> 00:02:59.733
里面既有what

00:02:59.800 --> 00:03:01.366
也有how也有why

00:03:01.566 --> 00:03:04.133
what我会讲清楚这一次更新有哪些

00:03:04.233 --> 00:03:07.000
how我会讲清楚这一次更新它如何

00:03:07.000 --> 00:03:09.466
作用于我们日常的具体任务中

00:03:09.666 --> 00:03:11.733
如何给我们实实在在的提升

00:03:11.733 --> 00:03:12.833
为什么这次更新给

00:03:12.933 --> 00:03:14.433
我如此多的兴奋感

00:03:14.433 --> 00:03:16.366
我会教教大家怎么去用好

00:03:16.366 --> 00:03:18.166
这一次它给我们带来的更新

00:03:18.266 --> 00:03:19.200
至于why这个点

00:03:19.233 --> 00:03:20.600
我也会给大家去讲讲

00:03:20.666 --> 00:03:23.266
为什么Openai能做这次更新

00:03:23.600 --> 00:03:26.466
它这一次更新的落脚点在哪里

00:03:26.533 --> 00:03:27.466
这里啊预告一下

00:03:27.466 --> 00:03:28.800
关于GPT的更新啊

00:03:28.800 --> 00:03:30.933
还有包括很多一些子功能

00:03:30.933 --> 00:03:32.400
有非常多的亮点

00:03:32.400 --> 00:03:33.066
在随后啊

00:03:33.066 --> 00:03:34.733
我会做非常多期的视频

00:03:34.733 --> 00:03:36.266
告诉大家应用的场景

00:03:36.266 --> 00:03:37.800
和一些重要的法则

00:03:37.800 --> 00:03:39.733
如果对后续的节目感兴趣

00:03:39.933 --> 00:03:42.200
请记得订阅我的频道灵姐说AI

00:03:42.200 --> 00:03:43.633
第一个部分给大家深度

00:03:43.633 --> 00:03:45.300
的解读一下这次更新

00:03:45.366 --> 00:03:47.300
这里面会包含一部分的what

00:03:47.300 --> 00:03:48.866
也会包含一部分的how

00:03:49.066 --> 00:03:50.366
在传统的观念里面啊

00:03:50.366 --> 00:03:51.066
大家看到的

00:03:51.066 --> 00:03:52.266
Codex是一个应用

00:03:52.466 --> 00:03:54.000
chatgpt是一个应用

00:03:54.000 --> 00:03:55.366
但是这一次变了

00:03:55.366 --> 00:03:57.533
chatgpt已经越来越变成一个

00:03:57.566 --> 00:03:59.700
统一的总的平台的入口

00:03:59.933 --> 00:04:01.500
它是大家的认知层

00:04:01.500 --> 00:04:03.033
是产品的外壳

00:04:03.200 --> 00:04:05.500
它下面下属了三个模式

00:04:05.500 --> 00:04:07.933
在这个总的应用下合体了

00:04:08.033 --> 00:04:08.766
chat模式

00:04:08.766 --> 00:04:09.733
聊天模式

00:04:09.933 --> 00:04:10.633
work模式

00:04:11.000 --> 00:04:12.500
知识工作的模式

00:04:12.633 --> 00:04:13.666
Codex模式

00:04:13.766 --> 00:04:16.066
智能体的执行模式

00:04:16.133 --> 00:04:19.433
大家现在看到我屏幕下方的程序坞

00:04:19.533 --> 00:04:21.166
看到这个图标就是

00:04:21.166 --> 00:04:23.266
大家传统使用的chatgpt

00:04:23.466 --> 00:04:25.400
它现在叫做chatgpt classic

00:04:25.533 --> 00:04:26.400
经典的APP

00:04:26.600 --> 00:04:28.533
这个它叫做ChatGPT

00:04:28.566 --> 00:04:30.700
实际上就是历史的Codex

00:04:30.766 --> 00:04:32.700
这里我是没有选择换图标

00:04:32.800 --> 00:04:34.366
如果换了图标的话

00:04:34.400 --> 00:04:36.566
它实际上就是和之前的

00:04:36.566 --> 00:04:39.133
ChatGPT的图标是完全一样的

00:04:39.133 --> 00:04:40.866
大家点开这个Codex

00:04:40.900 --> 00:04:42.433
现在叫做统一的GPT

00:04:42.733 --> 00:04:44.800
好我们在这里看到左上角

00:04:44.833 --> 00:04:45.633
在这个地方

00:04:45.633 --> 00:04:48.033
大家是可以切换两种模式的

00:04:48.066 --> 00:04:49.733
叫做work和Codex

00:04:49.900 --> 00:04:53.266
它这里写的work是面向知识工作者

00:04:53.266 --> 00:04:55.200
Codex是面向开发者

00:04:55.200 --> 00:04:57.066
这两者的区别如何选择

00:04:57.066 --> 00:04:58.666
待会会给大家详细去讲

00:04:58.833 --> 00:04:59.533
在这里啊

00:04:59.566 --> 00:05:01.533
点击聊天点一下

00:05:01.533 --> 00:05:02.900
点一下在右下方这个位置

00:05:02.900 --> 00:05:03.766
你就可以看到

00:05:03.766 --> 00:05:06.266
这里你就可以跟它直接聊天了

00:05:06.266 --> 00:05:08.800
它有一点像右下角的这个浮窗

00:05:09.066 --> 00:05:10.133
看到这个位置啊

00:05:10.133 --> 00:05:12.200
这里是一个非常大的亮点

00:05:12.200 --> 00:05:14.433
就是你可以选择add to task

00:05:14.866 --> 00:05:16.933
这个时候你就把这个上下文

00:05:16.933 --> 00:05:18.866
加到了你现在的任务窗口

00:05:23.533 --> 00:05:25.100
我之前和大家强烈地去

00:05:25.100 --> 00:05:26.800
讲了Loop这种工作方式

00:05:26.800 --> 00:05:29.800
实际上它的缝合是我通过人工

00:05:29.866 --> 00:05:33.033
的方式在GPT和Codex之间缝合的

00:05:33.033 --> 00:05:34.966
后面呢我又用了一种更高级的方式

00:05:35.033 --> 00:05:36.633
用了MCP的方式

00:05:36.700 --> 00:05:38.600
通过底层去打通了

00:05:38.833 --> 00:05:39.833
Codex和GPT

00:05:40.033 --> 00:05:41.300
但是不管我怎么做

00:05:41.300 --> 00:05:43.433
都不如GPT自己来这么一下

00:05:43.766 --> 00:05:46.066
它加的这种add to task的方式

00:05:46.100 --> 00:05:47.366
引用上下文的方式

00:05:47.500 --> 00:05:49.166
对于我们整个Loop的循环

00:05:49.200 --> 00:05:51.600
真的是非常非常有帮助的

00:05:51.600 --> 00:05:52.666
这一点在后面也会

00:05:53.000 --> 00:05:54.500
详细展开给大家讲

00:05:54.733 --> 00:05:55.766
所以发现了没有

00:05:55.766 --> 00:05:58.066
这一次是把我们的主工作台

00:05:58.100 --> 00:06:00.200
切换到了一个统一的桌面端

00:06:00.233 --> 00:06:01.000
在这里面

00:06:01.033 --> 00:06:02.100
chat负责想

00:06:02.200 --> 00:06:04.433
work负责一些通识的工作

00:06:04.466 --> 00:06:06.866
而Codex负责动手和执行

00:06:07.066 --> 00:06:10.366
add to task把这个三个连在了一起

00:06:10.400 --> 00:06:12.400
如果你是一个细心的用户

00:06:12.400 --> 00:06:14.633
你再打开你的手机端的GPT

00:06:14.633 --> 00:06:16.466
你会发现你手机端

00:06:16.533 --> 00:06:18.466
也可以打开work模式

00:06:18.566 --> 00:06:19.866
那有的用户要说了

00:06:19.900 --> 00:06:21.266
chat模式好理解

00:06:21.400 --> 00:06:24.166
work模式和Codex模式有什么区别呢

00:06:24.166 --> 00:06:25.766
如何选取合适的模式

00:06:26.000 --> 00:06:26.866
它们俩的区别啊

00:06:26.900 --> 00:06:28.500
可以从这张表格里面

00:06:28.500 --> 00:06:30.133
获得最直观的对比

00:06:30.300 --> 00:06:31.566
可以看到他们的目标

00:06:31.600 --> 00:06:33.533
输入输出核心工具

00:06:33.533 --> 00:06:34.500
还有验证方法

00:06:34.566 --> 00:06:36.533
工作单位和主要的使用者

00:06:36.566 --> 00:06:38.566
会有一些核心的差别

00:06:38.633 --> 00:06:40.200
用一句话总结就是

00:06:40.200 --> 00:06:42.400
work它是面向知识工作

00:06:42.533 --> 00:06:44.533
成果的通用执行代理

00:06:44.533 --> 00:06:47.200
而Codex它是面向可运行的

00:06:47.233 --> 00:06:49.266
软件系统的工程代理

00:06:49.500 --> 00:06:51.433
你看到这里的work它是偏向

00:06:51.433 --> 00:06:54.533
于研究分析创建文档表格

00:06:54.566 --> 00:06:56.500
演示报告site等产品的

00:06:56.500 --> 00:06:59.400
Codex面向的是编写或者调试代码

00:06:59.433 --> 00:07:00.666
运行测试命令

00:07:00.666 --> 00:07:03.200
审查改动和操作代码仓库等等

00:07:03.400 --> 00:07:06.300
work模式它最典型的一个工作对象

00:07:06.333 --> 00:07:07.266
一个工作单位

00:07:07.266 --> 00:07:08.433
是一个成果

00:07:08.433 --> 00:07:09.400
或者一个项目

00:07:09.400 --> 00:07:10.166
一个任务

00:07:10.166 --> 00:07:12.833
而Codex它最典型的工作对象

00:07:12.833 --> 00:07:15.833
是一个代码仓库中的工程变更

00:07:16.133 --> 00:07:17.366
所以work模式下

00:07:17.366 --> 00:07:20.500
它更多的面向的使用者是研究员

00:07:20.600 --> 00:07:23.766
运营咨询师内容创作者办公用户

00:07:23.766 --> 00:07:25.700
等等而Codex它主要的面向

00:07:26.133 --> 00:07:28.433
对象是开发者和工程师

00:07:28.700 --> 00:07:30.300
那么对于一些知识

00:07:30.300 --> 00:07:32.933
工作者就直接选择work模式吗

00:07:33.033 --> 00:07:36.300
实际上你是可以两种模式去交叉的

00:07:36.300 --> 00:07:38.300
取决于你的任务是什么

00:07:38.300 --> 00:07:40.833
那就要搞清楚这两种模式它

00:07:40.833 --> 00:07:42.766
底层逻辑上的差异点

00:07:42.800 --> 00:07:44.100
首先要强调的是

00:07:44.100 --> 00:07:46.500
这两种模式它底层上并

00:07:46.500 --> 00:07:49.333
不是两种完全不同类型的AI

00:07:49.400 --> 00:07:50.700
它们是有交叉的

00:07:50.700 --> 00:07:52.000
这两种模式啊

00:07:52.000 --> 00:07:52.800
它的底层

00:07:53.266 --> 00:07:55.533
基础的这个逻辑是相通的

00:07:55.533 --> 00:07:57.866
它们都是模型加上工具

00:07:58.000 --> 00:08:00.233
加上agent loop的通用循环

00:08:00.366 --> 00:08:02.300
它们的通用循环大概都是这样子的

00:08:02.300 --> 00:08:03.833
先理解这个目标

00:08:03.833 --> 00:08:05.800
然后制定具体的步骤

00:08:05.866 --> 00:08:07.900
接着调用工具去执行

00:08:07.966 --> 00:08:10.533
然后观察工具执行的结果

00:08:10.766 --> 00:08:13.066
再接着评估修正计划

00:08:13.100 --> 00:08:14.166
再调用工具

00:08:14.166 --> 00:08:15.433
再执行接着

00:08:15.433 --> 00:08:16.366
直到完成

00:08:16.466 --> 00:08:17.933
它们之间是有交叉的

00:08:17.933 --> 00:08:20.100
在Codex模式下也可以聊天

00:08:20.100 --> 00:08:21.666
也可以生成文档

00:08:21.700 --> 00:08:23.166
在工作模式下

00:08:23.233 --> 00:08:24.766
也是可以发起一些

00:08:24.766 --> 00:08:26.433
代码类的工具调用的

00:08:26.466 --> 00:08:29.066
它们真正的差异点在于以下几点

00:08:29.166 --> 00:08:29.733
第一个

00:08:29.733 --> 00:08:32.666
他们两者的默认的世界模型不同

00:08:32.666 --> 00:08:34.400
work认为自己是一个

00:08:34.400 --> 00:08:36.133
开放性的知识任务

00:08:36.366 --> 00:08:36.933
你要知道

00:08:36.933 --> 00:08:39.466
GPT是非常擅长去拓展的

00:08:39.466 --> 00:08:41.100
它就像你的一个合伙人

00:08:41.266 --> 00:08:42.766
在Work模式下

00:08:42.766 --> 00:08:43.666
这种模式

00:08:43.700 --> 00:08:44.866
这种优点吧

00:08:44.866 --> 00:08:46.100
会被放得比较大

00:08:46.100 --> 00:08:48.000
而在Codex模式下

00:08:48.533 --> 00:08:49.700
他默认的世界

00:08:49.700 --> 00:08:51.300
他是认为自己是面对

00:08:51.333 --> 00:08:53.566
一个有状态的计算环境

00:08:53.666 --> 00:08:55.633
他是有一个代码仓库存在

00:08:55.700 --> 00:08:56.666
这两个模式

00:08:56.766 --> 00:08:57.866
他一个很核心的点

00:08:57.866 --> 00:09:00.400
相当于他的底层思维存在差异

00:09:00.600 --> 00:09:03.266
work是围绕这个成果去组织环境的

00:09:03.266 --> 00:09:05.200
但是Codex是围绕这个

00:09:05.233 --> 00:09:07.233
工程状态去组织环境的

00:09:07.366 --> 00:09:09.100
他们的出发点和思维

00:09:09.166 --> 00:09:10.666
逻辑是存在差异的

00:09:10.666 --> 00:09:13.100
第二个大的不同是他们的Harness不同

00:09:13.166 --> 00:09:14.133
Harness是什么

00:09:14.166 --> 00:09:16.866
就是套在模型外面的那一套缰绳

00:09:17.200 --> 00:09:19.366
即使它们的底层模型是一样的

00:09:19.366 --> 00:09:23.133
但是装配给它的上下文工具权限

00:09:23.266 --> 00:09:25.866
审核的规则循环的规则验证的规则

00:09:25.866 --> 00:09:27.733
还有环境状态是完全不同的

00:09:28.033 --> 00:09:29.633
在work这种模式下

00:09:29.733 --> 00:09:33.033
它的harness更像项目经理的那套逻辑

00:09:33.533 --> 00:09:34.933
比如说我要写一个文稿

00:09:34.933 --> 00:09:37.200
它先是明确这个交付的目标

00:09:37.300 --> 00:09:38.900
然后就开始拆解步骤

00:09:39.033 --> 00:09:41.466
然后收集资料去建立结论

00:09:41.633 --> 00:09:43.633
然后撰写这个交付文件

00:09:43.633 --> 00:09:44.800
等待用户的审批

00:09:44.800 --> 00:09:45.533
最后确认

00:09:45.600 --> 00:09:46.533
在这个过程中

00:09:46.533 --> 00:09:49.300
它需要处理不同类型的信息源

00:09:49.533 --> 00:09:52.833
它需要处理很多看似矛盾的信息

00:09:53.033 --> 00:09:54.566
它还要处理整个

00:09:54.566 --> 00:09:56.600
用户表达的不确定性

00:09:56.633 --> 00:09:59.233
去调和文档表格幻灯片

00:09:59.233 --> 00:10:01.466
等不同应用之间的协作

00:10:01.633 --> 00:10:03.533
交付一个统一的结果

00:10:03.866 --> 00:10:05.800
所以work模式它擅长的

00:10:05.800 --> 00:10:08.100
是跨应用的综合理解

00:10:08.133 --> 00:10:11.200
包括搜索去形成最后的交付结果

00:10:11.233 --> 00:10:12.900
哪怕说你用户中间

00:10:12.900 --> 00:10:14.400
临时改变一些决定

00:10:14.400 --> 00:10:15.300
改变想法

00:10:15.366 --> 00:10:16.500
它也能够比较好的

00:10:16.500 --> 00:10:17.933
去完成整体的交付

00:10:18.033 --> 00:10:20.533
并且它还能够基于你的任务

00:10:20.766 --> 00:10:22.266
去触发它的automation

00:10:22.533 --> 00:10:24.233
定时任务的上线

00:10:24.300 --> 00:10:25.733
或者说一些监控的任务

00:10:25.800 --> 00:10:27.100
而Codex的Harness

00:10:27.133 --> 00:10:30.133
它更偏向于工程师的那套逻辑

00:10:30.366 --> 00:10:33.400
它的整个的运行会更加的工程化

00:10:33.500 --> 00:10:35.566
他会长期保留和关注

00:10:35.600 --> 00:10:37.533
的是当前的工作目录

00:10:37.600 --> 00:10:38.533
可写的目录

00:10:38.700 --> 00:10:40.233
还有这个沙箱的权限

00:10:40.400 --> 00:10:41.266
测试状态

00:10:41.333 --> 00:10:43.333
还有一些规则文档的写法等等

00:10:43.333 --> 00:10:44.433
第三个大的不同

00:10:44.433 --> 00:10:47.000
我觉得是它的成功的标准不同

00:10:47.233 --> 00:10:48.900
就是work的标准和Codex

00:10:48.933 --> 00:10:50.033
的成功标准不一样

00:10:50.266 --> 00:10:53.133
work的成果最后是交付给人看的

00:10:53.166 --> 00:10:53.633
对不对

00:10:53.666 --> 00:10:56.100
你要交付给你的老板同事甲方等等

00:10:56.100 --> 00:10:58.433
而Codex的产物最后是交给谁的

00:10:58.433 --> 00:11:01.333
是交给计算机去执行使用的

00:11:01.466 --> 00:11:03.800
work的交付物最后它的验证是

00:11:03.800 --> 00:11:06.100
偏向于语义和业务的验收

00:11:06.100 --> 00:11:07.266
是人来判断的

00:11:07.433 --> 00:11:09.900
而Codex最后它的东西好不好

00:11:09.900 --> 00:11:11.000
是给机器来用

00:11:11.033 --> 00:11:12.000
它能不能跑通啊

00:11:12.000 --> 00:11:13.300
这个项目会不会挂呀

00:11:13.366 --> 00:11:14.733
这个是它的交付标准

00:11:14.800 --> 00:11:18.166
Codex是偏向于执行和机器来验收的

00:11:18.400 --> 00:11:20.933
以前我们使用Codex和GPT

00:11:21.033 --> 00:11:22.433
两者独立分开的时候

00:11:22.466 --> 00:11:23.533
大家会有体感

00:11:23.566 --> 00:11:25.433
在GPT上面的内容

00:11:25.433 --> 00:11:26.700
它是跟账号的

00:11:26.700 --> 00:11:28.566
我换了一个设备

00:11:28.566 --> 00:11:30.200
我所有的聊天记录

00:11:30.200 --> 00:11:32.133
所有的上下文都是存在的

00:11:32.133 --> 00:11:33.100
它是跟账号的

00:11:33.100 --> 00:11:34.733
但在这个设备跑的

00:11:34.800 --> 00:11:36.733
所有的内容环境文件夹

00:11:36.800 --> 00:11:37.766
我换了一个电脑

00:11:37.800 --> 00:11:39.733
用同一个Codex账号登录

00:11:40.100 --> 00:11:41.900
这些内容是不能够直接

00:11:42.000 --> 00:11:43.600
的复刻和复现过去的

00:11:43.600 --> 00:11:45.166
它是跟在本地的

00:11:45.166 --> 00:11:47.733
所以work模式和Codex模式

00:11:47.866 --> 00:11:49.433
它们有着本质的区别

00:11:49.433 --> 00:11:51.000
当然现在在这个阶段

00:11:51.033 --> 00:11:53.000
你在这个GPT的现在的

00:11:53.000 --> 00:11:54.866
这个APP里面选择work模式

00:11:55.033 --> 00:11:56.766
它的本地的这个项目管理

00:11:56.766 --> 00:11:58.366
和云端的这个是分开的

00:11:58.533 --> 00:11:59.966
但是从长期来看

00:11:59.966 --> 00:12:02.433
我更加倾向于认为work模式

00:12:02.500 --> 00:12:04.200
它的整个的状态管理

00:12:04.200 --> 00:12:05.533
它是跟账号的

00:12:05.566 --> 00:12:08.266
它未来是会和云端同步打开的

00:12:08.266 --> 00:12:10.566
而Codex它的整个的模式状态

00:12:10.600 --> 00:12:12.933
一定是锁在本地设备

00:12:12.966 --> 00:12:13.933
文件夹和仓库上面的

00:12:13.933 --> 00:12:16.633
两者的能力底座可能相近

00:12:16.633 --> 00:12:18.633
但是工作系统完全不同

00:12:18.700 --> 00:12:20.300
大家根据自己任务的具体

00:12:20.300 --> 00:12:22.333
情况去选择合适的模式

00:12:22.433 --> 00:12:24.333
判断你是否选择一种模式

00:12:24.433 --> 00:12:25.933
并不是按你的任务

00:12:25.933 --> 00:12:27.566
是否含有代码来选的

00:12:27.566 --> 00:12:29.866
不是说work模式就处理非代码

00:12:29.866 --> 00:12:31.933
Codex模式就是处理代码的

00:12:32.033 --> 00:12:33.766
而是要看你的任务

00:12:33.766 --> 00:12:35.500
最后的主对象是什么

00:12:35.633 --> 00:12:37.600
如果说是一个业务成果

00:12:37.600 --> 00:12:39.533
我更建议你选择work模式

00:12:39.666 --> 00:12:41.600
如果说是一个需要持续

00:12:41.633 --> 00:12:44.066
维护和验证的计算环境

00:12:44.066 --> 00:12:46.100
我更建议你选择Codex

00:12:46.266 --> 00:12:47.666
甚至像我自己的实践

00:12:47.666 --> 00:12:49.600
我的Youtube内容工厂为例

00:12:49.600 --> 00:12:51.433
我还可以混用两个模式

00:12:51.433 --> 00:12:53.600
让work模式负责我的上半场

00:12:53.700 --> 00:12:55.766
它负责帮我研究主题

00:12:55.766 --> 00:12:57.933
形成逐字稿和发布包等等

00:12:57.933 --> 00:13:00.433
而Codex可以负责我的下半场

00:13:00.433 --> 00:13:02.566
它可以帮我获取我的项目目录

00:13:02.700 --> 00:13:05.500
使用本地的TTS生成音频和画面

00:13:05.500 --> 00:13:07.100
并且完成剪辑

00:13:07.266 --> 00:13:09.033
渲染和最后的API接口的发布

00:13:09.033 --> 00:13:10.000
这样看上去啊

00:13:10.000 --> 00:13:11.600
大部分的注意力和资源

00:13:11.866 --> 00:13:13.533
都投注到了agent这一端

00:13:13.533 --> 00:13:14.566
再回过头来看

00:13:14.700 --> 00:13:16.600
那chat模式还重要吗

00:13:16.966 --> 00:13:18.433
我们这个时候再打开

00:13:18.433 --> 00:13:20.766
这个经典的GPT classic的APP

00:13:20.866 --> 00:13:21.666
在里面啊

00:13:21.666 --> 00:13:24.633
我们在Codex里面对话的这些任务啊

00:13:24.766 --> 00:13:26.366
同样会同步到这个

00:13:26.366 --> 00:13:28.000
ChatGPT的窗口里面

00:13:28.266 --> 00:13:30.066
传统的chat还重要吗

00:13:30.166 --> 00:13:30.600
在我这里

00:13:30.633 --> 00:13:31.300
我的回答是

00:13:31.433 --> 00:13:33.866
我认为在非常多的场景下

00:13:33.866 --> 00:13:35.666
CHAT仍然非常有价值

00:13:35.700 --> 00:13:36.466
举个例子

00:13:36.466 --> 00:13:37.800
比如说开放性的思考

00:13:38.133 --> 00:13:40.433
Codex更加偏向于给他一个目标

00:13:40.466 --> 00:13:41.433
他去完成

00:13:41.433 --> 00:13:43.700
但是传统的chat他更加

00:13:43.733 --> 00:13:45.466
偏向于去跟我讨论

00:13:45.500 --> 00:13:47.133
这个目标到底对不对呀

00:13:47.166 --> 00:13:48.466
还有哪些可能性啊

00:13:48.700 --> 00:13:50.366
你真正想解决的是什么

00:13:50.366 --> 00:13:52.000
这件事情应该怎么理解

00:13:52.000 --> 00:13:53.466
这里面产品的理解

00:13:53.466 --> 00:13:56.333
还有很多机制的抽象策略的判断

00:13:56.400 --> 00:13:58.966
都非常适合使用chat模式

00:13:58.966 --> 00:14:01.133
而不是直接让Codex去

00:14:01.166 --> 00:14:02.466
修改本地的项目

00:14:02.566 --> 00:14:03.900
写一个MD的文档

00:14:04.300 --> 00:14:05.333
还有很多任务

00:14:05.366 --> 00:14:08.400
它是不依赖于项目的目录去讨论的

00:14:08.400 --> 00:14:10.066
比如说一些数学问题

00:14:10.333 --> 00:14:11.833
一个临时的提问

00:14:11.833 --> 00:14:12.833
一些情感问题

00:14:13.033 --> 00:14:13.966
医疗问题

00:14:14.066 --> 00:14:15.566
电影的分析等等

00:14:15.566 --> 00:14:17.133
这种即时的问答

00:14:17.133 --> 00:14:18.233
如果说每一个

00:14:18.366 --> 00:14:19.866
都去开一个项目窗口

00:14:19.866 --> 00:14:21.733
反而显得非常的笨重

00:14:22.233 --> 00:14:23.200
还有一个方面啊

00:14:23.200 --> 00:14:25.133
我们在我们的移动的APP端

00:14:25.166 --> 00:14:27.100
GPT仍然是存在的

00:14:27.100 --> 00:14:29.333
它会承担很多的语音实时

00:14:29.333 --> 00:14:32.166
交流和移动端对话的这些功能

00:14:32.166 --> 00:14:34.466
它仍然非常具有独立的价值

00:14:34.466 --> 00:14:36.400
第二个板块想和大家聊的是

00:14:36.466 --> 00:14:38.800
GPT的这一次的改变和更新

00:14:38.933 --> 00:14:41.633
对于我们日常的工作和项目推进

00:14:41.633 --> 00:14:43.766
有哪些值得研究的点

00:14:43.766 --> 00:14:45.033
需要重点关注

00:14:45.033 --> 00:14:47.533
对我们的帮助会体现在哪里

00:14:47.933 --> 00:14:50.600
我觉得这一次真正值得研究的点

00:14:50.633 --> 00:14:52.566
就是我前面也有点到

00:14:52.833 --> 00:14:55.000
说的那个功能叫做Add to task

00:14:55.000 --> 00:14:57.166
这个功能的重要之处

00:14:57.200 --> 00:15:00.666
它在于Openai它开始把chat和

00:15:00.700 --> 00:15:03.200
workflow融合为同一个对象

00:15:03.633 --> 00:15:05.333
如果是我频道的老观众

00:15:05.333 --> 00:15:07.266
可以看到我在提示词这方面

00:15:07.866 --> 00:15:09.266
是有非常深度的

00:15:09.266 --> 00:15:10.866
研究和高级的应用的

00:15:10.866 --> 00:15:12.600
我在最开始做了很多

00:15:12.633 --> 00:15:14.666
自动化的元提示词

00:15:14.733 --> 00:15:17.633
再进化到GPT和Codex的Loop

00:15:17.766 --> 00:15:20.666
再进化到多agent的协同的Loop

00:15:20.666 --> 00:15:21.466
而现在

00:15:21.566 --> 00:15:25.133
这一次GPT的这次底层的重大更新

00:15:25.133 --> 00:15:28.600
它实际上是实现了把一个对话变成

00:15:28.800 --> 00:15:32.100
一个可以持续运行的过程和任务

00:15:32.100 --> 00:15:33.733
以前这个chat它是有

00:15:33.800 --> 00:15:35.366
一个天然的问题的

00:15:35.600 --> 00:15:38.166
chat它的生命周期是比较短的

00:15:38.466 --> 00:15:39.800
一个对话结束了

00:15:39.833 --> 00:15:41.166
这个chat就结束了

00:15:41.166 --> 00:15:43.000
当然我做的工作很多时候是

00:15:43.233 --> 00:15:45.566
把这个chat的生命周期再延续

00:15:45.566 --> 00:15:47.000
那个时候我做的是什么事情呢

00:15:47.000 --> 00:15:49.633
我把这个chat变成一个元提示词

00:15:50.200 --> 00:15:51.866
不断地升级迭代

00:15:51.933 --> 00:15:54.700
就相当于前一个chat它跑出来的结果

00:15:54.733 --> 00:15:55.866
我会给它叠甲

00:15:55.966 --> 00:15:57.466
叠到后一个chat里面

00:15:57.466 --> 00:16:00.500
而且我会给它做一个hand off的文件

00:16:00.500 --> 00:16:01.800
就是一个交接文档

00:16:01.800 --> 00:16:03.666
这样子他就把前一个Chat的

00:16:03.800 --> 00:16:06.666
生命周期往后不断地在延在迭代

00:16:06.733 --> 00:16:07.633
又或者说

00:16:07.666 --> 00:16:10.166
我会把在Codex的执行

00:16:10.166 --> 00:16:12.933
成果和节奏步骤的回执

00:16:12.966 --> 00:16:15.033
我会让Codex定期的给我回执

00:16:15.033 --> 00:16:17.433
我把这个回执回给chatgpt

00:16:17.666 --> 00:16:19.600
实际上也是在延续

00:16:19.600 --> 00:16:21.133
这个Chat的生命周期

00:16:21.133 --> 00:16:22.466
但不管我怎么做

00:16:22.466 --> 00:16:24.700
这都是人工方式的缝合

00:16:24.800 --> 00:16:25.633
当然我想说

00:16:25.633 --> 00:16:28.233
这样的思路和方式确实帮我

00:16:28.233 --> 00:16:30.700
完成了Chat生命周期的延长

00:16:31.166 --> 00:16:33.100
以前我把上下文搬出来

00:16:33.100 --> 00:16:34.133
需要我这个human

00:16:34.266 --> 00:16:35.300
我这个人去做

00:16:35.400 --> 00:16:37.433
现在Openai用系统解决了这个问题

00:16:37.433 --> 00:16:39.033
你想想原来的逻辑是什么

00:16:39.266 --> 00:16:41.333
比如说我要构建一个声音系统

00:16:41.400 --> 00:16:43.333
我先在GPT里面去聊

00:16:43.333 --> 00:16:44.500
形成我的总纲

00:16:44.633 --> 00:16:46.366
然后形成Codex的指令

00:16:46.433 --> 00:16:48.466
然后我把指令给到Codex

00:16:48.533 --> 00:16:50.700
帮我去搭建了这个声音系统

00:16:50.733 --> 00:16:52.966
然后再打造了对应的这个skill

00:16:53.200 --> 00:16:54.766
两者对应的MD的文档好

00:16:54.766 --> 00:16:56.333
这个chat是不是就死了

00:16:56.333 --> 00:16:58.266
当然我是想办法让它不死

00:16:58.466 --> 00:17:01.766
那现在有了Add to task这个功能之后

00:17:02.200 --> 00:17:03.033
就会变成

00:17:03.033 --> 00:17:03.800
你先chat

00:17:04.000 --> 00:17:06.566
然后这个chat呢就变成了一个任务

00:17:06.933 --> 00:17:08.300
这个任务和这个CHAT

00:17:08.566 --> 00:17:10.200
就可以持续地执行

00:17:10.233 --> 00:17:13.100
这个任务本身其实就是

00:17:13.200 --> 00:17:15.033
这个CHAT生命力的延续

00:17:15.166 --> 00:17:16.866
这个时候它的上下文

00:17:16.866 --> 00:17:18.466
就不需要重新构建了

00:17:18.500 --> 00:17:19.433
我一直在说

00:17:19.466 --> 00:17:21.033
GPT的模型这么强

00:17:21.033 --> 00:17:22.333
它的执行能力

00:17:22.433 --> 00:17:25.066
包括最后的Harness的精准性这么强

00:17:25.066 --> 00:17:26.800
和它非常强大的

00:17:26.900 --> 00:17:28.200
上下文能力是离不开的

00:17:28.200 --> 00:17:30.666
以前你聊天聊的这个上下文和

00:17:30.700 --> 00:17:33.266
这边执行的上下文它是断裂的

00:17:33.266 --> 00:17:36.133
而现在每一个提示词都是

00:17:36.133 --> 00:17:38.733
一个持续运行的工作流

00:17:38.733 --> 00:17:40.866
一个持续生长的上下文

00:17:40.866 --> 00:17:42.666
而且我觉得一个非常

00:17:42.666 --> 00:17:44.033
重要的变化是什么

00:17:44.200 --> 00:17:45.633
注意啊前方高能

00:17:45.633 --> 00:17:47.366
我觉得这个变化非常重要

00:17:47.466 --> 00:17:49.466
就是说以前这个prompts

00:17:49.733 --> 00:17:51.666
它实际上是一个function

00:17:51.900 --> 00:17:52.866
是一个函数

00:17:52.933 --> 00:17:54.300
就是你给它一个input

00:17:54.333 --> 00:17:56.133
然后给你输出一个output

00:17:56.400 --> 00:18:00.200
但是现在prompt变成了一个对象object

00:18:00.366 --> 00:18:02.533
这个prompt它可以在这个

00:18:02.533 --> 00:18:04.700
对话里面拥有生命周期

00:18:04.700 --> 00:18:07.900
拥有状态拥有上下文拥有历史

00:18:08.100 --> 00:18:10.066
这个就是软件工程里面

00:18:10.100 --> 00:18:12.300
的function变成了object

00:18:12.766 --> 00:18:15.033
这个实例化的这个转变啊

00:18:15.033 --> 00:18:17.500
可能很多人都低估了它的重要性

00:18:17.566 --> 00:18:19.866
很多时候你的想法没办法推进

00:18:20.000 --> 00:18:22.233
你的整个的知识地图是乱的

00:18:22.233 --> 00:18:23.800
就是你没有把所有的

00:18:24.066 --> 00:18:26.366
内容结构化和实例化

00:18:26.366 --> 00:18:28.733
以前所有的CHAT你需要自己维护

00:18:28.900 --> 00:18:30.933
现在你所有的CHAT都

00:18:30.933 --> 00:18:32.866
能够变成一个任务

00:18:32.866 --> 00:18:33.566
一个task

00:18:33.666 --> 00:18:35.400
它具有长的生命周期

00:18:35.433 --> 00:18:36.866
而且还有一个好的点是什么

00:18:37.000 --> 00:18:39.366
就是你在任务的进行过程中

00:18:39.433 --> 00:18:42.833
你可以不断地去给它加新的chat进来

00:18:42.966 --> 00:18:44.900
哇这个功能实在是太好了

00:18:44.900 --> 00:18:46.466
因为我之前在缝合的时候

00:18:46.466 --> 00:18:47.500
明显发现

00:18:47.500 --> 00:18:48.966
就是我去缝的时候

00:18:48.966 --> 00:18:51.766
我的Codex和GPT它可能是不同步的

00:18:52.000 --> 00:18:53.366
它是有一点断裂的

00:18:53.366 --> 00:18:55.300
而且就是它的整个的体感

00:18:55.300 --> 00:18:57.533
左右多窗口切换会非常的不好

00:18:57.700 --> 00:18:58.333
现在好了

00:18:58.333 --> 00:19:01.366
你可以所有的话不用一次性说完

00:19:01.400 --> 00:19:03.100
你的任务执行的过程中

00:19:03.100 --> 00:19:05.033
你可以同步地跟chat

00:19:05.200 --> 00:19:07.066
去聊天把聊出来的上下文

00:19:07.066 --> 00:19:07.800
你认可的东西

00:19:07.800 --> 00:19:09.233
把它加到这个任务里面

00:19:09.400 --> 00:19:11.033
给它丰富它现有的

00:19:11.033 --> 00:19:12.933
上下文和项目背景

00:19:13.033 --> 00:19:15.666
这个用法实在是太爽了

00:19:15.666 --> 00:19:17.066
以前呢我们发现项目不对

00:19:17.066 --> 00:19:17.966
那么我就可能需要

00:19:18.066 --> 00:19:19.633
重新给出新的提示词

00:19:19.833 --> 00:19:21.966
现在我们发现项目有一些偏移

00:19:21.966 --> 00:19:22.833
我要重新loop

00:19:22.933 --> 00:19:24.800
我只需要任务执行的过程中

00:19:25.000 --> 00:19:27.200
然后加入我update的这个信息

00:19:27.200 --> 00:19:29.966
不断地update继续update继续

00:19:30.000 --> 00:19:33.100
我的loop这个环就会更加的丝滑了

00:19:33.100 --> 00:19:35.000
你会感觉到你的agent在

00:19:35.000 --> 00:19:36.866
这个过程中一直在成长

00:19:37.066 --> 00:19:38.066
这意味着什么

00:19:38.133 --> 00:19:41.733
所有的对话都可以升级为工作流

00:19:41.800 --> 00:19:44.566
而所有的工作流都是动态

00:19:44.733 --> 00:19:47.166
最后啊第三部分给大家分享一下

00:19:47.166 --> 00:19:49.633
我认为chatgpt的这次更新

00:19:49.800 --> 00:19:51.433
它会带来什么样的影响

00:19:51.466 --> 00:19:52.700
未来的走向如何

00:19:52.933 --> 00:19:54.866
首先谈谈我直接的体感

00:19:54.866 --> 00:19:57.833
我觉得这些功能更新非常有价值

00:19:57.866 --> 00:19:59.166
我非常的兴奋

00:19:59.166 --> 00:19:59.966
在未来几个月

00:20:00.033 --> 00:20:01.833
我会深度的使用这些功能

00:20:01.833 --> 00:20:03.600
如果发现了好的应用和玩法

00:20:03.866 --> 00:20:06.033
会在这个频道跟大家做后续的分享

00:20:06.033 --> 00:20:07.533
当我第一次看到它

00:20:07.533 --> 00:20:08.600
的这个更新的时候

00:20:08.600 --> 00:20:10.866
我的想法是GPT again

00:20:11.233 --> 00:20:13.166
GPT这次更新我认为它是

00:20:13.200 --> 00:20:15.600
又一次具有划时代意义的

00:20:15.600 --> 00:20:17.833
虽然山姆奥特曼经常画饼

00:20:17.900 --> 00:20:20.400
虽然他之前也拉了红色警报

00:20:20.400 --> 00:20:21.433
但不管怎么说

00:20:21.500 --> 00:20:23.033
Openai GPT

00:20:23.200 --> 00:20:27.200
它仍然终究是软件形态的引领者

00:20:27.700 --> 00:20:30.566
我相信在未来一段时间内

00:20:30.866 --> 00:20:34.033
国内的所有的大厂APP在一两个

00:20:34.033 --> 00:20:36.633
月内都会变成它一样的形态

00:20:36.900 --> 00:20:39.300
后面大家可以到我这条视频来考古

00:20:39.300 --> 00:20:40.666
看我说的对不对

00:20:40.666 --> 00:20:43.266
这些APP我觉得都会跟进这种模式

00:20:43.266 --> 00:20:45.266
把chat并入到agent

00:20:45.600 --> 00:20:47.766
并且实现人类的对齐

00:20:47.833 --> 00:20:48.866
人类的审核

00:20:49.066 --> 00:20:51.466
agent执行者和agent Loop

00:20:51.466 --> 00:20:53.700
的完整形态的升级

00:20:53.766 --> 00:20:55.433
最后all in one

00:20:55.533 --> 00:20:58.166
虽然曾经在很多访谈里面

00:20:58.266 --> 00:21:00.000
国内的一些开发者

00:21:00.000 --> 00:21:03.366
包括国内大厂的一些APP的领导者

00:21:03.433 --> 00:21:05.833
包括很多AI的观察者

00:21:05.833 --> 00:21:07.700
大家都知道说要去哪里

00:21:07.733 --> 00:21:09.600
都知道说要all in one

00:21:09.666 --> 00:21:12.166
都知道要抢这个agent的入口

00:21:12.366 --> 00:21:14.233
但是如何去到这个目的地呢

00:21:14.533 --> 00:21:16.400
其实没有人给出答案

00:21:16.466 --> 00:21:18.966
现在实际上是ChatGPT给出

00:21:18.966 --> 00:21:21.333
了一个相对完美的答案

00:21:21.366 --> 00:21:22.400
现在这个答案

00:21:22.600 --> 00:21:24.533
它实际上是由GPT不断的

00:21:24.533 --> 00:21:26.233
试错摸索才完成出来的

00:21:26.533 --> 00:21:29.133
特别是Codex最近几个月非常

00:21:29.166 --> 00:21:31.233
高频度的迭代升级和优化

00:21:31.233 --> 00:21:32.333
在这个过程中

00:21:32.333 --> 00:21:35.366
它使用和积累了大量的工程数据

00:21:35.766 --> 00:21:37.400
正是有这样的数据

00:21:37.400 --> 00:21:39.633
积累和不断的升级迭代

00:21:39.800 --> 00:21:43.933
才让Openai的工程师能够知道agent

00:21:43.933 --> 00:21:46.433
的工作细节和交互的细节

00:21:46.666 --> 00:21:47.433
我认为啊

00:21:47.433 --> 00:21:50.266
Openai作为AI产品的引领者

00:21:50.300 --> 00:21:52.700
它在AI产品形态这一块

00:21:52.700 --> 00:21:55.600
一直是有比较深刻的认知和判断的

00:21:55.700 --> 00:21:57.600
如果我们把过去两年的

00:21:57.766 --> 00:21:59.166
产品演进放在一起来看

00:21:59.366 --> 00:22:00.833
就能看出一些端倪

00:22:00.933 --> 00:22:03.266
一开始的memory是让用户

00:22:03.266 --> 00:22:05.433
变成一个持续存在的对象

00:22:05.466 --> 00:22:06.766
到后面的project

00:22:06.966 --> 00:22:08.200
它是让项目变成

00:22:08.200 --> 00:22:09.700
一个持续存在的对象

00:22:09.700 --> 00:22:10.700
再到Codecs

00:22:10.766 --> 00:22:12.233
它是把工程环境

00:22:12.233 --> 00:22:13.900
变成持续存在的对象

00:22:13.933 --> 00:22:14.633
再到work

00:22:14.633 --> 00:22:16.166
把工作空间变成

00:22:16.166 --> 00:22:17.766
一个持续存在的对象

00:22:17.900 --> 00:22:20.300
现在的Add to task这个功能

00:22:20.366 --> 00:22:22.300
它是把一次聊天变成

00:22:22.300 --> 00:22:24.233
一个持续存在的执行对象

00:22:24.233 --> 00:22:26.300
这些功能看上去是独立的

00:22:26.333 --> 00:22:28.066
但它并不是孤立的

00:22:28.066 --> 00:22:31.000
要把chatgpt变成一个拥有长期的

00:22:31.000 --> 00:22:34.033
持续执行和可演化的工作流的系统

00:22:34.433 --> 00:22:37.400
所以这不就是Openai正在努力

00:22:37.900 --> 00:22:40.800
覆盖研究编码文档和持续

00:22:40.800 --> 00:22:43.866
工作一个super APP的一个大图吗

00:22:43.866 --> 00:22:45.800
GPT5.6的这一次更新

00:22:45.833 --> 00:22:47.400
你的使用体感怎么样

00:22:47.400 --> 00:22:49.333
也欢迎在评论区跟我分享

00:22:49.333 --> 00:22:50.900
记得订阅灵姐说AI

00:22:50.900 --> 00:22:52.966
不要错过后续的精彩视频

00:22:53.066 --> 00:22:54.100
今天就先聊到这里

00:22:54.133 --> 00:22:55.933
我们下期再见啦拜拜

00:00:00.100 --> 00:00:01.933
GPT这次更新我认为它是

00:00:02.033 --> 00:00:04.333
又一次具有划时代意义的

00:00:04.800 --> 00:00:05.866
Openai GPT

00:00:05.866 --> 00:00:09.700
它仍然终究是软件形态的引领者

00:00:10.166 --> 00:00:12.900
我相信在未来一段时间内

00:00:13.200 --> 00:00:16.233
国内的所有的大厂APP在一两个

00:00:16.233 --> 00:00:18.733
月内都会变成它一样的形态

00:00:18.933 --> 00:00:21.233
后面大家可以到我这条视频来考古

00:00:21.300 --> 00:00:22.600
看我说的对不对

00:00:22.600 --> 00:00:24.766
这些APP我觉得都会跟进这种模式

00:00:25.100 --> 00:00:26.800
把chat并入到agent

00:00:27.133 --> 00:00:29.200
并且实现人类的对齐

00:00:29.300 --> 00:00:30.300
人类的审核

00:00:30.466 --> 00:00:32.766
agent执行者和agent Loop

00:00:32.766 --> 00:00:34.900
的完整形态的升级

00:00:34.933 --> 00:00:36.533
最后all in one

00:00:36.633 --> 00:00:39.166
虽然曾经在很多访谈里面

00:00:39.300 --> 00:00:40.966
国内的一些开发者

00:00:40.966 --> 00:00:44.200
包括国内大厂的一些APP的领导者

00:00:44.233 --> 00:00:46.533
包括很多AI的观察者

00:00:46.533 --> 00:00:48.300
大家都知道说要去哪里

00:00:48.333 --> 00:00:50.100
都知道说要all in one

00:00:50.233 --> 00:00:52.633
都知道要抢这个agent的入口

00:00:52.800 --> 00:00:54.566
但是如何去到这个目的地呢

00:00:54.833 --> 00:00:56.600
其实没有人给出答案

00:00:56.733 --> 00:00:59.133
现在实际上是ChatGPT给出

00:00:59.133 --> 00:01:01.400
了一个相对完美的答案

00:01:01.400 --> 00:01:02.400
现在这个答案

00:01:02.633 --> 00:01:04.466
它实际上是由GPT不断的

00:01:04.466 --> 00:01:06.100
试错摸索才完成出来的

00:01:06.366 --> 00:01:08.866
特别是Codex最近几个月非常

00:01:08.933 --> 00:01:10.900
高频度的迭代升级和优化

00:01:10.933 --> 00:01:12.000
在这个过程中

00:01:12.000 --> 00:01:14.900
它使用和积累了大量的工程数据

00:01:15.200 --> 00:01:16.766
正是有这样的数据

00:01:16.833 --> 00:01:18.966
积累和不断的升级迭代

00:01:19.100 --> 00:01:23.033
才让Openai的工程师能够知道agent

00:01:23.066 --> 00:01:25.466
的工作细节和交互的细节