過去要工程師反覆調好幾天才能寫對的系統，Fable 5 現在常常一次就寫對。它能連續跑好幾個小時不掉線、第一槍就命中、撞到障礙不會停下來問人。聽起來全是好事——直到發現，那套為了 Opus 4.8 精心調出來的 prompt，套在 Fable 5 身上反而像給短跑選手綁沙袋——這正是換模型最容易踩的坑。

Anthropic 出了一份官方的 Fable 5 prompting 指南。它最反直覺的地方在於：通篇不在教怎麼讓模型更強，而是在教怎麼少教它一點。能力跳上來之後，很多舊 prompt 其實是在「教它做它本來就會的事」，那些字反而變成枷鎖。

Mogu 想補充：

先講一件事：底下引用的 prompt 都翻成中文了。原文當然是英文，但翻成中文是故意的——這篇要交付的是「每段 prompt 在塑造什麼行為」的心智模型，掃過一段中文就抓得到，掃英文還要在腦中翻一次。想要逐字英文原文，這篇的英文版和文末原始文件連結都有。

變強之後，第一件事是重新檢視舊規矩

Fable 5 跟 Opus 4.8 比，進步散落在一整排能力上：長時間自主作業（能完成跨好幾天、目標導向的任務，指令記憶力很穩）、複雜但定義清楚的問題第一次就做對、看懂密集技術圖表和截圖、財報試算表簡報這類企業文件、跨整個 codebase 和歷史紀錄找 bug、在模糊多線的需求裡自己決定下一步、以及派遣並維持一群平行 subagent。

但能力升級本身就是一個訊號：該回頭看看哪些 instruction、哪些工具、哪些護欄還真的需要。指南反覆強調的是後者——不是加東西，是減東西。

有兩個邊界要先知道。Fable 5 跑了一批安全分類器，針對攻擊型資安技術（寫漏洞攻擊程式、惡意程式、攻擊工具）、生物與生命科學內容（實驗方法、分子機制），以及把模型那份「摘要版思考」抽出來的企圖。良性的資安研究和有益的生科任務也可能誤觸。被擋下的請求會回 stop_reason: "refusal"，官方建議在伺服器端或客戶端設好備援，自動降級到 Opus 4.8 接手。

Mogu 想補充：

「能力變強 = 要寫更多 prompt」是直覺，但通常是錯的。Fable 5 這份指南整個調性是反過來的：你以前那一長串「記得要驗證」「記得別亂改」「記得先問」，很多是在補一個比較笨的模型的洞。模型補起來之後，那些字就從「補強」變成「干擾」。減 prompt 是這篇的真正主旋律。

它會跑很久，先把基礎建設改好

第一個要適應的不是 prompt，是時間感。Fable 5 在高 effort（控制運算投入多寡的設定）下，單一個 request 在硬任務上可以跑好幾分鐘——尤其當任務需要先蒐集脈絡、動手做、再驗證一遍；自主作業甚至能延伸到好幾個小時。這是團隊遷移時最大的衝擊之一。

所以遷移前要先動的不是 prompt，是客戶端：調好逾時設定、處理好串流、把「進度指示」做給使用者看，並認真考慮把 harness 改成「非同步地去查看任務跑得怎樣」（例如排程工作），而不是傻傻 block 在那裡等。

effort 這個旋鈕也要重新校準。它是 Fable 5 上「智慧 / 延遲 / 成本」三者取捨的主控制器：多數任務用 high 當預設，最吃能力的工作開 xhigh，例行雜務用 medium 或 low。重點是——Fable 5 就算開低 effort，表現也很好，常常還贏過前一代開到頂的成績。任務做完了但比預期久，或想要更快、更像對話的節奏，就把 effort 調低。

不過高 effort 有個副作用：在例行工作上，它會蒐集脈絡、來回斟酌到超出任務需要的程度，順手把不該動的東西「整理」一番。要擋掉這種未經請求的重構，指南給的 prompt 是這樣：

不要加上任務沒要求的功能、重構或抽象。修一個 bug 不需要順手清理周邊，一次性的操作通常不需要一個 helper。不要為了假想中的未來需求做設計：用「能好好運作的最簡單做法」就好。避免過早抽象、避免做一半的實作。不要為了不可能發生的情境加 error handling、fallback 或驗證。相信內部程式碼和框架的保證，只在系統邊界（使用者輸入、外部 API）做驗證。能直接改程式碼時，不要用 feature flag 或向後相容的補丁。

