先記住：檢核表只阻擋高風險未知，不必每次寫大文件。
需要深入時：再補完整分析。

寫了很多筆記，怎麼還是不知道能不能開始？

我們在前六天談了目標、狀態、估時與契約。
如果把所有名詞排成一張五十題清單，看起來很厲害是沒錯，但其實每次開發都懶得打開。

我心中想要的檢核表比較像開工前的對話：哪些事情已經足夠清楚，可以往前；哪些未知會改變安全或核心流程，必須先解決。

先用同一個案例填一次

需求是會員套用優惠券。目標是在付款前確認折扣後總額。
一次一張券是本次假設；是否允許原價繼續結帳，尚待產品確認。

前端負責輸入、狀態與錯誤呈現；伺服器負責優惠資格與金額。
送出後商品改變，舊報價不能直接使用。
這幾句話已經把角色、規則、邊界與狀態串起來。

接著把它寫成實際檢核項：

• [ ] 使用者、目的與這次不做的範圍已寫清楚。
• [ ] 每條商業規則有來源，未知沒有被偷偷當成預設。
• [ ] 正常、替代、失敗與結果不明的流程都能描述。
• [ ] 資料的來源、null 意義、權威與失效時機已對齊。
• [ ] 重複操作、舊回應、離開頁面後的行為有決定。
• [ ] 驗收包含至少一個正常案例與高風險反例。
• [ ] 依賴、負責人及估時假設可以被檢查。
• [ ] 鍵盤操作、錯誤提示及基本可用性已納入。

勾選之外，更需要證據

「API 已確認」最好能指向契約或討論結論。
把沒有證據的打勾，只是把不確定性塗成綠色。

例如「舊回應不覆盖新資料」可以對應一個具體驗收：A 請求先發後到，B 請求後發先到，最終保留 B 的結果。
之後不論用哪個框架，測試都知道要保護什麼。

同樣，「畫面可用」太模糊；改成「輸入錯誤時有文字說明，焦點能移至相關欄位，鍵盤可完成操作」，就容易討論得多。

不必等全部準備好才開始

可以把未知分成阻擋與不阻擋。
優惠資格沒有裁定來源，會改變核心契約，是阻擋。
錯誤文案還在潤飾，只要行為已決定，通常可以先做流程。

這邊不是鼓勵帶著風險硬上，而是至少把能獨立完成的工作先切出來。

例如先完成輸入元件與狀態展示，等契約確認再接報價服務。
如果每個小需求都要求完整大文件，SASD 會變成負擔。

好的檢核應縮短返工，而不是讓文件比功能存在的久。

可以交給 AI 的 Prompt

請用這份需求檢核表審查優惠券規格。每項只能標「有證據、待確認、不適用」，並附來源或理由。請把待確認項分成阻擋開發與可後續補齊，說明影響。不要因為規格沒寫，就推定某個行為不存在。

這個 Prompt 把 AI 放在審查者的位置。它可以提醒遺漏，但「不適用」是否合理仍需要人判斷。

今日練習與筆記

用這份表檢查一個正在排期的功能，只挑最重要的三個未知去確認。
確認後再更新估時，你會看到分析如何實際改變計畫。

第一週留下的是可討論的需求，接著我們第二週要把這些材料轉成 AI 能協助的工作單位。
接下來的文章先看看為什麼看似清楚的指令，但在開發中依然會得到亂猜的程式。