改完 prompt 後，ai 的運行有沒有變差、能不能放行，都需要能拿出可比較的執行紀錄與事先寫好的判斷標準。

系列一開始，chatbot 明明回覆收到姓名和電話，資料卻沒有存進 DB。工程師手動測過、對話也正常結束，問題還是留到用戶和營運才發現。當時答不出來的，是憑什麼相信這次修改沒有漏掉原本該做的事。

同樣的困難，也出現在替需求方整理 ticket 的需求釐清 agent 上。它要指出驗收條件 AC 裡的問題，卻可能在填好目標、範圍之後，漏掉一個該提醒需求方的標註。

寫到最後，這隻 agent 仍未達到放行門檻。不過，現在已經能從紀錄指出它漏了什麼，也能在改動之後，依照預先訂好的條件決定停下來。

從一張卡，到能重跑的比較

最初那張優惠碼的卡有 7 條 AC，人工確認後留下 4 個問題標註。把答案寫成 goal state，也就是這筆案例通過的條件，才有依據判斷 agent 整理得對不對。這份案例檔把輸入與答案一起保存下來。

測試資料接著從一張卡擴成整份 dataset，按照 agent 可能出錯的情境挑選。輸入可以讓模型協助產生，通過條件仍由人工確認。以前測過的案例因此留在檔案裡，下次改 prompt，用 npm run run-all 就能全部重跑，不必靠人記得要再測哪些。

負責判定的 scorer 也要用正確與錯誤的產出測試，確認通過和失敗都有依據。重跑後還發現，同一份輸入不一定每次都做對，中途停止的那趟也不能當成已經判定。每次產出、判定與未完成的紀錄，都得一起留下。

開頭談改一行指示可能少標，只是推演。後來真正刪掉逐條檢查 AC 的那一行，拿 16 筆案例各跑 5 次，再讓原版與刪一行版成對開跑、各跑兩批，才留下了完整對照。

四批都跑滿後，刪一行版找到的人工標註比例，也就是 recall，兩組都低了約 5 個百分點。差距方向一致，也大於同一版本兩批之間的差距，依這次採用的工程規則，判定漏標增加。這個結論限於當次資料與條件，換個時段仍要重新比較。

下次改動時，帶著這份清單

把整套驗收收成三層，換成另一隻 agent 時，案例和門檻會不同，但每一層負責的問題仍要分清楚。

一、任務成果

• [ ] 每筆案例都保存輸入與 goal state，寫清楚最終產出哪些內容必須符合；判定程式同時用已知正確與錯誤的產出測試。
• [ ] 固定外部回應、重跑次數與放行條件，保存每次產出和判定。本系列要求 16 筆各跑 5 次、次次通過，缺趟也不能放行，並與判定失敗分開記錄。

二、必要的執行限制

• [ ] 把覆寫 AC、tag 人送出通知等會影響他人的動作逐個列出，寫清楚執行前需要什麼條件，在工具執行之前攔截。
• [ ] 每條限制都要刻意送出違規呼叫來測試，確認動作被擋、紀錄留下。不設限制的工具也要寫理由，現有規則表就是逐個檢查 7 個工具後留下的紀錄。

三、診斷與監控

• [ ] 保留 precision（標出的問題有幾成正確）、recall、各欄位判定和工具呼叫紀錄，分辨多標、漏標或執行中斷。
• [ ] 比改動前後，先確認各批跑滿，再比較同一版本的差距與兩版本的配對差距；診斷指標改善後，仍要另查結果門檻。

任務做對沒有，由最終產出判定；覆寫前是否取得同意，要看授權與執行順序。其餘工具呼叫紀錄可以協助找原因，agent 換了查資料的順序、仍然完成任務，不該只因為與參考路徑不同就扣分。

有改善，仍然可以決定不放行

最後一次實驗把 AC 問題的兩行定義寫窄，希望減少多標。precision 確實提高，卻沒達到事先訂的成功條件；整份案例反覆通過的結果門檻也沒過，因此改動沒有併入，這一版沒有放行，判定過程保存在對照紀錄。

有了這份紀錄，就不必因為某個數字變好，臨時替這次改動找一個能過的說法。即使很想採用這個修改，跑之前寫下的條件仍然適用。

目前 gate 只會攔截，尚無同意後放行的流程；記錄目標摘要的 Goal 欄位尚未接入內容品質的模型 judge，也未完成校準；資料庫查詢的唯讀檢查仍會漏擋 SELECT INTO。既有測試通過，只能證明涵蓋的條件通過，不能延伸成整隻 agent 已經可靠。

總結

這三十天留下的是一份能重跑的案例集、可核對的判定紀錄，以及任務成果、執行限制、診斷與監控三層驗收清單。刪一行指示造成的漏標增加有了證據，最後一次修改沒有達標，也照原先的條件擋下了。

一開始的困難，是修改完之後只能手動測試幾次，然後等別人發現有 bug。下次修改 prompt，已經可以先跑過保存的案例，指出哪些條件通過、哪些沒有通過，並在證據不足時決定擋下來。能在實際用戶遇到問題之前解決，就是這個系列要完成的事。