我现在把 Claude Code 用在除了 coding 之外的几乎所有事上

2026 年 4 月 3 日，我说过，30 天后我会回来，诚实地讲清楚：取消 Claude Max 之后，到底发生了什么。

现在我提前 11 天回来了。

不是因为我没耐心，而是因为模式已经很明显了。如果还硬等到 5 月 2 日再说，更多只是戏剧效果。

这个结论一开始听起来有点别扭。一个叫 Claude Code 的工具，现在反而成了我用来做几乎所有事、除了写 code 之外的那个工具。

短版本是这样：

xHigh thinking 的 GPT-5.4 Codex，坐上了 coding 的那把椅子。
xHigh 的 Opus 4.7 Claude Code，拿走了我桌上剩下的所有位置。
“便宜版 Codex 就够了” 这个故事，在真实 limits 出现的那一刻就破了。

如果要压缩成一句最干净的 thesis，大概就是：

所有跟 code 相关的事，用 xHigh 的 Codex-GPT-5.4。其他所有事，用 xHigh 的 Claude Code with Opus 4.7。

这条分界线，比 19 天前的我预想的还要更清楚。

而且这个答案，比我原本想的更贵，也更能暴露我工作流里的心理依赖。

最先出问题的，不是 code 质量

我写那篇取消订阅的文章时，故事看起来很简单：

Claude Max：每月 200 美元
Codex / ChatGPT：每月 20 到 25 美元
execution quality 的差距正在迅速缩小
OpenAI 的 reliability 看起来更强

这看起来像一次很容易的降级。

但实际并不是。

最先崩掉的，不是 architecture，不是 plan quality，也不是 execution discipline。

最先崩掉的是 limits 这套叙事。

我真实的时间线更像这样：

Apr 6： 我开了两个 ChatGPT Business seat，月付，每个 25 美元。
Apr 6： 我那天就已经开始按 workaround 的思路在想了。要维持差不多原来的 coding pace，我怀疑自己可能需要大约三个能跑 Codex 的 account。
Apr 10： 用这个 setup 活了几天之后，我已经有足够的证据把话说出来：三个便宜 account 也还是复刻不了 Claude Max 状态最好时给我的东西。
Apr 12： 我买了 每月 100 美元的 ChatGPT Pro，因为我越是把 Codex 用在纯 coding 上，就越想要更多 high 和 xHigh reasoning 的 GPT-5.4，而不是更少。

这就是对 4 月 3 日那篇文章的第一条诚实修正。

实际发生的并不是“200 美元的 Claude Max 被 20 美元的 Codex 替代了”。

更接近下面这样：

“我已经不再需要以前那个 Anthropic plan 了。”
“但我确实需要比便宜 tier 更多的 Codex capacity。”
“真正该比较的，是在真实 limits 下的 workflow quality，而不是 benchmark 截图。”

我现在的判断是，OpenAI 很可能是在为了 market share 而对 limits 采取激进策略。这只是推断，不是内部消息。如果这个判断成立，那么这个窗口未必会一直开着。

所以，如果你把整个决策都建立在今天这套 20 美元 economics 上，至少也要承认：眼下的 pricing environment 可能是战术性的，而不是稳定状态。

Codex 坐上了 coding 的那把椅子

我学到的最大一件事是，xHigh thinking 的 GPT-5.4，确实很像一个 coding specialist。

不是那种很有魅力的 specialist。

也不是很温暖的 specialist。

更不是那种想跟你做朋友的类型。

但它确实像 specialist。

Codex 身上有一种我原本没想到自己会喜欢的克制感。它像一个不说废话、做事谨慎、步骤清楚、不会对着你表演 personality 的工程师。

在长时间工作日里，这一点比我预想的重要得多。

对我来说，最明显的时刻发生在 4 月 17 日。我把一个已经达成一致的 plan 交给 xHigh 的 Codex-GPT-5.4，然后放手让它去做。它在一个 session 里连续工作了 30 到 45 分钟，非常贴着 plan 走，写并执行 unit tests、integration tests 和 browser tests，而且都是在 local 上完成的，我不需要全程盯着它。

