官方技能 · 產品

開發前的規格審查

v1.0.1 · 2026 年 11 月 4 日 更新

在開發前審查 PRD 或規格：模糊的用詞、缺少的空白／載入／錯誤／權限狀態、指標、推出計畫，並以新使用者身分走查流程。

可在 Claude、ChatGPT 和程式設計代理中使用。使用 Team 和 Business 方案時，我們改進官方技能後，你 Pod 裡的這個技能會自動更新。

適用情境

• PRD 或規格即將交給工程團隊估工
• 某個功能上線後出現意外，下一份規格需要更嚴格地檢查

你要提供的內容

• 規格或 PRD 的文字
• 目標使用者（選填）
• 期限和團隊（選填）

你會得到的內容

一個結論、新使用者的流程走查、附原文引用的阻礙與應修正項目、狀態表，以及指標和推出計畫的檢查。

運作方式

1. 以第一次使用的使用者身分走一遍流程 從使用者進來的地方開始（email 連結、導覽選單項目、空白帳戶），逐步敘述：他看到什麼、必須決定什麼、點了什麼。規格沒寫接下來會出現什麼的地方，就記一個缺口。任何會讓新手困惑的標籤或問題，也記下來。
2. 檢查每個畫面的狀態 每個畫面或元件都要找：空白（第一次使用、沒有結果）、載入中、錯誤、部分資料、無權限，以及成功。NN/g 建議空白狀態要顯示系統狀態、教使用者怎麼開始，並提供直接通往任務的路徑；資料還在載入時，絕不顯示「沒有資料」。錯誤訊息應該看得到、用白話、有建設性，並保留使用者已輸入的內容。
3. 找出模糊的用詞 標出「快速」、「容易」、「簡單」、「直覺」、「應該」、「等等」、「和／或」、「一些」和「視需要」。每一個都需要一個數字、一份清單或一個決定。標出任何兩個讀者會測出不同結果的需求。
4. 檢查規則和限制 誰可以做這件事？可以做幾次？到達上限時會怎樣？上線時，既有的資料和使用者怎麼處理？如果缺少的答案會改變資料模型，就是阻礙問題。
5. 檢查指標 必須有一個與問題相關的主要指標、基準值、目標值，以及衡量方式。如果要計數的事件還不存在，那就是規格漏掉的需求。
6. 檢查推出與回復計畫 是否用功能旗標控制？誰先看到（內部、一定比例、某個客群）？什麼指標會觸發回復？能不能不經過發布就關掉？Martin Fowler 對功能開關的說明，區分了發布開關、依比例逐步推出，以及緊急關閉開關（kill switch）；緊急關閉開關必須能快速切換，不需要新的發布。
7. 排序並寫出發現 阻礙 = 團隊無法開發或測試，或會危及資料或信任。應該修正 = 會造成重工或混淆。小問題 = 用字。每項發現都引用規格原文、說明為什麼重要，並提出修正方式或問題。

SKILL.md 檔案

完整檔案，就是你的 AI 讀到的內容。 下載檔案

---
name: spec-review
description: 在團隊開發之前審查 PRD、產品規格或功能簡報：找出語意模糊的用詞、缺少的狀態（空白、載入中、錯誤、無權限）、缺少的成功指標、缺少的推出與回復計畫，並以第一次使用的使用者身分逐步走一遍流程。依嚴重程度列出阻礙問題和待釐清的問題。有人分享 PRD 或規格，請你審查、把關、給回饋、找缺口，或問「這可以開工了嗎？」時使用。
---

# 規格審查

當工程師、設計師和測試人員根據同一份規格，各自做出並測試出同一個東西時，這份規格才算準備好了。審查要找的，是他們會各做各的地方，以及沒人寫下來的狀態。在讀需求清單之前，先以第一次使用的使用者身分走一遍流程：缺口會在走的過程中浮現。

## 適用情境