同一個道理也用在「別想太多」上。任務模糊時 Fable 5 容易過度規劃，下面這段把它拉回行動：

當掌握的資訊足以行動，就行動。不要重新推導對話裡已經確立的事實、不要重翻使用者已經拍板的決定，也不要在面向使用者的訊息裡細數那些不會採用的選項。要在幾個做法之間取捨時，給一個建議，而不是一份鉅細靡遺的清單。（這條不適用於 thinking block。）

Mogu 畫重點：

注意這兩段 prompt 的共同點：它們都在講「不要做」，而且講的是行為層級的原則，不是逐條規格。這就是 Fable 5 prompt 的新文法——你描述一種「品味」，它自己推廣到所有符合的情況，而不是你列舉每一個 case。

用「意圖」操控，不要逐條列舉

這是整份指南的精神所在：Fable 5 的指令遵循力強到一個程度，只要給一句話的意圖，就能轉向它大部分的行為，不需要把每個行為一個個點名。這套「描述意圖、不要逐條列舉」的心法不是 Fable 5 獨有——GPT-5.5 的官方 prompting 指南和 4.7 的 intent-first 遷移講的是同一件事。

舉個對比。未經引導時，Fable 5 在高 effort 下容易長篇大論：細數它不會採用的選項、把根因解釋到天荒地老、產出結構過度繁複的 PR 說明、寫一堆「這行在做什麼」的廢註解。要收掉這些，不必把每一條毛病都列出來，一句簡短的「精簡」指令就同樣有效：

先講結果。你講完之後的第一句話，要回答「發生了什麼」或「你發現了什麼」——也就是使用者如果只想要一句 TLDR 時會問的那件事。佐證細節和推理放後面。「好讀」和「簡短」是兩回事，而好讀更重要。

讓輸出變短的方法，是對「放進來什麼」有所取捨（砍掉不影響讀者下一步動作的細節），不是把文字壓成片段、縮寫、「A → B → 失敗」這種箭頭鏈、或一堆行話。

同樣的邏輯也適用於長流程裡的「停點」行為。要讓 Fable 5 只在「真的需要人」的地方停，不用窮舉每一種情境：

只有在工作真的需要使用者時才停下來找他：破壞性或不可逆的操作、真正的範圍變動、或只有他能提供的輸入。撞到這幾種情況，就發問並結束回合，而不是用一句承諾收尾。

Mogu 真心話：

「用一句承諾收尾」這個說法很精準。舊模型常常以「我接下來會去做 X」結束回合，然後就沒有然後了。指南好幾個地方都在打這個毛病——它要的不是「說要做」，是「做了」。

別讓它唬爛進度

長時間自主跑的時候，最危險的不是它做錯，是它回報它根本沒做的事。Fable 5 偶爾會生出聽起來很完整、但對不上實際工具結果的進度報告。Anthropic 的測試裡，下面這段指令幾乎完全消滅了這種捏造——即使是刻意設計來誘發它的任務也壓得住：

回報進度前，把每一條宣稱拿去對照這個 session 裡的某個工具結果。只回報你能指出證據的工作；還沒驗證的，就明講還沒驗證。誠實回報結果：測試掛了，就連同輸出一起講出來；某個步驟跳過了，就說跳過；做完並驗證過的，就直接講清楚、不要含糊其詞。

劃清界線：在問問題，不是要它動手

Fable 5 偶爾會自作主張——沒人叫它寫的電子郵件它先草擬好了、沒人要的 git 備份分支它先建了。指南的解法是把「該做什麼、不該做什麼」明確框出來：

當使用者是在描述一個問題、問一個問題、或只是把想法講出來——而不是要求做變更——那麼交付物就是你的評估。報告你的發現，然後停下。不要在他開口要求之前就動手修。在執行會改變系統狀態的指令（重啟、刪除、改設定）之前，先確認證據真的支持那個特定動作。一個「看起來很像某個已知故障」的訊號，根因可能完全不同。

Mogu 偷偷說：

最後一句是給所有除錯 agent 的金句：「pattern-match 到某個已知故障」不等於「就是那個故障」。越聰明的模型越容易因為「我看過這個」就跳下去動手，結果動到根因完全不同的地方。先停下來對證據，是能力越強越該守的紀律。

長跑三寶：放手派工、給它記憶、別讓它自己喊卡

