天才般的新人和经验丰富的资深
一起使用Codex和Claude Code的感受
现在，“用AI编码”这句话已经不再特别了。
我在实际服务开发过程中也同时使用多个模型，其中Codex(gpt-5-codex high)和Claude Code(Opus)就像两位性格迥异的同事一样。
有趣的是，如果简单地将这两者比作“谁编码更好”，就会忽略本质。
这不是实力优劣的问题，而更接近于与开发者相似的性格差异。
Codex: 天才般的新人开发者
使用Codex时最令人印象深刻的是速度。
提出问题后，代码会毫不犹豫地立即出现。转换思路为结构的能力非常出色。
就像这样的感觉。
“这样解决不就行了吗？”
— 刚入职但头脑异常灵活的新人
特别是在以下情况下，Codex表现得非常强大。
- 想要快速将头脑中的想法转化为代码形式
- 需要创建原型、POC或实验性结构时
- 语言或框架的语法完整性很重要时
然而，从实际运行Rails服务的角度来看，Codex也有明显的不足之处。
例如，在编写迁移文件时，有时会不准确地理解up/down方法的意图以及Rails推荐的变更方式（例如：可逆迁移）。
此外，对于像Kamal这样的部署工具，有时会给出“知道存在但不了解背景”的回答。
这并不是因为Codex不足，
而更接近于对Rails的‘使用经验’仍然较短的印象。
Claude Code(Opus): 长期使用Rails的资深
另一方面，Claude Code(Opus)从一开始就有不同的感觉。
提出问题后，并不立即编写代码，而是先整理背景。
“在Rails中，这样进行是很自然的。”
这种说话方式本身就已经是资深的特征。
Claude Code的优势是明显的。
- 对整个Rails平台的理解
- 迁移 → 部署 → 运营之间的整体流程
- 选择“Rails期望的代码”而不是“可行的代码”
即使编写相同的迁移，
他们首先提出的不仅仅是能够运行的代码，而是可以撤销且易于团队维护的形式。
因此，Claude Code提供的代码可能不够华丽。
但对于实际运行服务的人来说，“哦，这是我在现场使用的方式”这样的感觉会浮现。
我认为这一点非常重要。
因为代码最终比起编写更需要运行的时间长得多。
我是这样使用这两种模型的
因此，我现在有意识地将这两种模型分开使用。
而不是提出相同问题并进行比较，而是分配角色并共同工作。
通常在开始开发时，我会这样设置。
打开Warp终端
创建两个面板，一个在左边，一个在右边。
- 左侧面板： Claude Code(Opus)
- 右侧面板： Codex(gpt-5-codex high)
左侧总是有Claude Code。
这里不会直接编写代码。
而是首先让Claude Code*规划*。
- 在Rails中，如何自然地实现此功能
- 模型、控制器、服务对象的边界在哪里
- 迁移应该按什么顺序进行安全
- 在考虑部署和运营时需要注意什么
在这个阶段，Claude Code几乎像技术设计审查员一样行动。
“在Rails中这样做很自然”这样的话会自然地说出来。
接下来，将相同计划交给右侧的Codex。
“看看这个计划中有没有遗漏的地方。”
“这里是否有可以更简化的部分？”
这时，Codex发挥着非常好的作用。
快速指出结构上的缺陷，或者大胆整理过于复杂的部分。
编写由Claude，审查由Codex
计划整理好后，实际代码再次由Claude Code编写。
原因很简单。
在Rails中，“持久的代码”比“能运行的代码”更重要。
虽然Claude Code编写的代码可能速度较慢，
- 考虑迁移的撤销
- 不损害Rails的惯例
- 以一种我以后再看也能理解的形式呈现
当代码基本完成时，
然后再使用Codex作为代码审查员。
- 这个逻辑，能更简单地实现吗？
- 在查询或循环处理中是否遗漏了什么？
- 是否存在难以测试的结构？
在这个阶段，Codex非常有能力。
就像眼明手快的新人毫无顾虑地向前辈提出问题一样。
同时使用两种AI的感受
这样使用后，我确信了一点。
比较Codex和Claude Code并没有太大意义。
重要的是将它们分配到什么角色。
- Codex擅长发散和审查
- Claude Code擅长积累和稳定
将这两者并排放在Warp的左右面板上，
即使在独自开发，也感觉就像团队中有着不同性格的开发者一样。
而我只是在其中做出决策的开发者。