最近一段时间，我一直在反复比较 ChatGPT、Codex 和 Claude Code 的使用体验。
原因很简单。我现在主要使用 ChatGPT，每个月为订阅支付约 100 美元，也依赖 Codex 维护几个自己开发的软件。我希望它能够越来越好用，最好能接近甚至超过我过去使用 Claude Code 时的效率。
但比较了一阵子，我发现自己最初提出的问题可能就不够准确。
我一直在问，Opus 5.5 为什么审美好？为什么 Claude Code 用起来那么顺手？为什么 GPT 明明有相当强的能力，最终交付却经常让我不满意？
后来我意识到，这些问题也许有一个共同的入口：Agent 到底有没有选对工作方式和交付形式。
我觉得 Claude 好用时，还没有 Opus 5.5
这一点我觉得有必要先说清楚。
我最初使用 Claude Code 时，甚至是从 Sonnet 5 开始的。后来转到 Opus 5，那时候网上对 Opus 5 的评价并不一致，负面声音也不少。可我自己的使用体验已经很好。那时，我并没有觉得 Claude 的底层模型相对其他公司的模型，已经形成了什么不可逾越的优势。我也不是因为后来 Opus 5.5 被吹上天，才回过头去赞美 Claude Code。恰恰相反。在 Opus 5.5 出现之前，我就已经觉得 Claude Code 更符合我的工作习惯。
后来从 Opus 5 到 Opus 5.5，包括我所接触和观察到的 Fable 5、Fable 5.1，社区里确实出现了很多非常惊艳的作品。但在我自己日常使用的开发任务里，我并没有感受到每一次型号升级都带来同样巨大的体验跃迁。
这让我开始怀疑：我喜欢的到底是某一个模型，还是 Claude Code 这套 Agent 产品本身？
设计稿的差异，可能在动笔以前就发生了
我最近让 ChatGPT 设计一款 macOS 智能家居应用 Nagi。
它是准备真正落地的软件，未来要在 iMac 的菜单栏长期运行，负责监测设备状态、发现 HomeKit 异常，并提供实际的设备控制。我希望得到一份完整的设计稿，最好还能有几个惊喜。
ChatGPT 交出了一张很完整的图片。图里有菜单栏、设备卡片、温湿度图表、房间照片、场景按钮，还有一堆圆角和渐变。作为视觉展示，它有一定的完成度。可我越看越觉得不对，这些图形元素最终怎么进入软件？把每一块都裁成 PNG？按钮怎么点？不同设备状态怎么变化？文字长度不一样怎么办？真正写成 SwiftUI 之后，能不能还原得和图片一样？这里的问题已经超出了“审美好不好”。我需要的是一份将来能够变成软件的设计，得到的却是一张描绘软件长什么样子的图片。
过去我用 Claude Code 讨论界面，它更常交付可点击的 HTML 原型，或者直接在 Claude Design 里完成界面。那样的设计第一眼未必惊艳，但我看得到交互，改得了间距，能直接讨论按钮状态，也知道下一步怎样继续落地。
HTML 并不等于原生 macOS 界面，更不能证明最终 SwiftUI 可以像素级还原。不过，它把结构和交互变成了可以反复修改的代码。比起让另一个 Agent 看着一张图片重新创造一遍，摩擦明显更小。
后来我发现，我们以前做 App 图标也经历过类似的事。一张图生成不满意，就继续生图。生到满意后，再交给 Codex，要求它照着图片重新画成可用于软件的资源。而 Claude Code 的思路常常更接近：既然最后要用在软件里，简单、可控的图标一开始就使用 SVG 或其他可编辑的矢量方式表达。
虽然有些复杂插画本来就适合位图或专业绘画，但我们当时反复经历的流程，确实多了一次成本很高的“重新实现”。
所谓好审美，有多少来自工程约束？
我最开始的时候觉得 Claude 的界面设计有些素。没有那么多彩色卡片，没有特别复杂的渐变，也不太喜欢堆满发光图标。有时候第一眼看过去，好像没什么可夸的。
后来真正把软件做出来，我才逐渐理解这种设计方式的好处。布局通过网格组织，字体和间距有秩序，颜色只用在重要的状态上。一个设计稿看起来是什么样子，落地之后就能非常接近这个样子。
我现在有一个假设：Opus 给人的一部分“高级审美”，来自它把实现和维护成本提前纳入了设计判断。如果必须交付真实的 HTML、SVG 或原生组件，模型就不能只考虑这张图够不够好看。它还要考虑文字变化、响应式尺寸、深色模式、设备异常状态以及下一轮修改。很多看上去华丽的设计，一旦要适配这些状态，就会变得昂贵。
所以，我并不认为“素”天然等于高级。真正值得肯定的是：克制的视觉语言，加上明确的功能层级和可靠的交互结构，往往能形成更稳定的产品设计。
这也许能够解释为什么过去我不够欣赏的那种界面风格，后来逐渐成为我喜欢的东西。
Computer Use 和生图，让我想到一个问题
最近 Codex 还有一件事让我很吃惊。我让它做一个可点击的 HTML 设计稿。它把文件写完之后，打开 Computer Use，开始在自己生成的页面上点击。需要测试真实渲染，这个逻辑当然成立。真正的问题是：它有没有判断这一次交付究竟需要验收到什么程度？
这份文件只是让我看、让我讨论的初稿。它完全可以交付一个可打开、交互状态大致成立的版本，并明确告诉我哪些地方没有测试。我的反馈本来就是设计流程的一部分。如果它把初稿当成正式发布版本，反复截图、点击、检查每一项状态，就会在我尚未确认设计方向以前，消耗大量时间。
图片生成也类似。工具非常直观，几秒钟就能展示一个完整的漂亮画面。但当目标是软件原型时，这种便利有可能诱使 Agent 选择一条离真实交付更远的路。
当然 Computer Use 仍然有价值，面对没有 API 的软件，它可能是唯一合理的操作方式。图片生成也能用于插画、图标氛围探索和宣传素材。但工具多了以后，选择哪种工具，本身就成了更重要的智能。
一场十四小时的任务，让这个问题变得更具体
除了设计，我还在做高中数学题库。我整理了数千道题，题目已经数字化入库，Agent 可以直接读取结构化文本。后续需要它做的，是根据已有四维评分文档解题、核对答案，再为题目评分。
有一轮任务运行了大约十四个小时。其中有两批都是 54 道题，一批用了约 28 分钟，另一批用了约 172 分钟。单看这个数字，我几乎无法理解。等任务完成以后，我让 Codex 根据实际日志进行审计。结果很有意思。
那一批特别慢的工作，除了评分，还混进了组件配置修改、命名方案反复变动、额外解题文档等事情；模型交互轮次明显增加，中途还有一次将近二十分钟的上下文压缩。工具调用和数据库读写本身只占很短的时间。真正冗长的时间，发生在一次次模型响应之间。现有日志还无法精确区分模型推理、服务端排队和网络等待。所以我不知道他到底解一道题需要多久。但是可以确定：Agent 没有很好地控制任务边界、交互次数和阶段交付。
它有能力做评分，却把另一堆没有被要求的事情一起做了。部分工作明明完成，我作为用户却迟迟拿不到阶段成果。这就是我一直觉得 Codex 用起来很累的原因之一。
我为什么认为问题不能全部归咎于底层模型
如果我只在 Opus 5.5 发布之后才开始使用 Claude Code，那么把体验差异归因于旗舰模型升级，似乎也说得过去，但我的时间线并非如此。
从 Sonnet 5、Opus 5 时期开始，我就喜欢 Claude Code 的任务组织、文件管理和交接方式。那时我们就会用 Markdown 保存阶段决定，通过项目结构继续工作，而不是每一次都要求我解释先前做过什么。这些细节并不一定上得了 Benchmark 排行榜，却极大地影响了我的开发体验。
我不是程序员出身。我可以讨论软件为什么需要某个功能，可以检查产品设计是否符合预期，却不希望为了让 AI 帮忙工作，还要去研究什么时候该开子代理、什么时候该压缩上下文、什么时候该停止验证。所以，我想把一个 Agent 的实际效果拆成几部分：底层模型能力、任务理解、工具选择、任务编排、交付形式，以及它能否把已完成成果及时交到用户手里。对最终用户来说，产品整体就要为交付负责。
一个模型很聪明，最后却让我花大量时间纠正它的工作方法，这依然会是不好的使用体验。
我认为 GPT-6 是可以使用的模型
我研究这个问题的原因是因为现在我用的是 ChatGPT。我每个月还在交订阅费，也希望它继续进步。
相较过去，我对 GPT-6 的 Chat 模式有很明确的正面感受：它在长时间讨论中显得更加理智，评价问题也更稳定，这对我这种重度聊天用户有直接价值。但 Codex 的开发交付离我过去熟悉的效率还有差距。
我不认为这两个模型在所有能力上存在无法追赶的鸿沟。至少从我的实践看，一部分差距很可能在产品和工作流层面，可以通过更合理的约束减轻。比如，我开始考虑把交付形式写进长期规则：真实软件设计优先交付可交互的 HTML 或原生代码；简单软件图标优先考虑可维护的 SVG；评分任务只做评分，遇到修图问题另行记录；一个阶段完成就更新交接，不必等到整场任务全部结束。甚至，我正在尝试用 Codex 的本地 Hook 做会话管理：长对话到了合适的节点，就先提醒我把工作交给新会话，而不是任由上下文增长，最后花二十分钟进行一次压缩。
这些办法是否有效，还有待实际检验。更严格的提示词可能节省时间，也可能增加新的复杂度。不能把“写了规则”当成“问题解决了”。
我真正希望 AI 帮我省掉的是什么
经过这一轮比较，我反而不想简单地写一篇“Claude 比 GPT 强”的文章。我开始欣赏的，是另一种能力：一个工具能不能主动替用户减少从想法到成品之间的摩擦。
当我说要设计软件，它知道我最后需要的是可实现、可讨论的界面。当我说要做图标，它知道这个图标以后必须进入真正的工程。当我睡觉前交给它很多任务，它知道哪些可以并行、哪些应该分阶段交付，某项工作失败不应该把全部成果拖在最后。当我要求它评分，它知道不要顺手修图、重构组件、写一堆我不会阅读的文档。这些事情单独看都不是什么惊天动地的技术突破，但加起来就是“顺手”和“不顺手”的差异。
我现在愿意通过长期指令、Hook 和工作流程调整，尽量让 Codex 接近那种体验。至少在我还依赖它工作的阶段，这值得试一试。但我也希望下一代 Agent 不必再让用户做这么多工作。
好的 Agent，应该能够理解我最终要拿到什么，并选择一条让我少返工、少等待的路。如果将来 OpenAI 真正补上这一层能力，对我来说，那种改进可能比又一次漂亮的模型排行榜更重要。