回顧與練習

關鍵要點

• 規格先行，而且很短 — 一段話點明瞭真正重要的約束，包括那些在執行的應用裡永遠看不到的工作流約束。
• 金鑰從未碰過倉庫；每個專案都從環境變數或在儀表盤裡設定的加密配置中讀取金鑰。
• 技術棧是為了少出錯而選的 — 託管認證、託管資料庫、靜態託管、無伺服器函式。
• 障礙是靠給 AI 喂確切證據來解決的 — 真實的報錯、實際的程式碼、部署配置 — 並把修復範圍收得很窄。
• 上線意味著對現實的真實測試，而不是"它編譯通過了": 一筆真實購買、第二個賬戶、線上站點上的一個深層連結。

動手試試

挑一個你自己的點子，像這四個案例那樣寫出它的一段式規格: 點明核心動作、每個使用者能看到的資料，以及至少一個工作流約束(內容如何釋出、誰能做什麼)。然後列出你會依賴的託管構件，以減少會出問題的自定義程式碼。控制在一段話加一個簡短的專案符號列表 — 如果超出了，就說明你規格定得過頭了。

本章提示詞

I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
   (e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
   managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
   against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.