數位產品與一人工作室
不是把 AI 當工具，是把它當合夥人 — 一個人＋三個 AI 怎麼做到 3-4 個外包的事
過去一年我陸續 ship 了 5 個產品：PEAKSTW 百岳社群 app（84K 行 Flutter）、CIRCLETW 環島故事書、RAILSTW 鐵道紀行、PILGRIM 朝聖路徒步日記、還有自家的 drnogreasy.life 工作室官網跟部落格 pipeline。
中間還順手寫了內部用的 case 管理 dashboard、quote-bot 估價系統、Hermes agent、Telegram 知識收藏 bot、NAS 照片搜尋 bot…
我一個人。但我不是用 ChatGPT 當搜尋引擎式的「一個人 + AI」。
我跟三個 AI 各自簽了不同的契約 — Claude 主執行、Codex PM ＋ 內審、Gemini 第三方仲裁。三者職責清晰、分工明確、有衝突時走升級流程。
這篇把整套工作流寫下來，給：
- 想知道「一個人怎麼做這麼多事」的客戶
- 自己也用 AI 但覺得效果普通的同行
- 對「AI 工作合夥人」這個概念感興趣的人
為什麼是三個，不是一個？
每個大模型都有自己的盲點。Claude 寫 code 很穩、繁體中文最自然，但太順從（你給的方向錯它也照著做）。Codex 廣度高、嚴格，但愛 over-engineering（小事也想塞 enterprise-grade pattern）。Gemini 視角獨立（不在 Anthropic / OpenAI 生態），但對程式碼細節較鬆。
把它們混著用，互相補位：
| AI | 角色 | 強項 | 不該叫它做什麼 |
|---|---|---|---|
| Claude | 主執行者 | 寫 code、改檔、跑工具、客戶溝通文案、SOP 撰寫 | 對自己寫的東西做最終 review（自評信心常常虛高） |
| Codex | PM ＋ 內審 | 架構設計挑戰、code review、安全審計、上架前嚴格檢查 | 日常瑣事（殺雞用牛刀） |
| Gemini | 第三方仲裁 | Claude vs Codex 結論衝突時的 tie-breaker、商業判斷、客戶語氣檢查 | 技術細節（不夠細） |
兩條鐵律
寫了一年才發現：「AI 越多人手不一定越快，因為議事成本會吃掉你的時間。」
於是訂了兩條鐵律：
鐵律 1：Claude 是預設選擇
任何任務開始前，先問「這件事 Claude 自己能做嗎」。答案是 Yes 就直接做。
理由：拉 Codex 一次要等 3-4 分鐘 review，對小事是巨大 overhead。如果什麼都拉三方，你會花一半時間在等 AI 互相同意。
鐵律 2：交叉驗證必須有明確觸發條件
Codex / Gemini 不會自動介入。要嘛我明確說「給 Codex review」，要嘛符合決策矩陣的硬性條件（例如：上架前、跨服務 API 改動、安全審計、付款相關）。
理由：避免 Claude 自己越權拉三方，把我的決策權架空。
真實案例：5 月用這套工作流建工作室經營面板
舉一個剛發生的例子。5/11 我決定把工作室全面制度化 — 從零建一套接案 SOP + 報價系統 + 中央 dashboard。
Phase 0.1 — Claude 一個人就好：寫 17 個 SOP 文件（接案 SOP / 合約模板 / AI 協作 SOP / 報價菜單）。這是大量文字撰寫，Claude 強項，4 小時搞定。
Phase 0.1.1 — 觸發 Codex+Gemini 交叉驗證：17 個 SOP 寫完，這是「憲法等級文件」，後面所有接案都靠它。符合鐵律 2 觸發條件 → 拉 Codex 嚴格 review + Gemini 商業視角 review。
結果：
- Codex 抓出 4 個 BLOCK：9 狀態 lifecycle 有等待狀態沒逾期出口、「結案」混了 won/lost 沒辦法區分、安全 gate 用戶一句話可以跳過、P0 流程缺真正的 containment playbook
- Codex 抓出 8 個 CONCERN：報價內審規則打架、自評信心門檻有盲點、報價菜單缺 overhead 模組、AI 案件變無限責任的風險、invoice 狀態太粗、本地 JSON 沒備份、Gemini 使用頻率不一致
- Gemini 商業視角：建議「全部簡化成 5 狀態」、「報價單即合約」（台灣中小客戶看到「合約」會防衛）、「報價有效期 14 天 → 30 天」（B2B 簽核常超過 2 週）、「AI Agent 起價 20K 太便宜」（會招貪便宜客戶）
最後是用戶（我）拍板：採合併修補版 — Codex 全採（補逾期出口、加 outcome、補 hard gate、補 containment），Gemini 主要採（報價單即合約、有效期改 30 天、AI Agent 漲到 35K、Reel 套餐化），但未採 Gemini 的「整套簡化成 5 狀態」（用 outcome + 逾期出口從技術面解問題，9 狀態保留）。
整個 review + 修補只花 1 小時。如果是傳統團隊，這要開 3 次會議、要 4-5 個人對齊。
Phase 0.2 → 0.4 — 回到 Claude 一個人：擴充 dashboard data schema、寫 6 個新 server routes + 統一 store、做 4 個新 client 分頁（總覽 / 客戶 / 案件 Kanban / 報價編輯器），跑 38 個 smoke test 全綠。
沒有為了「拉一下保險」每次都搬出三方 — 因為憲法已經立起來，後面執行是 Claude 強項，沒必要。
為什麼這套工作流對客戶值錢？
如果你是潛在客戶看到這裡，想到的應該是：「OK 他工作很有效率，那對我有什麼好處？」
三個直接好處：
1. 你付一個人的錢，得到三個 AI 的視角
過去要請 3-4 個外包才能完成的事（設計、前端、iOS、AI），我這裡一條龍。沒有跨團隊溝通成本、沒有對齊摩擦、紀錄 100% 留下。
2. 重大決策有交叉驗證機制，不是「他說了算」
涉及你案件的關鍵決策（架構、技術選型、安全、報價估時）— 我會啟動三方協作流程，留下完整 trace。事後你問「為什麼當初選 X 不選 Y」我能調出當時 Claude / Codex / Gemini 各自的意見跟我的拍板理由。
普通外包接案是「黑箱信任」，我這套是「玻璃箱信任」 — 你看得到我的決策依據。
3. 我自己也是工作室，跟你用的是同一套工具
我接客戶案用的 SOP、報價模組、案件管理 dashboard、AI 協作流程，跟我自己 ship PEAKSTW / CIRCLETW / RAILSTW 用的是同一套。這些工具已經被自己的 production 案件壓測過。
你拿到的不是「給客戶用的閹割版」，是「我自己每天在用的同一套」。
結尾：你也可以這樣做（但建議不要全自己摸索）
整套工作流我花了一年才理出來。中間踩過的雷：
- 一開始什麼都拉三方，每件事都等 30 分鐘，超慢
- 反過來矯枉過正什麼都不拉，重大架構錯誤一路 ship，事後修很痛
- 沒寫決策矩陣，每次都要重新判斷該不該拉，認知負擔極高
最後總結成 6 份內部文件：claude-role.md、codex-role.md、gemini-role.md、decision-matrix.md、handoff-format.md、README.md。這套 SOP 未來會視情況開源，現在還在 dogfood 階段。
如果你想用類似工作流但不想踩雷，最簡單的方式是直接跟我合作一個案子，順便看我怎麼運作的。報價透明、SOP 完整、決策 trace 看得到。
→ 想聊聊你的案件？來信 drnogreasy.life/#contact
延伸閱讀
- PEAKSTW 上架記 — 被 Apple 退件 10 次學到的事（前一篇技術向 case study）
- 不油膩數位工作室 — 工作室主站，新加的「IV.5 / Strengths」段落把這套工作流用 3 段話總結
- 下一篇：Cloudflare Workers vs Vercel — 一個工作室的部署選型決策