一個人頂一個開發團隊？用 OpenClaw 實現一套 AI 編排系統

作者：程序員安仔

日期：2026年2月25日下午4:38

來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點高亮

一個人頂一個團隊嘅關鍵：用OpenClaw搭建AI編排系統，將人從「盯代碼」升級到「盯系統」

整理版摘要

呢篇文講嘅係一個叫Elvis嘅外國開發者，佢分享自己一個月內用AI編排系統一個人提交94次代碼、30分鐘開7個PR嘅真實經驗。佢唔似一般人咁用Cursor或Claude Code直接寫代碼，而係先搭一個兩層系統：上層係Zoe（運行喺OpenClaw上面），負責管理任務、業務上下文同監控；下層係Codex、Claude Code呢啲Agent，專注寫代碼。

Elvis指出傳統AI編程嘅問題——上下文窗口係零和遊戲，一個AI好難同時理解業務需求同寫代碼。所以佢嘅方案係專業分工：Zoe裝業務上下文，將客戶需求翻譯成精確技術任務；執行層Agent只裝代碼上下文，唔使知客戶係邊個。成個工作流程有8步：客戶需求→Zoe拆解→開獨立worktree+tmux啟動Agent→每10分鐘監控→Agent自動開PR→三個AI審查→CI測試→人工合併。核心係Ralph Loop V2，Zoe會根據失敗原因調整提示詞，唔係固定重試。

Elvis仲提到，佢個系統會主動掃Sentry、會議記錄同Git日誌嚟揾嘢做。佢嘅選擇標準係：Codex主力處理後端邏輯，Claude Code做前端快修，Gemini負責UI設計。目前瓶頸係RAM，佢買咗Mac Studio M4 Max（128GB）解決。Elvis認為2026年會出現大量「一人百萬美元公司」，關鍵係構建遞歸自我改進嘅Agent系統。作者最後補充，呢篇文嘅啟示係流程設計決定上限，而唔係單一模…

結論：一個人靠AI編排系統可以達到傳統團隊嘅產出，上限取決於流程設計而非模型能力。
方法：兩層架構——Zoe（OpenClaw）做編排層管理業務上下文，Codex/Claude Code做執行層寫代碼，實現任務拆解同自動化閉環。
差異：傳統AI編程要人盯代碼，而Elvis嘅系統係「AI管理AI」，人只需管系統同埋做最終驗收。
啟發：上下文窗口一定要專業分工，編排層掌握業務知識，執行層專注代碼，避免互相爭奪資源。
可行動點：可以複製Elvis嘅配置（OpenClaw+Agent腳本+tmux監控），但要注意算力資源（RAM至少128GB）。

整理重點

背景與問題：一個人頂一個團隊？真相係流程設計

Elvis呢個外國開發者分享咗個事實：一個月內佢一個人提交94次代碼，單日最高開咗7個PR，全部係商務項目直接上線。而且佢話最忙嗰日仲要開3個客會，連編輯器都冇開過——代碼係AI寫嘅。

「大部分人用AI寫代碼係管理代碼」，要盯住AI改、手動提交測試，每日能處理嘅任務量取決於你盯到幾多個AI。

Elvis嘅做法完全唔同：佢唔管代碼，佢管AI。同樣一個人，系統化後嘅任務吞吐量會明顯拉開差距。

整理重點

兩層架構：編排層（Zoe）與執行層（Codex）

Elvis搭咗個兩層系統：第一層係編排層，有個AI助手叫Zoe，運行喺OpenClaw上面，負責管理其他AI；第二層係執行層，Codex、Claude Code呢啲Agent負責寫代碼。打個比方：Codex係工人，Zoe係工頭，Elvis自己係老闆。

「上下文窗口係零和遊戲」，如果一個AI同時塞業務背景同代碼，兩邊都做唔好。

所以Elvis嘅解決方案係專業分工：Zoe裝業務上下文（客戶係邊個、要乜、之前試過乜），Codex裝代碼上下文（項目結構、類型定義、測試文件）。Zoe將業務需求翻譯成精確技術任務，然後交畀Codex執行。

「上下文決定專業化分工，角色分工靠職責邊界，唔靠換模型」

Zoe（編排層）：裝客戶需求、會議記錄、失敗經驗，負責寫提示詞同分配任務。
Codex/Claude Code（執行層）：裝代碼庫結構、類型、測試，專注實現功能。
Elvis（人類層）：只做大方向決策同最終驗收，唔再盯死代碼。

整理重點

完整工作流：從客戶需求到自動合併嘅8個步驟

Elvis詳細講咗佢個系統點運作，總共有8步，將自動化閉環串曬。

1 客戶需求→Zoe理解並拆解：Elvis嘅會議記錄自動同步到Obsidian，Zoe直接讀到，然後生成詳細任務提示詞。
2 啟動Agent：Zoe開獨立Git分支、新建worktree文件夾，用tmux啟動Codex，確保任務互不幹擾。
3 監控循環：每10分鐘Zoe檢查tmux會話、PR狀態、CI結果，失敗最多重啟3次，只用腳本唔使AI。
4 Agent創建PR：Codex寫完代碼自動用gh pr create開PR，但Elvis要到第7步先收到通知。
5 自動化代碼審查：三個AI（Codex、Gemini、Claude Code）各自留評論，Codex最擅長揾邊界情況。
6 自動化測試：Lint、TypeScript檢查、單元測試、E2E、Playwright，UI改動必須附截圖否則CI唔通過。
7 人工審查：Elvis收Telegram通知，直接睇截圖同AI審查結果，5-10分鐘搞掂。
8 合併：PR合併，定時任務清理工作文件夾同記錄。

