「幫我修這個付款錯誤。」

模型找到前端的錯誤處理，把逾時後的「付款失敗」改成「處理中」，補上一個測試：HTTP 逾時時，畫面不再顯示失敗。測試通過，PR 看起來也合理。

隔天，客人還是來問：「銀行已經扣款了，訂單到底有沒有成立？」畫面一直停在處理中。錯誤訊息消失了，客人的問題還在。

這是本文的虛構案例，沒有對應私人事故，也不是已完成的付款實測。它讓我們看見一個容易漏掉的問題：任務交得越大，驗收越需要能辨認「看似改善，實際沒有解決」的答案。

從修一個錯誤，走到解釋整筆付款

Felix Rieseberg 在 2026 年 10 月 13 日的〈How to be more ambitious〉鼓勵使用者重新考慮交給模型的工作。他談到加快速度、提高目標層次、深入原始資料與方法，以及跨領域協作。其中一個例子，是從修單一崩潰，改成讓模型持續維持應用程式不崩潰。

這是 Felix 的使用經驗與建議，不能直接當成模型可靠性的保證。他同時強調外部驗證，也指出要求模型扮演專家，可能只換來專業口吻。

把這個想法帶回付款案例，工單可以往上問一層：哪些路徑會讓顧客以為付款失敗，實際交易卻已成立？要回答它，模型就得一起看瀏覽器逾時、本站訂單、供應商交易結果與延遲回呼。只改畫面文字已經不夠了。

這種擴大有用。原本散在幾張工單裡的問題，可以放到同一條事件時間線上調查。但「確保付款可靠」仍然太寬，無法判斷什麼時候算完成。本案例先收斂成一個交付：重現結果未知時會誤導顧客的路徑，修好它，並列出仍無法解釋的案例。

工單修好後，還可以再往前走。假如幾週後另一個付款入口又遇到相同申訴，每次重新貼紀錄、解釋流程，模型做得再快，團隊仍在重複同一段調查。這時值得交大的工作，是把已找出的事件順序保存成可重跑案例，讓下一個版本也接受檢查。

具體來說，本案例可以先留下去識別化的事件樣本、版本對照與預期結果，再把「成功但回覆遺失」等情境放進測試流程。新版本若再次讓已知結果停在處理中，檢查就應失敗，並留下能重現的證據。這是本文建議的後續設計，尚未實作；模擬案例也不能代替供應商真實環境的驗證。

這樣才逐漸從「幫我處理這張單」，走向「協助找出這類問題何時又出現」。不必一開始就委託模型維持整個付款系統可靠；先挑一個反覆出現、資料找得到、結果分得出好壞的問題，讓下一次調查少從頭開始。

多給一段提示詞，補不出遺失的交易證據

假設模型只讀了客服摘要，建議延長 timeout、加三次重試。這個答案很容易寫，也很容易審錯。供應商可能早已建立交易，只是回覆沒有送到本站；若每次重試都被視為新付款，客人可能被扣第二次款。

要區分這兩種情況，調查至少要串起同一次操作的幾個事實：供應商收到什麼、建立了哪筆交易、本站寫入什麼、最後畫面說了什麼。事件時間要保留時鐘來源與可能偏差，程式也要對到事故當時的部署版本。

接著才有辦法設計重現：「供應商成功，HTTP 回應遺失，回呼晚到」。模型提出的修補，必須經得起這個順序。

如果請求、回呼與本地訂單沒有穩定的識別值可關聯，調查應停在這個缺口。時間接近的兩筆紀錄，可能根本是不同操作。這時交付補記欄位與觀測方案，比交出猜測的根因更有用。外部付款是否成立、能否安全重試，仍須讀實際供應商的查詢與冪等契約；本站下單收據的設計只能解決本地交易的那一段。

擴大調查也不需要同時擴大正式權限。去識別化事件、版本對照、供應商公開文件與測試環境，就能支援這一輪工作。正式退款、憑證與部署另有批准流程。讓模型看清問題，和讓它直接動客戶款項，是兩個各自要決定的範圍。

