# 写PRD

> 产品需求文档（设计师视角的工程交付桥接）。把已对齐的设计产出（/设计简报 + /用户故事 + /站点地图 + Flow Web/Mobile）整合为 8 段式 PRD，让工程师或 coding agent（Cursor / Claude Code 等）直接消费——含完整功能描述、Given/When/Then 验收标准、设计触点、已生成的设计资产引用、风险与发布计划。 触发关键词：写 PRD、生成需求文档、把这个交给工程、给工程师写文档、make this shareable、handoff to engineering、转 PRD、/用户故事 转 PRD、需求文档、product requirements document。 排除（反向）：读取已有 PRD 提炼设计字段（用 /读需求）、写用户故事（用 /用户故事）、做设计走查（用 /设计走查）、做项目复盘（用 /设计复盘）。

- Skill: `ahang1598/prd` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ahang1598/prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/prd/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/ahang1598/prd

---


# 写PRD

> 你是 PRD 生成专家。本 Skill 把已对齐的**设计产出**——Brief（业务对齐）+ Stories（用户故事）+ Sitemap（IA 骨架）+ Flow Web/Mobile（设计稿 / 代码）—— 整合为一份**工程师或 coding agent 可直接消费**的 8 段式 PRD。

**这是设计师视角的 PRD，不是 PM 视角的 PRD**：
- PM 的 PRD：从市场/用户研究开始，论证为什么做、做什么
- 设计师的 PRD：基于**已对齐的设计方向**，告诉工程师**做什么、按什么标准做、参考哪些已生成的设计资产**

**核心使命**：让独立设计师 / AI 原生设计师能在没有 PM 的情况下，把设计产出**完整、结构化、可执行**地交付给工程实现。

---

## Chain Context

### 上游读取（Step 0 执行，**最关键的一步**）

PRD 的质量直接取决于上游 context 的完整度。按以下顺序尝试读取：

1. 扫描会话中的 marker：`brief` / `stories` / `sitemap` / `flow-web` / `flow-mobile` / `frame` / `scope` / `check`
2. 读取项目目录 `spark-output/context/*.json`
3. 至少要读到 **stories**（最低门槛），否则降级到 Step 1 询问

**8 段输出结构是强约束**（PRD 必须含全部 8 段，缺一段标为 thin_sections 在 Step 3 输出）：

| # | 章节名 | 一句话定位 |
| --- | --- | --- |
| 1 | Summary / Overview | 60 秒读完版本 |
| 2 | Background / Business Context | 为什么做这个 |
| 3 | Personas / User Segments | 给谁做 |
| 4 | Goals & Success Metrics | 怎么算赢 |
| 5 | Value Proposition | 我们押什么 |
| 6 | Solution & Feature Scope | 做什么 + MVP 范围 + 设计资产 ⭐ 最重要 |
| 7 | Constraints & Risks（含 Release Plan） | 不做什么 + 风险分层 |
| 8 | Backend Dependencies / Release Approach | 工程依赖 + 上线节奏 |

**字段映射（PRD 8 段式如何消费上游 chain JSON）**：

| PRD 章节 | 上游来源 | 字段映射 |
| --- | --- | --- |
| Section 1 — Summary | brief + frame | `brief.business_context` + `brief.business_goal` + `frame.lean_direction` |
| Section 2 — Background | frame + brief | `frame.persona.workaround` + `frame.business_angle.why_now` + `brief.out_of_scope` |
| Section 3 — Personas | frame.persona / stories.persona | 完整 persona 结构 |
| Section 4 — Goals & Metrics | brief.business_goal + brief.design_criteria.quantitative | 业务 KPI + 体验度量 |
| Section 5 — Value Prop | frame.directions[lean] | user_value + business_value + 差异化 |
| Section 6 — Solution & Feature Scope | **stories** + flow-web/mobile + sitemap + journey | stories.acceptance_criteria + design_touchpoints + sitemap.pages + flow.output_files + journey.key_moments |
| Section 7 — Constraints & Risks | brief.constraints + frame.critical_assumption + check.findings + journey.dropout-risk | 技术约束 + 关键假设 + 已识别问题 + 流失风险 |
| Section 8 — Release Approach | stories.priority + frame.critical_assumption | MVP 范围 + 先发顺序 |