呢個流程令到Elvis可以同時開多個Agent做唔同任務，自己只需要做第7步嘅快速審查。

「Elvis定義嘅『做完』標準：PR已創建、CI通過、三個AI審查通過、有UI截圖」

啟動Agent嘅命令示例 bash

git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
cd ../feat-custom-templates && pnpm install
tmux new-session -d -s "codex-templates" \
 -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \
 "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

「如果Agent跑偏，可以用tmux send-keys即時修正，唔使殺掉成個Agent」

整理重點

核心系統：Ralph Loop V2 與主動排程

Elvis話佢個系統本質係Ralph Loop嘅升級版。傳統Ralph Loop每次循環用相同提示詞，但Elvis嘅Zoe會根據失敗原因調整。Agent上下文唔夠？「只關注呢三個文件。」Agent跑偏？「停，客戶要嘅係X唔係Y。」

「Zoe唔會用同樣提示詞重啟失敗Agent，而係用業務上下文解鎖佢」

而且Zoe會主動揾嘢做：早上掃Sentry發現錯誤就開Agent去修；開完會掃會議記錄啟動新功能Agent；夜晚掃Git日誌更新changelog。Elvis話：「我開完客會去散個步，返嚟睇Telegram：7個PR準備好審查。」

「Zoe會為每個任務選擇合適Agent：計費系統bug畀Codex，按鈕樣式修復畀Claude Code，新儀錶板設計從Gemini開始」

選Agent標準：Codex主力（90%任務），Claude Code更快適合前端，Gemini有設計感。

整理重點

瓶頸與展望：RAM同埋一人百萬美元公司

Elvis話而家最大瓶頸係RAM。每個Agent要獨立worktree、node_modules、編譯器，5個一齊跑16GB Mac Mini已經要swap。佢買咗Mac Studio M4 Max 128GB，3月到貨。

「系統跑通之後，瓶頸好快會從模型能力轉到算力資源」

佢預測2026年會出現大量「一人百萬美元公司」，槓桿在於構建遞歸自我改進嘅Agent系統。Agent可以處理工程、客戶支援、營運、營銷，人類專注方向同控制。

「下一代創業者唔會請10個人，而係用對嘅系統一個人做曬」

Elvis自己做緊Agentic PR，用Agent幫創業公司獲得媒體報道，唔使月費一萬美元。佢主張少炒作、多記錄真實構建過程。

最近睇到一篇文章，作者叫 Elvis，係個鬼佬。

佢分享咗一個好爆炸嘅事實：

一個月之內，佢一個人提交咗 94 次代碼（單日最高紀錄），30 分鐘內開咗 7 個 PR，而且啲代碼全部係真實嘅商業項目，直接上線俾客用。

仲癲嘅係，佢話自己個日最忙嘅時候，開咗 3 個客會議，編輯器未開過。

代碼邊個寫？AI 寫嘅。

1 月之前：只用 Claude Code/Codex | 1 月之後：OpenClaw 編排 Claude Code/Codex

但佢用嘅方法同大部份人唔同。

大部分人用 AI 寫代碼嘅方式

而家好多人用 Cursor、Codex、Claude Code 呢啲 AI 編程工具。

用法大致係咁：打開編輯器，同 AI 講「幫我寫個登入功能」，AI 寫完，你睇下啲 code，改下，提交。

呢個方法冇問題，但有個天花板：你仲係喺度「管理代碼」。

你要睇實 AI 寫，要 check 佢有冇走錯方向，要手動提交、測試、開 PR。一日可以處理嘅任務量，取決於你睇得幾多個 AI。

Elvis 嘅方法唔同。

佢唔理 code，佢管理 AI。

同樣 1 個人，系統化之後嘅任務吞吐量會明顯拉開差距

咩叫「管理 AI」？

Elvis 搭咗一個兩層系統：

第一層：編排層（Orchestrator）
佢有一個 AI 助手叫 Zoe，行喺 OpenClaw 上面。Zoe 嘅工作係「管理其他 AI」。

第二層：執行層（Agents）
Codex、Claude Code 呢啲 AI 編程工具，負責寫 code。

打個比喻：

Codex 同 Claude Code 就好似地盤嘅工人，專門做嘢（寫 code）。
Zoe 就好似工頭，負責分配任務、監督進度、檢查質量。
Elvis 自己就好似老闆，只理大方向同最終驗收。

工人唔需要知道成個項目嘅背景，只要知道「今日要砌呢幅牆」就得。工頭負責將老闆嘅需求翻譯成具體任務，分配俾工人，然後睇住佢哋做曬。

呢個就係「編排系統」嘅核心諗法。

點解要兩層？

Elvis 喺文章裏面解釋咗一個好關鍵嘅問題：上下文窗口係零和遊戲。

點解？

AI 嘅上下文窗口（Context Window）就好似一個背囊，容量有限。你要擺嘢入去，就要揀擺啲咩。

如果你將 code 塞滿，就冇位放業務背景。
如果你將客需求、會議記錄塞滿，就冇位放 code。

