讓 AI 越用越聰明：九個可以直接套用的飛輪模式 Make Your AI Agent Smarter Every Run: Nine Flywheel Patterns You Can Copy Today

大多數人用 AI 代理的方式，像是每天請一位很聰明、但每天早上都失憶的新人。你花半小時教會它一件事，關掉視窗，明天重來。

道理大家都懂：修正要留下來、重複的流程要變成 Skill、失敗要變成測試。問題是「然後呢？」要存在哪裡、寫成什麼格式、什麼時候該升級、怎麼知道真的有變好？

這篇不談概念，只給可以直接複製的模式。以 Claude Code 示範，最後說明如何搬到 Grok Build 或一般聊天介面。

模式 0先建好一個資料夾

所有模式都建立在同一個結構上。在專案根目錄建立：

my-project/
├── CLAUDE.md                  # 常設規則（永遠載入，控制在 60–150 行）
├── .claude/
│   ├── rules/                 # 只在處理特定檔案時才載入的規則
│   │   └── manuscripts.md
│   ├── skills/                # 可重複的程序（按需載入）
│   │   └── verify-dates/
│   │       └── SKILL.md
│   ├── agents/                # 獨立的審查者
│   │   └── fact-checker.md
│   ├── hooks/                 # 強制檢查的腳本
│   │   └── guard.py
│   └── settings.json          # 掛上 hooks
└── flywheel/
├── progress.md            # 工作記憶：這個任務現在走到哪
├── lessons.md             # 教訓日誌：還在觀察的候選規則
├── failures/              # 失敗庫：一案一檔
│   └── F001-date-confusion.md
└── metrics.md             # 每月飛輪指標

整個資料夾放進 git。每一次規則的增刪都有紀錄，改壞了可以退回。

模式 1收工三問：每次任務結束時貼這段

飛輪最常斷在「任務做完就關視窗」。把下面這段存成文字快捷鍵，任務收尾時貼上：

任務收尾前，請回答三個問題，不要直接修改任何設定檔：
1. 這次我修正了你哪些地方？逐條列出，每條標註：
- 類型：一次性 / 偏好 / 程序 / 事實錯誤 / 危險操作
- 是否曾在 flywheel/lessons.md 出現過（請先讀該檔）
2. 哪些值得在這次對話結束後存活？依「修正分流表」（見 CLAUDE.md）
建議放到哪裡，並寫出你建議新增或修改的確切文字。
3. 更新 flywheel/progress.md，讓下一個會話可以直接接手。
只有第 3 項可以直接寫入。第 1、2 項等我確認。

重點在最後兩行：模型提案，人類核准。模型只能直接寫工作記憶（progress.md），不能自己改規則。

模式 2修正分流表：一個修正該放哪裡？

把這張表放進 CLAUDE.md ，模型和你都照它判斷：

最關鍵的是「兩次規則」：第一次出現只記錄，第二次出現才改流程。這能防止規則檔被一次性的雜訊撐爆。

這張表其實就是醫院根本原因分析（RCA）裡的「行動強度階層」：

模式 3教訓日誌 lessons.md

候選規則在這裡「實習」。每條一個區塊，格式固定：

## L-012 公告日與上市日混淆
- 首次：2026-10-03（寫 Opus 新版本介紹文）
- 再次：2026-10-11（寫 Grok Build 記憶功能）
- 次數：2
- 修正後的正確做法：提到任何日期時，標明是「宣布日 / 開放使用日 /
文件更新日」哪一種，並以官方來源核對
- 狀態：已提升 → .claude/skills/verify-dates（2026-10-12）

狀態 只有四種： 候選 、 已提升 → 位置 、 合併至 L-xxx 、 淘汰（原因） 。

注意寫的是「修正後的正確做法」，不是錯誤本身。「上次把公告日當上市日」是事件；「提到日期時標明類型並核對官方來源」才是可以執行的規則。

模式 4工作記憶 progress.md

讓任何一個新會話都能在一分鐘內接手。用固定的五個欄位：

