用 AI 做 App 前先规划：需求文档、MVP 范围与验收清单
一句“帮我做个 App”，很容易换来几个好看的页面，却没有回答谁会用、解决什么问题、首版做到哪里就可以交付。先写一份简短的需求文档，能让 AI 围绕你要验证的事情展开工作。本文以阅读清单 App 为例，把点子、MVP 范围、实现任务和验收标准串起来。
先描述用户和场景，再讨论功能
先不选工具，写清这件事：谁，在什么场景下，要完成什么任务，目前遇到了什么障碍？
例如：“经常收到朋友推荐书籍的人，希望及时记下书名；目前记录散落在聊天和便签中，到了书店又找不到。”这个描述比“做一个带 AI 推荐、社交和排行榜的读书 App”更容易帮助你确定首版。
这里的问题只是示例假设，需要找潜在用户核实。可以询问最近一次怎样记录推荐、后来是否找回、现有办法哪里不方便。实际经历比“有这个 App 你会用吗”的假设回答更有参考价值。GOV.UK 的用户需求指南也从用户任务出发，区分真实需求与预先选定的解决方案。
给 AI 的背景可以写成：
用户：会积累待读书单的人。
场景：收到推荐时快速记录，选书时能够找回。
待验证问题：集中记录是否比现有便签更容易长期使用。
先确定要验证什么，再决定开发哪些功能。
把 MVP 收敛到一条完整流程
MVP 指最小可行产品。这个练习把首版限定为“添加一本书，之后能找到，读完能标记”，用来验证核心用途。完成这些功能，并不代表已经验证付费需求。
| 首版保留 | 保留理由 |
|---|---|
| 填写书名和可选作者 | 收到推荐时能够留下记录。 |
| 待读与已读状态 | 下次选书时能够区分。 |
| 编辑、删除和本地存储 | 记录有误可以修改，重新打开还能找到。 |
登录、云端同步、AI 推荐、好友分享和订阅付费先放入后续需求。每新增一项，都会增加页面、数据规则和测试成本；先做完核心流程，再根据试用反馈调整。
另列一份待确认事项：同名书能否重复添加？换设备时是否必须带走数据？首版在浏览器里运行，还是安装到手机？AI 可以解释选择的影响，取舍仍需符合你的目标。
把空状态和失败路径一起规划
核心操作是：打开清单 → 添加书名 → 保存 → 返回清单 → 标记已读。先用纸或文字列出每一步看到什么、可以做什么，不必急着打磨视觉效果。
| 场景 | 约定行为 |
|---|---|
| 清单为空 | 说明用途，并提供添加入口。 |
| 书名只有空格 | 留在输入页面，提示书名必填。 |
| 再次添加同名书 | 本例允许重复，两条记录使用不同标识。 |
| 保存失败 | 提示错误、保留输入，不显示保存成功。 |
| 删除记录 | 先确认，再删除指定条目。 |
把这些行为写清楚，避免 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 开发地图找到。