所以，一個 AI 好難同時做好「理解業務」同「寫 code」呢兩件事。

Elvis 嘅解決方案係：叫唔同嘅 AI 裝唔同嘅嘢。

Zoe（編排層）：裝嘅係業務上下文。客係邊個、佢哋要啲咩、之前做過啲咩、點解失敗、今次要點做。
Codex/Claude Code（執行層）：裝嘅係 code 上下文。項目結構、類型定義、測試文件、依賴關係。

Zoe 將業務需求翻譯成精確嘅技術任務，然後交俾 Codex 去執行。Codex 唔需要知客係邊個，只要知道「實現呢個 API，用呢個類型定義，測試文件喺呢度」就得。

呢個就係「專業化分工」。

上下文決定專業化分工，角色分工靠職責邊界，唔係靠換模型

完整工作流程（8 步）

Elvis 詳細講咗佢個系統點運作。我用口語翻譯下：

高層架構：OpenClaw 做編排層，管理多個 Codex/Claude Code Agent

第 1 步：客需求 → Zoe 理解同拆解

Elvis 同客開完會，客話想要一個新功能。

Elvis 唔使寫需求文檔，因為佢嘅會議記錄會自動同步到 Obsidian（一個筆記軟件）。Zoe 可以直接讀到啲記錄。

Elvis 同 Zoe 傾幾句，Zoe 就明：「哦，客想要一個模板系統，等佢哋可以保存同編輯現有配置。」

然後 Zoe 做三件事：

幫客充值（Zoe 有管理員權限，可以直接操作後台）
從生產數據庫拉客嘅現有配置（Zoe 有唯讀權限，可以睇數據但改唔到）
生成一個詳細嘅任務提示詞，然後啟動一個 Codex Agent

第 2 步：啟動 Agent

Zoe 會為每個任務創建一個獨立嘅工作環境：

創建一個新 Git 分支（例如 feat/custom-templates）
喺一個獨立嘅文件夾度行 Codex（叫 worktree，避免唔同任務互相干擾）
用 tmux（一個終端工具）啟動 Codex，咁就可以隨時睇進度


# 創建 worktree + 啓動 agent 
git worktree add ../feat-custom-templates -b feat/custom-templates origin/main 
cd ../feat-custom-templates && pnpm install 
tmux new-session -d -s "codex-templates" \ 
  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ 
  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

Agent 喺 tmux 會話中運行，通過腳本記錄完整嘅終端日誌。

啟動 Agent 嘅方式：


# Codex 
codex --model gpt-5.3-codex \ 
  -c "model_reasoning_effort=high" \ 
  --dangerously-bypass-approvals-and-sandbox \ 
  "Your prompt here" 
 
# Claude Code 
claude --model claude-opus-4.5 \ 
  --dangerously-skip-permissions \ 
  -p "Your prompt here"

Elvis 以前用 codex exec 或 claude -p，但最近改用 tmux。

tmux 嘅好處係可以任務中途重定向。Agent 走錯方向？唔使 kill 佢：


# 跑偏了： 
tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter 
 
# 需要更多上下文： 
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

每個任務都會被記錄喺 .clawdbot/active-tasks.json 裏：


{ 
  "id": "feat-custom-templates", 
  "tmuxSession": "codex-templates", 
  "agent": "codex", 
  "description": "Custom email templates for agency customer", 
  "repo": "medialyst", 
  "worktree": "feat-custom-templates", 
  "branch": "feat/custom-templates", 
  "startedAt": 1740268800000, 
  "status": "running", 
  "notifyOnComplete": true 
}

任務完成後，會更新 PR 編號同檢查狀態：


{ 
  "status": "done", 
  "pr": 341, 
  "completedAt": 1740275400000, 
  "checks": { 
    "prCreated": true, 
    "ciPassed": true, 
    "claudeReviewPassed": true, 
    "geminiReviewPassed": true 
  }, 
  "note": "All checks passed. Ready to merge." 
}

第 3 步：監控循環

Zoe 每 10 分鐘檢查一次所有正在運行嘅 Agent：

tmux 會話仲喺度？
PR 開咗未？
CI（自動化測試）過咗未？
如果失敗，要唔要重啟？（最多重啟 3 次）

監控腳本：


.clawdbot/check-agents.sh

呢個監控係「確定性」嘅，唔需要畀錢問 AI「你做曬未」。只要檢查文件、檢查 Git 狀態、檢查 CI 結果就得。

腳本做嘅嘢：

檢查 tmux 會話係咪生還
檢查追蹤分支上有冇打開嘅 PR
透過 gh cli 檢查 CI 狀態
如果 CI 失敗或者有嚴重審查反饋，自動重啟失敗嘅 Agent（最多 3 次）
只係喺需要人手介入嘅時候先發出警報

Elvis 唔使睇住終端，系統會喺需要人手介入嘅時候通知佢。

第 4 步：Agent 創建 PR

Codex 寫完 code，提交，推送，然後用 gh pr create --fill 指令自動開一個 Pull Request（代碼審查請求）。

但係呢個時候 Elvis 唔會收到通知，因為「開咗 PR」唔等於「做曬」。

Elvis 定義嘅「做完」標準係：

PR 已創建
分支已同步到主分支（冇衝突）
CI 通過（代碼檢查、類型檢查、單元測試、端到端測試）
Codex 審查通過
Claude Code 審查通過
Gemini 審查通過
如果有 UI 改動，一定要有截圖

