我而家將 Claude Code 用喺除咗 coding 之外嘅幾乎所有嘢

2026 年 4 月 3 號，我講過自己會喺 30 日之後返嚟，老老實實講清楚：取消 Claude Max 之後，實際發生咗啲乜。

而家我提早咗 11 日返嚟。

唔係因為我心急，而係因為個 pattern 已經定晒型。如果仲要等到 5 月 2 號先講，基本上就只係做戲。

呢個結論一開始聽落去會有少少古怪。個名叫 Claude Code 嘅 tool，而家反而變成我用嚟做幾乎所有嘢、除咗寫 code 之外嗰個 tool。

短版係咁：

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 日前嘅我預期得更鮮明。

而且個答案，比我原先估計更貴，亦都更直接暴露咗我 workflow 入面嘅心理依賴。

最先出問題嘅，唔係 code quality

我寫取消訂閱嗰篇文嗰陣，成件事睇落幾簡單：

Claude Max：每月 200 美元
Codex / ChatGPT：每月 20-25 美元
execution quality 嘅差距正喺度好快咁收窄
OpenAI 嘅 reliability 睇落更穩

所以成件事好似一個好易做嘅 downgrade。

但實際唔係。

最先崩嘅，唔係 architecture、唔係 plan quality、亦都唔係 execution discipline。

最先崩嘅，係 limits 呢個故事。

我真實嘅 timeline 反而更似係咁：

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 去做 pure coding，就越係想要更多 high 同 xHigh reasoning 嘅 GPT-5.4，而唔係更少。

呢個就係對 4 月 3 號嗰篇文第一個誠實修正。

真實情況唔係「200 美元嘅 Claude Max 變成 20 美元嘅 Codex」。

反而更接近咁：

「我唔再需要以前嗰種 Anthropic plan。」
「但我仍然需要比平價 tier 更多嘅 Codex capacity。」
「真正要比嘅，係真實 limits 之下嘅 workflow quality，而唔係 benchmark screenshot。」

我而家嘅判斷係，OpenAI 好可能係為咗 market share，所以喺 limits 上採取咗比較進取嘅做法。呢個係推斷，唔係 insider knowledge。如果呢個判斷啱，咁呢個窗口未必會一直開住。

所以，如果你成個決定都建基喺今日 20 美元嘅 economics 上面，最少都要承認一點：而家呢個 pricing environment 可能係戰術性，而唔係長期穩定狀態。

Codex 攞咗 coding 嗰個位

我呢 19 日學到最大嘅一件事，就係 xHigh thinking 嘅 GPT-5.4，真係幾有 coding specialist 嘅感覺。

佢唔係有魅力嗰種 specialist。

亦都唔係好 warm 嗰種。

更加唔係會主動想同你做朋友嗰種。

但佢真係似 specialist。

Codex 有一種我原本估唔到自己會鍾意嘅乾淨利落感。佢俾我嘅感覺，就好似一個唔多廢話、做事小心、methodical、唔會對住你表演 personality 嘅 engineer。

喺長時間工作日入面，呢一點比我想像中更重要。

對我嚟講，最清楚嘅時刻發生喺 4 月 17 號。我將一份已經談妥嘅 plan 交畀 xHigh 嘅 Codex-GPT-5.4，跟住就放手俾佢做。佢喺一個 session 入面連續做咗 30 到 45 分鐘，一路貼住個 plan 去行，寫同跑 unit tests、integration tests 同 browser tests，而且全部喺 local 上完成，我唔需要全程坐喺旁邊睇住。

我仲未遇過第二個 tool，可以用咁樣嘅穩定度幫我做到呢件事。

呢件事改變咗我點睇 Codex。佢唔再只係「做細 task 都算夠用」咁簡單。只要個 plan 足夠清楚，佢係真係可以做長時間、好有紀律嘅 execution。

對 pure coding work 而言，我而家幾乎都係先揀 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 之間嘅矛盾
根據真實 user row 同真實 production behavior 去改善產品

結果證明，呢類工作同 Codex 好夾。

當工作係下面呢種時，佢會顯得 competent、thorough，而且比我估計中更 sharp：

搵出 contradiction
將 logic bug 抽離出嚟
將 correctness 同 RFC territory 分開
提出一個最細、但仍然站得住腳嘅下一步

其中一個最清楚嘅例子，嚟自 Prova 入面一條 builder-intent user 嘅 production row。

當時個 system：

