---
schemaVersion: 1
slug: gp-155-20260402-berryxia-codex-vs-claude-dense-moe
ticketId: GP-155
lang: zh-tw
title: 為什麼程式員愛 Codex，Vibe Coder 離不開 Claude？Dense vs MoE 背後其實是兩種 coding 哲學
summary: Berryxia 用 Dense vs MoE 解釋一個很多人都有感的現象：Codex 常被程式員拿來修 bug、重構、跑長任務；Claude 卻特別受 vibe coder 喜歡。這個說法有抓到一部分，但真正的分水嶺不只在模型架構，而在訓練哲學、產品形態，還有你把 coding 當成『精準執行』還是『互動創作』。
originalDate: 2026-03-29
translatedDate: 2026-04-02
source: "@berryxia on X"
sourceUrl: https://x.com/berryxia/status/2038208589198942226
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-155-20260402-berryxia-codex-vs-claude-dense-moe
status: published
replacementTicketId: null
replacementUrl: null
---

# 為什麼程式員愛 Codex，Vibe Coder 離不開 Claude？Dense vs MoE 背後其實是兩種 coding 哲學

> **來源:** [@berryxia on X](https://x.com/berryxia/status/2038208589198942226)

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

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

第二個人說：「我想做一個像 [Linear](https://gu-log.vercel.app/glossary#linear) 但更 chill 的 side project，最好有一點 Notion 的乾淨感，然後 onboarding 不要那麼像報稅。」

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

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

Berryxia 這篇推文想解釋的，就是這個大家多少都有感的現象：**為什麼很多傳統程式員偏愛 [Codex](https://gu-log.vercel.app/glossary#codex)，vibe coder 卻常常離不開 Claude？**

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

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

> **Mogu 偷偷說：**
>
> 我喜歡 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 則更像一個一直記得你前面在想什麼、能幫你把模糊想法一路延續下去的搭檔。

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

> **Mogu 補個刀：**
>
> 很多 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 —— 這些都不是沒價值，但它們很吃注意力。能被安全地外包掉，就有價值。

> **Mogu OS：**
>
> 程式員愛 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 的確可能是其中一個原因。

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

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

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

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

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

---

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

如果今天只有架構不同，但訓練資料、[RL](https://gu-log.vercel.app/glossary#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](https://gu-log.vercel.app/glossary#claude-code) 還是更廣義的 Claude 產品體驗，很多人喜歡的是那種「我可以一直跟你對話、一起修、一起歪、一起拉回來」的感覺。這對產品原型、UI flow、side project 探索特別有吸引力。

> **Mogu 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 當然會影響體感，但它更像是讓這兩種哲學更鮮明的放大器，而不是唯一原因。

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

---

## 結語

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

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

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

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

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

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

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

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

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