由任務拆解到合併上線，呢 8 步將自動化閉環串埋一齊

第 5 步：自動化代碼審查

每個 PR 會俾三個 AI 模型審查：

Codex Reviewer：最叻揾邊界情況（edge cases）。可以發現邏輯錯誤、遺漏嘅錯誤處理、競態條件。誤報率好低。
Gemini Code Assist Reviewer：免費，而且有用。可以發現安全問題、擴展性問題。會俾具體嘅修復建議。
Claude Code Reviewer：基本冇用，太保守。成日建議「考慮加個 XXX」，大部份係過度設計。Elvis 只睇佢標記為「嚴重」嘅問題，但佢好少獨立發現嚴重問題。

三個 AI 會直接喺 PR 上面留評論。

第 6 步：自動化測試

CI 流水線會跑一堆測試：

代碼風格檢查（Lint）
TypeScript 類型檢查
單元測試
端到端測試（E2E）
Playwright 測試（喺一個同生產環境一模一樣嘅預覽環境度跑）

Elvis 仲加咗一條規則：如果 PR 改咗 UI，一定要喺 PR 描述入面附上截圖，如果唔係 CI 就唔通過。

咁樣佢審查嘅時候，直接睇截圖就知改咗啲咩，唔使撳入去睇預覽。

第 7 步：人手審查

而家 Elvis 收到 Telegram 通知：「PR #341 準備好審查。」

呢個時候：

CI 已經通過
三個 AI 審查員都批准咗
截圖顯示咗 UI 改動
所有邊界情況都喺審查評論入面記錄咗

Elvis 嘅審查只需要 5-10 分鐘。好多 PR 佢連 code 都唔睇，直接睇截圖就合併。

第 8 步：合併

PR 合併。每日有個定時任務會清理唔用嘅工作文件夾同任務記錄。

呢套系統嘅核心：Ralph Loop V2

Elvis 話佢個系統本質上係「Ralph Loop」嘅升級版。

Ralph Loop 係乜？

簡單講就係：拉取上下文 → 生成輸出 → 評估結果 → 保存經驗 → 下次做得更好。

但大部份 Ralph Loop 嘅實現有個問題：每次循環用嘅提示詞都一樣。雖然經驗會累積，但提示詞本身唔會變。

Elvis 嘅系統唔同。

當一個 Agent 失敗咗，Zoe 唔會用同一個提示詞重啟佢。Zoe 會睇失敗嘅原因，然後用業務上下文嚟「解鎖」佢：

Agent 上下文唔夠？「專注呢三個文件就得。」
Agent 走錯方向？「停。客要嘅係 X，唔係 Y。呢句係佢哋喺會議上講嘅原話。」
Agent 需要更多資訊？「呢封係客嘅電郵，呢度係佢哋公司做咩嘅。」

Zoe 會一直睇住 Agent，直到任務完成。佢有 Agent 冇嘅上下文：客歷史、會議記錄、之前試過啲咩、點解失敗。佢用呢啲上下文嚟寫更好嘅提示詞。

而且，Zoe 唔會等 Elvis 分配任務。佢會主動揾嘢做：

早上：掃描 Sentry（錯誤監控工具）→ 發現 4 個新錯誤 → 啟動 4 個 Agent 去調查同修復
開完會：掃描會議記錄 → 發現 3 個客提到嘅功能需求 → 啟動 3 個 Codex Agent
晚上：掃描 Git 日誌 → 啟動 Claude Code 去更新 changelog 同客文檔

Elvis 話：「我開完客會議去散個步，返嚟睇 Telegram：7 個 PR 準備好審查。3 個新功能，4 個 bug 修復。」

當 Agent 成功咗，呢個模式會被記錄低。「呢種提示詞結構適合計費功能。」「Codex 需要預先拎到類型定義。」「永遠要包含測試文件路徑。」

獎勵信號係：CI 通過、三個 code 審查通過、人手合併。任何失敗都會觸發循環。隨住時間，Zoe 寫嘅提示詞越嚟越好，因為佢記得咩可以上線。

選擇合適嘅 Agent

Elvis 話，唔係所有 AI 編程工具都一樣。佢嘅揀選標準係：

Codex：主力。後端邏輯、複雜 bug、多文件重構、任何需要跨 codebase 推理嘅任務。慢但徹底。90% 嘅任務用佢。
Claude Code：更快，更擅長前端工作。權限問題少，適合 Git 操作。（Elvis 以前用得多，但而家 Codex 5.3 更好更快）
Gemini：有唔同嘅超能力——設計感。做靚嘅 UI 時，Elvis 會叫 Gemini 先生成 HTML/CSS 規範，然後交俾 Claude Code 去實現到組件系統度。Gemini 設計，Claude 構建。

Zoe 會為每個任務揀合適嘅 Agent，並喺佢哋之間路由輸出。計費系統嘅 bug 俾 Codex。按鈕樣式修復俾 Claude Code。新嘅儀錶板設計由 Gemini 開始。

同一套編排層下，唔同任務路由俾唔同 Agent 先可以將效率拉到最盡

點樣搭建呢套系統？

Elvis 話：「將成篇文章複製到 OpenClaw，然後同佢講：『為我嘅 codebase 實現呢個 Agent 集羣設定。』」