我还没有遇到过另一个工具，能以同样的稳定度替我做到这一点。

这改变了我对 Codex 的判断。它已经不只是“做小任务够用”了。只要 plan 足够清楚，它真的能做长时间、纪律性很强的 execution。

对于纯 coding 工作，我现在几乎总是先用 Codex：

architecture
implementation
debugging
eval design
test framing
pipeline cleanup
production-minded 的 product logic

4 月最好的例子就是 Prova。

Prova 里最有价值的工作，大多数都不 glamorous。不是那种“看这个 model 多聪明”的事，而是这些：

评估 composable sprints
收紧 onboarding logic
找出 roadmap generation 和 assigned sprint state 之间的矛盾
根据真实用户 row 和真实 production behavior 改进产品

事实证明，这类工作非常适合 Codex。

当工作是下面这种时，它会显得 competent、thorough，而且比我预想得更 sharp：

找出 contradiction
隔离 logic bug
把 correctness 和 RFC territory 分开
推荐一个最小但又站得住脚的下一步

其中一个最清楚的例子，来自 Prova 里一条 builder-intent 用户的 production row。

当时系统：

把一个 builder-intent user 标成了 marketing_vp
给他分配了 table-stakes-diagnostic
生成了一条从更后面开始的 roadmap
在 onboarding 刚结束后就显示了 Context Check card

这一段真正有价值的地方，不只是 diagnosis 本身，而是 cross-review loop。

Opus 4.7 带我看到了前三个问题：

一个 track-calculation bug
一个 timing bug
一个 builder-opener / RFC question

然后 GPT-5.4 把分析继续往前推，抓到了 Opus 漏掉的那条更尖锐的矛盾：

assigned first sprint 和 generated roadmap，已经在对同一个 user 说两种不同的真相

这很关键。它把讨论从“我们要不要现在就 ship Builder RFC？”变成了“先修 live contradiction，再回来看 RFC。”

它给我的感觉，不像是一个试图让我惊艳的 model。更像是一个 senior SWE 在说：先把眼前这个 contradiction 修掉，再谈产品理论。

这种模式在这个月里重复得足够多，以至于我已经不再把 Codex 看成“更便宜的替代品”。我现在把它当成 我的 primary coding instrument。

Claude Code 拿走了剩下的所有位置

如果故事停在这里，答案会很简单：切去 Codex，然后继续往前。

但事情并没有这样发展。

Opus 4.7 版的 Claude Code，在那些 output 依赖 taste，或者 loop 很长、很迭代、很吃 context 的工作上，依然更强。

也正是在这里，这篇文章的标题不再显得矛盾，反而开始显得准确。以前每次要写 code 时我都会 instinctively 去拿的 Claude Code，现在变成了我在要做任何 不是写 code 的事时去拿的工具。

我说的“其他所有事”包括：

必须听起来像我写的 writing
反复打磨 structure 和 rhythm
naming 和 positioning
tagline 和 brand phrasing
blog cover image 的 prompt
logo 和 identity 的探索
当工作需要 visual judgment、而不仅仅是 functional UI 时更强的 /frontend-design
跨多个 session 慢慢搭出 point of view 的长 research thread

以我过去 19 天的实际体验来看，这一点反复成立。

这种差距在有 feedback loop 的时候尤其明显。

Claude 和 Codex 都能读历史文章、查看过去的 prompt，也都能把已有工作当作 reference。但当我在做 多轮 refinement，并且每一轮之后都给 feedback 时，Claude 仍然更稳定地理解我想去的方向。

这适用于 writing。

也适用于 image prompting。

同样适用于 naming。

最明显的产品例子就是 Prova。这个名字不是我用 Codex 想出来的。那种工作我需要 Opus。很多 brand language 的探索也是一样。GPT-5.4 会给我 solid、competent 的答案。Opus 会给我更强的 creative range。

