PRD 专家

解决什么问题

不少 PRD 写到一半就成了技术方案：接口路径、表结构、组件选型一应俱全，需求与实现细节搅在一起。结果是产研团队反复对齐口径，AI 编程工具拿到的需求里混着设计约束，生成的代码被错误假设锁死。更常见的是模糊描述——「界面要美观」「性能要好」——开发只能猜，验收时扯皮。

核心能力与工作方式

这个技能扮演资深产品专家的角色，核心是四条方法论：

• 槽位填充法：把 PRD 模板的 8 个章节当作槽位逐一检查，信息足够才填充，缺失的标记待确认，不盲目生成全文。
• 引导与追问：关键信息不足时，一次提出 3–5 个聚焦核心缺口的问题（痛点、用户、约束、目标指标、优先级），拒绝「还有其他补充吗」式的开放式提问。
• 显式排他：严格区分 In Scope 与 Out of Scope，每个排除项注明原因（优先级低、技术限制、留待后续版本），守住项目节奏。
• 验证友好写作：拒绝空泛形容词，验收标准统一用 Given/When/Then 格式，例如：

Given 用户在登录页已输入手机号
When 输入非法字符并失焦
Then 输入框变红，显示「请输入正确的手机号」

PRD 按 8 节模板输出：TL;DR、问题定义与业务价值、用户角色与场景、功能需求矩阵（每条带唯一 ID、验收标准、前置依赖）、范围边界、非功能性需求、数据埋点与 KPI 映射、待确认项追踪表。功能 ID、结构化表格与 Given/When/Then 让 AI 编程 Agent 直接生成自动化测试用例，实现需求即测试。

适用边界与注意点

最核心的一条红线：PRD 只回答做什么（What），不回答怎么做（How）。后端 API、数据库表结构、技术选型、组件实现、协议定义等设计层内容均不在 PRD 范畴，技能会主动剥离混入的设计细节，提示移至独立的技术设计文档，给技术团队保留方案自由度。

另外，当用户需求本身模糊时，宁可多追问一轮，也不猜测后生成一份不准确的 PRD；信息完整度达到 70% 才直接进入生成阶段。