模組 4：精通 4 / 6
進階
Session 22 Human-in-the-Loop Approval
人機協作（Human-in-the-Loop）
設計確認流程、審批閘門和升級模式。
2026年3月20日 · 17 分鐘閱讀
你將學到什麼
不經監督就行動的 AI 代理是危險的。每一步都要求許可的 AI 代理則令人厭煩。最佳的人機協作設計位於兩者之間 — 它在正確的時機、以正確的資訊來讓人類介入。
完成後，你將了解：
- 自主性的光譜以及每種模式的適用場景
- 如何設計感覺自然的確認流程
- 審批閘門：AI 暫停等待人類決策的檢查點
- 當 AI 卡住時的升級模式
- 信任梯度：從嚴格開始，隨時間逐步開放
問題是什麼
考慮兩個極端：
極端 1：完全手動
使用者：「修復這個 bug」
AI：「我想讀取 auth.ts。可以嗎？」
使用者：「可以」
AI：「我看到 bug 了。可以編輯第 42 行嗎？」
使用者：「可以」
AI：「可以跑測試嗎？」
使用者：「可以」
→ 正確但累人。一個 30 秒的修復花了 10 分鐘。
極端 2：完全自主
使用者：「修復這個 bug」
AI：*讀取 50 個檔案、編輯 12 個、執行部署、推送到生產環境*
使用者：「等等，我不是這個意思--」
→ 快速但嚇人。一個錯誤的假設，你就在幫除錯工具除錯。真正的答案在兩者之間。但在哪裡？這取決於操作、風險和信任程度。
如何運作
自主性光譜
┌──────────────────────────────────────────────────────┐
│ 自主性光譜 │
│ │
│ 手動 引導式 半自動 完全自動 │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ 每個 先規劃， 讀取+搜尋 所有操作 │
│ 操作 確認後 自動執行， 無需提示 │
│ 需要 再執行 寫入時 即可運行 │
│ 批准 才提示 │
│ │
│ claude claude claude claude │
│ --plan (預設) (預設) --dangerously- │
│ skip-permissions │
│ │
│ ◄── 更多監督 更少監督 ──► │
│ ◄── 更多摩擦 更少摩擦 ──► │
│ ◄── 更低風險 更高風險 ──► │
└──────────────────────────────────────────────────────┘何時需要人類介入
並非所有操作都帶有相同的風險。關鍵是將監督程度與後果相匹配：
| 操作類型 | 可逆？ | 風險等級 | 方法 |
|---|---|---|---|
| 讀取檔案 | 是 | 無 | 自動允許 |
| 搜尋程式碼庫 | 是 | 無 | 自動允許 |
| 編輯本地檔案 | 是 (git) | 低 | 提示或允許 |
| 執行測試 | 是 | 低 | 以允許清單允許 |
| 執行任意命令 | 也許 | 中 | 提示使用者 |
| 刪除檔案 | 部分 | 中 | 始終提示 |
| Git push | 否 | 高 | 始終提示 |
| 部署到生產環境 | 否 | 高 | 始終提示 + 確認 |
| 資料庫變更 | 否 | 關鍵 | 多步驟確認 |
原則：可逆性決定自主性。 如果可以用 git checkout 復原，就可以自動允許。如果會改變生產環境狀態，則必須由人類批准。
確認流程
Claude Code 的權限系統就是一個確認流程。當 AI 請求需要批准的工具時，使用者會看到提示：
┌──────────────────────────────────────────────┐
│ │
│ Claude 想要執行： │
│ │
│ bash: npm run build │
│ │
│ [允許] [拒絕] [本次會話允許] │
│ │
└──────────────────────────────────────────────┘一個好的確認提示具有三個特性：
- 明確的操作 — 確切會發生什麼
- 充分的上下文 — AI 為什麼要這樣做
- 快速決策 — 使用者不需要深入分析就能說是或否
審批閘門
審批閘門是設計好的檢查點，AI 在繼續之前暫停並呈現其計畫。與每個工具都會觸發的權限提示不同，審批閘門是工作流中的策略性暫停。
┌──────────────────────────────────────────────┐
│ 審批閘門模式 │
│ │
│ 階段 1：研究（自主） │
│ ├── 讀取檔案 │
│ ├── 搜尋程式碼庫 │
│ ├── 分析依賴 │
│ │ │
│ ▼ │
│ ╔══════════════════════════════════════════╗ │
│ ║ 閘門：呈現發現 + 提議計畫 ║ │
│ ║ 「我發現了 3 個問題。以下是我的計畫...」 ║ │
│ ║ 使用者審查並批准/修改 ║ │
│ ╚══════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ 階段 2：實作（半自主） │
│ ├── 編輯檔案（依 CLAUDE.md 規則） │
│ ├── 執行測試 │
│ │ │
│ ▼ │
│ ╔══════════════════════════════════════════╗ │
│ ║ 閘門：部署前展示結果 ║ │
│ ║ 「所有測試通過。準備好推送了嗎？」 ║ │
│ ╚══════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ 階段 3：部署（人類控制） │
│ └── 只在明確批准後才推送 │
│ │
└──────────────────────────────────────────────┘你可以在 CLAUDE.md 中編碼審批閘門：
## Workflow Rules
- Always present a plan before making changes to more than 3 files
- Never push to remote without explicit user confirmation
- After running tests, report results and wait for approval before proceeding升級模式
當 AI 遇到模糊性或失敗時，它應該升級而不是猜測：
┌──────────────────────────────────────────────┐
│ 升級階梯 │
│ │
│ 等級 1：自行解決 │
│ AI 遇到錯誤 → 讀取錯誤訊息 │
│ → 嘗試替代方法 → 成功 │
│ │
│ 等級 2：告知並繼續 │
│ AI 遇到非阻塞問題 → 報告問題 │
│ → 繼續主要任務 │
│ │
│ 等級 3：請求澄清 │
│ AI 面對模糊的需求 │
│ → 提出具體問題 → 等待 │
│ │
│ 等級 4：停止並報告 │
│ AI 無法安全地繼續 │
│ → 解釋情況 → 呈現選項 │
│ → 等待人類決策 │
│ │
└──────────────────────────────────────────────┘AI 根據兩個因素決定使用哪個等級：信心 和 後果。
| 低後果 | 高後果 | |
|---|---|---|
| 高信心 | 等級 1：自行解決 | 等級 2：告知並繼續 |
| 低信心 | 等級 3：請求澄清 | 等級 4：停止並報告 |
信任梯度
信任隨時間建立。一個設計良好的系統從嚴格開始，逐步開放：
第 1 次會話： ████░░░░░░ 預設模式，所有操作都提示
第 5 次會話： ██████░░░░ 常用命令已加入允許清單
第 20 次會話：████████░░ 大多數操作自動允許
第 50 次會話：██████████ 團隊完全信任，最少提示Claude Code 透過其權限允許清單（.claude/settings.json）支援這一點：
{
"permissions": {
"allow": [
"Bash(npm run test)",
"Bash(npm run lint)",
"Bash(git status)",
"Bash(git diff)"
]
}
}每個允許的模式都是一個信任決策：「我已經看過這個操作足夠多次，可以信任它了。」
關鍵洞見
最佳的人機協作設計讓人類參與感覺自然，而不是煩人。 目標不是最小化人類互動 — 而是最大化每次互動的價值。
糟糕的 HITL 問：「我可以讀取這個檔案嗎？」（顯然可以，永遠可以） 好的 HITL 問：「我找到了 3 種方法。你偏好哪一種？」（真正的決策點）
框架：
- 自動允許 沒有風險且意圖明顯的操作
- 設閘門 在人類判斷能增加價值的策略性決策點
- 升級 在 AI 不確定時，而不是在它確定時
- 永遠不問 有明顯答案的問題
這就像你管理一個初級開發者。你不會看著他們打每個字。你審查他們的計畫，檢查他們的 PR，在他們卡住時回答問題。
實作範例
以下是一個在 CLAUDE.md 中編碼了審批閘門的部署工作流：
## Deployment Workflow
When I ask you to deploy:
1. RESEARCH PHASE (autonomous)
- Check git status (any uncommitted changes?)
- Run the full test suite
- Check for dependency vulnerabilities
2. APPROVAL GATE 1: Pre-deploy report
- Show: test results, git status, any warnings
- Wait for my "proceed" before continuing
3. BUILD PHASE (autonomous)
- Run production build
- Verify build output
4. APPROVAL GATE 2: Final confirmation
- Show: build size, any build warnings
- Explicitly ask: "Ready to push to main?"
- Only proceed with explicit "yes"
5. DEPLOY (with confirmation)
- git push origin main
- Report deployment status當 AI 遵循這個流程時，互動看起來像這樣：
使用者：「部署最新的變更」
AI：[讀取檔案、執行測試、檢查狀態 -- 全部自主]
AI：「部署前報告：
- 測試：47/47 通過
- Git：3 個檔案變更，無未提交的工作
- 依賴：無漏洞
準備好建置了嗎？」
使用者：「好，繼續」
AI：[執行建置 -- 自主]
AI：「建置完成：
- Bundle 大小：245KB（從 260KB 減少）
- 無警告
準備好推送到 main 了嗎？」
使用者：「推送吧」
AI：[推送到 main]
AI：「已部署。Cloudflare 建置已啟動。」兩個人類接觸點。每一個都是有意義的。使用者對不可逆的操作保持控制，而不需要對可逆的操作進行微管理。
前後對比
| 沒有 HITL 設計 | 有 HITL 設計 |
|---|---|
| AI 要嘛對所有事情都問，要嘛什麼都不問 | 在決策點設置策略性檢查點 |
| 使用者感到焦慮或煩躁 | 使用者感到資訊充足且掌控全局 |
| 信任是二元的（開/關） | 信任透過允許清單逐步建立 |
| 失敗是沉默的或災難性的 | 失敗在正確的等級升級 |
| 每次會話感覺都一樣 | 自主性隨著信心增長 |
下一堂課
你現在了解了如何設計人類與 AI 之間的邊界。第 23 堂課深入探討自定義 Agents 與 Skills — 如何建構你自己的 Markdown 擴展，將工作流知識、專門行為和團隊標準編碼為可重複使用、可分享的元件。