App 需求規格書範本：一頁就夠

手機 App 需求規格書：簡短回答

當你要做自己的 app，一份好的手機 app 需求規格書只要一頁。它回答十個問題：給誰用、解決什麼問題、主要功能是什麼、app 怎麼賺錢、沒有帳號能做什麼、哪些資料必須保留下來、在哪個平台、哪些不在第一版裡、你怎麼知道它有用，以及有哪些限制。可以直接複製的範本在下面。你也可以下載範本和驗收表（.md），不用註冊。

網路上那些 40 頁的範本是寫給另一種情境用的：客戶委託外包商做 app，需要一份具合約效力的文件。而你既是做決定的人，也是動手做的人，而且常常有 AI 幫忙。你的需求規格書有兩個用途：在寫程式之前把決定定下來，以及給 Claude、ChatGPT 或 Cursor 清楚的脈絡，讓它們做出對的 app。

我自己有在發布 iOS app。Solys（一款用小遊戲叫你起床的鬧鐘）和 TradaZen（一款交易模擬器）都已經上架 App Store。Nolera 和 Clic 曾被 Apple 退件，之後修正了。這是我每一款 app 都用的方法，也是我在這裡推薦給你的方法。

為什麼一頁就足以規劃你自己的 app

長篇文件會讓人覺得自己有進度。但實際上，它寫完一次就很少再看，專案在頭幾週就開始偏離它。一頁則相反，每次開工前花兩分鐘就能重讀一遍。

篇幅限制還有一個好處：它逼你做決定。如果某個答案超過兩句話，通常代表那個決定還沒做。在紙上發現這件事，總比三週後在程式碼裡發現好。

最後，一頁正好是適合 AI 的長度。你可以整頁貼進對話，或放進專案的脈絡檔案裡。短文件比較容易重讀，也能減少互相矛盾的指示。但它不保證 AI 一定會照做：AI 的提案還是要對照這個框架檢查。

手機 App 需求規格書應該包含什麼？

每個問題用一到兩句話回答。

1. 誰在用這個 app，在什麼情境下用？ 不是「18 到 35 歲」。而是一個具體的人，在他一天中某個具體的時刻。
2. app 解決什麼問題，用一句話說？ 如果你需要說「還有」，那你描述的是兩個 app。
3. 第一版唯一的主要功能是什麼？ 只能有一個。其他的等數據出來再說。iOS App MVP 這頁說明了怎麼挑選。
4. app 怎麼賺錢？ 訂閱、買斷，或免費。這個答案從第一個畫面就會影響 app。如果拿不定主意，可以看iOS app 該用訂閱還是買斷。
5. 不建立帳號能做什麼？ 及早決定哪些不用註冊就能用，可以避免之後整個新手流程重做。
6. 哪些資料換手機後必須還在？ 這個問題決定你需不需要像 Supabase 這樣的後端，還是全部留在裝置上就好。
7. 只做 iOS，還是 iOS 和 Android 一起做？ 剛起步時我的建議是：先做 iOS。原因我在同時做 iOS 和 Android app 裡有詳細說明。
8. 哪些東西明確不在第一版裡？ 這是整份文件最有用的部分。它能在爭論出現之前就把它擋掉，不管是跟你自己，還是跟 AI。
9. 你怎麼知道它有用？ 一個訊號就好，要能在上架後幾週內衡量：開始的免費試用數、訂閱者、回訪的使用者。
10. 你真正的限制是什麼？ 你每週能投入的時間、你的設備，還有你的 Apple Developer 帳號，費用是每年 99 美元。沒有 Mac？這不是阻礙，我在沒有 Mac 也能發布 iOS app 裡有說明。

可直接複製的需求規格書範本

把這個範本複製到一則筆記或專案根目錄的文字檔裡，然後逐行填寫。

• app 暫定名稱： …
• 給誰用： 一個在……的時候……的人
• 解決的問題，一句話： …
• 第 1 版的主要功能： …
• 使用者第一次打開 app 看到的畫面： …
• 商業模式： 訂閱／買斷／免費，以及哪些要付費：…
• 不用帳號可以： …
• 換手機後要保留的資料： 無／…
• 平台： 先做 iOS（數據不錯的話之後再做 Android）
• 不在第 1 版： …、…、…
• 成功訊號： …
• 技術組合： React Native、Expo，需要帳號時用 Supabase，訂閱用 RevenueCat
• 限制： 每週……小時、是否已開通 Apple Developer 帳號、有沒有 Mac
• 我喜歡哪些 app 的體驗，以及原因： …