⛔ **消费上游 chain context 是强制约束**：
- 上游有的字段必须读，不能凭直觉重写（避免跟 brief / stories 产生事实漂移）
- Section 6 必须**列出全部上游 flow.output_files 中的 .tsx 路径**作为「设计资产清单」，让工程师能直接接走
- Section 7 的 risks 必须**从 check.findings 自动提取未修的 Major / Minor**，不要凭空写

读到上下文后告知用户："已读到 [项目名] 的 [N] 个上游 Skill 产出，将整合生成 8 段式 PRD。预计 [strong/moderate/thin] 完整度——[列出薄弱章节]。"

### 下游输出（Step 4 执行）

按 [chain-protocol.md](../../chain-protocol.md) §2.1 v1.1 智能适配规则：

1. **保存 Markdown PRD 文件**（核心产物）：`spark-output/prd/[direction-slug].md`
2. **写盘 chain context**：写入 `spark-output/context/prd.json`（含元数据 + 章节摘要，**不含完整 PRD 文本**——PRD 全文在 `spark-output/prd/[slug].md`）
3. **chat 输出紧凑 marker**（⛔ 不要在 chat 内输出完整 JSON）：

   ```
   <!-- spark-context:prd ref="spark-output/context/prd.json" -->
   PRD 已保存：project=[project_name]，direction=[direction]，[N] 个 Story / [M] 个 acceptance_criteria，prd_file=spark-output/prd/[slug].md
   <!-- /spark-context:prd -->
   ```

降级 fallback：若写盘失败，输出完整 JSON marker（无 ref）。详见 §2.1。

下游可消费 Skill：**Retro**（项目复盘归档）/ **Pitch**（汇报材料引用）。

### 字段流向下游

- `prd.sections_summary` → **Retro** 的 Decision Validation 输入（事后看每个 PRD 决策是否成立）
- `prd.success_metrics[]` → **Retro** 的"假设验证"输入（PRD 写明的指标是否达成）
- `prd.thin_sections[]` → **Retro** 的"做得不好"输入（PRD 写薄的段对应链路上下文不足）
- `prd.primary_persona` → **Retro** 的 persona 复盘锚点（设计假设的用户与实际用户是否一致）
- `prd.prd_file` → **Pitch** 的工程交付素材引用（汇报时引用 PRD 全文链接）

---

### 更新链路面板（必做，失败不阻断）

> **协议依据**：chain-protocol.md §九「面板自动生成约定」。本步在 Handoff 之前执行；**告知用户的提示必须作为独立段落输出，禁止折叠进 Handoff 末尾、禁止静默跳过**。

1. **找模板**：定位 `_shared/dashboard-template.html`（依次：相对套件根 → `glob dashboard-template.html` 搜套件安装目录 → 三轮都失败时，**用独立段落醒目告知用户**：`⚠️ 链路面板模板未找到（套件安装可能不完整，建议重装）。本 Skill 已正常完成，下游链路不受影响。` 然后跳过本步、继续 Handoff，**不阻断 Skill 完成**）。
2. **聚合 STATE**：扫 `spark-output/context/*.json`，聚合为 `{"project":"<brief.project_name 或 frame.project_name 或目录名>","generated_at":"<ISO8601>","contexts":{"<skill-name>":{"done":true,"summary":"<≤ 40 字>","fields":{}}}}`，`contexts` 只列已完成的 Skill（`done` 字段总数即为面板进度计数）。
3. **克隆模板**到 `spark-output/dashboard.html`（覆盖），用正则 `/\/\*__SPARK_STATE_INJECT__\*\/null/` 替换为 `/*__SPARK_STATE_INJECT__*/<JSON.stringify(STATE)>`。
4. **独立段落告知用户**（强提示，单独成段，与 Handoff 之间空一行；根据 `Object.keys(STATE.contexts).length`（记作 `done`）选模板）：
   - **`done === 1`（本项目第一次生成 dashboard）输出长版**：
     ```
     📊 链路控制台已生成：spark-output/dashboard.html（双击在浏览器打开）

     这是本套件给你的「设计全链进度看板」——5 个阶段 × 27 个 Skill 节点，亮起的代表已完成的步骤，灰色的是后续可调用的节点。每跑完一个 Skill 都会自动更新，建议钉在浏览器一个标签页里随时回看，能看清「现在在哪一步、下游还差什么、链路是否健康」。
     ```
   - **`done > 1`（后续更新）输出短版**：
     ```
     📊 链路面板已更新 · 进度 [done]/27 · spark-output/dashboard.html
     ```
