Fable method：讓任何模型重現 Claude Fable 5 習慣

Fable method 實際宣稱的內容

Fable method 是一組精簡的 agent skills，將某個模型的工作習慣寫成有順序的程序，讓其他模型也能執行相同程序。該 repo 是 Sahir619/fable-method，採用 MIT 授權；repo 自己的一句話說明是：「Claude Fable 5 的工作方式，濃縮成任何模型都能執行的 skills，並附有維持客觀性的 eval。」值得測試的是這句話的後半部。

文字檔是否真的能記錄特定模型的思考方式，Anthropic 以外的人無法驗證。但較便宜的模型讀取該文字檔後是否會產生不同的行為，你可以在一台 VPS 上，用一個下午自行測試。以下內容的重點就是這項測量：使用與不使用該 method，各執行相同任務一次，並計算工具呼叫次數與成本。

如果你不熟悉 skill 這個詞，請先閱讀agent skill 實際是什麼：它是一個資料夾，內含 SKILL.md 檔案，其 frontmatter description 會告訴 agent 何時載入本文。repo 以其命名的模型，則在Claude Fable 5 的成本與適用情境中介紹。

安裝 skills，並鎖定測試使用的版本

有兩種安裝方式。在 Claude Code 中，使用 plugin 的方式需要執行兩個命令：

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

在 VPS 上，如果需要將固定版本複製到磁碟，請先 clone 並切換至指定 tag：

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh 不需要 sudo，因為它只會寫入 $HOME/.claude/skills 底下。執行後，ls ~/.claude/skills 會列出 fable-judge、fable-loop 和 fable-method。請查看缺少哪些項目。此 repo 提供四個 skills，而 shell installer 只會複製三個，因此 standalone 使用者不會取得 fable-domain，除非手動複製：

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

請鎖定該 tag，並將 tag 記錄在測試結果旁邊。此 repo 在 2026-07-06 到 2026-07-15 之間發布了五個 releases，版本從 v1.0.0 到 v1.4.0；v1.4.0 透過新增 routing gate，變更了方法本身。截至 2026 年 8 月，v1.4.0 仍是最新的 tag。如果 control run 讀取某個版本的規則，而 test run 讀取另一個版本，測量結果就沒有意義。

四項技能各自要求模型執行的工作

承擔主要作用的檔案是 skills/fable-method/SKILL.md。其中包含兩道閘門與 7 個編號步驟，規則具體到足以逐條檢視。

第一道是 triviality gate：如果變更只涉及 1 個檔案、執行內容約少於 10 行、不會加入新行為，而且你已經確切知道要修改什麼，就直接處理，不必進行額外程序。整個獨立技能 Ponytail，會引導代理採用能運作的最小變更，就是建立在這個直覺上；它的核心規則短到可以直接複製到自己的指示中，不必安裝任何元件。接著是 fit gate，依答案所在的位置分流請求：可直接開啟的來源、必須先研究的技術，或你自己的推論；後者必須標示為低信心，不得當成事實陳述。中間這個分支只有在代理確實能存取 Web 時才有效。對受限制的 VPS 而言，這表示必須提供專用的搜尋後端，例如 以 JSON 搜尋工具形式公開的自架 SearXNG 執行個體。

接著是迴圈：分類請求、定義完成條件、蒐集證據、做出決定、執行、驗證、回報。第 2 步要求先列出目錄內容，再選擇檔案；優先採用主要來源，不要依賴記憶；如果連續 2 次查詢都沒有取得新資訊，就停止。第 4 步要求在任何編輯前先寫入一行 INTENT:，說明程式碼的功能、失敗檢查所期待的內容，以及規格的要求。如果這 3 項不一致，就完全不要編輯，因為不一致本身才是實際發現。第 5 步限制重試次數：同一問題連續 3 次修正與驗證都失敗後，就停止並回傳實際輸出。

檔案中最容易測試的部分是 4 個回報 token。行為變更必須回報一行 INTENT:。對外部可見的操作必須回報 AUTH: user said "<exact words>"，並引用使用者的原話，因為 repository 已明確說明，文件不代表授權。規定應執行但實際未執行的操作，必須回報一行 PENDING:。已修正的缺陷則必須回報 TWINS: searched <pattern> - found <N> other sites。你不必相信這套方法的任何其他內容，也能檢查這 4 個字串在應出現時是否確實出現。這使整套方法變得可量測，而不是憑感覺判斷。

