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 到底行不行，得測了才知道。