---
name: requirements2prd
displayName: 粗需求到PRD
description: 从粗需求到可执行 PRD 的方法论,同样覆盖既有模块的优化/重构与产品化。触发场景:① 用户给一句话粗需求(如"做一个 X 模块")需要梳理成 PRD;② 讨论"产品需求文档 / 产品方案 / 新模块设计 / PRD 草稿";③ 讨论或推进既有模块的优化、重构、通用性/标准化提升,或把"项目拼凑 / 缝合怪"的功能产品化、抽象产品本质、还历史债务——即使用户只说"讨论 / 梳理"而没说"做 PRD"也应触发。④ 用户用口语开场("我们来聊个新需求 / 聊个需求 / 看个需求 / 这块想优化下")并伴随给出需求材料时,也应在第一时间建议本 skill,不要当成普通对话裸推进。关键词:聊需求、聊个需求、聊个新需求、聊新需求、新需求、看个需求、捋需求、粗需求、做 PRD、产品方案、新模块、需求拆解、产品需求文档、requirements、PRD、五看三定、降本增效、产品价值、优化、重构、产品化、通用性、标准化、缝合怪、项目拼凑、模块优化、历史债务、产品本质、抽象、第一性原理。适用 B 端工具型产品、工作流类/治理类/监控类模块、以及历史模块的优化重构。
---

# 粗需求 → 可执行 PRD 的方法论

> 来自一个真实 B 端项目的复盘沉淀。检查清单经过实战验证。

---

## 何时该启用本 skill

**典型触发场景**:
- 用户丢过来一个粗略需求("做一个 X 模块"、"把 Y 功能加进 Z 系统")
- 需求里只有 What,缺 Why / Who / How / When
- 需要把模糊概念变成数据模型 + 状态机 + 视图 + 范围划分
- 对**既有模块做优化 / 还历史债务** —— 本 skill 也有专门子框架(见后)

**不适用**:
- 单纯界面级修改(直接进姐妹 skill `prd2prototype`)
- 没有数据/状态/工作流的轻量功能(配置项、文案修改、单个 widget)

---

## 心法

**粗需求的本质**:一个模糊的目标 + 一堆隐含的约束 + 没说出口的工作流。
**PRD 的本质**:让模糊变清晰、让隐含变明确、让工作流变可拆解。

不是把粗需求"翻译"成 PRD,而是**主动探索这个问题的全貌**,直到团队能据此估时、能拆 sprint、能开始动手写代码。

---

## 工作纪律(关键 · 全程贯穿)

### 纪律一:挨个过确认点,不能跳

本 skill 的所有"关键判断点"(0 号问题、5W 拆解、约束清单、数据模型、状态机、视图维度、MVP 范围、挂起话题),**逐项用 `AskUserQuestion` 工具明确确认**,不要默默推进。

- 不许"我以为你就是想要 X,所以接着做了"
- 不许"这个点我自己判断了一下,后面再说"
- **每个判断点都要明确"我们达成了什么共识"**,落到文档里

判断"是否需要确认":如果你内心 P(对) > 80% 还有疑问,或者用户没给过明确表态 → 必须 AskUserQuestion。

### 纪律二:苏格拉底式引导,不要被动接受

团队里很多产品经理(和你对面的人)可能没受过系统的产品思维训练。**你要主动用问题引导用户深入思考**,而不是有问必答、有需求必做。

**对面给一句话粗需求时,不要立刻开始拆 5W,先问:**

- "如果不做这个,会发生什么?谁会受影响?"
- "现在他们怎么解决这个问题的?手动也好、临时方案也好?"
- "这个需求是谁提出的?他真正想要解决的事是什么?"
- "类似的问题别人(竞品、行业、隔壁团队)是怎么处理的?"
- "如果我们的方案上线后,你怎么判断它有没有真正解决问题?"

