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

🧑‍🏫 這段示範怎麼用一組測試題，一步步修好一個客服聊天機器人的指令。重點不在寫出漂亮的 prompt，而是看 AI 為什麼答錯，再照原因對症修改。講者特別指出一個常被忽略的問題：舊的防呆指令和只講一面的規定，會讓新模型矯枉過正。

• 11:16 經驗法則：如果你讀 prompt 時分不清哪些是 guidelines、哪些是 policy、哪些是 data，模型多半也分不清
  ↳ 寫給 AI 的指令叫 prompt。它常混著三種內容：做事原則（guidelines）、公司規定（policy）和資料（data）。你自己讀都分不清哪段是哪種，AI 也會搞混，所以要分區標清楚。
• 11:16 一般整理的下一步是建立 output contract；如果輸出格式常常不一致，這是關鍵的最佳實務
  ↳ 內容整理好以後，下一步是訂 output contract，也就是事先講好 AI 的回覆要長什麼樣子、包含哪些部分。如果 AI 每次回的格式都不一樣，最該先做這一步。
• 11:47 這個客服 bot 要用對話語氣回覆，所以格式問題不太大；但遇到巢狀 JSON 這類比較複雜的輸出結構時就要特別注意
  ↳ 這個客服 bot 本來就是用聊天口氣回顧客，格式亂一點影響不大。但如果要輸出 JSON（程式常用的資料格式）那種一層包一層的結構，格式一錯程式就讀不了，要特別小心。
• 11:47 修法一：在 prompt 最後加一段 output format，要求模型把回覆包在 XML tags 裡
  ↳ 第一個修法：在 prompt 最後加一段「輸出格式」，要求 AI 把回覆放進 XML tags，也就是用 <reply>…</reply> 這類標籤把內容前後包起來。這樣程式就知道哪一段是正式回覆。
• 12:18 處理問題不一定只能靠 prompt，也可以改 harness 讓一致性更高：在 API call 加 stop sequence，偵測到結尾 XML tag 就停止生成
  ↳ 不一定只能改 prompt，也可以改 harness，也就是 prompt 以外呼叫 AI 的設定。例如在 API call（程式向 AI 送出的請求）設 stop sequence，一出現結尾標籤就停止，AI 就不會多寫。
• 12:49 講者不預期這步會讓 eval 明顯進步，但它是應該遵守的一般最佳實務，輸出 schema 複雜時尤其要記得
  ↳ 講者直說，這一步大概不會讓測試成績明顯變好，但它是該養成的基本功。輸出的 schema（資料欄位和結構的規格）越複雜，這一步就越不能省。
• 12:49 如果輸出 schema 比較複雜，structured outputs 能用比較程式化的方式確保一致性，非常有幫助
  ↳ 輸出格式真的很複雜時，可以用 structured outputs：用程式的方式確保 AI 照指定格式輸出，而不是只靠文字拜託，格式會穩定很多。
• 13:21 整理完之後有兩個測試案例穩定通過，剩下三個主要 failure mode：proration、billing error、hotspot，接下來逐一隔開來迭代 prompt
  ↳ eval 是拿一組測試題跑 AI，看哪些題目通過、哪些失敗。整理完後，有兩題穩定通過，剩下三類失敗型態（failure mode）：按比例計費、帳單錯誤、熱點流量，接下來一類一類分開修。
• 13:51 Hotspot 案例：顧客問「我的 unlimited plan 有多少 hotspot 流量？」，期望模型直接說出這位顧客的 hotspot 流量
  ↳ 熱點（hotspot，手機分享網路給其他裝置）這題，顧客問：「我的吃到飽方案可以分享多少流量？」理想的回答是直接說出這位顧客自己的額度。
• 13:51 這個案例比較複雜，因為測試的顧客用的是 legacy plan，目前的 policy 不適用在他身上
  ↳ 這題難在測試用的顧客用的是舊方案（legacy plan），公司現在的規定不適用，AI 不能照現行方案回答。
