2026 我不再自己寫 code，我管理兩位 AI 同事：Codex 當 PM，Claude 當主力工程師
這半年我越來越清楚一件事：所謂的 vibe coding，根本不是「把一句話丟給 AI，等它吐出程式碼」那麼簡單。
真正進入工作現場之後，你會發現問題不是「AI 會不會寫」，而是「誰來收斂需求、誰來施工、誰來審核、誰來負責最後上線」。
我最近把自己的工作流正式定下來了。不是讓一個 AI 從頭做到尾，而是把兩個 AI 當成不同職能的同事來合作：Codex 負責 PM、架構、風險與 review；Claude 負責主力 coding、UI/UX 與功能落地；我自己負責拍板方向、決定優先順序，以及最後是否進 production。
這篇文章能回答你的 5 個問題
- 為什麼一個 AI 從頭做到尾不夠用？什麼時候會開始卡住？
- Codex 跟 Claude 在這套工作流裡，各自負責什麼？
- 為什麼我不讓同一個 AI 同時當 PM、工程師、reviewer？
- 當 vibe coding 從「寫程式」變成「派工作」之後，創辦人到底在做什麼？
- 怎麼跟兩位 AI 同事說話？指令真的可以只剩幾個字嗎？
AI 協作真正需要設計的，不是 prompt，而是組織
以前很多人想像的 AI 寫程式，比較像這樣：我講一句需求，AI 直接幫我做完。這種方式不是不能用。如果你只是要快速做一個 demo、一個 landing page，或一個很小的功能，它甚至非常爽。
但我後來發現，當專案不是只做 30 分鐘，而是會跨天、跨任務、跨平台，甚至牽涉到上線與營運時，真正開始卡住的根本不是「程式寫不寫得出來」，而是誰來定義這輪到底要做什麼、誰來判斷這是功能擴張還是方向偏掉、誰來 review、誰來記錄 handoff，還有誰來擋 production。
我後來才意識到，AI 協作真正需要設計的，不是 prompt，而是組織。
我最後定下來的分工：Codex 當 PM，Claude 當主力工程師
在我現在的 workflow 裡，Codex 不是主力碼農。它比較像 PM 加技術架構，再加一點 reviewer 的角色。它負責先讀最新 handoff、把目前任務收斂成清楚的卡、判斷 scope、non-goals、風險與驗收條件，並在功能做完之後先看 bug、回歸與缺測，再決定可不可以往下走。
而 Claude 比較像真正下場施工的工程師。它負責按照這一輪的卡去落地、處理 UI / UX 和功能實作、把東西做出來，做完再更新 handoff，讓下一輪接得上。
這樣的分工，表面上看起來比較慢。因為它不是一句話叫一個 AI 從頭包到尾。但實際上，它讓我第一次覺得：這套東西可以連續工作，不是一次性表演。
為什麼我不讓 Claude 同時當 PM 跟 coder
先說結論：不是不行，而是我現在不想。Claude 很適合當主力 builder。它在寫 UI、補互動、做頁面、把模糊需求快速變成可以看的東西這件事上，真的很順。
問題是，當同一個 agent 同時負責理解需求、定義需求、落地需求、幫自己驗收需求，整個流程就很容易失去第二雙眼睛。它會很快，但也很容易把產品判斷偷偷埋進實作裡。你以為你只是在讓它寫 code，實際上它也順手替你做了一堆方向決策，而且很多時候你是事後才發現。
這不是 Claude 的問題，而是因為任何一個人同時當 PM、工程師、reviewer，本來就會有盲點。所以我現在更喜歡把這兩件事拆開：想清楚這輪要幹嘛，是 Codex 的工作；把東西做漂亮、做出來，是 Claude 的工作。
2026 的 vibe coding，正在從「寫程式」變成「派工作」
很多人還在討論 Claude 比較強還是 Codex 比較強、哪個模型寫前端比較好、哪個模型比較像資深工程師。但我覺得更像 2026 的問題其實是：你有沒有開始把 AI 當成不同角色來管理？
當你真的同時用兩個、三個 agent 工作，你會發現自己做的事情，已經不太像傳統意義上的「自己寫 code」了。你更像是在排優先順序、切模式、看 handoff、做拍板、控風險、管 review 節奏，以及決定什麼先進 production、什麼先不要。
換句話說，真正的改變不是 AI 取代人寫 code，而是人的工作開始從寫 code，移到管理一群會寫 code 的 AI。
我現在怎麼跟兩位 AI 同事說話
很好笑的是，最後真的有效的指令都變很短。我現在根本不需要每次重講一長串規則，只要說：進 PM、開工、審一下、上線檢查。
背後的 workflow 已經寫進 repo 裡。AGENTS.md、HANDOFF-LATEST.md、CCG-MAPPING.md 會定義誰做什麼。所以我不是每次重新教 AI 一遍，我是在叫它們切換角色。
常見問題
Q1：我只用一個 AI 工具，也需要學這套分工嗎？
如果你只是做 30 分鐘的 demo、單一 landing page 或小功能，一個 AI 從頭做到尾完全夠用。我自己也常常這樣跑短任務。但當專案開始跨天、跨任務、跨平台，甚至要進 production，你會發現卡住的不是「寫不寫得出來」，而是沒人收斂需求、沒人 review、沒人擋方向偏掉。那個時候，多一個職能的 agent 才有意義。
Q2：為什麼不能讓同一個 agent 同時當 PM、coder、reviewer？
會失去第二雙眼睛。同一個 agent 同時負責理解需求、定義需求、落地需求、驗收需求，它一定很快，但會把產品判斷悄悄埋進實作裡。你以為你只是在讓它寫 code，實際上它順手替你做了一堆方向決策，事後才發現方向已經偏掉。這不是 AI 的問題，是任何一個人同時當三個角色都會有的盲點。
Q3：怎麼開始一個 Codex + Claude 的協作工作流？
從寫一份 AGENTS.md 跟 HANDOFF-LATEST.md 開始。前者定義每個 agent 的角色、責任、不能跨越的界線；後者讓下一輪 agent 一進來就知道現在做到哪、為什麼這樣決定、下一步該幹嘛。等這兩份檔案穩定之後，你的指令會越變越短，因為背景知識都寫在檔案裡，不用每次重講。
下一步
先盤點你工作流裡的三個角色
你不用馬上加第二個 AI。先回頭看你最近一個跨天的專案：誰在做 PM（收斂需求、判斷 scope）、誰在做 coding（落地實作）、誰在做 review（擋 production）？如果這三個角色都是同一個 agent，或同一個你，那就是這套分工最能幫到你的起點。
所以如果你最近也開始同時用多個 AI，不妨不要只想誰最強。你可以先想另一個問題：如果它們都是你的員工，你會怎麼分工？
