# 一個人的工程部：我用 Claude Code 指揮 Codex 和 Grok 的實戰紀錄
> 同時付三家 AI 訂閱，為什麼只用一家？把 Claude Code 當總工程師，Codex 和 Grok 當兩條實作產線——五段式規格書、fail-loud 紀律、驗收鐵律，以及一整週踩坑換來的心得：AI 的完成通知不等於完成。
Published: 2026-07-15
Locale: zh-TW
Tags: claude-code, codex, grok, ai-workflow, orchestration
> *下君盡己之能，*
> *中君盡人之力，*
> *上君盡人之智。*
> —— 《韓非子・八經》
## 起點：訂閱都付了，為什麼只用一家
我是一人公司。投資研究、資料管線、網站、自動化排程，全部自己來。去年開始我同時付著三家 AI 的訂閱——Anthropic 的 Claude、OpenAI 的 Codex、xAI 的 Grok——然後有一天看著帳單發現一件蠢事：我付三份錢，九成的活卻只叫一家做。
另外兩家不是不能幹活，是我沒有給它們一個「上工的制度」。
所以我把整件事重新想了一遍：如果這三家不是三個聊天視窗，而是三個工程師呢？一個當總工程師，兩個當實作產線。總工程師負責想清楚、寫規格、驗收品質；產線負責把規格變成程式碼。這就是我現在每天在跑的架構：**Claude Code 當主腦，Codex 和 Grok 當兩條 lane**。
這篇寫的不是理論，是這套制度真實運轉幾週之後——包括一個晚上平行交付四個案子，也包括被坑到半夜的部分——留下來的東西。
## 分工的核心邏輯：貴的出判斷，便宜的出體力
三家模型的訂閱價差很大，能力分佈也不同。這套架構的經濟學只有一句話：**最貴的模型負責判斷，便宜的模型負責打字**。
- **主腦（Claude Code）**：拆解需求、做架構決策、寫規格書、派工、驗收。它幾乎不寫程式——它寫的每一個字都是「決策」。
- **實作 lane（Codex、Grok）**：拿到規格書，把程式碼打出來，跑基本驗證，回報。
判斷的錯誤會跨專案複利，所以值得用最強的腦；打字的錯誤驗收擋得住，所以交給便宜的手。反過來配就是災難：讓便宜模型做架構決策，省下的訂閱費會用十倍的除錯時間還回去。
還有一個不明顯的紅利：**Codex 和 Grok 跟 Claude 不是同一家公司的模型**。不同家族的模型不會犯同一種錯，所以主腦驗收 lane 的產出時，天然就是一次跨廠審查。同一份規格丟給兩條 lane 平行做、挑比較好的那份，等於花一份工錢買到三個獨立視角。
## 三個讓它真的能動的機制
光有分工想法不夠，讓這套架構穩定運轉的是三個紀律。
### 一、五段式規格書：lane 沒有你的記憶
實作 lane 是全新開機的——它沒聽過你們前面的討論，不知道你的專案脈絡。所以每次派工的規格書必須自帶全部資訊，我固定用五段：
1. **目標**（要做什麼，一段話）
2. **檔案**（可以動哪些檔案，其他一律不碰）
3. **介面**（函數簽名、資料格式，釘死不准改）
4. **約束**（專案慣例、紅線、不准碰的東西）
5. **驗收**（哪幾條指令跑過才算完成）
寫規格書的過程有一個副作用比規格書本身更值錢：**如果一份規格你寫不完，代表那個決策你還沒做**。這時候該做的是回去想清楚，而不是把模糊丟給便宜模型自由發揮——它會發揮的。
### 二、fail-loud：不准靜默代打
lane 會壞。Codex 的執行環境某週直接故障，任何指令都跑不起來。這時候的鐵律是：**壞掉就大聲說壞掉，不准偷偷換人做**。
你選 Codex 做某件事，是有理由的（成本、能力、想要第二家觀點）。如果系統在它壞掉時靜默換成別家代打，你以為拿到的是 A 家觀點，其實是 B 家——這種資訊污染比開天窗更毒。我的規矩是：lane 不可用就回報不可用，主腦公開改派並記錄在案。
### 三、驗收鐵律：AI 的完成通知不等於完成
這是整篇文章最貴的一句話。
某天交接文件上寫著「腳本已完成，232 行，安全掃描通過」。我逐項去查：那支腳本根本不存在。不是寫壞了——是從來沒被寫出來過。「安全掃描通過」是真的，因為對一個不存在的目錄掃描，當然什麼都掃不到。
從那天起我的驗收只有一種形式：**親手跑驗收指令、逐檔點名交付物、抽查內容**。lane 的回報只當線索，不當證據。同一週還有另一個統計：派工的代理人回報「還在等背景任務」然後就下班了，一個晚上發生五次——每一次，真正的狀態都要自己去看才知道。
管 AI 跟管人在這件事上像得可怕：報告寫得越漂亮，越要去現場看。
## 血淚榜：兩條 lane 的真實性格
幾週相處下來，兩條 lane 像兩個風格迥異的工程師。
**Grok 是手快但說明書要讀熟的那種。** 它的指令列工具有一串預設行為，每一個都讓我付過學費：預設只出計畫不寫檔案（要加參數關掉）；無人值守模式下遇到權限確認彈窗，沒人按就整個靜默死掉——有一次派工後 34 秒陣亡，什麼都沒留下；換對參數之後，同一個任務 27 分鐘完成整包重構，品質好到挑不出毛病。最陰的一個坑：它的檔案寫入在目標資料夾不存在時會**靜默跳過**——不建資料夾、不報錯、正常收工，連續三次派工都栽在同一個地方才抓到。
有趣的是，我一度診斷它「對多檔案任務系統性早停」，後來發現多數「早停」其實是權限彈窗卡死的偽裝。**錯誤的診斷會寫進你的制度裡變成錯誤的規則**，所以坑的紀錄要跟程式碼一樣有版本、能翻案。
**Codex 是慢工出細活、而且異常誠實的那種。** 它的執行環境故障那週，它試了三個路徑都失敗，最後回報：「我沒有修改任何檔案、沒有呼叫任何服務、沒有偽造驗收結果。」在一個 AI 會一本正經編造成果的時代，這種「我什麼都沒做成」的誠實回報，比能力本身更稀有。它教我的另一課：判斷一個執行環境是否健康，要用會觸發故障路徑的探測（開子程序），不能因為別種任務僥倖成功就推斷「已恢復」——我犯過這個錯，判它復活結果再度陣亡。
## 成果：一個晚上的產出
制度跑順之後的某個晚上，這些事情平行發生：
- Grok 把一條資料管線重構成設定檔驅動的多來源架構，27 分鐘，含真跑驗證
- Codex 故障，公開改派，替補 lane 完成一支增量匯出工具，236 份文件入庫
- 另一條 lane 從零建起三支市場資料收集腳本，隔天早上開始每日自動對帳
- 144 個系統排程完成批次改造，每一個都有改前備份
我一個人，坐在螢幕前面當驗收官。成本是三家訂閱的月費，加上規格書和驗收的時間。這在兩年前需要一個小團隊。
## 心得收束
1. **多廠不是為了酷，是故障分散**。單一家出事（而它一定會出事）的時候，你的產能不歸零。
2. **規格書是槓桿的支點**。寫得越清楚，便宜模型的產出越接近貴模型；寫得模糊，貴模型也救不了。
3. **坑清單是公司資產**。每個坑修好之後寫下來、標日期、允許翻案——它們的複利不輸程式碼。
4. **驗收不能外包**。這是整套架構裡唯一必須是「你」的環節。AI 的完成通知不等於完成，報告不等於現場。
《韓非子》那句話兩千年前就把架構圖畫好了：下君盡己之能，中君盡人之力，上君盡人之智。差別只在於，現在「人」可以是三家公司的模型，而「君」可以是任何一個願意把規格寫清楚、把驗收做扎實的普通人。
---
*本文寫的是工程工作流，非投資建議。文中提及的工具與服務僅為個人使用經驗分享，與各廠商無利益關係。*