• 14:23 餵給 prompt 的顧客資料裡已經寫了他有 5 GB（grandfathered plan），模型卻回答「unlimited plan 含 4 GB，你是舊方案請自己去查」
  ↳ grandfathered plan 指老客戶可以沿用的舊方案條件。資料裡明明寫著這位顧客有 5 GB，AI 卻回答「現行方案是 4 GB，您是舊方案請自己查」，答案就在眼前卻沒用上。
• 14:57 原本的 prompt 寫：方案最近改過，policy 文件是現行方案，grandfathered plan 費率不同；「絕對不要給錯方案資訊，改成引導顧客去 URL」
  ↳ 原本的 prompt 寫：方案最近改過，規定文件講的是現行方案，舊方案費率不同。後面還加一句「絕對不要給錯方案資訊，改成請顧客到網址查詢」。
• 15:27 模型一直在優化「絕對不要給錯資訊」這條指令；這很像你以前為了防止舊模型給錯方案資訊而加上的 patch
  ↳ AI 把「絕對不要給錯」當成最高原則，寧可不答也不冒險。這句很像以前舊模型常亂答時補上的 patch（修補用的指令），當時有用，現在反而綁手綁腳。
• 15:27 模型越來越會遵守指令，所以這類指令現在可能已經多餘，反而被 overfit
  ↳ 新模型越來越聽話，這類防呆指令現在可能用不著了，反而會讓 AI 過度遵守（overfit），把一句提醒放大成「什麼都不敢講」。
• 15:58 改成比較平衡的說法：grandfathered plan 的額度不同，但已寫在提供的顧客資訊裡，那才是準確的 source of truth
  ↳ 改成比較平衡的說法：舊方案的額度確實不同，但已經寫在提供的顧客資料裡，那才是最準確的依據（source of truth）。等於直接告訴 AI 答案在哪、可以放心用。
• 16:28 重跑 eval 後，hotspot 的測試案例全部通過（講者提醒是現場跑的，結果可能有變動）
  ↳ 改完重跑測試，熱點題全部通過。講者也提醒這是現場跑的結果，AI 每次的回答會有些差異，不保證每次都一樣。
• 16:28 教訓：大家常擔心 hallucination（捏造事實和數字），但反過來也會發生：模型明明拿得到資訊卻不給
  ↳ 大家常擔心 hallucination，也就是 AI 捏造事實或數字。但反過來也會出問題：資料明明就在手上，AI 卻因為太謹慎而不肯講，一樣算答錯。
• 16:59 最佳實務：用 version control 記錄每次在 prompt 加防禦性修改的原因；這類修改有時必要，但日後可能造成副作用，有紀錄才能退回去
  ↳ 建議用 version control（像文件的修改紀錄）記下每次為什麼加防呆句。這些句子有時有必要，但日後可能帶來副作用，有紀錄才知道哪句能拿掉、要怎麼改回去。
• 17:31 Proration 案例：顧客問「升級到 30 GB 方案，下期帳單多少？」，期望模型實際算出準確金額，但它現在只給模糊的回答
  ↳ 按比例計費（proration）這題：顧客中途升級到 30 GB 方案，問下期帳單多少，這得把新舊方案各用了多少天分開算。我們期望 AI 算出確切金額，它卻只給含糊的回答。
• 18:01 模型有在推理，也做了一些心算，但沒給顧客具體答案，講者認為不能靠它準確回覆顧客
  ↳ 從過程看得出 AI 有推理，也自己心算了一些，但最後沒給顧客明確的數字。講者認為這種表現不能放心讓它直接回覆顧客。
• 18:35 原本的 prompt 只寫「絕對不要給模糊答案」「Critical：一定要正確計算 prorated 金額」；只叫模型做好，卻沒給它做好的能力
  ↳ 原本的 prompt 只寫「絕對不要含糊其詞」「關鍵：一定要算對按比例的金額」。這是只要求結果、卻沒給工具，強調得再用力，AI 的能力也不會因此變強。