OpenClaw 會讀取架構，創建腳本，設定目錄結構，配置定時監控。10 分鐘搞掂。

冇課程要賣俾你。

意外嘅瓶頸：記憶體

Elvis 話佢而家遇到嘅天花板係：RAM（記憶體）。

每個 Agent 需要自己嘅工作文件夾（worktree）。每個工作文件夾需要自己嘅 node_modules（依賴包）。每個 Agent 要跑構建、類型檢查、測試。

5 個 Agent 同時運行，即係 5 個並行嘅 TypeScript 編譯器、5 個測試運行器、5 套依賴載入到記憶體。

Elvis 嘅 Mac Mini 得 16GB 記憶體，跑 4-5 個 Agent 就開始用 swap（交換記憶體）——仲要祈禱佢哋唔好同時構建。

所以佢買咗一部 Mac Studio M4 Max，128GB 記憶體，3500 美金。3 月底到貨，佢會分享值唔值。

系統行得通之後，瓶頸好快會由模型能力轉到算力資源

下一步：一人百萬美元公司

Elvis 話，由 2026 年開始，我哋會見到大量「一人百萬美元公司」。

槓桿太大，只要你識得點樣構建「遞迴自我改進嘅 Agent」。

呢個就係未來嘅樣：一個 AI 編排器做你嘅延伸（好似 Zoe 對 Elvis），將工作委託俾專門嘅 Agent 去處理唔同業務功能。工程、客戶支援、營運、營銷。每個 Agent 專注佢擅長嘅嘢。你保持專注同完全控制。

下一代創業者唔會請 10 個人嚟做一個人用啱嘅系統就可以做嘅事。佢哋會咁樣構建——保持細規模，快速行動，每日發佈。

而家有太多 AI 產生嘅垃圾內容。太多關於 Agent 同「任務控制中心」嘅炒作，但冇構建任何真正有用嘅嘢。花巧嘅示範，冇實際好處。

Elvis 話佢想做相反嘅事：少炒作，多記錄構建真實業務嘅過程。真實嘅客、真實嘅收入、真實嘅提交到生產環境嘅 code，仲有真實嘅失敗。

佢做緊乜？Agentic PR——一間一人公司，挑戰企業級 PR 巨頭。用 Agent 幫助初創公司獲得媒體報道，唔需要每個月 1 萬美金嘅代理費。

我嘅看法

我睇呢篇嘅時候，有個細節我一直記住：佢一日可以開 7 個 PR，自己仲開緊客會議，編輯器都未打開。

呢個結果靠嘅係流程設計。單個模型勁唔勁當然重要，但決定上限嘅係流程。

大部分人仲係將 AI 當代碼助手：提需求、等輸出、人手睇改動、再手動提 PR。

Elvis 行嘅係另一條路：先將編排層搭起，再叫執行層各自做嘢。工具串成系統，系統就可以自己轉。

真正拉開差距嘅位係「AI 管理 AI」。code 寫唔寫到，只係最底層。任務點拆、上下文點配、失敗後點重試，呢啲先決定產能上限。

Zoe 唔寫一行 code，但佢決定邊個 Agent 應該上、幾時重啟、幾時通知 Elvis。佢仲揸住業務上下文，可以將客語言翻譯成執行任務，亦會將失敗經驗沉澱落嚟。

所以我更加看重呢篇嘅方法論：將人由「睇住 code」切換到「睇住系統」。

再睇佢俾出嚟嘅結果：真實客、真實收入、真實上線 code。呢個體系已經喺生產環境跑緊。

如果你係開發者，或者你做緊自己嘅產品，呢篇文章好值得反覆拆解。

唔好急住照搬配置。更值得學嘅係呢個諗法：叫 AI 管理 AI，叫自己管理 AI 管理者。

呢套諗法行得通，一人公司嘅上限會被重新定義。

如果你覺得呢篇拆解有幫助，歡迎關注、點讚、推薦。

之後我會繼續寫更多 AI 工程化嘅實戰案例。

順便一提，我最近花咗半年時間，將自己用 AI 做全棧開發嘅經驗整理咗一本書——《人人都是 AI 程序員：TRAE+Cursor 從 0 到 1 全棧實戰》。

專門寫俾有想法但唔識技術嘅朋友。

書入面唔講複雜嘅 code，就教你好似導演咁同 AI 協作，用幾乎零成本嘅工具，喺一個下晝就可以做出你嘅第一個應用。

如果你都想試嚇喺 AI 時代做創造者，可以睇下呢本書：

最近看到一篇文章，作者叫 Elvis，是個老外。

他分享了一個很炸裂的事實：

一個月內，他一個人提交了 94 次代碼（單日最高），30 分鐘內開了 7 個 PR，而且這些代碼都是真實的商業項目，直接上線給客戶用的。

更離譜的是，他說自己那天最忙的時候，開了 3 個客戶會議，編輯器都沒打開過。

代碼誰寫的？AI 寫的。

1 月之前：只用 Claude Code/Codex | 1 月之後：OpenClaw 編排 Claude Code/Codex

但他用的方式跟大部分人不一樣。

大部分人用 AI 寫代碼的方式

現在很多人用 Cursor、Codex、Claude Code 這些 AI 編程工具。

用法基本是這樣：打開編輯器，告訴 AI「幫我寫個登錄功能」，AI 寫完了，你看看代碼，改改，提交。