同样的模式也出现在 site design 上。

在 Superpowers 里，当工作是 design-led 而不是 engineering-led 时，/frontend-design 这个 workflow 对我来说仍然是 Opus 比 GPT-5.4 更好用。Codex 会给我一个 functional 的结果。Claude 更常给我一个我真的愿意带着自豪感去 ship 的结果。

所以如果问题是：

“Codex 把 Claude 在所有事情上都替代掉了吗？”

没有。

它替代的是 coding 的那把椅子。不是剩下的一切。

这个区别很重要。

熟悉感是真的，戒断感也是真的

我已经用了大约 13 个月 的 Claude Code。

这么长的时间，改变的不只是偏好列表，还会改变你工作时的身体感。

当我更激进地切向 Codex 时，我确实感觉到了一种类似戒断的东西。

不是因为 Codex 不好。

而是因为它不一样。

摩擦点都很小，但持续存在：

某些 permission confirmation
某些时刻它像是多问了一句
回答语气偏 sterile
loop 里少了那种熟悉的 Claude “voice”

这些都不是客观缺陷。

它们只是 workflow difference。

而熟悉感会改变你对这些差异的感受方式。

我不想假装自己是以一个完全理性的经济学家姿态走过这段转换的。

并不是。

有一段时间，我发现自己会把工作再丢给 Claude 跑一遍，只是为了多一层 safety-net review。不是因为我真的需要 second opinion，而是那种吸引力比我自己“我要干净地切换过去”的叙事更强。

这件事教会我，真正的 dependency 不只是 Claude 的 raw capability。它还包括一种 安全感：loop 里有另一个我以不同方式信任的 intelligent system。

这也是为什么，对我来说，最终答案从一开始就不可能是“永远只选一个”。

workflow 的心理结构同样重要。

Codex 也有它自己的 failure mode

这段时间并不是一长串 Codex 胜利。

我也碰到了真实的问题。

第一个让我觉得“这像是 Codex 特有问题”的时刻发生在 4 月 14 日。在两个 terminal session 里，我都撞上了这个错误：

{
  "error": {
    "message": "Unknown parameter: 'prompt_cache_retention'.",
    "type": "invalid_request_error",
    "param": "prompt_cache_retention",
    "code": "unknown_parameter"
  }
}

这种事很重要，因为它打断的不是 reasoning layer 上的信任，而是 harness layer 上的信任。

我还发现，Codex 在 deploy 或者碰 production 相关事情时，对模型被允许做什么似乎更严格，哪怕同一个 session 里之前已经给过 approval。

有时候这很好。

有时候也挺烦。

但它显然是实际用户体验的一部分。

有一个我确实更喜欢 Codex 的小细节：它能在不打断主流程的情况下查看 status 和 limits。不用等当前工作结束就能跑 /status，这听起来很小，但 19 天下来，这种 ergonomics 的细小差异会不断累积。

这就是我说两套工具不只是 output quality 不同的意思。它们连 harness 的手感 都不一样。

reliability 依然重要，而 4 月并没有帮 Claude 加分

我一开始之所以觉得自己能放心切换，其中一个原因就是 reliability。

我在 3 月 31 日那篇 follow-up 里已经写过 Anthropic 和 OpenAI 的 90 天状态差异。大图景现在依然重要：

Anthropic 90 天 uptime 状态图，显示 claude.ai、platform、API 和 Claude Code 都出现过 partial outage

OpenAI 90 天系统状态图，显示 API 99.99% uptime、ChatGPT 99.91% uptime

然后 4 月又补上了一个现实提醒。

4 月 15 日，Claude 在 Claude.ai、API 和 Claude Code 上再次出现 elevated errors。login 受到了影响。API 先恢复。已经登录的 Claude Code 用户还能继续工作，但 login 本身有一段时间是坏的。

这不会抹掉 Claude 的强项。

但它会进一步强化一个很实际的结论：不要把整个 workflow 都押在单一 vendor 身上。

