「好噁心喔！」——讓同事五分鐘內喊出這句話的 AI 工作流

同事看完我的 AI 工作流 demo，沉默兩秒後說「好噁心喔」。在台灣，這是最高級的讚美。而我只花了五分鐘。

「好噁心喔！」

這是我同事看完我的 AI 工作流 demo 後的第一句話。

在台灣，這是最高級的讚美。意思是：強到不講道理、厲害到讓人不舒服。

而我花了不到五分鐘。

前情提要：一個人的 AI 部門

我目前的狀態是「一條龍」——公司工程部排不進 AI PoC 的排程，所以我自己做。從需求分析、架構設計、寫 code、測試、部署，全部一個人。

聽起來很累？其實還好。因為我不是一個人，我有四個。

四位一體：不是工具，是團隊

我的日常工作流長這樣：

角色	AI	做什麼
總指揮	Claude	架構設計、任務拆解、跨檔案整合、最終產出
研究員	Gemini	技術調研、最新資料查詢、方案比較（附 citation）
實作者 / 審查員	Codex	寫 code、code review、第二意見、挑戰 Claude 的設計
決策者	我	最終拍板、方向修正、說「不對，重來」

這不是四個獨立的 chatbot。它們之間有分工、有挑戰、有交叉驗證。Claude 設計完架構，Codex 會來 challenge；Gemini 查完資料，Claude 會整合並標註哪些結論互相矛盾。

我的角色？我是產品經理，不是打字員。

五分鐘 Demo：同事的表情變化

場景：午休時間，同事問我最近在忙什麼。我打開終端機。

第一分鐘：「所以就是 ChatGPT？」

我開了 Claude Code（CLI 版本的 Claude），同事看到黑底白字的終端機，表情寫著「這有什麼了不起的」。

我打了一句話：「幫我規劃把 LINE Bot 從 VPS 遷移到 Mac mini 的架構。」

同事：「就是問 AI 問題嘛，這我也會。」

第二分鐘：「等等，它在幹嘛？」

Claude 開始動作了。但它不是直接回答——它先拆解任務，然後同時派出三個子任務：

一個 subagent 去掃描整個專案的檔案結構
Gemini 去查「2026 年 LINE Bot + LLM 最佳架構實踐」
Codex 去 review 我現有的架構，找出遷移風險

三個任務同時並行。終端機上三條進度在同步跑。

同事的表情從「這我也會」變成了「嗯？」

第三分鐘：「它們⋯在吵架？」

結果回來了。有趣的事情發生了：

Gemini 建議全部容器化，用 Docker Compose 管理
Codex 反對，指出 Gateway 需要瀏覽器做 OAuth，放 Docker 裡會很脆弱
Claude 整合兩邊意見，提出混合方案：Gateway 跑在 Host，其他服務放 Docker

同事：「等等，它們的結論不一樣？然後 Claude 在整合？」

我：「對，它們會互相挑戰。如果三個都說一樣的話，我反而會擔心。」

第四分鐘：「這比開會有效率⋯」

Claude 輸出了一份完整的遷移計畫：

6 個 phase 的 checklist
風險對策表（每個風險都標了來源——是 Codex 提出的還是 Gemini 查到的）
架構決策表（為什麼選這個方案、誰提議的、誰反對的）
技術參考（Gemini 附的 citation，可以直接點進去看原文）

同事開始往螢幕湊近。

第五分鐘：「好噁心喔！」

我說：「這整個過程，從我打那句話到現在，大概三分鐘。而且這不是一次性的——Claude 會把這份計畫存成文件，下次繼續的時候自動讀取。Codex 負責寫 code，Claude 負責 review；反過來也成立。」

同事沉默了兩秒，然後：

「好噁心喔！」

為什麼不用一個 AI 就好？

這是最常被問的問題。答案很簡單：因為一個人的團隊不叫團隊。

想像一個軟體專案，架構師、工程師、QA、PM 都是同一個人。他會犯什麼錯？

自己設計的架構，自己 review 的時候看不出問題
自己查的資料，自己不會去質疑來源
自己寫的 code，自己測試的時候傾向證明它是對的

AI 也一樣。單一模型的 echo chamber 效應很明顯——它傾向於支持自己的前一個回答。

四位一體解決的是認知多樣性的問題：

Claude 擅長架構思維和整合，但有時會過度設計
Codex 擅長實作和挑毛病，會把 Claude 的花俏設計打回現實
Gemini 擅長查最新資料並附上引用，填補模型知識的盲區
人類知道什麼是真正重要的，什麼只是技術上有趣

實際工作流長什麼樣？

不是每個任務都需要四位一體。我的判斷標準：

情境	用誰
改一行 config	Claude 自己來
寫一個新功能	Claude 設計 + Codex 寫 code + 互相 review
技術選型 / 架構決策	Gemini 調研 + Codex challenge + Claude 整合
系統遷移 / 大型重構	全員出動

關鍵原則：不是每個釘子都需要四把錘子。但當你面對的是一面牆，四把錘子同時敲確實比較快。

成本

這大概是第二常被問的問題。坦白說，三個 AI 服務的訂閱加起來不便宜。但換個角度想：

這等於請了一個 24 小時待命的架構師 + 一個 code reviewer + 一個研究助理，而且它們不用睡覺、不會請假、不會在 code review 時說「LGTM」然後什麼都沒看。

如果你是獨立開發者或小團隊負責人，這個 ROI 值得認真算一下。

踩過的坑

四位一體不是一開始就順利的。幾個教訓：

1. AI 之間會互相抄

早期我讓 Claude 問 Gemini 意見，Gemini 回答後 Claude 全盤接受。這跟只用一個 AI 沒有區別。

解法：明確要求 Codex「挑戰」而不是「補充」。prompt 裡寫死：「找出這個設計的三個潛在問題。」

2. 研究員會幻覺

AI 做技術調研時，偶爾會自信滿滿地給出錯誤資訊。解法是要求附 citation——有引用來源的答案可以直接點進去驗證，沒有引用的就當作「待確認」。Gemini 的 grounding 功能在這方面幫了大忙。

3. 人類才是瓶頸

四個 AI 同時產出的速度很快，快到我來不及消化。後來我學會了一件事：不是每個輸出都需要仔細讀。Claude 整合過的摘要看一遍，有疑問再展開細節就好。

4. 要有人喊停

AI 會一直做下去，做到完美為止。但「完美」不是目標，「能 demo」才是。我的口頭禪是：「夠了，先這樣。」

要怎麼開始？

不用一次到位。我的建議：

先用好一個：把 Claude Code 或 Cursor 用到熟，理解 AI coding 的節奏
加一個 reviewer：Claude 寫完的 code 丟給 Codex review（或反過來）
加研究能力：遇到技術選型問題，用 Gemini 查最新資料
建立 SOP：把分工、觸發條件、品質標準寫下來（我的寫在 CLAUDE.md 裡）

最重要的是：你要把自己定位成 PM，不是打字員。你的工作是定義問題、判斷方向、做最終決策。code 讓 AI 寫，review 讓 AI 互查，你負責說「對」或「不對」。

結語

我同事最後問了一個問題：「所以你一天的工作量，以前大概要多久？」

我想了想：「大概一個小團隊一週吧。」

他又沉默了兩秒。

「好噁心喔。」

是啊，我也覺得。

本文描述的工作流基於 Claude Code CLI + Codex CLI + Gemini + 各種 subagent 的實際日常使用。不是廣告，純粹是用了覺得爽所以想分享。