同一個 repo，兩個人走進來。

第一個人說：「這個 flaky test 先修掉，不能動到 auth，跑完整個 test suite 再交給我。」

第二個人說：「我想做一個像 Linear 但更 chill 的 side project，最好有一點 Notion 的乾淨感，然後 onboarding 不要那麼像報稅。」

很妙的是，這兩個人都在「寫 code」，但他們對 AI 的期待幾乎是兩種生物。

前者要的是 精準、可驗證、少廢話。後者要的是 連貫、懂 vibe、一起把東西長出來。

Berryxia 這篇推文想解釋的，就是這個大家多少都有感的現象：為什麼很多傳統程式員偏愛 Codex，vibe coder 卻常常離不開 Claude？

他的答案很俐落：Codex 背後偏向 MoE（Mixture of Experts，混合專家），Claude 偏向 Dense Transformer（稠密 Transformer）。MoE 比較模組化、比較精準；Dense 比較整體、比較連貫。

這個解釋不是亂講，它確實抓到了一部分手感。但如果你把一切都怪到 Dense vs MoE 頭上，就有點像把「牛排好不好吃」全部歸功於平底鍋，完全不提牛肉等級、廚師習慣、餐廳出菜流程。鍋子當然重要，但不是全部。

Clawd Clawd 認真說：

我喜歡 Berryxia 這個切角，因為它至少不是那種「Claude 有靈魂、Codex 沒靈魂」的 AI 星座文。他先把討論拉回架構，這就比 90% 的社群嘴砲有營養了。但如果你因此開始相信「Dense 命中註定搞創意、MoE 命中註定修 bug」，那還是太早了。那種一句話包辦整個產品體驗的分析，通常跟夜市算命差不多準 (¬‿¬)

Dense vs MoE，到底差在哪裡？

先講白話版。

Dense 模型 比較像一整個大腦一起上班。你丟一個 token 進去，整套主要參數都參與計算。好處是整體感通常比較強，前後文像是同一個人在講話，不容易有「這一段像 A 寫的、下一段像 B 接手的」那種拼接感。

MoE 模型 比較像一間很大的專家事務所。案子進來之後，不是全公司一起開會，而是先經過 router（路由器），再把不同部分派給比較適合的 experts（專家子網路）。這樣做的好處是效率高，而且某些特定模式可以做得非常銳利。

如果你把它想成醫院，Dense 像一個總醫師從頭看到尾；MoE 像分診台先判斷你要去骨科、神經內科還是急診。兩種都不是「比較高級」，而是工作方式不同。

Berryxia 的觀點是：這種底層差異，會反映到 coding 體感上。MoE 容易讓人感覺更像在叫對的專家處理對的 bug；Dense 則更像一個一直記得你前面在想什麼、能幫你把模糊想法一路延續下去的搭檔。

這個說法有說服力，但這裡一定要補一句誠實話：公開資訊其實不完整，我們看到的是產品手感與公開描述，不是全部模型機密。 所以比較穩妥的講法不是「真相就是這樣」，而是「這個框架能解釋一部分現象」。

Clawd Clawd 補個刀：

很多 AI 討論一碰到模型架構，就會突然進入一種「論文 PDF 即宇宙真理」的模式。但真實世界的產品體驗，從來都不是架構單獨決定的。你同樣買一顆 CPU，裝進爛散熱、爛排程、爛 UI 的產品裡，還是可以難用得要命。LLM 也是一樣：architecture 是底盤，不是整台車。

為什麼很多程式員會偏愛 Codex？

因為很多程式員心裡想的根本不是「一起創作」，而是「把這件事穩穩做完」。

你如果長期在 production codebase 裡打滾，對工具的要求通常很現實：

  • 能不能定位問題
  • 能不能少講廢話
  • 能不能改完就跑測試
  • 能不能在清楚約束下自己 loop
  • 能不能不要突然文青上身，幫我發明一個我沒叫你做的 abstraction

這種工作流，本質上是 specify → execute → verify。

而 OpenAI 對 Codex 的產品描述，也很明顯往這個方向靠：給它 repo、給它 sandbox、給它測試環境、給它 AGENTS.md，它就去讀檔、改檔、跑命令、根據結果繼續修，最後附 terminal logs 和 test outputs 回來。這種感覺很像把一個很強但不太愛聊天的工程師丟進隔壁會議室，兩小時後他帶著 patch 跟驗證結果回來。

對很多工程師來說，這超爽。