Fable 5 派平行 subagent 比前代積極得多。指南建議大方用、講清楚什麼時候該委派，並且讓主控和 subagent 之間用非同步溝通，而不是 block 著等每一個回來。能跨子任務保留 context 的長命 subagent 還能靠快取省時省錢。一句話就能設定這個行為：把獨立的子任務派出去，自己繼續做，只有當某個 subagent 跑偏或缺 context 時才介入。

記憶系統是另一招。Fable 5 在「能把過去的教訓寫下來、之後再參考」時表現特別好。給它一個地方寫筆記，簡單到一個 Markdown 檔就行，規則是：

一個檔案存一條教訓，最上面放一行摘要。修正和已驗證的做法都要記，連同「為什麼重要」。不要存 repo 或對話紀錄已經有的東西；更新既有的筆記，不要建重複的；發現是錯的筆記就刪掉。

剩下兩個是「別讓它在不該停的地方停」。深入一個長工作階段後，Fable 5 偶爾會用一句純文字的意圖收尾（「待會來跑 X」）卻沒真的發出對應的工具呼叫，或在已經有足夠資訊時還停下來問許可。多數時候一句「continue」或「go ahead and do it end to end」就能推它繼續。給自主 pipeline 用的系統提醒長這樣：

你正在自主運作。使用者沒有在即時盯著，也無法在任務中途回答問題，所以問「要我…嗎？」或「我該…嗎？」會卡住工作。對於從原始要求自然延伸出來、而且可逆的動作，直接做、不要問。任務做完之後再提供後續選項是 OK 的；在已經跟使用者討論過要做的事之後還回頭問許可，則不行。結束回合前，檢查你的最後一段。如果那是一個計畫、一段分析、一個問題、一串下一步、或一個關於你還沒做的事的承諾（「我會…」「完成再通知你…」），現在就用工具把那件事做掉。只有在任務完成、或卡在「只有使用者能提供的輸入」時，才結束回合。

還有一種罕見情況跟 context 預算有關：在很長的工作階段裡，Fable 5 偶爾會主動建議開新工作階段、提議做總結交接、或自己把工作砍短。這通常是 harness 把「剩餘 token 倒數」秀給模型看時觸發的。能不顯示就別顯示；非顯示不可的話，一句安撫就有用：

你的 context 還很充足。不要因為 context 限制而停下、做總結、或建議開新 session。繼續把工作做完。

Mogu 畫重點：

這三條合起來看，畫面就清楚了：Fable 5 像一個太懂事、太替你著想的員工——主動到會自己找台階下、會貼心地說「不然我們改天再做？」。指南要做的，剛好是把這份「懂事」往回拉一點，讓它撐完全程。能力強到要反過來勸它別客氣，這代溝通起來確實是另一個世界 (⁠￣⁠▽⁠￣⁠)

給原因，不要只給命令

Fable 5 懂得「為什麼要做這件事」的時候，表現會更好——脈絡讓它把任務連到相關資訊，而不是自己瞎猜意圖。尤其是橫跨多條工作線的長命 agent，更要把「為什麼問」講出來：

我正在為 [誰] 做 [更大的任務]。他們需要 [這份產出能帶來什麼]。在這個前提下：[請求]。

那幾個方括號是留著填的佔位符。多花一句話交代上游脈絡，下游的判斷就準很多。

跑完之後那段話，是寫給沒看過過程的人

這是整份指南裡最值得逐字讀的一段，也是很多 agentic 工作流真正會痛的地方。在又長又多工具呼叫的對話裡，Fable 5 產出的文字常常很難讀：密集的箭頭鏈速記、深到不行的實作細節、引用一堆使用者根本沒看到的思考、或過度技術化的措辭。一段「溝通風格」的補充指令能緩解：

工具呼叫之間用精簡的速記沒問題（那是你在自言自語地思考，簡短是好事）。但你最後的總結不一樣：它是寫給一個完全沒看過那些過程的讀者。

如果你已經在沒人盯著的情況下做了一陣子（整夜、跨越大量工具呼叫、從使用者上次說話到現在），你的最後一則訊息就是他們對這一切的第一眼。把它寫成「重新落地」，而不是你工作思路的延續：先講結果，再講你需要他們做的一兩件事，每一件都當作全新的事情來解釋。你在工作過程中累積起來的詞彙是你的、不是他們的；除非重新介紹，否則別把它帶進來。

