上两篇分别介绍了 Codex 和 Cursor 的安装和使用，最近试了一下 Cursor 和 Codex，主要是想看看它们在真实开发任务里的差异。
先声明，这不是一篇严格评测，也没有做完整 benchmark。
我的方式比较简单，在应用层面做了几个测试：准备两个空目录，给它们同样的任务，看它们怎么理解、怎么执行、最后产出的东西能不能直接用。
测评数据
CursorBench v3.1 里，Cursor 自家的 Composer 2.5 得分是 63.2%。Opus 4.7 在最高设置下是 64.8%，默认 xhigh 是 61.6%。GPT-5.5 默认成绩是 59.2%（数据来源于网络）
这次我用的模型模式分别是：
- Cursor：Composer 2.5 Fast
- Codex：GPT-5.5，高推理
测试环境：
- Windows 11 64 位
- Cursor 目录：
D:\Project\PythonProject\test_cursor - Codex 目录：
D:\Project\PythonProject\test_codex
先做几个简单任务
一开始我没有直接上复杂需求，而是先问它们当前在哪个目录下。
然后让它们在当前目录创建一个 a.txt。
这类任务本身没什么难度，主要是看它们能不能正确理解当前工作目录，以及是不是真的执行了操作，而不是只在聊天框里回答一句“已创建”。
后面又试了一个稍微复杂点的文件任务：创建三层递归目录，a、b、c 里面各放一个 readme 文件，并写入 1-9 乘法口诀表。
这种任务更能看出 agent 的执行习惯：它是直接动文件，还是先解释；是一次做完，还是需要来回补。
需求分析：微信抽奖小程序
接着我给了一个偏真实的业务题：
某上市企业想做一个微信抽奖小程序，支持 2000 家门店使用。订单金额满 399 可抽奖一次，同一订单只能抽奖一次。每个门店都有不同二维码，每个门店实体奖品独立设置。请设计 MVP，只做分析，不写代码，列出功能列表。
Cursor 的输出更像一份已经整理过的 PRD。它把项目背景、角色、用户端、门店端、总部后台、核心业务规则、数据对接、MVP 闭环都拆开了，还给了 P0、P1、P2 优先级。
这点挺适合需求评审。拿去继续补细节，基本能接着用。
但它的问题也比较明显：格式感很强，像是直接生成了一份标准文档。内容完整是完整，不过个人读起来会觉得稍微“端”了一点。
Codex 的输出更像一个人在解释方案。它没有 Cursor 那么强的表格感，但业务链路说得比较顺：总部创建活动、导入门店、生成二维码、用户扫码、提交订单、抽奖、中奖后门店核销。
如果只看可读性，我会更愿意读 Codex 的版本。
如果要直接拿去做评审材料，Cursor 的版本更省事。
注：输出结果有点多，这里没有做展示，如果感兴趣，可后台私信我，把完整结果私发给你
数据表设计
下一步我让它们基于上面的 MVP 设计 MySQL 8.0 数据表，并把内容写到文件里。
Cursor 生成的文件结构是：
test_cursor/
├── docs/
│ └── lottery-mvp.md
└── database/
└── mysql8/
├── README.md
└── schema.sql
它设计了 15 张表，除了活动、门店、奖品、用户、抽奖记录这些核心表，还补了订单同步日志、操作日志、风控黑名单等内容。
这个结果比较像企业项目里的交付物。目录分得清楚，文档和 SQL 也分开了。
Codex 生成的是：
lottery_mvp_design/
├── mvp.md
└── mysql_schema.sql
它设计了 12 张表，覆盖了核心流程：门店、后台账号、活动、二维码、奖品、微信用户、订单、抽奖记录、核销、风控事件、操作日志。
Codex 的方案更轻一点，没那么“工程化”，但对于 MVP 来说也够用。
这一轮我的感觉是：Cursor 更像在帮你搭一个正式项目目录；Codex 更像先把主要东西落下来，结构不复杂，但能看懂、能继续改。
注：输出结果有点多，这里没有做展示，如果感兴趣，可后台私信我，把完整结果私发给你
非功能性需求和架构选型
再然后我让它们从可扩展性、性能、可用性、可靠性、安全性、可维护性、可部署性几个方面设计架构。
Cursor 的判断很明确：MVP 阶段先用模块化单体，不要一上来拆微服务。
它还给了一些比较具体的判断，比如：
- 2000 家门店不需要一开始就分库分表
- 抽奖系统里可靠性比性能更重要
- 一单一抽要靠数据库唯一键兜底
- 奖品库存不能只靠代码判断
- 后续是否拆微服务，要看业务量和系统复杂度
Codex 的回答也推荐模块化单体、MySQL、Redis 这一套，但它写得更像分析文章。每个非功能性点都解释了一遍，语气更平一些。
这部分我反而觉得 Cursor 更有用。因为架构设计里，我更需要明确判断，而不是每个方向都展开解释。
注：输出结果有点多，这里没有做展示，如果感兴趣，可后台私信我，把完整结果私发给你
让它们互相评价
最后，“电子逗蛐蛐”环节，
问了它们怎么看待对方，并且专门说了“不想听乐观的”。
Cursor 评价 Codex 时，
- 关注点不在“能不能写代码”，而在终端 agent、沙箱、无头执行、JSON 事件流、CI 自动修复这些方向。
- 它的意思大概是：Codex 真正值得看的地方，是能不能变成一种可编排、可审计、可限制权限的工程基础设施。
- 但它也提到几个风险：自动修 CI 这类能力还没被充分验证，绑定 OpenAI 生态会带来成本和供应商锁定，产品路线也可能变化。
Codex 评价 Cursor 时，
- 关注点放在 IDE 和代码上下文上。
- 它认为 Cursor 最大的价值不是聊天，也不是生成代码，而是它离文件、光标、diff、报错、终端都很近。也就是说，Cursor 抓住的是开发者真正工作的现场。
- 不过 Codex 也说得比较克制：Cursor 现在的优势更多是产品体验优势，不一定是长期技术壁垒。后面如果 VS Code、JetBrains、GitHub、OpenAI、Anthropic 都往这个方向做，Cursor 还得继续把上下文、权限、安全、团队协作这些东西做深。
这一段我觉得挺有意思。它们评价对方时，刚好说出了各自的定位：
**Cursor 更像 IDE 里的 AI 开发环境。 **
Codex 更像终端里的 coding agent。
Token 消耗
Cursor：
Codex：
这里不能下结论谁消耗的多，谁消耗的少。因为两边模型、推理强度、输出长度都不一样，直接比 token 消耗量不太公平，这里仅做参考，当一乐看就好了。
总结
这次用下来，我的感觉是：
Cursor 更适合放在日常编码环境里用。它的强项是离项目近，适合改文件、补文档、做需求拆解、生成比较正式的工程化结果。尤其是 PRD、表设计、架构说明这种任务，它很容易给出一份“像交付物”的东西。
Codex 更像一个终端里的 agent。它的表达更自然，分析也更像人在说话。它的价值不一定体现在单次回答有多漂亮，而是能不能进入真实工程流程里：读文件、改文件、跑命令、看结果，再继续调整。
如果只是写一份文档，Cursor 可能更快给出规整结果。
如果是围绕命令行、自动化、CI、批量修改这些场景，Codex 的方向更值得关注。
对我来说，短期内 Cursor 更像一个顺手工具；Codex 更像一个还在成型的工程 agent。
一个更适合日常写代码，一个更适合观察它未来能不能进入更自动化的开发流程。
本文由 楸木 原创，转载请注明出处。