你好,我是まだ。
你在猶豫該使用Claude Code還是Codex嗎?
因此這次,我們使用這兩個工具製作了相同需求的待辦清單應用,並從五個方面徹底比較了代碼品質。
從結果來看,我們發現這兩者各有明顯的優勢。
接下來將向你傳達這次的比較結果!
另外,在我們進行錄製的時候,據說Claude Code的性能暫時下降。
所以可能不是公平的比較,等問題修正後我們再重新檢查一下。
在影片中我們將進行比本文更詳細的解說!
隨著AI驅動的開發工具不斷出現,選擇哪一個變得越來越困難。
實際上,從Google Trends來看,Codex在日本和世界的關注度都在上升。但另一方面,Claude Code也保持著穩定的人氣。
因此這次,我們決定用客觀的數據進行比較。
如果用烹飪來比喻,就像把相同的食譜給兩位廚師,看看他們能做出怎樣的菜肴。
究竟哪位廚師能做出更美味的料理呢!
首先,我們讓ChatGPT成為優秀的產品經理。
不過,單純的待辦清單應用可能不容易顯示出差異。
因此,增加了以下功能:
此外,我們僅使用本地儲存,製作了一個單頁的應用。這樣可以排除外部因素,純粹比較實作能力。
為了保持公平性,我們在以下條件下實現了兩個工具。
此外,Claude Code使用Opus 4.1,而Codex則使用GPT-5(推理等級高)。
這兩者都是目前最強的智力模式。
實際動手製作後,我們發現了一些有趣的差異。
細節會在視頻版中說明,但這裡摘錄一些要點。
Claude Code是採用逐步增加功能的方式。
在需要的時候加入狀態管理和組件。就像在建造房子時繪製設計圖一樣。
另一方面,Codex則是一開始就固定整體設計的方式。
自動採用領域驅動設計,並且分層清晰。
這可以說是一種在完成設計圖後才開始建築的計畫性方法。
Claude Code忠實地遵循指示。
若請求使用TDD形式來實作,它會如實進行。
就像是一位乖順的助手。
如果出現與想法不同的地方,後來可以修正,這正是所謂的即時編碼。
相對而言,Codex會積極確認曖昧之處。
「這樣的行內編輯可以嗎?」「需要虛擬清單嗎?」等,逐步確定規格。
這就像客戶與工程師之間的對話。
在想快速完成的時候可能會讓人感到不耐煩,但在製作正式應用時這是一個重要的做法。
這種差異將影響到完成品的品質。
有趣的是,選擇的測試框架有所不同。
Claude Code選擇了Jest(重視穩定性)。
Codex則選擇了Vitest(採用最新技術)。
通常而言,AI往往選擇老舊且經典的穩定技術。
然而Codex卻選擇了速度更快的Vitest。
特別是在未明確指示的情況下選擇Vitest,是個頗令人意外的地方。
接下來進入重點。
我們使用SuperClaude這個品質分析框架,從五個方面進行評估。
工具 | 總體分數 | 評價 |
---|---|---|
Codex | 81.0分 | 良好水平 |
Claude Code | 76.8分 | 良好水平 |
兩者的品質均可用於實務。
近來據說Claude Code的性能暫時下降,因此我以為差距可能會更大,結果並沒有太大差別。
不過,若從項目別來看,卻出現了明顯差異。
讓我們深入看看。
Codex由於採用領域驅動設計,責任分離清晰。
其結構非常適合未來進行功能添加或修正。
另一方面,Claude Code雖然表現尚可,但組件稍稍較大。
就我個人的偏好而言,Codex更具優勢。
兩者均適當應用了React的優化方法。
並沒有顯著差距,都是實用的水準。
兩者均未實作本地儲存的加密。
同時,CSP標頭的設定也有不足之處。
這一部分可能需要人力介入來補充。
儘管如此,兩者在滿分100分中仍各自取得接近80分,因此在處理非特別安全的數據時,應該不會出現太大問題。
這裡顯示出最大的差距。
Codex融入了注重安全性的實作,並考慮了本地儲存資料損毀的恢復。
而Claude Code僅進行基本的處理,對於異常情況的應對卻不足。
在個人開發的階段,可能會將這一部分放在後頭處理,但Codex從一開始就做了周全的考慮。
雖然後來補充錯誤處理的情況很常見,但能在一開始就周到考慮,值得很高的評價。
意外的是Claude Code獲得了較高的評價。
可能是因為沒有導入領域驅動設計?
Claude Code在靈活性上更容易自訂的評價。
在小規模專案中,這份靈活性可能會派上用場。
在數值上無法表達的外觀和易用性也非常重要。
Claude Code製作的UI有如下特徵:
特別是在未特別指示的時候就完成了洗練的UI。
另一方面,Codex的UI則以功能為主。
功能一應俱全,但UI的完成度略有所欠。
對於AI所製作的UI我並沒有很高的期待,但就我個人而言,我更喜歡Claude Code的設計。
我們還比較了實作所需的時間。
Claude Code約花了25分鐘完成。
實作過程順利,沒有遇到大問題。
Codex約花了40分鐘(包括問題解決的時間)。
因Vitest未能在沙盒環境下運作,因此需切換到CLI版本。
不過,這是環境問題,而並非工具本身的缺陷。
那麼我們該如何正確使用這兩種工具呢?
以下是綜合至今所看到的個人想法。
首先,小〜中型的個人開發推薦使用Claude Code。
這非常適合快速製作原型,若重視UI/UX則更是好選擇。此外,還能利用自訂命令和子代理。
不過就如開頭所提,在2025年9月上旬時,Claude Code的性能暫時下降。
未來可能會有改善的機會。
實際上,在性能下降之前,即使是大型開發也並未出現太大的問題,因此不必過於擔心。
另一方面,實務級的大型開發則適合使用Codex。
特別是在重視可維護性和錯誤處理的情況下,我們會建議採用Codex。
另外,若是在團隊開發且長期運作,Codex的設計將更為適合。
習慣使用ChatGPT的使用者也會更容易接受。
總結來說,現在使用任一個工具都可以!
這次Codex稍有優勢,但Claude Code的品質改善有可能使性能逆轉。
而且,隨著學習模型的更新,情況會隨時發生變化。
再者,性能方面也存在著不可見的社群差異。
目前,Claude Code的社群明顯更為發達,資訊量大且志願者製作的工具也在普及。
而最重要的是,我認為不應依賴單一工具,需根據情況靈活使用。
實際上,我現在同時使用Claude Code和Codex。
我將會在Qiita、X和YouTube上發佈最新的資訊,協助你保持跟上步伐。
在這次的驗證中,我們詳細比較了包括實作過程在內的40分鐘內容。
在YouTube影片中,我們還公開了以下內容:
想邊看實際畫面邊理解的朋友,請務必觀看影片。
許多人在這次驗證中發現了Codex的實力。
如果你希望真正活用Codex CLI,我們也提供了Udemy課程。
【Codex CLI/IDE】實踐級的應用開發來學習即時編碼!
在這個課程中,你會學到:
如想系統化學習,請查看這些內容。
另外,我們也出了一門Claude Code的課程,歡迎查看網站限定的優惠券。
在這次的驗證中,兩個工具的特性變得明確。
在代碼品質方面,Codex佔優,但在UI/UX方面,Claude Code表現更佳。然而重要的不是哪一個更優秀。
而是根據專案的性質和個人工作流程選擇使用。
如果是小規模且想快速製作可以考慮Claude Code;而若是大型且需要穩定性則可考慮Codex。靈活使用這兩者能最大化開發效率。
各位也試試這兩個工具,找到適合自己的使用方式吧!