**为什么这样**:很多需求看起来是"做 X",其实背后是"治 Y"。直接做 X 会做出一个又对又错的东西 —— 功能上线了,问题没解决。先用问题把"真正的问题"挤出来。

引导成功的标志:对面会说"诶,我之前没想过这个" / "这么一问,可能需求不是这样" / "我得回去再确认一下"。**这是高质量的引导**。

---

## 前置判断:需求规模定级(必做 · 进任何流程前先走这一步)

**收到粗需求的第一件事,不是问商业三问,而是先判断这是哪类需求。**

### 两类需求的特征

| 类型 | 特征 | 典型例子 |
|---|---|---|
| **大模块 / 新产品** | 涉及多个页面、有独立数据模型 / 状态机、跨角色工作流、需要单独立项 | "做一个 X 治理模块"、"新增 Y 管理系统"、"重构 Z 整个模块" |
| **具体功能 / 页面级** | 在现有模块内增改、单一页面或单一操作、数据模型无需新建 | "在 X 列表加一列"、"Y 页面加个导出按钮"、"Z 表单增加一个字段" |

### 判断动作

用 `AskUserQuestion` 工具明确问产品经理:

> "这个需求是要做一个相对独立的大模块 / 新产品,还是在现有功能上做具体的页面级改动?"

**如果对面说不确定,给两个判断标准帮他选**:
- "这个需求上线后,会新增菜单 / 独立入口吗?" → 是 → 大模块
- "这个需求只影响某一个页面内的局部功能吗?" → 是 → 具体功能

### 两条路径

**路径 A:大模块 / 新产品**
→ 走完整流程:商业本质三问 → 五看三定 → 七步法(下面的完整内容全部适用)

**路径 B:具体功能 / 页面级**
→ 跳过商业三问和五看三定,直接做需求细化:
1. 用 5W 把功能描述清楚(What / Who / How / When,Why 简答即可)
2. 确认边界(改哪个页面?改哪个组件?不改什么?)
3. 确认约束(现有数据够用吗?接口有现成的吗?影响哪些上下游?)
4. 明确验收标准(什么叫"做完了"?怎么测?)
5. 挂起话题(有没有顺手发现的其他问题?先记下来)

路径 B 不需要走完整七步法,**目标是 1~2 轮对话内把需求钉清楚,直接进原型或开发**。

---

## 0 号问题:商业本质三问(路径 A 必答 · 路径 B 跳过)

**大模块 / 新产品需求,先回答这三个问题。三个都不沾边 → 该需求可能不该做。**

| 维度 | 含义 | 怎么判断 |
|---|---|---|
| **降本** | 减少人力 / 时间 / 物料 / 故障带来的损失 | 量化:节省多少人天?故障率下降多少?物料省多少? |
| **增效** | 同样的人 / 时间产出更多;或质量提升 | 量化:处理量提升多少?周期缩短多少?准确率提升多少? |
| **合规** | 满足法规、行业标准、客户合同、监管要求 | 明确:对应哪一条?不做的后果是什么?(罚款 / 失资质 / 监管处罚) |

**强制流程**:

1. 收到粗需求 → 立刻让对面回答"这个需求是降本、增效、还是合规?"
2. 如果对面说"都是" → 让他**排个优先级**,主因和副因
3. 如果对面说"都不是,但领导想要" / "竞品有我们也要" → **停下来讨论这个需求的意义**
   - 探索性 / 战略性需求是允许的,但必须承认它没有直接商业回报
   - 不要在没认清商业本质的情况下投入正式开发资源
4. 把答案写进 PRD 的"背景 / 价值"章节,作为第一条

### 三类的写法范例

- **降本类**:"目前 X 类问题每年浪费 N 人天 / Y 故障次数,本模块预计降低 Z%"
- **增效类**:"目前 Y 流程平均耗时 N 分钟,本模块可缩短到 M 分钟,日单量提升 K%"
- **合规类**:"对应《XX 规范》第 N 条要求 / 客户合同 SLA 第 M 款,不做将面临 …"

