知識系統建好了。但每次調查還要手動跟 AI 說「先讀這個、再讀那個」。能不能一句話搞定？
上一篇我們建了四層知識架構：環境設定、調查 SOP、服務文件、歷史案例。
AI 確實變好用了。
但每次調查，你還是要這樣：
「先讀 investigation-cheat-sheet.md。」
「然後讀 order-service.md。」
「按照 SOP 的順序來。」
三句話，每次都要講。
更麻煩的是：你知道要這樣做，但你的同事不知道。
新人 on-call 時，他不知道先讀哪個文件。
調查品質取決於「誰在值班」，而不是「有沒有 SOP」。
這篇要解決的事：把知識系統封裝成一個指令，一句話啟動完整調查。
一句話解釋：Skill 就是一份 AI 自動讀取的 SOP，附帶所有參考資料。
想像你帶一個很聰明的新人。
Article 7 教的是：把經驗寫成文件給他看。
Skill 做的是：把這些文件裝成工具包，新人拿到就能開始幹活。
技術上也不複雜。就是一個 markdown 文件加一堆參考資料。
Claude Code 啟動時自動載入。你甚至不需要打指令觸發。
差別在哪？
打雜的花園鰻
以前（Article 7 的做法）：
你：「幫我查 Order Service 的錯誤」
你：「先讀 runbook.md」
你：「再讀 order-service.md」
你：「按照 SOP 的順序」
→ 每次重複交代
有 Skill 之後：
你：「Order Service 5xx」（貼一張告警截圖）
→ AI 自動辨識關鍵字，觸發對應的 Skill
→ 讀 SOP、查路由表、找參考文件，按步驟調查
→ 你只看結果、做決策
我自己最常的用法：收到告警，截圖丟給 AI。就這樣。
AI 從截圖裡讀出服務名稱、錯誤碼、時間，自動觸發調查 Skill。
然後它就開始跑了。查 log、看 metrics、追 correlation、整理結論。
如果順利，我完全不用介入。整個調查從頭到尾自己跑完。
這才是 Skill 最開心的地方：不是「幫你查」，是「幫你查完」。
以下是我實戰的一個截圖，讓你感覺一下．
一個 Skill 最少只需要一個檔案：SKILL.md。
格式很簡單。開頭是 YAML frontmatter，定義名稱和描述：
---
name: my-investigator
description: 調查服務 5xx 錯誤。當使用者提到 5xx、500、503、
error、故障排查、troubleshoot 時觸發。
---
# My Investigator
（你的調查流程寫在這裡）
兩個必填欄位：
description 是最關鍵的欄位。
Claude 就是靠它來判斷「現在要不要啟動這個 Skill」。
你寫「5xx、error、故障排查」，使用者一提到這些關鍵字，Skill 就被觸發。
所以前面說的「截圖丟過去就自動跑」，就是靠 description 裡的關鍵字匹配。
Skill 不是一次全部塞進 AI 的腦袋。它是分層載入的：
第一層：Metadata（name + description）
→ 啟動時就載入，用來判斷要不要觸發
→ 很輕，大約 100 tokens
第二層：SKILL.md 本體
→ 觸發後才讀取
→ 建議控制在 500 行以內
第三層：references/ 裡的檔案
→ AI 需要時才去讀
→ 可以放大量資料，不會浪費 context
這設計很聰明。你可以在 references/ 放 20 份服務文件，AI 不會全部讀。它只會在需要 Order Service 資訊時，才去讀 services/order-service.md。
用一個虛構的場景來示範。
假設你是電商平台的 SRE。負責的系統：
使用者 → API Gateway → 微服務群
├── Order Service（訂單）
├── Inventory Service（庫存）
├── Notification Service（通知）
└── Payment Gateway（第三方金流）
Log: Elasticsearch
Metrics: Prometheus + Grafana
你想建一個 /investigate Skill。
shopflow-investigator/
├── SKILL.md # 核心：調查流程 + 判斷邏輯
├── references/
│ ├── runbook.md # 調查決策樹
│ ├── architecture.md # 系統架構 + 服務相依性
│ ├── es-indices.md # 各服務的 ES index 對照
│ └── services/ # 每個服務的 profile
│ ├── order-service.md
│ ├── inventory-service.md
│ └── payment-gateway.md
└── scripts/
└── es_query.sh # 查詢模板
三個角色：
# ShopFlow Investigator
## 核心原則
- 先確認影響範圍，再深入根因
- Log + Metrics 交叉比對
- 第三方問題先排除
## 調查流程
### Phase 1: 快速定位（2 分鐘）
1. 查服務路由表 → 確認是哪個服務
2. 查 Grafana → error rate、latency、throughput
3. 判斷：單一服務 or 串聯故障？
### Phase 2: Log 深入（5 分鐘）
4. 查 ES access log → 篩選 5xx
5. 看 error message → 分類問題類型
6. 取 request_id → 追蹤呼叫鏈
### Phase 3: 結論（3 分鐘）
7. 整理 timeline + 根因 + 影響範圍
## 服務路由表
（見下方）
你的調查流程跟我的一定不同。沒關係。
重要的是把你腦中的流程寫出來。格式不重要。
有一點要強調：Skill 不是死板的 SOP。
它更像是一條預設路線。AI 會遵循這個流程走，但遇到意料之外的東西，它會自己判斷、繼續探索。
比如 SOP 寫的是查 access log，但 AI 在 log 裡發現了一個沒見過的 error pattern。它不會傻傻跳到下一步，而是會順著那個線索繼續挖。
這才是 Skill 厲害的地方：有流程，但不僵化。
| 關鍵字 | 服務 | ES Index | 常見問題 |
|--------|------|----------|---------|
| 訂單, 結帳 | Order Service | shopflow-order-* | DB deadlock |
| 庫存, 缺貨 | Inventory Service | shopflow-inv-* | Redis 快取不一致 |
| 付款, 刷卡 | Payment Gateway | shopflow-pay-* | 第三方 timeout |
這是 Skill 的關鍵設計。
使用者說「結帳失敗」。AI 需要知道：這對應哪個服務？Log 在哪？常見原因是什麼？
沒有路由表，AI 用猜的。猜錯就浪費時間。
AI 看到「結帳失敗」→ 對應 Order Service → 讀 services/order-service.md → 查正確的 index。
全自動。
不需要一次建完。
mkdir -p my-investigator/references/services
SKILL.md 的最小可用版本：
# My Investigator
## 調查流程
1. 確認目標服務（查路由表）
2. 查 access log（最近 1 小時，過濾 5xx）
3. 取 request_id 追蹤呼叫鏈
4. 查 metrics 確認趨勢
5. 整理結論
## 服務路由表
| 服務 | Log Index | 備註 |
|------|-----------|------|
| Order | shopflow-order-* | 500 常見：DB deadlock |
| Payment | shopflow-pay-* | 504 常見：第三方 timeout |
20 行。不完美，但比每次手動交代好 100 倍。
調查完，花 5 分鐘問自己：
10 次調查後，你的 Skill 就覆蓋 80% 的場景。
Skill 不是寫完就放著。它是活的文件。
Article 7 教你建知識系統。這篇教你把它封裝成指令。
7 是「內容」，8 是「包裝」。
Skill 的真正價值不是技術多厲害。
是把「一個人的經驗」變成「團隊的能力」。
是讓調查品質不再取決於今天誰值班。
是讓 SRE 的知識可以像軟體一樣：版本控制、持續迭代、多人協作。
我自己目前有好幾個 Skill，覆蓋故障調查、報告撰寫、日常 review。
不用全部從零建。從最痛的那個場景開始就好。
但 Skill 還是要你手動打 /investigate 才會動。
下一篇，我們聊聊：當告警觸發，AI 自動啟動調查。
從「你叫它做」到「它自己做」。
iThome鐵人賽
看影片追技術