用 Codex 还是 Claude Code?¶
原文(免费):用 Codex 还是 Claude Code? —— 建议先读原文,本页是我的笔记
一句话结论:任何 AI 工具 = 「模型」×「Agent 工程(Harness)」,两者乘积决定体验;选工具时先看谁握着模型、再看谁把上下文工程做得好,而不是看界面形态。
核心要点¶
- 一个公式看穿所有产品。Coding Agent、AI 做 PPT、网页聊天机器人,底层都是「LLM + Agent 工程实现」。任意一项短板都会拖垮整体。
- 研发成本不对称。训练前沿模型极其烧钱,全球玩得起的公司屈指可数;写 Agent 本质是普通软件工程,门槛低,所以 Agent 产品遍地都是。
- 握有模型的公司有结构性优势。原文的推论:模型厂商以成本价用自己的模型,竞品得先买它的 API 再跟它竞争。Cursor、Copilot 这类「套壳」产品因此处境尴尬,还被迫在 token 上做妥协(例如更激进的上下文压缩)。
- 三家前沿模型厂商各自都有 CLI / 桌面端:OpenAI(GPT → Codex CLI / 桌面端)、Anthropic(Claude → Claude Code / Claude Desktop)、Google(Gemini → Gemini CLI / Antigravity IDE)。
- 路线之争:Copilot 路线 vs Agent 路线。Copilot 是「人写、AI 猜下一步(Tab 补全)」;Cursor 开启「AI 写、人 review」的 Agent 路线并胜出。
- Claude Code 证明了「不需要 IDE」。终端里一个输入框 + 强模型 + 好的工程(系统提示词、工具链、上下文管理)就够了。之后 Codex CLI、Gemini CLI 跟进。
- 2026 年作者的判断变化:GPT 5.5 之后编程能力与 Claude 打平,作者把主力迁到 Codex 桌面端;高风险改动再让另一个 Agent 独立 review 或调 Claude 交叉检查——原文说这「往往能发现主 Agent 在原有上下文里遗漏的问题」。
- 桌面端把 CLI 藏起来,目标用户从开发者扩展到所有人(Cowork、computer use),但底层仍是同一套 Coding Agent + 模型。
- 教学选型和使用选型可以不同:作者日常用 Codex,但后续拆源码用 Claude Code,因为它是纯 CLI、工程结构清晰,适合当案例。
⚠️ 勘误/补充:原文写「Claude 最新是 Sonnet 4.6 和 Opus 4.7」「Opus 4.7 (1M context)」。截至本笔记(2026-10),本机 Claude Code 2.1.306 的
~/.claude/settings.json的modelSettings里配置的是claude-sonnet-5-5/claude-haiku-5-5,当前会话运行在claude-opus-5-5。模型版本号是本文最容易过时的部分,读的时候只需记住「Sonnet = 标准、Opus = 旗舰、Haiku = 轻量」这个分层。
📝 作者是怎么讲的¶
- 先立一条原理,再用它推结论。 开头不急着比较工具,先给出「AI 工具 = LLM + Agent 工程」,接着推出一个判断:握有模型的公司做 Agent,别人很难竞争过它。后面谈 Cursor 为什么处境尴尬、厂商为什么都去做 CLI,都是这条原理的推论。这样整篇是一条推理链,不是一张功能对比表。你写选型文档也可以这样:先写清约束(比如成本结构、谁握着关键资源),再让结论顺着约束推出来。
- 按时间线讲演进,每个阶段只回答「谁是主力」。 Copilot(人写,AI 补全)→ Cursor(AI 写,人 review)→ Claude Code(扔掉 IDE,回到终端)→ 大厂跟进。每一段只抓住「写代码的主力换成了谁」这一个变量,读者很容易记住。这个手法适合给团队讲一项技术的来龙去脉。
- 先演示再评价。 讲 Claude Code 那一段,先贴了一段终端里的真实交互(初始化 rust 项目、把 hello world 改成 hello rust),接着才解释为什么「回到黑漆漆的命令行」反而火了。读者先看到它有多简单,后面的论证就容易接受。
- 先说出读者的第一反应,再反驳它。 原文写「很多人第一反应是」回到命令行很落后,然后给出模型能力、受众匹配两条理由。把读者的疑虑先说出来再回答,比正面论证更有说服力。
- 观点带时间戳,并且公开修正。 先给出「2025 年最佳选择是 Claude Code」,再用「2026 年的变化」推翻自己,把迁移到 Codex 的三条理由(模型打平、产品体验、封号和价格)逐条列出。另外他明说:教程以后仍然拆 Claude Code 源码,因为它工程上简单。日常主力用什么、教学拿什么当案例,他分得很清楚。你写周报或复盘时可以学这一点:判断要写明在什么条件下成立,条件变了就明确改口。
- 结尾指向下一步的行动。 收尾不做总结,直接说「接下来两篇」把两个工具都装上,读者读完就知道下一步做什么。
回到主线¶
本章是全库主线的「地图」:既然 LLM 只是「按已有 token 预测下一个 token」的模型,那么同一个模型套在不同产品里效果不同,差异全部来自 Harness 如何组织上下文——系统提示词写什么、给哪些工具、什么时候压缩、要不要开子 Agent 独立 review。原文提到 Cursor「更激进的上下文压缩」导致「没搞清楚需求就开干」,正是「上下文工程决定质量」的反面例子;作者「新开 Agent 独立 review」则是用干净上下文换可靠性,对应后面的 Sub Agent 与 Fork Agent。
对照你的环境¶
- 你本来就是「双模型」工作流:主力 Claude Code(2.1.306),Codex(codex-cli 0.153.4)作为异源臂——
codex-review(后台单臂codex review)和codex-cross-review(Claude reviewer + Codex 并行、交叉裁决)两个 skill 就是原文「调 Claude 交叉检查」的工程化版本,只是方向反过来。 - 原文的论点「同一上下文里的主 Agent 会遗漏问题」,在你的
~/.claude/agents/codex-review.md(隔离上下文的 Codex 子 agent)里已经被落实成机制:审查者看不到写代码时的推理过程,只看 diff。 - 你的
~/.claude/settings.json用CLAUDE_CODE_USE_VERTEX走 Google Cloud 渠道调 Claude——这正好印证「模型层与 Harness 层可分离」:Claude Code 这层 Harness 不变,模型供给方换成了 Vertex。
自测题¶
- 为什么原文认为「掌握大模型的公司,真想做某领域 Agent 时没人竞争得过」?用成本结构解释。
- Copilot 路线和 Agent 路线的核心区别是什么?Claude Code 在这两条路线中属于哪一条,它和 Cursor 的差别又在哪?
- 你用
codex-cross-review让 Codex 审 Claude 写的代码。从「上下文」的角度,说明它为什么比在同一个会话里让 Claude「再检查一遍」更容易发现问题。
参考答案
- 模型厂商用自家模型是成本价,竞品必须按市场价买 API 再加上自己的利润;同等工程水平下,厂商的单位成本更低、还能针对自家产品调模型。竞品为了省钱往往还得在上下文上做妥协,进一步拉低质量。
- Copilot 路线是人主导、AI 补全下一段;Agent 路线是 AI 主导写代码、人做 reviewer。Claude Code 属于 Agent 路线,和 Cursor 的区别只是形态:Cursor 把对话框放在 IDE 里,Claude Code 放在终端里,而且背后是自家模型。
- 同一会话里的「再检查」,模型读到的上下文里已经有它自己的推理和结论,下一个 token 的预测会被这些内容带偏,倾向于确认自己。异源 review 的上下文里只有 diff 和审查指令,没有原作者的思路;模型也换了一家,偏差不同,所以遗漏更容易暴露。