---

## 战略视角:五看三定

(改编自经典战略管理框架,B 端模块级别裁剪版)

### 五看

| 看什么 | 问什么 |
|---|---|
| **看用户** | 谁会用?日常 / 周期 / 应急三态怎么走?用户的工具习惯是什么? |
| **看现状** | 现在他们怎么解决?手动 / 临时脚本 / 老系统?痛在哪里? |
| **看法规** | 行业规范、客户合同、监管条例对这块有什么硬约束? |
| **看竞品** | 同类工具(同行 / 友商 / 开源项目)怎么做?他们的形态值得借鉴吗? |
| **看自己** | 我们的优势 / 约束是什么?现有系统能复用什么?跨模块依赖在哪? |

**踩坑警示**:不看用户现状就动手 → 做出来的方案要么不解决真问题,要么解决了但用户不会用。

### 三定

| 定什么 | 内容 |
|---|---|
| **定目标** | 这个模块要达成的可量化指标(对应 0 号问题里的降本 / 增效 / 合规) |
| **定边界** | 不做什么(防止 scope creep)。挂起话题清单作为正式产物 |
| **定打法** | MVP 范围 + 上线节奏 + 灰度策略(对应下面的七步法 + PDCA) |

---

## 发散工具箱(按需取用 · 发散补强)

> 来源:`product-management:product-brainstorming` 的方法论,裁掉与本 skill 重叠/不适用的部分,只留 4 个真正补强的。挂到七步法的对应步骤上用。

### 为什么有这一节

本 skill 主体是**收敛型**流水线:把模糊需求 → 清晰 → 可拆解。它的盲区是——**太会"问清已知需求",不太会"挑战需求本身 / 逼出多方案"**。结果就是常犯的「错 1:接活式做产品」「错 6:第一个方案就定了」。

这一节补的是**发散**。但有一条铁律(来自 brainstorming skill 自己的纪律):

> **不要堆框架(Do not dump frameworks)。** 下面 4 个是"按需取用的镜头",不是必填清单。每个都标了"何时用 / 何时别用"。不相关就不用。

### 工具 1:反向法 —— 当"约束 & 校验规则生成器"

**挂到**:第 2 步「探索约束」。

**怎么用**:不去正面问"要满足什么约束",而是反过来问——

> "怎样能让这个 [功能] 出错 / 算错 / 漏掉 / 被绕过?"

把每条"做砸的路径"列出来,**反过来就是一条校验规则或约束**。

**为什么对 B 端流程类需求杠杆高**:治理/审批/分配类需求,正面问约束容易漏;反向问"怎么搞砸"反而能逼出边界条件。人天生更擅长找茬,不擅长凭空想周全。

**实战案例(某"从资源池分配唯一资源"的功能)**:
- "怎么让分配出错 / 资源冲突?" → 已释放的资源没回收进池 / 并发申请抢到同一个空闲资源 / 手动改过分配结果后没做唯一性校验
- 三条反过来 → 三条分配规则:释放即回收、分配时加锁、手动改也必须过唯一性校验

**何时别用**:需求本身还没定形(连"做什么"都没共识)时别用——反向法是给"已知要做什么、要找边界"的场景用的。

### 工具 2:强制多方案 —— 关键岔路口 ≥3 方案再选

**挂到**:任何"设计岔路口"(入口放哪、数据放哪层、字段归属…)。

**怎么用**:遇到岔路,**先列至少 3 个方案 + 一张权衡表(各自的代价/收益),再用 `AskUserQuestion` 让用户选**。强制要求:其中至少一个是"做减法/反着来"的方案。

**防的是**:本 skill「错 6」——第一个还行的方案就拍板了。多方案不是为了选最多的,是为了**让"为什么不是另外两个"也被想过一遍**。

