系列：《我用 AI 養出一個 AWS 維運同事》｜撰於 2026-09｜Kiro IDE 1.0

一個懶人的堅持

昨天講了 AI 該有兩種記憶：日誌（記事件）和錯題本（記知識）。但馬上有個現實問題——

誰負責把日誌裡的教訓，整理進錯題本？

如果答案是「我手動整理」，那我直接告訴你結局：這套系統活不過三天。人就是懶，凡是要靠自律手動維護的東西，最後都會死在「啊我今天先不要」。我自己就是這種人，不騙你。

所以我的原則是：能自動的，絕不手動。 這套「日誌→錯題本」的蒸餾，必須自己跑。

蒸餾管線長怎樣

我設計了一條管線，讓一條技術雷從「今天的日誌」自動流進「對應服務的錯題本」。流程是這樣：

① 對話中得到一個技術雷/查證結論
      ↓（寫進 memory 日誌時）
② 如果是某服務專屬的雷 → 在條目末尾打個 tag：#待沉澱:eks
      ↓（背景整理員定期掃描）
③ 累積到一定量 → 自動把這些雷按服務分類
      ↓
④ 併入對應的 knowledge-eks.md、knowledge-rds.md……
   順便更新「最後驗證日期」、在檔尾加一行 changelog
      ↓
⑤ 原本的 tag 改成 #已沉澱，表示這條雷已經歸檔

白話講：每條雷先貼張「待歸檔」標籤，背景有個整理員定期把貼標籤的雷收進對應的錯題本，收完把標籤改成「已歸檔」。

關鍵設計一：為什麼要「攢一批」才沉澱

你可能會問，幹嘛不每踩一個雷就馬上歸檔？

因為「更新知識庫」是件相對重的事——要判斷歸到哪個服務、哪個主題區塊、有沒有跟舊條目重複。如果每次對話都做，很燒 token（也就是很花錢很花時間）。

所以我讓它攢一批再一次處理：累積到 5 條待沉澱、或距上次沉澱超過 7 天，才觸發一次。這是效率跟即時性的取捨——維運排程也是這個道理，不是每件事都要即時，能批次的就批次，省下的資源留給真正緊急的事。

關鍵設計二：錯題本不是「聖經」

這是我最想強調的一條紀律，也是很多人用 AI 知識庫會踩的坑：

錯題本裡的知識，是「歷史蒸餾」，只能當「起點假設」，不能當「權威事實」。

為什麼？因為它記的是「我幾個月前踩到、當時查證是這樣」的雷。但 AWS 一直在改——你三個月前確認的限制，今天可能已經不一樣了。

所以我在每個錯題本檔案開頭都寫了一條鐵律：

回答前仍要查官方文件比對。層間衝突的優先序是：官方最新文件 ＞ 錯題本（語意記憶）＞ 日誌（情節記憶）。

翻成白話：錯題本負責「以前踩過什麼」，官方負責「現在還是不是這樣」，兩個都要給使用者看。 這樣既能享受「累積」的好處（不用每次重踩），又不會被過期的知識反咬一口。

關鍵設計三：錯題本 vs SOP，別搞混

我還踩過一個雙頭維護的坑，順便講。我同時有「錯題本」（knowledge）和「操作手冊」（後面 Day 14 會講的 Skill）。一開始我把流程和雷都寫在兩邊，結果改一次要改兩個地方，很快就對不上。

後來我定了分工：

• 錯題本（knowledge）：只放「事實 / 雷 / 限制」——這些易變、要跟官方對帳
• 操作手冊（skill）：只放「操作步驟 SOP」——這些是流程，相對穩定

同一個主題重疊時，錯題本不寫流程、手冊不寫易變數字。一個知識只有一個家，才不會精神分裂。

照著做：我的實際設定

錯題本每個服務一個檔（.kiro/steering/knowledge-<服務>.md）。我有一份範本，開新檔就複製它：

---
inclusion: auto
name: knowledge-<服務>
description: <服務>踩雷與查證知識庫。當使用者提到 <關鍵字1>、<關鍵字2>、<關鍵字3>…時自動載入。
---

# knowledge-<服務>

## ⚠️ 使用規範（必讀，優先於下方所有內容）

**本檔是「歷史蒸餾知識」≠「當前權威事實」，可能已過時。**

回答該服務問題時，禁止只憑本檔作答，必須：
1. 以本檔為起點假設
2. 查證官方最新文件
3. 產出比對表（聲明 / 本地記憶含驗證日 / 官方最新 / ✅一致 🔄已更新 ⚠️有出入）
4. 標來源：官方附連結；本地標「歷史紀錄＋最後驗證日，未重新查證」
5. 不符 → 以官方為準，並回頭更新本檔 + 寫 changelog

### 層間衝突優先序（鐵則）
> **官方最新文件 ＞ 本知識檔（語意記憶）＞ 日誌（情節記憶）**

### 看驗證日決定查證力度
每區塊標 `最後驗證：YYYY-MM`；距今 **> 3 個月**視為高風險過時，務必重查。

口訣：**本檔負責「以前踩過什麼」，官方負責「現在還是不是這樣」。**

## <主題區塊 1>
`最後驗證：YYYY-MM（未重新查證）`
- 條目…

---
## Changelog
- YYYY-MM-DD：建立本檔。

三個設計重點，都是被雷過才加的：

1. inclusion: auto 加上塞滿關鍵字的 description。這是「按需自動載入」——講到那個服務它才進來，不佔平常的成本。我最早忘記把範本的 manual 改成 auto，結果檔案寫得很漂亮但一輩子沒被載入過，白寫。
2. 「本檔不是權威」寫在最上面。錯題本最大的風險不是沒東西，是你太相信它。所以我把「禁止只憑本檔作答」放在檔案第一段，讓它每次載入都先看到這句。
3. 每個區塊標驗證日期。三個月以上就當高風險過時。知識也有保鮮期，沒有日期的知識沒辦法判斷該不該信。

至於「怎麼把日誌裡的教訓自動搬進錯題本」，我的做法是先在日誌條目結尾打一個標記（例如 #待沉澱:rds），這個動作很輕、每次對話結束順手做；真正的整理留給明天要講的「睡覺」時段。快的事即時做、慢的事睡覺做，這樣它才不會每次回答都卡在整理知識。

帶走的三個重點

1. 靠自律的維護一定會死。 讓踩雷「自動」從日誌蒸餾進錯題本，貼標籤 → 定期歸檔。
2. 能批次就批次。 攢一批再沉澱，省資源，這跟維運排程同理。
3. 錯題本是起點不是聖經。 永遠「官方 ＞ 錯題本 ＞ 日誌」，回答前跟官方對帳。

但這裡還有一個沒解的問題：錯題本裡的知識會過期，誰來定期抓它上官方重新對帳？這就要靠一個比較特別的機制——我讓 AI「睡覺做夢」。明天講。

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