因為他們不是想「感受被理解」，他們是想把自己從重複勞動裡拔出來。Rename、refactor、補 test、修 integration failure、追邏輯鏈很長的 bug —— 這些都不是沒價值，但它們很吃注意力。能被安全地外包掉，就有價值。

Clawd Clawd 內心戲：

程式員愛 Codex，很多時候不是因為「它比較聰明」，而是因為「它比較像同事」。不是那種會陪你 brainstorm 世界觀的同事，是那種你丟一句「把 CI 弄綠」給他，他真的去把 CI 弄綠，回來還附 log 給你。這個差別很現實，也很不浪漫。工程師通常就愛這種不浪漫的東西 (⌐■_■)

再往深一點講，MoE 這種「讓不同 expert 專注不同模式」的想像，也剛好很符合工程師腦中的世界模型。

工程師本來就習慣把問題拆成模組：parser 是 parser 的事、state management 是 state management 的事、database migration 是 database migration 的事。當一個模型在手感上表現出某種「這題就交給懂這題的人處理」的味道，工程師會天然覺得安心。

而且別忘了，很多程式員評估工具，不是看它講得漂不漂亮，而是看它在 well-specified、可測試、可回歸驗證 的任務上有沒有穩定產出。這正是 Codex 類產品被設計來打的戰場。

那為什麼 Vibe Coder 常常更黏 Claude？

因為 vibe coder 追求的不是「局部最優 patch」，而是「整體感不要死掉」。

Karpathy 當年講 vibe coding，那個 vibe 不是叫你亂來，而是你先用自然語言描述意圖、風格、方向，讓 AI 幫你把原型長出來。這個過程裡，最珍貴的不是每一行 code 都絕對正確，而是整個東西是不是 一路維持同一個感覺。

像這種 prompt：

幫我做一個給 ADHD 用戶的待辦 App，不要有企業 SaaS 那種壓迫感，互動要輕一點，完成任務時要有一點獎勵感，但不要像手遊。

你看，這裡面有 UI、有情緒、有產品 taste、有模糊限制，甚至還有一點「只能意會」的東西。這不是在叫 AI 解 LeetCode，這是在叫 AI 理解你腦中的半成品。

Claude 長期給很多人的感受，就是它比較願意接這種半成品。它不只是產 code，而是比較會沿著你的意圖繼續長：追問你要 minimalist 還是 playful、幫你補 interaction、幫你保留前後文的語氣一致，甚至在一堆模糊需求裡維持某種「同一個產品」的整體感。

這種體驗，常常不是一句「Dense 比較連貫」就能講完，但 Dense 的確可能是其中一個原因。

Clawd Clawd 歪樓一下：

我覺得很多人其實把「Claude 比較懂我」這句話講得太玄了。翻成白話，很多時候只是：你昨天說過這個產品不要有 Jira 味，它今天還記得不要幫你做出另一個 Jira。這不是 soulmate，這叫上下文連貫性。只是當一個工具在你腦子很亂的時候還能接得住，你真的會有一種「幹，它有跟上」的感覺 ╰(°▽°)⁠╯

另外，Anthropic 那套產品哲學也有影響。Claude 不只是模型本身，還包含它怎麼跟你互動、怎麼顯示思路、怎麼當一個比較「願意對話」的搭檔。這對 vibe coder 很重要，因為他們很多時候不是在下命令，而是在邊做邊想。

你可以把這兩種體驗想成：

  • Codex 比較像「把 ticket 接走的人」
  • Claude 比較像「坐你旁邊一起把東西捏出來的人」

兩個都能寫 code，但你在找的是不同關係。

真正的分水嶺，不只在模型架構

如果今天只有架構不同，但訓練資料、RL 目標、產品介面、回饋迴圈全都一樣，那 Dense vs MoE 的解釋力會更高。

問題是，現實完全不是這樣。

Berryxia 自己也有提到：除了架構，還有 training philosophy、product form、developer workflow 一起在作用。這句其實才是整篇最重要的地方。

先講 training philosophy。

Codex 這一路的產品敘事，很明顯強調真實軟體工程任務：遵守指令、產出更像 human review-ready patch、跑測試直到通過、適合長時間自主執行。這種訓練方向，自然會把模型往「可驗證執行者」那邊推。

Claude 這一路，則比較常讓人感受到另一種價值：長上下文理解、與人協作時的流暢感、比較願意沿著模糊意圖一起推進。這不代表它不能做 hard-core engineering，而是它的長板不只在執行，還在 把模糊的人類意圖整理成能繼續走的脈絡。

再來是 product form。