5. **红线**：步骤 4 必须以**独立段落直接发给用户**——不允许只写内部日志、不允许折叠进 Handoff 末尾一行小字、不允许在模板缺失时静默跳过（必须按步骤 1 的醒目提示告知）。

## 三种激活模式

### A — 完整上下文（推荐）

读到 brief + stories + sitemap + flow-web 或 flow-mobile（至少 4 个 Skill 产出齐全）。

> "已读到完整上下文。8 段 PRD 全部章节都有强支撑，直接生成。"

进入 Step 2 直接生成。

### B — 部分上下文

只读到 stories（最低门槛）。

> "读到 stories 上下文，但缺少 [Brief / Sitemap / Flow]。我会基于 stories 生成 PRD，但 [Background / Solution 实现细节 / 风险] 等章节会偏薄。建议先回头补 Brief / Flow，或继续生成并接受薄弱章节。"

进入 Step 2，但在最终输出标注 thin_sections。

### C — Standalone（不推荐）

什么都没读到。

> "未读到任何上游 Skill 产出。PRD 需要至少 stories 作为输入。请粘贴 stories 内容，或先去跑 Stories Skill。"

要求用户提供 stories（粘贴或文件路径），否则不进入 Step 2。

---

## 触发条件

- 用户说"写个 PRD / 生成需求文档"
- 用户说"把这个交给工程师 / coding agent"、"handoff to engineering"
- 用户说"转 PRD / Stories 转 PRD"
- 用户使用 `/写PRD` 指令
- Stories 完成后，独立设计师准备交付工程实现时

---

---

## 独立能力（无需连接器）

本 Skill 在完全离线、无任何连接器的场景下即可完整交付，所有方法论与输出形态不依赖外部系统：

- **8 段式工程语言文档**：Background / Personas / Goals / Value Prop / Solution / Constraints / Acceptance / Rollout 完整模板
- **链式上下文双通道**：写入 `spark-output/context/prd.json` + 会话内 marker block，下游 QA / Retro 可直接读取
- **三种激活模式**：基于 Brief / 基于 Stories / 独立模式全本地完成
- **Acceptance Criteria 与 Stories AC 双向对齐**：避免需求 / 验收漂移

> 红线：缺连接器时 **绝不 abort**，所有引导与输出路径必须照常完成。

## 增强能力（连接器加持）

接入以下连接器后，可减少手动粘贴、提高对齐效率。所有连接器均为可选，未装时按"降级路径"列的方式回落。

| 连接器 | 阶段 | 增强能力 | 降级路径 |
| --- | --- | --- | --- |
| **Notion / 飞书文档** | 执行流程输出后 | PRD 一键写入团队 wiki 指定空间，工程师可直接阅读 | 未装时输出本地 `prd-{project}.md`，提示手动上传 |
| **Linear / Jira** | 执行流程输出后 | 一键把 PRD 的 Feature Scope 拆为 Epic + Story 创建到任务系统，自动关联 Brief / Stories 上游 ticket | 未装时输出 Story 列表 + 优先级，PM 手动建 issue |
| **Figma** | 执行流程（交互说明阶段） | 引用设计稿 frame 链接嵌入交互说明 / 状态规格，工程师可一键跳转 | 未装时仅文字描述交互，截图由设计师手动附 |

**接入触发**：用户首次调用 `/写PRD` 时，Skill 主动检测已认证的连接器并显示「已检测到：XXX，将自动启用增强模式」提示，用户可在该次会话中选择关闭。

**字段流向变化**：

- 启用 **Notion / 飞书文档** → `chain.schema` 新增可选字段 `wiki_page_url: string`
- 启用 **Linear / Jira** → `chain.schema` 新增可选字段 `epic_url: string` + `tickets: array<{story_id, ticket_url}>`
- 启用 **Figma** → `chain.schema` 新增可选字段 `design_refs: array<{feature_id, frame_url}>`

> 所有新增字段都是 **可选**，未启用连接器时字段缺省，下游 Skill 必须能容忍缺省。

---

## 执行流程

按 Step 0 → 1 → 2 → 3 → 4 顺序执行。

