news 2026/8/13 22:17:27

如何看待 Codex 与ChatGPT 合并,实际使用体验有什么变化?

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
如何看待 Codex 与ChatGPT 合并,实际使用体验有什么变化?

这次我觉得不能简单理解成:

“OpenAI 把 Codex 的入口塞进 ChatGPT 了。”

2026 年 7 月 9 日,OpenAI 正式宣布 Codex App 开始与新的 ChatGPT 桌面端合并。Codex 并没有消失,它仍然是面向软件开发的 Coding Agent,只不过现在和 Chat、Work 放进了同一个 ChatGPT 体系里。

我用一句比较直白的话概括这次变化:

以前 ChatGPT 负责跟你聊“怎么做”,Codex 负责真的进去“把它做了”;现在这两个东西终于开始长在一起了。

而且我觉得这个变化,比单纯更新一个 GPT-5.6 模型更值得关注。

以前用 ChatGPT + Codex,其实有一种很明显的割裂感

比如我想做一个网站。

第一步,我可能先打开 ChatGPT:

“我准备做一个库存管理系统,应该怎么设计?”

然后和 ChatGPT 聊:

产品需求。

数据库结构。

页面功能。

技术栈。

权限设计。

聊了半天,方案差不多了。

接下来真正开始写代码。

切到 Codex。

然后又得告诉 Codex:

我要做什么。

项目在哪里。

技术栈是什么。

刚才确定了哪些需求。

有哪些地方不能改。

虽然两边本来就可以使用同一个 ChatGPT 账号,而且 Codex 也早已经包含在 ChatGPT 的相关套餐里,但从使用习惯上看,很多人还是会把它们理解成两个工具。

一个负责:

想。

一个负责:

干。

现在 OpenAI 明显是在把这条线抹掉。

合并以后,我最大的感受是:ChatGPT越来越不像“聊天机器人”了

现在新版 ChatGPT 的思路其实已经很清楚。

官方目前把它分成三种主要体验:

Chat:聊天、搜索、快速问答。

Work:长任务、研究、分析、PPT、表格、文档等成品交付。

Codex:软件开发和技术工作。

所以以后你打开ChatGPT,思维方式可能不是:

“我要问AI一个什么问题?”

而是:

“我要让AI帮我完成什么事情?”

这两个思路差别非常大。

比如:

“React里useEffect为什么执行两次?”

这是Chat。

“分析一下这个项目为什么登录偶尔失败。”

这是Codex。

“分析过去一年的销售数据,最后给我做成一份汇报PPT。”

这是Work。

以前这些事情可能需要三个不同的软件或者工作流。

现在OpenAI明显想让它们全部从ChatGPT开始。

对程序员来说,最明显的变化其实是“少切软件”

这个看起来是小事,实际体验提升挺明显。

以前我的工作可能是:

浏览器里ChatGPT。

VS Code里写代码。

Codex App跑Agent。

GitHub看PR。

浏览器看前端效果。

Terminal跑测试。

几个窗口来回切。

现在Codex并入ChatGPT桌面端以后,OpenAI还顺手给Codex增加了不少开发相关能力,包括diff里的行内编辑、侧边栏PR Review、更快的Computer Use,以及一个项目同时支持多个repository。

所以它越来越像:

一个AI开发工作台。

而不是单纯的聊天窗口。

尤其是多仓库这个东西,对稍微复杂一点的项目其实挺实用。

比如:

frontend一个repo。

backend一个repo。

内部组件库又一个repo。

以前Codex处理这种项目比较容易割裂。

现在一个Project可以覆盖多个repository以后,就更接近真实公司的项目结构了。

第二个变化,是“聊天”和“执行”的距离越来越短

我觉得这个才是最重要的。

以前AI最烦的一件事情就是:

它特别会告诉你怎么做,但最后还是你自己做。

比如你问:

“这个页面为什么加载这么慢?”

ChatGPT给你分析半天:

可能是数据库。

可能是API。

可能是前端bundle。

可能是缓存。

最后来一句:

“建议你使用Chrome DevTools进一步排查。”

然后你自己去干。

Coding Agent出现以后,逻辑开始变成:

你:

这个页面最近加载特别慢,帮我找原因。

Codex:

读取项目。

检查相关代码。

