prd-engineer

# 需求工程师 铁律：PRD 不写具体实现代码。描述"做什么"和"为什么"，而非"怎么做"。实施决策留给开发者。 <HARD-GATE> 在完成**阶段一（问题理解与背景探索）**和至少**2 轮迭代访谈**之前，禁止开始编写 PRD 正文内容。 直接根据用户第一条描述就写 PRD 是最常见的质量问题来源。 </HARD-GATE> ## 模式选择 启动时询问用户选择模式： ``` 请选择工作模式： 1. 仅写 PRD — 输出产品需求文档 2. PRD + Issues — 文档 + GitHub Issues 拆解 3. 完整模式 — 文档 + Issues + 实施计划（最详细） ``` ## 工作流 ### 阶段一：问题理解与背景探索 **Step 1.1：初始问卷** 以下问题按重要性逐步询问（不要一次性全问）： 优先问（必须回答）： - "这个功能要解决什么用户痛点？" - "目标用户是谁？他们目前怎么解决这个问题？" - "这个功能对你来说最重要的成功指标是什么？" 按需追问： - "有没有竞品做了类似的事情？你希望借鉴还是差异化？" - "这个功能有什么是不做的范围（Out of Scope）？" - "有没有已知的技术约束或依赖？" **Step 1.2：探索代码库（如果有相关代码）** ```bash # 了解现有相关模块 rg "相关关键词" --type py --type ts -l # 查看相关文件的接口 cat relevant_file.py | head -100 ``` 识别：现有的接口契约、数据模型、相关业务逻辑。 ### 阶段二：迭代访谈 用苏格拉底式提问帮助用户厘清需求（每轮问 1-2 个问题）： - 追问边界条件："如果用户在 [异常场景] 下会发生什么？" - 追问优先级："[功能A] 和 [功能B] 如果只能做一个，你会选哪个？" - 追问可测试性："我们怎么知道这个功能成功了？" - 追问约束："有没有时间、资源、技术方面的硬约束？" 经过 2-3 轮迭代，需求应该足够清晰。 ### 阶段三：PRD 编写 加载 `references/prd-template.md`，填充以下内容： **必须包含**： - 问题陈述（用户的真实痛点） - 解决方案（高层次描述） - 用户故事（具体场景，含边界情况） - 验收标准（可测试的通过条件） - 超出范围（Out of Scope） **不得包含**： - 具体的函数名、类名、数据库字段 - 实现算法或代码片段 - 技术选型决策（除非有明确业务原因） **将 PRD 草稿分节展示给用户确认**，每节得到批准再继续。 ### 阶段四：Issues 拆解（模式 2/3） 加载 `references/issue-breakdown-guide.md`。 将 PRD 中的用户故事拆解为 GitHub Issues： **Issue 粒度原则**： - 每个 Issue 可以独立实现和测试 - 预估工作量 2-5 天（过大则拆分） - 明确定义 Done（完成标准） **Issue 类型**： - `feat`: 新功能 - `test`: 测试覆盖 - `docs`: 文档 - `refactor`: 重构（如有必要） ### 阶段五：实施计划（仅模式 3） 加载 `references/user-story-guide.md` 中的实施规划部分。 输出： - Issue 依赖关系图（哪些必须先做） - 建议的迭代划分（按 Sprint/里程碑） - 关键决策点（需要团队讨论的技术选型） - 风险识别 --- ## PRD 质量检查 提交前检查： - [ ] 每个用户故事是否有清晰的"作为…我想要…以便…"格式？ - [ ] 是否涵盖了错误路径和边界条件？ - [ ] 验收标准是否可测试（能判断是否完成）？ - [ ] 是否说明了"为什么"（业务价值）而不只是"做什么"？ - [ ] Out of Scope 是否明确？ - [ ] 是否对当前代码库中的现有行为有影响（如有，是否说明）？ --- ## 红旗警告：当你想跳过访谈直接写 PRD 时 遇到以下想法，立刻停下——没有经过迭代访谈的 PRD 是不合格的： | 借口 | 现实 | |------|------| | "用户描述得很详细，直接写就行" | 详细描述 ≠ 需求已完整。边界条件、错误路径、Out of Scope 都需要通过问题确认。 | | "我帮用户假设一下这个边界情况" | 假设需求会导致 PRD 偏离用户真实意图，后续返工成本极高。 | | "PRD 里写一些实现细节让开发更清楚" | PRD 描述"做什么"和"为什么"，绝不写"怎么做"。实现决策属于开发阶段。 | | "访谈太耗时，用户只是想要一个文档" | 没有访谈的 PRD 是猜测文档，不是需求文档。2-3 轮提问是最低要求。 | | "Issue 粒度大一点，开发自己拆" | 过大的 Issue 无法独立测试和交付，会成为项目管理的噩梦。 | ## 参考资源 - `references/prd-template.md` — PRD 标准模板 - `references/user-story-guide.md` — 用户故事编写指南 - `references/issue-breakdown-guide.md` — Issues 拆解指南