Day 06 說第一個 Prompt 要交代清楚要做什麼。這篇談下一件事：做到什麼程度，才算做完。

「幫我把網站做好看一點」、「功能要正常」、「操作要好用」，這些話人看得懂，卻很難拿來驗收。好看到什麼程度才算好看？正常又包含哪些情況？

這就是 Acceptance Criteria（驗收標準）存在的原因。它有點像考卷後面的評分標準，不只說明「要做什麼」，還說明「做到什麼程度才算過關」。

與其寫：

登入功能要正常運作。

不如改成：

輸入正確帳密後可進入首頁；密碼錯誤時顯示提示；連續送出期間按鈕顯示 Loading，且不可重複提交。

差別只是多寫幾句，卻讓模糊的要求變成可以一條一條去測的東西。

沒寫到的地方，AI 會自己填

尤其是讓 AI 寫程式的時候，規格沒有寫到的地方通常不會憑空消失，而是由 AI 自己補答案。

空資料要顯示白畫面還是提示文字？API 失敗要不要重試？沒有權限時要跳轉還是顯示錯誤？送出期間要不要鎖住按鈕？（這幾類狀況在業界分別叫 Empty State、Error、Permission 與 Loading，合起來就是 Happy Path 以外的世界。）

你沒決定，它就會替你決定。

寫完之後，規格才開始有用

驗收標準最大的價值，不在寫的當下，而在寫完之後。

那幾條可測的條件可以直接貼回對話，請 AI 照著逐條檢查，或請它產出對應的測試。規格於是從「給人看的文件」變成「驗收用的工具」。

這正好接上 Day 04 說的：AI 權限越高，驗收方式就得跟著換。Agent 一次改十個檔案，你逐行讀不完；能讀的是「這幾條有沒有過」。

到頭來最常見的狀況，是雙方從一開始就對「完成」有不同的想像。

好的規格不必把每個像素都寫死，先把及格線畫清楚就好。

延伸閱讀

Adzic, G. (2011). Specification by Example: How Successful Teams Deliver the Right Software. Manning（ISBN 9781617290084）。書中收錄 50 多個團隊案例，說明如何用具體例子降低商業端、開發端與測試端之間的理解落差。這本書寫在 AI 寫程式出現之前——把「完成」定義清楚從來不是 AI 時代才有的問題，只是現在不定義的代價變得更明顯。