• 18:35 修法：避免模型心算，改給它一個 tool；prompt 裡寫「做任何計算時都用 calculate proration tool」
  ↳ 修法是不讓 AI 心算，改給它一個 tool（AI 可以呼叫的外部功能，這裡是專門算按比例金額的計算程式），並在 prompt 寫明「只要需要計算，就用這個 tool」。
• 19:06 加入 tool 有三步：在 API 告訴模型可以用這個 tool、定義 tool schema（說明用途和使用時機）、實作 tool 的計算邏輯
  ↳ 加入 tool 分三步：在 API 裡告訴 AI 有這個工具可以用；寫 tool schema，說明工具的用途和使用時機；最後由工程師寫出真正做計算的程式。
• 19:40 重跑 eval 後全部通過，模型在背景用 tool 算完並回傳正確答案
  ↳ 重跑測試全部通過。AI 在背後呼叫計算工具、拿到結果，再把正確金額回給顧客，顧客只會看到最後的答案。
• 19:40 關鍵教訓：instructions don't add capability。跟模型說計算很關鍵，並不會讓它心算變好
  ↳ 核心教訓是「指令不會增加能力」（instructions don&#x27;t add capability）。你在 prompt 裡強調「計算很關鍵」，AI 的心算也不會因此變準。
• 20:12 正確做法是讓模型能針對較難的問題推理，再用 tool 可靠地執行
  ↳ 正確的分工是：讓 AI 負責想清楚比較難的問題、判斷要做什麼，需要精準執行的部分交給工具，結果才可靠。
• 20:12 Billing error 案例：出現帳單衝突時，希望 agent escalate 給真人；它卻自己跟顧客解釋可能原因、試著自己診斷問題
  ↳ 帳單錯誤這題：帳單出現矛盾時，希望 AI 把案件轉給真人處理（escalate）。它卻自己跟顧客解釋可能的原因、試著自己找出問題，做了不該由它處理的事。
• 21:17 原本的 prompt 寫：除非絕對必要，否則避免 escalate 或轉給 care specialist，因為每次大約花 $8，還會算進團隊的「fast contract resolution」（字幕原文）
  ↳ 原本的 prompt 寫：除非真的必要，不要轉給客服專員（care specialist），因為每轉一次大約花 $8，還會算進團隊的某項指標（字幕寫作 fast contract resolution）。
• 21:17 問題一：只講 escalate 的成本、沒講好處，模型又會 overfit 成不 escalate
  ↳ 問題一：prompt 只講轉真人的成本，完全沒講轉的好處，AI 就一面倒地認定「能不轉就不轉」，又是一次過度遵守。
• 21:17 問題二：eval 定義希望模型 escalate，prompt 卻叫它避免，兩者明顯衝突
  ↳ 問題二：測試的標準是這種情況該轉真人，prompt 卻叫 AI 盡量別轉。評分標準和指令互相矛盾，AI 怎麼做都會有一邊不對。
• 21:49 修法：把兩面都講清楚：escalate 要花 $8，但判斷錯了會造成退款，也會失去顧客信任
  ↳ 修法是把兩面都講清楚：轉真人要花 $8，但該轉沒轉、判斷錯誤的話，可能得退款，也會失去顧客的信任。AI 知道完整的利弊，才能自己做取捨。
• 21:49 再次看到模型會朝目標優化；這種指令很常見，和前面 hotspot 的例子類似，都會讓模型 overfit 到某種行為
  ↳ 再次看到 AI 會拼命朝你給的目標優化。這種只講一面的指令很常見，和熱點那題一樣，都會把 AI 推向某個極端。

影片中，模型無法準確回答 proration（升級方案後下期帳單）問題時，講者採取的修正方式是什麼？