本周,一位常年写Ruby on Rails的开发者做了个小实验:把AI编程主力从Claude Code换成Codex,一连用了一周,记下十条零散印象。最扎眼的一条不是效率,而是事故——一次rebase操作,Codex把分支目标搞乱,硬生生冲出一个4000多行改动的PR,只能手动纠偏。这条印象单独看是个bug,放进这几年Claude Code和Codex的持续缠斗里看,才更有意思。

十条印象,压成几件事

调试时,他手还是先摸向Claude——不是因为更强,是因为熟。工具用得越紧急,越不敢用陌生的。

Codex写的Ruby注释更少,他喜欢这点。风格上,Claude像结对编程的同事,会主动多说几句;Codex更像《星际迷航》里的Data,冷静、精确、不多话。

速度上,Codex改动更快,但跑测试、走review、补漏这些收尾环节反而拖得更久——算总账,时间没省。架构上,Codex更克制;Claude喜欢多造抽象、类型签名、概念分层,东西写得更复杂,但也确实处理了更多边界情况。

接Jira时,Codex在浏览器登录和CLI之间来回跳,体验割裂;Claude更愿意顺着此前会话的路子,把事按他要的方式办成。MCP授权上倒是反过来:Codex每次都用命令行拉起正确的认证窗口,Claude有时想自动执行,反而卡住。

作者自己说,这只是一周的体感,周末会做完整分析。问题是,这种"完整"到底有多少含金量。

这周的手感,是不是走势

同一位作者此前做过一次更大规模的复盘:两个月内951次交互式会话,覆盖Claude、Codex、Cursor、Amp,外加705次自动化实现和审查运行。结果是Claude在大多数实现类对比里胜出,Codex则在代码审查环节挑出了更多有效问题。

这和本周的印象对得上——"Claude代码更复杂但处理了更多边界情况",不是这周瞎猜出来的手感,是延续了此前的量化结论。另一位开发者Dat Tran也在LinkedIn上说,自己最近同样更多用Codex,理由是它在一次性修复和较大任务上表现更好。两个独立观察指向同一个方向:Codex在有界任务上确实有一手,不只是个人偏好。

孙子说"多算胜,少算不胜"。一周十条印象是"少算",951次会话加705次自动化运行才够格叫"多算"。碎片化的体感能提示方向,但真要下选型判断,还是得看谁攒了更大的样本。

简洁与完备,是两种赌注

Codex更克制的架构,和Claude爱造抽象、类型签名,本质是两种风险赌注。

  • 结论.临时脚本、单人维护、任务边界清楚,选Codex式的简洁——改得少,出错面也小。长期核心模块、团队共同维护,Claude式的"过度设计"未必是坏事,前提是团队接得住那套抽象。

Claude的毛病不是复杂,是"没人问就自己往前冲"——你让它改一个方法,它顺手把类型系统也重构了。Codex的毛病是反过来:停在第一个"看起来做完了"的信号上,边界情况留给你自己发现。哪种毛病更贵,取决于代码库谁在维护、维护多久。

Jira卡壳,不是环境问题

作者接Jira时来回横跳的糟糕体验,大概率不是他一个人的配置问题。社区里对官方Atlassian MCP的抱怨集中在一点:token和上下文消耗过大,不少开发者已经转向更聚焦的Jira skill、CLI工具或直接调REST接口,绕开官方MCP实现。

  • 风险.如果团队还在指望官方MCP"开箱即用"接入Jira、Sentry这类系统,大概率要先踩一遍上下文爆炸的坑,再回头找CLI或REST的替代路径。

网上还流传着一份用历史PR重放做的基准测试,拿GPT-5.3 Codex和Opus 4.6在用Phlex、Stimulus的Rails代码库上打分。这份测试和本文作者实际用的版本未必一致,拿它直接佐证或反驳这十条印象,是把不同信息源的具体数字张冠李戴——这也是这类碎片化评测最容易踩的坑。

改动快一步,不等于交付快一步

Claude主动替你想、直接越界去做;Codex只做被要求的事,停在第一个可能做完的信号上。调试、探索性的活儿,前者更省心;边界清楚的批量任务,后者更不添乱。选哪个,别看这一周的手感,看你的任务到底属于哪一类。