# /prd - 业务型 PRD 与 MVP 边界 ## 命令定位 从业务视角写一份可执行的 PRD,聚焦业务逻辑流、角色分工、 数据流转,明确 MVP 的精确边界和功能优先级。 ## 第 0 步:加载项目状态 执行本指令前,先读取项目根目录下的 `.yxstack/_state.md`(如果项目 CODEBUDDY.md 自定义了 YxStack 存档路径,则使用自定义路径): - 了解项目当前所处的 YxStack 阶段(exploration/validation/positioning/pricing/growth) - 确认已有的关键假设和决策 - 检查是否有与本次指令相关的待处理项 - 如果 _state.md 不存在,说明这是项目首次使用 YxStack 然后按原有规则检查历史记录: 执行本指令前,先检查当前项目根目录下的 `.yxstack/` 目录(如果项目 CODEBUDDY.md 自定义了 YxStack 存档路径,则使用自定义路径),查找近期同指令(prd)或相关(pfit/pos)的历史记录: - 如果已有痛点验证(pfit)或定位分析(pos)→ 作为 PRD 输入,不重复追问 - 如果已有同类 PRD → 标注与历史版的差异/迭代点 - 如果没有历史记录 → 跳过,正常执行 ### Confusion Protocol(假设暴露) 在执行本指令时,遇到以下情况停止推理,转为追问用户: - 对用户业务场景的关键事实在猜测而非确认 - 对市场/用户行为的判断缺少定量或定性证据 - 在多个不相容假设之间跳转(信号:假设 > 3 个未验证) 激活时机:上述任一条触发时,列出已知/未知,追问缺失信息,不继续产出。 ## 核心追问清单 ### 1. 业务目标 - [ ] 这个产品要解决的业务问题一句话是什么? - [ ] 成功的衡量标准是什么?(不是功能上线,是什么指标变了) - [ ] 不做这件事的代价是什么? ### 2. 角色与场景 - [ ] 涉及哪些角色?(用户、管理员、运营、合作伙伴) - [ ] 每个角色的核心场景是什么?(不列功能,列场景) - [ ] 角色之间怎么互相影响? ### 3. 业务逻辑流 - [ ] 核心业务的主流程是什么?(异常流先放一边) - [ ] 谁在什么条件做什么事?(判断逻辑用自然语言说清楚) - [ ] 数据从哪来、到哪去? ### 4. MVP 切分 - [ ] 如果只做一件事验证核心假设,做什么? - [ ] 「没有这个,用户流程会断」的功能 vs 「有了更好玩」的功能 - [ ] MVP 的用户体验底线是什么? - [ ] 不做 MVP 之外的功能,等什么信号后才决定做? ### 5. 优先级排序 - [ ] 用「用户价值 × 实现成本 × 商业影响」三维排优先级 - [ ] 哪些功能是你敢切掉的?依据是什么? - [ ] 有没有「做了反而有害」的功能? ## 输出结构 1. **业务目标**:一句话 + 成功指标 2. **角色映射**:角色 × 核心场景矩阵 3. **核心业务流**:主流程叙事(非流程图) 4. **MVP 定义**:干什么、不干什么、验证什么 5. **优先级清单**:P0/P1/P2 分类 + 取舍理由 ## 常见误区 - PRD 写成功能说明书而不是业务文档 - MVP 边界无限扩大(加了太多"万一需要"的场景) - 没有明确「不做哪些」——真正重要的决策 ## 存档规则 执行完毕生成报告后,按以下规范存档: **默认路径**:`{项目根目录}/.yxstack/prd-{日期}-{一句话摘要}.md` (如果项目 CODEBUDDY.md 自定义了 YxStack 存档路径,优先使用自定义路径) **格式**:YAML frontmatter + 报告正文 ```yaml --- title: "{一句话标题}" author: "{执行者}" date: "{YYYY-MM-DD}" tags: ["关键词1", "关键词2"] status: draft # draft → validated → outdated --- ``` ## 更新项目状态 ### 追加事件日志 向 `.yxstack/_timeline.jsonl` 追加一行: ```json {"skill":"prd","event":"completed","ts":"当前时间","phase":"当前阶段","summary":"本次产出核心结论","assumption":"本次新增假设(有则填,无则留空)","decision":"本次关键决策(有则填,无则留空)"} ``` ### 更新状态快照 更新 `.yxstack/_state.md`: - 如果本次执行推动了项目阶段前进,更新 `phase` 字段 - 本次新增的假设 → 写入「关键假设」表,status: active - 如果本次结论推翻了旧假设 → 将对应旧假设标记为 challenged 或 outdated - 如有重要决策 → 追加「决策链」 - 更新「待处理项」:标记已完成的,新增下一步建议 - 如果 _state.md 不存在,按模板创建(参考 templates/state_template.md) - 每个 active 假设必须附带验证标准(一句话:用什么证据可证实/证伪) - 同时 active 假设不超过 5 条,达到上限时必须先标记一条旧假设为 outdated 才能新增