# App 需求文档模板：一页纸写清楚

> 一页纸的 App 需求文档：10 个问题、可复制模板，帮你理清 iOS App 并指导 AI。

原始页面：[App 需求文档模板：一页纸写清楚](https://devoria.fr/zh-hans/blog/mobile-app-requirements-document-one-page-template)
作者：[Mehdi Azizi](https://devoria.fr/zh-hans/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

长文档会让人觉得已经有了进展。实际上，它写一次，很少再读，项目在头几周就偏离了它。一页纸则不同，每次开工前两分钟就能读完。

篇幅限制还有个好处：它逼你做决定。如果某个回答超过两句话，往往说明这个决定还没做。在纸上发现这一点，总比三周后在代码里发现要好。

最后，一页纸对 AI 来说也是合适的长度。你可以把它整段贴进对话，或者放进项目的上下文文件。短文档更容易复查，也能减少互相矛盾的指令。但它不能保证 AI 一定照做：要对照这个框架检查它的方案。

## 移动 App 需求文档应该包含什么？

每个问题用一两句话回答。

1. **谁在用这个 App，在什么场景下？** 不是“18 到 35 岁的人”，而是一个具体的人，在一天中的某个具体时刻。
2. **这个 App 解决什么问题，用一句话说？** 如果你需要说“另外还有”，那你描述的是两个 App。
3. **第一版唯一的核心功能是什么？** 只有一个。其他功能等数据说话再说。[iOS App MVP](https://devoria.fr/zh-hans/expertise/ios-app-mvp) 这一页讲了怎么选。
4. **App 怎么赚钱？** 订阅、一次性买断，还是免费。这个答案从第一个界面起就会改变 App。如果拿不定，可以看[iOS App 选订阅还是买断](https://devoria.fr/zh-hans/blog/ios-app-subscription-vs-one-time-purchase)。
5. **不注册账号能做什么？** 尽早决定哪些内容无需注册就能用，可以避免把整个新用户引导流程推倒重来。
6. **哪些数据在换手机后必须还在？** 这个问题决定了你是否需要 Supabase 这样的后端，还是一切都可以留在设备上。
7. **只做 iOS，还是 iOS 和 Android 一起做？** 我对新手的建议是：先做 iOS。原因我在[同时做 iOS 和 Android App](https://devoria.fr/zh-hans/blog/ios-or-android-first-app)里详细讲过。
8. **哪些内容明确不放进第一版？** 这是整份文档最有用的部分。它能在争论出现之前就把它掐掉，不管是跟自己争还是跟 AI 争。
9. **你怎么知道它成功了？** 只要一个信号，在发布后几周内可以衡量：开始免费试用的人数、订阅用户、回访用户。
10. **你真正的限制是什么？** 你每周能投入的时间、你的设备，以及你的 [Apple Developer 账号](https://devoria.fr/zh-hans/blog/apple-developer-account-price-free-or-99)，费用是[每年 99 美元](https://developer.apple.com/programs/enroll/)。没有 Mac？这不是障碍，我在[没有 Mac 也能发布 iOS App](https://devoria.fr/zh-hans/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-hans/blog/build-ios-app-with-ai-pitfalls-checks)里详细讲了常见陷阱和检查方法。

## 把决定变成验收标准

核心功能必须有可观察的结果。对于这个虚构的计时器，“计时器能用”太模糊了。应该写成：“我开始一段学习，剩余时间会显示，我可以停止它，并且重新打开 App 后能看到上一次完成的学习。”锁屏时计时器是否继续运行，要单独决定：这个选择可能改变技术工作量。

每个功能加三行：**操作**、**预期结果**、**证据**。证据可以是针对计算的自动化测试，也可以是针对流程的真机检查。也要记下哪些还没测过。这张小表能避免把“界面做完了”和“功能可以用了”混为一谈。

下面是为虚构计时器填好的验收表。这些是待验证的标准，不是已经通过的测试：

| 决定                         | 测试内容                           | 预期结果                           |
| ---------------------------- | ---------------------------------- | ---------------------------------- |
| 基础学习计时无需账号即可使用 | 安装 App，不注册直接开始一段学习   | 没有任何注册表单阻止开始           |
| 中途放弃的学习不计入连续天数 | 在结束前停止学习，然后打开历史记录 | 没有新增已完成的学习               |
| 历史记录保存在设备上         | 完成一段学习，关闭后重新打开 App   | 该学习只出现一次，且时长正确       |
| 基础计时器无网络也能用       | 开启飞行模式并完成一段学习         | 计时器和本地记录仍可正常使用       |
| 详细统计需要付费             | 未订阅时打开统计                   | 显示付费方案；基础学习计时仍可使用 |

仍然含糊的问题会变成需要做的决定。比如：学习过程中用户锁屏或修改手机时间，该怎么处理？别让 AI 代理悄悄替你决定。写下你想要的行为，再把这个情况加到验收表里。要在真实安装上组织这次验收，可以参考[用 TestFlight 测试 iPhone App](https://devoria.fr/zh-hans/blog/testflight-guide-test-iphone-app)。

### 第一版超出范围时，决定删掉什么

逐个审视每个功能，问一个问题：“没有它，用户还能得到承诺的结果吗？”对于我们的计时器，好友排行可以等。如果你承诺了连续天数，那找回已完成的学习就是必需的。只有当你在这个版本就真正对统计收费时，订阅界面才是必需的。

把决定及其原因记在[可下载模板的日志](https://devoria.fr/ressources/cahier-des-charges-app-ios.md)里。测试之后你可以重新考虑这个选择，同时不会忘记最初范围背后的原因。接下来，教程[用 Claude Code 做一个 App](https://devoria.fr/zh-hans/blog/claude-code-iphone-app-tutorial)演示了如何把这份规划拆成范围有限、可验证的请求。

想看实战案例：[TradaZen 在发布后调整了范围](https://devoria.fr/zh-hans/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-hans/blog/guideline-4-2-minimum-functionality-rejection)的拒审理由。

## 移动 App 需求文档不该写什么

- **完整的视觉规范。** 起步时几张参考截图就够了。
- **精确到天的排期。** 你还没有足够的信息去执行它。一个周目标就够了。
- **详细的技术架构。** 选一个成熟的技术栈，细节在开发过程中再定。
- **和其他内容混在一起的“以后再做”的功能。** 它们全部放进“不在第 1 版”那一节。

## 什么时候更新需求文档？

每个工作周开始时读一遍。只有当某个决定因为真实原因改变时才更新它：在 iPhone 上测试发现某个界面行不通、测试者的反馈、开发途中发现的 Apple 限制。如果你每天都在改，说明它已经起不到约束作用了。

第一版发布后，这页纸就成了下一版的基础：原本不在第 1 版的内容浮上来，按数据告诉你的优先级排序。从想法到发布的全流程概览，在[做一个 iPhone App](https://devoria.fr/zh-hans/expertise/create-an-iphone-app)这一页。

## 从一页纸到上架的 App

如果你回答了这十个问题，你已经完成了很多项目跳过的工作。接下来就是做出核心功能、在 iPhone 上测试、接入订阅，并为 Apple 准备审核材料。

这就是 [iOS Kit](https://devoria.fr/zh-hans/kits/ios) 的路线，分四个阶段，按你自己的节奏推进：第一阶段帮你选出能赚钱的 App、它的用户群和定价，而你的需求文档就是起点。

不确定你的想法能不能写进一页纸？[免费诊断](https://devoria.fr/zh-hans/diagnostic)会告诉你目前卡住项目的是什么，以及应该先攻哪一步。首页接着展示了如何基于这份规划，用 Claude Code [做一个移动 App](https://devoria.fr/zh-hans)。

我不承诺收入，也不承诺能上架：审核由 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-hans/kits/ios)：用 Claude Code 做你的 iPhone App：我自己 App 的起步代码、检查其工作的 skills，以及 Apple Review Kit、App Store Screenshots Kit 和 ASO Kit。129,99 €。