**实战案例(某"配置项放哪一层"的岔路)**:
- 方案 A:只放使用现场,每个实例单独配(简单,但通用性为零)
- 方案 B:只放全局模板层,统一标准(最通用,但现场一破例就失效)
- 方案 C:模板 + 覆盖(全局放默认模板,现场允许本实例 override 且不回写模板)
- → 摆出三个才看得出 C 是兼顾解;只盯 A/B 会陷入二选一。

**何时别用**:只有一条明显正确路径、或纯执行细节(按钮文案、字段顺序)——别为凑数硬造方案。

### 工具 3:假设测试 —— 最危险假设 + 最便宜验证

**挂到**:第 2 步「探索约束」之后。

**怎么用**:
1. 列出需求**依赖的所有假设**(说出口的 + 没说出口的)
2. 标出**最危险的那个**——错了就全盘崩的
3. 想**最便宜的验证方式**(常常就是"调一页真实数据看看")

**为什么 B 端必做**:B 端最危险的假设往往是"**现场数据是干净的 / 两个实体是 1:1 映射的 / 所有客户都一样**"。这类假设错了,整个数据模型重来。

**实战案例**:某需求里"A 与 B 是 1:1 映射"这个假设,翻一页真实业务数据(发现其实是一对多、还混着脏数据)就被证伪了——验证成本 1 分钟,省下的是整个数据模型返工。**先验证最危险假设,再投设计**。

**何时别用**:假设已经被现场数据或既有系统证实过,别为流程而流程地再走一遍。

### 工具 4:给七步法前面开个"发散口"

**挂到**:「需求规模定级」之后、进「七步法」之前。

**怎么用**:**仅大模块/路径 A 场景**,在钻进收敛流水线前,插一个轻量发散环节:
- 用 1~2 个 **HMW(How Might We)** 把痛点**重述成机会问题**("怎样能让 X 用户在 Y 约束下达成 Z"),避免一上来就把需求做窄
- 用一轮**反向法**先扫一遍约束

**为什么**:纯收敛流水线最大的风险是"**过早把需求框死**"——5W 拆得很细,但拆的是一个本就偏窄的需求。先发散一下,确认在解对的问题,再收敛。

**何时别用**:路径 B(具体功能/页面级)别用——那种需求目标就是 1~2 轮钉清楚,加发散反而拖慢。

### 一句话总表(何时别用,优先记这个)

| 工具 | 用在 | 别用于 |
|---|---|---|
| 反向法 | 找约束/校验规则 | 需求还没定形 |
| 强制多方案 | 设计岔路口 | 只有一条对的路 / 纯执行细节 |
| 假设测试 | 投设计前验最危险假设 | 假设已被证实 |
| 发散口(HMW+反向) | 大模块进七步法前 | 路径 B 具体功能 |

> 核心纪律重申:**这是工具箱,不是检查清单**。一次对话用 0~2 个就够,别四个全上。

---

## 七步法(主线工作流)

### 第 1 步:粗需求拆解 5W

把粗需求拆成 5 个维度。**任何回答不上来的就是要主动追问的**。

| 维度 | 问什么 | 典型答错 vs 答对 |
|---|---|---|
| **What** | 这个东西具体是什么?有边界吗? | ❌"做 X 治理" / ✅"周期性对比 A 状态和合规基线,识别偏差项" |
| **Why** | 为什么现在要做?(对应 0 号问题三类之一) | ❌"用户方便" / ✅"合规要求 / 节省 N 人天 / 提升 Y%" |
| **Who** | 用谁的视角?日常操作员 / 主管 / 审计 / 监管? | ❌"用户" / ✅"操作员(P0)、主管(P1)、审计(P2)" |
| **How** | 用户怎么用?日常 / 周期 / 应急三态? | ❌"看一眼" / ✅"日常进列表看待办,周期出报告,应急时溯源" |
| **When** | 什么时候触发?手动 / 定时 / 联动? | ❌"想看就看" / ✅"跟随上游事件触发、定时跑、即时验证" |

