| name | dprd |
| description | 产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比" |
| argument-hint | [产品名] [对比维度] [目标用户] |
| context | fork |
| agent | general-purpose |
| allowed-tools | ["WebSearch","Read","Write","Edit","Grep","Glob","Bash"] |
| effort | high |
diwu-prd
产品需求分析方法论知识库。提供竞品分析、需求分级、方案对比等可复用框架，适用于任何产品规划和需求讨论场景。
竞品分析方法
调研步骤
-
搜索竞品：使用 WebSearch，关键词组合：
"{产品类型} competitors""{核心功能} best tools {年份}""{目标用户} solutions"
-
整理对比表：产品名称 x 核心功能维度，每格填写具体实现方式
-
差异化分析：
- 我们与竞品的核心差异点
- 竞品中值得借鉴的设计或功能
- 用户选择我们而非竞品的理由
对比表写作规范
- 每格必须是具体描述，不允许"快/慢/高/低"等单字评价
- 同一维度下不同产品的描述粒度保持一致
- 无法获取的信息标注"未公开"，不编造
用户画像与场景分析
核心定位三问
| 问题 | 目的 | 好的回答 | 坏的回答 |
|---|
| 要解决什么问题？ | 明确痛点 | "团队会议录音无法快速定位关键决策" | "提高效率" |
| 目标用户是谁？ | 圈定范围 | "每周至少 3 次团队会议的项目经理" | "所有人" |
| 核心场景是什么？ | 锚定用法 | "会后 5 分钟内找到某个议题的讨论结论" | "管理会议" |
场景分析维度
- 核心操作：用户最常执行的 1-3 个操作 + 完整使用例子
- 呈现粒度（涉及内容展示时）：逐条标注还是汇总展示？
- 边界：明确不做什么
- 涉及端：哪些平台/客户端？后端服务？
需求优先级：迭代层次方法论
层次定义
| 层次 | 含义 | 规则 |
|---|
| Layer 0（Demo 验证） | 结果不可预期的能力验证 | Layer 0 未通过时 Layer 1 不得开始 |
| Layer 1（必须） | 核心业务，不可拆分 | 最小可用产品 |
| Layer 2（增强） | 提升体验，依赖 Layer 1 | Layer 1 完成后才开始 |
| Layer N（扩展） | 可选功能 | 优先级由业务价值决定 |
核心原则：Layer 越高依赖 Layer 越低，不可倒置。
不确定性评估
何时需要 Layer 0（Demo）：
| 判断标准 | 可预期（直接集成） | 不可预期（需 Demo） |
|---|
| 有现成模式吗？ | 标准 REST CRUD、已有模式的 SSE | Prompt 效果、LLM 输出格式 |
| 结果可控吗？ | 输入-输出关系确定 | 依赖外部模型或不确定因素 |
Demo 命名规范
名称必须体现能力而非产品功能。判断标准：换一个产品，这个 Demo 还能用吗？
- ❌
hera-meeting-citation（产品特定）
- ✅
prompt-citation-stability（通用能力）
Demo 需求清单格式
| Demo 名称 | 验证什么不确定性 | 对应 Layer 1 功能 |
|---|
每条 Layer 0 对应一行。名称用 kebab-case，直接作为 /ddemo 的输入参数。
业务指标定义规范
成功指标
每条指标必须包含：
| 要素 | 说明 | 示例 |
|---|
| 口径定义 | 分子/分母 | "活跃用户 = 7 天内至少使用 1 次核心功能的注册用户" |
| 判定频率 | 多久看一次 | "周级" |
| 达标线 | 量化目标 | ">= 60%" |
不允许只写达标线不写口径。
失败止损条件
格式：若 X 连续 N 天触发 -> 执行 Y
必须写明：
方案对比方法论
对比表结构
维度 x 方案 A/B/C，每格必须是具体描述：
| 维度 | 方案 A | 方案 B |
|---|
| 开发成本 | "3 人周，需新建 2 个服务" | "1 人周，复用现有网关" |
| 性能 | "P99 延迟 200ms，需缓存层" | "P99 延迟 50ms，直连数据库" |
- ❌ "快"、"慢"、"高"、"低"等单字评价
- ✅ 具体的数值、工作量、实现方式
推荐策略
推荐必须包含两部分：
- 推荐理由：正向论证"为什么选这个方案"，而不是逐一排除其他方案
- 切换条件：什么情况下应该切换到备选方案
论证方式：
- ❌ 排除式："方案 A 延迟高所以不行，方案 B 成本高所以不行，所以选方案 C"
- ✅ 正向式："选方案 C，因为它在延迟和成本间取得最佳平衡（P99 < 100ms，月成本 < $500）。若延迟要求放宽到 500ms，方案 A 更简单"
约束发现方法
五维约束识别框架
五维约束识别：
| 维度 | 判断问题 | 约束类型 |
|---|
| 业务约束 | 100 年后还成立吗？ | 不随实现变化的本质规则 |
| 时序约束 | 有没有执行路径可以绕过这个规则？ | 状态转移、执行顺序 |
| 跨端约束 | 如果两个端定义不同，这是 bug 吗？ | 多端一致性要求 |
| 并发约束 | 两个线程同时做这件事会出问题吗？ | 并发安全规则 |
| 感知约束 | 超过这个阈值，用户会注意到吗？ | 用户体验底线 |
判断锚点：业务约束识别
- 正例："原始录音不可变，摘要可重新生成" — 100 年后成立，这是事实与解释的本质区别
- 反例："用 Opus 编码传输音频" — 编码格式会变，这是实现选择而非约束
- 边界例："Card 有且仅有 5 种类型" — 小心区分结构和值。"Card 是统一业务实体抽象"是约束，"恰好 5 种"是当前枚举值
判断锚点：时序约束识别
- 正例："录音停止后，同一 session 不可能重新进入录音状态" — 无执行路径可绕过，必须编码为状态机转移规则
- 反例："建议先上传再处理" — 有绕过路径（可以先处理），这是推荐而非约束
- 边界例："离线处理必须在音频上传完成之后" — 如果技术上可以边上传边处理但业务禁止，则是约束；如果技术上必须串行，则是实现限制
判断锚点：跨端约束识别
- 正例："CardType 在所有端完全一致" — 两端不同会导致用户看到 Unknown 类型，是 bug
- 反例："列表滑动动画的曲线" — 各平台遵循各自设计语言，不同不是 bug
- 边界例："排序规则" — 如果用户在两个设备上看到不同顺序会困惑，则是约束；如果只是展示偏好，则不是
约束发现示例
需求："用户通过蓝牙设备录音，设备断开时自动切换到手机麦克风继续录音"
识别约束：
- 业务约束：录音产生音频文件 + 转录文本，两者不可丢失
- 时序约束：音频源切换不可中断录音 session（idle → recording 后不可回退到 idle）
- 跨端约束：录音状态枚举在 iOS/Android 必须一致
- 并发约束：同一音频文件只有一个写入者
- 感知约束：音频源切换 < 100ms（超过用户会感知录音中断）
非功能性需求分类
边界条件与异常处理分组
按角色/层分组：
| 分组 | 覆盖内容 | 示例 |
|---|
| AI 行为 | 模型输出异常、超时、格式错误 | "LLM 返回空内容时显示默认提示" |
| 客户端 | 网络异常、状态不一致、UI 边界 | "离线时缓存最近 10 条记录" |
| 后端 | 服务不可用、数据一致性、限流 | "SMTP 不可用时返回 EmailServiceError" |
写作规范：
- 场景描述必须具体到触发条件
- 处理方式必须具体到行为
- ❌ "合理处理"、"重试"等模糊描述
- ✅ "重试 3 次，间隔 1s/2s/4s，仍失败则返回 503"
触发阈值表
涉及"显示/隐藏"类需求时必须输出：
不允许留给实现方自由发挥。
验收条件规范
- 验收条件按迭代层次分组
- 高层验收条件必须包含对低层的回归项
- 每个 Layer 的验收条件必须包含至少一条边界/异常场景（空状态、失败路径、边界值）
- 不允许只有 happy path
双端落地 Checklist
iOS 平台陷阱
@State 不能安全持有 Timer -> 必须用 @StateObject class 包装，deinit 中清理- SSE 解析中的共享可变状态 -> 必须约束在同一串行队列读写，不可跨线程
- 数据模型必须包含 envelope 层
Android 平台陷阱
@SuppressLint("CheckResult") 是订阅泄漏的信号 -> 必须用 CompositeDisposable 管理- 数据模型必须包含 envelope 层
端侧映射表格式
每端一张：| 需求点 | 推荐改动文件 | 说明 / 验收 |
Demo 阶段端侧约束
明确不做的事：不重构现有网络层 / 不引入新依赖管理框架 / 不修改与本需求无关的 ViewModel / Adapter
PRD 写作原则
- 论证型写作：每个段落遵循"我观察到 X → 所以判断 Y → 因此决定 Z"的结构，而不是"这是 A，这是 B，这是 C"的陈列。文档的目的是说服读者，不是罗列信息
- 脊梁贯穿：核心洞察是文档的脊柱，在开头立论、中段论证、结尾收束，至少出现 3 次
- 章节串联：每章结尾自然引出下一章的问题。读完全文应该像顺着一条河流走完，不像翻了一本字典
- 结论先行：每节开头说结论，细节后面展开
- 图表优于文字：流程用 mermaid，规格用表格，示例用代码块
- 具体优于抽象：避免"合理处理"、"适当优化"等模糊表述，写具体的值和行为
- 每个数字有出处：量化指标必须有推导过程（数据来源、计算方式），或显式标注"待验证"并说明验证方法。禁止凑整数
反模式速查
| 反模式 | 症状 | 正确做法 |
|---|
| 陈列式写作 | 段落以"这是 X"罗列，缺少因果推理 | 改为"因为 X → 所以 Y → 因此 Z"的论证式 |
| 脊梁缺失 | 核心洞察只出现一次或埋在中间章节 | 在开头立论、中段论证、结尾收束，至少 3 次 |
| 排除式论证 | "A 不行…B 不行…所以选 C" | 正向论证"选 C 因为…"，备选作切换条件 |
| 凑数字 | 量化指标无推导过程（85% 为什么不是 80%？） | 补推导过程，或标注"待验证"+验证方法 |
| 机械 diff | "继承/替换/新增"列表，无判断 | 改为"为什么保留 X"的判断论述 |
| 重复表达 | 多个表/段换角度说同一件事 | 合并为一处，选最有力的角度 |
| 零价值章节 | 删掉后文档完整性不受影响 | 删掉或合并入相邻章节 |
| 章节断裂 | 读完第 N 章不知为什么要读第 N+1 章 | 调整顺序或补充过渡 |
| 只写达标线 | 成功指标无口径定义 | 补充分子/分母和判定频率 |
| 线性路径 | 只写 Phase 1→2→3 无决策节点 | 每阶段间加量化决策门槛 |
| 模糊评价 | 方案对比用"快/慢/高/低" | 每格写具体数值或实现描述 |
| 只有 happy path | 验收条件无异常场景 | 每层至少一条边界/异常用例 |
| 产品命名 Demo | Demo 名体现产品功能而非能力 | 换产品还能用才是正确命名 |
| 多开关组合 | 多 Boolean 控制功能档位 | 用单枚举配置控制 |