這個方式沒問題，但有個天花板：你還是在「管理代碼」。

你要盯着 AI 寫，要檢查它有沒有跑偏，要手動提交、測試、開 PR。一天能處理的任務量，取決於你能盯多少個 AI。

Elvis 的方式不一樣。

他不管代碼，他管 AI。

同樣 1 個人，系統化後的任務吞吐量會明顯拉開差距

什麼叫「管 AI」？

Elvis 搭了一個兩層系統：

第一層：編排層（Orchestrator）
他有一個 AI 助手叫 Zoe，運行在 OpenClaw 上。Zoe 的工作是「管理其他 AI」。

第二層：執行層（Agents）
Codex、Claude Code 這些 AI 編程工具，負責寫代碼。

打個比方：

Codex 和 Claude Code 就像工地上的工人，專門幹活（寫代碼）。
Zoe 就像工頭，負責分配任務、監督進度、檢查質量。
Elvis 自己就像老闆，只管大方向和最終驗收。

工人不需要知道整個項目的背景，只要知道「今天要砌這面牆」就行。工頭負責把老闆的需求翻譯成具體任務，分配給工人，然後盯着他們幹完。

這就是「編排系統」的核心思路。

為什麼需要兩層？

Elvis 在文章裏解釋了一個很關鍵的問題：上下文窗口是零和遊戲。

什麼意思？

AI 的上下文窗口（Context Window）就像一個揹包，容量有限。你要往裏面塞東西，就得選擇塞什麼。

如果你把代碼塞滿了，就沒地方放業務背景了。
如果你把客戶需求、會議記錄塞滿了，就沒地方放代碼了。

所以，一個 AI 很難同時做好「理解業務」和「寫代碼」這兩件事。

Elvis 的解決方案是：讓不同的 AI 裝不同的東西。

Zoe（編排層）：裝的是業務上下文。客戶是誰、他們要什麼、之前做過什麼、為什麼失敗了、這次要怎麼做。
Codex/Claude Code（執行層）：裝的是代碼上下文。項目結構、類型定義、測試文件、依賴關係。

Zoe 把業務需求翻譯成精確的技術任務，然後交給 Codex 去執行。Codex 不需要知道客戶是誰，只要知道「實現這個 API，用這個類型定義，測試文件在這裏」就行。

這就是「專業化分工」。

上下文決定專業化分工，角色分工靠職責邊界，不靠換模型

完整工作流程（8 步）

Elvis 詳細講了他的系統是怎麼運作的。我用大白話翻譯一下：

高層架構：OpenClaw 作為編排層，管理多個 Codex/Claude Code Agent

第 1 步：客戶需求 → Zoe 理解並拆解

Elvis 跟客戶開完會，客戶說想要一個新功能。

Elvis 不用寫需求文檔，因為他的會議記錄會自動同步到 Obsidian（一個筆記軟件）。Zoe 能直接讀到這些記錄。

Elvis 跟 Zoe 聊幾句，Zoe 就明白了：「哦，客戶想要一個模板系統，讓他們能保存和編輯現有配置。」

然後 Zoe 做三件事：

給客戶充值（Zoe 有管理員權限，能直接操作後台）
從生產數據庫拉取客戶的現有配置（Zoe 有隻讀權限，能看數據但不能改）
生成一個詳細的任務提示詞，然後啓動一個 Codex Agent

第 2 步：啓動 Agent

Zoe 會給每個任務創建一個獨立的工作環境：

創建一個新的 Git 分支（比如 feat/custom-templates）
在一個獨立的文件夾裏運行 Codex（叫 worktree，避免不同任務互相干擾）
用 tmux（一個終端工具）啓動 Codex，這樣可以隨時查看進度


# 創建 worktree + 啓動 agent 
git worktree add ../feat-custom-templates -b feat/custom-templates origin/main 
cd ../feat-custom-templates && pnpm install 
tmux new-session -d -s "codex-templates" \ 
  -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ 
  "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"

Agent 在 tmux 會話中運行，通過腳本記錄完整的終端日誌。

啓動 Agent 的方式：


# Codex 
codex --model gpt-5.3-codex \ 
  -c "model_reasoning_effort=high" \ 
  --dangerously-bypass-approvals-and-sandbox \ 
  "Your prompt here" 
 
# Claude Code 
claude --model claude-opus-4.5 \ 
  --dangerously-skip-permissions \ 
  -p "Your prompt here"

Elvis 以前用 codex exec 或 claude -p，但最近改用 tmux 了。

tmux 的好處是可以任務中途重定向。Agent 跑偏了？不用殺掉它：


# 跑偏了： 
tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter 
 
# 需要更多上下文： 
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

每個任務都會被記錄在 .clawdbot/active-tasks.json 裏：


{ 
  "id": "feat-custom-templates", 
  "tmuxSession": "codex-templates", 
  "agent": "codex", 
  "description": "Custom email templates for agency customer", 
  "repo": "medialyst", 
  "worktree": "feat-custom-templates", 
  "branch": "feat/custom-templates", 
  "startedAt": 1740268800000, 
  "status": "running", 
  "notifyOnComplete": true 
}

任務完成後，會更新 PR 編號和檢查狀態：


