Claude Code、Codex 与 Cursor：AI 编程的三种思路

我想比较 Claude Code、Codex 和 Cursor 的产品理念，而不只是看哪个模型得分更高。我从 Cursor 转到 Claude Code，再转到 Codex，自己的工作方式也随之改变。关键是这些工具各自试图支持什么工作流程，以及未来可能走向哪里。

我不是要让所有人换工具。这些判断来自我的使用体验，而且有一个相关背景：我参与开发了接入 Codex 的智能体编程应用 T3 Code。文中功能和模型比较反映的是录制时的情况。

Claude Code 最初的想法很简单：随着模型变聪明，它可以直接在开发者的终端工作，不必把代码复制进聊天窗口再粘贴回来。Cursor 已经把聊天带入编辑器，而终端工具则能融入开发者现有的工具。

终端也带来取舍：粘贴和查看图片并不顺手，文本选择、间距和渲染也有困难。Claude Code 的全屏模式改变了界面的渲染方式；我更喜欢它，因为旧界面的闪烁让我难受，但这种方式也有代价。

它容易上手：安装 CLI、完成认证，就能继续使用原来的编辑器和 Git 流程，智能体只是终端里的另一个标签页。随着时间推移，用户又想要自动 Git 操作、感知拉取请求、MCP 连接、远程控制和并行工作。

Claude Code 增加了 hooks 等扩展能力，但我用它们做实验时遇到了一些不完善的地方。我的一个实验会在智能体完成任务时限制我访问 Twitter 等网站，促使我回来给它布置下一个任务。

对我来说，Opus 4.5 是一个转折点。模型的能力提高后，让它通过终端搜索仓库、执行命令和使用 MCP 变得更有价值。我更信任它写的代码，也就不再觉得必须在编辑器里盯着每一项修改。

因此，我经常在跳过权限提示的模式下运行这些工具。这只是我个人的工作方式，并不保证智能体不会执行有害命令；权限级别和运行环境需要根据任务及其风险来选择。

我的一个有争议的看法是，Claude Code 也在展示 Anthropic 模型的能力。动画和功能让智能体的活动显得很吸引人。这是我根据界面和使用体验推断出的产品倾向，并非对团队内部设计决策的证据。

演示中，我让它启动子智能体审查示例项目。界面显示 token 数量、状态更新、动画和各个智能体的活动。这种可见性让人感觉很有效率，并行智能体也确实可能完成有用工作，但界面忙碌本身不能证明结果的价值。

更多智能体可能消耗大量 token。我认为 Claude Code 比较愿意用并行工作换取结果，但实际成本取决于任务和套餐。我对集成限制及厂商锁定的担忧，是我对激励机制的解读，并不是对 Anthropic 动机的已证实解释。

我也觉得动画容易分散注意力，并认为它们与过去的性能问题有关。不过，这种有吸引力的体验确实让我投入了智能体编程。喜欢它的用户并没有错：让工作显得有活力正是它的吸引力之一。

我给 Codex 发出类似的项目审查请求。它的终端界面安静得多：一个计时器、工作状态提示，子进程的活动也不太显眼。这是在展示界面差异，并不是对两款工具完成任务质量的受控测试。

在我看来，功能更新也体现了这种差异。Claude Code 的电台命令比较有趣；Codex 允许在 Mac 锁定时继续使用电脑的选项不那么抢眼，但在我的环境里很实用。我偏爱减少实际摩擦的功能，即使它们不适合做炫目的演示。

另一个例子是快捷键：它能把我正在看的画面截图送给 Codex 作为上下文。我喜欢给智能体提供视觉信息。在我专用的 Mac mini 上，Codex 还能通过电脑操作检查自己的修改；按我的经验，这提高了完成的任务真正可用的概率。

Codex 应用的任务界面也比较克制。相比之下，我更新并打开 Claude 桌面应用时，遇到了登录不便、误导性的失败提示、CLI 会话没有同步以及添加项目困难。这些是我那次使用时遇到的问题，不能证明 Anthropic 没有人使用该应用。

在我看来，差异还体现在算力的使用上。我认为 Anthropic 更愿意使用额外 token 和子智能体，而 OpenAI 更强调效率和验证。这些是总体印象，不是受控比较，也不能代表两家公司的内部战略。

我提到一个基准测试：我看到的 GPT-5.5 结果消耗的 token 少于一些对比模型，同时得分更高。这样的比较取决于测试、模型配置和日期，不能证明某种方法总是更高效。运行修改后的应用并检查结果，也是另一种验证方式。

验证依赖运行环境。我尝试配置 Claude Code 的云环境，最后放弃了；如果智能体无法运行项目，检查工作就更困难。按我的体验，Codex 强调利用现有本地环境，包括远程控制机器；云端配置也是一种选择，具体功能可能变化。

Cursor 的云端方案是第三种选择。我使用它的浏览器界面，看重云端智能体能运行图形化 Linux 环境、启动应用，并通过电脑操作检查修改。在示例中，智能体运行 T3 Code 的浏览器版本来测试自己的工作。

当我在手机上、没有准备好可远程访问的机器，或者多个任务同时需要电脑操作时，这很有用。本地电脑可能关机、断网或正被占用。云环境仍需要针对项目配置，能启动并不保证结果正确。

我也喜欢团队协作流程：有人可以在 Slack 中提及 Cursor 机器人并描述产品问题，随后在线程里收到展示修复的视频。我的简化理解是：Codex 重视当下的本地流程，Claude Code 强调更强模型可能做到的事，Cursor 则投入云端任务委派。

我很在意工具开发者是否真的使用和测试客户获得的体验。我认为 OpenAI 和 Cursor 在内部大量使用自己的产品，而我对 Claude 桌面体验的信心较低。我还推测内部与公开模型和配置可能存在差异，但在这里无法证实这些说法。

让我担忧的一个例子是：Claude 桌面应用审查我的个人网站时，把关于恶意软件的系统提醒当作可能的提示注入。我觉得这个回答很奇怪，但它不能证明问题为何发生，也不能证明公司内部使用什么配置。

集成是另一个实际差异。Julius 和我开发的 T3 Code 使用了开源 Codex CLI 中的 Codex app server。我很看重其他界面可以利用这一组件，虽然我也希望 Codex 应用本身能开源。

我们尝试将 Cursor 加入 T3 Code 时，发现它的 CLI 和智能体协议集成落后于其他地方可用的模型：列表是写死的，缺少较新的选项。我们与团队沟通后解决了问题，Cursor 也发布了 agents SDK。我的判断是，各家对第三方集成的重视程度不同。

最后，模型质量会影响整个产品的使用感受。在我自己的测试中，我更喜欢 OpenAI 模型的演进，并觉得较新的 Opus 版本在我的工作中有所退步。这是主观评价，不能推论某个模型系列对所有人都变好了或变差了。

比起单个提示词的比较，我更在意团队的方向、它解决的问题，以及工作流程是否能持续可靠。如果你主要使用编辑器侧边栏，可以试试较新的智能体界面和桌面应用，看看是否适合自己的工作。

我的个人推荐也反映了这些偏好：Claude Code 的体验可能更有吸引力、让人更有动力；Codex 适合我对安静界面和既有工程流程的偏好；Cursor 云端智能体则适合探索团队任务委派。这些只是评估的起点，不是给用户能力贴标签。

我还简短地批评了 Antigravity，并认为已经使用 Pi 的人可能不需要这份比较。归根结底，还是要亲自试用，也让工具适度影响你的工作方式。当我不再要求 Codex 的行为完全像 Claude Code 时，我反而更喜欢它。