运行程序。

分析请求。

查看日志。

定位问题。

修改代码。

跑测试。

然后告诉你:

我找到问题了,修改在这里。

这才是我觉得“ChatGPT + Codex”真正应该发展的方向。

不是让ChatGPT回答得越来越长。

而是:

回答完以后,它能不能顺手把事情做掉。

GPT-5.6 又把这种感觉往前推了一步

这次合并恰好又碰上GPT-5.6。

目前GPT-5.6 Sol已经可以在Codex里使用,OpenAI对它的定位本身就包括复杂Coding、Computer Use以及更长时间的工作流;Codex里Plus、Pro、Business、Enterprise等符合条件的方案可以使用Sol、Terra和Luna。

这就产生了一个挺有意思的变化:

以前使用Codex,很大一部分精力是在指导AI怎么工作

现在越来越多时候,只需要告诉它:

最后我要什么。

比如以前Prompt可能写:

先读取项目结构,找到认证模块,不要修改现有API,分析依赖以后修改代码,然后运行测试,如果测试失败继续修复,最后总结修改内容。

现在我可能直接说:

重构登录模块,保持现有API兼容,完成以后跑测试。

然后让它自己规划。

模型越强,这种变化越明显。

这其实也和前面很多人开始减少低价值Skills是同一个逻辑:

我们正在从“教AI每一步怎么做”,转向“告诉AI最终要达到什么结果”。

第三个变化我觉得很多人会喜欢:手机开始真正有用了

以前手机上的ChatGPT主要还是聊天。

你不太可能拿手机真正写一个大型项目。

但Codex现在已经进入ChatGPT手机App。

而且不是让你拿手机敲代码。

它的思路是:

电脑干活,手机遥控。

OpenAI在5月份就开始推出这套体验:Codex可以继续在连接的Mac上工作,而你在ChatGPT手机端可以查看任务、继续Thread、回答Codex的问题、改变方向、审批操作以及查看diff和测试结果。

这个场景其实特别真实。

比如你让Codex:

把后台管理系统升级到新版本,顺便修复测试。

然后出门吃饭。

半小时以后手机弹出来:

Codex遇到一个需要你决定的问题。

你看一下:

“选方案B。”

它继续干。

以前这种Agent一旦离开电脑,基本就断了。

现在越来越接近:

你不是坐在电脑前陪AI工作,而是AI工作,需要你的时候再找你。

我觉得这个体验上的变化,可能比模型Benchmark提高几个百分点更重要。

但合并以后,也有一个我觉得比较容易误解的地方

就是:

Codex并没有变成普通ChatGPT聊天。

OpenAI现在依然把它们分得很清楚。

Chat负责快速交流。

Work负责长时间知识工作和成品交付。

Codex仍然专门负责软件开发和技术任务。

所以不是说以后:

打开ChatGPT随便发一句话,它就开始修改你的电脑。

权限、工具和任务模式还是有区别的。

我反而觉得这样比较合理。

否则聊天的时候随口说一句:

“这个文件看起来没什么用了。”

AI:

“好的,已经帮你删除。”

那才是真的吓人。

对普通人来说,这次合并其实比程序员更值得关注

很多人看到Codex两个字就觉得:

和我没关系,我又不写代码。

但OpenAI这次其实释放了一个很明显的信号。

7月发布的新ChatGPT Work已经直接使用了Codex技术,让ChatGPT能够处理文件、应用和网页,并持续完成复杂任务。OpenAI还披露,当时Codex每周用户已经超过500万,其中超过100万人会把它用于软件开发之外的工作。

这就很有意思了。

Codex最早训练出来的是一种能力:

理解任务 → 使用工具 → 执行 → 检查结果 → 继续执行。

这种能力为什么只能写代码?

完全可以:

整理Excel。

制作PPT。

分析资料。

修改网站。

整理文件。

做市场研究。

处理重复办公流程。

所以我觉得这次所谓的“Codex和ChatGPT合并”,真正的重点可能不是:

Codex进了ChatGPT。

而是:

Codex这种Agent式工作方式,开始进入整个ChatGPT。

当然,现在的体验还远远没到“AI员工”的程度

这个也得说。

Agent最大的问题一直不是:

“它能不能做。”

而是:

它能不能连续做几十步都不犯错。

一个任务只有3步:

每一步95%正确率。

体验很好。

一个任务50步:

中间任何一步理解错了,都可能一路跑偏。

所以现在使用Codex,我还是会看:

它改了哪些文件。

测试是不是真的通过。

有没有偷偷改需求。

有没有为了通过测试把测试本身改掉。

涉及删除、部署、权限、生产环境的时候,更要自己确认。

模型变强和产品合并,都不意味着:

从此可以闭着眼睛把项目交给AI。

至少现在还远没到这个阶段。

所以我怎么看这次合并?

我觉得这是ChatGPT这几年非常关键的一次产品方向变化。

2022年的ChatGPT解决的是:

“AI能不能听懂我说话?”

后来解决:

“AI能不能把问题回答得更聪明?”

Codex开始解决:

“AI能不能自己去干活?”

现在把Codex能力逐渐并进ChatGPT以后,OpenAI真正想解决的问题已经变成:

“我能不能只告诉AI我要什么,然后等它把结果交给我?”

这才是这次合并真正有意思的地方。

所以实际体验上的变化,我会概括成一句:

以前我打开ChatGPT,是准备和AI聊一件事情;现在越来越多时候,我打开ChatGPT,是准备把一件事情交给AI。

从“聊天工具”到“工作入口”,我觉得这才是ChatGPT和Codex合并真正要走的方向。

至于最后能不能做到所谓的“AI员工”,现在还不好说。

但至少从Chat、Work、Codex被放进同一个ChatGPT,以及Codex开始打通桌面、网页和手机来看,OpenAI现在想做的显然已经不只是一个更聪明的聊天机器人了。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/13 22:16:20

(论文速读)DarkIR:稳健的微光图像恢复

论文题目:DarkIR: Robust Low-Light Image Restoration(DarkIR:稳健的微光图像恢复) 会议:CVPR2025 摘要:夜间或黑暗条件下的摄影通常会受到噪音、光线不足和模糊问题的困扰,这是因为环境昏暗和…

作者头像 李华
网站建设 2026/8/13 22:13:03

边看直播边聊的数字人Agent,5款数字人口播横评实测

盯弹幕盯到眼瞎,直播运营到底怎么把数字人拉进来一起看做直播运营的人都懂:主播在讲品,运营要同时盯弹幕、看礼物、回评论、切链接,眼睛根本不够用。很多人开始想,能不能让一个数字人Agent和我一起看屏幕、一起聊弹幕&…

作者头像 李华
网站建设 2026/8/13 22:10:52

现代 C++ 异步编程:从零实现一个高性能 ThreadPool (C++20 深度实践)

在高性能 C 开发中,线程池是绕不开的核心基础设施。随着 C20 标准的普及,我们能够以更简洁、更安全的方式实现一个生产级的线程池。本文将带你深度剖析一个基于 std::jthread 的线程池实现,并探讨其背后的架构思考与内存管理机制。1. 核心代码…

作者头像 李华
网站建设 2026/8/13 22:09:32

开发者技术搜索安全指南:从官方文档到代码验证的全流程实践

最近在技术社区看到不少关于“最可怕的搜索引擎”的讨论,很多开发者,尤其是刚入门的新手,在寻找技术解决方案时,可能会误入一些存在安全风险、隐私泄露或提供恶意代码的网站。本文并非要讨论某个具体的搜索引擎,而是想…

作者头像 李华
网站建设 2026/8/13 22:04:52

软考高项新考点:数字化转型、数据要素、元宇宙相关概念体系梳理

摘要本文系统梳理了软考高级信息系统项目管理师(高项)考试中新增的三个重要考点:数字化转型、数据要素和元宇宙。文章从核心概念、关键特征、技术体系、应用场景及对项目管理的影响等多个维度进行阐述,旨在帮助考生构建清晰的知识…

作者头像 李华
网站建设 2026/8/13 21:59:11

React Native与OpenHarmony动态标题栏开发实践

1. 为什么需要动态标题? 在移动应用开发中,标题栏(TitleBar)是与用户交互的重要界面元素。传统开发模式下,我们通常在页面组件挂载时通过 setOptions 静态设置标题,这种方式存在几个明显痛点:…

作者头像 李华