### Step 0 — Chain Context 读取

按上文执行。

### Step 1 — 缺口确认（仅当上下文不全）

用 `AskUserQuestion` 询问关键缺失字段：

1. 没有 brief → 问业务背景一句话 + 业务目标
2. 没有 frame → 问人物锚点（一句话）
3. 没有 sitemap → 问主要页面 / 路由清单
4. 没有 flow-web/mobile → 问"已有设计稿吗？提供截图或代码路径"

不强求填全，能薄就薄，最终 thin_sections 字段标注。

### Step 2 — 生成 8 段 PRD

按以下结构生成完整 Markdown 文档。**每段必有，深度按上下文调整**——上下文不够就薄，不要凭空编造。

---

#### Section 1 — Summary（一段话，60 秒读完）

一段散文（不要 bullet），覆盖 4 个要素：

- **做什么**（一句话）
- **给谁**（primary persona）
- **为什么是现在**（市场 / 业务原因）
- **成功长什么样**（一个可量化结果）

**写作约束**：如果 stakeholder 只看这一段就要理解整个项目押注，必须做到。

#### Section 2 — Background & Problem

- **问题**：从用户视角描述（用 frame.persona 或 brief.business_context 的措辞），**不要从产品视角**
- **当前 workaround**：用户今天怎么解决？为什么不够好？（来自 frame.persona.workaround）
- **为什么是现在**：市场 / 用户行为 / 竞品格局有什么变化？（来自 frame.business_angle.why_now）
- **不解决什么**：明确 1-2 个相邻问题本 PRD 故意排除（来自 brief.out_of_scope）

#### Section 3 — Personas & User Segments

**Primary persona** 完整版（用 frame.persona 或 stories.persona）：

```
姓名：[name]
身份：[description]
情境：[situation]
JTBD：当 [situation]，[name] 想 [motivation]，从而 [outcome]。
当前 workaround：[workaround]
痛点：[frustrations]
```

**Secondary persona**（如适用）：相同格式。常见于 B2B（买家 vs 使用者不同）。

**这个产品不为谁做**：一句话。防止"为所有人做"。

#### Section 4 — Goals & Success Metrics

- **产品目标**：一句话，**outcome-framed 不是 feature-framed**（来自 brief.business_goal）
- **成功度量表**：

```markdown
| 指标 | 度量什么用户行为 | 目标值 | 时间窗 |
| --- | --- | --- | --- |
| [primary] | ... | 具体数字 | 30/60/90 天 |
| [secondary] | ... | ... | ... |
| [health] | ... | ... | ... |
```

度量来源：brief.design_criteria.quantitative + brief.business_goal

- **Anti-metrics（反指标）**：**这是 SparkSkillsHub PRD 的特色之一**。明确不优化什么——例如"通知打开率"虽然好看但优化它会破坏信任。每个 PRD 至少列 1 个 anti-metric。
- **关键假设**：来自 frame.critical_assumption——一句话写出"如果错了就意味做错产品"的假设。

#### Section 5 — Value Proposition

**对主用户**：

> "[persona name] 终于可以 [JTBD] 而不必 [当前阻力]，因为 [本产品做了什么不一样的事]。"

**对 buyer**（如不同于 user）：相同模板。

**竞争差异化**：2-3 句。要具体，"更好的 UX" 不算差异化。来自 frame.competitive_landscape——明确**对手做对了什么、留下什么空白、本产品填的是哪个空白**。

#### Section 6 — Solution & Feature Scope（**最重要章节**）

> 这一段是 SparkSkillsHub PRD 跟传统 PM PRD 最大的不同——它**显式包含设计触点和已生成的设计资产引用**，让 coding agent 直接消费。

对 stories 中每个 Story（按 priority 降序），生成以下结构：

