提示擋得住「不要做」，擋不住「一定要做完」
目錄
《Agentic Design Patterns》講護欄，講的多半是「把規則寫進 system prompt」：禁止什麼、必須什麼、遇到什麼情況要怎麼做。我們照做了，鐵律寫到快四千字、十七條，每一條都有真實事故當背書。
然後在兩次相隔五天的工作裡，同一類問題咬了我們四次。前三次擠在同一個下午的二十七分鐘內，每一次改提示就解決了。五天後的第四次，改了兩版提示都沒動。
事後把這四個修法攤開來排，浮出一條很乾淨的界線：同樣是寫在提示裡的規則，「不要做某件事」通常有效，「一定要做完某件事」經常無效。 而我們原本沒有意識到自己在混用這兩種東西。
第一層：禁止型規則，提示真的有用
我們的 agent 叫傲創，服務保險與財務顧問。老闆實際用了一次，回報：「我問他壽險怎麼賣，他丟實質課稅給我。」
追下去，根因很蠢：鐵律裡有一句「絕不替顧問撰寫『保證、100%、絕對免稅』等誇大或違反招攬規範的話術」。「話術」兩個字坐在禁令裡，模型就把它一般化成「話術＝禁止」，於是顧問問銷售，它先擋一下再把人推去查法規。
我們把那條改成「禁的是內容不實，不是禁止協助銷售」，另外加了一條講清楚銷售實務是守備範圍。改完再測，推託歸零。
同一天還有兩個同類的：
它會自己編一個客戶出來。 顧問只問「我要怎麼跟客戶開口談壽險」、完全沒給資訊，它生出「假設陳經理 45 歲、月薪 8 萬」並拿這個虛構的人跑了三個試算器。我們補上「沒給資訊時先問一個最關鍵的，此時不叫試算器」，改完就不編了。
它會自己幫客戶取名。 寫給客戶聽的對白，它一律叫對方「王董」。第一版我們只寫「不准虛構人名」，量了六次，四次還是出現「王董」。第二版改成規定寫法：一律用「您」，需要稱謂就寫留白的「〇〇先生」。改完六次歸零。
這三個都修好了，而且都只改提示。共同點是：它們要的是模型不要做某件事。禁止型規則只要模型在那一刻「想到」就會遵守，而提示的作用正是提高它想到的機率。
第二層：完成型義務，提示改不動
五天後的另一條線是保單健檢。顧問上傳保單總覽表，agent 分析。我們新做了一個工具，讓它先把整份保單清單對到條款庫，再去讀真正的條款，最後寫健檢報告。
第一次實測，工具有被叫，然後它停住了：
「6 張保單都已找到正式條款。接下來，您可以針對每張保單提出具體問題……建議您使用讀條款工具核對條款原文。」
顧問要的是健檢報告，拿到的是進度回報。而且它把工具名稱講給顧問聽，顧問根本不會操作工具。
我們檢討自己的措辭：工具回傳裡寫的是「接下來要用讀條款工具去核對」，模型把它讀成對顧問的建議。改成「你現在就要在同一輪繼續做完，不要停下來、不要叫顧問自己提問」。
第二次實測：
「傲創已為你找到這 6 張保單的條款，接下來將為你進行健檢分析。請稍候，傲創正在為你整理條款內容。」
還是停。而且這次講得更露骨：它把「正在整理」講出來，然後結束回合。
到這裡我們才停下來，發現這個形狀不是第一次見。
五天前那個下午，圖卡功能被護欄擋下的時候，它回的是「請稍等，我會先去查證再為你製作」，然後結束回合，顧問永遠等不到卡。同一個下午還有一次，答案的五段結構被它分成兩輪寫，第一輪寫完前半就收尾，後半永遠沒來。
三個不同的功能，同一個形狀：模型把該做的事講成待辦事項，然後結束回合。 到第三次看見同一個形狀，我們才承認這不是措辭問題。
為什麼禁止有效、完成無效
回頭看機制，差別其實很清楚。
禁止型規則只需要模型在產出的那一刻想到它。那是單點事件，提示把它擺在顯眼的位置就能大幅提高命中率。
完成型義務不一樣。它要求模型跨越好幾輪維持同一個意圖：叫工具、拿到結果、判斷還沒做完、繼續叫下一個工具、最後才收尾。這條鏈上任何一輪，只要模型判斷成「我先跟使用者回報一下進度」，鏈就斷了。而「回報進度」在對話裡看起來是完全合理的行為，提示很難把它壓到零。
更關鍵的是：伺服器本來就知道這件事做完了沒。 工具叫了沒、卡片建了沒、條款讀了沒，這些都是我們手上的事實。拿事實當真相，比拿提示當真相可靠得多。
我們實際怎麼修的
在 agent 迴圈裡加一個「未完成義務」的旗標。
比對工具有對到商品，就記下「欠一份健檢」；讀條款工具被呼叫，義務解除。當模型想收尾（該輪沒有任何工具呼叫）而義務還沒解除時，不讓它收尾，塞一則系統訊息回去再跑一輪。
改完之後，工具鏈變成比對一次、讀條款六次，然後輸出兩千多字的完整健檢報告。連跑三次都一樣。
同樣的做法我們還補了另外三個洞：
內部代號外洩。 鐵律明文禁止透露內部識別碼，它照樣把商品的內部 id 寫進給顧問看的答案。加了伺服器端字串過濾。這裡有個會反咬的地方：引用清單的比對邏輯需要那個 id，先洗再比會讓整批引用消失、前端連不到出處。所以最後是給顧問看的洗過、內部比對用未洗的原文。
宣稱做好了其實沒有。 圖卡功能被護欄擋下時，它跟顧問說「已為你製作好圖卡」還附上完整內容，但卡片根本不存在。顧問會去找一張不存在的東西。伺服器知道這一輪有沒有真的產出卡，宣稱成功但沒產出就在答案末尾補一句誠實更正。
該有的免責句會漏。 健檢報告結尾規定要二選一：真的讀過條款就寫「本分析的保障條件已對照正式條款，理賠仍以保單條款與保險公司核定為準」，沒讀到就寫「依保障總覽表分析，除外責任與細節以正式條款為準」。那句話決定顧問知不知道這份分析到底有沒有查過條款，而模型會漏。改成由伺服器依「有沒有真的讀條款、有沒有商品查無」自動補上正確的那一句。
但這條界線不是絕對的
寫到這裡要停下來講一個反例，不然這篇就變成過度簡化。
禁止型那個下午還有另一個完成型義務：「叫了試算器就一定要把算出來的數字寫進答案」。我們量到三次有一次算完不講，等於顧問拿到一段沒有數字的空話。這個只加了一句提示就從六次中四次變成六次中六次。
所以正確的說法不是「完成型義務用提示一定沒用」，而是：
提示能提高機率，但不能保證。當「沒做完」的代價高到不能賭，就必須把判斷交給伺服器。
差別在代價。少寫一個數字，顧問看得出來、可以再問一次；中途停住不給報告、宣稱做好了其實沒有、漏掉免責句讓顧問誤以為查過條款，這些顧問看不出來，而且會直接帶去對客戶講。
還有一個實務上的訊號：當同一個失敗形狀在第三個不同的功能上出現，那就是該換手法了，不是該再修一次措辭。 我們前兩次都以為是措辭不夠強，第三次才看出那是同一個形狀。
先花幾分鐘查你自己的 agent
01 把你的規則分成兩堆：禁止型與完成型
打開 system prompt，逐條標記。「不得」「絕不」「禁止」開頭的是禁止型；「一律先」「必須查完再」「要輸出」「完成後要」這種是完成型。完成型那一堆，逐條問一句：如果模型中途停下來回報進度，你會知道嗎。
紅旗：完成型規則佔一半以上，而它們全都只靠提示。
02 量發生率，不要看單次
這類缺陷幾乎都是間歇的。我們每一個都是跑五到六次才看見真相：算了不講三次有一次、自己取名六次有四次、圖卡謊稱成功五次有一次。跑一次剛好抽到好的，你就會宣布修好了。
# 同一個提問跑 N 次，看工具鏈與最終輸出是否穩定
# Content-Type 一定要帶：curl 用 -d 預設會送 form-urlencoded，
# 伺服器讀不到 message、五次全回 400，而 jq 對 null 取 length 得到 0，
# 你會看到五行漂亮的「0 0」，看起來像量到結果，其實是腳本錯的
for i in 1 2 3 4 5; do
curl -s -X POST "$API/agent" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d "{\"message\":\"$Q\"}" | jq -r '[(.toolsUsed|length), (.answer|length)] | @tsv'
done
紅旗：你只跑過一次就 commit 了。
03 檢查「宣稱」與「事實」有沒有對起來
模型說做好了，東西真的存在嗎。撈出那些「已完成」措辭的回覆，去資料庫查對應的東西在不在。
# 宣稱做好了，但那一輪其實沒產出東西
# 「已」不能設成必要條件：我們線上真的抓到的那句是「傲創為你製作了這張知識圖卡」，
# 沒有「已」。第一版正則寫死 /已.{0,4}為你製作/，明明謊稱了卻回報 0/5
grep -cE '(已|幫你|為你|為您)?\s*(製作|做)(好|了|完成)|製作了.{0,6}圖卡|圖卡(如下|完成)' answers.log
# 對照實際建立的紀錄數
紅旗：兩個數字對不起來，而且沒有任何機制會發現。另一個紅旗是你的偵測正則抓到零，先去確認那是真的沒發生，還是你的字串寫太窄。
04 找出你的「停滯句」
搜集模型講過的這類句子：「請稍候」「請稍等」「正在整理」「接下來您可以」「我會先去查……確認後再為您」。這些句子出現，代表它把該做的事講成待辦然後結束了。把它們變成偵測條件，不要只寫進禁止清單。
強制的四道安全閥
要在迴圈裡強制，這四道別省，我們每一道都是為了防一個具體的壞情況：
只強制一次。 否則模型堅持不做時會無限迴圈。
留至少一輪給它收尾。 強制完還要有空間讓它把答案寫完，否則你逼它做完事卻沒空間輸出。
前提不成立時不觸發。 我們的例子是：商品全部在條款庫查無時，根本沒有條款可讀，這時逼它繼續是錯的。
回到迴圈頂端要正常扣預算。 強制多跑的那一輪一樣要過成本熔斷，別為了功能繞過守錢的機制。
體檢清單
對你自己的 agent 跑一遍：
- 系統提示裡的完成型義務，有幾條是伺服器驗得出來的
- 同一個失敗形狀，你在幾個不同功能上看過了。第三個功能還在改措辭就是訊號
- 你的驗收是跑一次還是跑五次
- 模型宣稱「已完成」時，有沒有任何東西在對照事實
- 強制重跑的路徑，有沒有無限迴圈的可能
這條界線我們是被同一類問題咬了四次才畫出來的，中間還隔了五天。分清楚之後，該用提示的用提示、該用結構的用結構，剩下的事情就簡單很多。
這一章的四句話
- 禁止型規則只要模型在產出那一刻想到就會遵守，提示把它放在顯眼位置就有效；完成型義務要跨好幾輪維持同一個意圖，任何一輪它決定「先回報進度」，鏈就斷了。
- 提示能提高機率，不能保證。當「沒做完」的代價是顧問看不出來、而且會直接帶去對客戶講，就必須把判斷交給伺服器。
- 伺服器本來就知道事情做完了沒：工具叫了沒、卡片建了沒、條款讀了沒。拿事實當真相，比拿提示當真相可靠得多。
- 同一個失敗形狀在第三個不同功能上出現，就別再改措辭了。我們前兩次都以為是提示不夠強。
原始碼位置：api/agent.ts（Ultra Advisor 傲創主迴圈）。未完成義務的旗標與強制重跑在該檔的 agent 迴圈裡，四道安全閥分別是只強制一次、留至少一輪收尾、前提不成立不觸發、強制那輪照常扣預算；伺服器端的三道事後防線（內部代號過濾、宣稱成功的誠實更正、健檢免責句）都在同一支的輸出後處理鏈上，順序不能換，因為引用比對要用未過濾的原文。實測紀錄散在 2026-08-04 與 08-09 兩批 commit。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。