06 · 进阶：原型转 PRD Skill
05 章那个纪要 Skill 是"一个模板 + 一组规则"，够用但简单。这一章做一个真正复杂的：把一段原型的文字描述，转成能交给研发的 PRD。
它复杂在三个地方，也正好演示三种进阶写法：
| 复杂在哪 | 用什么手法 |
|---|---|
| 步骤多，顺序不能乱 | 带勾选框的工作流 |
| 输出长，容易漏块 | 模板 + 检查回路 |
| 有必须写死的业务口径 | 口径专章 + 反例 |
输入长什么样
原型不用画图，用文字描述就行——这本身也是个教学点：你不必会画线框，把界面"说清楚"就够了。
text
【原型｜预算偏差预警看板 - 首页】
· 顶部：四个数字卡片——总预算、已下单、偏差金额、偏差率。
· 中部：一张项目列表表格，每行是一个项目，列出该项目的预算、已下单、
偏差金额、偏差率；偏差为负的金额标红。
· 表格可按"偏差金额绝对值"从大到小排序。
· 右上角：两个按钮——「上传对账表」（上传 Excel）、「导出」。
· 点某个项目行 → 向下展开，显示该项目下各成本子类的偏差明细。
· 顶部有筛选：按"大区"、按"项目状态"两个下拉。完整的 Skill
markdown
---
name: prd-from-prototype
description: 把功能原型的文字描述转成可直接交给研发的 PRD，包含功能背景、
用户场景、模块详述（字段 / 交互 / 计算口径）、边界异常、验收标准，以及
一份「待产品确认」清单。当用户提供原型描述、界面草图说明、功能构想，
或要求写 PRD、需求文档、需求评审材料、把原型转成需求时使用。
---
# 原型转 PRD
## 工作流
把下面这份清单复制到你的回答开头，每完成一步打一个勾：
```
- [ ] 步骤 1：读原型，列出所有可见元素和交互
- [ ] 步骤 2：标出原型没说清的地方（不要自己补）
- [ ] 步骤 3：按模板写 PRD 正文
- [ ] 步骤 4：把步骤 2 标出的问题整理成「待产品确认」清单
- [ ] 步骤 5：对照检查清单自查，不通过就回到步骤 3
```
**步骤 1 · 拆解原型**
逐条列出：有哪些区块、每个区块有哪些字段、有哪些操作、有哪些状态变化。
只描述原型里写了的，不要脑补。
**步骤 2 · 标出缺口**
每遇到一处"研发会来问、但原型没说"的地方，就记一条。典型的缺口：
枚举值有哪些、分母是什么、空数据怎么显示、权限怎么分、排序的次要规则、
上限和分页、错误提示的文案。
**这一步不要自己假设答案，只记问题。**
**步骤 3 · 写正文**
按下面的模板。
**步骤 4 · 汇总缺口**
把步骤 2 的问题写成文末清单，每条写成一个可以直接问产品的问句。
**步骤 5 · 自查**
对照末尾的检查清单，不通过就改，不要交带问题的版本。
## 输出模板
```
# [功能名] · PRD
## 1. 功能背景与目标
[当前怎么做、痛点是什么、这个功能要达成什么]
## 2. 目标用户与使用场景
- 用户：[角色]
- 场景：[什么时候、为了什么而打开它]
## 3. 功能列表
[一句话概览每个模块，用①②③编号]
## 4. 各模块详细需求
### 4.x [模块名]
- 字段：[逐个列出]
- 交互：[点什么、发生什么]
- 计算规则：[公式写死]
- 联动：[受哪些筛选 / 状态影响]
## 5. 边界与异常处理
[空数据、极值、除零、字段缺失、权限不足、并发]
## 6. 验收标准
[可勾选的条目，每条都要能被测出来]
## 7. 待产品确认
[编号列出，每条是一个可以直接问的问句]
```
## 硬性口径
这些是团队规范，必须写进 PRD，不得省略：
- **所有计算必须写出公式。** 例：偏差金额 = 已下单 − 预算。
- **不替用户下结论。** 例：偏差为负不代表"节约"，也可能是少下单或未下单，
界面只如实展示，可加提示语，但不得自动标注为"节约"。
- **除零必须处理。** 任何比率型指标都要写明分母为 0 时显示什么。
- **口径必须统一。** 同一个指标在卡片和列表里的分母必须一致；
如果原型没说清是哪个分母，进「待产品确认」，不要自己选一个。
## 边界
- 不臆造原型里没有的功能。想到了但原型没写的，进「待产品确认」，
不要直接写进需求。
- 面向研发，语言具体可执行；不写"提升用户体验""优化交互"这类空话。
- 原型描述与用户口头补充冲突时，以口头补充为准，并在文末注明这处冲突。
## 反例
❌ "偏差率 = 偏差金额 ÷ 预算"
—— 没说是"该项目预算"还是"总预算"，研发会按自己的理解写。
✅ "偏差率 = 偏差金额 ÷ 该项目预算。
注意：顶部卡片的偏差率分母为总预算，与列表口径不同，此处需产品确认。"
—— 写死了公式，并把口径不一致这件事挑明了。
❌ "偏差为负标红，表示节约。"
—— 替用户下了结论。
✅ "偏差为负时金额标红。不标注含义——负偏差可能为节约、少下单或未下单。"
## 检查清单
- [ ] 七个章节齐全
- [ ] 每个计算指标都写出了公式，且写明了分母
- [ ] 每个比率型指标都写了分母为 0 时的显示
- [ ] 没有出现原型里不存在的功能
- [ ] 「待产品确认」清单非空（原型不可能什么都说清了）
- [ ] 「待产品确认」里每条都是一个能直接问的问句，不是一个陈述
- [ ] 全文无"提升体验""优化交互"这类不可验收的表述三个手法，单独拎出来说
手法一：带勾选框的工作流
text
把下面这份清单复制到你的回答开头，每完成一步打一个勾：
- [ ] 步骤 1：……对多步骤任务特别有效：让它把进度显式地写出来，它就不容易跳步。——尤其是"步骤 2 只记问题不给答案"这种反直觉的要求，没有清单它十次有八次会顺手把答案也编了。
副作用是回答开头多几行。不想要就加一句"完成后把清单删掉再输出"。
手法二：检查回路
text
步骤 5 · 自查：对照末尾的检查清单，不通过就改，不要交带问题的版本。配上末尾那份具体的清单，形成一个闭环：做 → 查 → 不合格就回去改 → 再查。
清单一定要写成可勾选的具体项（"每个比率型指标都写了分母为 0 时的显示"），不能写成"内容完整准确"——后者查不了。
手法三：口径专章 + 反例
业务里那些"看着合理但不能这么写"的规矩，光写正面要求不够，必须给反例。
上面那组 ❌/✅ 就是：只说"要写清分母"，它会写"÷ 预算"然后觉得自己写清了。给一个反例，它才知道边界在哪。
这三个手法可以单独用
不做 PRD 也用得上：
- 步骤多 → 用勾选清单
- 输出长、容易漏 → 用检查回路
- 有行业口径 → 用反例
它们和提示词篇 04 章的"让它先想再答"是同一个思路，只是固化进了 Skill。
该拆文件了吗
上面这个 Skill 已经不短了。如果你还要加上"三种不同类型看板的模板""公司的字段命名规范""十组完整示例"，就该按 03 章拆：
text
prd-from-prototype/
├── SKILL.md 工作流 + 口径 + 边界 + 检查清单（保持简短）
├── TEMPLATES.md 三种功能类型的 PRD 模板
├── NAMING.md 字段命名与术语规范
└── EXAMPLES.md 完整示例（输入原型 → 输出 PRD）主文件里这样指过去：
markdown
## 模板
默认模板见下。看板类 / 表单类 / 流程类的专用模板见 [TEMPLATES.md](TEMPLATES.md)。
## 命名
字段和术语的命名规范见 [NAMING.md](NAMING.md)。记住那条硬规矩：引用只能一层深。
下一步
07 · 先写测试再写正文 —— 上面这个 Skill 到底行不行，得测了才知道。