「全部顯示處理中」會通過你的驗收嗎？

回到開頭的 PR。如果驗收只有「未知時不顯示付款失敗」，把所有付款一律顯示成處理中，就可能全數通過。

這個反例值得在修改前寫下來。它會逼我們補上原先沒有說清楚的承諾：當可靠的結果已到達，流程必須能結案；仍未確認時，顧客與客服要有查詢或後續處理的途徑。

因此，本案例的驗收會走完幾條不同路徑：

  • 供應商已成功、回覆遺失：同一次操作重送不建立第二筆付款；可靠結果到達後，訂單與畫面能反映成功。
  • 供應商已確認失敗：畫面能離開處理中，說明失敗及可採取的下一步。
  • 回呼重複或晚到：不得讓已確認的狀態倒退，也不重做付款副作用。
  • 一直拿不到結果：保留查詢與人工處理路徑；超過約定的等待條件便升級處理，不能默默永久等待。

這些是待實作的驗收情境，時間界線要依供應商契約與產品政策決定。它們不保證涵蓋所有事故，卻已能淘汰那個「文案修好了，流程沒修好」的答案。

模型可以幫忙建立案例與執行工具，但不能只用自己的完成摘要證明成功。審查者要看到修補前失敗、修補後同一情境通過的結果，也要確認測試沒有被改到只剩容易通過的條件。若供應商的測試環境無法模擬某種延遲，就把那一段列為未驗證。

分工之後，還得把同一筆付款拼回來

這個問題確實需要後端、介面與客服的不同知識。後端檢查狀態轉移與重複寫入；介面檢查畫面是否說了系統還不知道的事；客服檢查未知結果該如何查證、何時交給有權限的人。

分工還應改變調查方法。後端可以從狀態轉移找出反例，介面逐一核對畫面承諾與已知結果，客服則沿查詢流程找出缺失欄位。每一方都交出可檢查的案例或流程缺口，才有辦法補進同一套重跑檢查；專業名稱本身沒有增加證據。

不過，請三個 Agent 各寫一份報告，最後都說合理，仍然可能沒有解決問題。三份報告必須對到同一個操作識別值與版本，並共同走完上述案例。否則後端驗的是交易甲，畫面展示交易乙，客服流程又假設某個根本沒保存的欄位存在。

Anthropic 的 Agent 工程文章建議從簡單方案開始，依需要增加複雜度。用在這裡，一個能取得完整材料、執行重現測試的工作流程，可以先做；只有實際缺少不同專業的檢查時，再分工。Agent 數量本身沒有提供額外的交易證據。

可以把工作交大，但要知道怎樣算沒有做好

對這個付款案例，我會把委託縮成下面這段。它是工作規格範例，並非已驗證的付款實作：

在測試環境重現「付款結果未知，卻誤導顧客」的路徑。
可讀去識別化事件、部署版本與供應商公開契約；可改工作分支與測試。
交付修補前後相同案例的結果、程式差異及仍未覆蓋的情境。
驗收同時檢查：不重複付款、已知結果能結案、未知結果有後續處理途徑。
關鍵事件無法關聯時，回報缺少的證據，不猜根因。
需要正式退款、部署或權限變更時，停下來交由有權限的人決定。
達到事先約定的時間或費用上限，交接目前結果與剩餘問題。

這裡支持 Felix 的方向：值得把反覆出現的工單，擴成一個能改善使用者結果的調查。但擴大任務的同時，必須保留能推翻方案的測試。開頭那個 PR 的缺口，在於驗收容許它把所有付款留在處理中。

下一次把缺陷交給模型前，試著寫出一個「符合工單字面，卻讓使用者更困擾」的修補。若你的測試仍會放行它，先補那個案例。這比再要求模型寫得更完整，更能決定你敢把多少工作交出去。

若這個問題反覆出現，再找出最近三張同類工單，看看是否能共用事件樣本與重現步驟。能留下可重跑的檢查，下一次就有機會在客人再次詢問前發現問題。這是值得逐步交給模型的較大工作。