Codex 和 Claude 推出之后，我都持续使用，目前也同时订阅两个产品。桌面端的交互方式、模型特点和任务节奏各不相同，这些差别决定了我会把对话、写作、编码和 review 分给不同的产品。
Codex 桌面端的产品设计
我是从 Codex 桌面端推出之后开始深度使用的。当时 Claude 的桌面端只能使用官方订阅，而 Claude 的官方订阅比较难订阅到，我只能通过官方 API 或者第三方中转站的方式使用，没有办法使用它的桌面端应用。Codex 推出桌面端应用之后，我觉得桌面端应用会比终端方便很多。
不过 Codex 桌面端刚推出的时候性能特别差，开两个项目的会话就已经卡得不行，内存泄漏的问题很严重。即便性能有问题，一个可以看到的 Agent 还是让我用起来比较方便。比如在左侧可以直接查看我已经配置了哪些 Skill，相比在终端里查看，可视化的呈现更直观。
桌面端推出之后，Codex 不断在产品里加入一些关于 Agent 设计的巧思。比如宠物功能，可以在设置里自己配置宠物；还有快速的应用截图、内置的浏览器，以及通过 computer use 和 Chrome 浏览器拓展来自动化控制电脑。
在后续的迭代中，Codex 的 UI 越做越好，一直保持一个很清爽的状态。目前我认为 Codex 是各种本地 Agent 里面使用体验最流畅的：即便开很多会话，在不同会话之间切换、滚动的时候几乎都没有卡顿。这一点很难得，Codex 的底层使用 Rust 编写，性能方面做得比较好。
除此以外，官方也推出了很多第一方插件。第一方插件里除了 Skill 之外，还有自己的连接器和 MCP，打包组合在一起。
Codex 对非开发者也有更集成化的包装。它的方向是把 Codex 做成一个更通用的 Agent，往 OpenClaw、Manus 这个方向发展，想要用来取代 GPT——GPT 毕竟是纯对话的，上限比 Codex 低。如果能够用 Codex 替代 GPT，对 OpenAI 来说肯定是一件很好的事情。
为什么最近这么多人开始使用 Codex？之前 OpenClaw 火过之后，大家会发现各个 Agent 之间的能力大差不差，OpenClaw 能火是因为它可以方便地接在手机、飞书、微信这些应用上。但后面大家发现，如果有一台电脑，在手机上操作的效率始终不如电脑。大家要求的是更强的模型能力、更好的 Agent harness，以及更好的交互页面。对我自己来说，做生产力相关的工作（比如开发）时，很多时间要用来验收它的成果：手机上看 HTML 不方便，各种调试环境也没办法看，所以我宁肯随时随地打开笔记本，也不想用手机跟它对话。就桌面端的 Agent 应用来说，我认为目前 Codex 是做得最好的。
Claude 桌面端的产品设计
第一次使用 Claude 桌面端的时候，会觉得它比 Codex 更有艺术气息。Claude 不管是官网设计还是 UI 传达，都是暖色调加上衬线文字，比较体现人文感；相比之下 Codex 更现代一点。
Claude Code 的整体 UI 可读性没有那么强。我现在的文字是自己调整过的，比原始的大很多；默认情况下左侧栏很小，而且很多文字使用衬线字体，读起来没有 Codex 那么舒服、清爽。
还有一个区别：Claude 把不同的常用功能切成了三个大的标签页。一个是 chat，就是普通对话；一个是 Cowork，面向非编程群体，类似 Manus 或者 OpenClaw 这一类；还有一个是 Claude Code。它们对应的产品化包装不太一样：Cowork 更注重 PPT、Excel、Word 这些非代码类文件的展示和功能集成；Claude Code 里则有分支工作树、代码 diff 这一类的 UI 展示。一个是通用入口，一个是按场景区分，这两种取向各有各的好处，没有哪个一定好、哪个一定不好。
但是从对话里的产品化包装来说，Claude Code 目前做得不如 Codex。比如 Codex 里有一个很实用的侧边栏功能：打开侧边栏之后，可以基于当前上下文开启一个新的对话，也可以在右侧查看文件，对话过程中还能看到它交付的产物。Claude 也可以在对话过程中打开侧边栏，但没有 Codex 这么灵活，最主要是缺失了基于当前上下文继续对话的能力。
Claude Code 也有自己的好处。比如在一个对话里可以回滚到之前的状态；Codex 只能重新编辑上一次发送的最后一条内容，而且代码是没有办法回滚的，它没有 checkpoint 机制。这两个点我觉得都不如 Cursor 做得好。
还有一个很重要的点：Claude Code 里 AI 读取图片或者调用工具生成图片之后，没有办法直接在对话里展示出来。Codex 在这方面做得比较好，它读取的图片和生成的图片都可以直接在对话里渲染出来。另外，Claude Code 里 Skill 这一类的配置没有 Codex 做得那么可视化，自定义选项也不如 Codex 桌面端丰富。相比之下，我经常觉得 Claude 在桌面端使用和在终端使用做得差不多，有的时候甚至终端的使用体验会更好一点。
模型：GPT 5.5 的特点
Codex 里面现在用的是 GPT 5.5，可以开 Fast 模式，速度特别快。但是我觉得 Codex 里的 GPT 相较于 Claude 会更难驾驭一点。
难驾驭体现在它比较喜欢钻牛角尖。比如写 Skill 的时候，Skill 作为一个 SOP 是通用的。假设调用 Skill 时某一次出现了错误，我想让它优化这个 Skill，它会喜欢把特判逻辑写进去。比如我的发布视频 Skill 在发布某一个平台的时候失败了，它就会写很多专门针对这个平台的 if else，而这些内容很可能影响其他平台发布时的流程。它很喜欢把局部的东西写进通用的东西里面，对整个大局没有那么有大局观。
它的干活能力很猛，但还有一个点：它很喜欢写 fallback 逻辑、兼容性逻辑，不喜欢把陈旧的东西直接删掉。如果长时间不关心代码，它会越写越多、越写越差。必须认真花时间检查代码写得怎么样，去治理一下；或者安装一些 Skill，让它写更精简的代码，让它在写代码的过程中自己回头看：有没有做足够的组件化，有没有做足够的函数化，有没有把大的文件拆分。如果不提，一个文件写四五千行也是常态。
还有一个点是 GPT 5.5 在 Codex 里开放的上下文太小，只有二十多万。如果是比较复杂的项目，第一次让它读代码，问完第一个问题、它把代码梳理出来之后，问第二个问题的时候就已经触发上下文压缩了。这样的使用体验没有那么好，毕竟上下文压缩总会有一些细节的偏移。不过 Codex 的上下文压缩带来的影响其实已经很小：它的上下文短、干活速度快，我经常一个会话触发十几二十轮上下文压缩，但依然在这个上下文里面继续对话，因为我相信它的指令遵循性做得比较好。
创意和设计方面，Codex 的表现没有那么好。只给一句话、让它自行发挥时，结果经常达不到我的要求。它更适合执行已经明确的任务：比如微调页面里的一个设计细节，只要描述足够清楚，它通常能够快速、准确地完成修改。
模型：Claude Opus 的特点
Claude 我目前主要使用两个模型：opus 4.8 和 opus 4.6。opus 4.6 主要用来帮我写 PPT 和文档，opus 4.8 写代码比较多一点。
我认为 opus 4.6 是目前最聪明的模型，也是人味最浓的模型。让它写文档会写得特别好，而且跟它的沟通感很强，我会觉得它很懂我的意思，创意能力也不错。我有很多 PPT 让它写，只要给它足够的我之前的参考，它写出来就是我的那个风格。
Claude 的问题是速度比 GPT 5.5 慢很多。它的慢不是慢在思考上，而是 token 输出的速度特别慢。我日常使用会开 Fast 模式：使用 opus 4.8 的时候开 ultracode，使用 opus 4.6 的时候开 max 模式。
Claude 做事情的时候谨慎程度更高，对我们意思的理解也更好。比如跟 Codex 说「你帮我看看要怎么解决」这种稍微模糊一点的描述，它看完就会直接去解决这个问题；而 Claude 可能会向我们问问题。Claude Code 里有一个默认开启的工具，它在任何情况下都可以调用这个工具向我们发问、获取信息；而 Codex 只有用斜杠命令开启 plan 模式之后，才会向我们发问。这一点可以看出这两个 Agent 在设计上的差别。
另一个区别是子 Agent 的调用策略。Codex 默认不会调用子 Agent；Claude Code 非常积极地调用子 Agent，尤其是开了 ultracode 模式、使用 dynamic workflow 的时候，它经常会开五六路子 Agent 并行做调研或者编码，而且不只是单轮——有时候第一轮六路子 Agent，下一轮再开两路。这导致我使用 Claude Code 时，稍微复杂一点的任务就得让它自己干一两个小时；但同样的事情给 Codex，可能十几分钟就干完了。
Claude Code 的默认策略也有好处。由于模型很强，它触发提问的时候，我会觉得它问的问题是很好的。能力比较弱的模型喜欢问一些没有必要的问题：给的四个选项都是错的，或者问题本身它自己就能想清楚，只是单纯走一下流程。Claude Code 一般是遇到真正重大的、需要我做决策的时候才会提问，而且给出的选项都会觉得确实有点道理，确实需要自己选择一下。
我的使用方式
我目前的日常使用姿势是：对话还是跟 Claude 去对话，因为跟 Claude 对话会让我感觉比较舒服；写文档的时候也肯定会用 Claude。
Codex 还有一个很大的、由模型带来的弱点：做网页设计或者写文档的时候，它很喜欢把一些元数据写进去。比如我让它写一个设计清爽的 HTML，它就会把 HTML 里面的文案写成「这是一个设计清爽的 HTML」，我不明白这种文案为什么要写到 HTML 里面去。Claude 不会做类似的事情。修改文档的时候也一样：假设文档是面向同事写的，最终要交付给其他人看，读者不需要看到文档的迭代信息，Claude 不会把这些历史信息频繁地加进去；而 Codex 每次修改，都会把历史信息、像是我们的对话记录一样写进文档。
要干活的时候，我会让 Claude 调用一个叫作 Codex 的 Skill，这是我很久之前写的一个 Skill。干活或者图片生成都可以交给它——Codex 的一个好处就是可以生成图片，我要生成图片的时候也会让 Claude 调用 Codex 来生成。比较长、比较复杂的活，也是 Claude 出方案、Codex 执行。做代码 review 的时候，Codex 去 review 代码会很快，而且上下文相对独立出去了，Claude 自己的消息会比较干净，只需要负责修复。
如果目前只保留一个应用，我会选择 Codex。它的风控限制比 Claude 少，一些中转服务的价格也更低；桌面端还集成了 image_gen，可以直接使用 GPT Image 2。做 PPT、编写前端和生成配套图片时，这项能力会减少工具之间的切换。
Claude 仍然负责我更看重交流、文案和设计判断的任务。我的实际用法没有把两者分出绝对高低，而是让 Claude 保持对话与方案的上下文，再把执行、图片生成和代码 review 交给 Codex。