嗨欢迎来到灵姐说AI
GPT5.6终于更新了
可以说啊
这一次Openai是把Codex和chatgpt合体了
Codex正式变成了chatgpt的
work模式和Codex模式
并且啊你在更新的时候
如果你选择不保留Codex图标的话
可以统一为chatgpt的图标
其中最大的变化主要
表现为以下三个点
第一个你可以根据是编程
任务还是工作任务
在左上角进行切换和选择
选择之后就会有
相应的倾向性的调整
第二点
你可以直接在Codex里面去点击聊天
就可以进入chatgpt最传统的聊天模式
第三点我觉得也是非常重要的一点
就是你在聊天模式
里面可以选择add to task
这个时候你就可以将上下文
合并到Codex的执行任务中去
特别是第三点
它让任务和我们人类的
聊天的对齐过程和Codex的
任务进程实现了无缝的链接
这样子就可以把我们
设计一个任务去实现
我们一直在推荐的loop的
方式变得非常的游刃有余了
现在相当于可以把多个
上下文加到同一个当前任务里面
也可以把同一个上下文
加到不同的任务里面
GPT的这次更新是具有划时代意义的
这期视频我会给大家详细的
解读一下GPT5.6的这次更新
里面既有what
也有how也有why
what我会讲清楚这一次更新有哪些
how我会讲清楚这一次更新它如何
作用于我们日常的具体任务中
如何给我们实实在在的提升
为什么这次更新给
我如此多的兴奋感
我会教教大家怎么去用好
这一次它给我们带来的更新
至于why这个点
我也会给大家去讲讲
为什么Openai能做这次更新
它这一次更新的落脚点在哪里
这里啊预告一下
关于GPT的更新啊
还有包括很多一些子功能
有非常多的亮点
在随后啊
我会做非常多期的视频
告诉大家应用的场景
和一些重要的法则
如果对后续的节目感兴趣
请记得订阅我的频道灵姐说AI
第一个部分给大家深度
的解读一下这次更新
这里面会包含一部分的what
也会包含一部分的how
在传统的观念里面啊
大家看到的
Codex是一个应用
chatgpt是一个应用
但是这一次变了
chatgpt已经越来越变成一个
统一的总的平台的入口
它是大家的认知层
是产品的外壳
它下面下属了三个模式
在这个总的应用下合体了
chat模式
聊天模式
work模式
知识工作的模式
Codex模式
智能体的执行模式
大家现在看到我屏幕下方的程序坞
看到这个图标就是
大家传统使用的chatgpt
它现在叫做chatgpt classic
经典的APP
这个它叫做ChatGPT
实际上就是历史的Codex
这里我是没有选择换图标
如果换了图标的话
它实际上就是和之前的
ChatGPT的图标是完全一样的
大家点开这个Codex
现在叫做统一的GPT
好我们在这里看到左上角
在这个地方
大家是可以切换两种模式的
叫做work和Codex
它这里写的work是面向知识工作者
Codex是面向开发者
这两者的区别如何选择
待会会给大家详细去讲
在这里啊
点击聊天点一下
点一下在右下方这个位置
你就可以看到
这里你就可以跟它直接聊天了
它有一点像右下角的这个浮窗
看到这个位置啊
这里是一个非常大的亮点
就是你可以选择add to task
这个时候你就把这个上下文
加到了你现在的任务窗口
我之前和大家强烈地去
讲了Loop这种工作方式
实际上它的缝合是我通过人工
的方式在GPT和Codex之间缝合的
后面呢我又用了一种更高级的方式
用了MCP的方式
通过底层去打通了
Codex和GPT
但是不管我怎么做
都不如GPT自己来这么一下
它加的这种add to task的方式
引用上下文的方式
对于我们整个Loop的循环
真的是非常非常有帮助的
这一点在后面也会
详细展开给大家讲
所以发现了没有
这一次是把我们的主工作台
切换到了一个统一的桌面端
在这里面
chat负责想
work负责一些通识的工作
而Codex负责动手和执行
add to task把这个三个连在了一起
如果你是一个细心的用户
你再打开你的手机端的GPT
你会发现你手机端
也可以打开work模式
那有的用户要说了
chat模式好理解
work模式和Codex模式有什么区别呢
如何选取合适的模式
它们俩的区别啊
可以从这张表格里面
获得最直观的对比
可以看到他们的目标
输入输出核心工具
还有验证方法
工作单位和主要的使用者
会有一些核心的差别
用一句话总结就是
work它是面向知识工作
成果的通用执行代理
而Codex它是面向可运行的
软件系统的工程代理
你看到这里的work它是偏向
于研究分析创建文档表格
演示报告site等产品的
Codex面向的是编写或者调试代码
运行测试命令
审查改动和操作代码仓库等等
work模式它最典型的一个工作对象
一个工作单位
是一个成果
或者一个项目
一个任务
而Codex它最典型的工作对象
是一个代码仓库中的工程变更
所以work模式下
它更多的面向的使用者是研究员
运营咨询师内容创作者办公用户
等等而Codex它主要的面向
对象是开发者和工程师
那么对于一些知识
工作者就直接选择work模式吗
实际上你是可以两种模式去交叉的
取决于你的任务是什么
那就要搞清楚这两种模式它
底层逻辑上的差异点
首先要强调的是
这两种模式它底层上并
不是两种完全不同类型的AI
它们是有交叉的
这两种模式啊
它的底层
基础的这个逻辑是相通的
它们都是模型加上工具
加上agent loop的通用循环
它们的通用循环大概都是这样子的
先理解这个目标
然后制定具体的步骤
接着调用工具去执行
然后观察工具执行的结果
再接着评估修正计划
再调用工具
再执行接着
直到完成
它们之间是有交叉的
在Codex模式下也可以聊天
也可以生成文档
在工作模式下
也是可以发起一些
代码类的工具调用的
它们真正的差异点在于以下几点
第一个
他们两者的默认的世界模型不同
work认为自己是一个
开放性的知识任务
你要知道
GPT是非常擅长去拓展的
它就像你的一个合伙人
在Work模式下
这种模式
这种优点吧
会被放得比较大
而在Codex模式下
他默认的世界
他是认为自己是面对
一个有状态的计算环境
他是有一个代码仓库存在
这两个模式
他一个很核心的点
相当于他的底层思维存在差异
work是围绕这个成果去组织环境的
但是Codex是围绕这个
工程状态去组织环境的
他们的出发点和思维
逻辑是存在差异的
第二个大的不同是他们的Harness不同
Harness是什么
就是套在模型外面的那一套缰绳
即使它们的底层模型是一样的
但是装配给它的上下文工具权限
审核的规则循环的规则验证的规则
还有环境状态是完全不同的
在work这种模式下
它的harness更像项目经理的那套逻辑
比如说我要写一个文稿
它先是明确这个交付的目标
然后就开始拆解步骤
然后收集资料去建立结论
然后撰写这个交付文件
等待用户的审批
最后确认
在这个过程中
它需要处理不同类型的信息源
它需要处理很多看似矛盾的信息
它还要处理整个
用户表达的不确定性
去调和文档表格幻灯片
等不同应用之间的协作
交付一个统一的结果
所以work模式它擅长的
是跨应用的综合理解
包括搜索去形成最后的交付结果
哪怕说你用户中间
临时改变一些决定
改变想法
它也能够比较好的
去完成整体的交付
并且它还能够基于你的任务
去触发它的automation
定时任务的上线
或者说一些监控的任务
而Codex的Harness
它更偏向于工程师的那套逻辑
它的整个的运行会更加的工程化
他会长期保留和关注
的是当前的工作目录
可写的目录
还有这个沙箱的权限
测试状态
还有一些规则文档的写法等等
第三个大的不同
我觉得是它的成功的标准不同
就是work的标准和Codex
的成功标准不一样
work的成果最后是交付给人看的
对不对
你要交付给你的老板同事甲方等等
而Codex的产物最后是交给谁的
是交给计算机去执行使用的
work的交付物最后它的验证是
偏向于语义和业务的验收
是人来判断的
而Codex最后它的东西好不好
是给机器来用
它能不能跑通啊
这个项目会不会挂呀
这个是它的交付标准
Codex是偏向于执行和机器来验收的
以前我们使用Codex和GPT
两者独立分开的时候
大家会有体感
在GPT上面的内容
它是跟账号的
我换了一个设备
我所有的聊天记录
所有的上下文都是存在的
它是跟账号的
但在这个设备跑的
所有的内容环境文件夹
我换了一个电脑
用同一个Codex账号登录
这些内容是不能够直接
的复刻和复现过去的
它是跟在本地的
所以work模式和Codex模式
它们有着本质的区别
当然现在在这个阶段
你在这个GPT的现在的
这个APP里面选择work模式
它的本地的这个项目管理
和云端的这个是分开的
但是从长期来看
我更加倾向于认为work模式
它的整个的状态管理
它是跟账号的
它未来是会和云端同步打开的
而Codex它的整个的模式状态
一定是锁在本地设备
文件夹和仓库上面的
两者的能力底座可能相近
但是工作系统完全不同
大家根据自己任务的具体
情况去选择合适的模式
判断你是否选择一种模式
并不是按你的任务
是否含有代码来选的
不是说work模式就处理非代码
Codex模式就是处理代码的
而是要看你的任务
最后的主对象是什么
如果说是一个业务成果
我更建议你选择work模式
如果说是一个需要持续
维护和验证的计算环境
我更建议你选择Codex
甚至像我自己的实践
我的Youtube内容工厂为例
我还可以混用两个模式
让work模式负责我的上半场
它负责帮我研究主题
形成逐字稿和发布包等等
而Codex可以负责我的下半场
它可以帮我获取我的项目目录
使用本地的TTS生成音频和画面
并且完成剪辑
渲染和最后的API接口的发布
这样看上去啊
大部分的注意力和资源
都投注到了agent这一端
再回过头来看
那chat模式还重要吗
我们这个时候再打开
这个经典的GPT classic的APP
在里面啊
我们在Codex里面对话的这些任务啊
同样会同步到这个
ChatGPT的窗口里面
传统的chat还重要吗
在我这里
我的回答是
我认为在非常多的场景下
CHAT仍然非常有价值
举个例子
比如说开放性的思考
Codex更加偏向于给他一个目标
他去完成
但是传统的chat他更加
偏向于去跟我讨论
这个目标到底对不对呀
还有哪些可能性啊
你真正想解决的是什么
这件事情应该怎么理解
这里面产品的理解
还有很多机制的抽象策略的判断
都非常适合使用chat模式
而不是直接让Codex去
修改本地的项目
写一个MD的文档
还有很多任务
它是不依赖于项目的目录去讨论的
比如说一些数学问题
一个临时的提问
一些情感问题
医疗问题
电影的分析等等
这种即时的问答
如果说每一个
都去开一个项目窗口
反而显得非常的笨重
还有一个方面啊
我们在我们的移动的APP端
GPT仍然是存在的
它会承担很多的语音实时
交流和移动端对话的这些功能
它仍然非常具有独立的价值
第二个板块想和大家聊的是
GPT的这一次的改变和更新
对于我们日常的工作和项目推进
有哪些值得研究的点
需要重点关注
对我们的帮助会体现在哪里
我觉得这一次真正值得研究的点
就是我前面也有点到
说的那个功能叫做Add to task
这个功能的重要之处
它在于Openai它开始把chat和
workflow融合为同一个对象
如果是我频道的老观众
可以看到我在提示词这方面
是有非常深度的
研究和高级的应用的
我在最开始做了很多
自动化的元提示词
再进化到GPT和Codex的Loop
再进化到多agent的协同的Loop
而现在
这一次GPT的这次底层的重大更新
它实际上是实现了把一个对话变成
一个可以持续运行的过程和任务
以前这个chat它是有
一个天然的问题的
chat它的生命周期是比较短的
一个对话结束了
这个chat就结束了
当然我做的工作很多时候是
把这个chat的生命周期再延续
那个时候我做的是什么事情呢
我把这个chat变成一个元提示词
不断地升级迭代
就相当于前一个chat它跑出来的结果
我会给它叠甲
叠到后一个chat里面
而且我会给它做一个hand off的文件
就是一个交接文档
这样子他就把前一个Chat的
生命周期往后不断地在延在迭代
又或者说
我会把在Codex的执行
成果和节奏步骤的回执
我会让Codex定期的给我回执
我把这个回执回给chatgpt
实际上也是在延续
这个Chat的生命周期
但不管我怎么做
这都是人工方式的缝合
当然我想说
这样的思路和方式确实帮我
完成了Chat生命周期的延长
以前我把上下文搬出来
需要我这个human
我这个人去做
现在Openai用系统解决了这个问题
你想想原来的逻辑是什么
比如说我要构建一个声音系统
我先在GPT里面去聊
形成我的总纲
然后形成Codex的指令
然后我把指令给到Codex
帮我去搭建了这个声音系统
然后再打造了对应的这个skill
两者对应的MD的文档好
这个chat是不是就死了
当然我是想办法让它不死
那现在有了Add to task这个功能之后
就会变成
你先chat
然后这个chat呢就变成了一个任务
这个任务和这个CHAT
就可以持续地执行
这个任务本身其实就是
这个CHAT生命力的延续
这个时候它的上下文
就不需要重新构建了
我一直在说
GPT的模型这么强
它的执行能力
包括最后的Harness的精准性这么强
和它非常强大的
上下文能力是离不开的
以前你聊天聊的这个上下文和
这边执行的上下文它是断裂的
而现在每一个提示词都是
一个持续运行的工作流
一个持续生长的上下文
而且我觉得一个非常
重要的变化是什么
注意啊前方高能
我觉得这个变化非常重要
就是说以前这个prompts
它实际上是一个function
是一个函数
就是你给它一个input
然后给你输出一个output
但是现在prompt变成了一个对象object
这个prompt它可以在这个
对话里面拥有生命周期
拥有状态拥有上下文拥有历史
这个就是软件工程里面
的function变成了object
这个实例化的这个转变啊
可能很多人都低估了它的重要性
很多时候你的想法没办法推进
你的整个的知识地图是乱的
就是你没有把所有的
内容结构化和实例化
以前所有的CHAT你需要自己维护
现在你所有的CHAT都
能够变成一个任务
一个task
它具有长的生命周期
而且还有一个好的点是什么
就是你在任务的进行过程中
你可以不断地去给它加新的chat进来
哇这个功能实在是太好了
因为我之前在缝合的时候
明显发现
就是我去缝的时候
我的Codex和GPT它可能是不同步的
它是有一点断裂的
而且就是它的整个的体感
左右多窗口切换会非常的不好
现在好了
你可以所有的话不用一次性说完
你的任务执行的过程中
你可以同步地跟chat
去聊天把聊出来的上下文
你认可的东西
把它加到这个任务里面
给它丰富它现有的
上下文和项目背景
这个用法实在是太爽了
以前呢我们发现项目不对
那么我就可能需要
重新给出新的提示词
现在我们发现项目有一些偏移
我要重新loop
我只需要任务执行的过程中
然后加入我update的这个信息
不断地update继续update继续
我的loop这个环就会更加的丝滑了
你会感觉到你的agent在
这个过程中一直在成长
这意味着什么
所有的对话都可以升级为工作流
而所有的工作流都是动态
最后啊第三部分给大家分享一下
我认为chatgpt的这次更新
它会带来什么样的影响
未来的走向如何
首先谈谈我直接的体感
我觉得这些功能更新非常有价值
我非常的兴奋
在未来几个月
我会深度的使用这些功能
如果发现了好的应用和玩法
会在这个频道跟大家做后续的分享
当我第一次看到它
的这个更新的时候
我的想法是GPT again
GPT这次更新我认为它是
又一次具有划时代意义的
虽然山姆奥特曼经常画饼
虽然他之前也拉了红色警报
但不管怎么说
Openai GPT
它仍然终究是软件形态的引领者
我相信在未来一段时间内
国内的所有的大厂APP在一两个
月内都会变成它一样的形态
后面大家可以到我这条视频来考古
看我说的对不对
这些APP我觉得都会跟进这种模式
把chat并入到agent
并且实现人类的对齐
人类的审核
agent执行者和agent Loop
的完整形态的升级
最后all in one
虽然曾经在很多访谈里面
国内的一些开发者
包括国内大厂的一些APP的领导者
包括很多AI的观察者
大家都知道说要去哪里
都知道说要all in one
都知道要抢这个agent的入口
但是如何去到这个目的地呢
其实没有人给出答案
现在实际上是ChatGPT给出
了一个相对完美的答案
现在这个答案
它实际上是由GPT不断的
试错摸索才完成出来的
特别是Codex最近几个月非常
高频度的迭代升级和优化
在这个过程中
它使用和积累了大量的工程数据
正是有这样的数据
积累和不断的升级迭代
才让Openai的工程师能够知道agent
的工作细节和交互的细节
我认为啊
Openai作为AI产品的引领者
它在AI产品形态这一块
一直是有比较深刻的认知和判断的
如果我们把过去两年的
产品演进放在一起来看
就能看出一些端倪
一开始的memory是让用户
变成一个持续存在的对象
到后面的project
它是让项目变成
一个持续存在的对象
再到Codecs
它是把工程环境
变成持续存在的对象
再到work
把工作空间变成
一个持续存在的对象
现在的Add to task这个功能
它是把一次聊天变成
一个持续存在的执行对象
这些功能看上去是独立的
但它并不是孤立的
要把chatgpt变成一个拥有长期的
持续执行和可演化的工作流的系统
所以这不就是Openai正在努力
覆盖研究编码文档和持续
工作一个super APP的一个大图吗
GPT5.6的这一次更新
你的使用体感怎么样
也欢迎在评论区跟我分享
记得订阅灵姐说AI
不要错过后续的精彩视频
今天就先聊到这里
我们下期再见啦拜拜
GPT这次更新我认为它是
又一次具有划时代意义的
Openai GPT
它仍然终究是软件形态的引领者
我相信在未来一段时间内
国内的所有的大厂APP在一两个
月内都会变成它一样的形态
后面大家可以到我这条视频来考古
看我说的对不对
这些APP我觉得都会跟进这种模式
把chat并入到agent
并且实现人类的对齐
人类的审核
agent执行者和agent Loop
的完整形态的升级
最后all in one
虽然曾经在很多访谈里面
国内的一些开发者
包括国内大厂的一些APP的领导者
包括很多AI的观察者
大家都知道说要去哪里
都知道说要all in one
都知道要抢这个agent的入口
但是如何去到这个目的地呢
其实没有人给出答案
现在实际上是ChatGPT给出
了一个相对完美的答案
现在这个答案
它实际上是由GPT不断的
试错摸索才完成出来的
特别是Codex最近几个月非常
高频度的迭代升级和优化
在这个过程中
它使用和积累了大量的工程数据
正是有这样的数据
积累和不断的升级迭代
才让Openai的工程师能够知道agent
的工作细节和交互的细节