ARTICLE · 1084082
AI开发小程序(四)——产品调研与需求文档实战
〇、导语
前三篇把"用什么开发"和"怎么搭环境"讲清楚了。这一篇进入真正的开发起点：想清楚要做什么，并把想法变成 AI 能执行的文档。
很多初学者跳过这一步，直接让 AI"帮我写一个育儿小程序"。结果 AI 自由发挥，生成的东西跟你想的完全不是一回事——不是 AI 笨，是你没告诉它"我要什么样的"。
这一篇讲三件事，同时针对三个"最容易翻车"的点做了加粗提示：
1.用 AI 做竞品调研——重点讲"调研怎么发起"和"AI 的结论怎么听"；
2.用 AI 生成需求文档（PRD）——重点讲清楚"PRD 不是一次生成，而是搭骨架 → 填血肉 → 做体检三步走"；
3.圈定 MVP 范围——用"价值 × 复杂度"矩阵守住边界，不让自己陷入"再加一个功能"的无底洞。
如果你已经用 AI 做过 APP，前面的安装和框架可以跳过，直接看标了 【经验】 和 【教训】 的段落——那是对"和 AI 协作"这件事本身的反思，比某个功能怎么写更值钱。
一、用 AI 做竞品调研
1.1 调研目标：发问之前，先回答三个问题
在打开对话窗口之前，先想清楚三个问题——这三个问题的答案质量，直接决定这次调研值不值：
•研什么：市面上到底有哪些同类产品？哪些算"直接竞品"、哪些只是"看起来像"？
•为什么研：我要从它们身上学什么（产品结构/交互细节），又要避开什么（差评集中点/审核雷区）？
•给谁用：我的目标用户和它们的目标用户有什么不一样？
很多人犯的第一个错：一上来就"帮我分析一下育儿小程序竞品"。这句话太宽了，AI 只能还你一份"看起来什么都说了、其实什么都没说"的报告。
【经验】调研问题的颗粒度，决定 AI 输出的价值。 模糊问题 → AI 给"常识性综述"（说了等于没说）； 聚焦问题（带用户画像、带决策背景、带输出格式）→ AI 给"可执行的对比"。 把上面三个问题的答案写进 Prompt 当"背景"，AI 的结论才能落在你的项目上。
1.2 第一轮：让 AI 出"粗筛清单"，你负责核实
Prompt（第一轮：粗筛）：
你是微信小程序产品顾问。我要做一款"0-1 岁宝宝养育记录"小程序，目标用户是新手父母（特点是：时间碎片化、夜间使用多、单手操作多）。请列出 6-8 个这个赛道最直接的竞品，并给出：- 产品名称、一句话定位- 其中最接近我定位的 3 个，单独标出来- 重要：只列你确认真实存在、可搜索到的产品； 拿不准的请标注"待核实"，不要编造
有一个关键设定：要求 AI 区分"它知道的"和"它编的"。因为 AI 给的竞品清单里，产品名、下载量、评分都可能出自幻觉——它会"一本正经地编数据"。
我方核实后，实际进入分析清单的竞品如下（前两行为已实测核实，其余为教学示意，数据以各平台官方渠道为准）：
| 亲宝宝 | ||||
| 小豆苗 | ||||
【教训】AI 输出的"用户量、评分、下载量"默认不要信。 这些数字它记不准，会顺理成章地"补全"。把它当"相对量级"参考（"亲宝宝大概比某记录类大一个数量级"）即可。 真正值得花时间核实的，是功能结构（进去点一遍）和差评（看应用商店 / 小红书 / 知乎的真实吐槽）。 处理秘诀：让 AI 在表格里加一列"证据来源类型（实测/评论区/推测）"，你只采信带"实测/评论区"标记的结论。
1.3 第二轮：深挖优劣势，每条结论要带证据
清单核实后，让 AI 聚焦分析（第二轮：深挖）。
Prompt：
基于下面核过实的竞品清单，请分析它们各自的优劣势：1. 亲宝宝 2. 小豆苗 3. 宝宝成长记录 4. 妈妈帮 5. 宝宝树孕育分析维度：核心功能、目标用户、界面风格、商业模式、用户评价中最集中的 3 个痛点、哪些功能是"做了却没人用"的。输出格式：表格对比 + 一段 200 字总结。额外要求：每条痛点必须标注证据来源类型（评论区 / 实测 / 推测）。
AI 输出示例（注意"证据"列，这是我们要的关键）：
1.4 调研发起的重点：把"发问"变成你的思考框架
把上面两轮复盘一下，发起调研的重点其实就三条——它本质上是在把你的思考框架先交给 AI：
| 定角色 | ||
| 限范围 | ||
| 要证据 |
记住一句话：AI 不是替你思考，是替你加速你已有的思考。 框架越清楚，加速效果越好；框架模糊，加速的就是糊涂。
1.5 AI 给出结论的重点：怎么"听"，才不被带偏
AI 给了你五条结论，怎么判断哪条是金矿、哪条是废话？听结论的三条铁律：
1.对不上目标的一律当噪音。我们的目标是"差异化定位"，那"UI 配色建议"再精彩也先挂起，不进本阶段结论。
2.只有"痛点"没有"证据"的，降权处理。AI 爱说"用户反馈功能太复杂"，你要追问一句："这条是你的推测，还是有真实评论支撑？"让它带证据重新说。
3.让 AI 唱反调（红队提问）：
你已经给出"做极简记录工具"的定位方案。现在请你换个角色：扮演一位保守谨慎的产品经理，挑出这个定位最站不住的 3 个理由，每个理由给出逻辑或数据支撑。
这一步能戳破 AI（和你自己）最容易犯的"自证倾向"——先有了结论，再去找理由。
最终，我们结合调研得出定位（示意）：
总结：竞品走两条路——要么"功能多而杂"（亲宝宝、宝宝树），要么"功能专而窄"（小豆苗）。中间存在一个明显缺口：简单、专注、无广告的记录工具。我们的机会：做一款"打开即用、3 秒完成记录"的极简工具。
【经验】AI 的结论要当成"假设"，不要当成"答案"。 在拍板之前，把结论丢给至少一个真人（或自己完整走一遍使用场景）验证一次。 AI 给你效率，验证才能给你确定性。
1.6 进阶技巧：让 AI 出"问真人"的访谈提纲
很多人不知道：AI 调研最该问的，不是 AI，而是真人用户。让 AI 帮你把"问真人"的提纲准备好，比自己干想高效得多。
Prompt：
我要找 3 位 0-1 岁宝宝的父母做 15 分钟访谈，验证"极简记录工具"这个方向。请帮我生成一份访谈提纲，要求：- 5 个问题，前 2 个用于了解他们现在的记录习惯- 第 3-4 个用于戳痛点（具体到"哪一步最麻烦"）- 第 5 个用于验证付费意愿（"愿不愿意为无广告版本付 6 元"）- 每个问题附 1 句"问这个问题想验证什么"
这份提纲，就变成了你 - 人的调研闭环里"真人验证"那一步的落地工具。
二、用 AI 生成需求文档（PRD）：三步走，不是一次到位
2.1 为什么 PRD 对 AI 开发尤其重要
在传统开发里，PRD 是给"人"看的。在 AI 开发里，PRD 有双重身份：
1.它是一份给"人"的需求说明书（你自己、你的合伙人、未来接手的人）；
2.它是后面所有代码 Prompt 的"母版"——本系列第 6 篇写代码时，每个页面的 Prompt 都是从 PRD 对应章节复制改写来的。PRD 写得不清楚，代码必然走样。
所以，生成 PRD 不是为了"有一份文档"，而是为了"给 AI 一张施工图"。这也决定了 PRD 的质量标准：不是"看起来专业"，而是"AI 照着写不跑偏、你自己也看得懂"。
2.2 第一步：搭骨架（让 AI 先出大纲，人对完再动手）
不要一上来就让 AI 写完整 PRD。先让它出"章节骨架 + 每章要回答的问题"，你自己先过目。
Prompt：
请为"育儿助手"微信小程序规划 PRD 的章节骨架。每个章节写：章节名 + 这一章要回答的 3 个问题 + 输出形式（表格/文字）。注意：只要骨架，不要展开内容。
AI 输出的骨架（示例）：
【经验】骨架阶段值得花 5 分钟核对。 骨架就是你和 AI 之间的"验收清单"。骨架对不上（比如少了"范围与数据"章节），现在就提，不要等文档生成了再改。 "先让 AI 出大纲、人对完再填内容"，是 AI 文档协作通用的一招，写 PRD、写技术方案、写周报都适用。
2.3 第二步：填血肉（逐章生成，你确认一章，再走一章）
骨架确认后，让 AI 逐章生成，而不是一次全出。逐章的好处：每章你都能校验、能追问，AI 不会在前面章节埋错、后面章节跟着错。
逐章 Prompt 示例（功能列表章）：
请生成 PRD 第 2 章"功能列表"的完整内容：- 至少 10 个功能点，标注优先级 P0/P1/P2 和版本（MVP/二期/三期）- MVP 功能不超过 5 个- 每个功能给出：一句话描述 + 给谁用 + 解决什么问题- 用表格呈现在我确认这一章之前，不要继续下一章。
注意最后一句："在我确认这一章之前，不要继续下一章"。这句话把主动权从 AI 手里拿回来——AI 默认会一口气把 8 章全写了，等发现第 2 章不对劲时，你已经被 8 章返工包围了。
2.4 生成需求文档时，必须说明清楚的三件事
下面这三件事，是"生成需求文档到底要说明什么"的关键，新手最容易漏：
| 范围边界：明确写"不做什么" | |||
| 数据来源与存储方式 | |||
| 验收标准前置 |
一句话总结：生成需求文档不是"让 AI 写"，而是"把我们说清楚的东西，交给 AI 工业化地落地"。你要说不清楚的，它永远不会替你补上。
2.5 成稿：完整的 PRD 框架（可直接当模板用）
经过"骨架 + 逐章填充"，汇总后的 PRD 如下。想用的时候复制这份骨架，替换成你的项目内容即可：
# 育儿助手 产品需求文档（PRD）## 1. 产品概述### 1.1 背景新手父母每天需要记录宝宝的喂奶、睡眠、换尿布等信息，纸笔记录容易丢失；现有小程序要么功能复杂、要么广告繁多。### 1.2 目标用户- 主要用户：0-1 岁宝宝的父母（时间碎片化、夜间高频、单手操作）- 次要用户：爷爷奶奶等家庭成员（手机操作能力弱 → 界面必须极简）### 1.3 核心价值- 极简记录：3 秒完成一次记录- 数据可视化：一键查看成长曲线- 完全免费：无广告、无内购## 2. 功能列表| 编号 | 功能 | 描述 | 给谁用 | 解决什么问题 | 数据方式 | 优先级 | 版本 ||---|---|---|---|---|---|---|---|| F01 | 喂奶记录 | 记录喂奶时间、时长、奶量 | 妈妈 | 掌握喂奶规律 | 本地 | P0 | MVP || F02 | 睡眠记录 | 记录入睡/醒来、睡眠时长 | 爸爸 | 调整宝宝作息 | 本地 | P0 | MVP || F03 | 换尿布记录 | 时间、类型（尿/便/混合） | 妈妈 | 观察宝宝健康 | 本地 | P0 | MVP || F04 | 成长曲线 | 身高/体重/头围变化图表 | 父母 | 了解发育情况 | 本地 | P0 | MVP || F05 | 疫苗提醒 | 按国家免疫规划提醒接种 | 父母 | 不错过接种时间 | 本地 | P0 | MVP || F06 | 喂养统计 | 日/周/月统计 | 父母 | 看喂养趋势 | 本地 | P1 | 二期 || F07 | 多宝宝支持 | 多宝宝切换 | 二胎家庭 | 一个应用管两个娃 | 本地 | P1 | 二期 || F08 | 家庭共享 | 家庭成员共享记录 | 全家 | 爸爸也能看到记录 | 云端 | P1 | 二期 || F09 | 数据导出 | 导出 Excel/PDF 报告 | 父母 | 备份、打印体检报告 | 本地 | P2 | 三期 || F10 | 智能建议 | 基于记录给出育儿建议 | 父母 | 个性化建议 | 云端 | P2 | 三期 |## 3. 页面流程图首页（记录入口）├── 喂奶记录页│ ├── 开始喂奶 → 计时中 → 结束喂奶 → 保存│ └── 历史记录列表├── 睡眠记录页│ ├── 开始睡眠 → 睡眠中 → 醒来 → 保存│ └── 历史记录列表├── 换尿布记录页│ ├── 选择类型 → 保存│ └── 历史记录列表├── 成长曲线页│ ├── 身高曲线 / 体重曲线 / 头围曲线└── 设置页 ├── 疫苗提醒设置 └── 关于## 4. 范围边界（本版本明确不做）- 不做登录/账号体系（MVP 数据纯本地）- 不做社区、分享、排行榜- 不做支付、会员、广告- 不做云同步（二期家庭共享时再做）## 5. 核心交互说明### 5.1 喂奶记录1. 用户点击"开始喂奶" → 开始计时，显示"喂奶中 00:05:32"2. 用户点击"结束喂奶" → 弹出备注输入框（可选）3. 点击"保存" → 记录写入本地存储4. 返回首页，显示"最近一次喂奶：10:30"### 5.2 睡眠记录1. 用户点击"宝宝入睡了" → 记录入睡时间2. 用户点击"宝宝醒了" → 自动计算睡眠时长3. 保存记录，写入本地存储### 5.3 换尿布记录1. 用户点击"换尿布" → 选择类型（尿 / 便 / 混合）2. 点击"保存"，写入本地存储## 6. 非功能需求| 维度 | 要求 ||---|---|| 性能 | 页面加载 < 1 秒，记录保存 < 200ms || 安全 | 数据本地存储，不上传服务器 || 兼容 | 支持 iOS 10+、Android 6.0+ || 包体积 | 主包 < 2MB（微信小程序限制） |## 7. 技术选型| 层级 | 技术 | 理由 ||---|---|---|| 前端 | uni-app + Vue 3 | 一套代码多端运行 || 后端 | Go + Gin | 轻量、高性能（二期再上） || 数据库 | MySQL + Redis | 经典组合（二期再上） || 部署 | 微信云开发 + 云服务器 | 免鉴权 + 灵活扩展 |## 8. 项目排期| 阶段 | 时间 | 产出 ||---|---|---|| 需求确认 | 第 1 周 | PRD 终稿 || UI 设计 | 第 2 周 | 设计稿 || 前端开发 | 第 3-4 周 | 可运行的小程序 || 后端开发 | 第 3-4 周 | API 服务（二期） || 联调测试 | 第 5 周 | 测试报告 || 发布上线 | 第 6 周 | 上线版本 |## 9. 验收标准- 每个 P0 功能的可勾选验收项（即第 3.3 节中每个功能的"验收标准"）- 喂奶记录的功能级测试用例（见本文 4.3 节）
【经验】PRD 里的每一张表格，都要留"给谁用 / 解决什么问题"这一列。 原因是：AI 开发时，AI 只认"功能描述"，但你自己需要靠"用户价值"来拦功能、判优先级。没有这一列，你后面会分不清 F06 和 F09 到底哪个该做。
2.6 PRD 生成的 5 条 Prompt 技巧速查
三、MVP 功能确认：学会对 AI 说"不"
3.1 什么是 MVP，以及 AI 时代为什么更难守住
MVP（Minimum Viable Product，最小可行产品）：用最少的功能验证想法。它不是"先做个半成品"，而是"先做一个刚好能用的版本"。
AI 时代的特殊难题：AI 把"加功能"的成本压到极低——你说"加个天气功能"，它 5 分钟就给你加上了。正因为加得便宜，你才特别容易乱加。"反正 AI 写得快，多要一个功能怎么了？"——每一个"怎么了"，都在推迟你真正想验证的东西。
守 MVP 的要领只有一句：所有新功能先过"两道门"，都过了才准进：
•第一道门（用户价值）：没有它，用户会用不下去吗？
•第二道门（核心目标）：它服务于"极简记录"这个定位吗？还是稀释了定位？
3.2 用"价值 × 复杂度"矩阵圈定 MVP
经过竞品分析与需求梳理，我们用"用户价值 + 技术复杂度"两个维度筛选功能，得到 MVP 结论：
怎么读这张矩阵：MVP 不一定选"价值最高的"，而是选"价值足够 + 成本可承受"的。"家庭共享"价值很高，但复杂度也很高（要云同步、要账号体系），硬塞进 MVP 会拖垮"6 周上线"的排期。它应该排在二期，等核心功能验证了再上。
【经验】AI 会倾向"多做"，你要学会判"该做什么"。 每次 AI 建议加功能，先问它两道门： （1）没有它用户会用不下去吗？（2）它贴"极简记录"的定位吗？ 问完这两问，一半的"锦上添花"会自己消失。
3.3 MVP 功能详细描述（用户故事 + 验收标准）
验收标准是 MVP 边界的"锁"。每一个 P0 功能都写好两样东西：用户故事（给谁用、要什么）和验收标准（做到什么算完成）。以 F01 为例：
F01：喂奶记录
用户故事：作为一名妈妈，我想记录每次喂奶的时间和奶量，以便了解宝宝的饮食规律。
验收标准：
•点击"开始喂奶"开始计时
•点击"结束喂奶"停止计时
•可输入奶量（毫升）
•可输入备注（可选）
•保存后显示在历史记录中
•历史记录按时间倒序排列
其余四个 MVP 功能（F02-F05）用同样的模板补齐：睡眠记录（入睡/醒来 + 自动算时长）、换尿布记录（类型选择）、成长曲线（身高/体重/头围折线图 + 录入）、疫苗提醒（按免疫规划预设 + 到期前提醒）。
【经验】验收标准同时管住了"做什么"和"算做完"两件事。 到第 6 篇写代码时，AI 每交一个页面，你都拿这几条验收项去勾：勾得上 = 完成，勾不上 = 让 AI 继续改。 这一套勾选清单，就是你验收 AI 工作的唯一尺子。
四、用 AI 完善 PRD：让 AI 体检，但你来下诊断结论
4.1 让 AI 检查遗漏：给它"体检清单"，而不是空泛地"帮我看看"
"帮我检查一下 PRD 有没有问题"——这句话，AI 只能回你两句不痛不痒的套话。给 AI 一份清单，它才能还你一份批改：
Prompt：
请按以下体检清单检查这份 PRD，逐项给结论，不通过的给修改建议：1. 场景覆盖：是否覆盖新手父母早/中/晚的典型使用场景？2. 边界情况：数据为空、断网、凌晨 3 点单手操作时，功能还成立吗？3. 数据一致性：喂奶计时被打断、换手机数据丢失时怎么处理？4. 微信审核：有没有可能触犯《微信小程序平台运营规范》的功能？5. 可测试性：每个 MVP 功能是否有明确的验收指标？输出格式：每项"通过/不通过 + 一句话依据 + 修改建议"，最后给一个总评分（百分比）。
4.2 AI 的典型建议：红绿灯决策法（建议是菜单，不是医嘱）
体检完，AI 给了我们一批建议。重点看右侧的"决策"列——这是 AI 做不到、只有你能做的部分：
红绿灯决策法三连问：
1.它解决的是真实痛点吗——证据在哪？不是"AI 说有需求"就有需求；
2.它贴 MVP 定位吗——是强化"极简记录"，还是稀释它？
3.它的成本可控吗——改动范围、数据合规、微信审核风险。
三问下来：全过 → 绿灯采纳；两过一疑 → 黄灯挂 backlog（写清触发条件）；有明显问题 → 红灯直接拒绝，别注入本次排期。
【经验】AI 的建议是"菜单"，不是"医嘱"。 它天然倾向于"多补几个功能显得专业"，但每多一个功能，都在分摊你的迭代速度。 拒绝 P2 建议不是"不听 AI"，而是：它在做信息汇总，你在做产品决策——责任在你这。
4.3 让 AI 生成验收测试用例（素材直接进 PRD 第 9 章）
Prompt：
请为"喂奶记录"功能生成验收测试用例，覆盖：- 正常流程：开始 → 结束 → 保存 → 列表出现- 边界情况：计时 0 秒结束、奶量留空、连续两条记录- 异常情况：本地存储写入失败、计时中退出页面每条用例包含：前置条件、步骤、预期结果、优先级（P0/P1）。
样例（节选）：
这批用例直接回填到 PRD 的"验收标准"章节（2.5 骨架里的第 9 章），PRD 初稿就此闭环。
五、需求文档终稿：一份"施工总图"
经过"调研 → 骨架 → 逐章填充 → 体检 → 红绿灯筛选"，终稿 PRD 包含 9 个部分：
1.产品概述：背景、目标用户、核心价值（一句话定位）
2.功能列表：10 个功能，5 个 MVP + 5 个后续，每个带"给谁用 / 解决什么问题 / 数据方式"
3.页面流程图：6 个页面 + 交互关系
4.范围边界：明确列出本版本"不做什么"
5.核心交互说明：每个 MVP 功能 3-6 步操作
6.非功能需求：性能、安全、兼容性、包体积硬指标
7.技术选型：前端 uni-app / 后端 Go / 数据库 MySQL+Redis / 部署方案
8.项目排期：6 周交付 MVP
9.验收标准：每个功能的可勾选验收项 + P0 功能测试用例
这份终稿，就是第 5 篇 UI 设计、第 6 篇代码开发的"施工总图"——也可以说，PRD 至此已经不再只是一份文档，而是后续所有 AI 协作的起点。
六、总结：整篇的行动清单
到这里，我们完成了一次"AI 辅助、人来拍板"的需求确认。把整篇压成一张可以直接照做的行动清单：
这套流程不只能用在写小程序上——任何"让 AI 帮你做产品"的项目都是同一个套路：你负责想清楚，AI 负责加速。换一个新项目，把上面 6 步的"育儿助手"换成你的业务名就可以直接复用。
最后三句话总结此篇文章：
1.AI 的调研数据是"分析视角"，不是"事实"——数字要核，痛点要带证据；
2.AI 的结论是"假设"、建议是"菜单"——拍板的是你，这是产品决策，不是整理资料；
3.PRD 是给 AI 的施工图——写清楚"不做什么、数据存哪、怎么算完成"，后面的代码才不会走样。
如果觉得文章对你有帮助，记得点赞、在看、转发支持一下～ 欢迎扫码关注本公众号解锁更多AI编程与AI办公技能点。