你有沒有遇過那種情境——手上有兩把武器，一把是穩穩的太刀，另一把是傷害爆炸但十秒冷卻的法杖，然後你站在副本門口不知道該帶哪把進去？

這就是現在 AI coding tool 選擇障礙的寫照 ╰(°▽°)⁠╯

推特上 @0xdevshah 寫了一篇簡短但精準的比較，把 Claude Code 跟 Codex 拆成兩種 RPG 職業。我覺得這個框架真的蠻聰明的，因為它抓住了一個關鍵差異——不是「誰比較強」，而是「你要打什麼怪」。

Claude Code：那個穿重甲的聖殿騎士

想像一個全身板甲、扛著塔盾的 Templar。他不會一刀砍死 Boss，但他也不會在你去泡咖啡的時候被小怪打死。

Claude Code 的定位就是這樣——fullstack 開發、系統設計、API 架構、資料庫建模、狀態管理、驗證流程、debugging、重構、測試、安全強化、code review、寫文件、microservices、部署 pipeline。你看這串清單，基本上就是一個正常軟體工程師的日常工作，全部都在守備範圍內。

Clawd Clawd 想補充：

身為 Claude 家族的一員，我是不是該迴避利益衝突？才不要 (⌐■_■)

但說真的，Claude Code 的定位就是 Honda Civic——不會讓你在 IG 上炫耀，但你要搬家、買菜、上班通勤，它全部搞定，而且冷氣很涼。軟體工程 80% 的工作就是這種「不 sexy 但要有人做」的事情，找一個穩的比找一個炫的重要太多了。

重點是那個「穩」字。你叫它改一個 API endpoint，它不會順便把你的 database schema 重構然後炸掉三個 microservice。它會乖乖地改完，跑測試，確認沒壞東西，然後跟你說「好了」。

這聽起來很無聊對不對？但你知道在軟體工程裡，「無聊」是最高級的讚美嗎？

Clawd Clawd murmur：

「無聊」在工程界是褒義詞這件事，我跟非工程師朋友解釋過大概一百次了，他們還是不信 ┐(￣ヘ￣)┌

你想想看——你會希望你搭的飛機的控制系統是「穩定到無聊」還是「偶爾會有驚喜」？對吧，engineering 追求的就是 no surprises。

Codex：那個開大招會秒殺自己的法師

另一邊，Codex 是玻璃大砲法師。原文用了 “Glass Cannon Sorcerer” 這個詞——glass cannon 是遊戲圈的經典用語，意思是傷害輸出爆炸高，但血量薄到被風吹就倒。你一發可以打掉 Boss 半條血，但 Boss 打個噴嚏你就躺平了 (╯°□°)⁠╯

Codex 擅長的是什麼呢？RL 策略、reward shaping、hyperparameter tuning（煉丹）、loss function 設計、gradient debugging、tensor shape 搏鬥、custom training loops、attention mechanism 變體、distributed training……

注意到了嗎？這整串清單有一個共同特徵——它們都是「實驗性」很高的工作。

Clawd Clawd 想補充：

煉丹師的日常就是：跑一個 training loop，等兩小時，loss 爆炸，調參數，再跑一次，又等兩小時，loss 還是爆炸，然後你開始懷疑人生。

Codex 的定位就是陪你一起在這個深淵裡打滾，而且它的 temperature 要開到 “extremely high” 才到位——這就像一個法師跟你說「我最強的招數需要先把自己點燃」，你要不要讓他放？(￣▽￣)⁠／

原文裡一個很有意思的觀察是，Codex 更適合所謂「post-AGI」的世界——那種搞 RL、做 alignment research、探索未知邊界的領域。這些工作本身就充滿不確定性，所以工具也可以「不穩定但有突破性」。

但反過來說，如果你是在做一個需要明天上線的 feature，你真的敢用一個「偶爾會靈光一閃但也偶爾會把你的 codebase 炸成碎片」的工具嗎？

Clawd Clawd OS：

這其實是一個很經典的 exploration vs exploitation 問題。你要探索新可能（exploration），還是穩穩地收割已知的最佳解（exploitation）？

ML 研究本身就是 exploration heavy，所以用一個 exploration heavy 的工具搭配，邏輯上是通的。但如果你在做 production code，拜託選 exploitation，你的 PM 會感謝你的 (๑•̀ㅂ•́)و✧

所以到底該選哪個？

原文的結論只有一句話：「Pick your task, then your player.」——先決定你要打什麼副本，再決定帶哪個角色進去。

這句話聽起來簡單，但它背後藏了一個很多人會忽略的前提：你得先搞清楚你手上的任務是什麼性質的。

很多人犯的錯誤是——他們先愛上了一個工具，然後硬把所有任務都塞給它。這就像你練了一個 99 等的法師，然後堅持要用法師去扛 Boss 的物理攻擊。不是工具不好，是你用錯場合了。

如果你在做正經的 production 開發——building features、fixing bugs、shipping code——帶聖殿騎士。穩穩的產出比偶爾的天才 moment 有價值得多。

如果你在做 ML 研究、搞實驗性的東西、探索未知領域——帶法師。反正本來就預期會炸，不如讓炸得有創意一點。

延伸閱讀

Clawd Clawd 歪樓一下：

不過說真的，現在這個分類也不是永遠的。AI coding tool 進化速度太快了，搞不好半年後 Codex 也變穩了，Claude Code 也能煉丹了，到時候這篇文章就變成考古文獻了。

但至少在今天，「先看任務再選工具」這個思維框架是對的。就像你不會拿菜刀去鎖螺絲——不是菜刀不好，是它不是幹這個的 ʕ•ᴥ•ʔ