こんにちは、とまだです。

各位，有沒有在考慮使用 Claude Code 或 Codex CLI 哪一個的困擾呢？

過去，Claude Code 曾經一度風靡，但最近試用了 Codex CLI 後，對它強大的推理能力感到驚訝。

觀察到 X 上，Codex CLI 的討論也逐漸增加。

這樣看來，「究竟應該使用哪一個？」的疑惑也讓許多人困擾。

這次，我將根據過去對這兩個工具的實際使用經驗，詳細闡述各自的特點及使用分配！

另外，這次的內容會在 9/28 的線上活動中進一步深入解說！

忙碌人士的摘要

我將從幾個觀點來比較，先做好結論。

AI 驅動開發工具的選擇取決於開發風格

我開始接觸 AI 驅動開發的契機是從 GitHub Copilot 開始的。

在工作中第一次接觸到，對其程式碼生成能力感到驚訝。
從那以後，我嘗試了像 Cursor、Cline、AWS Kiro 和 JetBrains 的 AI 助手等各種工具。

然後，自 6 月開始我正式使用 Claude Code，現在已經成為我日常的開發工具。

而如今我同時使用 Claude Code 和 Codex CLI。

基於這些經驗，我將解釋這兩個工具的特點與使用分配，以及應該選擇哪一個！

溫故知新：Claude Code 和 Codex CLI 的基本資料

首先確認基本的定位。

Claude Code 是由 Anthropic 提供的終端整合型 AI 編碼助手。
Codex CLI 則是 OpenAI 提供的命令列基礎工具。

而且，Codex 除了命令列基礎外，還有雲端版本與 VSCode 的擴充功能可供使用。

應該選哪一個？觀點別的比較

接下來，我將從不同的觀點來解釋應該選擇哪一個。

根據我對 Claude Code 和 Codex CLI 的深入使用經驗，希望能提供對大家有幫助的信息。

觀點 1：依價格方案與性價比選擇 Claude Code

這兩者都可以從每月 20 美元開始，但在價格體系和使用限制上有很大的不同，下面詳加說明。

價格體系的詳細比較

Claude Code 的價格體系如下：

• Pro 方案：每月 20 美元（年繳每月 17 美元）
• Max 5x 方案：每月 100 美元
• Max 20x 方案：每月 200 美元

另一方面，Codex CLI 的價格體系是這樣的：

• Plus 方案：每月 20 美元
• Pro 方案：每月 200 美元

Claude Code 的 Pro 方案是每月 20 美元，但 Codex CLI 的 Pro 方案則是每月 200 美元。
雖然同名「Pro」，但內容差異很大，需仔細注意。

中間方案的存在是亮點

這裡需要注意的是中間方案的選擇。

• 參考：Max 方案的價格是多少？

Claude Code 有一個名為 Max 5x 的計畫，每月 100 美元。

然而 Codex CLI 在 20 美元之後，則跳到了 每月 200 美元，這是一個很大的漲幅。

在最便宜的方案中，使用 1-2 小時就達到限制，因此對於需進行認真開發的人來說，可能不夠用。

如果你希望使用的時間更長，但 200 美元卻覺得貴，那麼 Claude Code 提供了選擇的機會。

若價格可接受，可考慮年繳的 Claude Code

更進一步，Claude Code 年繳發票可為 每月 17 美元。
這意謂著，每個月將節省 3 美元，每年可省 36 美元（約 5000 日元）。

更棒的是，可從年繳的 Pro 方案遷移至 Max 方案。
差額將以信用額度形式提供，讓人安心。

• 參考：如何註冊 Max 方案？

因此，從價格來看，Claude Code 是較為划算的選擇。

對於在平日夜間或假日只需偶爾使用的人，選擇年繳方案的 Claude Code 性價比是很好的選擇。

觀點 2：若重視程式碼品質，則選擇 Codex CLI

接下來，讓我們看看 程式碼品質 這個觀點。

這應該是許多人最關心的重點。

實務中使用的實感

我在實務上用過這兩個工具。

我使用過 Claude Code 的 Max 20x 方案，也在 Codex CLI 上試過 Pro 方案。

根據我的使用經驗，Codex CLI 的程式碼品質通常較高。

特別是在處理漏洞修正和複雜實作等情境時，Codex CLI 多數可一次性完成。