**踩坑案例**:某项目最初没拆 Who,做出来后才发现"日常操作员"和"审计"想看的东西完全不同 —— 操作员要待办,审计要治理报告。后来才补出多视图。

### 第 2 步:探索约束

粗需求背后,**约束往往比目标更重要**。要主动问的几类:

1. **行业规范 / 法规**(对应行业的安全合规、等保、监管条例)
2. **现有系统的边界**(不能改 X、必须复用 Y、跟 Z 联动)
3. **目标用户的工具习惯**(用什么桌面工具、命令行、Excel、纸质报告)
4. **客户的"政治"约束**(领导要看到的 KPI、监管要看到的报告)

**踩坑案例**:某项目曾把"批量操作"做成了云厂商风格的"提交审批表单后等待",被纠正:**目标用户要的是桌面工具风格的直接操作(看着每台机器的输出),不是黑盒等待**。教训是没问"目标用户现在用什么工具做这事",就抄了云厂商。

### 第 3 步:第一性原理建数据模型

**先于界面**,把数据模型想清楚。

**关键判断**:
- 哪些是"稳定身份"?(在系统里有持续生命周期、跨多个事件保持同一性)
- 哪些是"时间快照"?(某个时间点的事实记录)

**示例(通用形态)**:
- **问题层** = 稳定身份:(主体, 维度) 组合,有自己的状态机,跨多次事件保持同一性
- **快照层** = 时间快照:每次执行 / 每个时间点的当时事实,只为审计追溯保留
- 多个快照引用同一个问题。状态变化(完成 / 失败 / 漂移 / 忽略)发生在问题层

**为什么重要**:状态机、视图、操作权限,全都建在"问题层"这个抽象上。

### 第 4 步:状态机定义

凡是涉及"对象有生命周期"的设计,**用状态机表达**。列所有状态、迁移、迁移触发条件、每个状态的可做操作,区分"持久状态"和"临时标签"。

### 第 5 步:视图分层 / 维度去重

PRD 里通常要做多视图。**逼自己问每个视图独立回答什么用户问题**。

- 如果两个视图回答的是同一个问题,只是数据维度不同 → **删掉其中一个**或重新定义
- 视图维度要"正交":按时间 / 按对象 / 按事件,不要交叉重复

**踩坑案例**:某项目最初把"按 X 聚合"做成了"按 X × Y 聚合",其实只是把"按 X 聚合"展开了一层。后来重做成真正按 X 聚合才有独立的视角。

### 第 6 步:PDCA 闭环 + MVP 范围

把功能放进 P(规划) / D(执行) / C(检查) / A(改进)四个象限,**明确 MVP 做哪几个**。

- MVP1:通常做 P + D + C + 部分 A(轻动作)
- 重 A 动作(自动下发、自动回滚)涉及变更审批、影响范围评估、审计追溯 —— **工程量是 5 倍,留到下一版**

### 第 7 步:挂起话题作为正式产物

遇到的疑难、跨模块依赖、不在本次范围内但浮现出来的话题,**全部记到「挂起话题-待讨论.md」**。每条挂起项要带"预期讨论时机"。

---

## 历史债务 / 模块优化 子框架(适配重构场景)

如果触发本 skill 的不是"新模块",而是**对既有模块的优化 / 还历史债务**,在七步法之前先走以下子框架:

### 0. 商业本质三问(同样必答)
- 这次优化降本?增效?合规?
- 没有可量化收益的"为优化而优化",慎做。技术债务的真正成本是 ongoing 维护人力,要量化它

### 1. 现状盘点

| 维度 | 问什么 |
|---|---|
| 用户痛点清单 | 现在用户最骂的、最绕过的、最易出错的环节是什么? |
| 技术债清单 | 哪些代码 / 设计 / 数据模型已经撑不住了?未来 N 个月会更糟吗? |
| 数据现状 | 现有数据有多少?有多少历史"脏数据"? |
| 上下游依赖 | 谁依赖这个模块?改动会影响谁? |