將一個 builder-intent user 標成 marketing_vp
分配咗 table-stakes-diagnostic
產生咗一條喺 journey 後段先開始嘅 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 講緊兩套唔同真相

呢點好重要。佢令個討論由「Builder RFC 係咪要而家就 ship？」變成「先修 live contradiction，再返去講 RFC。」

嗰個感覺唔似一個 model 想 impress 我。反而似一個 senior SWE 同你講：先修好眼前嘅 contradiction，之後先傾 product theory。

呢個 pattern 今個月重複得夠多，以至我已經唔再將 Codex 視為「平啲嘅替代品」。我而家係將佢視為 我嘅 primary coding instrument。

Claude Code 攞走咗其餘所有位置

如果故事停喺度，答案就會好簡單：轉去 Codex，然後繼續行。

但事實並唔係咁。

Opus 4.7 嘅 Claude Code 喺嗰啲 output 高度依賴 taste，或者個 loop 好長、好 iterative、好 context-heavy 嘅工作上，依然更強。

就係由呢度開始，呢篇文個標題唔再顯得矛盾，反而顯得非常準確。以前一講到要寫 code，我就會本能咁打開 Claude Code；而家，Claude Code 變成咗我喺要做任何 唔係寫 code 嘅工作時最先伸手拎嘅 tool。

我講嘅「其他所有嘢」包括：

一定要聽落似我本人嘅 writing
反覆打磨 structure 同 rhythm
naming 同 positioning
tagline 同 brand phrasing
blog cover art 用嘅 image prompt
logo 同 identity 探索
需要 visual judgment、而唔止係 functional UI 嘅 /frontend-design
跨多個 session 慢慢砌出 point of view 嘅長 research thread

以我過去 19 日嘅經驗，呢點係反覆成立嘅。

有 feedback loop 嘅時候，差距會特別明顯。

Claude 同 Codex 都可以睇舊 post、翻舊 prompt、用既有工作做 reference。但當我喺做 多輪 refinement，而且每一輪之後都會再俾 feedback 嘅時候，Claude 仍然更穩定咁理解我真正想去嘅方向。

呢點適用喺 writing。

亦都適用喺 image prompting。

同樣都適用喺 naming。

最明顯嘅 product example 就係 Prova。我唔係用 Codex 想到呢個名。呢種工作我需要 Opus。好多 brand language exploration 都係一樣。GPT-5.4 會俾我 solid、competent 嘅答案；Opus 會俾我更強嘅 creative range。

同一個 pattern 喺 site design 上面都會出現。

喺 Superpowers 底下，當工作係 design-led 而唔係 engineering-led 嘅時候，/frontend-design 呢個 workflow 對我嚟講依然係 Opus 比 GPT-5.4 更好用。Codex 會俾我 functional 嘅結果。Claude 更常俾到我一個我真係想帶住自豪感去 ship 嘅結果。

所以如果問題係：

「Codex 係咪已經將 Claude 全面取代？」

唔係。

佢取代咗嘅，係 coding 嗰個位。唔係其餘全部。

呢個分別好重要。

熟悉感係真嘅，戒斷感都係真嘅

我用咗大約 13 個月 Claude Code。

用咁耐，改變嘅唔止係你嘅 preference list，仲會改變你做嘢時個身體感。

當我更積極咁轉向 Codex 嘅時候，我的確感受到一種近似戒斷嘅感覺。

唔係因為 Codex 差。

而係因為佢唔同。

啲 friction points 都好細，但係會一路存在：

某啲 permission confirmation
某啲時候會覺得佢多問咗一句
回應語氣比較 sterile
loop 入面冇咗嗰種熟悉嘅 Claude「聲線」

呢啲唔係客觀缺陷。

佢哋只係 workflow difference。

而熟悉感會改變你點樣感受呢啲差異。

我唔想扮到自己係用一個完全理性經濟學家嘅姿態跨過呢段過渡期。

其實唔係。

有一段時間，我發現自己會將工作再丟返去 Claude 跑一次，只係為咗多一重 safety-net review。唔係因為我真係需要 second opinion，而係因為嗰股吸引力比我自己「而家我要乾淨地切換」嘅故事更強。

呢件事教識我，真正嘅 dependency 並唔只係建立喺 Claude 嘅 raw capability 上面。佢仲包括一種 安全感：loop 入面有另一個我用另一種方式去 trust 嘅 intelligent system。

