想像一個待辦事項工具。你按下「新增任務」，畫面沒有回應。再按一次，清單裡卻多了兩筆。
這裡有兩個不同的問題：功能能不能建立任務，以及你憑什麼判斷它適合交給別人使用。
以下是一個假設案例，不是真實產品或客戶事故。我們先約定一條產品規則：同一次建立操作，在約定的重試期間內，最多對應一筆任務。兩次獨立操作則可能是使用者真的想建立兩筆，不能只看標題相同就合併。
這是本例的產品承諾；重複請求與預期效果的基本區分，可參照 HTTP 規範的冪等性定義。
AI 可以協助修程式、補測試、解釋原因。交付時，仍需要有人說得清楚：目前承諾的是什麼，支持承諾的證據在哪裡，以及哪些事情還不知道。
我會把這些判斷濃縮成四行。這張卡是思考與交接輔助，不是驗收證明，也不會授權發布。
第一行：承諾
哪項行為必須成立？對象與條件是什麼？
「新增任務正常」太模糊。把這個例子的承諾寫成：「同一次建立操作，在約定的重試期間內，即使回應遺失而重試，也不應多出一筆任務。」接著把重試如何辨識、期間多長，留在規格裡說清楚。
AWS 對重試與冪等性的說明討論了這類難題：沒有收到回應，不能直接當成操作沒有發生。這裡借用的是問題，不是替任何特定實作背書。
第二行：證據
在哪個版本、環境與情境觀察到什麼？哪些還沒驗證？
「測試通過」還不足以讓接手的人知道你查過什麼。可以記下：測的是哪個版本；是否真的模擬了回應遺失後的重試；觀察到的是畫面、資料紀錄，還是兩者；測試環境和實際使用環境有什麼差別。
如果只測過一般的成功路徑，就把這個限制寫下來。證據能支持到哪裡，承諾就先說到哪裡。
第三行：失效處理
如何發現、停止擴大影響，並處理已發生的副作用？
回到那份清單：如果重複任務已經建立，還原程式版本不會自動刪掉它們。停止新的寫入、找出受影響的紀錄，以及決定如何修正，是不同的工作。
同樣地，已寄出的通知也不會因為版本回退就消失。交付判斷需要包含這些後果，不能只停在「有問題再回上一版」。
如果目前還無法可靠地發現或處理失敗，這一行可以誠實地寫：「尚未確認，需要補上觀察方式或請具備相關能力的人協助。」
第四行：判斷邊界
哪個條件改變就需重驗？哪項未知需要誰協助？
原本只有單一使用者，後來增加多人協作；原本只在一個環境測過，後來換了資料儲存方式。舊證據未必能回答新的問題。
可以選一個改變，先預測它可能影響哪個行為，再找證據核對。說得流暢不等於判斷正確；預測與實際結果不一致的地方，通常更值得追問。
這也讓「產出、控制、能力」分開被看見：產出是目前做出了什麼；控制是能否察覺與處理問題；能力則包含自己能判斷到哪裡、哪些部分需要合作。它們不是依序通關的等級。
分工仍然成立
這並不要求每位創業者理解每個函式庫的內部。成熟工具與專業分工讓人可以委託許多工作。
需要保留的是與後果相稱的理解，以及能補上未知的協作關係。個人練習工具與多人依賴的服務，需要的證據深度不會相同。填完一張卡，也不能代替合適的工程規格、專業審查與實際驗證。
我先前在為什麼 AI 會寫程式，人仍值得學程式談過規格、除錯與理解。這張卡補的是一個更小的動作：在交付之前，讓接手的人看得見你判斷的依據。
下一個小功能完成後，試著填這四行。選出一項還沒有答案的問題，帶著目前的證據，找能幫你判斷的人討論。
有時最有價值的交付，是及早說清楚那個未知。
