­▋反直覺、也反主流的做法：­
­­
­負責「控場」的 Orchestrator 用 Opus­
­真正「下去寫程式」的 Dev 用 Fable­
­­
­我現在基本上只有 Dev 任務用 Fable­
­其他任務像是規劃、Explore、Code Review­
­都用 Opus 或 Codex­
­­
­對於用 SDD 開發來說­
­這樣可以省下不少 Token­
­­
­這個做法一開始聽起來反直覺­
­因為很多人會覺得 Fable 比較強­
­就應該讓它負責規劃、決策、Review 這種高價值任務­
­­
­但我實際用下來­
­反而覺得 Fable 最值得花的地方­
­是放在「第一線開發」­
­­
­因為 Fable 的可靠性夠高­
­第一線實作時­
­如果遇到規劃階段沒先想到的問題­
­它通常可以根據我的 Context­
­做出符合我想法的判斷­
­­
­這部分我覺得和 Context 完整度有關­
­也因此反而省下「做錯再改」所浪費的 Token­
­­
­我試過讓 Fable 一路跑到掛­
­大概 3 個 5h session­
­就能用完一週限額（心好痛）­
­­
­改用這個做法後­
­昨晚睡前跑一整晚­
­醒來它還在跑（可以算是 2 個 5h session）­
­大概只用掉 30% Fable 週限額­
­­
­最有感的差別在於 Loop 做任務的完成數量­
­明顯感受到同樣時間內­
­Fable 可以完成更多任務­
­因為要完成一個 Story­
­會經過規劃、開發、Review、QA、部署測試站、實機 E2E 測試­
­­
­Fable 明顯感受到的是穩定性­
­不會一直莫名停下來問我過度謹慎的白痴問題­
­­
­▋需要規劃或動腦的任務，我還是先用 Opus­
­­
­這部分和原本 Fable 出來前的做法都一樣­
­等到我覺得討論或是規劃得差不多了­
­­
­我會說­
­­
­「用 Fable 分析目前計劃­
­Review 有沒有問題­
­以及有沒有可以優化的方案」­
­­
­這樣比一開始就用 Fable 啟動省得多­
­而且看到 Fable 說沒什麼問題­
­還會覺得很爽，賺爛了­
­要是它提出很棒的建議­
­還能順便讚嘆 Fable 太神了吧­
­­
­▋7/7 之後，訂閱就不能用 Fable 了­
­­
­但理論上你有兩條 Fable 血條­
­在 7/7 前­
­如果剛好會遇到週用量重置­
­記得趕快把第一條用完­
­­
­用完後，週用量重置­
­Fable 血條也會重置­
­只是第二條血可用的窗口可能會很短 🥲­
­加緊用­
­過了這個村就沒這個店­
­­
­如果你好奇為何我可以一直測試­­
­目前我有 5 個 Max 20x 訂閱­帳號
­（是 Anthropic 課長啊 XD）­
­以上的心得用掉了 5 個 Fable 週扣打­