為什麼要先準備？
許多人在 Vibe Coding 中輸入一句話就期待驚人產出，但 AI 需要充足的上下文與明確目標。布魯斯張建議把自己當作產品經理，先釐清「我要什麼」和「為何需要」，再請模型執行。這些準備會讓結果更貼近真實需求，也降低來回修正的時間成本。
精確描述需求的三個核心面向
1. 目標導向
把想要的成果寫成可驗證的句子，例如「建立一個能匯入 CSV 的 Flask API，回傳 JSON 並附單元測試」。不要只寫「幫我做個 API」。
2. 邊界條件
- 明確限制：資料量、執行時間、可用資源、需避開的技術或授權。
- 品質指標：可維運性、可測試性、可擴充性，最好能列出量化指標或具體檢核步驟。
3. 成功量尺
定義「完成」的樣子，例如「PR 經過 npm test」、「文件包含 API 範例」、「佈署指南能在 30 分鐘內完成」。布魯斯張會把這些條件寫在提示的最前面，讓 AI 知道成品必須符合的標準。
釐清需求的快速流程
Stakeholder 問題清單
- 主要使用者是誰？他們的痛點與想完成的任務是什麼？
- 時程與里程碑？是否有硬性截止日或法規考量？
- 現有系統或流程有哪些需要兼容或不能改動的部分？
需求拆解技巧
- 把需求拆成「結果、流程、限制、驗收」四段話，再逐一請 Vibe Coding 深挖。
- 用範例說明：附上目前的資料樣本、錯誤訊息、或既有程式碼片段。
- 明示不要的輸出，例如「不要改寫資料結構」或「不要生成虛構引用」。
計畫書與溝通模板
有了需求骨架後，布魯斯張會先讓 AI 生成一份 1 頁計畫書，確認方向再進入開發。以下是常用模板：
- 背景與目標
- 用三行文字說明業務背景、目標客群、預期成果。
- 範圍與交付物
- 以條列列出必做、可選、延伸項目，並標示優先順序。
- 里程碑
- 拆成「草稿、驗證、上線」三階段，每階段附驗收標準。
- 風險與對策
- 列出三個最可能失敗點與備案，例如資料權限、第三方 API 限制、或人力瓶頸。
把這份計畫書丟回 Vibe Coding，請模型檢查假設、補齊風險，往往能提前發現盲點。
如何迭代提示詞
第一次結果不滿意時，不要只說「再試一次」。把偏差寫下來，例如「缺少錯誤處理」或「格式不符 JSON schema」，再加上「請只修改必要部分」。布魯斯張也會要求 AI 回報它的理解下一步計畫，確保每輪迭代都更接近目標。
工具與資源建議
- 需求對齊：使用用戶旅程地圖或簡易的 event storming，確認流程節點後再寫提示。
- 快速驗收：建立可重複執行的測試命令，例如
npm test或pytest，在提示中要求模型保留。 - 知識輸入：把現有文件、API 規格或設計稿摘要成要點，作為提示的「系統上下文」。
結語
Vibe Coding 是放大思考的工具，而不是替代思考。當你先準備好需求敘述、範圍界線與可驗證的計畫，AI 的每一次輸出都會更貼近真實世界的限制。希望這份備忘能讓你像布魯斯張一樣，用清晰的語言引導模型，讓創意與工程並行。