### 2. 痛点优先级排序(双因素矩阵)

| | 影响人多 | 影响人少 |
|---|---|---|
| **频率高** | 🔴 优先解决(高 ROI) | 🟡 第二优先 |
| **频率低** | 🟡 第二优先 | ⚫ 暂缓(可忽略) |

把痛点贴到象限里,**只做 🔴 区,其它挂起**。

### 3. 目标态描述

把"理想中的样子"写出来,作为锚点。注意:
- 目标态要可达(不是技术幻想)
- 目标态要可衡量("用户操作步骤从 N 步减到 M 步")
- 目标态要有明确的"和现状的差距"

### 4. 改造路径选择

| 路径 | 适用 | 风险 |
|---|---|---|
| **渐进改造**(原地补丁) | 痛点局部、上下游耦合多、不允许停机 | 周期长,过渡期内"新旧并存"复杂 |
| **平行重构**(新建一套,逐步切量) | 痛点系统性、技术债深、可灰度 | 双重维护成本、数据迁移风险 |
| **整体重构**(推倒重来) | 影响面有限、可以接受停机 | 慎用,通常代价高于预期 |

**默认推荐渐进改造**,除非有明确证据支持平行重构。

### 5. 兼容性与数据迁移

- **接口兼容性**:旧接口什么时候废弃?有过渡期吗?
- **数据兼容性**:旧数据怎么迁?要不要保留只读?
- **用户行为兼容性**:用户老的操作习惯还能用吗?需要培训?
- **灰度策略**:按用户 / 按部门 / 按区域 / 按时间窗?回滚机制?

### 6. 把"已废弃"写进文档

历史债务的清理,要在 PRD 里**显式声明"什么被废弃了"** —— 这是给团队和接班人的承诺。

---

## 检查清单(逐项确认 · 不许跳)

> 用法:对面给完粗需求后,**逐条问**对面:"X 这点我们能不能现在就确认?"。**不能跳过,不能默默推进**。

### A. 商业本质(0 号问题)
- [ ] 降本 / 增效 / 合规三类中,主因明确 + 已量化
- [ ] 如果都不沾边,已讨论过"为什么还要做" + 风险告知

### B. 五看三定
- [ ] 五看每项都有明确回答(用户 / 现状 / 法规 / 竞品 / 自己)
- [ ] 三定都明确(目标 / 边界 / 打法)

### C. 范围与目标(5W)
- [ ] What / Why / Who / How / When 五项都有清晰答案
- [ ] 行业法规 / 客户合同里的硬约束都列出来了
- [ ] 已确认目标用户现在用什么工具做这事,新设计有对标过

### D. 数据模型
- [ ] 区分了"稳定身份"和"时间快照"
- [ ] 状态机的所有迁移路径都画了(图或表)
- [ ] 名词术语有中英对照表

### E. 视图与场景
- [ ] 每个视图能独立回答一个用户问题,不和其他视图重复
- [ ] 详情页 / 列表页的下钻关系是闭环的

### F. 范围划分
- [ ] PDCA 表清楚标了"本版做 / 不做 / 下版"
- [ ] 重 A 动作的工程门槛和审批链路评估过

### G. 历史债务(仅优化场景)
- [ ] 现状盘点完成(用户痛点 / 技术债 / 数据 / 依赖)
- [ ] 痛点优先级矩阵画完
- [ ] 改造路径已选(渐进 / 平行 / 整体)+ 兼容策略
- [ ] 废弃声明已写

### H. 挂起话题
- [ ] 所有"暂不讨论的点"都写到挂起话题清单
- [ ] 每条挂起项有"预期讨论时机"

### I. 输出格式
- [ ] PRD 用 .md 格式(docx 表格 / 字符画常崩),除非有强制要求

---

## 常犯的错(避坑)

### 错 1:被动接受需求,没引导
对面说做 X 就做 X,不问 Why 不问背景。**这种"接活式"做产品 = 给开发挖坑**。

