name: write-prd description: PRD 编写——当用户描述产品想法、功能需求或改进意见时，按两阶段流程产出可 vibe coding 的精确 PRD。含三视角诊断、概念版、范围冻结、落地版、六大盲区自检。

PRD Writer

当用户描述产品想法、功能需求或改进意见时，按以下两阶段流程产出可直接用于 vibe coding 的精确 PRD。

核心约束：在完成三视角诊断并输出概念版之前，禁止输出任何形式的 PRD 文档。

触发确认

收到用户描述后，先用一句话复述你理解的核心需求，然后说明接下来会通过几轮提问对齐需求，再开始 Phase 1。

Phase 1：三视角诊断

执行规则

禁止在此阶段输出完整 PRD、功能列表或任何结构化文档
每次提问不超过 3 个问题，等待用户回答后再继续，不得一次抛出全部问题
三个视角的必问项全部收集完毕后，进入 Phase 2

提问顺序与必问项

第一轮（用户视角，选其中最关键的 2–3 个提问）： 1. 目标用户是谁？（年龄段、职业背景、使用场景） 2. 他们现在用什么方式解决这个问题？ 3. 你的产品帮他解决的是哪一件具体的事？ 4. 这个场景下用户会多久用一次？（每天 / 每周 / 偶尔）

第二轮（商业视角，全部询问）： 1. 这是免费产品，还是用户要付费使用？ 2. 如果收费，模式是哪种：一次性买断 / 订阅 / 免费增值？ 3. 预期把这个产品做多久？（验证型项目 / 长期运营）

第三轮（技术视角，全部询问）： 1. 产品形态：小程序 / iOS / Android / H5 / Web App？ 2. 是否需要用户账号和登录体系？ 3. 数据存在哪里？本地存储 / 云端数据库？ 4. 是否依赖第三方服务？（地图、支付、AI API 等，请逐一列出） 5. 产品预计有几个主要页面？核心导航结构是什么？（例如：底部 Tab / 侧边栏 / 单页面滚动）是否有独立于主导航的页面，如引导页、弹窗、详情页？ 6. 这个版本预期几周内可以做出来？

Phase 2：概念版输出 + 方向对齐

三视角诊断完成后，立即输出概念版 PRD。严格使用以下模板，总字数不超过 200 字，禁止自行扩展结构：

## 概念版 PRD

核心用户：[一句话描述目标用户]
要解决的一件事：[一个具体痛点，不能写多个]
产品形态：[平台]
最小可用版功能（≤ 3 条）：
  1. [功能一]
  2. [功能二]
  3. [功能三]
本版本不做：[明确排除的功能]
商业模式：[收费方式 或 免费]
技术前提：[账号体系 / 数据方案 / 第三方依赖]

输出后询问：

以上是概念版 PRD，请确认：① 方向是否对齐？② 有需要调整的地方吗？确认后进入落地版。

若用户有调整 → 修改概念版后重新询问，直到确认为止
若用户确认 → 进入 Phase 3

Phase 3：范围冻结

进入落地版之前，输出以下清单，要求用户明确确认：

在开始落地版之前，请确认以下内容不会再修改：

✅ 目标用户：[从概念版填入]
✅ 核心功能（≤ 3 条）：[从概念版填入]
✅ 平台选择：[从概念版填入]
✅ 本版本不做：[从概念版填入]

请回复"确认"后继续。

收到确认后进入 Phase 4。若用户仍有修改，返回 Phase 2 重新对齐。

Phase 4：落地版 PRD

执行规则

任何字段不得出现"待定"、"TBD"、"视情况而定"等模糊表述
每个功能模块必须完整输出五大盲区对应的内容
严格按照以下三层结构输出

一、概述

文档信息

版本号	日期	作者
V 1.0.0	[当前日期]	—

1. 需求背景（必写）

目标用户现状：[从三视角诊断结论填入，描述用户当前处境]
核心痛点：[用户面临的具体问题]
当前问题汇总：

问题点	问题描述	当前影响
[问题一]	[具体描述]	[对用户的影响]
[问题二]	[具体描述]	[对用户的影响]

2. 需求目标（必写）

业务目标（1–3 条，需可验证）：
[目标一]
[目标二]
成功标准：

指标	当前状态	目标状态
[关键指标]	[现状/未知]	[预期结果]

3. 需求范围（必写）

包含：[列出 Phase 3 冻结的功能]
不包含：[列出 Phase 3 明确排除的功能]

4. 参考资料（按需）

文档名称	链接/说明
竞品参考
原型地址

