摘要

ChatGPT桌面端更新后，Codex被合并进新的ChatGPT应用，但仍保留独立的编码体验。对开发者来说，真正变化不只是入口变了，而是需求整理、代码修改、测试验证和文档交付可以更自然地串成一个工作流。

OpenAI近期更新ChatGPT桌面端，将原来的Codex App合并进新的ChatGPT应用。官方说明中提到，Codex仍然保留面向开发者的独立编码体验，同时新增了diff内联编辑、侧边栏PR审查、多仓库项目和更快的计算机使用能力。(openai.com)

这次变化最值得关注的，不是“Codex是不是消失了”，而是开发者的工作流开始发生变化。

以前，很多开发者的使用方式是分开的：

ChatGPT用来问问题、写方案；
Codex用来读项目、改代码；
文档再单独整理。

合并后，这些环节更容易在同一个桌面应用里完成。

一、需求整理更适合交给Chat或Work

开发任务开始前，最容易出问题的不是代码，而是需求没说清楚。

比如：

要改哪个模块？
允许动哪些文件？
是否要兼容旧逻辑？
测试标准是什么？
上线前需要哪些检查？

现在更适合先用Chat或Work整理需求，再交给Codex执行。OpenAI介绍中提到，ChatGPT Work可以从文件和插件中获取上下文，生成文档、表格、演示文稿和其他可审阅成果，并让用户在关键操作前确认。(learn.chatgpt.com)

也就是说，开发者可以先让ChatGPT把需求转成任务清单，再让Codex处理具体代码。

二、代码修改仍然交给Codex

虽然入口合并了，但Codex的核心定位没有变。

它仍然更适合：

读取代码仓库；
修改多个文件；
运行测试；
检查diff；
处理PR审查；
管理多个代码任务。

OpenAI的Codex更新说明也写到，Codex在新的ChatGPT桌面端中保留专门的编码体验，并支持Chat、Work并列使用。(learn.chatgpt.com)

所以，不建议把真实项目直接丢给普通Chat窗口处理。

如果任务涉及代码仓库、终端命令、测试和文件修改，仍然应该进入Codex模式。

三、测试验证更不能省

AI写代码变方便后，最危险的习惯是直接相信“已完成”。

开发者仍然要检查：

git diff改了哪些文件；
测试是否真正通过；
有没有新增无关依赖；
有没有改动配置文件；
有没有删除旧逻辑；
有没有泄露密钥或内部信息。

合并后的好处是，Codex可以更方便地在同一个工作区里完成修改、审查和说明，但最终是否合并，仍然需要开发者判断。

AI可以加快开发流程，但不能替代代码审查。

四、文档和复盘可以顺手完成

以前写完代码后，很多人还要手动整理：

修改说明；
PR描述；
测试结果；
接口变更；
上线注意事项；
使用文档。

现在更适合让ChatGPT根据Codex任务结果生成初稿。

比如：

“根据这次修改，帮我整理一份PR说明。”
“把测试结果整理成上线前检查清单。”
“把这次Bug原因写成复盘文档。”

这也是合并后的实际价值：不只是写代码，而是把开发前后的文档工作一起串起来。

五、开发者工作流会变成这样

更合理的流程可以是：

第一步，用Chat或Work整理需求和边界。

第二步，让Codex读取项目并提出修改计划。

第三步，只允许Codex修改指定模块。

第四步，运行测试并检查diff。

第五步，用Chat整理PR说明、测试结论和复盘文档。

这样比直接说“帮我重构整个项目”更稳定，也更符合真实工程流程。

总结

ChatGPT和Codex合并后，开发者工作流确实变了，但不是“所有东西都交给AI自动完成”。

更准确地说，是开发流程开始从单点工具变成统一工作台：

Chat负责解释和沟通；
Work负责整理资料和任务；
Codex负责代码修改和验证；
开发者负责边界、审查和最终决策。

对开发者来说，真正值得学习的不是入口在哪里，而是如何把需求、代码、测试和文档组织成一条清晰的AI协作流程。