fable-loop 將相同方法分成 4 個階段執行協調：先由平行證據子代理進行規劃，再由主執行緒執行，接著由 1 至 3 個攻擊者子代理進行驗證，每個子代理採用不同的檢視角度，最後進行稽核與回報。它假設證據與攻擊者角色使用低成本模型，而決策與編輯則使用較強的模型。

即使捨棄其他部分，fable-judge 仍值得安裝。它的立場是：「報告是一組主張，不是證據。」它會從已完成的報告中擷取主張，依據 git diff 與 git status 建立事實基準，重新執行報告所稱已執行的每項驗證，並搜尋一份具名的舞弊清單：弱化檢查、虛假完成、範圍擴張、未經授權的操作、背離規格，以及殘留垃圾。它會回傳 VERIFIED、VERIFIED WITH CAVEATS 或 REFUTED；對於無法重現的內容，會標記為 UNVERIFIABLE，而不是假設已通過。安裝程式最後一行也指向這項功能：「試用方式：開啟 Claude Code，並在任何代理宣稱工作完成後輸入 /fable-judge。」

fable-domain 會產生包含陷阱 fixture 與 smoke eval 的領域介面套件。它隨附 8 個介面：行銷、研究、資料分析、商務與營運、財務、法律與法遵、設計與 UX，以及 devops。醫療與臨床工作則刻意不提供介面。

哪些部分可以移植到其他模型，哪些不行

存放庫直接以 AGENTS.md 回答這個問題。該檔案開頭寫著：「適用於任何 coding agent 或 harness 的可移植版本（Codex、Cursor、aider、原始 system prompt）。方法與 SKILL.md 完全相同；將此檔案貼到 agent instructions，或放在存放庫根目錄並命名為 AGENTS.md。」全文約 2,600 字，包含相同的閘門、步驟與模式。如果你已在存放庫根目錄維護 instruction files，AGENTS.md 與 HUMAN.md 慣例會說明檔案的放置位置及讀取者。

有兩個部分可以直接移植。方法文字是沒有特定模型程式碼的有序 prompt，因此任何能遵循指示的模型都能執行。存放庫提出的核心論點也是，移植效益與模型層級成反比。judge 也能移植，前提是 agent 具備 shell 和存放庫，因為它執行的所有操作都是 git diff，以及重新執行讀者也能執行的命令。

有一個部分無法直接移植。fable-loop 假設 harness 能夠啟動平行 subagents，並將它們分派給不同模型。沒有 subagents 的 agent 會在單一模型上依序執行這些階段，因此失去支撐此設計的平行處理能力與成本節省。最後只剩下具備額外術語的 fable-method。

另外有兩個較小的部分取決於 harness，且容易被忽略。/fable-method trigger 是 Claude Code 的 slash command，因此在其他 harness 上必須透過描述該方法來叫用。SKILL.md frontmatter description 讓 agent 僅在符合工作時載入本文，因此已安裝的 skill 在觸發前幾乎不會產生成本。若改為將 AGENTS.md 貼入 system prompt，這 2,600 字就會出現在你送出的每個 request 中，不論工作只是修正一行 typo，還是進行 refactor。這確實會造成成本差異，也是 skill packaging 存在的主要原因。

如何在 VPS 上進行 A/B 測試：相同工作執行兩次

設定兩份完全相同的工作副本，確保其中一次執行看不到另一次執行的修改。將 YOUR_ORG/YOUR_REPO 替換為要測試的 repository；兩份 clone 必須來自相同的 commit。

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

選擇可客觀觀察結果的工作，例如必須通過的失敗測試，或必須以 0 結束的 script。任務描述含糊時，比較結果也會含糊，因為你最後評估的是文字，而不是結果。

使用 --bare 執行 control 組。此選項會略過 hooks、skills、plugins 與 CLAUDE.md 的自動探索。這個 flag 讓它成為 control 組：先前安裝的 skills 無法混入。Bare mode 不會使用你的 subscription login，因此請先從 Claude Console 設定 API key。

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

method 組使用相同的 command，只增加一個 flag，將可攜式 method 載入為 system prompt 的附加內容：

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

相同的 binary、相同的 model、相同的 tools，以及相同的初始工作樹。兩者只有一個 flag 不同，這是比較具有意義的唯一方式。

