先記住：拿到需求先問目的、規則、未知、失敗與驗收。
需要深入時：再使用完整 SA 工具。

畫面出來了，事情卻還沒做完

想像這個情境：你把購物車設計稿交給 AI，沒多久就有商品列、數量按鈕和漂亮的總計。
第一次跑起來真的很開心，直到測試的 QA 問：「如果庫存剩一件，兩個人同時結帳呢？」
你往畫面多加一個判斷，接著又有人問優惠券過期、價格異動、網路逾時。
看起來只是做個購物車，結果修完一個問題，馬上又冒出下一個：庫存、優惠券、價格、逾時。

所以我才意識到我每次都太早把「畫面要長什麼樣」當成「功能要怎麼運作」。

先解釋兩個名詞

SA，也就是系統分析，先弄清楚誰遇到什麼問題、哪些規則不能違反，以及怎樣才算完成。
SD，也就是系統設計，接著決定資料由誰管理、模組怎麼分工、失敗時如何恢復。

拿優惠券作為舉例

• SA 要問「可以疊加嗎？折扣由誰裁定？失效時能不能繼續結帳？」
• SD 才回答「用哪個狀態表示驗證中、哪一層呼叫服務、舊回應怎麼避免覆蓋新結果」。

兩者會來回修正，是不是開發前要想一堆分析才能開始做？
不過這也不表示每個需求都要畫一堆架構圖，小功能可能只需要一張規則表和三個驗收例子。
不過分析與設計的份量，本身就會連帶錯誤成本一起長大。

AI 改變的是工作分配

我想記下自己的提醒：AI 越會寫，我越要能說清楚自己為什麼這樣做。
在協作上，AI 不會自動知道你們尚未寫下來的產品決策。
如果我們只交代「做購物車」，產出只能建立在它補上的假設。
要先說清楚「成交金額由伺服器確認；前端展示的是報價；報價失效需重新確認」，它才有明確邊界可以遵循，並且也要搭配測試確認它有沒有做到。
所以這三十天的筆記，練習的不只是把問題寫清楚、方便檢查，也是在慢慢熟悉系統怎麼運作。
架構看懂了，哪些地方可能出錯、風險會從哪裡冒出來，才有機會提早發現。

今天先留下三點…

• 問題：會員想使用優惠券，目的是在付款前確認實際應付金額。
• 規則：折扣與庫存由伺服器確認；前端不能自行宣告優惠有效。
• 驗收：優惠券失效時保留商品與輸入，顯示原因，重新報價後才能進入確認。

然後看的人能馬上知道：哪些已經決定，哪些還要再問。

可以交給 AI 的 Prompt

請分析「會員在購物車套用優惠券」這個需求。已知折扣由伺服器裁定，前端需保留失敗時的輸入。請分成已知規則、待確認問題、正常流程、例外流程與驗收案例。未知 API 請標示待確認，不要自行發明端點。這一輪先不要寫程式。

這段 Prompt 用的是 SA 的問題界定：先約束「我們知道什麼」，再找缺口。
不過 AI 產出的問題清單仍需由人確認，不能隨便看看就當成規格。

今日練習與筆記

選一個最近做過的功能或者按鈕之類的，寫下使用者目的、最重要的規則，以及一個失敗情境。
如果只能描述按鈕顏色與 API 名稱，表示還有分析空間。
不過程式能跑只是其中一種證據，使用者能正確完成事情才是目標。
那第一天就從「簡單做一個按鈕」開始試試。