再加上三到五張你喜歡的 app 截圖，附一句說明你喜歡哪裡。這比一份視覺規範更好懂，對你和 AI 都是。

需求規格書不是願望清單。它是一份已做決定的清單。

範例：一個虛構 app 的填寫版本

為了讓你看到應有的詳細程度，這是用一個為了舉例而虛構的 app（讀書計時器）填好的範本。

• 給誰用： 一個晚上自己讀書、十分鐘後就分心的學生。
• 問題： 他沒辦法在不碰手機的情況下撐完一段讀書時間。
• 主要功能： 開始一段計時的讀書時段，並看到自己連續達成的天數。
• 第一個畫面： 只有一個按鈕，用來開始一段時段。
• 商業模式： 詳細統計要訂閱，基本時段免費。
• 不用帳號： 全部都能用，除了跨手機備份。
• 不在第 1 版： 群組模式、好友排行榜、小工具、Android 版。
• 成功訊號： 使用者連續好幾天都回來用。

注意刻意省略的東西：沒有二十個畫面的清單、沒有指定顏色、沒有架構。這些選擇會在動手做的過程中出現，而這一頁是用來確認它們始終服務於主要功能。

如何用需求規格書引導 AI

這一頁最能發揮價值的地方就在這裡。沒有脈絡就寫程式的 AI 只能用猜的，而它常常猜成另一個不是你的 app。

把這一頁放進專案的常駐脈絡裡。 Claude Code 會讀取根目錄的 CLAUDE.md 檔案，Cursor 有自己的規則檔。把你的需求規格書和技術組合貼進去。這樣每個請求都從同一個基礎出發。

AI 做太多時，引用「不在第 1 版」那一段。 AI 助手很愛主動加功能：深色模式、分享、通知。你的排除清單給了你現成的回答：現在不做。

要求一份遵守這一頁的計畫。 在大工程之前，寫下：「這是我的需求規格書，請為主要功能提出計畫，先不要寫程式。」你馬上就能看出計畫是否偏離你的決定。

讓它檢查這一頁，而不只是程式碼。 問它：「這份需求規格書裡有哪些問題是模糊或互相矛盾的？」這是被低估的 AI 用法，能幫你省下好幾週往錯誤方向的工作。

想深入這個主題，我在用 AI 做 iOS app 裡詳細整理了陷阱和檢查方法。

把決定轉成驗收標準

主要功能必須有可觀察的結果。以這個例子的虛構計時器來說，「計時器能用」太模糊了。改寫成：「我開始一段時段，畫面顯示剩餘時間，我可以停止它，並在重新打開 app 後找到上一個完成的時段。」另外決定計時器在鎖定畫面時是否要繼續：這個選擇可能會改變技術工作。

每個功能加三行：操作、預期結果、證據。證據可以是針對計算的自動化測試，或針對流程在裝置上的檢查。也要記下哪些沒測過。這個小表格能避免你把「畫面做完了」和「功能可以用了」搞混。

這是我們虛構計時器的填寫範例。這些是待驗證的標準，不是已通過的測試：

規劃時的決定	要測試什麼	預期結果
基本時段不用帳號就能使用	安裝 app，不註冊就開始一段時段	沒有任何註冊表單擋住開始
中途放棄的時段不計入連續天數	在結束前停止時段，然後打開歷史紀錄	沒有新增任何完成的時段
歷史紀錄留在裝置上	完成一段時段，關閉再重新打開 app	該時段只出現一次，且時長正確
基本計時器不需網路就能運作	開啟飛航模式並完成一段時段	計時器和本機儲存都仍可使用
詳細統計需要付費	沒有訂閱時打開統計	顯示付費方案；基本時段仍可使用

還模糊的部分要變成待做的決定。例如：使用者在時段中鎖定螢幕或更改手機時間時該怎麼辦？別讓 agent 默默自己決定。寫下你要的行為，再把這個情況加進表格。要在實際安裝的版本上安排這些驗收，請參考用 TestFlight 測試你的 iPhone app。

第一版範圍爆掉時，決定要拿掉什麼

逐一檢視每個功能，問一個問題：「沒有它，使用者還能得到承諾的結果嗎？」以我們的計時器來說，好友排行榜可以等。如果你承諾連續天數，找回已完成的時段就是必要的。訂閱畫面只有在你這一版真的要販售統計功能時才變成必要。

