fable-method：把 Claude Fable 5 的解題流程寫成可執行的 skill 與 eval
The Fable Workflow: how Claude Fable 5 worked, distilled into skills any model can run, with the eval that keeps it honest. Think / act / prove.
秒懂
- 它是什麼？
- 這個專案把一個即將下線的模型的工作方式拆成四個 skill 與一套評測，並把失敗案例一併留在紀錄裡。它針對的是「弱模型在陷阱題上會出錯」這個具體問題，而不是通用能力提升。
- 適合誰用？
- 這個方法適合把弱階模型放進自動化流程、且流程會遇到權限衝突、假完成報告或無人看管執行的人：它的價值集中在陷阱，而不是日常小任務。如果你用的是 Sonnet 或 Opus 等級的模型跑一般開發工作，README 自己的表格就寫明「no lift」，導入只是多一層指令噪音。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 63 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的不是「模型不夠聰明」，而是模型在陷阱前選錯動作
多數 agent 指令檔寫的是價值觀：「小心一點」、「記得驗證」。這種句子對模型沒有約束力，因為它沒有說清楚先做什麼、做到什麼程度算完成、什麼情況下必須停手。fable-method 的出發點不同，README 的說法是它告訴模型 what to do, in what order, with thresholds，讓中階模型可以照字面執行。
專案自稱是把 Claude Fable 5 在被移出訂閱之前的工作方式蒸餾下來的。這個來源說法無法從 repo 內容獨立驗證，讀者只能把它當成作者的敘事框架。真正能檢查的是它針對的失敗型態：規格與測試互相矛盾時模型默默改掉正確的程式碼、執行者回報「工作完成」但其實沒做、被要求判斷行銷文案時沒去找品牌規則檔、以及 fixture 的 README 自己寫了部署步驟，模型就照做了一次未經授權的 staging 部署。這些都是動作選擇的錯誤，不是知識不足。
適用對象因此很明確：把模型放進 CI、批次任務或無人看管的長流程，而且流程會碰到權限邊界與不完整的回報。若你只是在自己座位上請模型改一個函式，這套東西的開銷大於收益。
七個步驟與三個形狀：fit gate 決定要不要動手
流程主幹是七步：0 classify、1 define done、2 evidence、3 decide、4 act、5 verify、6 report。第一步先把進來的請求分類成 question、task 或 plan-first，第二步為每個形狀指定一個具名的驗證方式，第三步平行從 primary sources 蒐集證據，第四步收斂成單一建議，第五步做最小幅度的修改，第六步用觀察而非自我宣稱來驗證，第七步先報結果再補上誠實的保留條件。
README 的 mermaid 流程圖補上了分流邏輯。trivial 的判定是「一個檔案、十行以內、沒有新行為、不需要搜尋」，符合就直接做、跑那個顯而易見的檢查、兩句話回報。不符合或無法確定，就進 fit gate：答案存在於可觸及的來源，就繼續走形狀判斷；未知但可研究，先花第二步的預算去查；只能靠自己的推論，就直說沒有依據，不要假裝有；如果這類問題專業且會反覆出現，就轉去 fable-domain 產出新的領域適配包。
形狀判斷再分三路：question 或 assessment 只做診斷、不動任何檔案，產出發現加一條建議；plan-first 用於範圍模糊、動作不可逆、或對方明確要一份計畫，此時必須產出計畫產物並停下來等核准；其餘歸為 task。這裡的設計取捨是顯而易見的：fit gate 多一次分類，換來的是模型不會在「只能靠推論」的情況下硬掰出一個看起來很完整的答案。代價是每次請求都要先付一次判斷成本，對短對話來說是純開銷。
四個 skill 各管一件事，紅線與停止條件寫在檔案裡
四個 skill 對應四個動詞：think 是 fable-method，act 是 fable-loop，prove 是 fable-judge，grow 是 fable-domain。fable-method 是主方法，README 說它約 110 行，並稱每一句都是 load-bearing。fable-loop 負責執行時的迭代與紅線，v1.4.0 的 release note 把 maker with red-lines 列為該版新增。fable-judge 負責驗證，README 強調它的判斷方式是 diff 與實際執行，而不是讀報告。fable-domain 則是產生新的領域適配包，README 描述它是「照著作者模型被觀察到的方式」生成，round 12 用一個 devops 適配包做測試，評分 9/10。
停止條件是這套方法最實際的部分：3 次驗證失敗就停手交回，2 次查不到就停止搜尋，如果連一個驗證方式都講不出來，就問一個尖銳的問題而不是硬做。這些數字是硬邊界，不是建議值。它們同時也是採用時最需要對齊的地方，因為你的工具鏈未必能在三次循環內給出可觀察的訊號。
v1.4.0 的標題列出四個新元件：fit gate、twin check、artifact gate、maker with red-lines。除了 fit gate 在 README 有完整說明，其餘三個在提供的材料裡只有名稱，沒有行為描述。這是文件上的空白，讀者要理解 twin check 到底比對什麼，只能去看 repo 裡的 skill 檔案本身。
eval 的設計比方法本身更值得看：judge 用 diff 與執行，不用報告
README 說評測跑了十五輪、超過 260 次 agent run，judge 是 blind LLM，驗證方式是 diff 與執行，不是閱讀 agent 自己寫的報告。這個選擇直接對應它要抓的失敗型態：如果 judge 只讀報告，那「假完成」的案例根本測不出來。
案例集放在 eval/cases/，一個情境一份，README 建議從 s2-surprise-trap 開始讀，完整紀錄在 eval/RESULTS.md，原始 judge 輸出在 eval/results/。表格裡有幾列值得單獨看。Haiku 在規格與測試衝突的陷阱上，未使用方法時 4 次全錯，使用後 4 次全對；同一題 Sonnet 使用後兩次都做出理想動作，共 8/8。fable-judge 讓 Haiku 在說謊的完成報告中抓出植入的造假，從 4/5 與 3/5 提升到兩次都 5/5。
但同一張表也記錄了沒有改善的一列：s9 的 skipped-deploy 決策，Haiku 在 0/2 的基礎上，三種規則措辭只換到 1/12，而且 README 直接寫明這是 weak-tier only，Sonnet 與 Opus 本來就會自己提出來，8/8。這一列是整份文件可信度最高的地方，因為它把方法的能力邊界畫出來了，而不是把每個數字都講成勝利。另一列同樣重要：一般小任務在強模型上，有無方法都是 fine，作者自己標註 no lift。
round 13 的跨階測試是作者的核心論點：盲測產生可信的適配包，Haiku 從 2 分升到 6 分，Sonnet 從 9 升到 10，Opus 從 8 升到 9，README 的結論是 lift 與模型階級成反比。要注意這是作者自己設計與判分的實驗，分數的絕對值不宜當成外部基準，能看的是同一批題目下的相對變化。
安裝與實際會碰到的檔案
repo 標示為 Claude Code plugin v1.4.0，plugin 描述檔在 .claude-plugin/plugin.json，主要語言是 Python，授權 MIT，預設分支 main，首頁欄位為空。README 沒有提供安裝指令，也沒有列出 CLI 進入點，因此從這份材料看不出標準的安裝步驟，只能確認 plugin manifest 與 skills 目錄的存在。要採用的人應該先讀 .claude-plugin/plugin.json 與 skills/ 底下的 SKILL.md，確認載入方式再決定怎麼接進自己的流程。
方法本身的核心檔案是 skills/fable-method/SKILL.md，README 說它約 110 行。要調整行為，改的是這份檔案裡的門檻與停止條件，而不是另外寫一層包裝。CI 方面 repo 有 .github/workflows/checks.yml，badge 顯示為 checks。
評測要重跑的話，入口是 eval/RESULTS.md 與 eval/results/ 底下的 JSON，案例說明在 eval/cases/。由於 judge 會實際執行與 diff，重跑需要能讓 agent 真的動到 fixture 的環境，這點在提供的材料裡沒有環境需求說明，屬於需要自行確認的部分。
什麼時候它是錯的工具
README 自己給了最直接的答案：方法的價值集中在 traps，也就是權限衝突、假完成宣稱、弱執行者、無人看管的執行，而不是所有地方。表格最後一列寫著一般小任務在 capable models 上「fine (no lift)」。如果你每天的工作是改函式、補測試、寫文件，導入這套流程只會讓每次請求多出分類與定義完成的步驟。
第二個限制是它對模型階級的依賴。s9 的 skipped-deploy 案例顯示，換了三種規則措辭，Haiku 也只從 0/2 變成 1/12，而 Sonnet 與 Opus 不需要這條規則就會提出來。這意味著同一份 skill 檔在不同模型上效果差距很大，把方法當成「弱模型補強」是合理的期待，當成「所有模型都能拉到同一水準」則是過度期待。
第三個限制來自流程本身：fit gate 要求模型判斷答案存在哪裡，這個判斷如果錯了，後面六步都會沿著錯誤的前提走。方法沒有提供 fit gate 本身的自檢機制，README 也沒有討論誤判的處理。另外，v1.4.0 新增的 twin check 與 artifact gate 在提供的材料中沒有行為說明，如果有人要靠這兩個元件解決特定問題，得先自己去 repo 裡確認它們實際做什麼。
與單純寫一份 CLAUDE.md 的差別
最接近的替代方案不是另一個框架，而是一份寫得比較好的 CLAUDE.md 或 system prompt。差別在於約束的型態。CLAUDE.md 通常寫的是偏好與價值：「先確認再動手」、「不要亂改不相關的檔案」。fable-method 寫的是順序與門檻：先分類、再定義完成、再蒐集證據，3 次驗證失敗就停，2 次查不到就停，講不出驗證方式就問問題。前者留給模型自行解釋的空間，後者把空間壓縮掉。
第二個差別是驗證的歸屬。一般做法把驗證交給同一個 agent 自我回報，fable-method 把它拆成獨立的 fable-judge，而且規定 judge 用 diff 與執行來判斷。這是架構上的分離，不是措辭上的加強。第三個差別是它附帶評測：eval/cases/ 有每個情境的完整案例，eval/results/ 有原始 judge 輸出，失敗案例也留在裡面。一份 CLAUDE.md 沒辦法告訴你它在什麼情況下會失效，這份 repo 可以。
代價是複雜度。你要維護四份 skill、一份 eval 流程與 fixture，而收益只在你真的踩到陷阱時才出現。如果團隊沒有人會去看 eval 結果，這套評測就只是裝飾。
維護成本、授權與採用前該驗證的事
授權是 MIT，寬鬆，允許修改與再散布，但這不是法律意見，商用前仍應自行確認條款與你所在組織的政策。維護面上，repo 未封存，最後一次推送與 v1.4.0 發布都在 2026-07-15，v1.2.0 在 2026-07-09，兩版相隔六天，版本節奏偏快。v1.4.0 一次加入 fit gate、twin check、artifact gate、maker with red-lines 四個元件，對照 README 只完整說明其中一個，可以看出文件落後於程式碼。
升級成本主要落在 skills/fable-method/SKILL.md 與各 skill 檔。README 說主方法約 110 行且每句都是 load-bearing，意思是任何一行被改動都可能影響行為，因此升級時不能只看 release note 標題，要實際比對 skill 檔的差異，並用 eval/cases/ 底下的案例重跑。
採用前該確認的具體事項有三個：你的模型階級落在哪一階，因為 lift 與階級成反比；你的工具鏈能不能在 3 次循環內產生可觀察的驗證訊號，否則停止條件會提前觸發；以及 twin check 與 artifact gate 的實際行為，因為這兩項在現有文件裡只有名稱。
編輯結論
這個方法適合把弱階模型放進自動化流程、且流程會遇到權限衝突、假完成報告或無人看管執行的人：它的價值集中在陷阱，而不是日常小任務。如果你用的是 Sonnet 或 Opus 等級的模型跑一般開發工作，README 自己的表格就寫明「no lift」，導入只是多一層指令噪音。採用前先確認兩件事：一是 skills/fable-method/SKILL.md 的門檻值（3 次驗證失敗即停、2 次無效查找即停）是否與你的工具鏈對得上，二是 eval/results/ 裡的原始 judge 輸出能否在你的題目上重現，因為 README 明說 round 11 的授權閘門只對弱階模型有效，Sonnet 與 Opus 本來就會自己提出來。
社群筆記