从想法到需求：PRD·原型·验收标准
项目往往不是“写崩”的，而是一开始就想错了。这一章把一句想法变成 AI 能执行、你能验收的东西。
一句话记住：需求不是“我要什么功能”，而是“谁在什么场景下，要完成什么，什么算完成”。
你将学会
- 把「我想要」改写成「谁、在什么场景、做什么」；
- 划出 MVP 与「不做清单」，挡住需求膨胀；
- 写出一页能被验收的 PRD（四块 + 逐块要点 + 完整示例）；
- 写出可验证的验收标准（判据 + 八类必测 + 好例坏例）；
- 画出页面清单（原型图），交出第一版界面骨架；
- 需求变了知道怎么改才不乱。
前置知识
Vibe Coding 入门教程（需求与一页说明两节）。可直接复制的完整 PRD 模板见模板库。
一、从“我想要”到“谁在什么场景做什么”
1. 先回答五个问题
别问“我要做什么功能”，先回答这几个问题：
| 问题 | 为什么先问它 | 打卡板的回答 |
|---|---|---|
| 谁用？ | 决定复杂度：给自己用 vs 给别人用 | 只有我自己 |
| 解决什么？ | 决定什么是“核心”，什么是“花边” | 记录每天的学习任务，看得到进度 |
| 最少需要哪几个动作？ | 每多一个动作就多一处交互、多一处 bug | 新增、标记完成、按分类看 |
| 哪里可能出错？ | 现在想清楚，比上线后救火便宜十倍 | 空任务、数据丢了、换浏览器还在不在 |
| 第一版明确不做什么？ | 最容易被跳过、也最值钱的一问 | 登录、云同步、分享、报表 |
2. 把“形容词”改成“句子”
一次改写，感受差别：
| ❌ 还是想法 | ✅ 变成需求 |
|---|---|
| 我想做个记账的东西，要好看好用 | 我每天记 3~5 笔支出；打开就能记一笔；能看到当月合计数；刷新不丢 |
| 做个能管学习计划的 | 我能新增学习任务、标记完成、按 AI/Agent/Vibe Coding 三类看进度 |
| 想弄个爬虫抓数据 | 每天把某站列表页的标题+链接存成 CSV，一条一行，重复的不重复存 |
判据：改写后的句子，不是程序员也能看懂，而且能一眼判断“做到没有”。
3. 产出三样东西
- 需求清单：几条“用户能做什么”的句子（上面那张表右列就是）；
- 不做清单：第一版明确不做的功能；
- 主流程一句话：
打开 → 新增 → 看到列表 → 刷新还在（一句话就够）。
这三样加起来，就是后面 PRD 的原料。
二、范围控制：MVP 与不做清单
1. 什么是 MVP
MVP（最小可用版本） = 能跑通主流程的最小功能集合。注意关键词是主流程，不是“最少代码”。
判定方法只有一个问题：
删掉这个功能，用户还能完成主流程吗？ 能 → 放进「以后再说」；不能 → 必须留在第一版。
2. 优先级分三档
| 档位 | 含义 | 处理 |
|---|---|---|
| 必须有（P0） | 删了主流程走不通 | 第一版就做 |
| 应该有（P1） | 明显提升体验，但不做也能用 | 第一版之后第一件事 |
| 以后再说（P2） | 想得到，但和主流程无关 | 写进不做清单，先不做 |
3. 例子：学习打卡板
| 放进 MVP（P0） | 放进不做清单（P2） |
|---|---|
| 新增任务 | 登录 / 注册 |
| 标记完成 | 云同步 / 多设备 |
| 按分类筛选 | 社交分享 |
| 本地保存 + 刷新不丢 | 图表报表 / 成就系统 |
| 导出 JSON 备份 | 提醒推送 / 换肤 |
4. 第一次做项目，让失败成本尽量低
- 只在本机跑：不部署、不买服务器，坏了也不丢人；
- 只存本地：数据在你自己电脑上，不怕泄露；
- 只给自己用：不用考虑别人怎么想；
- 只做一条主流程：跑通了再谈第二个。
一句话：第一个项目不是证明“我能行”，是证明“这条路走得通”。
三、写一页 PRD
1. 四块，缺一不可
| 块 | 回答的问题 | 写不好会怎样 |
|---|---|---|
| 目标 | 给谁、解决什么问题 | AI 会自由发挥，做出一堆你没要的 |
| 功能清单 | 有哪些功能、优先级 | 分不清主次，先做了花边 |
| 验收标准 | 每条功能怎么算“做完” | 你没法判断做完了没有 |
| 边界与不做 | 不做什么、什么算失败 | 出错时无从下手，需求无限膨胀 |
2. 逐块写作要点
① 目标
- 一句话：给谁 + 解决什么 + 形态（网页 / 桌面 / 小程序）；
- 别写“做一个优秀的 XX”——那是口号，不是目标。
② 功能清单
- 每条一句话，动宾结构（“新增任务”“按分类筛选”）；
- 每条标 P0 / P1 / P2（见上一节）；
- 控制在 5~8 条 P0，多了就是范围失控。
③ 验收标准
- 每条功能至少配 1 条，可观察、可测（写法见下一节）；
- 至少 2 条覆盖失败路径（输错、导入坏文件、断网……）。
④ 边界与不做
- 明确列出不做清单；
- 写清“什么情况算失败”（而不是只写成功路径）。
3. 完整示例：学习打卡板一页 PRD
# 目标
给「我自己」用的本地学习打卡板：记录每天的学习任务并看到进度。
形态：单个网页，本地打开，不联网、不注册。
# 功能清单（P0）
1. 新增任务（标题 + 分类）
2. 标记完成 / 取消完成
3. 按「全部 / AI 基础 / Agent / Vibe Coding」筛选
4. 本地保存，刷新不丢
5. 导出 JSON 备份
# 验收标准
- 空状态：没有任务时显示引导文案，不显示空白列表
- 新增任务后刷新页面，数据仍存在
- 三种分类筛选正确；切到「全部」恢复完整列表
- 输入为空或超长时给出提示，且不写入数据
- 导出的 JSON 可被重新导入；非法 JSON 不覆盖现有数据并提示错误
- 窄屏无横向滚动条；键盘可完成主要操作
# 边界与不做
- 不做：登录注册、云同步、多设备、社交分享、图表报表、提醒推送
- 失败定义：数据写入失败、导入覆盖了旧数据、筛选结果与预期不符拿不准就直接让 AI 起草：「我要做<项目>，用户是<谁>，按一页 PRD 整理，逐条写可验证的验收标准，然后列出我还没想清楚的问题来问我。」
4. 一页 PRD 和完整 PRD，给 AI 哪个
| 项目规模 | 给 AI 什么 |
|---|---|
| 单次小练习、一次做完 | 一页 PRD（上面这种）就够 |
| 要做一阵子、会长期维护 | 完整 PRD 存 docs/PRD.md，再压一页说明当“摘要” |
规则：每次会话先读短的（一页说明），需要细节时再让它翻 PRD。 交接的具体步骤见从 0 到 1 实战 · 第 2 步。
四、验收标准怎么写才可验证
1. 唯一的判据
一条验收标准，你能不能在 30 秒内手动验证它的真假？不能，就继续拆。
2. 好例坏例对照
| ❌ 不可验证（形容词） | ✅ 可验证（动作 + 结果） |
|---|---|
| 界面要好看 | 窄屏无横向溢出；主色与按钮一致 |
| 要好用 | 键盘可完成主要操作 |
| 数据别丢 | 新增后刷新页面，数据仍存在 |
| 导入要稳 | 非法 JSON 不覆盖现有数据，并给出错误提示 |
| 速度快 | 100 条任务时列表滚动不卡顿 |
| 分类要准 | 三类各加 1 条，切换筛选后各只显示 1 条 |
3. 八类必测（照着一张表过一遍）
| 类别 | 问自己 | 示例标准 |
|---|---|---|
| 空 | 没有数据时什么样 | 显示引导文案，不留空白列表 |
| 非法 | 输错了怎么办 | 非法金额被拦截并提示，不写入 |
| 边界 | 极长 / 极大 / 极小 | 超长标题被截断或拒绝，界面不崩 |
| 重复 | 连点两次会怎样 | 连点「添加」只新增一条 |
| 刷新 | 刷新 / 重开后还在吗 | 刷新页面数据仍存在 |
| 返回 | 中途退出再回来 | 返回后仍停在原列表 |
| 权限 | 能不能看到不该看的 | 只能看到自己的数据 |
| 失败 | 外部失败怎么办 | 导入失败不清空原数据，且给出可读错误 |
4. 数量克制
- 一页 PRD 的验收标准控制在 5~8 条；
- 写太多你会懒得验；写太少等于没写；
- 每条都要能逐条打勾，不能打勾的就重写。
五、原型图与页面清单
1. 原型图就是“骨架”
原型图（线框图）不画颜色、不画图标，只画结构：哪里有输入框、哪里有列表、按钮放哪、页面之间怎么跳。
- 不需要设计软件——纸笔、白板就够；
- 也可以让 AI 生成一版低保真草图，你“指哪改哪”；
- 有草图就截图，配文字一起发给支持图片的 Agent，效果好很多。
2. 产出：页面清单
一页一张表就够：
| 页面 | 关键元素 | 从这里能去哪 |
|---|---|---|
| 主列表页 | 输入框 + 添加按钮、任务列表、筛选栏、计数 | 空状态（无任务时） |
| 空状态 | 引导文案 + 一个“新增任务”入口 | 回到主列表页 |
打卡板第一版两屏就能开工——别一上来画十个页面。
3. 别忘四种状态
每个页面都问一遍：
- 空：没有数据时长什么样；
- 加载：数据还没来时（本地应用可省略）；
- 成功：正常显示；
- 错误：失败了怎么提示、原数据在不在。
新手最常漏的是空状态和错误状态——而这两处恰恰最容易出丑。
六、让 AI 反问
1. 追问模板（直接复制）
这是我的项目想法：<一句话>。
请先不要写代码，只做两件事：
1. 列出 5 个我还需要想清楚的问题，逐条问我；
2. 指出其中哪些属于「第一版可以不做」，单独列一份不做清单。把它的回答补回 PRD，盲区自然就少了。
2. 十个常见盲区（自查清单）
- 数据存哪？换设备还在吗？
- 多人用还是一个用？
- 出错时是“提示”还是“静默失败”？
- 有没有“只有我听懂”的术语？换成白话了没？
- 一条数据最多多大／多少条？
- 有没有涉及账号、付款、隐私？（有就得切换工程化流程）
- 用户点错了能撤销吗？
- 删除是硬删还是可恢复？
- 第一版明确不做的是什么？（写下来了吗）
- 我打算怎么验证“做完了”？
3. 让 AI 挑战你的需求
追加一句，效果很好：
请指出我这个需求里**最可能在实现时返工**的三处，并说明原因。它往往会点出你没写的边界条件——比你自己憋半天管用。
七、需求会变：怎么改才不乱
需求一定会变。变不可怕，乱才可怕。 三条纪律：
- 先改文档，再改代码：需求变了先动 PRD，再让 AI 动代码——否则文档和实现各说各话；
- 一次只改一件事：改需求 + 加功能 + 顺手重构，三件事一起做，出问题无法定位；
- 记一条变更：每次改需求在 PRD 末尾追加一行，别覆盖原文。
变更日志长这样：
| 日期 | 改了什么 | 为什么 |
|---|---|---|
| 09-20 | 加「导出 JSON」 | 怕换电脑丢数据，优先级从 P2 提到 P0 |
| 09-22 | 砍「深色模式」 | 和主流程无关，移入不做清单 |
不做清单是你的守门员：有人（包括你自己）想加功能时，先看它在不在清单里。
八、常见坑
| 坑 | 表现 | 怎么破 |
|---|---|---|
| 把方案当需求 | “我要用 Vue 做”被当成需求 | 需求只说“要什么”，方案留到技术选型 |
| 形容词验收 | “要流畅”“要好看” | 换成可观察、可测的动作 + 结果 |
| 需求膨胀 | 功能越加越多，永远做不完 | 回不做清单；问“删了主流程还走通吗” |
| 过度设计 | 第一版就上账号体系、后台管理 | 失败成本最小化：本机、本地、自己用 |
| 只写成功路径 | 没写“出错怎么办” | 验收标准至少 2 条覆盖失败路径 |
| 文档和实现两张皮 | 改了代码没改 PRD | 先改文档再改代码 |
动手练习
- 用「五个问题」把你的想法改写成 3 条需求句子。
- 自评：不是程序员也能看懂吗？能一眼判断做到没有吗？
- 写一份「不做清单」（至少 5 条），每条标 P1 或 P2。
- 自评：能不能说出“为什么把它放进去”？
- 产出一页 PRD（四块齐全），每条 P0 功能配 1 条验收标准。
- 自评：任取一条，能在 30 秒内手动验证真假吗？
- 画出第一版页面清单（两屏即可），并标注空状态和错误状态。
- 自评：有没有哪个页面漏了“没数据时什么样”？
检查点
- 能用一句话说清“给谁、解决什么、什么形态”；
- 有不做清单，且每条能说出理由；
- 一页 PRD 四块齐全，P0 功能 5~8 条；
- 每条 P0 功能至少 1 条可验证验收标准，且含失败路径；
- 有页面清单，标了空状态与错误状态；
- 需求变更时，先改文档再改代码。
常见问题
Q：一个人做小项目也要写 PRD 吗？ 不用写成正式文档，但至少写下验收标准——否则你自己都不知道做完了没有。
Q：功能越加越多怎么办？ 回到不做清单。每加一个功能，先问“删了它主流程还能走通吗”。能，就砍掉。
Q：验收标准写多少条合适？ 一页 PRD 建议 5~8 条。写太多你会懒得验，写太少等于没写。
Q：想不清楚需求怎么办？ 别憋着。用第六节的追问模板让 AI 问你，或先做一版最丑的能跑的东西，看着实物再改需求。
Q：PRD 和“一页产品说明”是同一个东西吗？ 不是。PRD 是给你自己和评审看的完整需求；一页产品说明是给 AI 看的精简上下文。项目小的时候可以用一页说明兼任。
Q：需求老变，是不是我能力不行？ 不是。需求变是常态。要练的不是“一次想全”，而是改得有序：先改文档、一次一改、留变更记录。
小结与下一步
需求想清楚，AI 才可能做对。可直接复制的完整 PRD 模板见模板库；把文档交给 AI 的具体步骤见从 0 到 1 实战；想深入提示词写法见提示词与上下文工程。