若在 Claude Code 中需要多次進行修改的情形，往往在 Codex CLI 上可以在一兩次內解決。

為什麼 Codex CLI 的程式碼品質高？

Codex CLI 使用的是GPT-5-Codex這個專用模型。

據說該模型專為編碼而訓練。
因此，我感受到對程式碼結構及最佳實踐的理解很深入。

例如，當發出模糊的指示時。

Claude Code 會迅速生成可運行的東西，而生成的程式碼還算不錯。

另一方面，Codex CLI 則通常會在不必說的情況下，直接考慮以下幾點：

• 適當的錯誤處理
• 安全性的考量
• 程式碼的可讀性
• 高效演算法的選擇

雖然 Claude Code 在某些情況下也會主動考慮這些點，然而 Codex CLI 提供的高品質程式碼的印象更加一致。

我在日常開發和實務中使用這兩者的時候，發現了這一點。

在複雜實作中差異顯著

特別在處理複雜邏輯或大型系統設計時，差異變得更加明顯。

在這種情況下，Codex CLI 提供的實作建議非常準確。

我見過的各種項目也提到「Codex CLI 在嘗試不同方案後找到最佳解」，顯示出其深厚的推理能力。

當前進行量化評估頗有挑戰，但根據實務經驗，我覺得 Codex CLI 的程式碼品質高出一籌。

注意事項：Claude Code 曾經有品質一度降低的時期

之前，我有寫過文章比較這兩個工具。

• 參考: 【驗證】Claude Code vs Codex：比較製作相同應用程式的程式碼品質

然而，在進行此比較的時期（大約2025年8月），Claude Code 則曾出現 性能降低的錯誤。

網上有意見混合一些該時期的影響，因此在觀察時必須小心。

然而，即使在性能恢復的當前，對於 Codex CLI 在漏洞修正及複雜實作的優勢我依然有深刻的感受。

考慮長期觀點

性能差異主要源於模型的差異。

此外，關於 Claude 4.5 的發佈臨近的消息，若 Opus 也有更新，可能會使 雙方的差異縮小甚至逆轉。

因此，無需僅根據當前的品質差異決定，而是 著眼於「長期使用」 來綜合考量使用的便利性等。

特別是在團隊導入的情境下，基本上是以數月到數年的使用為前提。

因此，強烈建議重視長期使用的便利性，而非評估特定時間的模型性能差異。

Claude Code 透過巧思提升品質的可能性

需要說明的是，Claude Code 並不意味著它的品質低下。

使用像 SuperClaude 這樣的框架，任何人都能夠輕鬆獲取高效能。

• 參考: SuperClaude 什麼？讓 Claude Code 的程式碼品質提升 30% 的工具完整指南！

透過自定義指令可以自動化品質檢查，還可以通過子代理讓專業領域承擔責任來期望提升程式碼品質。

總結來說，默認品質較高的是 Codex CLI。
但是，根據自定義的情況，Claude Code 也能達到相當的品質。

這樣的關係我理解得很清楚。

觀點 3：如重視自定義性則選擇 Claude Code

接下來，個人最重視的 自定義性觀點，讓我們來看一下。

自定義指令是什麼？自動化標準作業的機制

這裡所說的自定義指令，是指可從 CLI 呼叫的標準化提示。

透過它可以快速指示 AI 處理特定任務。

• 參考: 讓我們使用 Claude Code 自定義指令，提高效率與自動化！
• 參考：SuperClaude 自定義指令 21 種使用方法！包括選項及使用場景

Claude Code 的情況：靈活且強大的自定義指令

Claude Code 的最大魅力就是其絕對的自定義性。

自定義指令可接收參數，也可嵌入 Bash 指令。
此外，還可針對專案設定不同的指令。

而且，因為它可以透過參數接收文本，因此在呼叫指令時可以一起傳遞詳細的指示。

例如，以下用途中可以活用自定義指令。

• 需求定義：從用戶訪談中提取需求
• 測試生成：自動生成單元測試和整合測試
• 程式碼審查：分析 PR 差異並提出改進建議
• 文檔生成：自動生成文檔

設定也很簡單，只需將其放在 .claude/commands/ 目錄下。
還可以將其放在專案內，利用 Git 進行管理並與團隊共享。

Codex CLI 的情況：功能或團隊共享有限制