```markdown
### [Story 标题]

**Persona**：[story.persona]
**Job**：[story.scenario] → [JTBD 动机]
**优先级**：P0 / P1 / P2
**关键假设标记**：⭐（仅当 critical_assumption=true）

**功能描述**（2-3 句，从用户视角，平实语言）：
[基于 story.scenario 和 story 主体生成]

**In Scope（这版要做的）**：
- [基于 story.acceptance_criteria 转译]
- [...]

**Out of Scope（这版故意不做的）**：
- [基于 brief.out_of_scope + story.priority < p0 的部分]

**验收标准（Given / When / Then）**：
- Given [情境]，When [动作]，Then [可观察结果]
- Given [情境]，When [动作]，Then [可观察结果]
- 边缘情况：[X 出错时怎么办]
- 空状态：[没数据时用户看到什么]

**设计触点**（来自 story.design_touchpoints）：
- 涉及屏：[...]
- 涉及组件：[...]
- 涉及状态：[...]

**关联 Sitemap 页面**（来自 sitemap.pages）：
- [page.id]: [page.route] — [page.label]

**已生成的设计资产**（来自 flow-web.output_files / flow-mobile.output_files）：
- `src/app/(retro)/new/page.tsx` — Three Questions 屏
- `src/components/retro/WeekStreak.tsx` — 连续打卡组件
（如果上游有 flow 输出则列出，没有则标注"待生成"）

**待澄清问题**：
- [story 阶段未解决的决策项]
```

**关键规则**：
- 每个 Story 一节，按 priority 降序（P0 在前）
- 没有上游 flow 时"已生成的设计资产"标注为"待生成"，提示工程师走 vibe coding 流程
- 已生成的设计资产**必须列具体文件路径**，不要写"在 src/app 下"这种模糊描述

最后单独列一个"未列入本版的 Stories"小节，列 P2 或低优先级 Story 的标题，备 Phase 2 引用。

#### Section 7 — Constraints & Risks

- **技术约束**：来自 brief.constraints。例如"4 周交付"、"Web 优先"、"必须用 SparkDesign"
- **设计约束**：UX pattern / 无障碍要求等不可妥协项。来自 brief.design_criteria.qualitative
- **数据 & 隐私**：本 PRD 涉及哪些个人数据？合规考虑（GDPR / CCPA / 国内法规）？
- **关键风险表**：

```markdown
| 风险 | 可能性 | 影响 | 缓解措施 |
| --- | --- | --- | --- |
| [关键假设错] | High | High | [最便宜的测试，来自 frame.critical_assumption + 关联条件] |
| [技术依赖失败] | M | M | [fallback 方案] |
| [用户不接受] | M | H | [灰度 / 测试方案] |
```

**特别引用**：如果上游有 check.findings，把其中的 blocker / major 项列入 risks 表（"已识别但未修复的设计问题"）。

#### Section 8 — Release Approach

- **推荐顺序**：哪个 Story 先发，为什么？**优先发关键假设测试 Story**（来自 frame.critical_assumption + stories.critical_assumption=true 的 Story）
- **MVP 定义**：最小 Story 集合，能交付足够价值且能验证核心假设。**显式列 Story 标题**
- **Phase 2**（如适用）：故意延后到第二版的内容，为什么
- **上线考虑**：
  - 上线前需要通知谁？（stakeholders / 客服 / 法务）
  - 是否 soft launch / beta 降风险？
  - 上线后头 2 周监测什么？

---

### Step 3 — 自检与 thin_sections 标注

PRD 生成完后，对每段做"完整度自检"：

| 段落 | 完整 | 中等 | 薄 |
| --- | --- | --- | --- |
| Summary | 4 要素全有 | 3 要素 | <3 要素 |
| Background | 4 子段全有 | 缺 1 段 | 缺 ≥2 段 |
| Personas | primary 完整 + 谁不为 | primary 缺细节 | 仅一句话 |
| Goals | 3 度量 + anti-metric + assumption | 缺 anti-metric | 仅 1 度量 |
| Value Prop | 用户 + buyer + 差异化 | 缺 buyer | 仅模板未填 |
| Solution | 每个 Story 有完整 GWT + 设计触点 | 缺设计触点 | 仅功能描述 |
| Constraints | 4 子段 + 风险表 | 缺 1 段 | 仅约束无风险 |
| Release | 顺序 + MVP + Phase 2 + 上线 | 缺 1 项 | 仅 MVP 列表 |

任何一段评级"薄"的，记入 thin_sections，在 PRD 末尾标注。

### Step 4 — 输出（保存文件 + 双通道 Context）

#### 4.1 保存 Markdown PRD

文件路径：`spark-output/prd/[direction-slug].md`

`direction-slug` 来源（按优先级）：
1. frame.lean_direction 的 slug 化
2. brief.project_name 的 slug 化
3. 用户提供

**完整 PRD Markdown 文件结构**：