{ 
  "status": "done", 
  "pr": 341, 
  "completedAt": 1740275400000, 
  "checks": { 
    "prCreated": true, 
    "ciPassed": true, 
    "claudeReviewPassed": true, 
    "geminiReviewPassed": true 
  }, 
  "note": "All checks passed. Ready to merge." 
}

第 3 步：監控循環

Zoe 每 10 分鐘檢查一次所有正在運行的 Agent：

tmux 會話還活着嗎？
PR 開了嗎？
CI（自動化測試）通過了嗎？
如果失敗了，要不要重啓？（最多重啓 3 次）

監控腳本：


.clawdbot/check-agents.sh

這個監控是「確定性」的，不需要花錢去問 AI「你幹完了嗎」。只要檢查文件、檢查 Git 狀態、檢查 CI 結果就行。

腳本做的事情：

檢查 tmux 會話是否存活
檢查跟蹤分支上是否有打開的 PR
通過 gh cli 檢查 CI 狀態
如果 CI 失敗或有嚴重審查反饋，自動重啓失敗的 Agent（最多 3 次）
只在需要人工介入時發出警報

Elvis 不用盯着終端，系統會在需要人工介入的時候通知他。

第 4 步：Agent 創建 PR

Codex 寫完代碼，提交，推送，然後用 gh pr create --fill 命令自動開一個 Pull Request（代碼審查請求）。

但這時候 Elvis 不會收到通知，因為「開了 PR」不等於「做完了」。

Elvis 定義的「做完」標準是：

PR 已創建
分支已同步到主分支（沒有衝突）
CI 通過（代碼檢查、類型檢查、單元測試、端到端測試）
Codex 審查通過
Claude Code 審查通過
Gemini 審查通過
如果有 UI 改動，必須包含截圖

從任務拆解到合併上線，這 8 步把自動化閉環串了起來

第 5 步：自動化代碼審查

每個 PR 會被三個 AI 模型審查：

Codex Reviewer：最擅長找邊界情況（edge cases）。能發現邏輯錯誤、缺少的錯誤處理、競態條件。誤報率很低。
Gemini Code Assist Reviewer：免費，而且很有用。能發現安全問題、擴展性問題。會給出具體的修復建議。
Claude Code Reviewer：基本沒用，太保守了。總是建議「考慮加個 XXX」，大部分是過度設計。Elvis 只看它標記為「嚴重」的問題，但它很少能獨立發現嚴重問題。

三個 AI 會直接在 PR 上留評論。

第 6 步：自動化測試

CI 流水線會跑一堆測試：

代碼風格檢查（Lint）
TypeScript 類型檢查
單元測試
端到端測試（E2E）
Playwright 測試（在一個跟生產環境一模一樣的預覽環境裏跑）

Elvis 還加了一個規則：如果 PR 改了 UI，必須在 PR 描述裏附上截圖，否則 CI 不通過。

這樣他審查的時候，直接看截圖就知道改了什麼，不用點進去看預覽。

第 7 步：人工審查

現在 Elvis 收到 Telegram 通知：「PR #341 準備好審查了。」

這時候：

CI 已經通過
三個 AI 審查員都批准了
截圖顯示了 UI 改動
所有邊界情況都在審查評論裏記錄了

Elvis 的審查只需要 5-10 分鐘。很多 PR 他連代碼都不看，直接看截圖就合併了。

第 8 步：合併

PR 合併。每天有個定時任務會清理掉不用的工作文件夾和任務記錄。

這套系統的核心：Ralph Loop V2

Elvis 說他的系統本質上是「Ralph Loop」的升級版。

Ralph Loop 是什麼？

簡單說就是：拉取上下文 → 生成輸出 → 評估結果 → 保存經驗 → 下次做得更好。

但大部分 Ralph Loop 的實現有個問題：每次循環用的提示詞都一樣。雖然經驗會積累，但提示詞本身不會變。

Elvis 的系統不一樣。

當一個 Agent 失敗了，Zoe 不會用同樣的提示詞重啓它。Zoe 會看失敗的原因，然後用業務上下文來「解鎖」它：

Agent 上下文不夠了？「只關注這三個文件。」
Agent 跑偏了？「停。客戶要的是 X，不是 Y。這是他們在會議上說的原話。」
Agent 需要更多信息？「這是客戶的郵件，這是他們公司做什麼的。」

Zoe 會一直盯着 Agent，直到任務完成。它有 Agent 沒有的上下文：客戶歷史、會議記錄、之前試過什麼、為什麼失敗了。它用這些上下文來寫更好的提示詞。

而且，Zoe 不會等 Elvis 分配任務。它會主動找活幹：

早上：掃描 Sentry（錯誤監控工具）→ 發現 4 個新錯誤 → 啓動 4 個 Agent 去調查和修復
開完會：掃描會議記錄 → 發現 3 個客戶提到的功能需求 → 啓動 3 個 Codex Agent
晚上：掃描 Git 日誌 → 啓動 Claude Code 去更新 changelog 和客戶文檔

Elvis 說：「我開完客戶會議去散個步，回來看 Telegram：7 個 PR 準備好審查了。3 個新功能，4 個 bug 修復。」

當 Agent 成功了，這個模式會被記錄下來。「這種提示詞結構適合計費功能。」「Codex 需要提前拿到類型定義。」「永遠要包含測試文件路徑。」

獎勵信號是：CI 通過、三個代碼審查通過、人工合併。任何失敗都會觸發循環。隨着時間推移，Zoe 寫的提示詞越來越好，因為它記得什麼能上線。