Codex CLI 也可建立自定義指令（準確而言為自定義提示）。

• 參考：全方位攻略 Codex CLI 的自定義指令！即時調用常用指示的方法

但是，相較於 Claude Code 存在以下限制。

• 僅可配置在主目錄的 .codex/commands/ 中
• 無法用 Git 管理和與團隊共享
• 專案之間無法管理不同的設定
• 不能接收參數或 Bash 指令

由於這些限制，使用不同設定的變換不太方便。

據說如果預先準備文本文件放在專案內，強行以參數的身份呼叫是有可能的。

不過，這樣的方式不太聰明。

理想上，希望 Codex CLI 能像 Claude Code 一樣，作為標準功能支持參數接收，或能管理專案間不同的設定。

這部分期待未來的更新。

使用子代理讓專業領域負責（僅 Claude Code）

更多地，Claude Code 擁有一個功能強大的 「子代理」 功能。

首先，子代理是指擁有特定角色的 AI 代理。

• 參考: 在 Claude Code 中創建專家！子代理功能用來開發專業 AI 提升品質的體驗

並且當進行開發時，自動呼叫這些子代理。

例如，可以配置以下類型的子代理。

• 專注於安全檢查的代理
• 專注於前端開發的代理
• 專注於後端開發的代理
• 專注於測試程式碼生成的代理

這個功能的特點在於，即使用戶未明確指示，也會在適當的時機自動呼叫。

此外，各個代理能獨立管理上下文（對話歷史）。

這意味着，它們在良好的意義上不會被先前的對話歷史影響，而是能利用專業知識。

SuperClaude 讓自定義變得輕而易舉

再回到 Claude Code，這裡有一個更強大的框架。

它就是 SuperClaude。

之前在文章和影片中介紹過，這個框架內建了各種在開發場景中實用的自定義指令和子代理。

• 參考: SuperClaude 什麼？Claude Code 的程式碼品質提升 30% 的神工具完整指南！

這些指令的數量每日都在更新，截止到 2025 年 9 月 22 日，自定義指令有 25 個，子代理則提供 15 個。

例如，有助於構思的自定義指令，或用於檢查程式碼品質和進行重構的指令等，他們都是個人或實務開發中非常有用的功能。
實際上，已經有實績證明，在專案中減少 71% 的程式碼量。

從需求定義到設計、計劃、實作和錯誤解決的全過程，均有相關的文章和影片公開，若有興趣的話請參考。

• 參考：用 SuperClaude 的推薦工作流程開發天氣預報應用程式，開發效率劇增的故事

這個框架充分利用了 Claude Code 自定義指令中的參數和 Bash 指令，因此在 Codex CLI 上實現相同的效果將非常艱難。
這也是 Claude Code 的靈活性的好處。

預設即為高品質的 Codex CLI

稍微偏離主題，讓我們看看 Codex CLI。

Codex CLI 基於 GPT-5-Codex 的程式碼專用模型運行，性能優越。

因此，即使不進行細緻的自定義，也能獲得良好的效果。
即便是簡單的指出，Codex CLI 也能生成適合的程式碼。

至此，我將 Claude Code 的 自定義性視為優勢 來陳述。

不過，相對而言，自定義過多可能會在某些情況下成為缺點。

例如在團隊開發中，可能會出現 技能差距，以及 對新成員的資訊共享負擔增重 的問題。
因此，Codex CLI 即使在默認也具備高性能，這也可以算是它的優勢之一。

觀點 4：針對需求與設計，則選擇 Claude Code

接下來我們針對特別預想於實務的使用，從 需求與設計重視的「計劃性」 的方向來看。

透過「計劃模式」實現計劃性開發

針對重視設計者，我會推薦 Claude Code。

Claude Code 提供了利用「計劃模式」在實作前首先進行計劃的機會。

在實作前先進行計劃，獲得用戶的批准後再進行實作。

在以下幾種情況下，這非常有效：

• 與業務方協作時
• 以任務為單位進行謹慎開發時
• 當需求複雜並需逐步實作的情況下

目前我在實務中使用的時間多於個人開發，因此計劃模式對我來說非常重要。

這種開發模式是根據事先確定的需求進行設計的。

與規範驅動開發工具的相容性

此外，像 AWS 的 Kiro 這樣的規範驅動開發工具也雖然未正式，但確實存在。