这依然是整个实验里最 durable 的教训之一：

双持，不只是奢侈，而是 operational resilience。

当其中一家 provider 有一个糟糕的下午时，你仍然可以继续 ship。

Opus 4.7 让这个模式更清楚了，而不是把它翻过来

Claude Opus 4.7 是在 4 月 16 日发布的。 如果不认真跑一轮就直接下 honest verdict，那是不公平的。

所以我几乎立刻把它放进了一个真实的 Prova coding diagnostic 场景里。

Opus 4.7 给了我一个相当 solid 的 first pass。它识别出了 track bug、时机不对的 Context Check card，以及更广义的 Builder-opener 问题。

然后我把这份 diagnosis 交给 GPT-5.4 做 critique pass。不是 blind second opinion，而是当成一个 reviewer 去读 Opus 的书面分析。GPT-5.4 抓到了 Opus 漏掉的、更尖锐的 contradiction：产品已经分配了一个 first sprint，却又生成了一条从别处开始的 roadmap。这不只是 Builder-fit 问题，而是一个真实存在的 correctness 问题。

之后我把修订后的 diagnosis 再推回给 Opus，它也收敛了。

真正让我意外的是另一个方向。

4 月 19 日，我注意到一件我原本没想到的事：在 更简单的任务 上，比如短 code review pass，或者针对一个小改动的 focused execution，xHigh 的 Opus 4.7 明显比 xHigh 的 Codex-GPT-5.4 更慢。我原本预期正好相反。

这个细节又把我的模式重新锚定住了。

Opus 现在依然明确胜出的地方，是上面提到的那些 taste-heavy、iterative、long-context 工作。Codex 明确胜出的地方，是深度 coding diagnosis，以及我以前会伸手去找 Claude 的那些日常快速 coding turn。

所以诚实版本是这样的：

在更深一点的 code analysis 上，Opus 4.7 依然能给我一个不错的 first pass
但在 lighter coding turns 上，它目前感觉比同级 thinking 的 GPT-5.4 更慢
再加上 4 月 17 日那次 continuous execution 体验，这让 coding 的那把椅子进一步朝 Codex 倾斜，而不是回到接近平局

我最后到底落在了哪里

如果把 drama、pricing screenshot、outage screenshot 和 social-post framing 都去掉，那么 到 4 月 22 日为止，我的 working pattern 已经稳定成这样：

所有和 code 有关的事

我首先会去拿 xHigh thinking 的 Codex with GPT-5.4。

原因很简单：

它感觉像 specialist
它 methodical
它谨慎
它能同时处理好 architecture 和 execution
它能把一个 agreed plan 连同 unit、integration、browser tests 一起跑上 30 到 45 分钟
在 everyday coding turn 上，它现在比 xHigh 的 Opus 4.7 更快
在 deep coding work 上，我现在也更容易信任它

其他所有事

我首先会去拿 xHigh thinking 的 Claude Code with Opus 4.7。

现在这包括：

必须听起来像我自己的 writing
cover art 的 image prompt
naming、positioning 和 brand language
需要 visual judgment 的 /frontend-design
跨多次 session 慢慢搭出 point of view 的长 research thread
在把 plan 交给 Codex 之前先 review 我自己的想法
这篇 blog post

原因是：

它更能跟住我的 style
它更擅长处理 feedback-driven creative iteration
它在 brand taste 和 design taste 上更强
当任务需要的是 judgment 而不是 execution 时，它仍然是我最信任的 model

对重要的 coding plan

我仍然喜欢 cross-review loop：

先从一个模型那里拿到 plan
再让另一个模型 critique
然后从那里继续收紧

这个 workflow 仍然比把赌注压在单个 model 的第一版答案上更稳，无论那个 model 有多强。上面那个 builder-intent row 的例子，就是我还在继续用这套做法的原因。

对 pricing

我最后并没有落在一个简单的便宜替代方案上。

我落在这里：

