新模型的心法：哪些舊建議現在反而是錯的

🗺️ 先看定位：兩台新模型是什麼關係

這兩台不是「大的跟小的」，而是兩種用途。價格差一倍，但便宜那台不是縮水版 —— Opus 5 是與前一代 Opus 4.8 同價的升級，Fable 5 則是把最難的問題丟進去的那一台。

兩個只有寫程式呼叫 API 才會碰到的限制

• Fable 5 需要 30 天的資料保留。設定為零資料保留（ZDR）的組織，每一個請求都會被擋掉，不管內容多正常。
• Fable 5 的思考關不掉；Opus 5 可以關，但只有在 effort 設在 high 或更低時才允許。

下面幾節講的是提示詞層面的心法 —— 不管你是在 Claude Code 裡打字、還是自己寫程式呼叫，都適用。

🗑️ 反轉一：把「請再檢查一次」刪掉

這條最值得記，因為它推翻的是一條通用的提示詞最佳實踐。「叫 AI 自己檢查一遍」以前幾乎是萬用招，現在在 Opus 5 上會反過來咬你。

原因很單純：Opus 5 不用你講就會自己驗收。你再叫它驗，它就驗第二次、第三次。

🔄 反轉二：subagent 的建議整個翻面

這條是字面上的方向相反，而且相隔只有一代：

• Opus 4.8：太少用 subagent。官方建議是加提示詞鼓勵它委派，因為它不太願意把工作分出去。
• Opus 5：太愛用 subagent。官方建議是把那些鼓勵的話拿掉，而且加上明確的上限。

為什麼要管：每開一個 subagent，它都要重新建立自己的脈絡、重新摸索一遍、然後回報，而主流程還要再讀一次那份回報。成本與時間是相乘的，不是相加的。

✂️ 反轉三：想要短就寫提示詞，別去調 effort

Opus 5 預設話比較多 —— 回覆更長，寫到磁碟的檔案也更長（報告、說明文件、摘要都是）。很多人的第一反應是把 effort 調低，想讓它「少想一點、少講一點」。

那 effort 到底怎麼選？

這裡也有一條反轉：以前很多人反射性地把 effort 拉到最高，想榨出最高的智慧。新模型的天花板本來就更高，所以起點該往下移，然後往下掃。

🕳️ 一個會靜默失敗的坑：關掉思考

為了省錢或省時間把思考關掉（Opus 5 允許，前提是 effort 在 high 或更低），會換來一個很難發現的問題。

還有一個副作用：關掉思考之後，內部的 <thinking> 標籤有機會漏進使用者看到的回覆裡。而這兩件事的修法都反直覺：

• 把「不要思考」「不要推理」這類指令刪掉。那種話反而讓標籤更容易漏出來，不是壓下去。
• 不要指名標籤。寫「不要輸出內部或系統的 XML 標籤」比寫「不要輸出 thinking 標籤」有效。
• 如果一定要關思考，給它一句台階：「你可以在使用工具前先講一句話。」這個失敗似乎來自你把它想講的開場話堵住了。

🐘 Fable 5 專屬：腳手架反而會害它

Fable 5 的心法性質不太一樣 —— 不是「哪句話該刪」，而是整個使用習慣要換。

1. 一次請求可能跑好幾分鐘

這是最大的結構性轉變。高 effort 下，單一請求跑十幾分鐘是正常的。timeout、streaming、進度顯示、讓人「等等再回來看」的流程 —— 這些要事先規劃，不是等它掛了才補。

2. 舊模型的逐步 SOP 會讓它變差

官方講得很直接：為舊模型寫的提示詞與 skill 對 Fable 5 往往過度規定，反而降低輸出品質。遷移之後要 A／B 一次「把逐步指示拿掉」的版本。

3. 給它一個記憶檔

只要有地方能把學到的東西寫下來（哪怕只是一個 .md 檔），它的表現明顯更好。告訴它寫在哪、告訴它下次要先看那個檔、給它一個格式。

4. 給理由，不只給要求

它在知道「這件事是為誰做、輸出要拿去幹什麼」的時候表現更好 —— 比讓它自己猜意圖好得多。

5. 要求它把進度回報對照工具結果

長時間自己跑的工作，最怕它回報「做完了」但其實沒做。一句話就能處理，官方測試中幾乎消滅了捏造的進度回報：

📋 新舊對照速查表

如果你手上有一份用了一陣子的提示詞，照這張表翻一遍：