Prd

/prd — 把模糊点子变成可落地的 PRD

帮没有产品背景的人，通过和 AI 对话，把一个模糊的想法一步步变成可以直接拿去 coding 的需求文档。

核心理念来自实践经验：不要让 AI 一上来就写完整 PRD。AI 写 PRD 有三个通病——幻觉迎合（你说啥它都说好，不挑战你）、细节模糊（没有状态、字段、文案、异常）、返工成本高（需求没对齐就 coding，后面改一处全盘重来）。解法是拆成两步：先出精简版对齐方向，再出落地版补全细节。

适用边界

• ✅ 个人/小团队的产品创意、App、小程序、工具、网站，准备用 vibecoding 实现
• ✅ 优化一份已有的、写得不够落地的需求文档
• ✅ 给已有产品增加一个新需求
• ❌ 企业级工具链需求规格说明书（SRS）、甲方验收文档 → 用 /需规、/需求澄清、/验收清单

三种模式（开场先确认是哪种）

| 模式 | 触发 | 做什么 | |------|------|--------| | 从零生成 | "我有个点子想做" | 走完整两阶段流程 | | 优化已有 | "帮我把这份需求改得能落地" | 读入现有文档 → 诊断缺口 → 直接补全到落地版结构 | | 新增需求 | "给这个产品加个 X 功能" | 复用已有产品上下文 → 只对新功能走两阶段 |

不确定时直接问用户一句"你是想从零开始、优化现有文档、还是加新需求？"

两个非从零模式的要点：

• 优化已有：先方向后细节，别一头扎进补格式。用概念版模板的八个字段扫一遍现有文档——方向层（MVP 范围、明确不做）缺失或含糊的，先按阶段一补问对齐；方向没问题再进落地版。细节缺口直接拿 references/prd-template.md 末尾的自检清单当体检表逐条诊断，不另造清单。
• 新增需求：产品上下文按 用户给的旧 PRD > 已有代码/文档 > 现场问用户 的顺序补齐。输出交增量：新功能的完整六项细节 + 功能列表新增行 + 数据模型/接口的变更——加功能常牵动实体表，别漏。

---

阶段一：概念版 PRD（对齐方向，约 10 分钟）

目标是把模糊 idea 变成一段明确、精简的概念描述，确定 MVP 范围。不要直接写文档，先从三个视角连续提问诊断这个想法。

Step 1 — 三视角诊断

一次提问聚焦一个视角，不要一口气抛 15 个问题。每个视角追问到清楚为止：

用户视角（排除自嗨的伪需求）

• 目标用户是谁？年龄、职业、使用场景
• 他们现在用什么方式解决这个问题？痛点到底在哪？
• 你的产品到底帮他们解决了什么？真的帮到了吗？
• 这个功能他们多久用一次？

商业视角（判断能不能持续做下去）

• 一次性需求还是长期需求？
• 免费还是付费？买断 / 订阅 / 增值 / 打赏？
• 预期持续运营多久？

技术视角（判断能不能快速做出来）

• 产品形态？小程序 / iOS / 安卓 / H5 / Web
• 需不需要账号系统？
• 数据放本地还是部署云端？
• 有没有依赖的第三方服务？
• 能接受的开发周期 / 成本？

提问方式：可枚举的选项（产品形态、商业模式、数据本地/云端等）用 AskUserQuestion 工具出选择题让用户点选；能从上下文合理推断的，先给默认值请用户确认，不要全部开放式追问；每个视角 2~3 轮封顶，问不透就先给出你的建议让用户纠偏。

> 这一阶段要敢于挑战用户：发现是伪需求、范围过大、技术不现实时直接说，并解释为什么。这正是普通 AI 缺的——不要一味迎合。

Step 2 — 输出概念版 PRD

三视角聊透后，输出一份约 300 字、格式固定、字段精简的概念版（模板见下）。重点是圈定 MVP：

> 最忌讳大而全。先做一个最小可用版本（MVP）上线验证，而不是自嗨地把产品做得很大——大而全永远上不了线。聊嗨了往往会聊到很大的功能，这一步必须明确：哪些这期先不做，哪些必须先做出来。

概念版模板：

# 概念版 PRD：

一句话定位：

- 目标用户：
- 核心痛点：
- 核心价值：
- MVP 范围（本期做）：
- 明确不做（本期不做）：
- 商业模式：
- 产品形态 / 技术约束：
- 预期周期：

Step 3 — 确认并冻结需求范围

输出概念版后不要直接进入落地版。先把聊过的关键决策一一列出，让用户逐条再确认一遍：