二、功能列表（必写）

模块	功能名称	功能说明	优先级
[模块]	[功能名]	[用户可完成…操作]	P0
[模块]	[功能名]	[新增…能力]	P1

优先级定义：P0 = MVP 必须上线 / P1 = 重要但可延后 / P2 = 可选优化

三、页面结构与导航设计（必写）

在功能说明之前，必须先描述清楚整体导航结构和每个主要页面的职责与元素。禁止跳过此章节直接输出功能说明。

整体导航结构

[导航类型：底部Tab / 侧边栏 / 单页面]
├─ [页面一名称]  → [一句话职责]
├─ [页面二名称]  → [一句话职责]
└─ [页面三名称]  → [一句话职责]

[页面名称]（每个主要页面单独一节）

页面职责： [这个页面解决用户的什么问题，一句话]

页面元素（从上到下）：

区域	内容	显示条件
[区域名]	[展示内容]	[何时显示 / 始终显示]
[区域名]	[展示内容]	[何时显示 / 始终显示]

本页面不展示： [明确列出不放在这个页面的内容，避免范围蔓延]

独立页面 / 弹窗（按需）

列出不属于主导航、但独立存在的页面，如引导页、权限申请页、弹窗等。

页面/弹窗名称	触发条件	与主导航的关系
[名称]	[何时出现]	[覆盖主页面 / 替换主导航 / 独立展示]

四、功能说明

每个 P0/P1 功能单独一节，按以下结构输出。

功能 N：[功能名称]

功能描述

用户可在 [所属页面] 完成 [目标行为]，解决 [具体问题]。（必须注明所属页面，与第三章页面结构保持一致）

用户流程（必写，含正常路径 + 所有异常路径）

[入口]
  ↓
[步骤一]
  ↓
[步骤二]
  ├─ 成功 → [结果反馈]
  ├─ 失败（原因一）→ [异常处理]
  └─ 失败（原因二）→ [异常处理]

状态机（必写）

状态名称	进入条件	退出条件	用户可见表现
[状态一]	[触发条件]	[转换条件]	[界面表现]
[状态二]	[触发条件]	[转换条件]	[界面表现]

字段规范（有输入字段时必写）

字段名	类型	是否必填	长度限制	校验规则	错误提示
[字段]	文本/数字/…	是/否	[上限]	[规则描述]	[提示文案]

文案规范（必写）

场景	文案内容
空状态	[当无数据时显示的文案]
加载中	[加载状态提示]
操作成功	[成功反馈文案]
操作失败	[失败提示文案]
权限不足	[权限提示文案]
网络异常	[网络错误提示]

异常情况处理（必写）

异常场景	触发条件	处理方式	用户反馈
网络断开	请求失败	[处理逻辑]	[提示文案]
数据为空	无内容返回	[处理逻辑]	[空状态方案]
操作超时	超过 X 秒	[处理逻辑]	[超时提示]
权限不足	未登录/无权限	[处理逻辑]	[引导方案]

六大盲区自检清单

落地版全部输出完成后，对每个功能模块执行以下检查。有任何一项未覆盖，补充后再输出最终版：

[ ] 页面结构：是否输出了「三、页面结构与导航设计」章节？每个主要页面的职责、元素、不展示内容是否明确？独立页面/弹窗的触发条件是否说明？
[ ] 异常交互：每个功能的用户流程是否包含异常路径？（不能只写成功路径）
[ ] 状态机：所有状态是否完整列出？每个状态的进入和退出条件是否明确？
[ ] 字段规范：每个输入字段是否有类型、必填、长度、校验规则、错误提示？
[ ] 文案规范：空状态、加载、成功、失败、权限、网络异常六类场景文案是否齐全？
[ ] 流程图：用户流程是否包含分支和异常分支？（不能是单一直线流程）

自检通过后，输出："PRD 落地版已完成，六大盲区均已覆盖。"

PRD 完成后的下一步

PRD 经用户确认后，应作为 dfc Kanban 流水线的 spec 阶段：

保存 PRD 文档到 docs/prd/YYYY-MM-DD-<topic>-prd.md
启动 dfc 流水线（见 infrastructure/multi-profile-workflow skill）
forge 任务 body = PRD 文档路径 + 从 PRD P0 功能列表派生的 DoD
chief 审查基准 = 完整 PRD（含状态机、字段规范、异常处理），不限于简化的 DoD

小改动 / Bug fix / 改配置 —— 跳过 PRD 阶段，直接用 1-3-1 分析后进入 dfc。