首先，規範驅動開發 是在編碼之前製作規範書，並根據該規範生成和驗證代碼的開發方法。
以 AWS 的 Kiro 編輯器為契機而受到關注。

透過事前的「需求定義」、「設計」、「實作計劃」文件化，能夠給 AI 提出明確的指示。

而且雖然是非官方的，但已有一些針對 Claude Code 的規範驅動開發工具。

在國內外知名的有 GitHub 官方提供的工具 spec-kit。

另外，我之前介紹的國產工具 cc-sdd 也在此列。

• 參考: 【規範驅動開發】cc-sdd 讓 Kiro 風格也簡單！Claude Code/Cursor/Gemini CLI 都支持的國產工具

Claude Code 除了支援以外，Cursor 和 Gemini CLI 等 VS Code 系的編輯器也能使用，而 Codex CLI 幾乎不具備此功能。
例如 spec-kit 對於 Codex CLI 是無法使用的。

另外，個人對規範驅動開發非常喜愛，我還為 Codex CLI 製作了一個 npm 版的規範驅動開發工具。
有興趣的話，歡迎使用！

（補充：我也寫了方便了解使用方式和優點的文章！）

到這裡的比較

如先前所述，Codex CLI 不具備計劃模式，因此想提前計劃需要自行細心設計提示。
而且，若要實施規範驅動開發，同樣需透過提示進行細緻調整。

因此，在具有 標準功能或知名的非官方工具支持 的意義上，Claude Code 是勝出的。

當然，在 Codex CLI 上也能進行設計重視的開發。

但是，通常在掌握提示的要點上會花一些時間，因此對於不熟悉的人來說，可能有較高的門檻。

觀點 5：若為程式設計初學者，則選擇 Codex（IDE/Cloud）

接下來，讓我們從 工具的操作性 的觀點進行比較。

這同時包含了程式設計和命令列以外的需求。

終端使用者則兩者都可

首先，Claude Code 完全基於終端。
儘管還有可以在 VSCode 上使用的擴充功能，但仍然主要是在命令列的操作。

（截圖為 Claude Code 的 VS Code 擴充功能）

對於習慣命令列的人來說，這並不是問題。
但是對於不習慣的人來說，可能會有些高門檻。

例如我目前進入的專案中，設計師也開始使用 Claude Code 製作原型。

但是因為他平常不常操作終端，實際上會有一些困難。

偏好 GUI 者則 Codex CLI 的靈活性更具魅力

Codex CLI 除了 CLI 外，還可通過 VS Code 的擴充功能或網頁瀏覽器進行使用。

準確來說，將 Codex CLI 視為 Codex IDE 和 Codex Cloud 兩種不同的工具。

Codex IDE 支援 VS Code、Cursor 和 Windsurf 等 VS Code 系的編輯器。

安裝為擴充功能後，可在側邊欄以聊天形式發出指示，並可管理模型的變更和對話歷史。

此外，Codex Cloud 讓用戶可直接透過網頁瀏覽器發出開發指示。

甚至可以透過手機應用程式向 Codex 發出指示。

若事先將自己的 GitHub 倉庫連接，則可從外出至開展開發、撰寫和修改 Pull Request。

另外，在 Cloud Code 中也有名為 Cloud Code Action 的功能，通過與 Pull Request 相關聯來實現。
例如，可以從 Pull Request 中提及，呼叫 Codex 進行修正。

而在 Codex 中，可以直接透過瀏覽器或應用程式發出指示，並立即創建 Pull Request，因此連不熟悉命令列操作的人也能進行功能創建。

對於非工程師或程式設計初學者來說，首先試著使用 Codex IDE 或 Codex Cloud，熟悉後再轉移至 Codex CLI 或 Claude Code 將會是個不錯的選擇。

在擴充功能或網頁版中熟悉後，再轉移至 Codex CLI。
這樣階段性的過渡是 Codex 的強項。

觀點 6：若是第一次接觸 AI 驅動開發，選擇 Claude Code

接下來，我們從 學習的容易性 的觀點進行分析。

這個分析並非針對程式設計的學習，而是針對 作為 AI 驅動開發的學習容易性，及技術的掌握容易性 的觀點進行比較。

資訊收集的方便性

原文出處：https://qiita.com/tomada/items/c369d5f28142a2599a36