```markdown
# PRD — [项目名] / [direction]

- **生成时间**：[ISO8601]
- **数据源**：[brief / stories / sitemap / flow-web / ...] [N] 个上游 Skill
- **完整度**：strong / moderate / thin

[Section 1 - Summary]

---

## Background & Problem

[Section 2]

---

## Personas

[Section 3]

---

## Goals & Success Metrics

[Section 4]

---

## Value Proposition

[Section 5]

---

## Solution & Feature Scope

[Section 6 — 每个 Story 一段]

---

## Constraints & Risks

[Section 7]

---

## Release Approach

[Section 8]

---

> ⚠️ **薄弱章节提示**（如有）：
> [thin_sections 中每条说明缺什么、建议怎么补]
```

#### 4.2 双通道 Context 输出

按 [chain-protocol.md](../../chain-protocol.md) 第 2.1 节执行。

**Step 1 — 写盘到 `spark-output/context/prd.json`**（必做，主持久化通道；**仅含元数据 + 章节摘要，不含 PRD 全文**——PRD 全文在 `spark-output/prd/[slug].md`）。写入以下完整 JSON：

```
{
  "skill": "prd",
  "generated_at": "<ISO8601>",
  "project_name": "...",
  "direction": "...",
  "prd_file": "spark-output/prd/[direction-slug].md",
  "sections_summary": {
    "summary": "<Section 1 一句话>",
    "primary_persona": "<persona name>",
    "product_goal": "<one sentence>",
    "success_metrics": [
      { "metric": "...", "target": "...", "timeframe": "..." }
    ],
    "feature_count": 0,
    "in_scope_features": ["..."],
    "out_of_scope_features": ["..."],
    "critical_assumption": "...",
    "mvp_stories": ["..."]
  },
  "source_skills": {
    "brief": true,
    "stories": true,
    "sitemap": false,
    "flow_web": true,
    "flow_mobile": false,
    "frame": true,
    "scope": false,
    "check": false
  },
  "thin_sections": ["release_approach"]
}
```

**Step 2 — chat 输出紧凑 marker**（必做，⛔ **不要在 chat 内重复输出 Step 1 的完整 JSON**）：

```
<!-- spark-context:prd ref="spark-output/context/prd.json" -->
PRD 已保存：project=[project_name]，direction=[direction]，[N] 个 Story / MVP=[mvp_stories]，prd_file=spark-output/prd/[slug].md
<!-- /spark-context:prd -->
```

**降级 fallback**：若 Step 1 写盘失败（chat-only 平台），输出完整 JSON marker（无 ref 属性，marker 之间放裸 JSON）作为唯一持久化通道。

#### Handoff 提示（必输出）

> **协议**：按 [`_shared/next-skill.md`](../../_shared/next-skill.md) 三层结构模板输出；前 5 候选由 `_shared/skill-graph.json` 的依赖图算法实时算（done ⊆ ready，按 next_hint.preferred → alternatives → 同阶段 → anchor → fan-out 排序），优先建议从 `_shared/skill-graph.json#skills[id="prd"].next_hint` 读取。

**首行模板**：`✅ 写PRD 已完成，8 段工程交付文档 + 先发 Story 推荐已就绪，已保存到 `spark-output/prd/[slug].md`。`

**本 Skill 的 `next_hint`**（来自 skill-graph.json，**不可在此 SKILL.md 内硬编码覆盖**）：

- **preferred**：`/extract`
- **优先理由**：PRD 已交付工程，进 Extract 把设计 token 抽出来给工程实现侧消费，让代码与设计稿对齐。
- **alternatives**：`/qa` (等工程实现后做还原度验收) · `/metric` (PRD Section 4 想用 Metric 蓝图替代 Brief 简版)
- **emoji**：📄

**红线**：
- ❌ 禁止在本段硬编码候选清单（如「进入 Stories / Journey / Sitemap」）——所有候选必须由算法实时生成
- ❌ 禁止按「文档类 / 视觉类 / 决策类」再分类候选（v0.5.5 起，分类已折叠进 next_hint.alternatives）
- ❌ 禁止与「更新链路面板」段合并——两段必须各自独立成段，中间空一行
- ❌ 禁止漏第 2 行候选清单——即使候选只有 1 个、或为空（终端节点）也要写出来

---

## 实操注意事项

