產季提前結束、天候異常、品質未達出貨標準，都可能讓生鮮電商一次取消整批訂單，還要補購物金作為補償。主副單結構加上三種券型與折抵上限，人工逐張計算要花數天，金額算錯就會變成客訴。我起初照傳統方式盤出 12 條退款規則，後來決定換一種做法：不做後台按鈕，也不把所有情境寫死成 if else。我自己開發一支 AI 工具，遇到沒有把握的訂單就停下來問人；確認後的通則再經審核寫回規則。
CHALLENGE 01
真正耗時的是退款金額。 訂單分成單一訂單與主副單（拆單）；優惠券有折數型、面額型、單品折扣碼三類；折數券又會依會員等級套用不同的折抵上限，超過上限退原價，未超過則退折後價。三個維度交叉後，每張訂單都要人工查結構、加總關聯單、判斷上限、計算金額，再依序取消、補購物金、開發票、寫備註。整批處理往往要數天。
CHALLENGE 02
需求一開始很典型：營運希望後台增加「批量轉購物金」按鈕。 我也先按傳統方式，把單一訂單、主單、副單，與無券、折數券達標／未達標、面額券、折扣碼交叉展開，整理出 12 條退款規則。接著出現三個警訊：
每次會議都在增加規則，卻沒有增加同等程度的信心。 即使開發前盤得再細，上線後仍可能遇到一張從未見過的訂單。
AI 可以幫我更快展開情境，卻無法證明清單已經完整。PM 和 AI 一起窮舉，本質上仍是窮舉。
TURN
盤到第三輪，我把問題反過來：與其花數週猜完所有特殊情境，不如在使用者真的遇到那張訂單時，再由人與 AI 一起確認。
傳統做法是在需求階段定完情境，再寫成一連串 if else；日後每出現新例外，就要改程式、測試、重新部署。這個案子改用另一種結構：不做後台按鈕，營運透過對話說明要處理的訂單，由 AI 呼叫受控工具執行。流程如下：
關鍵是「必停」：遇到規則未涵蓋的訂單，AI 不猜、不算，也不執行，而是請營運先向客服確認。若答案可以成為通則，AI 會開 PR 更新規則，再由我審核；下次遇到同類訂單，就能直接套用。
需求確認不再只發生在開發前，而是持續運作的迴圈。 系統上線時不必假裝全知，但必須知道何時停下來。
DESIGN
讓 AI 執行與金額有關的動作，風險不能只靠提示詞控制。因此我把安全限制放進架構：
金額安全放在工具層，情境判斷放在規則層。 只有分開處理，系統才能同時保有安全與彈性。
BUILD
這個專案由我負責開發。 五支工具（查單、取消、補購物金、開發票、寫備註）、步驟防呆、權限表與稽核寫入，從規則設計到程式碼都由我完成，AI 是開發夥伴。
驗收標準也不是「跑得起來」。724 項單元測試全數通過，涵蓋 12 條規則與各種金額組合；測試機另外進行兩輪端對端測試，共使用 10 張真實結構的訂單，後台編輯紀錄也逐筆核對。過程中還修正一個既有 bug：補購物金的紀錄原本不會寫入建立人員。
IMPACT
最直接的效益，是把數天的人工計算縮成數分鐘的批次執行；金額則由通過 724 項測試的規則計算，不再仰賴逐張手算。
更長期的改變，是營運看見另一種需求形狀。過去請工程做功能，PM 往往得在開發前列完所有情境，討論來回數週；現在團隊知道，有些內部工具可以先定義清楚邊界，也就是什麼絕對不能做、遇到不確定時如何停下來，再讓特殊情境在實際使用中逐步補齊。
這套做法不適用所有產品功能，但對例外多、變動快的內部流程，能明顯降低前期窮舉與後續改版的成本。
LESSONS
與其假設系統已經看過所有情境，不如先教會它何時承認不會。 能在沒把握時停下來，比永遠給出答案更安全；上線也不再是賭清單是否完整，而是開始累積經過確認的規則。
STACK
C#（掛在既有後台系統上的 5 支 MCP 工具，沿用現成的取消與發票服務）、Claude Skill（GitHub 版控＋PR 審核）、名單制工具權限（SQL 生效、不用部署）、稽核雙寫（SQL 後台編輯紀錄＋Mongo 操作 log）、724 項單元測試。
內部工具，原始碼不公開。