- 工程團隊根據 PRD 或規格估工或開始開發之前。
- 規格修改過，需要再看一次時。
- 某個功能上線後出現意外，想更嚴格地檢查下一份規格時。
- 不適用於根據筆記撰寫規格：請用 prd-from-notes。也不適用於審查完成的畫面或文案：請用 landing-copy-review 或設計審查。

## 需要準備

- 規格或 PRD 的文字，包括任何設計稿的描述。
- 目標使用者是誰（如果規格沒寫）。沒有的話，就以沒受過任何訓練、第一次使用的使用者身分審查，並註明「[假設]」。
- 選填：期限和團隊，方便判斷範圍。

## 步驟

1. **以第一次使用的使用者身分走一遍流程。** 從使用者進來的地方開始（email 連結、導覽選單項目、空白帳戶），逐步敘述：他看到什麼、必須決定什麼、點了什麼。規格沒寫接下來會出現什麼的地方，就記一個缺口。任何會讓新手困惑的標籤或問題，也記下來。
2. **檢查每個畫面的狀態。** 每個畫面或元件都要找：空白（第一次使用、沒有結果）、載入中、錯誤、部分資料、無權限，以及成功。NN/g 建議空白狀態要顯示系統狀態、教使用者怎麼開始，並提供直接通往任務的路徑；資料還在載入時，絕不顯示「沒有資料」。錯誤訊息應該看得到、用白話、有建設性，並保留使用者已輸入的內容。
3. **找出模糊的用詞。** 標出「快速」、「容易」、「簡單」、「直覺」、「應該」、「等等」、「和／或」、「一些」和「視需要」。每一個都需要一個數字、一份清單或一個決定。標出任何兩個讀者會測出不同結果的需求。
4. **檢查規則和限制。** 誰可以做這件事？可以做幾次？到達上限時會怎樣？上線時，既有的資料和使用者怎麼處理？如果缺少的答案會改變資料模型，就是阻礙問題。
5. **檢查指標。** 必須有一個與問題相關的主要指標、基準值、目標值，以及衡量方式。如果要計數的事件還不存在，那就是規格漏掉的需求。
6. **檢查推出與回復計畫。** 是否用功能旗標控制？誰先看到（內部、一定比例、某個客群）？什麼指標會觸發回復？能不能不經過發布就關掉？Martin Fowler 對功能開關的說明，區分了發布開關、依比例逐步推出，以及緊急關閉開關（kill switch）；緊急關閉開關必須能快速切換，不需要新的發布。
7. **排序並寫出發現。** 阻礙 = 團隊無法開發或測試，或會危及資料或信任。應該修正 = 會造成重工或混淆。小問題 = 用字。每項發現都引用規格原文、說明為什麼重要，並提出修正方式或問題。

## 輸出格式

```markdown
# 規格審查：[規格名稱]

**結論：** [可以開工 / 修正阻礙問題後可開工 / 還不能開工] — [一句話說明原因]

## 第一次使用的流程走查
1. [步驟：使用者看到什麼、做了什麼] — [缺口或「清楚」]

## 阻礙
| # | 規格原文 | 問題 | 修正方式或問題 |
|---|---|---|---|
| B1 | 「[引用]」 | [為什麼構成阻礙] | [提案] |

## 應該修正
| # | 規格原文 | 問題 | 修正方式或問題 |
|---|---|---|---|

## 缺少的狀態
| 畫面 | 空白 | 載入中 | 錯誤 | 無權限 | 備註 |
|---|---|---|---|---|---|
| [畫面] | [已涵蓋 / 缺少] | …… | …… | …… | [備註] |

## 指標與推出
- 主要指標：[有 / 缺少] — [備註]
- 推出計畫：[有 / 缺少] — [備註]
- 回復觸發條件和緊急關閉開關：[有 / 缺少] — [備註]

## 小問題
- [用字]
```

## 範例

**輸入（節錄）：** 「使用者可以邀請自己的會計師，給予唯讀權限。邀請應該要很容易。唯讀使用者不能編輯。我們會衡量採用情況。1 號對所有人上線。」