不再想要以前那种 200 美元 Claude Max 的结构
我想要的是 更多 Codex capacity，而不是更少
我接受了 100 美元的 ChatGPT Pro 作为更现实的 coding plan 答案
对于所有不是 code 的事，我依然把 Claude 留在 loop 里

对 shipping

这次切换的全部意义，就是继续 ship。它不是 19 天什么都没有产出的工具 benchmarking。在同一个窗口里，Prova 的 Operator/Builder split 已经带着真正的 Builder execution lane 上线了，两篇 substantial blog post 也发出去了，而且我还跑完了一轮覆盖 12 个 locale 的 full translation pass。这个实验有没有拖慢我的 output？答案是没有。

如果你想要最压缩的版本，那就是：

我取消了 Claude Max，但并没有把 Claude Code 从我的工作里拿掉。我只是把 Claude Code 从 primary coding seat 上挪开，把整张桌子的其他位置交给了它。

这是我现在能给出的最真实总结。

所以：如果重来一次，我会不会做同样的决定？

会。

但现在我会换一种说法。

4 月 3 日那天，我的 framing 是：

“我取消了 Claude Max，现在在测试 Codex 能不能取代它。”

到了 4 月 22 日，更接近真实的 framing 其实是：

“我取消了 Claude Max，发现对现在的我来说，Codex 是更强的 coding specialist，而 Claude Code 则接管了我桌上其他所有工作——在那个位置上，它依然是我手里最好的工具。”

这个答案没有那么二元，它比简单的 social-post 版本更贵，但也更接近事实。

常见问题

Codex 真的在 coding 上取代了 Claude 吗？

对我来说，是的。在 pure coding work 上，xHigh thinking 的 Codex with GPT-5.4 已经成了默认位置。xHigh 的 Opus 4.7 在更深的 diagnosis 上依然能给我一个有用的 first pass，但对我来说，它已经不再是 primary coding seat，而且在更轻的 coding turn 上也更慢。

“便宜版 Codex” 这套说法站得住吗？

并不完全站得住。一旦我开始按真实工作量去用它，低 tier 的 economics 就不再能解释全部情况了。我转到更贵的 OpenAI plan，不是因为实验失败了，而是因为我需要更多 capacity。

你现在还需要 Claude 吗？

需要。如果你的工作里有 writing、design、naming、image prompting、长 research thread，或者任何强依赖 taste 和 judgment 的 loop，那么你仍然会需要 Claude。在我的 workflow 里，xHigh 的 Opus 4.7 已经成了所有非 code 工作的默认选择。

reliability 怎么看？

reliability gap 依然重要。4 月只是在强化这一点。答案不是恐慌，而是 backup coverage。

为什么提前 11 天发？

因为模式已经 settle 了。如果只是为了尊重原来标题里的数字而硬等到 5 月 2 日，那就是戏剧化。更诚实的做法，是把我现在真实在做的事直接说出来，然后继续往前。

那你今天会买哪个 plan？

如果你的工作主要是 coding，我会非常认真地先看 Codex / GPT-5.4。如果你的工作既有 coding，又有很多依赖 taste 的 creative work，那我不会想在没有 Claude 的情况下工作。而如果现在每月 100 美元超出预算，那么 20 美元的 Codex tier 对小一点的个人项目仍然能用——只是你要预期，在 sustained 的 multi-project 工作里，你会更快撞到 limits。至少就我自己而言，现在的答案已经不是 single-tool answer 了。

这就是 19 天后的诚实 update。

Codex 坐上了 coding 的那把椅子。

Claude Code 拿走了剩下所有位置。

也因此，一个字面上就叫 Claude Code 的工具，现在反而成了我处理 code 之外所有事情的工具。

而真正的 lesson，还是那句：workflow 比 fandom 更重要。

如果你这个月也做了类似的切换，我真的很想知道你最后落在了哪里。是某一个工具彻底赢了，还是你的分工也变得更清楚了？

祝好，
Chandler