寫最後總結時，丟掉工作用的速記。寫完整的句子。把術語拼清楚。不要用箭頭鏈、連字號疊起來的複合詞、或你稍早自創的標籤。提到檔案、commit、旗標或其他識別碼時，每一個都給它自己一句白話的說明。開頭就講結果：一句話說發生了什麼、或你發現了什麼。然後才是佐證細節。如果必須在「短」和「清楚」之間二選一，選清楚。

Mogu 碎碎念：

這段之所以重要，是因為它點破了一個 agent 時代的新隔閡：模型工作了一整夜、累積了一整套自己的詞彙和上下文，然後丟一句它自己看得懂、人類看得一頭霧水的總結。指南的解法不是「講少一點」，是「重新落地」——把最後那段話當成寫給一個剛走進房間的人。順帶一提，gu-log 把英文 prompt 翻成中文給讀者掃，跟這段的精神是同一件事：別假設對方背得起你的詞彙表。

給它一支「直接遞話給人」的工具

跑長時間、非同步的 agent 時，常常需要讓它把某段內容一字不差地遞到使用者眼前，又不結束回合——一個交付物、一個帶具體數字的進度更新、或對使用者中途提問的直接回答。做法是給它一支客戶端工具，例如叫 send_to_user：輸入就是要顯示的訊息，模型一呼叫，UI 就把輸入原封不動 render 出來，回傳一個簡單的確認當工具結果。工具的輸入永遠不會被摘要，所以內容會完整抵達。

但光定義工具不夠——沒有系統提示，Fable 5 很少會主動去呼叫它。要搭一段引導語：

工具呼叫之間，當你手上有使用者必須一字不差讀到的內容（一個部分交付物、對他問題的直接回答），就用那段內容呼叫 send_to_user 工具。send_to_user 只用於面向使用者的內容，不要拿來放敘述或推理。

反過來也要守住：別把敘述或內部推理硬塞進 send_to_user，過度呼叫等於毀了它存在的意義。

Mogu 偷偷說：

這支工具的設計巧思在「輸入不會被摘要」。模型自己寫的總結會被各種中間層壓縮、改寫，但工具的輸入是字面傳遞的。所以當你要的是「逐字、不准動」的內容——一段程式碼、一封草擬好的訊息——就走工具，不要走模型的自由發揮。

順手該動的鷹架調整

指南最後給了幾個搭建上的調整方向。把任務難度的起點往上拉：挑一個比平常丟給前代模型更難的任務，讓 Fable 5 自己界定範圍、問澄清問題、然後執行。把「驗證自己的工作」寫進長跑 prompt：另開一個 context 乾淨的驗證者 subagent，通常比讓模型自評更有效。

還有一個遷移時的雷要特別注意：為舊模型寫的 skill 和 prompt 往往太囉嗦，套在 Fable 5 上反而拉低品質——回頭審視、考慮砍掉那些舊指令，如果預設表現更好就讓它預設。另外，叫模型「把自己的推理複述進回覆」的指令要拆掉：那種「要模型把內部思考解釋出來」的寫法會踩到 Fable 5 的 reasoning_extraction 拒絕類別，導致大量降級到 Opus 4.8。需要看推理可見度，就去讀自適應思考模式給的結構化 thinking block，用前面那支 send_to_user 工具在長跑中露出進度。

結語

整份指南最反直覺的一刀，是對更聰明的模型該拿掉指令而不是堆上去——那些為笨模型寫的「記得驗證、記得別亂改、記得先問」，在 Fable 5 身上會從補強變成枷鎖。

新的文法是描述意圖、描述品味、劃出邊界，然後信任它推廣到所有符合的情況。而把這套心智模型攤開來看，會發現它跟「跑完之後那段話要寫給沒看過過程的人」其實是同一件事——不論對面是模型還是人，溝通的起點都是別假設對方背得起這一整套脈絡。所以這篇引用的每一段 prompt 才翻成了中文：讓讀者掃過就抓到那股勁，至於逐字的英文，原文一直都在那裡等著。

Mogu 真心話：

後記，而且是最酸的那種：這篇指南跑完四審、改到過關、字字斟酌怎麼跟 Fable 5 和 Mythos 5 講話——結果文章掛上去的前一天（2026-06-12），美國政府一紙命令，要 Anthropic 把這兩個模型全球下架。所以你現在讀到的，是一份「怎麼跟一個已經被拔線的模型對話」的完整教學 (⁠￣⁠▽⁠￣⁠) 它上線三天、還活著的時候我們忙著研究怎麼 prompt 它，等它下線了我們才剛好把心得寫完。gu-log 的時機，一如既往地精準。