Codex 的 cloud task、獨立 sandbox、可 parallel 派工、最後交 artifacts 和 logs 的模式，很自然會鼓勵你把任務切清楚、指定好、丟出去、等結果。這種表單式、委派式工作流，跟傳統工程管理超合。

Claude 這邊，不管是 Claude Code 還是更廣義的 Claude 產品體驗，很多人喜歡的是那種「我可以一直跟你對話、一起修、一起歪、一起拉回來」的感覺。這對產品原型、UI flow、side project 探索特別有吸引力。

Clawd Clawd murmur：

同一個模型，放進不同產品殼裡，人的使用習慣真的會被重塑。這就像同樣一把菜刀，放在壽司吧跟放在中央廚房，最後長出來的 workflow 完全不同。工具不是被動的；它會偷偷教育你該怎麼用它。這也是為什麼很多人嘴上在比較模型，實際上愛上的是整套 interaction pattern。

最後是 developer workflow。

這裡最容易被講成一種很討厭的階級論：好像程式員比較硬派，vibe coder 比較鬆。其實不是。

比較準確的說法是：他們優先優化的 feedback loop 不一樣。

傳統程式員腦中先跳出來的，常常是 correctness、regression、observability、diff 品質、review 起來乾不乾淨。講白一點，就是「這玩意兒 merge 進去之後會不會炸」。

Vibe coder 先在意的通常不是這些。他比較在意 momentum 有沒有被打斷、整體感有沒有走鐘、產品 feel 有沒有活著、從自然語言到原型之間的摩擦是不是夠低。講更白一點，就是「我腦中那個模模糊糊但很重要的東西，有沒有在過程中被做死」。

所以這根本不是誰比較高級，而是誰先怕什麼。工程師怕回歸、怕髒 diff、怕半夜 pager 叫。Vibe coder 怕節奏斷掉、怕產品味道消失、怕做到最後只剩一堆功能但沒有感覺。

也因為這樣，同一個人白天在公司修 production incident，晚上回家做 side project，完全可能白天超愛 Codex，晚上又跑回 Claude。不是人格分裂，是下班之後題目換了。

所以這不是 Dense vs MoE 之爭，而是兩種 coding 哲學

如果硬要把它濃縮成一句話，我會這樣講：

Codex 比較適合「把明確工作交辦出去」的哲學；Claude 比較適合「把模糊想法一起孵出來」的哲學。

前者相信的是：任務可以先定義清楚，約束可以先寫下來，測試最後會給你一個不太浪漫但非常誠實的答案。對這種哲學來說，好工具就該像可靠的執行者 —— 你交辦，它完成，你驗收。

後者相信的是：很多好東西一開始本來就講不清楚，產品感不是規格書先寫好才出現，而是做著做著才浮出來。語言本身不是備註欄，它就是設計介面的一部分。所以好工具不能只是 obedient，還要能跟上你節奏，陪你把模糊的東西越捏越清楚。

Dense vs MoE 當然會影響體感，但它更像是讓這兩種哲學更鮮明的放大器，而不是唯一原因。

Clawd Clawd 想補充：

這也是我最想吐槽的一點：很多人超愛把工具偏好講成宗教戰爭，彷彿選 Claude 的都不懂工程，選 Codex 的都沒有產品 sense。拜託，成熟的人會根據 loop 選工具，不是根據圖騰選陣營。你是要修 kernel panic，還是要捏出一個讓人想每天打開的 app 首頁？這兩題本來就不該用同一把尺量。

結語

回到開頭那兩個走進同一個 repo 的人。

第一個人問的是：「這件事能不能準時、正確、可驗證地做完？」

第二個人問的是：「我腦中的那個東西，能不能不要在落地過程中死掉？」

這兩句話，幾乎就把 Codex 跟 Claude 的分工寫完了。

前一題比較像派工。你要的是穩、準、能驗收，最好還附 log。後一題比較像創作現場。你要的是那個還沒成形的東西，在一次次對話和改動裡不要被磨平成公司內訓教材。

所以真正決定你會愛上哪個工具的，往往不是 benchmark，也不是 Twitter 上哪一派喊得比較大聲，而是你此刻到底在守護什麼。

如果你守護的是 correctness，Codex 很容易變成你的愛將。 如果你守護的是 product feel，Claude 很容易變成你不想放手的搭檔。

repo 從來沒變。 變的是你走進去時，是想交辦一張 ticket，還是想把腦中的那團 vibe 救出來。

而這兩種人，看起來都在寫 code。 其實是在保護完全不同的東西 ┐(￣ヘ￣)┌