這項設計測量的是 method 文字，不是 skill packaging；後者是另一個問題。若要測量 packaging，移除 --bare，按照上述方式安裝 skills，並將 skill 名稱放入 prompt string，因為 user-invoked skills 會在 print mode 中展開：claude -p "/fable-method $task"。即使可見行為相同，也應預期其成本特徵不同於 system-prompt 組。

計算步驟與成本

兩次執行都會寫入 JSON 事件串流。最後一行是包含最終文字、成本與工作階段中繼資料的 result 訊息。先將它只輸出一次並讀取內容，再撰寫任何依賴該輸出的腳本，因為欄位名稱會隨 Claude Code 版本變更。

tail -1 ~/ab/control.jsonl | jq .

每次執行的成本取自該行，這就是應比較的數值：

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

執行步驟數則來自計算同一檔案中的工具呼叫次數：

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

對兩個檔案都執行這項統計。差異的形態比總數更能說明問題。方法型執行讀取更多檔案、編輯更少檔案，表示它確實遵循該方法，而這正是你付出成本所換取的結果。如果方法型執行的編輯數相同，成本卻高出 40%，那麼這項任務並未因此得到任何好處。

請注意兩點。第一，不要把 ~/.claude/projects/ 下工作階段記錄中的 output_tokens 加總後視為總成本。那些每則訊息的使用量區塊是在串流期間擷取的快照，已有公開回報指出它們可能低估數值。應以 result 行的數值為準。第二，每個組別只執行一次仍只是個別案例。因此，在確認差距前，請以相同任務對每個組別執行 3 或 4 次，因為即使是同一代理程式對相同任務執行兩次，結果也可能彼此不同。若要長期檢視支出，追蹤 Claude Code 支出的工具與Claude Code 計算 token 的方式會說明為何快取項目在原始計數中占主導地位。

請確認代理程式在無人值守執行期間無法存取任何重要資源。在 VPS 上安全執行 Claude Code涵蓋使用者帳號與權限旗標的設定。

誠實解讀該 repo 自身的評估結果

README 的標題是「15 輪評估、超過 260 次代理程式執行，以及透過差異比對與執行結果驗證的盲測 LLM 評審」。這比幾乎任何 skill repo 提供的證據都多，而且 eval/RESULTS.md 逐輪記錄，並保留了失敗案例。不過，查看標題列背後的個別儲存格後，會發現實際資料量比標題中的數字所暗示的更少。

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

其中最大的 4 列，是以 4 次執行為基礎。其他 3 列各自只有 2 次執行。該 repo 在評估紀錄開頭的固定限制說明中也明確寫道：「整體樣本數很小（每個儲存格只有 1-4 次執行）、使用 LLM 評審（比較多個輸出時會盲測，但評審與其中一個基準使用相同的 frontier model）、使用合成 fixture，而且研究用 ground truth 只更新到執行日期。」更直接地說：「建立這份紀錄是為了測試方法修改，不是要讓任何人誤以為這是一項 benchmark。」

這點值得肯定。作者公開自己的 n 值，也指出評審與作為基準的模型相同所造成的問題，這在此類專案中已比一般情況誠實。應將這些數字解讀為作者確實執行測試並保留失敗案例的證據。至於你的程式碼庫，只有你自己的 A/B 測試能告訴你答案。

README 同樣清楚說明該方法在哪些情況下完全沒有作用，而這是其中最有用的一段。紀錄顯示，對於由能力足夠的模型處理的一般小型工作，沒有任何提升。文件指出：「該方法無法讓模型取得更新的事實；以知識為主的研究工作中，裸用 frontier model 會勝出。」它也將價值定位在「陷阱（權威衝突、虛假的完成聲明、能力不足的執行器、無人監看的執行），而不是所有情況」。如果你的代理程式工作只是由強大的模型進行小幅修改，而且你會在旁監看，預期完全測不到差異。如果是由較便宜的模型在無人監看的情況下執行，差距才可能出現；這也表示 在 Opus、Sonnet 與 Haiku 之間的選擇 屬於同一項決策。

套件化流於照本宣科

有 4 項批評值得提出，但沒有任何一項足以成為跳過此 repo 的理由。

論述框架超出了證據所能支持的範圍。「How Claude Fable 5 worked」是關於模型內部運作方式的主張，Anthropic 以外沒有人能驗證；而 repo 自己的核心句子也削弱了這項主張：「品質來自結構、證據與誠實，而不是模型。」如果品質取決於結構，來源故事就只是裝飾。這套程序本身即可成立，不需要虛構起源。