亦都因為咁，對我嚟講，最終答案一開始就唔可能係「揀一個用到永遠」。

workflow 嘅心理結構一樣咁重要。

Codex 都有佢自己嘅 failure mode

呢段時間並唔係一長串 Codex victory。

我都撞到真實問題。

第一個令我覺得「呢個真係似 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 相關事情時，對 model 可以做啲乜似乎更嚴格，就算同一個 session 入面之前已經俾過 approval 都係咁。

有時候呢樣係好事。

有時候就幾煩。

但無論點都好，呢啲都係真實 user experience 嘅一部分。

如果講一個我真心更鍾意 Codex 嘅小位，就係佢可以喺唔打斷 main flow 嘅情況下睇 status 同 limits。唔需要等手上嘅工作完咗先可以跑 /status，聽落係小事，但用足 19 日之後，呢啲 ergonomics 會慢慢累積成差距。

呢個就係我所講，兩個 tool 唔止喺 output quality 上有分別。佢哋連 harness 嘅手感 都唔同。

reliability 依然重要，而 4 月並無幫到 Claude 加分

我一開始之所以夠膽切換，其中一個原因就係 reliability。

我喺 3 月 31 號嗰篇 follow-up 入面已經寫過 Anthropic 同 OpenAI 嘅 90 日 status 差距。大圖景到而家仍然重要：

Anthropic 90 日 uptime 狀態圖，顯示 claude.ai、platform、API 同 Claude Code 都曾經出現 partial outage

OpenAI 90 日 system status 圖，顯示 API 99.99% uptime 同 ChatGPT 99.91% uptime

而之後 4 月又加多咗一次現實提醒。

4 月 15 號，Claude 喺 Claude.ai、API 同 Claude Code 再次出現 elevated errors。login 都受影響。API 先恢復。已經登入咗嘅 Claude Code user 仲可以繼續做嘢，但 login 本身有一段時間係壞咗。

呢樣唔會抹走 Claude 嘅優勢。

但佢會進一步加強一個好實際嘅理由：唔好將成個 workflow 押喺單一 vendor 身上。

呢一點仍然係整個 experiment 入面最 durable 嘅教訓之一：

dual-wielding 唔只係奢侈，而係 operational resilience。

當其中一間 provider 過咗一個爛下午，你仍然可以繼續 ship。

Opus 4.7 令呢個 pattern 更尖銳，唔係反轉咗佢

Claude Opus 4.7 喺 4 月 16 號推出。 如果我未認真跑過佢就直接寫 honest verdict，咁就唔公平。

所以我幾乎即刻就將佢放入一個真實嘅 Prova coding diagnostic 場景入面。

Opus 4.7 俾咗我一個幾 solid 嘅 first pass。佢認出咗 track bug、timing 唔啱嘅 Context Check card，同埋更大範圍嘅 Builder-opener 問題。

之後我將呢份 diagnosis 交畀 GPT-5.4 做 critique pass。唔係 blind second opinion，而係當成一個 reviewer 去讀 Opus 嘅書面分析。GPT-5.4 捉到咗 Opus 漏咗嗰條更尖銳嘅 contradiction：個 product 明明已經 assign 咗一個 first sprint，但生成出嚟嘅 roadmap 又係喺另一個地方開始。呢個唔止係 Builder-fit 問題，而係一個真實存在嘅 correctness 問題。

之後我再將修訂版 diagnosis 推返畀 Opus，佢亦都收斂咗。

真正令我意外嘅，反而係另一個方向。

4 月 19 號，我發現咗一件自己原本冇預到嘅事：喺 更簡單嘅 task 上，例如短嘅 code review pass，或者針對細改動嘅 focused execution，xHigh 嘅 Opus 4.7 會明顯慢過 xHigh 嘅 Codex-GPT-5.4。我本來以為情況會係相反。

呢個細節重新將我嘅 pattern 錨定咗。

Opus 仍然清楚勝出嘅地方，係上面講過嗰啲 taste-heavy、iterative、long-context 工作。Codex 清楚勝出嘅地方，係深度 coding diagnosis，同埋以前我會即刻交畀 Claude 嘅日常高速 coding turn。

所以誠實版本係：

喺更深一層嘅 code analysis 上，Opus 4.7 依然可以俾我一個幾好嘅 first pass
但喺 lighter coding turn 上，佢而家感覺比同級 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。

原因好簡單：

