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

移动 App 需求文档：简短回答

做自己的 App 时，一份好的移动 App 需求文档一页纸就够了。它回答十个问题：给谁用、解决什么问题、核心功能是什么、App 怎么赚钱、不注册账号能做什么、哪些数据必须保留下来、做哪个平台、哪些内容不放进第一版、怎么判断它成功了，以及有哪些限制。可复制的模板在下面。你也可以下载模板及其验收表（.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 这一页讲了怎么选。
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	该学习只出现一次，且时长正确
基础计时器无网络也能用	开启飞行模式并完成一段学习	计时器和本地记录仍可正常使用
详细统计需要付费	未订阅时打开统计	显示付费方案；基础学习计时仍可使用

仍然含糊的问题会变成需要做的决定。比如：学习过程中用户锁屏或修改手机时间，该怎么处理？别让 AI 代理悄悄替你决定。写下你想要的行为，再把这个情况加到验收表里。要在真实安装上组织这次验收，可以参考用 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 版”那一节。