### 错 2:跳过商业本质三问
"反正都是任务,做就行了" → 后期 ROI 不明,KPI 算不清,可能整个模块没人用。**三问必答**。

### 错 3:把"翻译需求"当 PRD
拿着需求文档逐句翻译成 PRD,没有探索约束、没有建模、没有视图设计。

### 错 4:跳过数据模型直接画界面
最终会发现界面之间的下钻 / 状态变化 / 关联全乱套。**数据模型是 PRD 的脊柱**。

### 错 5:多视图设计时维度重复
画了三个视图,其实只是同一份数据的三种 fold 状态。

### 错 6:把所有能想到的功能都塞进 MVP1
做减法是 PRD 的核心动作。

### 错 7:挂起话题口头说说,没落档
半年后再讨论,完全不记得当时为什么挂起。**必须落到文档**。

### 错 8:重构场景里"为优化而优化"
没有量化收益的优化等于在烧资源 + 制造新债。

### 错 9:确认点跳过
"我以为对面就是这个意思,后面再说" —— 错。**逐项 AskUserQuestion 明确确认**。

---

## PRD 文档结构标准(强制规范)

> 本节是 PRD 输出的硬约束。原型完成、走过几轮评审后,PRD 主体应符合下面的结构。**写初稿时也按这个骨架预留,不要事后再大改**。

### 一、主体一级目录(只放"任何产品 PRD 都该有"的通用骨架)

主体一级目录控制在 **5~6 章** 之内,各章节顺序固定:

1. **产品背景与目标**(业务背景 / 业务目标 / 产品定位与价值主张)
2. **用户角色与场景**(利益相关者拆解 / 核心用户场景)
3. **核心痛点与价值主张**(痛点清单 + 对应价值)
4. **产品范围**(MVP1,**按菜单维度展开功能项**,而不是按功能领域罗列)
5. **信息架构**(菜单结构 / 跨模块联动)
6. **版本规划与功能取舍**(合并"MVP1 不做" + "未来规划",每条明确 MVP1/2/3/4 归属)

**为什么是 5~6 章**:任何产品 PRD 都该有这套骨架,跨模块跨产品线复用。**模块特有的设计机制不放主体**,放附录。

### 二、附录(模块特有的设计机制)

模块特有的"设计机制"章节(PDCA 闭环 / 状态机 / DSL / 视图分层 / 监管对照 等),全部下沉到附录:

- **附录 A**:数据 / 业务条目的完整定义表(如"19 项核查项完整定义表")
- **附录 B**:核心设计机制(把模块特有的几个机制集中在这里,如 PDCA 闭环 / 状态机 / DSL / 监管对照 4 个子节)
- **附录 C**:术语表(中英对照 + 业务定义)

### 三、不该出现在 PRD 主体的内容

以下内容**不要写进 PRD 主体**,放原型 / UED 设计稿 / 技术设计文档:

- **UI 设计 / 交互细节**:按钮位置、控件样式、动效、配色规则 —— 这些归原型 / UED
- **实现细节**:URL 参数、技术栈、API 设计、数据库表 —— 这些归技术设计
- **页面截图说明**:原型已有可视化形态,PRD 不重复赘述具体形态
- **英文技术黑话**:`running-configuration` / `VendorVersion` / `chip` / `modal` 等,**统一换中文**(运行配置 / 厂商版本 / 标签 / 弹窗)

PRD 锚定的是"功能清单 + 产品规则",**不是 UI 不是实现**。

### 四、修订历史按"阶段"维护版本号

文档头部的修订历史表,**按阶段维护版本号**,不要按每次改动独立升号:

| 阶段 | 版本 | 触发条件 |
|---|---|---|
| 初稿 | v0.1 | 产品负责人完成、提交评审前 |
| 原型期累积修订 | v0.2 | 原型推进过程中持续累积的对齐修订,**所有原型期间的修改合并到本版** |
| 需求评审后定稿 | v0.3 | 评审会议反馈纳入后定稿 |

