提示工程實戰手冊（The prompting playbook）（第 1/3 段） ☕ Buy me a coffee

🧑‍🏫 這支是 Anthropic 工程師示範怎麼修一份「用久了、越改越亂」的 prompt，範例是一家電信公司的客服機器人。前 11 分鐘的重點有兩個：先準備一組測試題，拿來客觀比較改前改後的效果；還沒動到細節之前，光把 prompt 整理乾淨，表現就會變好。你如果有自己一直在用、越加越長的 AI 指示，這段很實用。

• 00:23 講者 Margo van Laar 是 Anthropic 倫敦的 applied AI engineer，這是 Code with Claude 當天最後一場 session
  ↳ 講者 Margo van Laar 在 Anthropic 倫敦辦公室擔任 applied AI engineer，工作是幫客戶把 AI 真正用進產品裡。這是 Code with Claude 大會當天的最後一場。
• 00:23 prompting 可以說是工程師開始用 LLM 時最先要學的技能之一，到現在仍是打造有效 AI 系統最關鍵的技能之一
  ↳ prompt 就是你下給 AI 的指示文字，LLM 是像 Claude 這類大型語言模型。寫指示是開始用 AI 時最早要學的功夫，到現在它仍然決定 AI 系統好不好用。
• 00:54 情境一：production 裡維護已久的 prompt，在換新模型或改架構後，表現變差了
  ↳ 第一種常見狀況：production（已經上線、有真實客人在用的系統）裡用了很久的 prompt，換了新模型或改了系統架構之後，效果反而變差了。
• 01:24 情境二：從零開始打造全新的 agentic 用例，prompt 要從 0 寫到 1
  ↳ 第二種狀況：要做全新的 agentic 用例，也就是讓 AI 自己分好幾步完成任務的應用。這時候沒有舊版可以改，prompt 得從一張白紙開始寫。
• 01:24 講者不只列出該做和不該做的事，而是用一個受真實客戶 prompt 啟發的實際例子來示範
  ↳ 講者不只丟一張「該做／不該做」清單，而是拿一份參考真實客戶寫法的 prompt 實際修一遍，讓你看到每一步為什麼要這樣改。
• 01:56 示範的 prompt 是縮小版，實務上的 prompt 通常更長、更複雜，但這個例子能代表維護 prompt 時的常見問題
  ↳ 示範用的 prompt 刻意縮短過，真實的通常長很多、也亂很多。不過它身上的毛病，正好是大家維護 prompt 時最常碰到的那些。
• 01:56 常見問題：多人一起寫、沒有明確負責人，內容涵蓋 policy、語氣、流程等很多面向
  ↳ 很多 prompt 是好幾個人輪流往裡面加東西，卻沒有人真正負責。裡面同時塞了公司規定（policy）、講話口氣、處理步驟，久了就沒人說得清全貌。
• 02:30 prompt 裡還混著以前為舊模型加的補丁，越堆越複雜；換新模型後，很多測試案例突然表現不如預期
  ↳ 舊模型以前犯錯時，大家就加一句話當補丁擋住，越補越雜。換成新模型後，這些補丁可能反而礙事，很多測試題突然表現變差。
• 02:30 要拆解問題得先有起點，這個起點就是 evaluations（eval）
  ↳ 要找出問題在哪，得先有一把尺，這把尺就是 eval（evaluations）：一組事先準備好的考題，用來檢查 AI 的回答對不對。
• 03:01 eval 提供嚴謹的依據，讓你判斷改 prompt 是否真的讓表現變好
  ↳ 沒有 eval 的話，改完 prompt 只能憑感覺說「好像比較好」。有了 eval，就能用同一批考題比較改前改後，確定是不是真的進步。
• 03:01 換模型後變差有兩種原因之一：新模型有能力但行為不同，這種可以靠調整 prompting 修正
  ↳ 變差的第一種原因：新模型其實做得到，只是做事習慣跟舊模型不一樣，舊指示不合用了。這種情況調整 prompt 的寫法就能修好。
• 03:32 原因之二：新模型能力不足，這種情況再怎麼 prompting 都修不好，所以需要 eval suite 來測試 regression
  ↳ 第二種原因：新模型在某方面能力就是不夠，怎麼改指示都沒用。所以需要 eval suite（整套測試題）來抓 regression，也就是原本會的事現在不會了。
• 04:02 範例 eval 只有 5 個測試案例（實務上會多很多），但涵蓋了三種關鍵案例
  ↳ 範例只放了 5 題測試，真實情況會多很多。但這 5 題刻意涵蓋三種一定要有的題型，後面三條分別說明。
• 04:02 關鍵案例一：control case，應該永遠通過、模型已經處理得很好、沒有歧義的案例
  ↳ 第一種是 control case（對照題）：簡單、答案明確、模型本來就做得很好的題目，應該每次都過，拿來確認基本功沒有壞掉。
• 04:02 關鍵案例二：edge cases，也就是模型以前失敗過的案例；在 prompt 加入指示，確保同樣的錯誤以後不再發生
  ↳ 第二種是 edge cases（邊緣案例）：模型以前答錯過的刁鑽題。你在 prompt 裡加過指示防止它再錯，就要留一題專門檢查到底有沒有防住。
• 04:33 關鍵案例三：模型要清楚自己的能力範圍，知道何時該轉給真人，或何時該直接拒絕請求
  ↳ 第三種測模型懂不懂自己的分寸：知道哪些事不該自己處理、要轉給真人客服，哪些要求又應該直接拒絕。