# 任務：Grok Build 記憶功能文章
最後更新：2026-10-12 17:30
## 目標
寫一篇給醫療資訊讀者的介紹文，WordPress HTML，約 3000 字
## 已確認的決策（不要再討論）
- 主軸是「記憶資產屬於使用者，不屬於模型」
- 不做 Claude vs Grok 的優劣比較
## 已完成
- [x] 事實查核（來源見 sources.md）
- [x] 大綱
## 未解決的問題
- Grok Skills 的 token 上限找不到官方來源 → 暫不寫
## 下一步
撰寫第三節「跨平台搬遷」

「已確認的決策」這一欄最重要。少了它，新會話常常會把你們已經討論完的事重新提出來。

開新會話時只要一句：「先讀 flywheel/progress.md，然後從『下一步』繼續。」

模式 5把程序寫成 Skill

Skill 的關鍵是 description ：模型平常只看得到這一行，靠它決定要不要載入全文。所以要寫「什麼情況下用」，而不是「這是什麼」。

.claude/skills/verify-dates/SKILL.md ：

---
name: verify-dates
description: 文章或報告中出現產品發布、政策生效、法規公告等日期時使用。區分日期類型並以官方來源核對。
---
# 日期查證程序
## 步驟
1. 列出文中所有日期，每個標註類型：宣布日 / 開放使用日 / 生效日 / 文件更新日
2. 每個日期找一個官方來源（公司部落格、政府公告、官方文件）。二手報導只能當線索
3. 官方來源與二手報導不一致時，以官方為準，並在備註說明差異
4. 找不到官方來源的日期，改寫成不含具體日期的說法，或標註「據 OO 報導」
## 輸出格式
| 日期 | 原文寫法 | 類型 | 官方來源 | 結果（正確 / 已修正 / 改寫） |
## 停止條件
- 所有日期都有結果才算完成
- 任何日期無法判斷類型 → 停下來問我，不要猜

每個 Skill 都照同一副骨架寫：步驟、輸出格式、停止條件，需要時再加一個審查者。

模式 6失敗庫：一案一檔，改了系統就重跑

每個暴露過弱點的案例存一個檔，內容要能「重現」：

flywheel/failures/F001-date-confusion.md ：

# F001 公告日與上市日混淆
- 加入日期：2026-10-03
- 對應教訓：L-012
## 輸入（原封不動保存）
請寫一段 150 字介紹 Grok Build 的記憶功能，包含推出時間。
## 及格標準（逐條可檢查）
- [ ] 日期寫 2026-09-16，且明確說是「宣布並開放」
- [ ] 沒有把五月的 Grok Build 首發日當成記憶功能的推出日
- [ ] 附官方或可靠來源
## 歷次結果
| 日期       | 系統版本               | 通過項 | 備註         |
|------------|------------------------|--------|--------------|
| 2026-10-03 | 原始                   | 1/3    | 混淆兩個日期 |
| 2026-10-12 | 加入 verify-dates skill | 3/3    |              |

回歸測試的指令：

請依序執行 flywheel/failures/ 底下每個案例：
在一個不讀取我們這段對話的子代理中，以「輸入」原文執行，
再依「及格標準」逐條判定，結果追加到各檔的「歷次結果」表。
最後給我一張總表：哪些案例退步了。

什麼時候跑？只要動了 CLAUDE.md、Skill 或 Hook，就跑一次。案例不用多，十到二十個真實踩過的坑，比一百個想像出來的測試有用。

模式 7審查者與執行者分開

在 .claude/agents/fact-checker.md 定義一個只能讀、不能寫的審查者：

---
name: fact-checker
description: 文章完成後查核事實。對每個事實性主張回報證據，不修改檔案。
tools: Read, Grep, WebSearch, WebFetch
---
你是事實查核員。逐句找出文中的事實性主張（數字、日期、人名、產品功能），
每一條回報：
| 主張 | 判定：有據 / 無據 / 與來源矛盾 | 來源網址 | 說明 |
規則：
- 不准說「大致正確」。每條都要有判定
- 找不到來源就判「無據」，不要推論
- 你沒有寫入權限，只回報，不修改