把決定和理由記在可下載範本的紀錄區。之後測試完你可以回頭改這個選擇，而不會忘記當初範圍的理由。接著，用 Claude Code 做 app 這篇教學示範如何把這份規劃轉成範圍有限、可驗證的請求。

想看實戰經驗，TradaZen 在上架後調整了範圍。規劃的目的是推出一個可衡量的第一版，再根據真實回饋決定下一版。

功能清單的陷阱

很自然的反應是列出 app「應該要做」的所有事：地圖、聊天、通知、推薦、離線模式。這種清單是專案做不完最可靠的徵兆，原因很簡單：上架前每多加一個功能，就延後了真實使用者告訴你什麼才重要的時刻。

好的第一版只做一件事，而且做好。不過也要小心另一個極端：根據 App Review Guidelines 第 4.2 條，Apple 要求 app 不能只是包裝過的網站。只有一個主要功能可以；空殼不行：這正是 guideline 4.2 的退件理由。

手機 App 需求規格書不該包含什麼

• 完整的視覺規範。 一開始幾張參考截圖就夠了。
• 逐日排程。 你還沒有足夠資訊去照著執行。一個每週目標就夠了。
• 詳細的技術架構。 選一套成熟的技術組合，細節讓它在動手做時再決定。
• 混在其他內容裡的「以後再做」功能。 它們全部都放進「不在第 1 版」那一段。

什麼時候該更新需求規格書？

每週開工時重讀一次。只有在某個決定因為真正的理由而改變時才更新：在你的 iPhone 上測試發現某個畫面行不通、測試者的回饋、途中發現的 Apple 限制。如果你每天都在改，那它已經規劃不了任何東西了。

第一版上架後，這一頁就成為下一版的基礎：原本不在第 1 版的項目會浮上來，依數據告訴你的結果排序。從點子到上架的完整流程，請看做一個 iPhone app。

從這一頁到上架的 app

如果你回答了這十個問題，你已經完成了很多專案會跳過的工作。接下來就是做出主要功能、在你的 iPhone 上測試、接上訂閱，以及準備送審 Apple 的資料。

這正是 iOS Kit 的流程，分四個步驟，照你自己的節奏走：第一步是選出能賺錢的 app、它的受眾和價格，而你的需求規格書就是起點。

不確定你的點子能不能寫成一頁？免費診斷會告訴你目前專案卡在哪裡，以及該先處理哪個步驟。接著首頁會示範如何從這份規劃出發，用 Claude Code 做一個手機 app。

我不保證你會有收入或一定能上架：審核由 Apple 決定，其餘交給市場。沒有這個 kit，這個範本也足夠讓你起步。

常見問題

手機 app 的需求規格書怎麼寫？

把需求規格書控制在一頁：十個問題，每個答案一到兩句話。內容涵蓋受眾、問題、主要功能、商業模式、沒有帳號時能做什麼、必須保留的資料、平台、不在第一版的項目、成功訊號和限制。如果某個答案超過兩句話，通常代表那個決定還沒做。

寫 app 需求規格書要用什麼軟體？

一則簡單的筆記或專案根目錄的文字檔就好：把範本複製進去，再逐行填寫。你也可以下載範本和驗收表（.md），不用註冊。要引導 AI 的話，之後把它放進專案的脈絡檔案裡。

app 需要 40 頁的需求規格書嗎？

不需要，做自己的 app 時一頁就夠。網路上 40 頁的範本是寫給委託外包商做 app、需要合約文件的客戶。而你既做決定也動手做：你的這一頁是用來在寫程式前定下決定，並提供脈絡給 AI。

怎麼把需求規格書交給寫程式的 AI？

把這一頁放進專案的常駐脈絡：Claude Code 會讀取根目錄的 CLAUDE.md 檔案，Cursor 有自己的規則檔。AI 做太多時，引用「不在第 1 版」那一段。大工程之前，先要求一份遵守這一頁的計畫，暫時不要寫程式。

怎麼確認某個功能符合需求規格書？

每個功能加三行：操作、預期結果和證據。證據可以是針對計算的自動化測試，或針對流程在裝置上的檢查。也要記下哪些沒測過，才不會把畫面做完和功能可以用搞混。

app 需求規格書裡不該寫什麼？

要避免四樣東西：完整的視覺規範、逐日排程、詳細的技術架構，以及混在其他內容裡的「以後再做」功能。一開始幾張參考截圖就夠了，排程有個每週目標就夠了。以後再做的功能全部放進「不在第 1 版」那一段。