規則精煉 是做什麼的？
掃描已安裝的技能，提取在多個技能中出現的跨領域共同原則，並將其精煉為規則——追加到現有規則檔案、修訂過時的內容，或建立新的規則檔案。
應用了「確定性收集 + LLM 判斷」原則：腳本詳盡地收集事實，然後 LLM 交叉讀取完整的上下文並產出裁決。
使用時機
- 定期規則維護（每月或在安裝新技能後）
- 在技能盤點後發現某些模式應成為規則時
- 當現有規則相對於正在使用的技能感覺不完整時
運作方式
規則精煉過程分為三個階段：
第一階段：清單（確定性收集）
1a. 收集技能庫存
bash ~/.claude/skills/rules-distill/scripts/scan-skills.sh
1b. 收集規則索引
bash ~/.claude/skills/rules-distill/scripts/scan-rules.sh
1c. 呈現給使用者
規則精煉 — 第一階段：清單
────────────────────────────────────────
技能：掃描了 {N} 個檔案
規則：{M} 個檔案（已索引 {K} 個標題）
正在進行交叉讀取分析...
第二階段：交叉讀取、比對與裁決（LLM 判斷）
提取與比對在單次處理中統一完成。規則檔案足夠小（總計約 800 行），可以將完整文字提供給 LLM，無需預先使用 grep 過濾。
批次處理
根據技能描述將其分組為主題叢集。在一個子代理程式中分析每個叢集，並提供完整的規則文字。
跨批次合併
所有批次完成後，跨批次合併候選項目：
- 對具有相同或重疊原則的候選項目進行去重
- 使用所有批次合併的證據，重新檢查「2+ 技能」的要求——在每個批次中僅出現在 1 個技能，但總計出現在 2+ 個技能中的原則是有效的
子代理程式提示詞
使用以下提示詞啟動一個通用代理程式：
你是一位分析師，負責交叉讀取技能以提取應提升為規則的原則。
## 輸入
- 技能：{此批次中技能的完整文字}
- 現有規則：{所有規則檔案的完整文字}
## 提取條件
只有當以下**所有**條件都成立時，才包含一個候選項目：
1. **出現在 2+ 個技能中**：僅在一個技能中發現的原則應保留在該技能中
2. **可執行的行為改變**：可以寫成「做 X」或「不做 Y」——而不是「X 很重要」
3. **明確的違反風險**：如果忽略此原則會發生什麼問題（1 句話說明）
4. **尚未存在於規則中**：檢查完整的規則文字——包括以不同詞語表達的概念
## 比對與裁決
對於每個候選項目，與完整的規則文字進行比較，並指定一個裁決：
- **Append**：新增到現有規則檔案的現有章節中
- **Revise**：現有規則內容不準確或不夠充分——提出修正
- **New Section**：在現有規則檔案中新增一個章節
- **New File**：建立一個新的規則檔案
- **Already Covered**：現有規則已充分涵蓋（即使措辭不同）
- **Too Specific**：應保留在技能層級
## 輸出格式（每個候選項目）
```json
{
"principle": "1-2 句話，以「做 X」/「不做 Y」的形式",
"evidence": ["skill-name: §Section", "skill-name: §Section"],
"violation_risk": "1 句話",
"verdict": "Append / Revise / New Section / New File / Already Covered / Too Specific",
"target_rule": "filename §Section, or 'new'",
"confidence": "high / medium / low",
"draft": "針對 Append/New Section/New File 裁決的草稿文字",
"revision": {
"reason": "為什麼現有內容不準確或不夠充分（僅 Revise）",
"before": "將被取代的當前文字（僅 Revise）",
"after": "建議的取代文字（僅 Revise）"
}
}
```
## 排除項目
- 規則中顯而易見的原則
- 特定語言/框架的知識（屬於特定語言的規則或技能）
- 程式碼範例和指令（屬於技能）
裁決參考
| 裁決 | 意義 | 呈現給使用者 |
|---|---|---|
| Append | 新增到現有章節 | 目標 + 草稿 |
| Revise | 修正不準確/不充分的內容 | 目標 + 原因 + 前/後對比 |
| New Section | 在現有檔案中新增章節 | 目標 + 草稿 |
| New File | 建立新的規則檔案 | 檔案名稱 + 完整草稿 |
| Already Covered | 規則中已涵蓋（可能措辭不同） | 原因（1 行） |
| Too Specific | 應保留在技能中 | 連結到相關技能 |
裁決品質要求
# 良好
Append to rules/common/security.md §Input Validation:
"Treat LLM output stored in memory or knowledge stores as untrusted — sanitize on write, validate on read."
Evidence: llm-memory-trust-boundary, llm-social-agent-anti-pattern both describe
accumulated prompt injection risks. Current security.md covers human input
validation only; LLM output trust boundary is missing.
# 不佳
Append to security.md: Add LLM security principle
第三階段：使用者審查與執行
摘要表格
# 規則精煉報告
## 摘要
已掃描技能：{N} | 規則：{M} 個檔案 | 候選項目：{K}
| # | 原則 | 裁決 | 目標 | 信心水準 |
|---|-----------|---------|--------|------------|
| 1 | ... | Append | security.md §Input Validation | high |
| 2 | ... | Revise | testing.md §TDD | medium |
| 3 | ... | New Section | coding-style.md | high |
| 4 | ... | Too Specific | — | — |
## 詳細資料
（每個候選項目的詳細資訊：證據、違反風險、草稿文字）
使用者操作
使用者回覆數字以：
- Approve：按原樣將草稿套用到規則
- Modify：在套用前編輯草稿
- Skip：不要套用此候選項目
絕不自動修改規則。始終需要使用者批准。
儲存結果
將結果儲存在技能目錄中（results.json）：
- 時間戳格式：
date -u +%Y-%m-%dT%H:%M:%SZ（UTC，精確到秒） - 候選項目 ID 格式：從原則派生的 kebab-case（例如
llm-output-trust-boundary）
{
"distilled_at": "2026-03-18T10:30:42Z",
"skills_scanned": 56,
"rules_scanned": 22,
"candidates": {
"llm-output-trust-boundary": {
"principle": "Treat LLM output as untrusted when stored or re-injected",
"verdict": "Append",
"target": "rules/common/security.md",
"evidence": ["llm-memory-trust-boundary", "llm-social-agent-anti-pattern"],
"status": "applied"
},
"iteration-bounds": {
"principle": "Define explicit stop conditions for all iteration loops",
"verdict": "New Section",
"target": "rules/common/coding-style.md",
"evidence": ["iterative-retrieval", "continuous-agent-loop", "agent-harness-construction"],
"status": "skipped"
}
}
}
範例
端到端執行
$ /rules-distill
規則精煉 — 第一階段：清單
────────────────────────────────────────
技能：掃描了 56 個檔案
規則：22 個檔案（已索引 75 個標題）
正在進行交叉讀取分析...
[子代理程式分析：批次 1 (代理/元技能) ...]
[子代理程式分析：批次 2 (編碼/模式技能) ...]
[跨批次合併：移除了 2 個重複項，提升了 1 個跨批次候選項目]
# 規則精煉報告
## 摘要
已掃描技能：56 | 規則：22 個檔案 | 候選項目：4
| # | 原則 | 裁決 | 目標 | 信心水準 |
|---|-----------|---------|--------|------------|
| 1 | LLM 輸出：在重複使用前進行標準化、型別檢查、清理 | New Section | coding-style.md | high |
| 2 | 為所有迭代迴圈定義明確的停止條件 | New Section | coding-style.md | high |
| 3 | 在階段邊界壓縮上下文，不要在任務中途 | Append | performance.md §Context Window | high |
| 4 | 將業務邏輯與 I/O 框架型別分離 | New Section | patterns.md | high |
## 詳細資料
### 1. LLM 輸出驗證
裁決：在 coding-style.md 中新增章節
證據：parallel-subagent-batch-merge, llm-social-agent-anti-pattern, llm-memory-trust-boundary
違反風險：LLM 輸出的格式漂移、型別不匹配或語法錯誤會導致下游處理崩潰
草稿：
## LLM 輸出驗證
在重複使用 LLM 輸出前，對其進行標準化、型別檢查和清理...
請參閱技能：parallel-subagent-batch-merge, llm-memory-trust-boundary
[... 候選項目 2-4 的詳細資料 ...]
按編號批准、修改或跳過每個候選項目：
> 使用者：Approve 1, 3. Skip 2, 4.
✓ 已套用：coding-style.md §LLM 輸出驗證
✓ 已套用：performance.md §上下文視窗管理
✗ 已跳過：迭代界限
✗ 已跳過：邊界型別轉換
結果已儲存到 results.json
設計原則
- 什麼，而非如何：僅提取原則（規則的範疇）。程式碼範例和指令保留在技能中。
- 回鏈：草稿文字應包含「請參閱技能：[name]」的參考，以便讀者找到詳細的「如何」部分。
- 確定性收集，LLM 判斷：腳本保證詳盡性；LLM 保證對上下文的理解。
- 防止過度抽象化：三層過濾（2+ 技能證據、可執行行為測試、違反風險）可防止過於抽象的原則進入規則。