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

> 一頁的需求規格書幫你規劃自己的 iOS app 並引導 AI：10 個問題、可複製的範本，以及絕對不該寫進去的內容。

原始頁面：[App 需求規格書範本：一頁就夠](https://devoria.fr/zh-hant/blog/mobile-app-requirements-template-one-page)
作者：[Mehdi Azizi](https://devoria.fr/zh-hant/mehdi-azizi)
發布日期：2026-08-31
內容最後修訂：2026-10-09


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

當你要做自己的 app，一份好的手機 app 需求規格書只要一頁。它回答十個問題：給誰用、解決什麼問題、主要功能是什麼、app 怎麼賺錢、沒有帳號能做什麼、哪些資料必須保留下來、在哪個平台、哪些不在第一版裡、你怎麼知道它有用，以及有哪些限制。可以直接複製的範本在下面。你也可以[下載範本和驗收表（.md）](https://devoria.fr/ressources/cahier-des-charges-app-ios.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](https://devoria.fr/zh-hant/expertise/ios-app-mvp) 這頁說明了怎麼挑選。
4. **app 怎麼賺錢？** 訂閱、買斷，或免費。這個答案從第一個畫面就會影響 app。如果拿不定主意，可以看[iOS app 該用訂閱還是買斷](https://devoria.fr/zh-hant/blog/ios-app-subscription-vs-one-time-purchase)。
5. **不建立帳號能做什麼？** 及早決定哪些不用註冊就能用，可以避免之後整個新手流程重做。
6. **哪些資料換手機後必須還在？** 這個問題決定你需不需要像 Supabase 這樣的後端，還是全部留在裝置上就好。
7. **只做 iOS，還是 iOS 和 Android 一起做？** 剛起步時我的建議是：先做 iOS。原因我在[同時做 iOS 和 Android app](https://devoria.fr/zh-hant/blog/ios-or-android-app-which-first) 裡有詳細說明。
8. **哪些東西明確不在第一版裡？** 這是整份文件最有用的部分。它能在爭論出現之前就把它擋掉，不管是跟你自己，還是跟 AI。
9. **你怎麼知道它有用？** 一個訊號就好，要能在上架後幾週內衡量：開始的免費試用數、訂閱者、回訪的使用者。
10. **你真正的限制是什麼？** 你每週能投入的時間、你的設備，還有你的 [Apple Developer 帳號](https://devoria.fr/zh-hant/blog/apple-developer-account-price-free-or-99)，費用是[每年 99 美元](https://developer.apple.com/programs/enroll/)。沒有 Mac？這不是阻礙，我在[沒有 Mac 也能發布 iOS app](https://devoria.fr/zh-hant/blog/publish-ios-app-without-mac-expo-eas) 裡有說明。

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

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

- **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](https://devoria.fr/zh-hant/blog/ai-ios-app-pitfalls-checks) 裡詳細整理了陷阱和檢查方法。

## 把決定轉成驗收標準

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

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

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

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

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

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

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

把決定和理由記在[可下載範本的紀錄區](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)。之後測試完你可以回頭改這個選擇，而不會忘記當初範圍的理由。接著，[用 Claude Code 做 app](https://devoria.fr/zh-hant/blog/claude-code-iphone-app-tutorial) 這篇教學示範如何把這份規劃轉成範圍有限、可驗證的請求。

想看實戰經驗，[TradaZen 在上架後調整了範圍](https://devoria.fr/zh-hant/blog/tradazen-case-study-launch-iphone-app)。規劃的目的是推出一個可衡量的第一版，再根據真實回饋決定下一版。

## 功能清單的陷阱

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

好的第一版只做一件事，而且做好。不過也要小心另一個極端：根據 [App Review Guidelines 第 4.2 條](https://developer.apple.com/app-store/review/guidelines/)，Apple 要求 app 不能只是包裝過的網站。只有一個主要功能可以；空殼不行：這正是 [guideline 4.2](https://devoria.fr/zh-hant/blog/guideline-4-2-minimum-functionality-app-rejected) 的退件理由。

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

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

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

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

第一版上架後，這一頁就成為下一版的基礎：原本不在第 1 版的項目會浮上來，依數據告訴你的結果排序。從點子到上架的完整流程，請看[做一個 iPhone app](https://devoria.fr/zh-hant/expertise/build-an-iphone-app)。

## 從這一頁到上架的 app

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

這正是 [iOS Kit](https://devoria.fr/zh-hant/kits/ios) 的流程，分四個步驟，照你自己的節奏走：第一步是選出能賺錢的 app、它的受眾和價格，而你的需求規格書就是起點。

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

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

## 常見問題

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

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

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

一則簡單的筆記或專案根目錄的文字檔就好：把範本複製進去，再逐行填寫。你也可以[下載範本和驗收表（.md）](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)，不用註冊。要引導 AI 的話，之後把它放進專案的脈絡檔案裡。

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

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

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

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

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

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

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

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


## 你的專案

[iOS Kit](https://devoria.fr/zh-hant/kits/ios)：用 Claude Code 打造你的 iPhone App：我的 App 所用的 Starter Code、檢查成果的 skills，以及 Apple Review Kit、App Store Screenshots Kit 與 ASO Kit。129.99 €。