設計重點有兩個。第一， tools 不給寫入權限，審查者在結構上就不可能「順手修掉」。第二，要求逐條判定加來源，你只需要看「無據」和「矛盾」那幾列，不必重讀整篇。

模式 8Hook：不能靠記性的事，就不要靠記性

寫在 CLAUDE.md 的「不准刪除原始資料」，模型大多會遵守，但「大多」在某些場合不夠。這時改用 Hook，在動作發生前攔截。

.claude/settings.json ：

{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "python3 .claude/hooks/guard.py" }
]
}
]
}
}

.claude/hooks/guard.py ：

import json, sys
data = json.load(sys.stdin)
cmd = data.get("tool_input", {}).get("command", "")
forbidden = ["rm -rf", "data/raw", "DROP TABLE"]
for word in forbidden:
if word in cmd:
print(f"已攔截：指令包含「{word}」。原始資料不可刪改，請改用複本。",
file=sys.stderr)
sys.exit(2)   # exit 2 = 阻擋，stderr 的訊息會回傳給模型
sys.exit(0)

退出碼 2 會擋下這個動作，並把訊息交給模型，讓它改走別的路。這是行動強度階層裡最強的一級：不是提醒，是讓錯誤做不到。

模式 9每月修剪與飛輪指標

每月一次，貼這段給模型：

請做本月的飛輪維護，只提出建議，不要直接修改：
1. CLAUDE.md：列出超過 30 天沒被用到、彼此衝突、或已被 Skill 涵蓋的規則
2. lessons.md：列出「候選」超過 60 天仍只出現一次的條目，建議淘汰
3. Skills：列出 description 可能觸發不到、或與其他 Skill 重疊的
4. 依 metrics.md 的定義計算本月指標，和上月比較

flywheel/metrics.md 只追四個數字：

自動記憶也一樣。Claude Code 的 MEMORY.md 在啟動時只載入前 200 行（或前 25KB），超過的部分會被靜默截斷。放不進前 200 行的，就該拆到主題檔或提升成 Skill。

換平台：資產在資料夾裡，不在模型裡

這套結構全是 Markdown 和幾個小腳本，所以不綁定任何一家廠商。

Grok Build

根據 xAI 文件與相關報導，Grok Build 會直接讀取 CLAUDE.md、CLAUDE.local.md、 .claude/rules/ 、skills 與 hooks，上面整個資料夾可以原樣沿用。它在 2026 年 9 月另外加入了自動記憶：每輪對話後在背景記下慣例與決策， /memory 可以瀏覽（唯讀）， /dream 會把零散筆記整併成主題檔。它刻意不存任務狀態與未確定的結論，所以 progress.md 還是要自己維護。

一般聊天介面（claude.ai、Grok 網頁版）

沒有終端機，也能用上一半的模式：

• 模式 2 的分流表與常設規則 → 放進「專案指示」或「自訂指令」
• 模式 5 的 Skill → 上傳成 Skill（Claude 與 Grok 都支援）
• 模式 4 的 progress.md → 放成專案檔案，每次收工請模型產出新版後替換
• 模式 1、6、9 的提示詞 → 照貼即可

從哪裡開始

不用一次建完。建議的順序：

1. 第一週：只做模式 1（收工三問）和模式 4（progress.md）。先讓修正不再消失。
2. 第二週：開始寫 lessons.md。第一個被提升的教訓，寫成你的第一個 Skill。
3. 第一個月底：把踩過的坑整理成五個失敗案例，跑第一次回歸；同時做第一次修剪。
4. 之後：只有在出現「一旦發生就很嚴重」的錯誤時，才加 Hook。

衡量這套系統成不成功，不是看資料夾有多完整，而是看三個月後，你說「不是這樣，我上次講過了」的次數，有沒有變少。

本文以 @LunarResearcher 關於 Opus 飛輪的討論為起點延伸整理。Claude Code 與 Grok Build 的功能細節以 2026 年 10 月為準。