过去一段时间，我一直在用 Claude Code 做日常开发。

它有两个很明显的优点：一是上手快，二是终端里的使用方式很符合程序员习惯。提需求、看改动、继续追问，整个流程比传统聊天框更接近真实开发。

所以很长一段时间里，我对 Claude Code 的评价都不错。
它不是那种只能“看看热闹”的 AI 工具，而是真的能用起来。

但最近，我开始越来越多地把主力切到 Codex。

原因不是谁突然“碾压”了谁，也不是单看参数得出的结论。更真实的原因是：当 AI 开始真正进入开发流程之后，我在意的东西变了。

我不再只看它会不会生成一段代码，而是更在意这些问题：

• 它能不能看懂一个真实项目
• 它改代码时稳不稳
• 它能不能处理多文件、多模块的修改
• 它是不是适合长期作为主力工具

也是在这些维度上，我开始明显感觉到：Codex 更像一个面向工程流的工具。

AI Coding 的关键，不只是“会写代码”

刚开始用 AI Coding 工具时，大家最容易关注的是：

• 会不会写 React
• 会不会写 Node.js
• 一次能生成多少代码
• 回答看起来聪不聪明

但用久了之后会发现，这些都不是最关键的。

真正重要的是：
它到底能不能帮你把真实项目往前推进。

因为真实开发不是从零写一个 demo，而是面对：

• 已经存在的仓库
• 不统一的历史代码
• 多个文件之间的依赖关系
• 改一处可能影响多处的复杂逻辑

这时候，你需要的不是“临时回答一个问题”的 AI，
而是一个能进入项目语境、理解上下文、尽量稳定修改代码的工具。

这也是我越来越看重 Codex 的原因。

为什么我开始更偏向 Codex

我现在最明显的感受，是 Codex 更像是在“读仓库”，而不是“回答问题”。

这两者差别很大。

“回答问题”式的工具，适合快速生成、快速试验。
“读仓库”式的工具，更适合真实开发。

比如一个实际需求，往往不是只改一个文件，而是会牵动：

• 页面组件
• 状态管理
• API 层
• 类型定义
• 构建或配置逻辑

这时候，一个工具能不能在多文件上下文里稳定工作，就很关键。

我的实际体验是，Codex 在这类任务里更容易形成连续的工作过程。
不是回你一段代码就结束了，而是更像在参与一段真正的开发流程。

另外一点是，它在“改已有代码”这件事上，更符合我的预期。

因为生成新代码不难，难的是在现有系统上做修改。
有些 AI 工具第一次看很惊艳，但真放进项目里，会出现这些问题：

• 改动表面合理，实际上破坏原逻辑
• 修一个问题，又引入新的问题
• 过度重写，增加 review 成本

相比之下，我现在会更信任 Codex 一些。
不是说它不会出错，而是它更容易给出“像在认真修改现有项目”的结果。

那 Claude Code 还有没有价值？

当然有。

而且我不觉得这件事应该写成“谁赢谁输”。

在我看来，它们只是更适合不同场景。

Claude Code 依然适合：

• 快速试验一个想法
• 处理轻量项目
• 更灵活地尝试不同模型或组合方案
• 作为备选工具做交叉验证

所以我现在不是完全不用 Claude Code 了。
更准确地说，是它从“主力”慢慢变成了“仍然值得保留的工具”。

我的结论

我现在的判断很简单：

Claude Code 依然是个好工具。
对于个人开发者、轻量项目、快速试验，它仍然有价值。

但如果你已经开始认真把 AI 用进真实开发里，尤其是越来越在意：

• 仓库理解能力
• 多文件修改能力
• 改代码的稳定性
• 持续协作体验

那 Codex 更值得你认真投入。

未来 AI Coding 工具真正竞争的，未必只是模型能力。
更重要的，是谁能更稳定地融入开发者每天真实的工程流程。

谁能进入工作流，谁才更可能成为主力。

而对我来说，Codex 现在越来越像那个主力。