先寫需求書再開工｜Vibe Coding 為什麼要先寫需求書再開工？

每次叫 AI 做 App，為什麼總是要改到天亮？很多人用AI做App，第一句話都是：幫我做一個學習追蹤App。然後就是花好幾個小時，來回修改、來回重做。這是Vibe Coding最常見的失敗方式。原因很簡單，因為AI不會讀心。你沒說清楚的部分，它只能自己猜。猜對了是運氣，猜錯了就是你的時間。解法其實很樸素：開工之前，先花15分鐘寫一頁需求書。這十五分鐘，能替你省下好幾個小時的來回修改。很多人跳過這一步，結果花了更多時間在修改。你可以把它想成：先把想法講清楚，再請AI動手。需求書不用寫得很漂亮，只要把重點交代完整就好。這個做法不是我們發明的，開源社群早就這樣做了。許多給AI寫程式用的工作方法，都把先釐清需求放在最前面。例如先讓AI反過來提問，再把答案整理成規格書。接著把規格拆成小任務，一件一件交給AI實作。說穿了，就是先想清楚要做什麼，再動手寫程式。這和專業團隊的開發流程，其實是一致的。一頁需求書，只要填五個欄位。第一個欄位是目標使用者與情境：誰會用？在什麼時候用？第二個是核心功能，最多只能寫三個。例如新增項目、勾選完成、顯示本週完成率。第三個欄位最關鍵，叫做明確不做的事。例如不做登入、不做多人共用、不做手機App。如果你沒寫，AI很可能覺得多加幾個功能比較貼心。結果程式越變越複雜，你反而越難改。所以寫出不做什麼，能防止AI自作主張加功能。第四個欄位，是資料存在哪裡。例如存在瀏覽器的localStorage，重新整理後資料仍在。第五個欄位，是畫面與技術限制。例如單一HTML檔、手機也能用、不使用外部套件。如果你不知道需求書怎麼寫，可以請AI當訪談者。讓它一題一題問你，回答完再整理成需求書。你可以直接複製這段提示詞，貼給AI。它會扮演產品經理，一次只問一個問題，最多問八題。問題會涵蓋使用者、情境、功能、不做的事、資料和畫面。訪問結束後，它會幫你整理成一頁五個欄位的需求書。整理好之後，請仔細檢查不做的事那一欄，它最容易被忽略。最後記得在括號那裡，換成你自己的初步想法。以本課專題為例，一份合格的需求書大概長這樣。使用者是正在自學轉職的人，每天睡前打開來記錄。核心功能是新增學習項目、勾選完成、顯示本週完成率。不做登入，也不做雲端同步，資料就存在瀏覽器。最後做成單一HTML檔，手機與電腦都能使用。短短幾行，AI就有足夠資訊，一次做出八成正確的版本。來做一題隨堂小檢查，看看你記住了沒有。需求書中寫出明確不做的事，主要目的是什麼？選項一，讓需求書看起來比較長。選項二，方便日後向別人收費。選項三，防止AI自作主張加入不需要的功能。先想想看，答案是哪一個？答案是第三個，防止AI自作主張加入不需要的功能。AI常常覺得多加功能是貼心，但功能一多，程式就變複雜。把不做的事寫清楚，你才不用一直幫AI收拾殘局。最後送你一個小技巧：需求書請存成一個文字檔。把它放在專案資料夾裡，隨時都找得到。之後每次開新的AI對話，都先把需求書貼上去。這樣AI就不會忘記你的原始設定，也不會越做越偏。回頭看這一單元，其實只有一個重點。動手之前，先花15分鐘，把想法寫成一頁需求書。尤其別忘了「不做的事」，它是整個需求書最重要的欄位。有了需求書，下一步就能穩穩地請AI動手。先寫需求書，AI 才做得對。