系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0
前情提要：我在前傳（[前傳系列連結]）講過怎麼治 AI 唬爛——給它查官方文件的工具（MCP），再立一條「先查後答」的紀律。這篇是那套的進階版，沒看過前傳也能直接讀。

自律有個上限

前傳那條「先查後答」紀律（可驗證的技術事實，回答前一律先查官方）很有用，但用久了我發現一個問題：紀律靠的是 AI 的自覺，而自覺會累。

對話一長、context 一多，那條「先查再答」的規矩就會被稀釋。它偶爾還是會偷懶，憑記憶回你一句聽起來很對的話。這就像你交代新人「有疑問要查證」，他當下點頭，做到第五件事就忘了。

人的解法是什麼？加一道複查。 重要的東西，一個人做完、另一個人審。我就把這招搬過來，設了三個自動審核員。

什麼是「審核員」？先認識 Hook

在 Kiro 裡，這種「在某個時機自動跳出來做事」的機制叫 Hook。你可以把它想成 IDE 版的「鬧鐘 + 待辦」——某件事發生（例如「AI 剛答完話」「檔案被存檔」），就自動觸發一段動作。

我用它做的三個審核員，分別盯不同的東西：

審核員一：AWS 答案複查（aws-qa-auto-review）

觸發時機：每當 AI 回答完一個 AWS 技術問題。
它做的事：把剛才那段回答裡所有「可驗證的技術聲明」抓出來，一條一條獨立再去查一次官方文件，然後產一張表告訴我哪些 ✅ 正確、哪些 ⚠️ 有出入、哪些 ❌ 錯了。

等於是「答題的是它、改考卷的也是它，但改考卷時被規定要重新翻書」。這招對抓「數字類」的幻覺特別有效——配額、限制、定價這種最容易記錯的，複查一次就現形。

審核員二：CLI 結果驗證（verify-aws-cli-result）

維運很多操作是直接下 AWS CLI 查資源。問題是，AI 有時會「腦補」CLI 的輸出——你問它某資源狀態，它給你一個看似合理、但其實沒真的跑指令得來的答案。

這個 hook 就是盯這個：確保「講出來的結果」真的來自「跑過的指令」，而不是它想像的。維運最怕的就是拿幻覺當現況去做決策。

{
  "enabled": true,
  "name": "Shell 執行結果分析",
  "description": "shell 指令執行後，判斷成功或失敗並採取對應行動。",
  "version": "3",
  "when": {
    "type": "postToolUse",
    "toolTypes": [
      "shell"
    ]
  },
  "then": {
    "type": "askAgent",
    "prompt": "**[CRITICAL]** 檢查剛執行的 shell 指令結果，依以下邏輯處理：\n\n**Step 1：判斷成功或失敗**\n檢查輸出是否包含錯誤訊息（error、failed、denied、not found、InvalidParameter、command not found、No such file、Permission denied、exit code 非 0）。\n\n**如果成功：**\n- 如果是 AWS CLI 寫入操作（create、delete、terminate、modify、update、put、remove、stop、start），用一句話確認操作完成\n- 如果不是 AWS CLI 寫入操作，不做任何事\n\n**如果失敗：**\n**[MANDATORY]** 不要繼續同樣的假設再試一次。\n1. 分析失敗原因，分類錯誤類型：\n   - 權限不足（AccessDenied、UnauthorizedAccess）→ 檢查 IAM/profile\n   - 參數錯誤（InvalidParameter、ValidationError）→ 檢查參數格式\n   - 資源不存在（NotFound、NoSuchEntity）→ 確認資源名稱/ID\n   - 連線問題（timeout、connection refused）→ 檢查網路/endpoint\n   - 其他 → 用 --help 或官方文件確認用法\n2. 如果原因不明確，先收集更多資訊，不要猜\n3. 如果同一問題第 2 次以上失敗，必須說明「之前的假設哪裡錯了」再繼續"
  }
}

審核員三：設定一致性自檢（kiro-self-review）

這個比較特別，是拿來審它自己這套設定的。我這套 AI 系統有一堆 steering、skill、agent、hook 互相引用，改一個地方常常會漏改另一個。這個審核員負責做交叉檢查，抓「規則自相矛盾」「引用到不存在的東西」這種內傷。

{
  "enabled": true,
  "name": "Kiro 設定一致性審查",
  "description": "手動觸發的 Kiro 設定一致性檢查。用二元 pass/fail 標準檢查 agents、skills、hooks、steering、MCP 之間的交叉一致性。",
  "version": "1.0.0",
  "when": {
    "type": "userTriggered"
  },
  "then": {
    "type": "askAgent",
    "prompt": "你是 Kiro 設定的獨立審查員（不是這個 workspace 的日常助理）。你的職責是找出設定中的問題，不是維護它。\n\n**MANDATORY**: 執行以下步驟，不得跳過：\n\n1. 載入 `kiro-self-review` skill（使用 discloseContext）\n2. 讀取所有 `.kiro/agents/*.md` 文件\n3. 讀取所有 `.kiro/skills/*.md` 文件（只讀前 5 行，確認 Summary/Purpose 是否存在）\n4. 讀取所有 `.kiro/hooks/*.kiro.hook` 文件\n5. 逐項執行 skill 裡定義的所有 pass/fail 檢查\n6.. 用 skill 裡定義的輸出格式呈現結果\n\n**CRITICAL**: 每個檢查項都必須實際讀取文件驗證，不要靠記憶或假設。如果某個文件讀取失敗，標記為 ❌ FAIL 並說明原因。"
  },
  "workspaceFolderName": "KrioAWS",
  "shortName": "kiro-self-review"
}

一個真實的例子：它自己抓到自己的錯

講個有感的。有次我問一個資料庫參數的上限，AI 憑印象回了個數字（又來）。但這次答完之後，第一個審核員自動醒來、去翻了官方文件，然後回頭補一句：

⚠️ 修正：我剛才講的上限有誤，官方文件寫的是另一個數字，來源在此。

我什麼都沒做。它自己答錯、自己抓包、自己修正。那一刻我真的有種「請對人了」的感覺——不是它變得不會錯，是它會自己接住自己的錯。

為什麼是「事後複查」而不是「答得更小心」

有人會問：幹嘛不乾脆叫它答之前更小心就好？

因為**「更小心」是模糊的、會累的；「答完自動複查」是明確的、每次都跑的**。前者靠自覺，後者靠機制。維運的世界裡，能自動化的紀律，就不要留給人的意志力——這句話對帶 AI、對帶自己，都成立。

帶走的三個重點

1. 自律有上限，複查沒有。 重要的答案，讓另一道機制自動再審一次。
2. 審核員要分工。 查文件的、驗 CLI 結果的、查設定一致性的，各盯各的，別混成一坨。
3. 能自動化的紀律，別靠意志力。 這是防幻覺，也是維運的通則。

到這裡，唬爛的病治得差不多了。明天開始換一個題目——不是問答，是真刀真槍的維運現場。我會用兩個真實案例驗收這套機制：一次是 AI 差點讓我信錯資料庫的限制，一次是一句指令回我空的，害我以為東西被人刪了。

✍️ 關於作者：康子晉，做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖為伍。這個系列記錄我怎麼把 AI 從「會聊天」調教成「能扛維運的同事」。
🔗 LinkedIn