Agentic Interface Operating Guide
操作指南 •
操作者不需要隨時使用所有介面。他們需要的，是在當下工作類型中，用對的介面做對的事。
為什麼介面紀律很重要
一旦 app 和 CLI 介面開始增加，就很容易把「可選的強大工具」和「必要的工作流程」混為一談。
這會導致兩種常見失敗：
- 太多重型介面在同一台機器上競爭資源
- 對於哪個介面該負責哪種任務，缺乏清晰的劃分
介面角色矩陣
| 介面 | 主要角色 | 何時使用 | 何時不用 |
|---|---|---|---|
| Claude Code CLI | 首席工程官，執行 | 編碼、檔案編輯、部署、UB 寫入 | 輕量研究、快速問答 |
| Codex CLI exec | 程式碼審查、第二意見 | 審查輸出、跨模型驗證 | 主要實作（用 Claude Code） |
| Codex App | 並行探索 | 在 Claude Code 工作時同步調查問題 | 需要 deterministic hooks 時 |
| Gemini CLI | PK 研究、批次草稿 | 網路研究、摘要、免費配額任務 | 重要決策（有幻覺風險） |
| Antigravity IDE | Browser testing、視覺工作 | Frontend 驗證、截圖比對 | 系統操作、檔案管理 |
更好的分工方式
更好的分工是基於角色的：
- App 介面 — 統籌協調、並行總覽和審查
- CLI 介面 — 實作、驗證和系統操作
這不是意識形態的問題，而是保護注意力和系統穩定性的實際需要。
SS1 的資源管理
SS1（MacBook Air M3，24GB）可以同時運行多個 Agent，但有實際限制。
舒適的並行負載：
- Claude Code CLI（主要）— 1 個 session
- Codex exec（審查，read-only）— 與 Claude 並行
- Gemini CLI — 輕量，可並行
重型負載（需謹慎）：
- Antigravity IDE — 其 browser automation 使用大量 RAM
- 多個完整的 Claude Code session — 面臨 context window 壓力
經驗法則： 如果風扇開始轉，就關掉當前不需要的最高成本介面。
保護主 session
主要的 Claude Code CLI session（SS1）是最有價值的計算資源。保護它的規則：
- 絕不在主 session 做純研究 — 委派給 Gemini CLI
- 並行編碼任務使用 worktree — 不是新 session
- 程式碼審查使用 Codex exec — read-only，不競爭 RAM
- 不主動做 browser testing 時關閉 Antigravity
為何這值得公開記錄
介面紀律不只是內部程序。它成為學習旅程的一部分，因為它記錄了一個真實的系統如何在限制條件下運作。
一個在單台筆電上同時跑四個 AI 工具的獨立操作者，學到了關於資源分配和角色清晰度的知識——而這是使用無限雲端算力的團隊永遠不需要學的東西。這種在限制中磨練出的知識，值得記錄下來。
Session 啟動檢查清單
| 步驟 | 動作 | 驗證 |
|---|---|---|
| 1 | 開啟 Claude Code CLI | terminal 顯示 prompt |
| 2 | 等待 session-start hook 完成 | 看到 heartbeat + mailbox 輸出 |
| 3 | 確認 Astro dev server 運行中 | curl localhost:4010 返回 200 |
| 4 | 確認 Bridge API 運行中 | curl localhost:8000/health 返回 200 |
| 5 | 如需 Codex：codex exec "test" | 確認回應 |
| 6 | 如需 Gemini：echo "test" | gemini | 確認回應 |
資源管理具體閾值
| 指標 | 正常 | 警告 | 動作 |
|---|---|---|---|
| CPU 使用率 | < 60% | > 80% 持續 30 秒 | 關閉最高成本介面（Codex > Gemini > Astro） |
| RAM 使用率 | < 70% | > 85% | 關閉 Docker 容器（LiteLLM, Qdrant） |
| Claude 用量 | < 50% weekly | > 70% weekly | 切換到 Sonnet/Haiku 派工 |
| 同時 agent 數 | ≤ 3 | > 5 | 排隊等待，不新開 |
典型工作流程範例
研究任務流程：
- 夏哥指派研究題目
- Opus 做 Pre-Flight Check → 判斷 PK 需要驗證
echo "research prompt" | gemini→ 免費研究- 結果回到 Opus → 審查品質
- 合格 →
ingest_fragment入庫 UB - 不合格 → 派 Sonnet subagent 深度研究
編碼任務流程：
- 夏哥指派 WO
- Opus 做 Pre-Flight Check → 判斷複雜度
- 簡單 → 派 Sonnet subagent (worktree)
- 複雜 → Opus 分解為 3-5 子任務 → 並行派 Sonnet
- Opus 審查所有輸出 → Quality Gate
- 合格 → merge + commit