選擇合適的 Agent

Elvis 說，不是所有 AI 編程工具都一樣。他的選擇標準是：

Codex：主力。後端邏輯、複雜 bug、多文件重構、任何需要跨代碼庫推理的任務。慢但徹底。90% 的任務用它。
Claude Code：更快，更擅長前端工作。權限問題少，適合 Git 操作。（Elvis 以前用得多，但現在 Codex 5.3 更好更快了）
Gemini：有不同的超能力——設計感。做漂亮的 UI 時，Elvis 會讓 Gemini 先生成 HTML/CSS 規範，然後交給 Claude Code 去實現到組件系統裏。Gemini 設計，Claude 構建。

Zoe 會為每個任務選擇合適的 Agent，並在它們之間路由輸出。計費系統的 bug 給 Codex。按鈕樣式修復給 Claude Code。新的儀表盤設計從 Gemini 開始。

同一套編排層下，不同任務路由給不同 Agent 才能把效率拉滿

如何搭建這套系統？

Elvis 說：「把這整篇文章複製到 OpenClaw，然後告訴它：『為我的代碼庫實現這個 Agent 集羣設置。』」

OpenClaw 會讀取架構，創建腳本，設置目錄結構，配置定時監控。10 分鐘搞定。

沒有課程要賣給你。

意外的瓶頸：內存

Elvis 說他現在遇到的天花板是：RAM（內存）。

每個 Agent 需要自己的工作文件夾（worktree）。每個工作文件夾需要自己的 node_modules（依賴包）。每個 Agent 要跑構建、類型檢查、測試。

5 個 Agent 同時運行，意味着 5 個並行的 TypeScript 編譯器、5 個測試運行器、5 套依賴加載到內存裏。

Elvis 的 Mac Mini 只有 16GB 內存，跑 4-5 個 Agent 就開始用交換內存了（swap）——而且還得祈禱它們不要同時構建。

所以他買了一台 Mac Studio M4 Max，128GB 內存，3500 美元。3 月底到貨，他會分享值不值。

系統跑通之後，瓶頸很快會從模型能力轉到算力資源

下一步：一人百萬美元公司

Elvis 說，從 2026 年開始，我們會看到大量「一人百萬美元公司」。

槓桿太大了，只要你懂得如何構建「遞歸自我改進的 Agent」。

這就是未來的樣子：一個 AI 編排器作為你的延伸（就像 Zoe 對 Elvis），把工作委託給專門的 Agent 來處理不同的業務功能。工程、客戶支持、運營、營銷。每個 Agent 專注於它擅長的事。你保持專注和完全控制。

下一代創業者不會僱 10 個人來做一個人用對的系統就能做的事。他們會這樣構建——保持小規模，快速行動，每天發佈。

現在有太多 AI 生成的垃圾內容了。太多關於 Agent 和「任務控制中心」的炒作，但沒有構建任何真正有用的東西。花哨的演示，沒有實際好處。

Elvis 說他想做相反的事：少炒作，多記錄構建真實業務的過程。真實的客戶、真實的收入、真實的提交到生產環境的代碼，還有真實的失敗。

他在做什麼？Agentic PR——一個一人公司，挑戰企業級 PR 巨頭。用 Agent 幫助創業公司獲得媒體報道，不需要每月 1 萬美元的代理費。

我的看法

我看這篇的時候，有個細節我一直記着：他一天能開 7 個 PR，自己還在開客戶會，編輯器都沒打開。

這個結果靠的是流程設計。單個模型強不強當然重要，但決定上限的是流程。

大部分人還是把 AI 當代碼助手：提需求、等輸出、人工盯改動、再手動提 PR。

Elvis 走的是另一條路：先把編排層搭起來，再讓執行層各自幹活。工具被串成系統，系統就能自己轉。

真正拉開差距的點在「AI 管理 AI」。代碼能不能寫出來，只是最基礎的一層。任務怎麼拆、上下文怎麼配、失敗後怎麼重試，這些才決定產能上限。

Zoe 不寫一行代碼，但它決定哪個 Agent 該上、什麼時候重啓、什麼時候通知 Elvis。它還握着業務上下文，能把客戶語言翻成執行任務，也會把失敗經驗沉澱下來。

所以我更看重這篇裏的方法論：把人從「盯代碼」切到「盯系統」。

再看他給出的結果：真實客戶、真實收入、真實上線代碼。這個體系已經在生產環境跑起來了。

如果你是開發者，或者你在做自己的產品，這篇文章很值得反覆拆解。

別急着照搬配置。更值得學的是這個思路：讓 AI 管理 AI，讓自己管理 AI 管理者。

這套思路跑通了，一人公司的上限會被重新定義。

如果你覺得這篇拆解有幫助，歡迎關注、點贊、推薦。

後面我會繼續寫更多 AI 工程化的實戰案例。

對了，我最近花了半年時間，把自己用 AI 做全棧開發的經驗整理成了一本書——《人人都是 AI 程序員：TRAE+Cursor 從 0 到 1 全棧實戰》。

專門寫給那些有想法、但不懂技術的朋友。

書裏不講複雜的代碼，就教你像導演一樣與 AI 協作，用幾乎零成本的工具，在一個下午就能做出你的第一個應用。

如果你也想試試在 AI 時代當創造者，可以看看這本書：