4 項技能的表面範圍超過內容的實際需求。fable-loop 在很大程度上重述 fable-method，只是外面包了一層協調流程；在沒有 subagent 的 harness 上，它會退化回 fable-method。安裝兩者之前，先將這 2 個檔案並排閱讀。

8 個領域 adapter 的涵蓋範圍超出 eval 的測試內容。日誌中只有 8 個 adapter 的其中 2 個曾出現：第 9 輪的 marketing，以及第 12 輪的 devops。finance、legal、design 和 data adapter 隨套件提供，但沒有任何測試輪次支援。針對你的領域所提供的 adapter 仍可能不錯。不過，它目前只是作者的草稿，尚未經過陷阱 fixture 的驗證。

此外，installer 對 repo 實際提供的內容有不同認知，將 4 項技能中的 3 項複製到 ~/.claude/skills。這個問題很小，但也反映出套件化速度快於審查進度。決定一次採用多少內容時，應記住這點。

如果其他內容都不保留，至少保留這些

移除品牌內容後，無論使用哪個 agent，仍可獨立適用以下4項規則。

• 授權引文。不可逆或面向外部的操作，必須使用使用者自己的原話，明確寫成 AUTH: 行。找不到引文的 agent 不得執行操作。
• 雙重檢查。修正缺陷後，搜尋整個專案是否存在相同的錯誤結構，並回報數量，包括數量為0的情況。
• 透過觀察進行驗證。在損壞的 build 上方僅有一項通過的針對性檢查，代表驗證失敗，不是通過。
• 以結果為先回報。任何略過或尚未驗證的內容，都必須列為限制條件，不得悄悄省略。

採用這4項規則不需任何成本，也能使用 grep 檢查是否符合。先從這裡開始，使用上述 harness 進行衡量，再決定儲存庫的其餘內容是否值得占用你的 context budget。若要提供 agent 固定的專案背景，而不是工作方法，讓 agent 在編輯前讀取 DESIGN.md 是互補的做法。

FAQ

Fable 方法能與 Claude 以外的模型搭配使用嗎？

方法本文可以。它是依序執行的提示，不含特定模型的程式碼；repo 也提供 AGENTS.md，可作為 Codex、Cursor、aider 或原始 system prompt 的可攜式副本。不過有兩項內容無法直接移植。/fable-method 與 /fable-judge 是 Claude Code 的 slash command，因此在其他環境中，您必須透過描述方法來呼叫它。fable-loop 則假設所使用的 harness 能在不同模型上平行啟動 subagent；若不具備這項能力，就只能序列執行，並需要額外步驟才能得到 fable-method。

執行這些 skill 會耗用更多 token 嗎？

會，實際增加多少取決於載入方式。以 skill 安裝後，只有在描述符合工作時才會載入本文，因此無關請求幾乎不會增加成本。若貼入 system prompt，約 2,600 個字的 AGENTS.md 會隨每個請求一併傳送。執行本身也會耗用更多成本，因為此方法要求先了解環境再編輯、先取得證據再決策，並在最後進行實際驗證。請實際測量：在兩個條件中都使用 --output-format json 執行相同工作，再比較 total_cost_usd 欄位。

我應安裝哪個版本的 fable-method？為什麼要固定版本？

安裝前先執行 git checkout v1.4.0。該 tag 的日期是 2026-07-15，截至 2026 年 8 月仍是最新版本。在此之前的 9 天內，repo 發布了 5 個版本，而 v1.4.0 直接變更了路由規則。測量期間若追蹤 main，控制組與測試組可能會讀取不同指示，導致比較結果失去意義。請將 tag 與結果一併記錄。

repo 中的 eval 是值得信任的 benchmark 嗎？

請將它視為此方法的變更日誌，這也是作者對它的稱呼：「此日誌的用途是測試方法的編輯內容，而不是讓任何人誤以為它是 benchmark。」檔案開頭已說明限制：每個 cell 執行 1 到 4 次、使用 synthetic fixture，以及採用與 baseline 相同的 frontier model 建立的 LLM judge。這些回合確實執行過，也保留了失敗的實驗，已經比多數 repo 公開的內容完整。不過，它仍無法衡量此方法在您的 codebase 上會產生什麼結果，因此請自行執行兩組比較。