010. 導讀｜Prompt engineering 不是咒語，是任務設計
Nate Herk 這支影片 How Anthropic Engineers Actually Prompt Fable 5，表面上是在講「怎麼 prompt Claude Fable 5」，但更值得抓住的其實不是模型名稱，而是背後的工作方法：高價模型不是拿來亂問的，是拿來承接你已經定義清楚的任務。
影片中講者的立場很明確：Fable 5 強，甚至在他的使用經驗裡非常強；但也因為它貴，使用方式就不能像免費聊天機器人那樣隨手丟一句「幫我想一下」。他在影片中提到，依當時他看到的資訊，Fable 5 每百萬 input token 是 10 美元、每百萬 output token 是 50 美元，並且 promotional period 有週額度限制。這些數字是否長期維持，要以官方方案為準；但作為使用策略，它提醒了一件事：越昂貴的模型，越需要清楚的使用邊界。
這篇導讀不把影片當成「六個 prompt 小技巧」來讀，而是把它整理成一張工作流地圖：什麼資訊要先給模型？什麼事要禁止？什麼任務適合 Fable 5？什麼情境該交給 Opus？如果你每天都在用 AI 寫文件、改程式、做研究或搭 agent workflow，這些問題比單一 prompt 模板更重要。
021. 先說為什麼｜模型需要意圖，不只需要指令
影片的第一條規則是給模型「why」。不要只告訴模型要做什麼，也要告訴它你為什麼要做。
這個觀念看似基本，但它其實切中很多 AI 工作流失敗的原因。許多人會把 prompt 寫成一個孤立命令：「幫我寫一封通知客戶延期的 email。」模型當然可以寫，但它只能用一般情境猜：客戶是誰？延期的是什麼？語氣要道歉、安撫、還是強勢？這封信是為了維持關係、爭取時間，還是要留下法律紀錄？如果這些都沒有，模型只會生成一封看似像信、但未必能用的信。
講者建議的做法是，把任務放回上下文裡：我正在處理什麼大任務、對象是誰、對方在意什麼、這封信要達成什麼效果。這不是「把 prompt 寫長」而已，而是把判準交給模型。
對 Fable 5 這類推理能力更強的模型來說，意圖尤其重要。越強的模型越會嘗試補完你的任務；如果你沒有說清楚，它補完的方向可能和你真正要的方向不同。反過來說，只要你給它足夠的意圖，它就比較能把零散資訊組成符合情境的輸出。
這也是為什麼講者提到 second brain 或 AI operating system。當你的資料庫、專案脈絡、客戶資訊、品牌語氣都已經結構化，prompt 就不只是單句命令，而是一個觸發模型讀取上下文的入口。好的 prompt 不只是「文字」，更像是工作流的路由。
032. 明確說不要什麼｜負面提示是品質護欄
第二條規則是 negative prompting：直接告訴模型不要做什麼。
這件事對寫作、研究、程式和商業輸出都很關鍵。模型受大量資料訓練，本能上會補足、延伸、潤飾。有時這種能力很好，能讓草稿變完整；但在專業工作裡，模型的「多做一點」常常就是錯誤來源。
例如你只說「幫我寫一篇產品介紹」，它可能自動加上浮誇口號、虛構客戶收益、過度承諾的語句。你只說「幫我整理競品」，它可能把沒有來源的推測寫得像事實。你只說「幫我改這段 code」，它可能順手重構一堆你沒有要求的地方。
因此，比起只描述理想答案，更好的 prompt 會同時列出禁止事項：
- 不要假設沒有提供的資料。
- 不要把講者的單方說法寫成事實。
- 不要使用行銷腔或過度形容詞。
- 不要新增未要求的功能。
- 不要改動既有 API 或資料結構。
- 不要輸出無法驗收的抽象建議。
這些「不要」不是限制模型，而是幫模型省掉錯誤路徑。對高價模型來說，負面提示還有成本意義：你不想花 token 讓它走一圈錯誤創意，再花更多 token 修正。把護欄先畫出來，通常比事後修稿便宜。
043. 貼近真實任務｜Prompt 越像工作現場，結果越可用
第三條規則是讓 prompt 貼近你真正要完成的事。
這一點很容易被誤解成「要寫更詳細的 prompt」。更精確地說，是要把任務寫得更像真實工作現場，而不是像測試題。模型不只需要知道你要一段文字、一份表格或一段 code，它還需要知道這份輸出要放在哪裡、誰會看、看完要做什麼、什麼情況下算成功。
一個可用的 prompt 通常包含五個元件。
第一是目標：這次到底要達成什麼？是說服、告知、比較、決策、排錯，還是產生可執行步驟？
第二是背景：目前狀態是什麼？有哪些既有素材？對象是誰？上下游限制在哪裡？
第三是限制：不要碰什麼？字數、語氣、格式、資料來源、技術框架、時間成本有沒有邊界？
第四是反例：你不想看到什麼樣的答案？哪些常見輸出雖然看起來完整，但其實不能用？
第五是輸出格式：答案要怎麼交付？是列表、PR 描述、決策 memo、測試計畫、JSON schema，還是可以直接貼進產品的文案？
這五件事湊在一起，才會讓模型知道「好」的定義。否則模型只能交出語言上漂亮、但工作上不一定有用的結果。
054. 指定風格｜不要讓模型猜你的語氣
第四條規則是給風格與參考。
很多人會期待模型「自然知道」自己想要的語氣：專業但不冷、簡潔但不粗糙、像內部 memo、像投資人更新、像產品 release note、像客服信。但如果沒有說明，模型只會回到平均語氣，也就是最常見的 AI 文字：禮貌、完整、泛用、但沒有真正的個性。
講者的建議很實用：如果你要特定風格，就把風格說出來。你可以給一段範例，說明喜歡的是它的節奏、句長、用詞密度，還是論證方式。你也可以直接列出「不要像什麼」：不要像社群貼文、不要像銷售頁、不要像學術摘要、不要像 AI 客服。
對內容工作者來說，這一步決定輸出能不能進入編輯流程。對工程工作者來說，這一步也同樣重要。你可以要求模型用既有 codebase 的命名風格、測試習慣、錯誤處理方式；你可以要求它只改最小範圍，或先列風險再改。風格不是美感問題，而是系統一致性問題。
高階模型的強項之一，是能吸收比較抽象的風格指令。但前提是你真的給它。不要讓模型猜你的審美，也不要讓它猜團隊的工作規範。
065. 降低延遲與成本｜不是每個問題都值得最高規格
第五條規則談的是效率：降低延遲與無效成本。
影片裡講者一直提醒，Fable 5 很強，但不便宜。這裡的重點不是替某個模型算帳，而是建立一個 AI 使用原則：模型能力越高，越要把它用在能創造邊際價值的地方。
如果只是把一段文字改短、把會議記錄整理成條列、幫變數命名、查一個簡單語法，使用最昂貴的模型可能只是增加延遲與成本。更好的做法是把任務拆成迭代：先用短 prompt 驗證方向，再補更多 context；先讓模型產生架構，再要求它填細節；先問「這樣的輸出方向對不對」，再讓它寫完整稿。
這種做法有兩個好處。第一，使用者可以提早發現模型理解錯誤，不必等它生成一大段才返工。第二，模型也不需要在資訊不足時硬猜，因為任務被拆成可以逐步確認的小步驟。
對 agent workflow 來說，這點更重要。很多失敗不是模型不夠聰明，而是工作被設計成一次要做太多：讀資料、判斷需求、寫稿、查證、格式化、部署，全塞進同一個 prompt。當流程太大，模型的每一步錯誤都會放大。把流程拆成明確階段，反而能讓高價模型只在關鍵節點出手。
076. 模型分工｜Fable 5 與 Opus 不該互相取代
第六條規則是保留複雜任務給真正適合的模型。講者在影片後段提到，某些情境仍然應該交給 Opus 或更擅長長鏈推理的模型：多步推理、大型重構、策略判斷、跨資料整合，或條件不完整但風險很高的工作。
這裡最有價值的觀念，是不要把模型選擇變成信仰。不是「Fable 5 比 Opus 好」或「Opus 比 Fable 5 好」，而是先問任務需要什麼腦力。
如果任務清楚、輸出格式明確、需要快速來回，Fable 5 可能是很好的選擇。它適合日常多數情境：改寫、整理、明確問題回答、小範圍規劃、根據已知上下文產出可驗收結果。
如果任務模糊、資料不足、需要深度分析、會跨多個步驟累積判斷，就應該考慮更強或更穩的模型。大型 codebase 重構、架構決策、投資判斷、複雜研究合成，不應只看單次回答速度，而要看整體錯誤成本。
這其實是 AI 團隊會越來越需要的能力：不是只會 prompt，而是會 routing。知道什麼任務可以用便宜模型，什麼任務要用快模型，什麼任務必須升級到最強模型，什麼任務甚至不該交給模型，而要先補資料、補規格、補驗收標準。
087. 編輯筆記｜把 prompt 當成一份小型規格
這支影片最實用的總結，可以濃縮成一句話：prompt 是一份小型規格。
如果你把 prompt 當成聊天，它就會產生聊天式結果。如果你把 prompt 當成願望，它就會產生看起來努力、但未必對準的結果。如果你把 prompt 當成規格，它才會開始具備可驗收性。
一份好的 prompt 會回答這些問題：
- 任務目標是什麼？
- 背景與受眾是誰？
- 哪些資料可以用，哪些不能假設？
- 哪些風格是正例，哪些是反例？
- 輸出要長成什麼格式？
- 什麼情況下需要交給更強模型？
這也是把 Fable 5 這類模型用好的關鍵。不是找到某個萬能 prompt，而是讓每次任務都有足夠清楚的目標、上下文、限制和驗收方式。
高價模型的價值不在於「它可以替你想一切」，而在於當你把問題定義清楚時，它能更快、更穩地把複雜工作推到可用狀態。換句話說，真正該升級的不只是模型，也包括我們交付任務的方式。