**輸出：**

```markdown
# 規格審查：唯讀席次

**結論：** 還不能開工 — 沒有定義狀態、指標無法衡量，而且上線後沒有退路。

## 第一次使用的流程走查
1. 擁有者找邀請的入口 — 規格沒寫在哪個頁面；缺口。
2. 擁有者輸入 email — 規格沒寫如果這個 email 已經是成員會怎樣；缺口。
3. 會計師打開邀請信 — 沒有指定信件內容；缺口。
4. 會計師進入 App — 他第一眼看到什麼？空白的儀表板會讓人以為「壞掉了」；缺口。

## 阻礙
| # | 規格原文 | 問題 | 修正方式或問題 |
|---|---|---|---|
| B1 | 「不能編輯」 | 匯出算編輯嗎？留言算嗎？兩位工程師會給出不同答案。 | 列出允許的動作：檢視、匯出 [待確認]，其他都不行。 |
| B2 | 「1 號對所有人上線」 | 沒有功能旗標，也沒有回復觸發條件。一個權限錯誤就會讓所有帳戶曝險。 | 先用功能旗標開放給內部帳戶，再開放 10% [本技能的預設]；加上緊急關閉開關。 |
| B3 | 「我們會衡量採用情況」 | 沒有事件、基準值或目標值。 | 每週計算有 1 個以上已接受唯讀邀請的帳戶數；目標值待訂。 |

## 應該修正
| # | 規格原文 | 問題 | 修正方式或問題 |
|---|---|---|---|
| S1 | 「邀請應該要很容易」 | 無法測試。 | 「擁有者在團隊頁面點 3 下以內就能送出邀請。」[本技能的建議] |
| S2 | （無） | 唯讀席次沒有數量上限。 | 決定一個上限，或寫明「不設上限」。 |

## 缺少的狀態
| 畫面 | 空白 | 載入中 | 錯誤 | 無權限 | 備註 |
|---|---|---|---|---|---|
| 團隊頁面的邀請 | 不適用 | 缺少 | 缺少 | 缺少 | 非擁有者會看到什麼？ |
| 會計師的第一個畫面 | 缺少 | 缺少 | 缺少 | 不適用 | 需要一則「你只有檢視權限」的提示 |

## 指標與推出
- 主要指標：缺少 — 見 B3。
- 推出計畫：缺少 — 見 B2。
- 回復觸發條件和緊急關閉開關：缺少 — 見 B2。

## 小問題
- 「會計師」和「唯讀使用者」指的是同一個角色；選一個用。
```

## 寄出前檢查

- [ ] 流程走查從真實使用者進來的地方開始，並涵蓋到成功為止的每一步。
- [ ] 每項發現都引用規格原文，遺漏的部分則寫「（無）」。
- [ ] 每項阻礙都有提議的修正方式或直接的問題。
- [ ] 狀態表涵蓋規格中提到的每個畫面。
- [ ] 指標、推出和回復計畫都標明有或缺少。
- [ ] 你建議的預設值（百分比、點擊次數）都標為建議，而不是規格本身的內容。

## 常見錯誤

- 只審查需求清單。大部分缺口藏在步驟之間，所以要先走一遍流程。
- 列出 40 個小問題。先寫阻礙問題；小問題最多 5 個。
- 把規格整份重寫。指出缺口並提出建議就好；修正由作者負責。

分享給你的團隊

把它加入 AI Skill Pod，團隊每個人（外包人員也包括在內）都能從自己的 AI 使用同一個版本。 看看和團隊分享 AI 技能的最佳做法

加入我團隊的 Pod

更新紀錄

• v1.0.1 · 2026 年 11 月 4 日 · Example: S1's "3 clicks or fewer" is marked [our suggestion], as the checks require for defaults the review proposes.
• v1.0.0 · 2026 年 11 月 4 日 · First release.