如果你維護過上線的 AI 功能，下面這個畫面大概不陌生。客服機器人上線時好好的，半年後同事 A 為了修一個誤導回覆加了一句指令，同事 B 為了語氣太冷加了另一句，後來模型升級成 Sonnet 4.6，結果客戶問「我這個月帳單多少」，機器人居然開始裝傻說「抱歉我無法提供」——明明那筆資料就在它眼前。
你打開那段 system prompt，往下捲了三螢幕，發現裡面政策混著語氣、語氣混著計算規則，還躺著三條是當年為某個早就下架的舊模型寫的防禦補丁。沒人記得那幾句在幹嘛，也沒人敢刪。每次「優化」都是再往這坨東西上面疊一句，然後祈禱。
這就是「提示詞越改越爛」的真實樣貌。而 Anthropic 工程師 Margot van Laar（Member of Technical Staff）在 2026 年 5 月倫敦的 Code w/ Claude 2026 開發者大會 上，用一場叫《The Prompting Playbook》的演講，把這個問題拆得很透——而且給了一套能照著做的 SOP（這場演講的完整重點，Marco Kotrotsos 在 Medium 有很詳盡的整理 ）。她的核心主張只有一句話：把提示詞當成生產程式碼來除錯，而不是當成一段可以隨手亂塞的文字。
不是模型笨，是你的 prompt 欠了一屁股技術債
van Laar 開場講了一句讓全場點頭的話：
「我們很少從頭寫一個提示詞，我們大多數時候是在 debug 一個舊的。」
這句話之所以扎心，是因為它戳破了一個幻覺：我們以為自己在「寫」提示詞，其實絕大多數時間是在「維護」提示詞。而維護一段沒有 owner、沒有版本控管、沒有測試的東西，結局只有一個——技術債利滾利。
她點出三個典型病灶。第一個最隱蔽，叫舊補丁反噬。早期的 Claude 比較容易亂編，所以大家習慣寫一堆「避免誤導使用者」「不確定就不要回答」的防守性指令。問題是 van Laar 指出，新一代模型（她以 Sonnet 4.6 這條線為例）本來就聽話得多，這些防守指令在新模型上反而過頭了，導致它連手上明明有的資料都不敢給。前面那個帳單裝傻的例子，根因就在這。
第二個是規則混雜。不同業務場景的規則全疊在同一段裡，模型分不清哪條優先、哪條只適用某情境，只好自己亂猜。第三個更基本：根本沒有可量測的成功標準，所以你永遠不知道這次改完到底是變好還是變壞，只能靠感覺。
媒體把這場演講的標題下成「問題不在模型」，其實滿準的。當系統失準，工程師的直覺通常是「換更強的模型」或「等下一代」。但 van Laar 想說的是：你換新引擎，車架的裂縫還在，它只會用不同的方式再裂一次。
真正的分水嶺：沒有 eval 的修改，不算工程
那要怎麼判斷一次修改是真的有效、還是只是換個地方爆？答案是 evaluation（評估，簡稱 eval）。van Laar 講得很直白：
「我們需要評估，來提供那種嚴謹性，去理解一次提示詞的修改，是否真的跟效能的改善有關聯。」
換句話說——沒有 eval 的提示詞修改，不是工程，是憑感覺。
這不是她一個人的偏好，而是 Anthropic 整套開發哲學的延伸。官方工程部落格〈Demystifying evals for AI agents 〉講得很清楚：eval 就是把「agent 品質」這種摸不著的概念，變成「可量測、可重複的訊號」的基礎設施。更關鍵的是它提到——當一組能力測試（capability eval）通過率夠高之後，它會「畢業」變成回歸套件（regression suite），持續跑在 CI 裡，專門抓「漂移（drift）」。任務從「我們做得到嗎？」變成「我們還能不能穩定做到？」
這就是為什麼「越改越爛」的隊伍通常都沒有 eval：他們連自己什麼時候開始爛掉的都不知道。
4 步驟，把失準的系統救回正軌
好，診斷完了，來講藥方。van Laar 的救援流程就四步，順序不能亂——很多人壞就壞在還沒建 eval 就急著改 prompt。
流程： ① 建立 eval 清單 → ② XML 結構化 → ③ 逐一修失敗案例 → ④ 用架構替代模型強度（通過後升級為回歸守門，回頭持續把關）
步驟一：先建評估清單，再碰 prompt
動任何一行字之前，先寫一份涵蓋三類案例的 eval 清單。這三類缺一不可：
| 類別 | 它是什麼 | 為什麼需要 |
|---|---|---|
| 控制組（Control） | 模型本來就該答對的標準情境 | 確保你改完沒把原本好好的東西弄壞（防回歸） |
| 邊緣案例（Edge cases） | 過去曾經出包、踩雷的情境 | 驗證你這次是真的修好了 |
| 能力邊界（Capability boundaries） | 什麼時候該轉人工、該拒絕、該說「我不知道」 | 定義系統「不該做什麼」 |
第三類最常被忽略，但它其實最重要——一個成熟系統的價值，有一半在於它知道什麼時候閉嘴、什麼時候把球丟給真人。沒有這份清單，後面所有的「優化」用 van Laar 的話講，不過是憑感覺（vibes）。
步驟二：用 XML 標籤把混在一起的東西拆開
接著處理那坨攪成一團的內容。做法不難，就是用 XML 標籤把不同職責物理性地隔開：
<role>你是 Meridian Mobile 的客服助理</role>
<policy>
優先使用客戶資料庫中的既有資料回答；
資料不足時，才引導客戶補充，不要直接拒絕。
</policy>
<instructions>
帳費計算一律呼叫 billing_calculator 工具，禁止自行心算。
</instructions>
<tone>口語、簡潔、不要過度道歉。</tone>這一步有個很反直覺的效果：光是把結構整理乾淨，往往就直接讓一部分測試案例通過了，你連內容都還沒改。原因 van Laar 一句話總結——
「模型分不清的內容，它也優化不了。」
你把 policy 跟 tone 攪在一起，模型就只能在兩者之間亂權衡；你把它們標籤分開，模型才知道哪些是硬規則、哪些是風格偏好。
步驟三：拿著 eval 清單，逐一修失敗案例
現在才開始改內容，而且是對著 eval 清單一條一條攻。這裡有三個血淋淋的教訓：
第一，主動清掉舊補丁。 前面提到的帳單裝傻案例（Meridian Mobile），修法就是把那句「避免誤導，不確定就別說」改成「優先用客戶資料，不足才引導」。一句話的方向反過來，整批測試就過了。建議對你的 system prompt 或提示詞設定檔（用 Claude Code 的話就是 CLAUDE.md）做一次舊補丁風險審計，把為已棄用模型寫的防守指令全揪出來。
第二，指令不能增加能力（instructions can't add capabilities）。 這句話我覺得是整場演講的金句。有個帳費按比例分攤的案例，模型怎麼算都算錯，工程師一開始拼命改 prompt 叫它「仔細算、一步一步算」，完全沒用。後來加了一個計算工具（tool），所有測試案例瞬間全過。重點是：模型不會的事，你用文字叮嚀一萬遍它還是不會，該給工具就給工具。 這也呼應 Anthropic〈Building Effective Agents 〉一貫的立場——算術、查表這類確定性的事，交給確定性的函式。
第三，給完整的決策框架，而不是只告訴模型「這樣很糟」。 與其寫「不要拒絕客戶」，不如寫清楚「在 A 條件下這樣做、在 B 條件下那樣做」。模型需要的是判斷依據，不是情緒勒索。
步驟四：當一個 prompt 撐不住，就用架構拆它
前三步是「把一個 prompt 修好」，第四步是「承認有些任務不該塞進一個 prompt」。怎麼判斷該不該拆？我自己抓三個訊號：
- 改 A 就壞 B：你修好一類失敗案例，另一類就回退，eval 數字在原地打轉——代表單一 prompt 同時背了互相衝突的職責。
- 規則又多又軟：任務裡塞了一堆「盡量」「優先」「除非」這種模糊的軟性約束，模型每次權衡都不穩定。
- 需求三天兩頭變：業務規則常改，但你每次都得動到核心邏輯、又得重跑全套 eval。
只要中了其中一兩個，與其繼續硬改 prompt 或換更大的模型，不如把任務拆成幾個各司其職的步驟——這就帶到下一段的主角：三段式代理。
三段式代理：生成 → 評估 → 修復
van Laar 拿「員工班表生成」當示範。這種任務的規則又多又軟（資深員工盡量排早班、連續夜班不能超過幾天、某些人不能同時段……），塞進一個 prompt 裡保證爆炸。她的做法是拆成三個各自簡單的提示詞，串成一條流水線：
流程： 生成器（依員工資料產出初版班表）→ 評估器（逐條檢查規則、列出違規與證據）→ 修復器（針對違規清單精準修正）→ 仍有違規則回到評估器
- 生成器：吃員工資料，吐出初版班表，不用想太完美。
- 評估器：拿規則一條一條檢查，列出哪裡違規、證據是什麼。
- 修復器：拿著違規清單做針對性修正。
這個架構最漂亮的地方在於：軟性需求可以直接在評估層動態加，完全不用碰核心生成邏輯。 老闆臨時說「這週讓 Amy 多排一點」，你在評估器加一條規則就好，生成器一個字都不用動。這其實就是 Anthropic〈Building Effective Agents〉裡講的 evaluator-optimizer（生成器產出、評估器回饋、不斷迴圈直到通過）模式的具體應用，只是套在真實業務上。
而且——這是最打臉「大模型萬能論」的部分——根據第三方對這場演講的整理分析（以下數字非 Anthropic 官方發布，僅供參考量級），效能對比呈現出拆解架構贏過硬堆算力的結果：
※ 下表數字（α 值、token 數、通過率）為第三方分析估算，非 Anthropic 官方數據，僅用來看量級、不要直接截圖當官方結論引用。
| 方案 | 結果 |
|---|---|
| 簡單單一提示詞 | 失敗率高 |
| 五代理群體（5-agent swarm） | α = 0.625，低於基準 |
| 生成→評估→修復三段迴圈 | 5/5 全過，6,449 tokens 內完成 |
| Opus + 動態思考（extended thinking） | 會過，但 token 與延遲都更貴 |
也就是說，Sonnet ＋ 改好的 prompt ＋ 三段式架構 直接打贏 Opus ＋ extended thinking，又快又省。
這裡還藏了一個反直覺結論：代理不是越多越好。那個五代理群體反而掉到基準以下，因為每個子代理都只在做「提示工程」，卻沒有人嵌入完整的上下文、意圖跟規格。一盤散沙的多代理，還不如一個結構清楚的單一系統。這點 interestingengineering 的延伸分析 講得很到位，大意是：提示詞治理「系統怎麼想」，但能力天花板是由設計（能看到什麼）跟工具（能算什麼）決定的——三者要協同，不是把寶全押在 prompt 上。
別過度樂觀：這套方法的邊界
講了這麼多好處，也得誠實說它的天花板，免得你照單全收又踩坑。
第一，長時間自主運行會撞牆。當代理連續自主跑久了，「對話式 prompt」的那套假設會逐漸失效，這時候要靠的是 checkpoint、記憶體管理這類架構手段，不是再多寫幾句指令。有第三方分析提到「跑超過約莫半小時就是個坎」，但這個量級沒有官方定義、會隨任務與模型而變，聽聽就好、別當硬指標。
第二，算術類問題別硬用 prompt 解。利息、按比例分攤這些，請一律丟給確定性的工具函式——這其實就是「指令不能增加能力」的同一件事，講第二遍是因為太多人還在這上面浪費生命。
第三，意圖工程（intent engineering）仍是未解的缺口。van Laar 的流程很擅長「修已知的失敗」，但系統缺乏一個閉環的事後校準機制，導致它給出的「信心分數」其實沒被校準過。這比較像是營運規程要補的洞，不是改 prompt 能解決的。
順帶一提，這也是為什麼 Anthropic 官方 prompt engineering 文件 一開頭就叫你「先定義成功標準、先建立評估」——跟 van Laar 講的完全是同一件事。
結語：把 prompt 當程式碼，從今天就能開始
這套方法真正的重點，從頭到尾不是某句魔法咒語，而是一個心態的轉變：提示詞是會累積技術債的生產資產，不是可以隨手亂塞的便利貼。
如果你手上正好有一個「越改越爛」的 AI 系統，把前面四步收斂成一張這週就能勾的 checklist：
- 幫每個生產 prompt 指定一個明確的 owner，丟進 git 版控。
- 改任何 prompt 之前，先寫好含「控制組／邊緣案例／能力邊界」三類的 eval 清單，塞進 CI 當守門員。
- 對舊的
CLAUDE.md跟 system prompt 做一次補丁審計，把為已下架模型寫的防守指令揪出來。 - 用 XML 標籤把 role / policy / instructions / tone 物理分家。
- 凡是計算類需求，一律改用 tool。
- 複雜任務優先想「能不能拆成生成→評估→修復」，而不是「要不要換更大的模型」。
說到底，AI 系統失準的時候，最貴的解法往往是換模型、加算力；而 van Laar 想告訴我們的是——最有效的解法，常常是回去把那段沒人維護的 prompt，當成程式碼好好重構一次。
你手上那段半年沒人敢動的 system prompt，今天要不要先幫它建一份 eval？
參考資料
- The Prompting Playbook — Code w/ Claude 2026（議程頁）
- Demystifying evals for AI agents — Anthropic Engineering
- Building Effective AI Agents — Anthropic
- Prompt engineering overview — Claude Docs
- The Prompting Playbook: Debugging Prompts Like Production Code — Marco Kotrotsos, Medium
- The Prompt Is Not the Architecture — interestingengineering
註：本文部分量化數據（5/5 通過率、6,449 tokens、五代理 α=0.625）出自第三方對演講的整理與分析，未經 Anthropic 官方逐字確認；效能對比為單一班表生成案例的結果，不宜外推為所有任務的通則。