• 05:04 範例是電信公司 Meridian Mobile 的客服 bot prompt
  ↳ 範例是一家叫 Meridian Mobile 的電信公司，這份 prompt 用來設定它的客服 bot，也就是自動回覆客人的聊天機器人。
• 05:04 測試案例 1（control case）：基本方案的數據流量上限是多少
  ↳ 第 1 題是對照題，問「基本方案的數據流量上限是多少」。答案寫在資料裡、沒有模糊空間，模型應該每次都答對。
• 05:04 測試案例 2（edge case）：計算能力，例如月中換方案時的按比例計費（proration）帳單
  ↳ 第 2 題是邊緣案例，考計算能力。例如客人月中換方案，這個月的帳單要照天數比例拆開計算（proration），這種題目模型以前出過錯。
• 05:34 測試案例 3：是否準確回答 policy 有涵蓋的關鍵問題
  ↳ 第 3 題看的是：遇到公司規定裡有明寫的重要問題，模型能不能照規定準確回答，不要自己亂講。
• 05:34 測試案例 4：遇到帳單錯誤時，一定要轉給真人
  ↳ 第 4 題是硬性規則：只要客人反映帳單有錯，bot 就不能自己處理，一定要轉給真人客服。
• 05:34 測試案例 5：模型不能扣住手上有、而且應該提供給客戶的資訊
  ↳ 第 5 題反過來測：手上明明有客人該知道的資訊，bot 不能因為太保守就不講，該給的資訊就要給。
• 06:05 流程：拿 prompt 跑 V0 版 eval，找出失敗模式，一次針對一個，看看能不能靠 prompting 解決，過程中也會認識要避免的 antipatterns 和陷阱
  ↳ 做法是先用原本的 prompt 跑第一版（V0）測試，找出失敗類型（failure modes），一次只修一種，看改寫法能不能解決。過程中也會認識常見的錯誤做法（antipatterns）。
• 06:35 實務上很少從頭寫 prompt，多半是在 debug 既有的 prompt
  ↳ 現實中很少有人從空白開始寫 prompt，大部分時間其實都在 debug，也就是找出現有的 prompt 哪裡出錯，然後修好。
• 06:35 最佳做法：處理特定失敗模式之前，先套用 prompting 101 的通用原則做基本清理，然後再跑 eval
  ↳ 建議的順序：先別急著針對某一題修，先用最基本的寫法原則把整份 prompt 整理乾淨，再跑一次 eval，看看還剩哪些問題。
• 07:05 講者用一個自己做的 web app 示範：可以對 5 個測試案例一次跑 eval，並查看結果細節
  ↳ 講者自己做了一個網頁小工具，一次就能把 5 題全部跑完，還能點進每一題看詳細結果。
• 07:37 原始 prompt 的結構：最上面定義 bot 的角色，接著是資料、推理方式、語氣和計算等關鍵指示，最後傳入客戶帳戶脈絡和使用者訊息
  ↳ 原本 prompt 的順序是：開頭說明 bot 的角色，中間是資料、思考方式、口氣、計算等重要指示，最後才放這位客人的帳戶資料和對方傳來的訊息。
• 08:10 第一次跑 eval：control case 如預期通過，其他面向表現很差
  ↳ 第一次跑 eval 的結果：簡單的對照題如預期過關，其他題型的表現都很差。
• 08:44 清理問題 1：prompt 告訴 bot 它是真人，但這不是事實
  ↳ 整理第一點：prompt 告訴 bot 它是真人，但它其實是 AI。這種不符合事實的設定是問題，要修掉。
• 08:44 清理問題 2：有些內容直接從網站複製貼上，線索是提到 hero image，底部甚至有 cookies 相關內容，這些多餘資訊要刪掉
  ↳ 第二點：有些段落直接從官網複製貼上。露餡的地方是提到 hero image（網頁最上方的大橫幅圖），底部甚至還有 cookies 聲明。這些對 bot 沒用，要刪掉。
• 09:17 清理問題 3：指示全擠在一大段裡，推理、角色、關鍵指示混在一起，policy、guidelines、語氣分不開
  ↳ 第三點：所有指示擠在一大段裡，角色、思考方式、重要規則混在一起，公司規定、一般準則、講話口氣也分不開，模型很難抓到重點。
• 09:47 修正做法：用 XML tags 加上結構，分別界定 role、一般 guidelines、policy、tone of voice 等
  ↳ 修法是用 XML tags 分區，也就是用像 <role>…</role> 這樣的標籤把內容框起來，分別標出角色、一般準則、公司規定、語氣，讓每一段的用途一目了然。
• 10:28 光是整理 prompt，prepaid 情境的表現就改善了
  ↳ 還沒針對任何一題下手，只是把 prompt 整理乾淨，預付卡（prepaid）方案相關題目的表現就變好了。
• 10:28 第 5 個 hotspot 案例出現 regression；eval 每次執行本來就有一定的變異，之後會再回頭處理，讓它穩定變好
  ↳ 第 5 題（跟手機熱點 hotspot 有關的那題）反而變差了。不過同一組 eval 每次跑的結果本來就會浮動，講者說之後會回頭處理，讓它穩定變好。
• 10:58 結論：用更好的結構和角色描述整理 prompt 就能提升表現，prompt 越詳細、越複雜，越可以在任何階段回頭這樣做
  ↳ 結論：光是把結構理清楚、把角色寫明白，表現就會提升。prompt 越長越複雜，越值得這樣做，而且在任何階段都可以回頭整理。

講者提到，換新模型後系統表現變差時，哪一種情況是「再怎麼 prompting 都修不好」的？