你有沒有遇過這種狀況：本來好好的 AI 系統，換了個新模型、或多人改了幾輪提示詞之後，反而開始亂答？多數人第一反應是換模型、調參數、把提示詞愈寫愈長。但 Anthropic 的工程師說，問題八成不在模型，在你那個堆滿歷史包袱的提示詞。這篇把她公開的整套除錯心法整理給你，外加我自己用 Claude Code 建 agent 的踩坑體會。
這套方法是誰講的？
今年 5 月，Anthropic 在倫敦的 Code w/ Claude 2026 開發者大會，應用 AI 工程師 Margot van Laar 做了一場 33 分鐘的演講，標題就叫「The Prompting Playbook」（提示詞實戰手冊）。她不是丟一堆 do's and don'ts，而是拿一個真實客服機器人的爛提示詞，當場一步步修給你看。
她開場第一句話我覺得超有共鳴：「我們很少從零寫一個提示詞，多數時候我們是在除錯一個舊的。」（We're rarely writing a prompt from scratch. We're often debugging an existing prompt.）這句話完全打中我，因為我自己在維護 AI 工作流的時候就是這樣，沒幾天就在改舊指令。
為什麼你的提示詞會慢慢「爛掉」？
想像一個提示詞，好幾個人一起改、沒有明確負責人，幾個月下來混進了：舊模型時代的補丁、不同業務場景的規則、直接從官網複製貼上的文字（van Laar 示範的那個提示詞裡，甚至還留著 hero image 說明跟 cookies 提示）。
平常還能跑，一旦你換到新模型，測試案例就開始失敗。你第一個懷疑的是模型，但真正的問題是：提示詞本身已經亂到模型自己都讀不懂了。
她全場用一個電信客服機器人（Meridian Mobile）當示範，從一個有問題的提示詞出發，跑 5 個測試案例，一個一個失敗模式去修。我把她的心法拆成兩個情境來講。
情境一：維護一個跑歪掉的舊提示詞
心法 1：先建評估清單，再動提示詞
核心動作：改任何東西之前，先定義你的測試案例。沒有評估清單，所謂的「優化」全憑感覺。
她說一份及格的評估清單要涵蓋三種案例：
1. 控制組（control case）：模型本來就答得對的、不能改壞
2. 邊緣案例（edge case）：以前看過它失敗的，改完要持續通過
3. 能力邊界：哪些要轉人工、哪些該直接拒答為什麼這麼做：評估清單還能幫你分清楚兩種問題 —— 一種是模型有能力、只是指令不清（改提示詞就能救）；另一種是模型根本沒這個能力（再怎麼改提示詞都是白費，得換模型或接外部工具）。
小結：沒有 eval，你只是在對著一面歪掉的鏡子調整自己。
心法 2：別急著修問題，先把結構清乾淨
核心動作：在針對具體失敗下手之前，先做「prompt 衛生」—— 把不同性質的內容用結構分開。
她的做法是加 XML 標籤，把角色、指引、政策、語氣明確切開：
<role> 你是 Meridian Mobile 的客服助理… </role>
<guidelines> 一般回應指引… </guidelines>
<policy> 資費與計畫政策… </policy>
<tone_of_voice> 語氣要求… </tone_of_voice>光是這一步、完全沒針對任何失敗案例，5 個測試就有一個立刻改善。她有一句話我直接抄起來：「如果你讀一個提示詞，分不清哪裡是指南、哪裡是政策、哪裡是資料，那模型大概也分不清。」
她還補一招「輸出契約」：在提示詞要求模型把回應包在 <response> 標籤裡，再到 API 加 stop_sequences: ["</response>"]，模型一輸出閉合標籤就停，不會多生廢話。客服這種簡單回覆影響不大，但你的輸出是巢狀 JSON 的話，這個設定對格式一致性差很多。
心法 3：一次只修一個失敗案例
結構清乾淨後，她開始一個一個修，過程中帶出三個我覺得最值得記的教訓。
教訓一：舊補丁會變成新詛咒。客戶問「我的無限方案有多少熱點流量？」資料裡明明有答案（5GB），模型卻叫客戶自己去查官網。原因是提示詞裡有一條舊補丁：「絕對不要給錯誤方案資訊，請引導至查詢網址。」這在舊模型時代有必要，但新模型指令跟隨太強，反而過度執行、連有答案都不敢講。修法是改成「客戶資料裡有就以資料為準直接回答，資料不足才引導」。她建議用版本控制記下每條防禦性補丁的新增原因，方便日後移除。
教訓二：指令不能取代能力，要給工具。客戶問月中升級方案下期帳單多少，模型給了一串含糊的心算、講不出確切金額。提示詞寫著「務必精確計算按比例費用」——但要求模型做好，不等於給它做好的能力。修法是給它一個 calculate_proration 計算工具（API 層要定義 schema＋實作邏輯）。加了工具，所有計算案例全過。這場演講最該記住的一句話就是：「指令不會增加能力。」（Instructions don't add capability.）
教訓三：只告訴模型代價，它會做出偏心的決策。出現帳單爭議該轉人工，模型卻自己硬要診斷。原因是提示詞只寫了「轉接約 8 美元、會影響團隊指標」——只給了一面。模型看不到「不轉接的代價」，當然偏向不轉。修法是把另一面補上：「轉接 8 美元，但處理不當造成退款或客戶流失，損失遠大於此，請自行判斷。」她說模型愈聰明愈會自己做取捨，你的任務是給它完整的資訊框架，不是只丟一個你想要的結果。
情境二：從零打造一個新 agent，架構比模型重要
下半場她示範從頭建一個 agent：根據 8 位員工的排班限制，自動生出一週班表。因為規則是硬性的，她乾脆用 Python 函式程式化檢查每張班表違規幾條，不用 LLM 當裁判。
重點是她沒有一開始就寫一個完美提示詞，而是逐步測不同的「模型＋策略」組合，看哪個最划算：
| 組合 | 結果 |
|---|---|
| Sonnet 4.6 ＋ 簡單提示詞 | 全部失敗，違規數高 |
| Opus 4.7 ＋ 同一個提示詞 | 仍全部失敗，但違規數明顯下降 |
| Opus 4.7 ＋ 動態思考 | 全部通過，但 token 與延遲都 ×3 |
| Sonnet 4.6 ＋ 更好的提示詞（含自我檢查） | 過 2/5，卡在輸出長度上限 |
| 三段式 agent 循環（生成→評估→修復） | 全部通過，token 與延遲最低 |
最後勝出的不是最強的模型，而是最聰明的架構。三段式的做法是：第一個提示詞生成班表草稿，第二個逐條核對規則、列出每個違規＋證據，第三個收到違規清單做針對性修正。三個提示詞各自獨立、每個只做一件事，刻意保持簡單。
她還點出這個架構一個額外好處：軟性需求可以在第二個（評估）提示詞裡臨時加，例如「Harry 跟 Sally 盡量別排同一班」，完全不用動到後端那支硬性規則的 Python。彈性整個拉開。
我自己怎麼用：建 agent 跟教同仁寫 prompt 都踩過
看完最有感的是，這些不是 Anthropic 工程師才會遇到的事，我自己用 Claude Code 搭 Telegram 建 AI agent 跑日常工作流時，幾乎每一條都踩過。
先講「指令不能取代能力」這條。我以前會在提示詞裡寫「請精確計算」「不要算錯」，結果它還是給我一串看起來很認真、其實不可靠的心算。後來改成把計算交給寫死的腳本、AI 只負責判斷什麼時候呼叫，整個就穩了。這跟 van Laar 給 calculate_proration 工具是同一件事 —— 該交給工具的別硬要 AI 用嘴算。
再來是「架構比模型重要」。我之前也以為換更強的模型就會更好，但真正讓我的 agent 從「常常跑歪」變成「能交差」的，是把任務拆開、每一步只專心做一件事，而不是塞一個超長提示詞要它一次搞定。跟她那張表的結論一模一樣。
最後是教學現場。我是教育訓練講師，常要教第一線同仁怎麼跟 AI 講話。「分不清指南、政策、資料，模型也分不清」這句，我會直接拿來當教材 —— 與其叫同仁把需求寫成一大段，不如教他們分段、標清楚「這是規則／這是語氣／這是資料」，產出的品質立刻不一樣。這比講一堆抽象的 prompt 技巧好用太多。
套用前，有幾點要先想清楚
評估清單的品質決定一切。她示範只用 5 個案例，真實環境要大得多。邊緣案例的覆蓋率，直接決定你能改善到哪。清單設計爛，你只是在優化一個錯的目標。
加工具需要工程支援。定義 schema、實作邏輯，不是純提示詞工程師一個人能搞定的，要後端配合。
三段式 agent 有延遲開銷。它比單一提示詞多兩次 LLM 呼叫。雖然整體效能比「Opus＋動態思考」更好，但在對延遲極度敏感的場景還是要評估。
如果你手上也有一個愈改愈亂的提示詞，我的建議是先別急著換模型 —— 今天就回去把它的結構清一遍、補一份 eval 清單，光這兩步可能就把你大半的問題解掉了。
本文整理自 Anthropic 應用 AI 工程師 Margot van Laar 在 Code w/ Claude 2026（倫敦）的演講「The Prompting Playbook」（2026 年 5 月），內容依演講影片逐字稿整理，案例與心得為作者本人補充。原始影片：https://www.youtube.com/watch?v=G2B0YWuJUgI
留言
張貼留言