上週一個開發者在群組裡說了一句話，讓我想到一個我自己也踩過很多次的坑：

「我的 agent 一直說『你應該手動確認一下』，感覺在用它還不如自己做。」

我完全理解這種挫折感。

AI Agent 的懶散模式

如果你用過 AI coding agent 一段時間，你一定認識這些句子：

  • 「這個問題可能是資料庫連線設定，建議你確認一下。」
  • 「功能已經實作，應該可以正常運作。」
  • 「我沒辦法直接確認，你可以手動測試看看。」
  • 「這可能是環境變數的問題。」

這不是 agent 壞掉了。這是 AI 模型在面對不確定性時的標準反應——把結論留給用戶，自己退到「建議」的安全位置。

問題是，你花時間設置 agent，不是為了讓它給你「建議清單」。你要的是它真的去解決問題。

為什麼 Agent 會推責任？

AI 模型在訓練時有一個內建傾向：在不確定的情況下，推責任比犯錯更「安全」。

對模型來說，說「你應該確認一下」是一個低風險的答案——不會犯錯，也不會造成額外問題。但對你來說，這個答案沒有價值。

這個問題換一個框架來看會更清楚：

想像你剛雇了一個工程師，問他「這個 API 為什麼一直回 401？」

懶散模式的工程師：「可能是 token 過期了，你去看一下 API 文件確認一下。」

**你想要的工程師：**跑一個 curl 確認回應格式、查 token 過期時間、試 refresh、確認修好、告訴你結果。

差別不在能力，在責任感。

YES 紀律引擎：5 條鐵則

YES 紀律引擎（YES Discipline Engine）是一套裝進 agent 系統提示的行為規則。它的名字來自核心哲學：當 agent 說「我做好了」，你應該能夠說「Yes，我相信你」——而不是「讓我去確認一下」。

鐵則一：不猜測，只查證

1
2
3
4
5
6
7

❌ "問題可能出在資料庫連線。"
✅ 執行 psql -U user -h localhost testdb
   → 得到 "Connection refused (port 5432)"
   → PostgreSQL 沒在跑
   → 執行 sudo systemctl start postgresql
   → 重新連線測試通過
   → 報告：已確認並修復

任何「可能是 X 的問題」都必須先變成「我跑了 Y，得到結果 Z」。

鐵則二：不推責，自己解決

1
2
3

❌ "你應該手動確認這個設定是否正確。"
✅ 讀設定檔、比對文件、找出差異、修正、驗證
   → 如果沒有權限：說明具體需要什麼權限，原因是什麼

agent 的工作邊界是「你設定給它的作用域（allowed files / assigned tasks）之內的事情自己解決」。超出邊界才說需要幫助，但要說清楚需要什麼。

鐵則三：不聲稱，附證據

1
2
3
4

❌ "rate limiting 功能已完成。"
✅ 執行 for i in {1..15}; do curl -s localhost:3000/api; done
   → 確認前10次 200、後5次 429
   → 報告：功能驗證通過，符合需求

「功能已完成」不算完成。帶著輸出的「功能已完成」才算完成。

鐵則四：不重複失敗的方法

1
2
3
4
5

如果方法 A 第一次失敗：
→ 先診斷為什麼失敗
→ 再決定下一步（修改 A 或換方法 B）

不是：把一模一樣的命令跑第二次然後說「我試過了」

鐵則五：每個任務有明確狀態

任務結尾必須是三種之一：

  • ✅ 完成：附驗證輸出
  • ❌ 阻擋：說明具體原因 + 需要什麼才能繼續
  • 🔄 進行中：說明下一步是什麼

不存在「應該沒問題」這種狀態。

安裝 YES 紀律引擎

這套規則設計為純文字，可以直接加到任何 agent 的系統提示裡。

Claude Code / Claude API： 在 CLAUDE.md 或 system prompt 裡加入以下規則區塊：

1
2
3
4
5
6
7

## YES Discipline Engine

- Rule 1: Never guess. Run the actual command and report the real output.
- Rule 2: Never deflect. If it's in your scope, solve it. If not, say exactly what you need.
- Rule 3: Never claim without evidence. Show the verification output before saying "done."
- Rule 4: Never retry identically. If approach A failed, diagnose why before next attempt.
- Rule 5: Every task closes with: ✅ Done (with evidence) | ❌ Blocked (specific reason) | 🔄 In Progress (next step)

OpenClaw： 把規則加到 SOUL.md 的 <anti-slack> 區塊，或作為獨立 skill 載入（skills/yes-en/SKILL.md）。

實際上會有什麼變化？

裝完之後最明顯的改變不是 agent「更聰明了」，而是你不需要當中間人了。

以前的流程：

  1. 你問問題
  2. Agent 給建議
  3. 你去手動確認
  4. 你回來告訴 agent 結果
  5. Agent 給下一步建議
  6. 重複

裝了 YES 引擎之後：

  1. 你給任務
  2. Agent 跑到底，附帶完整輸出
  3. 你看結果決定下一步

差別在於步驟 3-5 從你的工作清單裡消失了。

一個注意事項

YES 紀律引擎會讓 agent 更主動——它會去跑命令、讀檔案、修改程式碼。這意味著你需要設定清楚的邊界：

  • allowed_files：哪些檔案 agent 可以修改
  • 哪些操作需要確認（部署、DB 修改、對外發布）

沒有邊界的「主動」會變成問題。YES 引擎的設計前提是 agent 有明確的作用域，在作用域內自主，在作用域外詢問。

如果你的 agent 現在還在說「你應該手動確認一下」，試試把這五條規則加進它的系統提示，下一個任務看看會不會不一樣。

AI 指揮官手冊 — 零程式背景的 OpenClaw AI 團隊建置實戰指南
$14.90 · 8 章完整內容 + 6 份模板
了解更多 →

延伸閱讀