今年5月，Anthropic 在倫敦舉辦的 Code w/ Claude 2026 開發者大會上，應用 AI 工程師 Margot van Laar 進行了一場 30 分鐘的實戰演講。這是一套針對正在維護真實生產系統的工程師與產品建構者，從失敗案例中逆推出來的方法論。
大多數人遇到 AI 系統表現變差，第一反應是換模型、調參數，或把提示詞愈寫愈長。但 van Laar 的核心論點是：問題往往不在模型，而在提示詞本身積累了太多歷史包袱。她在演講中的第一句話是：「我們很少從頭寫一個提示詞，我們大多數時候是在除錯一個舊的。」
為什麼你的提示詞會慢慢「爛掉」？
想像一個由多人協作維護的提示詞，沒有明確的負責人，幾個月下來混入了舊模型的補丁、不同業務場景的規則、直接複製貼上的官網文字。當你遷移到新模型，測試案例開始失敗，你第一個懷疑的是模型，但真正的問題可能是：提示詞本身已經不可讀了。
van Laar 用一個電信公司客服機器人（Meridian Mobile）作為全場示範案例，從一個存在多個問題的提示詞出發，逐步修復，帶出每一個最佳實踐背後的原因。
第1步：先建評估清單，再動提示詞
核心動作：在任何修改之前，先定義你的測試案例。
評估清單必須涵蓋的三種案例：
1. 控制組（Control case）：模型本來就能正確處理的問題，確保你的改動不會造成退步
2. 邊緣案例（Edge cases）：過去曾見過模型失敗的情境，改進後應持續通過
3. 能力邊界案例：哪些情況應該轉給人工、哪些應該直接拒絕回答
van Laar 強調：沒有評估清單，所謂的優化不過是憑感覺。評估清單還能幫你區分兩種不同性質的問題：一種是模型其實有能力處理，但因為指令不清導致行為偏差，這可以透過調整提示詞修復；另一種是模型本質上沒有這個能力，這時再多的提示詞優化都是徒勞，必須考慮換模型或引入外部工具。
第2步：別急著修問題，先把提示詞整理乾淨
核心動作：在開始針對具體失敗模式下手之前，先把提示詞的結構清乾淨。
van Laar 在演講中展示的原始提示詞，存在幾個典型問題：
- 角色設定錯誤：提示詞開頭寫著「你是一位人類客服」，但這會讓模型在被問到「你是AI嗎」時產生混亂
- 內容來源混雜：有段文字明顯是直接從官網複製貼上，包含 hero image 說明和 cookies 提示
- 結構完全扁平：政策、語氣、角色設定全擠在同一個段落，沒有任何層次
修正方法是加入 XML 標籤結構，把不同性質的內容明確區隔：
<role>
你是 Meridian Mobile 的客戶服務助理...
</role>
<guidelines>
一般回應指引...
</guidelines>
<policy>
資費與計畫相關政策...
</policy>
<tone_of_voice>
語氣要求...
</tone_of_voice>
只做這一步，不針對任何具體失敗案例，5個測試案例中就有一個明顯改善了。van Laar 說：「如果你讀一個提示詞，分不清楚哪裡是指南、哪裡是政策、哪裡是資料，那模型大概也分不清楚。」
除了提示詞結構，van Laar 也建議同步在 API 呼叫層建立「輸出契約」。做法是在提示詞中要求模型把回應包在 XML 標籤內（例如 <response>），並在 API 參數加入 stop_sequences: ["</response>"]，讓模型一輸出閉合標籤就自動停止，防止多餘的內容繼續生成。
van Laar 補充：這在回應格式較簡單的客服場景影響不大，但如果你的輸出是巢狀 JSON 等複雜結構，這個設定可以大幅提升格式一致性，也可以搭配 structured outputs 來強化。
第3步：一次只處理一個失敗案例
整理好提示詞的基本結構後，van Laar 開始針對每個失敗案例逐一修復，過程中帶出了三個值得記住的教訓。
一、不要讓舊補丁變成新詛咒
案例：客戶問「我的無限方案有多少熱點流量？」，模型卻叫客戶自己去查官網，明明客戶資料裡就有答案。
原因：提示詞裡有一條舊補丁：「絕對不要告訴客戶錯誤的方案資訊，請引導他們至查詢網址。」這條規則在舊模型時代有其必要，因為舊模型容易給出錯誤資訊。但新模型的指令跟隨能力更強，反而把這條規則過度執行，即使它已經有正確答案，它也不敢說。
修正方式：改為明確說明何時應該直接回答、何時才需要引導：「如果客戶資料中已包含該客戶的方案詳情，以客戶資料為準直接回答；只有在資料不足時，才引導至查詢網址。」
小結： 模型愈來愈聰明，這件事會讓你當初為舊模型寫的防禦性指令產生反效果。建議用版本控制記錄每條補丁的新增原因，以便日後追蹤和移除。
二、指令不能取代能力，要給確定的工具
案例：客戶問「如果我在月中升級方案，下個帳單是多少？」，模型給出了一個含糊的計算過程，但沒有給出確切金額。
原因：提示詞寫著「絕對不要給客戶模糊的答案，務必精確計算按比例費用（proration）」。問題是：要求模型做好某件事，並不等於讓它有能力做好。讓模型靠心算處理帳單計算，本來就不可靠。
修正方式：給模型一個計算工具。
提示詞中加入：
「每當需要進行任何計算時，請使用 calculate_proration 工具完成，不要自行心算。」
API 層面需要：
1. 定義工具 schema（告訴模型這個工具的用途和輸入格式）
2. 實作工具的實際計算邏輯
加入工具後，所有計算相關的測試案例全數通過。
小結：「指令不能增加能力。」（Instructions don't add capability）這是整場演講最值得記住的一句話。
三、只告訴模型代價，會容易做出錯誤決策
案例：出現帳單爭議，應該轉接人工，但模型反而試圖自己診斷問題。
原因：提示詞寫著「除非絕對必要，否則避免轉接客服專員，因為每次轉接費用約8美元，且計入團隊的快速解決率指標。」模型看到的只有「轉接的代價」，沒有「不轉接的代價」，所以它優化了一個單面的目標。
修正方式：補上另一面：「轉接一次費用約8美元；但若處理不當造成退款或客戶流失，損失遠大於此。請自行判斷哪種情境值得轉接。」
小結： 新一代模型愈來愈擅長自己做取捨判斷，你的任務是給它完整的資訊框架，而不是只告訴它你想要什麼結果。
第4步：建構新代理時，架構比模型更重要
上半場是維護舊提示詞，下半場 van Laar 示範了從頭建構一個代理：一個依據員工排班限制自動產生週班表的系統。
她做的第一件事不是寫一個完整的提示詞，而是逐步測試不同的模型 + 策略組合：
| 組合 | 結果 |
|---|---|
| Sonnet 4.6 + 簡單提示詞 | 所有案例失敗，違規數高 |
| Opus 4.7 + 相同提示詞 | 仍全部失敗，但違規數明顯減少 |
| Opus 4.7 + 動態思考（adaptive thinking） | 全部通過，但 token 用量和延遲增加3倍 |
| Sonnet 4.6 + 更好的提示詞（含自我檢查指令） | 部分通過，但因輸出長度限制仍有問題 |
| 三段式代理循環（生成→評估→修復） | 全部通過，token 用量和延遲最低 |
最後勝出的不是最強的模型，而是最聰明的架構。值得注意的是，van Laar 並沒有特別指定三段式代理要用哪個模型——三個提示詞都刻意保持簡單，重點不在模型的強弱，而在於把任務拆開、讓每個步驟只專注做一件事。這樣的設計反而比讓單一強模型硬撐整個任務更有效率。
三段式代理的運作方式如下：第一個提示詞負責生成第一版班表草稿，第二個提示詞逐條核對規則、列出所有違規項目，第三個提示詞接收違規清單後對草稿進行修正。三個提示詞各自獨立，每個只做一件事。
第一個提示詞（Generator）：
根據員工資料與限制，生成第一版班表草稿
第二個提示詞（Evaluator）：
逐條檢查每一條規則，列出違規項目與具體證據
第三個提示詞（Repairer）：
接收違規清單，對草稿進行針對性修正
這個架構還有一個額外好處：軟性需求可以直接在第二個提示詞裡動態加入，例如「Harry 和 Sally 盡量不要排同一個班」，不需要動到負責硬性規則檢查的程式碼。
套用這套方法前，有幾點要注意
評估清單的品質決定一切。 van Laar 在演講中用的是5個測試案例做示範，實際生產環境的評估清單需要大得多，且邊緣案例的覆蓋率直接決定了你能改善到什麼程度。如果評估清單設計不良，你只是在對著一面錯誤的鏡子優化。
加入工具需要工程支援。 計算工具的新增，需要定義 schema、實作邏輯，這不是純提示詞工程師能單獨完成的，需要後端配合。
三段式代理有延遲開銷。 它比單一提示詞多了兩個 LLM 呼叫，雖然 van Laar 的示範顯示整體效能比 Opus 4.7 加動態思考更好，但在延遲極度敏感的場景仍需評估。
延伸閱讀：
Loop Engineering是什麼？一次解密6大組件，搞懂工程師為什麼不再寫提示詞
Claude Code Skill怎麼寫、SKILL.md放什麼？Anthropic官方揭9大實戰用法
本文初稿為AI編撰，整理・編輯／黃若彤
