用 AI 做 App 前先規劃：需求文件、MVP 範圍與驗收清單
「幫我做一個 App」很容易得到幾個漂亮畫面，卻沒說清楚誰會用、要解決什麼，以及第一版做到哪裡就能交出去。開工前先寫一份短需求文件，能讓 AI 把力氣花在你真正要驗證的事情上。這篇用一個閱讀清單 App，示範從點子、MVP 範圍到驗收清單的完整規劃。
先寫清楚誰在什麼情況下需要它
先把工具名稱放旁邊，完成這句話：誰，在什麼情境下，想完成什麼事情，目前卡在哪裡？
例如：「喜歡看書的人在朋友推薦一本書時，想快速記下書名；目前資料散落在聊天和便條裡，到了書店又找不到。」這比「做一個有 AI 推薦、社群與排行榜的讀書 App」更容易決定第一版。
這裡的痛點是示範假設，還需要找可能的使用者確認。問對方最近一次如何記下推薦、後來有沒有找到、目前做法哪裡麻煩；記錄實際經歷，比問「如果有這個 App，你會用嗎」更能幫你調整方向。GOV.UK 的使用者需求指南也從使用者想完成的任務出發，並區分需求與預先選定的解法。
給 AI 的背景可以只有三行：
使用者：會累積待讀書單的人。
情境：收到推薦時要快速記錄，挑書時要能找回。
待驗證問題：集中記錄是否比目前的便條更容易持續使用。
先說清楚要學到什麼，再決定要做多少功能。
把 MVP 限制成一條能走完的主要流程
MVP 是最小可行產品。在這個練習中，我把第一版限制為「新增一本書，之後找得到，讀完能標記」，用來驗證核心用途。它不等於已證明有人願意付費。
| 第一版要有 | 為什麼保留 |
|---|---|
| 新增書名與選填作者 | 收到推薦時能留下記錄。 |
| 待讀與已讀狀態 | 下一次挑書時能分辨。 |
| 編輯、刪除與本機保存 | 記錯能修改，重開後還找得到。 |
登入、雲端同步、AI 推薦、好友分享與訂閱付款先放進以後再做的清單。每多一項，就會增加畫面、資料規則與測試；先讓這條流程完成，再根據回饋決定擴充。
另外記一張待確認清單，例如：同名書能不能重複新增？換手機是否需要帶走資料？第一版要在瀏覽器使用，還是安裝到手機？AI 可以列出選項，最後的取捨仍要對應你的目標。
先排操作流程，連空畫面和失敗情況一起想
閱讀清單的主流程是：打開清單 → 新增書名 → 保存 → 回到清單 → 標記已讀。先用紙或文字列出每一步看到什麼、能按什麼，這時還不需要精緻的 UI。
| 情況 | 第一版要怎麼回應 |
|---|---|
| 還沒有任何書 | 顯示用途與新增入口，讓人知道下一步。 |
| 書名只有空白 | 保留輸入畫面，提示書名必填。 |
| 同名書再次新增 | 本例允許，兩筆以不同識別碼保存。 |
| 保存失敗 | 顯示失敗訊息並保留輸入，不假裝保存成功。 |
| 刪除一本書 | 先確認，再刪除指定項目。 |
先決定這些行為，AI 才不會替你偷偷做出產品決策。本例使用本機資料，換裝置同步與備份都不在首版範圍內；如果跨裝置是使用者最重要的需求，就應重新調整範圍。
一頁 PRD 範本：把決定存進專案
PRD 是產品需求文件（Product Requirements Document）。小專案不必先寫成一本書；先讓需求能被回頭查到，也能在改動時同步更新。
可以下載App 規劃空白範本，或照這份已填好的示例建立文件：
目標與使用者：讓累積待讀書單的人，快速保存推薦並找回。
第一版流程：新增書名 → 保存 → 清單查看 → 標記已讀。
必要功能：書名必填、作者選填、待讀／已讀、編輯、確認刪除、本機保存。
暫不包含：帳號、同步、AI 推薦、社群、付款。
畫面與狀態：清單、新增／編輯表單、空清單、輸入錯誤、保存失敗。
資料規則：同名書可重複；每筆有獨立識別碼；重開後讀取已保存資料。
待確認：目標平台與裝置、資料保存方案、是否需要匯出。
完成證據：以下驗收案例的操作結果，加上使用者試用後的具體回饋。
文件不夠清楚的地方寫待確認，不要讓 AI 把猜測補成已經決定的需求。
驗收條件要寫成看得見的結果
「畫面漂亮」「功能正常」很難拿來驗收。改成做了什麼，應該得到什麼結果。GOV.UK 的使用者故事指南把驗收條件視為確認成果是否滿足需求的清單；下面是針對這個示範 App 自訂的案例。
| 編號 | 操作 | 預期結果 |
|---|---|---|
| A1 | 輸入書名並保存 | 清單新增一筆，預設為待讀。 |
| A2 | 書名只輸入空白 | 不新增資料，指出需要填書名。 |
| A3 | 新增後關閉並重開 | 在已約定的平台環境中，原資料仍在。 |
| A4 | 標記已讀、編輯作者再重開 | 新狀態與作者都保留。 |
| A5 | 取消刪除，再確認刪除 | 取消時資料不變；確認後只移除指定項目。 |
| A6 | 以測試方式模擬保存失敗 | 顯示錯誤、保留輸入，不顯示成功訊息。 |
這些是待實作、待測試的目標，並非本文已完成的 App 測試結果。建置通過也不能替代 A1 到 A6 的實際操作。
讓 AI 先整理需求，再拆成可交付的任務
把 PRD 交給 AI，可以使用這段提示詞：
請先閱讀這份 App 規劃。列出已確定的需求、會改變第一版範圍的疑問，以及你提出的假設；不要把假設當成決定。用最少的關鍵問題釐清缺口。接著整理一頁 PRD、畫面與資料狀態，以及對應驗收案例的實作步驟。此階段先完成規劃，不要直接生成整個 App。
實作順序也要能看懂成果：先完成清單與表單，再接新增和保存，接著處理狀態與編輯刪除，最後補錯誤情況與驗收。每個任務都附上能驗證的結果，例如「新增一本書並重開仍存在」，而不是「完成前端」這種大標籤。
如果第一個實作步驟就要同時建帳號、付款、推薦系統與資料庫，回頭檢查第一版是不是還太大。需求確定後，再看AI 開發工具比較；想把規劃接到測試與交付，可以接著讀 Agentic SDLC 工作流程。
開工前核對這五件事
- 能用一句話說出使用者、情境與要解決的問題。
- 第一版有一條完整流程，也有明確的暫不包含清單。
- 空畫面、輸入錯誤與保存失敗都有約定的回應。
- 每個核心功能都有可操作的驗收條件。
- 已記錄待確認問題、實作順序，以及試用後要蒐集的回饋。
把文件與驗收清單保存在專案裡，再從第一個小任務開始。需要接著找開發、測試與上架的文章，可以回到AI 開發地圖。
