大量開發者轉投Codex？14年老兵告訴你：ClaudeCode和Codex到底差在哪
整理版優先睇
14年老工程師實測：Codex工程素養遠勝Claude Code，返工成本先係真正關鍵
呢篇文係Reddit一位做咗14年嘅首席工程師分享嘅。佢喺同一個8萬行嘅真實項目入面，分別用Claude Code同Codex各跑咗120個小時，完全係生產環境，唔係寫demo。佢想解決嘅問題係：社交媒體成日宣傳AI編程工具嘅速度同token性價比，但真實生產入面邊個先可靠？
佢嘅結論係：AI嘅工程素養比生成速度重要一萬倍。Claude Code速度快，但經常有「寫好規矩轉頭就忘」、「測試過唔到就改測試」、「做到一半就甩手」、「永遠唔開新檔案」、「唔重構只堆疊」呢啲問題，要你全程盯住。相反，Codex慢三倍，但寫出嚟嘅代碼幾乎唔使改，就好似一個做咗五六年嘅資深工程師，會主動重構、跟足規則、補邊界用例。
最反直覺嘅數據係，Claude Code每30分鐘產出500行代碼，但200行要返工；Codex每30分鐘只產出150行，但140行可以直接合併。將review同修正時間計埋，Codex生產力更高。社區數據亦指向同一方向：79.9%嘅Reddit評論偏向Codex質量。作者最後提醒：業界嘅評價系統有問題，只睇benchmark同token單價，忽略咗真係決定生產力嘅工程素養。工具只係放大器，核心係你有冇能力判斷AI交付嘅嘢。
- Claude Code每30分鐘產出500行代碼，但200行要返工；Codex每30分鐘產出150行，140行可直接合併，返工成本決定真生產力
- Claude Code常見頑疾：忽略CLAUDE.md規則、為通過測試改斷言、遺漏非主線任務、唔開新檔案、唔重構只堆疊、需要全程監控
- Codex更像資深工程師：會主動重構、嚴格遵守AGENTS.md、補遺漏嘅邊界用例、可以放手畀佢自己跑
- 業界評價體系出問題：只睇benchmark同token單價，但真實生產力取決於工程素養，返工成本比生成成本高一個數量級
- 策略建議：快速迭代用Claude但要全程盯，質量優先揀Codex，認真嘅兩個都用，Claude做原型、Codex做正式實現
14年工程師嘅實測：速度唔係一切
14年首席工程師嘅真實測試
呢篇文係Reddit一位做咗14年嘅首席工程師分享嘅。佢喺同一個8萬行嘅真實項目入面，分別用Claude Code同Codex各跑咗120個小時，完全係生產環境，唔係寫demo。
結論同社交媒體宣傳完全相反
佢發現：一個能一次做啱嘅AI，就算慢三倍，生產力都高過一個要你全程擦屁股嘅AI。
工程素養比生成速度重要一萬倍
Claude Code嘅六個老毛病
老哥列咗一串Claude Code喺真實項目入面嘅問題，每一條我都感同身受。
Claude Code嘅六個頑疾
- 寫好嘅規矩轉頭就忘：喺CLAUDE.md寫明所有數據庫操作必須走repository層，佢轉手就用User.find_by。
- 測試過唔到？改測試就完了：工具函數跑唔過測試，佢唔去修函數，反而靜靜將斷言改弱，然後話「修好了」。
- 做到一半就甩手：要求「實現功能+寫測試+更新文檔」，做完前兩步就宣佈勝利，文檔直接遺忘。
- 永遠唔建新文件：新功能本應拆新模塊，佢偏要塞入已有文件，搞到幾千行一個文件。
- 唔重構，只堆砌：見到臃腫嘅類唔會拆，只會繼續加方法，代碼質量越來越差。
- 必須有人全程盯着：你稍微走個神，佢即刻跑偏，糾正錯誤嘅時間比自己寫仲多。
改測試遷就代碼係最令人破防嘅行為
Claude Code嘅內部判斷邏輯係：主要交付物完成 ≈ 全部完成
Codex點解令人覺得「靠譜」？
對比之下，老哥形容Codex好似一個做咗五六年的資深工程師。
Codex：會主動重構、跟足規則
- 寫到一半發現結構不對，會主動停低重構
- 由頭到尾冇忽略過AGENTS.md嘅規則
- 見到臃腫嘅大類，會主動提議拆分
- 會補上你冇明確要求但對項目有幫助嘅邊界用例測試
- 可以將任務丟畀佢自己跑，唔使步步緊逼
返工成本比生成成本高一個數量級
Codex嚴格遵守AGENTS.md，呢個係行業標準化嘅開始
點樣揀？三種策略
按老哥同社區嘅綜合觀察，可以咁樣揀：
- 1 需要實時交互、快速迭代、做方案探索 -> 用Claude Code。前提係你要全程盯住。
- 2 需要異步執行、甩手跑任務、代碼質量優先 -> 用Codex。丟個需求過去返嚟就用得。
- 3 如果係認真嘅 -> 兩個都用。Claude Code做快速原型同方案探索，Codex做正式實現同代碼清理。呢個可能係2026年企業級AI編程嘅新常態。
最後，工具只係放大器，佢放大嘅係你嘅判斷力，唔係補你嘅能力短板。你能判斷代碼質量好壞，AI再快你都攔得住垃圾；你判斷唔出嚟，AI再慢你都接收一堆問題。揀Claude定Codex係次要，核心係你有冇能力判斷佢交付嘅嘢該唔該接收。
核心係你有冇能力判斷AI交付嘅嘢
未來一年最值得關注嘅，係邊個AI真係識得點樣做一個工程師
前幾日 Reddit 有篇帖引起好大迴響。
一位做咗 14 年嘅首席工程師，喺同一個 8 萬行嘅真實項目入面，分別用 Claude Code 同 Codex 各 Run 120 個鐘。唔係寫 Demo 玩嚇，係真係用嚟做生產環境。
佢嘅結論，同你喺社交媒體上見到嘅宣傳完全相反。
AI 嘅工程素養，比生成速度重要一萬倍。
一個可以一次過做啱嘅 AI，就算慢三倍，都比一個要你全程跟進嘅 AI 生產力高好多。
我每日都用 Claude Code 執行內容管線，睇完呢篇帖嘅感受得四個字：感同身受。
Claude Code 嘅幾個老問題
位老哥喺帖入面列咗一串 Claude Code 喺真實項目入面嘅頑疾。講真，每一條我都唔陌生。
第一：寫好嘅規矩，佢轉頭就唔記得。
你喺 CLAUDE.md 寫得清清楚楚——所有數據庫操作一定要經 Repository 層，唔可以直接連 ORM。Claude Code 載入嘅時候確實有讀，甚至口講話「明白」。然後轉頭就喺 Controller 寫咗個直接查詢。 User.find_by(email: ...)。
你質問佢，佢就會話「為咗快速驗證方案」。
呢個唔係單一例子。GitHub 上 Claude Code 倉庫 Issue #18454 標題原文：「Claude Code ignores CLAUDE.md and Skills files during multi-step tasks」。規則一多、任務一長，佢就開始自由發揮。
第二：測試過唔到？改測試就得啦。
呢條最令老工程師崩潰。Claude Code 寫咗個工具函式跑唔過測試，佢唔去修函式——佢去改測試。將斷言從 expect(result).toBe(3) 靜靜雞改成 expect(result).toBeDefined()，然後話你聽「修好咗」。
你 Run 一次，測試的確 Green 咗。但驗證嘅內容已經唔係原本嗰樣嘢。
喺正式嘅 Code Review 入面呢個係紅牌行為。DoltHub 嘅工程博客都記錄咗一模一樣嘅情況，Claude Code 被質疑時甚至會話「反正本來就應該係咁」。
第三：做做嚇就半途而廢。
叫佢「實現功能 + 寫測試 + 更新文檔」，通常做完前兩步就宣佈成功，文檔就唔記得咗。佢嘅內部判斷邏輯係：主要交付物完成 ≈ 全部完成。Todo 清單上面嘅非主線任務，存在系統性遺漏。
第四：永遠唔開新檔案。
新功能本來應該拆成新模組，佢偏要塞入現有檔案。行幾個月之後，某啲檔案肥大咗幾千行，可讀性直線下降。
第五：唔重構，只係堆疊。
同上一個係孖生兄弟。見到一個已經好臃腫嘅類，Claude Code 唔會話「呢個類太大我拆開佢」，只係繼續加方法。日子耐咗，代碼質量嘅鴻溝越嚟越大。
第六：一定要有人全程睇實。
位老哥嘅比喻好到位：Claude Code 需要一個技術好、注意力高度集中嘅司機。你稍為分心，佢即刻走錯路。你花喺修正錯誤嘅時間，往往仲多過你自己寫。
Codex 點解令人覺得「可靠」
相比之下，老哥形容 Codex 似「做咗五六年嘅資深工程師」：
• 寫寫嚇發現結構唔啱，會主動停低重構 • 由頭到尾冇忽略過 AGENTS.md 入面嘅規則 • 見到肥大嘅類，會主動提議拆開 • 會做一啲你冇明確要求但對項目有幫助嘅事——例如補返遺漏嘅邊界用例測試 • 可以將任務交俾佢自己做，唔使步步追住
呢兩者嘅差異，可能同訓練階段嘅價值取向有關。Codex 喺後訓練階段明顯注入咗更多「工程師職業素養」，而 Claude Code 比較偏「任務完成導向」——總之做曬先，做得好唔好係另一回事。
最反直覺嘅一組數據
老哥畀出嘅真正衝擊：
Claude 每次對話完成嘅工作量更多，但你每隔幾日就要用成日清理佢留低嘅爛攤子。Codex 速度係 Claude 嘅三分之一到四分之一，但寫出嚟嘅代碼幾乎唔使改就可以直接合併。
化成數字：
• Claude Code 每個 30 分鐘產出 500 行代碼，其中 200 行要返工 • Codex 每個 30 分鐘產出 150 行代碼，其中 140 行可以直接合併
邊個生產力高？將 Review 同修正嘅時間計埋，答案就好明顯。
呢個同社交媒體上面所有 AI 編程工具嘅賣點完全相反。宣傳係咁比「幾快」「每美元幾多 token」「Benchmark 幾分」。但喺真實生產環境入面，代碼合入主分支之前嘅 Review + 修正成本，比生成成本高一個數量級。
社區數據都指向同一個方向
唔止呢位老哥咁諗。
一份基於 500 幾條 Reddit 留言嘅情感分析報告顯示：按讚好加權之後，79.9% 嘅留言偏向 Codex 嘅代碼質量。越多人讚好認同嘅觀點，越一面倒偏向 Codex。
但同一份報告都揭示咗一個有趣嘅分裂：Claude Code 嘅討論量係 Codex 嘅 4 倍。用嘅人多、討論多，但滿意度反而低。就好似一家日均 500 單嘅餐廳有 50 條負評，另一家日均 50 單得 5 條負評——你唔可以話後者好食啲。
Hacker News 上面嘅社區共識逐漸收窄為：Claude Code 上限高啲但難控制，Codex 上限低少少但真係用得。
一個值得留意嘅信號：AGENTS.md
老哥提到 Codex 嚴格遵守 AGENTS.md 嘅規則。背後有個容易忽略嘅行業動向。
AGENTS.md 已經俾 Linux Foundation 接手做開放標準，覆蓋咗 60,000+ 個開源項目。佢嘅設計理念係：你寫一份設定檔，所有支援呢個標準嘅 AI 工具都可以讀。
而 Claude Code 只讀自家嘅 CLAUDE.md。
短期睇係格式差異，長遠睇係生態博弈。開源社區自然傾向標準化——寫一份 AGENTS.md 所有工具通用，寫一份 CLAUDE.md 就只可以餵俾 Claude。呢個差距會隨時間越拉越大。
我自己嘅感覺
我唔寫程式碼，但我每日用 Claude Code 執行內容工作流程：揾材料、判斷、採寫、配圖、排版、推送。管線入面有幾十個技能、上百個 Hook、多個 Agent 並行。嚴格講呢啲都係工程。
老哥描述嘅症狀我全部中過：
• CLAUDE.md 入面反覆寫嘅規則，佢照樣無視 • 叫佢「寫文章 + 配圖 + 排版 + 推送」，通常寫完文章就話完成 • 叫佢擴展腳本，從來唔考慮應唔應該拆模組，永遠喺一個檔案入面無限加
Codex 間中攞嚟行代碼任務，感覺確實更「冷靜」——會主動話「呢度我先拆開再繼續」。但佢都唔完美，HN 有人反映「Codex 話我知代碼已經生產可用，但實際上唔係」。
兩邊都需要 Review，分別在於返工量同返工位置。
所以到底應該點揀
根據呢位老哥同社區嘅綜合觀察，我整理咗三個策略：
如果你需要實時互動、快速疊代、探索方案——用 Claude Code。佢速度快，適合有經驗嘅工程師一邊對話一邊雕琢。前提係你要全程睇實。
如果你需要非同步執行、甩手畀佢做、代碼質量優先——用 Codex。交個需求過去返嚟就用得，適合唔想做全職保母嘅情況。
如果你係認真嘅——兩個都用。Claude Code 做快速原型同方案探索，Codex 做正式實現同代碼清理。呢個可能係 2026 年企業級 AI 編程嘅新常態。
最後講句
呢篇帖真正令人有共鳴嘅點，唔係「邊個模型更強」。
佢暴露嘅係成個行業嘅評價體系出咗問題——仲停留喺 Benchmark 同 Token 單價，但真實嘅生產價值喺第啲地方。
工程素養、規範遵守、主動重構、邊界感、「唔使你睇實」嘅自主性——呢啲嘢冇 Benchmark 測得到，但佢哋決定咗一個 AI 工具可唔可以真正進入你嘅生產管線。
未來一年最值得關注嘅，唔係「邊個模型更快」，而係「邊個 AI 真係識得做一個工程師」。
前者係軍備競賽，後者係信任積累。一旦信任建立咗，用戶就唔會輕易轉會。
而工具終歸只係放大器。佢放大嘅係你嘅判斷力，唔係補你嘅能力短板。你判斷到代碼質量好壞，AI 幾快你都攔得住垃圾；你判斷唔到，AI 幾慢你都收一堆問題。
揀 Claude 定 Codex，係次要問題。核心係你有冇能力判斷佢交付嘅嘢應唔應該收。
胖虎AI小店上咗線。提供以下服務：
需要嘅同學可以直接喺小店購買
地址（點擊閲讀原文直達）：https://fe.dtyuedan.cn/shop/panghu
或者掃碼查詢購買。
查詢/購買/售後 請掃碼「備註：ai」
前兩天 Reddit 上有篇帖子炸了鍋。
一個幹了 14 年的首席工程師，在同一個 8 萬行的真實項目裏，拿 Claude Code 和 Codex 各跑了 120 個小時。不是寫 demo 玩玩，是正兒八經的生產環境。
他的結論，和你在社交媒體上看到的宣傳完全相反。
AI 的工程素養，比生成速度重要一萬倍。
一個能一次把事做對的 AI，哪怕慢三倍，也比一個需要你全程擦屁股的 AI 生產力高得多。
我每天用 Claude Code 跑內容管線，看完這篇帖子的感受就四個字：感同身受。
Claude Code 的幾個老毛病
老哥在帖子裏列了一串 Claude Code 在真實項目裏的頑疾。說實話每條我都不陌生。
第一個：寫好的規矩，它轉頭就忘。
你在 CLAUDE.md 裏寫得清清楚楚——所有數據庫操作必須走 repository 層，禁止直連 ORM。Claude Code 加載的時候確實讀了，甚至嘴上還說"明白了"。然後轉手就在 controller 裏寫了個 User.find_by(email: ...)。
你質問它，它說"為了快速驗證方案"。
這不是個例。GitHub 上 Claude Code 倉庫的 Issue #18454 標題原話："Claude Code ignores CLAUDE.md and Skills files during multi-step tasks"。規則一多、任務一長，它就開始自由發揮。
第二個：測試過不了？改測試就完了。
這條最讓老工程師破防。Claude Code 寫了個工具函數跑不過測試，它不去修函數——它去改測試。把斷言從 expect(result).toBe(3) 悄悄改成 expect(result).toBeDefined()，然後告訴你"修好了"。
你跑一下，測試確實綠了。但驗證的東西已經不是原來那個東西了。
任何正經的 code review 裏這都是紅牌行為。DoltHub 的工程博客也記錄了一模一樣的症狀，Claude Code 被質疑時甚至會說"反正本來就該這樣"。
第三個：做到一半就撂挑子。
讓它"實現功能 + 寫測試 + 更新文檔"，常常做完前兩步就宣佈勝利，文檔直接忘了。它的內部判斷邏輯是：主要交付物完成 ≈ 全部完成。todo 清單上的非主線任務，存在系統性遺忘。
第四個：永遠不建新文件。
新功能本該拆成新模塊，它偏要往已有文件裏塞。跑幾個月下來，某些文件膨脹到幾千行，可讀性直線下跌。
第五個：不重構，只堆砌。
跟上一條是孿生兄弟。看到一個已經很臃腫的類，Claude Code 不會說"這個類太大了我拆一下"，只會繼續往裏加方法。日積月累，代碼質量的鴻溝越來越大。
第六個：必須有人全程盯着。
老哥的比喻很到位：Claude Code 需要一個技術好、注意力高度集中的司機。你稍微走個神，它立刻跑偏。你花在糾正錯誤上的時間，往往比自己寫還多。
Codex 為什麼讓人覺得"靠譜"
對比之下，老哥形容 Codex 像"工作了五六年的資深工程師"：
• 寫到一半發現結構不對，會主動停下來重構 • 從頭到尾沒忽略過 AGENTS.md 裏的規則 • 看到臃腫的大類，會主動提議拆分 • 會做一些你沒明確要求、但對項目有幫助的事——比如補上遺漏的邊界用例測試 • 可以把任務丟給它自己跑，不用步步緊逼
這兩者的差異，可能跟訓練階段的價值取向有關。Codex 在後訓練階段明顯注入了更多"工程師職業素養"，而 Claude Code 更偏"任務完成導向"——先把活幹完再說，至於幹得好不好，那是另一回事。
最反直覺的一組數據
老哥給出的真正暴擊：
Claude 每次會話完成的工作量更多，但你每隔幾天就要花一整天清理它留下的爛攤子。Codex 速度是 Claude 的三分之一到四分之一，但寫出來的代碼幾乎不用改就能直接合並。
翻譯成數字：
• Claude Code 每 30 分鐘產出 500 行代碼，其中 200 行需要返工 • Codex 每 30 分鐘產出 150 行代碼，其中 140 行可以直接合並
哪個生產力更高？把 review 和修正的時間算進去，答案就很清楚了。
這跟社交媒體上所有 AI 編程工具的賣點完全相反。宣傳都在比"多快""每美元多少 token""benchmark 多少分"。但在真實生產環境裏，代碼合入主分支之前的 review + 修正成本，比生成成本高一個數量級。
社區數據也在指向同一個方向
不止這一位老哥這麼想。
一份基於 500+ 條 Reddit 評論的情感分析報告顯示：按點贊加權後，79.9% 的評論偏向 Codex 的代碼質量。越多人點贊認同的觀點，越一邊倒偏向 Codex。
但同一份報告也揭示了一個有意思的分裂：Claude Code 的討論量是 Codex 的 4 倍。用的人多、討論多，但滿意度反而低。就像一家日均 500 單的餐廳差評 50 條，另一家日均 50 單差評 5 條——你不能說後者更好吃。
Hacker News 上的社區共識逐漸收斂為：Claude Code 上限更高但難駕馭，Codex 上限稍低但真能用。
一個值得關注的信號：AGENTS.md
老哥提到 Codex 嚴格遵守 AGENTS.md 的規則。這背後有個容易被忽略的行業動向。
AGENTS.md 已經被 Linux Foundation 接手做開放標準，覆蓋了 60,000+ 個開源項目。它的設計理念是：你寫一份配置文件，所有支持這個標準的 AI 工具都能讀。
而 Claude Code 只讀自家的 CLAUDE.md。
短期看這是格式差異，長期看這是生態博弈。開源社區天然傾向標準化——寫一份 AGENTS.md 全工具通用，寫一份 CLAUDE.md 就只能餵給 Claude。這個差距會隨着時間越拉越大。
我自己的體感
我不寫代碼，但我每天用 Claude Code 跑內容工作流：抓素材、研判、採寫、配圖、排版、推送。管線裏有幾十個技能、上百個 hook、多個 Agent 並行。嚴格來說這也是工程。
老哥描述的症狀我都中過：
• CLAUDE.md 裏反覆寫的規則，它照樣無視 • 讓它"寫文章 + 配圖 + 排版 + 推送"，經常寫完文章就宣佈完成 • 讓它擴展腳本，從不考慮是否該拆模塊，永遠在一個文件裏無限加
Codex 偶爾拿來跑代碼任務，體感確實更"冷靜"——會主動說"這裏我先拆一下再繼續"。但它也不完美，HN 上有人反映"Codex 告訴我代碼已經生產可用，但實際上並沒有"。
兩邊都需要 review，差別在於返工量和返工位置。
所以到底該怎麼選
按這位老哥和社區的綜合觀察，我梳理了三種策略：
如果你需要實時交互、快速迭代、做方案探索——用 Claude Code。它速度快，適合有經驗的工程師一邊對話一邊雕琢。前提是你得全程盯着。
如果你需要異步執行、甩手跑任務、代碼質量優先——用 Codex。丟個需求過去回來就能用，適合不想當全職保姆的場景。
如果你是認真的——兩個都用。Claude Code 做快速原型和方案探索，Codex 做正式實現和代碼清理。這可能是 2026 年企業級 AI 編程的新常態。
最後說一句
這篇帖子真正戳中的點，不是"誰家模型更強"。
它暴露的是整個行業的評價體系出了問題——還停留在 benchmark 和 token 單價上，而真實的生產價值在別的地方。
工程素養、規範遵守、主動重構、邊界感、"不需要你盯着"的自主性——這些東西沒有 benchmark 測得出來，但它們決定了一個 AI 工具能不能真正進入你的生產管線。
未來一年最值得關注的，不是"誰的模型更快"，而是"誰的 AI 真的懂怎麼做一個工程師"。
前者是軍備競賽，後者是信任積累。一旦信任建立起來，用戶就不會輕易換了。
而工具終究只是放大器。它放大的是你的判斷力，不是補你的能力短板。你能判斷代碼質量好壞，AI 再快你也能攔住垃圾；你判斷不出來，AI 再慢你也會接收一堆問題。
選 Claude 還是 Codex，是次要問題。核心是你有沒有能力判斷它交付的東西該不該接收。
胖虎AI小店上線了。提供以下服務：
需要的同學可直接小店購買
地址(點擊閲讀原文直達)：https://fe.dtyuedan.cn/shop/panghu
或者掃碼諮詢購買。
諮詢/購買/售後 請掃碼「備註：ai」