佢感覺好 specialized
佢 methodical
佢小心
佢同時處理 architecture 同 execution 都做得好
佢可以將一份 agreed plan 連同 unit、integration、browser tests 一齊跑 30 到 45 分鐘
喺 everyday coding turn 上，佢而家比 xHigh 嘅 Opus 4.7 更快
喺 deep coding work 上，我而家都更容易 trust 佢

其餘所有嘢

我首先會拎起 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，佢仍然係我最 trust 嘅 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 日冇任何結果嘅工具 benchmark。喺同一個 window 入面，Prova 嘅 Operator/Builder split 已經連同真正嘅 Builder execution lane 上咗線，兩篇 substantial blog post 出咗，而我亦都跑完咗一輪跨 12 個 locale 嘅 full translation pass。呢個 experiment 有冇拖慢我 output？答案係冇。

如果你想要最壓縮版本，咁就係：

我取消咗 Claude Max，但冇將 Claude Code 從工作流入面移除。我只係將佢搬離 primary coding seat，然後將成張枱其餘部分交畀佢。

呢個就係我而家可以俾到最真實嘅總結。

所以：如果重來一次，我仲會唔會做同一個決定？

會。

但而家我會用另一種方式去講。

4 月 3 號嗰陣，我嘅 framing 係：

「我取消咗 Claude Max，而家測試緊 Codex 可唔可以取代佢。」

到咗 4 月 22 號，更接近真相嘅 framing 其實係：

「我取消咗 Claude Max，發現對而家嘅我嚟講，Codex 係更強嘅 coding specialist，而 Claude Code 就接手咗我張枱其餘所有工作——喺嗰個位置上，佢仍然係我手上最好嘅 tool。」

呢個答案冇咁二元，比簡單 social-post 版本更貴，但亦都更接近事實。

常見問題

Codex 係咪真係喺 coding 上取代咗 Claude？

對我嚟講，係。喺 pure coding work 上，xHigh thinking 嘅 Codex with GPT-5.4 已經變成 default seat。xHigh 嘅 Opus 4.7 喺更深嘅 diagnosis 上仍然可以俾我一個有用嘅 first pass，但對我嚟講，佢已經唔再係 primary coding seat，而且喺 lighter coding turn 上而家都比 Codex 慢。

「平價 Codex」呢個故事企得唔企得住？

唔完全企得住。一進入真實工作量，low-tier economics 就已經唔足以講完整個故事。我要轉去更貴嘅 OpenAI plan，唔係因為 experiment 失敗，而係因為我需要更多 capacity。

你而家仲需要 Claude 嗎？

需要。如果你嘅工作包含 writing、design、naming、image prompting、長 research thread，或者任何高度依賴 taste 同 judgment 嘅 loop，你仍然會需要 Claude。喺我嘅 workflow 入面，xHigh 嘅 Opus 4.7 已經成為所有非 code 工作嘅 default。

reliability 又點睇？

reliability gap 依然重要。4 月只係令呢點更明顯。答案唔係 panic，而係 backup coverage。

點解提早 11 日出文？

因為個 pattern 已經 settle 咗。如果只係為咗尊重原本 headline 個數字而硬等到 5 月 2 號，嗰個只會係戲劇效果。更加誠實嘅做法，係直接講我而家實際點做，然後繼續向前。

咁如果係今日，你會買邊個 plan？

如果你嘅工作大部分都係 coding，我會非常認真先睇 Codex / GPT-5.4。如果你嘅工作同時包括 coding 同大量依賴 taste 嘅 creative work，我就唔想冇 Claude。而如果而家每月 100 美元超出預算，20 美元嘅 Codex tier 對較細嘅個人 project 仍然用得——只係你要預期，喺 sustained 嘅 multi-project work 之下，會更快撞到 limits。至少對我自己而言，而家個答案已經唔再係一個 single-tool answer。

呢個就係 19 日之後最誠實嘅 update。

Codex 攞咗 coding 嗰個位。

Claude Code 攞走咗其餘所有位置。

所以，一個字面上叫做 Claude Code 嘅 tool，而家反而變成我用嚟處理 code 之外幾乎所有嘢嘅 tool。

而真正嘅 lesson，講到尾都係嗰句：workflow 比 fandom 更重要。

如果你今個月都做過類似切換，我真係好想知你最後落喺邊度。係咪某一個 tool 完全贏咗，定係你自己嗰個 split 其實都變得更清楚？

祝好，
Chandler