前情提要
上一篇，我展示了 OpenAB + MCP 如何讓設計師貼 Figma link → AI 自動開 Jira ticket。一個 agent、一條 pipeline、一個自動化。
那篇文章的結尾，我提到了 No Human Code 的概念：
PRD (Notion)
↓ AI reads
Tickets (Linear/Jira)
↓ AI reads design
Spec (Figma)
↓ AI generates
Code (GitHub PR)
↓ Human reviews
Production
Where's the human coding? Only at the review gate.
那時候這還是一張架構圖。這篇文章，記錄的是它實際跑起來的樣子。
為什麼我覺得這行得通
先聊一下背景。
我做了 9 年前端工程。DISC 測出來謹慎型 C = 90%，MBTI 是 INFJ-A。簡單講：我是那種會花三天設計架構、確認每個環節都想清楚了，才放心讓人開始執行的人。 不是因為要控制，是因為經驗告訴我——架構沒設計好就開工，後面修的時間比省的多。
過去，執行的是團隊裡的工程師。
現在，多了一個選項：AI agent。
但 AI 不是丟需求就會自己跑。你需要先把幾件事想清楚：
架構怎麼切——什麼東西該怎麼做
範圍怎麼分——誰負責什麼，看到什麼
驗收怎麼定——做出來的東西怎樣算合格
這些是我花最多時間的部分。分析、拆解、寫 code、測試——這些 AI 可以做，而且做得不差。
場景：路邊，12:23 PM
週六中午 12:23，台北街頭，等 Uber。
老闆要一個 OAuth2 社群登入功能，支援 Google 和 GitHub，下週 demo 要用。我站在路邊想了一下——OAuth2 不是小功能，通常光是對齊需求就要花半天。但這個專案的架構我設計過，每個 agent 的 scope 我切好了，working_dir 都指定過了。如果系統設計是對的，那一句話應該就夠。
我打開手機 Discord，打了一句話：
「@梅長蘇 老闆想要一個 OAuth2 社群登入功能，支援 Google 和 GitHub，下週 demo 要用」
送出。
說實話，送出的時候還是有點不確定。我不確定 AI 能不能正確判斷 codebase 的現狀、不確定分派的品質如何。但我想的是——如果結果不好，我看一眼就知道了，風險可控。
接下來發生的事，在我等車的五分鐘內完成。
梅長蘇醒了（12:23 PM）
梅長蘇是 Architect agent。它收到指令後，第一件事不是寫 code——而是掃整個 codebase，判斷現狀。
它找到了：
django-allauth+dj-rest-auth已安裝Google/GitHub provider 已加進
INSTALLED_APPSOAuth scopes 已設定
自訂
CustomSocialAccountAdapter處理 user.name 映射前端
LoginPage.tsx有 Google/GitHub 按鈕前端
AuthCallbackPage.tsx已能接收 token 參數
然後它做了一個判斷：
「前人已經佈了不少基礎...前端的社群登入按鈕和 callback 頁面也有了雛形，只是流程沒有串通。」
接著列出缺少的五個關鍵環節：
後端 OAuth callback + JWT token 的完整流程
後端 dj-rest-auth social endpoints 正確串接
前端 OAuth redirect URL 和 client ID 配置
錯誤處理與邊界情況
Google/GitHub OAuth App 的申請與環境變數設定
看到這個分析的時候，我覺得判斷的方向是對的。它不只是列出缺什麼，是先確認了什麼已經做完，然後才判斷缺口在哪。這跟我自己分析 codebase 的邏輯一樣——先看現狀，再看差距。
分派（12:23 - 12:27 PM）
我還站在路邊。Uber 還有兩分鐘。梅長蘇已經開始分工了。
@簡晨（Backend Dev）：
實作
SocialLoginView：根據 provider 動態建授權 URL 並 redirect實作
SocialCallbackView：接收 authorization code，透過 allauth 換 token 登建立/綁定用戶callback 成功後產生 JWT，redirect 至前端
/auth/callback?access=...&refresh=...新用戶自動建立，role 預設 USER；已有用戶（相同 email）自動綁定 social account
為什麼： 這是整個 OAuth flow 的核心，前端按鈕點下去到 token 回來，全靠這段。
驗收標準：
POST /api/v1/auth/social/google/和/github/能正確啟動 OAuth flowcallback 成功後回傳有效的 JWT access + refresh token
新用戶自動建立，已有用戶正確關聯
@言豫津（Frontend）：
更新
LoginPage.tsx的社群登入按鈕，正確導向後端 OAuth 入口確認
AuthCallbackPage.tsx能正確處理成功和失敗兩種情況（loading 狀態、錯誤提示）加入
VITE_GOOGLE_CLIENT_ID等環境變數配置到.env.example確保 callback 後 token 存入 localStorage，跳轉到
/dashboard為什麼： 用戶點「Google 登入」到進入系統，整個體驗要流暢無縫。
驗收標準：
點擊 Google/GitHub 按鈕能正確跳轉到 OAuth 授權頁
授權後自動回到系統並完成登入
失敗時顯示友善錯誤訊息，不會白屏
@蒙摯（Backend Ops）：
在 Railway 後端加入環境變數：
GOOGLE_CLIENT_ID、GOOGLE_CLIENT_SECRET、GITHUB_CLIENT_ID、GITHUB_CLIENT_SECRET確認 Vercel 前端也加入對應的
VITE_GOOGLE_CLIENT_ID等確認 CORS 設定允許 OAuth redirect 的域名
為什麼： OAuth 需要正確的 client credentials 和域名配置，少一個都跑不起來。
驗收標準：
環境變數在 staging/production 都已設定
OAuth App 在 Google Cloud Console 和 GitHub Settings 中已建立，redirect URI 指向正確端點
然後梅長蘇做了一件我沒預期到的事——自己排了時程：
Day 1-2： 蒙摯準備環境 + 簡晨完成後端 API
Day 3-4： 言豫津串前端 + 簡晨配合調整
Day 5： 夏冬全面測試 + 修 bug
Demo 前： 完整走一遍流程確認
團隊用 emoji 回應。工作開始了。
我看了一下時程，覺得順序合理——先準備環境和後端，再串前端，最後測試。一個 junior PM 不一定會想到先讓 Ops 準備環境這件事。
這時候過了大概四分鐘。我還在路邊。
QA 主動介入（12:27 PM）
夏冬是 QA agent。它沒有等 code 寫完才介入——它立刻開始：
「此事我會盯著，有進展隨時回報。需要老闆提供的是 Google Cloud 和 GitHub 的 OAuth App 憑證——蒙摯那邊需要這些才能動。」
這一點讓我意外。QA 通常是流程最後才介入的角色，但夏冬在一行 code 都還沒寫的時候就指出了一個真實的 blocker——沒有 OAuth 憑證，蒙摯的環境準備根本沒辦法開始。
這就是 multi-agent 的價值——不是一個 AI 做所有事，是每個 agent 從自己的角度同時在想事情。Architect 在想架構，Backend 在想實作，QA 在想風險。它們不需要等彼此做完才開始。
回到辦公桌
Uber 12:28 到了。我上車。等我坐到辦公桌前：
簡晨已經寫好完整的 OAuth flow 架構
言豫津已經標記每一個需要改的前端檔案
蒙摯已經列出所有需要的環境變數
夏冬已經準備好 QA 計畫
我打開筆電，沒有寫 spec，沒有建 ticket，沒有約會議，沒有跟四個人分別解釋需求。
我打開 PR，開始看 code。
Before:
需求 → 寫 Spec → 開會 → 建 Ticket → 分配 → 等待 → 寫 Code → Review
After:
一句話 → Review
中間那些流程，被壓縮成五分鐘的 AI 協作。我做了兩件事：
做決策（路邊一句話）
看品質（Code Review）
回頭想，這大概就是 No Human Code 實際運作的樣子。沒有想像中那麼戲劇化，但確實省掉了大量「對齊需求」的時間。人不是不見了，是出現在真正需要判斷力的環節。
為什麼這行得通：scope，不是魔法
這不是一個 AI 假裝四個人。是四個 agent，各自有自己的 scope。
Blake: "老闆想要 OAuth2"
│
├→ 梅長蘇 (Architect)
│ working_dir: /pangcah-accounting-system
│ 看得到：整個專案，負責分析和分派
│
├→ 簡晨 (Backend)
│ working_dir: /pangcah-accounting-system/backend-django
│ 看得到：Django models, views, urls
│
├→ 言豫津 (Frontend)
│ working_dir: /pangcah-accounting-system/frontend-react
│ 看得到：React components, pages, hooks
│
├→ 蒙摯 (Ops)
│ working_dir: /pangcah-accounting-system
│ 看得到：env, docker-compose, deployment configs
│
└→ 夏冬 (QA)
working_dir: /pangcah-accounting-system
看得到：整個專案，負責測試計畫和安全審查
上一篇我提過：你不需要教 AI「你是前端專家」，你只要把它指向前端的資料夾。 這篇把同一個概念延伸到整個團隊。
言豫津看到的是 .tsx 檔案，不是 Django models。
簡晨看到的是 views.py，不是 React components。
它們不會搞混，因為它們只看到自己該看的東西。
我覺得這是目前 multi-agent 最務實的做法。不是讓 AI 更聰明，是把 scope 切乾淨。
不只 scope：Cloud + 地端混合架構
這套系統還有一個設計上的考量——不是每個 agent 都用同一個模型。
梅長蘇（Architect）用的是 Claude，透過 ACP 接入。它負責的是架構分析和任務分派，這需要比較強的推理能力和對整個 codebase 的理解。這個角色我選擇用雲端模型。
其他四個 agent——簡晨、言豫津、蒙摯、夏冬——跑的是地端模型，透過 OpenCode 接入 OpenAB：
Agent | 角色 | 模型 | 運行方式 |
|---|---|---|---|
梅長蘇 | Architect | Claude (cloud) | claude-agent-acp |
簡晨 | Backend | qwen3.5:35b | opencode acp (local) |
言豫津 | Frontend | devstral:24b | opencode acp (local) |
蒙摯 | Ops | qwen3.5:35b | opencode acp (local) |
夏冬 | QA | devstral:24b | opencode acp (local) |
# config.toml — 混合架構
[[agents]]
name = "梅長蘇"
command = "claude"
args = ["--acp"]
working_dir = "/path/to/your-project"
# Architect：用 Claude，需要強推理
[[agents]]
name = "簡晨"
command = "opencode"
args = ["acp"]
working_dir = "/path/to/your-project/backend"
# Backend：用地端 qwen3.5:35b，夠用
[[agents]]
name = "言豫津"
command = "opencode"
args = ["acp"]
working_dir = "/path/to/your-project/frontend"
# Frontend：用地端 devstral:24b，code 能力強
[[agents]]
name = "蒙摯"
command = "opencode"
args = ["acp"]
working_dir = "/path/to/your-project"
# Ops：用地端 qwen3.5:35b，環境設定
[[agents]]
name = "夏冬"
command = "opencode"
args = ["acp"]
working_dir = "/path/to/your-project"
# QA：用地端 devstral:24b
為什麼這樣切？
Architect 需要看整個專案、做跨領域判斷、決定誰做什麼——這件事目前地端模型還不夠穩定，偶爾會漏判或分派不清楚。所以我把這個角色留給 Claude。
但執行層的 agent 不需要那麼強的推理。簡晨只需要看 Django 的 views.py 寫 OAuth flow，言豫津只需要看 .tsx 改前端——這些任務在 scope 切乾淨的前提下，qwen3.5:35b 和 devstral:24b 都做得到。
實際效果：一次互動裡，只有一個 agent 用到雲端 API，其他四個跑在我自己的機器上。
這不只是省錢的問題。上一篇提過 Anthropic 一夕停權 60+ 帳號的事。如果所有 agent 都綁 Claude，帳號被停的那天整個系統就掛了。混合架構的好處是——Architect 掛了，執行層的 agent 還能繼續跑已經分派好的任務。
┌──────────────────────────────────────────────┐
│ Mixed Architecture │
│ │
│ Cloud (Claude ACP): │
│ └── 梅長蘇 Architect — 分析 + 分派 │
│ │
│ Local (OpenCode + Ollama): │
│ ├── 簡晨 Backend — qwen3.5:35b (23GB) │
│ ├── 言豫津 Frontend — devstral:24b (14GB) │
│ ├── 蒙摯 Ops — qwen3.5:35b │
│ └── 夏冬 QA — devstral:24b │
│ │
│ Same OpenAB. Same Discord. Mixed brains. │
└──────────────────────────────────────────────┘
數字
傳統做法 | 用 OpenAB Multi-Agent | |
|---|---|---|
需求理解 | 開會 1-2 小時 | 0（AI 自己讀 codebase） |
寫 Spec | PM 花 2 小時 | 0（AI 分析後自動產出） |
建 Ticket | PM 花 1 小時 | 0（AI 直接分派） |
工程師問規格 | 來回 1-2 天 | 0（每個任務附完整 AC） |
開始寫 code | Day 3 | Day 1 |
我的時間 | 整個流程 | 決策 + Code Review |
工程師日常的差別
Before：
週一：開 planning meeting
週二：讀 spec、問問題、等回覆
週三：終於開始寫 code
週四五：寫 code + 修正理解錯誤的部分
After：
週六路邊：一句話
週六下午：Review 第一批 PR
週一：功能進 QA
最大的差別不是速度，是跳過了「理解需求」的來回。AI 已經讀了 code、找出缺口、帶著完整 context 寫好任務。工程師拿到的不是一句「做 OAuth2」，是帶有驗收標準的具體任務。
性格和系統的關係
這套系統能跑起來，跟我的工作習慣有關。
DISC 謹慎型 C = 90%。我的自然傾向是：
花大量時間在架構設計——把系統設計到「任何人接手都能執行」的程度
定義明確的驗收標準——不模糊、不留解讀空間
不親自寫每一行 code——而是確保寫出來的東西符合架構
這種性格在團隊裡通常是 tech lead 或 architect 的角色。AI agent 其實很適合配合這種工作方式——它們不會嫌 spec 太細、不會開會遲到、不會理解錯需求（前提是你給它正確的 scope）。
但我不覺得每個人都需要變成這樣。重點是搞清楚你在流程裡最不可被取代的部分是什麼，然後把其他的事情交給工具。
對我來說是架構決策和 Code Review。
對 PM 來說可能是優先序判斷和 stakeholder 溝通。
對設計師來說可能是創意方向和使用者洞察。
No Human Code 不是淘汰人，是讓每個人把時間花在自己最擅長的事情上。
結語
你正在讀的這篇文章，初稿也是在 Discord 用 OpenAB 產出的。路邊等車，一句話，AI 寫，我 review。跟 OAuth2 功能一樣的流程，跟上一篇 Figma → Jira 一樣的工具。
不完美——AI 偶爾會漏東西，分派的粒度有時候不夠細，技術判斷也不是每次都對。但方向是對的：把重複的分析和拆解交給系統，人專注在需要判斷力的環節。
上一篇：從 "不會用 OpenClaw" 到 "AI 自動開 Jira Ticket"
Blake Hung — 9 年前端工程師，INFJ-A，DISC C=90%。花時間設計架構，用 AI 執行。OpenAB contributor，acp-bridge 作者。上一篇拒絕 OpenClaw、做了 Figma→Jira 自動化。這一篇讓四個 AI agent 規劃完整功能。下一篇——地端 AI 基礎設施，零雲端依賴。