在修订历史表顶部加一段"修订阶段约定"说明,让读者一眼明白本 PRD 的版本节奏。**v0.2 不应该出现 v0.2 / v0.3 / v0.4 这种细分**——原型期所有改动合并写到一个 v0.2 即可,描述里可以分点列出"做了什么"。

### 五、产品决策 vs 功能描述

PRD 主体写"**功能项 + 产品规则**",每个功能项尽量是**可被勾选验收的具体行为**:

- 好:"列表字段:编号 / 名称 / 分类 / 规则数 / 厂商版本覆盖度 / 状态"
- 不好:"列表展示核查项的关键信息"(太抽象,验收无法对)

涉及"为什么这样做"的产品决策,放在**该功能描述之后的一两句解释**里。不要单开"设计原因"小节。

### 六、体量控制(防 AI 长篇大论)

**PRD 主体目标体量:仔细评审 15 分钟读完**。

按中文阅读速度 200 字/分钟(技术文档 + 表格)估算:

| 阅读场景 | 速度 | 主体目标字数 |
|---|---|---|
| 仔细评审(评审会前) | 200 字/分钟 | **3,000 ~ 3,300 汉字** |
| 正常阅读(理解每段) | 300 字/分钟 | 11 分钟读完 |
| 扫读(快速浏览) | 500 字/分钟 | 7 分钟读完 |

**为什么有这个上限**:

- 评审会上,所有人(产品、研发、QA、设计)都要看完 PRD。**超过 15 分钟没人看完**,评审就变成"产品讲、其它人听",决策质量下降
- AI 写 PRD 容易堆砌:把每个决策都解释一遍背景 / 利弊 / 选择理由 → 字数暴涨,信息密度暴跌
- 真正起作用的是"**可验收的行为清单 + 数字事实**",不是"我们为什么这样设计"的解说

**怎么控制**:

- 主体写完后跑一遍字数统计(`grep -o '[一-鿿]' file.md | wc -l`),超过 3,300 就**逐章审视哪段在解释而非锚定行为**
- 长描述合并成对比表(如"三个视图各 200 字" → "对比表 1 行 80 字")
- 删除"为什么这样设计"类解释段(放挂起话题清单或附录,不进主体)
- 章节首段的"本章讲什么"导读句,如果只是重复章节标题,删掉

**附录不受 15 分钟约束**,因为是按需查阅,不是必读。

---

## 输出物清单

完成本 skill 后,你应该有:

1. **PRD 主文档**(.md 格式,遵循上面「PRD 文档结构标准」)
   - 主体:**产品背景与目标 / 用户角色与场景 / 核心痛点与价值主张 / 产品范围(按菜单) / 信息架构 / 版本规划与功能取舍**
   - 附录:**数据完整定义表 / 核心设计机制 / 术语表**
2. **挂起话题清单**(.md)
3. **术语字典**(可以是 PRD 的附录,或独立文件)
4. **数据模型 ER 图**(可以用 mermaid 嵌在 PRD 里)
5. **状态机图**(同上)
6. **(优化场景额外)现状盘点 + 痛点矩阵 + 改造路径选择**

---

## 与下一步的衔接

PRD 完成后,进入姐妹 skill **`prd2prototype`**(本 plugin 内的另一个 skill),把 PRD 落成可评审的高保真原型。

**重要**:**本 skill 产出的 PRD 是"草稿"**,不是终稿。原型评审通过后,需要走 `prd2prototype` 的第 8 步 —— **回写 PRD + 锁定本轮迭代范围 + 拉通设计/技术/QA 确认**,才得到 PRD 终稿。

产品经理是迭代 owner,要主动驱动这一步,把"PRD 草稿 → 原型评审 → PRD 终稿"形成完整闭环,而不是停在原型评审通过就交出去。