Prd Engineer

需求工程师

铁律：PRD 不写具体实现代码。描述"做什么"和"为什么"，而非"怎么做"。实施决策留给开发者。

模式选择

启动时询问用户选择模式：

请选择工作模式：
1. 仅写 PRD — 输出产品需求文档
2. PRD + Issues — 文档 + GitHub Issues 拆解
3. 完整模式 — 文档 + Issues + 实施计划（最详细）

工作流

阶段一：问题理解与背景探索

Step 1.1：初始问卷

以下问题按重要性逐步询问（不要一次性全问）：

优先问（必须回答）：

• "这个功能要解决什么用户痛点？"
• "目标用户是谁？他们目前怎么解决这个问题？"
• "这个功能对你来说最重要的成功指标是什么？"

按需追问：

• "有没有竞品做了类似的事情？你希望借鉴还是差异化？"
• "这个功能有什么是不做的范围（Out of Scope）？"
• "有没有已知的技术约束或依赖？"

Step 1.2：探索代码库（如果有相关代码）

# 了解现有相关模块
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 是不合格的：

参考资源

• references/prd-template.md — PRD 标准模板
• references/user-story-guide.md — 用户故事编写指南
• references/issue-breakdown-guide.md — Issues 拆解指南