用咗兩個星期 Codex 之後，我決定退訂 $200 嘅 Claude Code 計劃
距離我上次比較兩個星期之後，兩個工具都出咗重大更新。Codex 挑戰咗我嘅產品策略，而 Claude Code 做唔到。Claude Code 就推出咗 Agent Teams 同 AutoMemory。結果係：我準備退訂 $200/月嘅 Max 計劃——而且用更少錢，出更好嘅成果。
兩個星期之前我寫咗篇文章，講雙持 Codex 同 Claude Code 嘅體驗。嗰篇比我寫過嘅任何嘢反應都大——原來好多人都喺做同一個實驗。
嗰時，我嘅工作模型好清晰：Claude Code 負責執行質量同 QA，Codex 負責架構推理同持續計劃。兩個工具，唔同強項，重要嘅嘢就用跨模型 review。
兩個星期之後，兩邊都出咗重大更新，而平衡已經開始移動。唔算好誇張——但足以值得再寫一篇。（講明先，呢篇文我係用 Claude Code 寫嘅——唔係因為忠誠，而係因為我呢個 billing cycle 仲未完，唔想浪費已經畀咗嘅錢。呢種實際考量正正就係呢篇文想講嘅重點。）
2026 年 3 月對兩個平台嚟講都好密集。Codex 推出咗 plugins，整合咗 Slack、Gmail、Linear、Figma、Sentry 等等——仲有 Triggers 做自動化 GitHub workflow、GPT-5.4 mini 同 nano model，以及 Windows 原生支援。Claude Code 就出咗 Agent Teams（多 agent 編排，仲係實驗性質）、AutoMemory、Computer Use（只限 macOS，Pro/Max 計劃）、透過 /loop 嘅排程任務，同埋光係 3 月就出咗大約 10 個版本。兩邊都跑得好快。
Newsletter 嘅故事（點解呢件事唔止關 code 嘅事）
改變我諗法嘅觀察，同寫 code 完全冇關。
我個網站有一套完整嘅 newsletter 系統——訂閱表單、文章 CTA、歡迎郵件、每日 cron、雙重確認、13 種語言支援。技術上嚟講，全部都 work。問題係：zero verified subscribers。
我草擬咗一個修復方案：由課程入面抽一份 lead magnet PDF、將 Module 1 放喺 email gate 後面、加入文章中段 CTA、將 AI chatbot 接入訂閱流程、通過 YouTube 同 LinkedIn 再分發。七樣新嘢。
我用 Claude Code 起呢個方案。過程感覺好有效率。
然後我將同一份 brief 畀咗 Codex。佢嘅 pushback 即刻到。
Lead magnet 係多餘嘅——Module 1 本身已經免費。太多 surface 一次過做——如果七樣都起晒，你根本分唔到邊樣有效。問題唔係基建，係文案。「Stay in the loop」太 generic。確認郵件唔夠有說服力。興趣選擇增加咗摩擦。
Codex 嘅方案：先修好而家有嘅嘢（重寫文案、改善確認郵件、減少摩擦），加一個新 surface（inline blog CTA），用 GA event 做量度，然後先決定下一步。
我嘅方案係「整更多嘢」。Codex 嘅方案係「將現有嘅嘢做好，然後測試一樣新嘅嘢」。我嗰個方案要一個星期，而且完全冇辦法知道邊樣有效。Codex 嗰個一日可以 ship，仲會話你知下一步應該投資喺邊。
我都要承認——呢下真係被佢 catch off guard。唔係因為 Claude 唔識做策略。我覺得如果我 prompt 得更小心——「喺執行之前先挑戰我嘅假設」——可能都會收到類似嘅 pushback。但預設嘅推理風格明顯唔同。GPT-5.4 預設係「質疑前提」。Claude 預設係「好好咁執行計劃」。
呢個分別對產品決策嚟講好重要。
速度同操控
兩個我留意到嘅嘢，對日常 workflow 嘅影響比預想中大好多。
速度同 token 效率： Codex 配 GPT-5.4 開 high thinking，喺同等任務上一直都比 Opus 4.6 開 high thinking 快。第三方比較顯示 Codex 大概用少 3 倍嘅 token 做類似工作——有一個 benchmark 喺一個 Figma 風格嘅任務上量到 150 萬 token，而 Claude 用咗 620 萬。Claude 傾向「出聲思考」多啲，呢樣會產生質量更高嘅推理，但燒 limit 燒得更快。大約 3 月 20 號開始，Opus 似乎做多咗 tool call——到答案之前有更多中間步驟。我唔確定呢個係 model 改動定純粹巧合，但感覺到。
實時操控： 當我喺工具運行緊嘅時候傳新訊息——「等等，唔係嗰個方向，試下呢個」——Codex 幾乎即刻就讀到然後調整。Claude Code 傾向做完手頭嘅執行先讀 correction。
聽落好小事。但唔係。當你望住一個 agent 行錯方向，你想即時修正，「而家就讀到你嘅 correction」同「做完手頭嘅嘢先讀」之間嘅延遲，喺成日嘅工作 session 入面係會疊加嘅。
SSE Bug：一個具體例子
我當時喺起一個新 iOS app。Claude Code 已經產出咗 40 個 Swift 檔案，覆蓋晒所有功能——auth、agents、chat、frameworks、dashboard、profile。涵蓋面好闊。但有一個關鍵 bug 搞唔掂：SSE streaming 做唔到實時 chat。
Backend 冇問題。Curl 正常。但 Swift client 入面嘅 URLSessionDataDelegate.didReceive(data:) 點都唔 fire。Claude Code 喺呢個問題上搞咗幾個鐘。試過好多方法，做過幾輪 debugging session。
我將同一個問題畀咗 Codex。試咗幾次之後：commit 7f592152 —— "fix(ios): restore real-time chat streaming."
呢個係唔係有代表性？可能唔係。每個工具都有順風同逆風嘅日子。但以我嘅經驗嚟講，當 Claude Code 困喺一個 debugging loop——不斷試同一種方法嘅越嚟越聰明嘅變體——轉去 Codex 通常可以打破僵局，因為 GPT-5.4 一開始就用唔同嘅方式定義問題。
Claude Code 仲係贏喺邊
如果你讀到呢度覺得 Codex 已經全面領先，咁就錯啦。Claude Code 呢個月一樣出咗好多嘢，而且佢好幾個優勢其實仲強咗。
Agent Teams。 呢個 2 月推出，3 月一路成熟緊。多個 Claude Code instance 平行運作——一個 explorer、一個 code reviewer、一個 implementer、一個 test runner——有依賴追蹤同共享任務列表。仲係實驗性質，預設停用，但開咗之後真係好 impressive。Codex 都有 multi-agent 支援（task 喺隔離嘅雲端 container 跑），但 Claude Code 嘅 Agent Teams 感覺更有協調性。做大型 refactor 要改好多檔案嘅時候，Agent Teams 而家嘅體驗更好。
AutoMemory。 Claude Code 而家會自動根據你嘅習慣寫 memory rule。用咗幾個 session 之後，佢知道你嘅 project 結構、命名慣例、偏好。呢個效果好subtle，但累積起嚟嘅結果係 Claude Code session 會越嚟越有效率，而 Codex session 目前仲未做到呢一點。
Frontend 設計。 Claude Code 配 /frontend-design plugin 出嚟嘅 UI，依然明顯比 Codex 配同等 skill 更 polished、更有 design system 意識。我喺 3 月 26 號做一次網站 redesign 嘅時候直接測試咗。Claude 嘅輸出有更好嘅空間構圖、更一致嘅 styling、更有凝聚力嘅整體效果。呢個可能係 harness 優勢（Claude 嘅 plugin 系統跑 skill 嘅時候帶更多 context），但實際結果好清楚。
Code 質量。 一個 社群分析咗 Reddit 上 500+ 開發者評論 嘅研究發現，開發者喺約 67% 嘅 blind comparison 入面偏好 Claude Code 嘅輸出——覺得 code 更乾淨、更 idiomatic、結構更好。呢個同我嘅經驗吻合。當 code 唔止要 work，仲要 maintainable 嘅時候，Claude Code 有優勢。
自動 QA。 仲係 killer feature。完成工作之後，Claude Code 會自動派 review agent——code review、一致性檢查、gap analysis——唔使我開口。Codex 而家仲未有呢一層。任何 correctness 比 speed 更重要嘅嘢，單係呢一點就足以令 Claude Code 留喺 workflow 入面。
可靠性問題
我想分享一樣嘢，大部分比較文都會避開。
以下係截至 2026 年 3 月下旬，兩個平台狀態頁嘅 90 日 uptime 數字：
| 服務 | Anthropic | OpenAI |
|---|---|---|
| 主平台 | claude.ai: 99.16% | ChatGPT: 99.91% |
| API | api.anthropic.com: 99.24% | APIs: 99.99% |
| 開發者工具 | Claude Code: 99.48% | — |
| Console | platform.claude.com: 99.41% | — |
差距係真實嘅。90 日入面，Anthropic 嘅服務大約有比 OpenAI 多 8-10 倍嘅 downtime。3 月 25 號有一宗具體事故——「Elevated errors on Claude Opus 4.6」——一個 investigating-fix-investigating 嘅循環持續咗差唔多兩個鐘。
公平嚟講，呢個唔係全部。可靠性唔淨係 uptime。BeyondTrust 嘅 Phantom Labs 公開披露咗一個 Codex 嘅命令注入漏洞，可以通過操縱 branch name 暴露 GitHub 認證 token。呢個漏洞影響咗 web UI、CLI、SDK 同 IDE 整合——一個用戶可控嘅 branch name 直接傳入 shell command 而冇做 sanitization。OpenAI 已經 patch 咗，但呢件事提醒我哋，穩定性同安全性係可靠性嘅唔同維度，兩者都重要。
我分享 uptime 數據唔係想踩 Anthropic。我每日都用 Claude Code，佢仲係好出色。但對於任何將專業 workflow 建立喺呢啲工具上嘅人嚟講，呢啲數字值得知道。而且呢個正正就係點解雙持唔止係「有就好」——當其中一個服務有個差嘅下午，你切過去繼續工作。兩個星期入面我已經做過三次。
Plugin 差距正在收窄
喺我第一篇文入面，我提到 Claude Code 嘅 plugin 生態更成熟。兩個星期前係事實。而家冇咁準確。
Codex 喺 3 月 27 號推出咗佢嘅 plugin 系統，整合咗 Slack、Gmail、Google Drive、Linear、Figma、Sentry、Notion 同 Hugging Face。仲有 skills、hooks（包括 SessionStart 同 UserPromptSubmit event）、MCP server，同埋 app 同 CLI 入面嘅 plugin directory。
功能集正在收斂。兩個工具而家都有：plugin/skill 做可重用 workflow、hooks 做 event-driven automation、MCP server 整合，以及同外部服務嘅 app 層面整合。
Claude Code 仲係領先嘅地方：現有 plugin 生態更深。好似 Superpowers（結構化規劃）、/feature-dev（引導式開發）同 /frontend-design 呢類 plugin 已經打磨咗幾個月。Codex 嘅 plugin directory 比較新，個別 plugin 仲未經過咁多實戰考驗。
Codex 正在領先嘅地方：Triggers。 Codex 可以自動回應 GitHub event——一個 issue 入嚟，Codex 自動修，開 PR。呢個係一個全新嘅自動化類別，Claude Code 而家仲未有。對於想要自主工程 workflow 嘅團隊嚟講，Triggers 係一個重要嘅差異化優勢。
我更新咗嘅工作模型
兩個星期之前，我大概 60/40 分配 Claude Code/Codex。我有一個清晰嘅心智模型：要質量就用 Claude Code，要架構推理就用 Codex。
呢個整齊嘅分法已經溶解咗。我而家成日兩個都用，憑感覺切換多過跟規則。一個任務用 Codex，下一個用 Claude Code，有時兩個一齊 review 同一份計劃。兩個工具嘅能力已經接近到，「呢件事應該用邊個？」呢個問題比兩個星期前冇咁重要。
改變咗嘅係經濟考量。
OpenAI 嘅 Plus plan 係 $20/月，limit 越畀越慷慨。我發現自己越嚟越多伸手攞 Codex——唔係因為佢喺任何一方面大幅領先，而係速度、token 效率加埋嗰個 $20 嘅價位，令摩擦消失。唔使再喺腦入面計「呢個任務值唔值得燒 Claude Code token？」
我傾向將 Claude Code 計劃由 $200/月嘅 Max tier 降去 $100/月嘅計劃，甚至可能降到 $20/月嘅 Pro plan。兩個星期前，咁做會覺得有風險。而家覺得好實際。我需要 Claude Code 做到最好嘅嘢——frontend 設計、Agent Teams 編排、自動 QA 捉到我會漏嘅嘢——呢啲係真實優勢。但如果 Codex 喺 $20 度接走我一半嘅工作量，可能唔需要 $200/月。
我知道呢個押注有風險。$20 嘅 Claude Code tier 有真實嘅用量限制——如果喺一個關鍵 session 入面撞到 limit，我會後悔降級。而且 OpenAI 嗰個慷慨嘅 $20 limit 好可能係搶市場份額嘅策略，未必會永遠維持。但而家，經濟考量有利於雙持。
總成本（$20 Codex + $100 甚至 $20 Claude Code）會低過我之前單獨畀 Claude Code 嘅錢。而且合併輸出比任何一個工具單獨用喺任何價位都更好。
呢個可能係雙持兩個星期最實際嘅 takeaway：競爭唔止令工具更好。仲令佢哋更平。更平就代表你兩個都用得起。
我預期接下嚟會點
兩個平台都喺加速。Codex 啱啱推出咗 plugin、triggers 同 Windows client。Claude Code 啱啱出咗 Agent Teams、AutoMemory、Computer Use 同 Scheduled Tasks。冇一個企喺度唔郁。
Reddit 開發者社群入面一個常見嘅講法——我覺得佢捕捉到一啲真實嘅嘢——就係「Claude Code 質量更高但你會撞 limit。Codex 質量稍低但日常用更順。」隨住兩邊改進，呢個平衡會繼續移動。
我嘅建議同第一篇一樣，但而家更堅定：試下另一個工具用一個星期。唔係為咗轉——而係為咗加。跨模型 review workflow 仲係我搵到最好嘅發現。而且有兩個你信得過嘅工具帶嚟嘅操作韌性，喺其中一個 down 嘅嗰日會救到你。
作為用家，呢個係最好嘅情況。兩個出色嘅工具都喺快速進步，互相推動對方向前。競爭嘅節奏咁激烈，我唔覺得任何一間公司可以舒服咁領先太耐——所以押注喺單一工具上越嚟越有風險，押注喺 workflow 上（雙持、跨模型 review）越嚟越合理。
常見問題
你嘅睇法同第一篇相比有冇變？
核心論點——雙持好過揀贏家——只係更加堅定咗。改變咗嘅係分配（60/40 變咗 50/50）同原因。Codex 喺策略推理方面嘅強勢比佢 coding 嘅進步更令我意外。
Codex 比 Claude Code 快？
開 high thinking 嘅話，係——一直都快啲，而且第三方比較顯示佢做同等任務大約用少 3 倍 token。開 default thinking，差距細啲。對於需要頻繁來回嘅迭代工作，速度同 token 效率會疊加。
應唔應該擔心 Claude Code 嘅 uptime？
90 日數字顯示差距係真實嘅（99.2% vs 99.9%）。如果 Claude Code 係你唯一嘅工具而你又趕 deadline，要有後備方案。但 Anthropic 光係 3 月就出咗大約 10 個 Claude Code 版本——佢哋功能迭代好快，只係可靠性仲追緊 OpenAI。
Codex 嗰個安全漏洞係咩事？
一個 Codex 嘅命令注入漏洞可以透過 branch name 暴露 GitHub token。已經被發現同修復。值得知道，但同時都值得留意，安全研究人員積極測試呢啲工具——呢個對成個生態係好事。
Newsletter 策略嘅故事真係關工具嘅事？
一部分。唔同 model 有唔同嘅預設推理風格。GPT-5.4 更傾向挑戰我嘅假設。Claude 更傾向幫我好好執行計劃。兩者都有用——但對於產品策略嚟講，「你係咪喺解決正確嘅問題？」往往比「呢個係一個好嘅 implementation」更有價值。
我應該買邊個工具？
兩個都買。呢個唔係 hea 答——係真心覺得最好嘅答案。Codex $20/月加 Claude Code $20-100/月，出嚟嘅結果好過任何一個工具單獨用喺任何價位。我傾向由 Claude Code 嘅 $200/月降去 $100 甚至 $20，再加 Codex $20。總成本降低，產出反而提高。不過 OpenAI 嗰個慷慨嘅 limit 未必會持續——所以保持靈活。
差唔多就係咁。如果你都喺做自己嘅雙持實驗，我真心想聽下你嘅分配點樣演變緊。同一個 pattern，定係完全唔同嘅發現？
Cheers, Chandler