### 不要做的事

- ❌ **不要再做研究**：PRD 生成阶段，所有用户研究 / 竞品分析 / 商业判断都应该已经在上游 Skill 完成。PRD 是**整合**不是**创造**
- ❌ **不要凭空补字段**：上游缺什么就标 thin，不要为了"PRD 看起来完整"自己编
- ❌ **不要写 PM 视角的论证**：PRD 不需要"为什么我们应该做"的长篇论证，那是 Frame / Brief 的事
- ❌ **不要遗漏 design_touchpoints**：Solution 章节的核心差异化就是设计触点，漏了 PRD 就退化为普通 PM PRD

### 最适合的使用场景

- **独立设计师**：自己设计完，没 PM，要交付工程
- **AI 原生设计师**：vibe coding 后把设计产出转 PRD 给 coding agent 系统化实现
- **团队设计师**（少见）：补充 PM 没写到的设计相关 PRD section（一般直接合并到 PM 的 PRD）

### 非最佳场景

- 项目还在方向探索阶段（用 Frame）
- PRD 已存在且要解读（用 Scope）
- 要评估设计稿完整度（用 Check）

---

## 已知限制

- PRD 质量上限取决于上游 context 的完整度，"垃圾进垃圾出"
- 不能替工程师做技术选型 / 架构决策
- 不能替 PM 做商业模型论证（如 unit economics / go-to-market）
- 大型多 Squad 项目可能需要拆多个 PRD（按 Squad 拆 stories 集合分别生成）

---

## 与兄弟 Skill / PM 套件的边界（v0.4.0 补充）

| 场景 | 用谁 | 不用谁 |
| --- | --- | --- |
| 设计完成后给工程师 / coding agent 的 PRD | **PRD** | Scope（PRD 入口拆解）/ Pitch（决策汇报） |
| 从 PRD 拆解设计目标 | Scope | PRD（Scope 是入口，PRD 是出口） |
| 给决策者汇报推动批准 | Pitch | PRD（PRD 是工程语言，不是决策语言） |
| PM 套件「PRD 生成」 | PM 套件（**PM 视角 PRD**：商业 / 优先级 / 路线图） | PRD（**设计师视角 PRD**：设计资产路径 / 交互细节 / 验收标准 / 埋点字段） |
| 设计稿走查 / 验收 | Check / QA | PRD（PRD 不做 review） |
| 用户故事拆解 | Stories | PRD（PRD 吸收 Stories 但不替代故事拆解） |

**PRD 不可替代性**：设计师视角的工程交付 PRD，重点是「设计资产路径（.tsx / Figma）+ 交互细节 + 验收标准 + 埋点字段」，与 PM 套件 PRD 互补——PM 写「为什么做 + 业务价值」，设计师 PRD 写「设计怎么落 + 工程怎么做」。

## 质量标准

1. **8 段结构完整**：1 概要 / 2 用户故事 / 3 信息架构 / 4 页面 Flow / 5 交互细节 / 6 设计资产 + 埋点 / 7 验收标准 / 8 异常态——8 段一段不少
2. **Section 6 必含 .tsx 路径**：设计资产段必须含具体代码文件路径 + Figma 链接，不能只说「见设计稿」
3. **上游 chain 强制消费**：必须读取 brief + frame + scope + stories + sitemap + journey + flow-web + flow-mobile + check 九个上游（缺则在文档头部标 ⚠️）
4. **验收标准 ≥ stories 数量 × 2**：每个 story 至少对应 2 条工程可验收标准（功能 / 视觉 / 交互）
5. **埋点字段对齐 Metric**：Section 6 埋点列表必须与 Metric.events 一一对应，event_name / 字段一致
6. **行数 ≥ 500**：完整 PRD（含 8 段 + 表格 + 资产路径）应 ≥ 500 行，过短即视为漏内容

## 红线规则

1. **不替代 PM PRD**：设计师 PRD 不写「为什么做这个产品 / 商业价值 / 优先级排序」——那是 PM 套件的范围
2. **不省略异常态**：Section 8 必须覆盖来自 Edge 的异常态清单，不能只写 happy path——红线场景：上线后客服爆「错误页没设计」
3. **不脱离上游 stories / brief**：PRD 出现的新功能 / 新交互必须能追溯到 stories 或 brief，凭空加内容 = 红线