> 这一步非常重要。如果在落地版甚至 coding 之后才改需求，返工代价极大——改一个点，流程图、状态机全得重来，既费时间又费 token。

用户明确说"确认/对齐了"之后，把概念版落盘留痕——写成 PRD--概念版.md（用户指定过路径用指定路径，否则放当前工作目录），作为阶段二的冻结基准，然后进入阶段二。不满意就回到 Step 1 继续聊，直到能准确描述出用户的想法。

---

阶段二：落地版 PRD（补全细节，约 30 分钟）

方向冻结后，产出可直接交付开发的落地版。结构和"五个盲区"已固化在 references/prd-template.md ——编写落地版前先读取该文件，严格按其结构填充，防止 AI 偷懒跳过细节。

功能多时分批写：每批 2~3 个功能，交付一批让用户过目一批，避免单次输出过长导致细节质量衰减。

落地版结构：

1. 概述 — 产品背景、目标、范围（含 / 不含）
2. 功能列表 — 本期功能 + 优先级排序
3. 功能详细说明 — 每个功能逐项覆盖五个盲区
4. 技术方案与数据模型 — 技术栈建议（含理由）+ 全局数据实体表 + 关键接口/读写时机，让 PRD 能直接作为 coding 输入而不只停在产品层
5. 交付契约 — 验收证据 + 禁止路径 + 取舍优先级 + 未知处置，约束执行者不走捷径

AI 最容易跳过的五个盲区（逐功能必填）

1. 用户流程 / 路径 — 正常路径 + 异常路径都要写
2. 状态机 — 枚举所有状态，每个状态怎么进、怎么出
3. 字段规范 — 是否必填、数据类型、长度限制、校验规则、报错提示文案
4. 文案规范 — 空状态 / 加载中 / 成功 / 失败文案；产品文案人设（可爱 vs 中性）
5. 异常状态处理 — 断网、超时、无数据、无权限、重复提交……怎么给用户反馈

> 反例：一个"提交"按钮，不约束时 AI 只会写"用户提交 → 显示成功页"。实际必须覆盖：提交失败怎么办、断网怎么办、没权限怎么办、重复提交怎么办。这些不写，开发阶段返工时间极长。

补充：能画就画用户核心流程图和关键页面线框图（ASCII 或 Mermaid），文字描述不如一张图清楚。

交付契约：约束执行者不走捷径

前四节描述要做什么，第五节约束不许怎么做。需求写得再完整，也挡不住执行者走捷径——mock 掉真实逻辑、删掉跑不过的测试、交个 UI 骨架就报告完成。PRD 交给 Agent 长程自主执行（/goal、目标模式）时尤其致命：跑偏几小时后才发现，返工代价远大于写这一节。

四项必填（结构见 references/prd-template.md 第五节）：验收证据（怎么证明做完了，不接受自述）、禁止路径（把"达成指标最偷懒的办法"逐条堵死）、取舍优先级（速度 vs 质量、性能 vs 功能冲突时保哪个）、未知处置（撞上 PRD 没写的情况，何时自行取默认值、何时必须停下来问）。

> 定义目标时，排除比设定更重要。肯尼迪登月宣言的关键不在"把人送上月球"，而在"并安全带回地球"——多出的这句话，删掉了"单程票"这个最省钱的解法。

---

交付后的下一步（主动提示用户）

落地版 PRD 完成后，提醒用户后续路径，并询问是否继续：

1. 用计划模式让 AI 产出完整开发计划：原型设计 → UI 设计 → 代码开发 → 测试验收 → 上线
2. 再开始 UI/UX 设计和 coding

交付契约那节写多细，看用户打算怎么用这份 PRD——不确定就问一句：

• 打算直接丢给 /goal、目标模式或新会话长跑几小时 → 五个小节必须填满再交付，这是唯一的防跑偏手段
• 自己边看边 coding、随时能纠偏 → 可精简到只保留禁止路径（5.2），其余按需

核心原则：先把需求对齐，再开始 vibecoding。 第一步需求评审决定了 80% 的结果。

输出与归档

• 概念版在冻结时已落盘（见阶段一 Step 3）；落地版默认直接输出在对话中
• 用户要求保存时，写成 .md 文件；若说"入库/存到知识库"，走 /zhishiku 存入 Obsidian 写作/ 目录

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: liuzhaowei1
• Source: liuzhaowei1/Digital--PRD-SKILL
• License: MIT

Install and usage instructions live in the source repository linked above.