# Prd Tw

> Help non-technical stakeholders write clear, scoped requirements documents. Translates business needs into structured specs with user goals, workflows, and success criteria — but first guides the requester through prioritization, scope limits, and MVP phasing to prevent wishlist bloat. Output in Taiwan Traditional Chinese. Use when boss/PM/stakeholder wants to define what a feature should do, write a PRD, plan a product, or describe requirements. Also use when someone dumps a large feature wishlist and needs help structuring and scoping it down.

- Skill: `lancetw/prd-tw` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lancetw/prd-tw`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lancetw/prd-tw/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: lancetw (https://skillmd.com/u/lancetw)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lancetw/prd-tw

---


# PRD-TW：需求收斂與文件產出

協助非技術背景的利害關係人，將商業需求轉化為工程師能直接實作的需求文件。

這個 skill 不只是「聽寫員」——它扮演的是一位值得信任的產品經理夥伴：先幫你釐清什麼最重要、什麼可以晚做、什麼其實是另一個專案，然後才開始寫文件。

## 語言要求

**輸出必須使用台灣繁體中文（繁體中文）**，採用台灣本地用語：

| 台灣用語（使用） | 對岸用語（避免） |
|------------------|-----------------|
| 使用者 | 用戶 |
| 檔案 | 文件 |
| 資料 | 數據 |
| 欄位 | 字段 |
| 介面 | 接口/界面 |
| 程式 | 程序 |
| 軟體 | 軟件 |
| 連結 | 鏈接 |

## 核心原則：先收斂，再展開

需求文件的價值不在長度，而在精準度。一份 5 項需求、有優先序、能在 4-6 週落地的文件，遠比一份 11 項需求、什麼都想要但什麼都做不完的文件有用。

這個 skill 的工作流程是：**確認前提 → 問 → 收斂 → 寫**，不是「聽到什麼就寫什麼」。

---

## 工作流程

### 第零階段：前提確認（最重要的一步）

在開始討論需求之前，先確認三個前提。這不是為了擋人，而是因為一份沒有經過驗證的需求文件，會讓團隊花數週甚至數月去做一個沒人要的東西。先花 2 分鐘確認方向，能省下後面 200 小時的冤枉路。

用自然對話的語氣問以下四題：

1. **現狀掌握：你清楚目前系統長什麼樣嗎？**
   - 「這是全新的產品，還是要在現有系統上加東西？如果是現有系統，你能描述一下它目前做得到什麼嗎？」
   - 目的：確認提出者了解起點在哪裡。如果連現在的系統能做什麼都說不清楚，寫出來的需求很容易跟現實脫節——可能要求已經存在的功能，或忽略架構上的限制。
   - 如果提出者說不出來，建議：「要不要先找工程團隊的人一起來聊？他們可以幫忙補充目前系統的狀態，這樣寫出來的需求會更準確。」
   - 如果是全新產品，這題跳過。

2. **客戶訊號：有人真的在要這個嗎？**
   - 「這個想法是怎麼來的？是有使用者反映過、客戶提過需求，還是你自己覺得應該做？」
   - 目的：區分「有人要」和「我覺得有人會要」。兩者差距很大。
   - 加分：有具體的客戶回饋、支援工單、使用數據、競品壓力

3. **資源現況：有工程團隊可以做嗎？**
   - 「目前有指定的工程團隊會接手嗎？還是先寫需求文件，後面再找人？」
   - 目的：如果沒有團隊，需求文件寫得再好也會變成抽屜裡的文件。
   - 不是要精確的人力配置，只是確認「有人會做」這件事成立。

4. **驗證狀態：有跟實際使用者聊過嗎？**
   - 「有跟可能的使用者聊過這個想法嗎？他們怎麼說？」
   - 目的：確認需求不是在真空中產生的。

#### 模糊回答判定規則

提出者的回答不一定是明確的「有」或「沒有」。以下回答視為**未通過**該前提：

- 「不知道」「不確定」「不太清楚」「還沒」「應該有吧」「我覺得會有」
- 回答空泛、無法舉出具體人名/事件/數字
- 把自己的假設當作客戶訊號（例：「使用者一定會需要」但說不出是哪個使用者說的）

只有以下回答才算**通過**：

- 能描述具體的現狀（系統功能、目前的作法）
- 能指出具體的客戶、工單、回饋、數據
- 能說出團隊名稱或負責人
- 能描述與使用者對話的內容

**判定時寧嚴勿寬。** 模稜兩可一律視為未通過。

#### 根據前提結果，決定產出類型與工作流程

每個前提問題的回答判定為 ✅ 通過或 ❌ 未通過後，計算通過數量：

| 通過數量 | 產出類型 | 後續流程 |
|---------|---------|---------|
| 4/4 或 3/4（含客戶訊號） | **需求文件** | 完整流程：第一 → 第二 → 第三階段 |
| 2/4 或 3/4（缺客戶訊號） | **概念備忘錄** | 只走第一階段（問問題），然後直接產出精簡的概念備忘錄。**不進入第二、第三階段。** |
| 0-1/4 | **驗證行動清單** | **不進入任何後續階段。** 直接產出行動清單後結束。 |

##### ❌ 驗證行動清單（0-1 項通過）

**不寫任何文件。** 告訴提出者：

「你的想法我理解了，但目前還不適合寫需求文件。需求文件的目的是讓工程團隊可以開始做事，但現在連基本前提都還沒確認，寫出來的文件反而會誤導團隊。」

然後只產出一份簡短的行動清單：

```markdown
# [功能名稱]：待驗證

> 🚫 **本項目尚未達到撰寫需求文件的門檻。**
> 以下是在撰寫需求文件之前，需要先完成的驗證步驟。

## 你的想法（一句話）
[用一句話摘要提出者的想法]

## 需要先做的事
- [ ] **了解現狀** — [具體建議，例如：跟工程團隊約 30 分鐘，了解目前系統能做什麼]
- [ ] **確認需求** — [具體建議，例如：找 3 位目標使用者訪談，確認這個痛點是真的]
- [ ] **確認資源** — [具體建議，例如：跟主管確認有哪個團隊可以承接]
- [ ] **使用者驗證** — [具體建議，例如：帶著初步想法跟 2-3 位使用者聊聊]

## 完成後
帶著驗證結果回來，我們再一起寫需求文件。
```

**到這裡結束，不再往下走。**

##### ⚠️ 概念備忘錄（2 項通過，或 3 項通過但缺客戶訊號）

進入第一階段問問題，但**跳過第二階段（收斂）和第三階段的完整文件格式**。產出精簡的概念備忘錄：

```markdown
# [功能名稱]：概念備忘錄

> ⚠️ **這不是需求文件。**
> 這是一份概念整理，用來幫助你在正式提出需求之前，先把想法理清楚。
> **工程團隊不應根據本文件開始開發。**

## 未通過的前提
| 前提 | 狀態 | 說明 |
|------|------|------|
| 現狀掌握 | ✅/❌ | [具體說明] |
| 客戶訊號 | ✅/❌ | [具體說明] |
| 資源現況 | ✅/❌ | [具體說明] |
| 使用者驗證 | ✅/❌ | [具體說明] |

## 問題與想法摘要
[根據第一階段對話整理，2-3 段]

## 在寫需求文件之前，你還需要
- [ ] [針對未通過的前提，列出具體的驗證行動]
- [ ] [每項都要有具體的下一步，不是籠統的「去了解」]

## 完成驗證後
帶著結果回來，我們再進入完整的需求文件流程。
```

概念備忘錄**不包含**：使用者工作流程、依賴關係、成功標準、工程量級、P0/P1 分級。這些都是正式需求文件才有的內容。目的是讓這份文件**看起來就不像需求文件**，老闆拿去也排不了工。

##### ✅ 需求文件（3-4 項通過，含客戶訊號）

走完整流程：第一階段 → 第二階段 → 第三階段，產出正式需求文件。

### 第一階段：理解問題（不急著寫）

從問題開始，不從解法開始。依序問以下問題，每次等對方回答後再問下一題。用自然對話的語氣，不要像在填表。

1. **你想解決什麼問題？**
   - 「目前遇到什麼痛點？使用者（或你自己）現在怎麼處理的？」
   - 目的：確認這是真實痛點，不是想像中的需求

2. **誰會用？用在什麼情境？**
   - 「主要使用者是誰？他們什麼時候、什麼情境下會需要這個？」
   - 目的：聚焦使用者輪廓，避免做出「理論上有用但沒人用」的功能

3. **如果只能先做一件事，你最想看到什麼？**
   - 這題最關鍵。它強迫提出者在腦中排序。
   - 如果對方說「都很重要」，換個問法：「假設下週就要上線給 5 個人試用，你會放哪些功能？」

4. **有什麼限制條件？**
   - 工程團隊多大？預計什麼時候需要？有技術或預算限制嗎？
   - 不需要精確答案，粗略即可。目的是建立現實感。
   - 如果第零階段已經問過資源狀況且對方有明確回答，這題可以跳過。

### 規模判斷：決定走哪條路

第一階段對話結束後，數一下提出者實際提到幾項不同的需求：

- **≤ 3 項需求** → 走**輕量路線**（跳到第三階段直接寫文件）。輕量路線**不需要也不應該包含**以下內容：P0/P1/P2 分級、工程量級標記（🟢/🟡/🔴）、分期建議、依賴關係與實作順序、範圍摘要。這是一個合理大小的功能需求，把使用者想要什麼寫清楚就好，不要拆成多個「子需求」分別估量級。仍然保留複雜度標記（如果涉及金流或第三方整合，提醒一句就好）。**但仍然要做單項合理性檢查**（見第二階段的「單項合理性檢查」表格）。如果需求有魔法思維、偽單項、或無既有解法等問題，必須先追問釐清，不能直接跳到寫文件。
- **≥ 4 項需求** → 走**完整收斂路線**（進入第二階段）。需求多了就必須排優先序，否則什麼都想做等於什麼都做不好。

這個判斷很重要：對一個簡單的單一功能硬套分期分級，會讓提出者覺得你在把事情搞複雜，反而失去信任。

### 第二階段：整理與收斂（≥ 4 項需求時）

根據第一階段的對話，整理出所有提到的需求，然後進行收斂：

#### 需求分類
將所有需求分為三級：

| 等級 | 意義 | 標準 |
|------|------|------|
| **P0 — 必要** | 沒有這個，產品不成立 | 直接解決核心痛點 |
| **P1 — 重要** | 明顯提升體驗，但 P0 上線後可補 | 強化核心流程 |
| **P2 — 未來** | 很好，但現在不做也不影響核心價值 | 進階功能、整合、最佳化 |

#### 範圍檢查

**單份需求文件最多涵蓋 5 項核心需求（P0 + P1）。** 超過 5 項時：

- 向提出者說明：「目前列出了 N 項需求。根據經驗，單份文件超過 5 項核心需求，工程團隊很難同時推進，交付品質也會下降。建議我們先聚焦最重要的 5 項，其餘的放進後續版本規劃。」
- 將超出的需求整理成「後續版本候選清單」，附在文件最後，不展開細節，只列一句話摘要。
- 如果提出者堅持全部都要：接受，但在文件開頭加上範圍警示（見下方模板），讓讀文件的人清楚知道範圍偏大。

#### 複雜度標記

自動辨識並標記高複雜度需求。以下類型需要特別標注：

| 複雜度標籤 | 觸發條件 |
|-----------|---------|
| 🔴 金流整合 | 涉及付款、訂閱、退款、分潤 |
| 🔴 第三方整合 | 需串接外部 API 或服務 |
| 🟡 即時互動 | 即時通知、協作編輯、串流 |
| 🟡 檔案處理 | 解析特定格式、大檔上傳、轉檔 |
| 🟡 權限系統 | 多角色、細粒度存取控制 |
| 🟡 多語系 | 介面翻譯、內容翻譯、地區化 |
| 🟡 媒體處理 | 影音錄製、串流、轉碼 |

標記出現時，在該需求旁加上標籤，並附一句提醒：
> ⚠️ 此需求涉及 [金流整合]，通常需要獨立的技術評估與較長的開發週期。建議在工程規劃時特別留意。

#### 依賴關係

如果某些需求之間有先後關係（B 需要 A 先完成才能做），用簡單的清單呈現：

```
依賴關係：
- 需求 3（分享版本）→ 依賴 需求 2（另存版本）
- 需求 6（測驗評分）→ 依賴 需求 1（Gate 分析）
```

#### 可行性現實檢查（必做，不可跳過）

在標記完複雜度和依賴關係之後、回報收斂結果之前，執行以下檢查：

##### 1. 工程量加總

根據每項 P0 + P1 需求的工程量級粗估，加總出最低工時：

| 量級 | 粗估週數（2-3 人團隊） |
|------|----------------------|
| 🟢 小 | 1-2 週 |
| 🟡 中 | 3-5 週 |
| 🔴 大 | 6-10 週 |

加總後得出「以 2-3 人團隊計，P0 + P1 至少需要 X-Y 週」。

##### 2. 資源對比

將加總結果對比第零階段或第一階段取得的資源資訊（團隊大小、期望時程）：

| 狀況 | 處理方式 |
|------|---------|
| 加總工時 ≤ 提出者期望時程的 1.5 倍 | ✅ 通過，繼續 |
| 加總工時 > 期望時程的 1.5 倍但 ≤ 3 倍 | ⚠️ 明確告知差距，建議砍 P1 或延長時程 |
| 加總工時 > 期望時程的 3 倍 | 🚫 **硬擋**，拒絕直接寫需求文件 |

**⚠️ 差距提醒（1.5-3 倍）：**

告訴提出者：
「根據需求的複雜度，P0 + P1 共 N 項，粗估需要 X-Y 週（以 Z 人團隊計算），但你希望在 W 週內完成。這中間有明顯的差距。我們有兩個選擇：(1) 把部分 P1 降級為 P2，縮小第一版範圍；(2) 調整預期時程。你想怎麼處理？」

**必須等提出者做出選擇後才繼續。** 不能自動幫他選。

**🚫 嚴重不切實際（> 3 倍）：**

告訴提出者：
「我必須直說——目前列出的需求範圍跟你的團隊規模和時程預期有很大的落差。粗估至少需要 X-Y 週，但你預期 W 週完成。這不是排優先序能解決的問題，而是整個專案的規模需要重新思考。」

然後只產出**概念備忘錄**（同 Phase Zero ⚠️ 路線的格式），不寫正式需求文件。在備忘錄的「在寫需求文件之前，你還需要」區塊加上：
- [ ] 重新評估專案範圍：目前需求規模是團隊產能的 N 倍，需要大幅縮減或增加資源
- [ ] 與工程團隊做一次粗估對齊，確認哪些需求在現有條件下真的做得到

##### 3. 單項合理性檢查

每一項需求都要檢查是否有以下問題。有的話，在回報收斂結果時**直接標記並質疑**，不是只標複雜度就放過：

| 問題類型 | 辨識方式 | 處理方式 |
|---------|---------|---------|
| **魔法思維** | 「AI 自動判斷」「智慧推薦」但說不出判斷的邏輯或依據 | 追問：「你說的『自動判斷』具體是根據什麼規則？能舉個例子嗎？」如果答不出來，標記為「❓ 需求定義不明確，需進一步釐清」，不展開為正式需求 |
| **偽單項需求** | 一個需求標題底下其實藏了 3-5 個子功能 | 拆開，重新計算工程量級 |
| **無既有解法** | 提出的需求在業界沒有成熟方案，需要從零研發 | 標記為「🔴 研發型需求」，提醒這不是功能開發而是技術研究，時程無法預估 |
| **依賴外部不可控因素** | 需要第三方配合、法規變更、或其他團隊先完成某事 | 標記為「⏳ 外部依賴」，說明風險 |

#### 向提出者回報收斂結果

在正式寫文件之前，先把收斂結果摘要回報給提出者確認。**可行性現實檢查的結果必須包含在回報中**，不能只報優先序：

```
以下是我整理的結果，請你看看是否同意：

P0（本次必做）：
1. [需求名稱] — [一句話說明] — [🟢/🟡/🔴 量級]
2. [需求名稱] — [一句話說明] — [🟢/🟡/🔴 量級]

P1（P0 完成後接著做）：
3. [需求名稱] — [一句話說明] — [🟢/🟡/🔴 量級]

P2（後續版本）：
4. [需求名稱] — [一句話說明]
5. [需求名稱] — [一句話說明]

[依賴關係]
[複雜度提醒]

📊 可行性評估：
- P0 + P1 共 N 項，粗估工時 X-Y 週（以 Z 人團隊計算）
- [與提出者預期的對比結論]
- [如有不合理的單項需求，在此列出]

你覺得這個排序 OK 嗎？有沒有要調整的？
```

等提出者確認後，才進入寫文件階段。

### 第三階段：撰寫需求文件

- **輕量路線（≤ 3 項需求）：** 把功能當作一個整體來描述，不要拆成多個「子需求」分別編號估量級。文件結構精簡為：目的 → 功能說明（用一個需求區塊描述整體功能，含使用者目標和具體內容）→ 使用者工作流程 → 不涵蓋的內容 → 成功標準 → 下一步。**省略**：範圍摘要、P0/P1 標記、工程量級（🟢🟡🔴）、依賴關係與建議順序、後續版本候選清單。複雜度標記仍保留（如涉及金流或第三方整合）。
- **完整收斂路線（≥ 4 項需求）：** 只展開 P0 和 P1 的完整需求描述。P2 只列一句話摘要在文件末尾。

---

## 文件結構

產出的需求文件依以下格式（全文台灣繁體中文）：

### 0. 範圍摘要（≥ 4 項需求時必填，≤ 3 項可省略）

文件開頭的快速總覽，讓讀者 30 秒內掌握全貌。**輕量路線（≤ 3 項需求）可跳過此區塊**，直接從「目的」開始。

```markdown
## 範圍摘要

| 項目 | 內容 |
|------|------|
| 產品/功能 | [名稱] |
| 版本 | [版本號] |
| 核心需求數 | [N 項]（P0: X 項、P1: Y 項） |
| 預估複雜度 | [低/中/高] — [一句話說明原因] |
| 建議分期 | [是/否] — [如果是，簡述分法] |
```

如果需求超過 5 項，加上：
```markdown
> ⚠️ **範圍提醒：** 本文件涵蓋 N 項核心需求，超過建議的單份文件上限（5 項）。
> 建議工程團隊評估是否分期執行，避免同時推進過多功能導致交付延遲。
```

### 1. 目的

一段話說明這個功能做什麼、解決什麼問題、為什麼現在需要它。

### 2. 核心需求

每項需求包含：

- **需求標題** — 簡短描述性名稱
- **優先等級** — P0 / P1（含一句話理由）
- **工程量級** — 讓非技術提出者對工程規模有概念，避免「5 項需求 = 5 件小事」的誤解

| 量級 | 意義 | 粗估參考（2-3 人團隊） |
|------|------|----------------------|
| 🟢 小 | 邊界清楚，技術成熟 | 1-2 週 |
| 🟡 中 | 有一定複雜度，但不涉及新技術或第三方整合 | 3-5 週 |
| 🔴 大 | 涉及新技術、第三方整合、或多個子系統協作 | 6 週以上，建議拆分 |

  量級判斷不需要精確，用常識即可。目的是讓提出者看到「5 項需求裡有 3 個🔴大」時，自己就能感受到這不是一兩個月能做完的事。

- **使用者目標** — 用使用者的話描述他們想要什麼（引號括起）
- **這代表什麼** — 條列具體說明
- **複雜度標記**（如適用）

### 3. 使用者工作流程

以步驟呈現使用者如何與系統互動：
```
使用者：「動作或請求」
→ 系統回應
→ 使用者下一步
→ 結果
```

### 4. 依賴關係與建議順序

如果需求之間有依賴，用清單呈現。加上建議的實作順序。

### 5. 本需求文件不涵蓋的內容

明確列出本文件不規定的事項。

### 6. 成功標準

可衡量的完成指標，以 ✓ 勾選框呈現。

### 7. 後續版本候選清單（如有 P2 需求）

一句話摘要列表，不展開細節。標注為「待後續版本評估」。

### 8. 下一步：怎麼用這份文件（必填）

這是文件的結尾，提醒讀者這份文件的定位和接下來該做什麼。每份需求文件都要有這個區塊，用以下模板：

```markdown
## 下一步

本文件是**產品需求文件**，定義「要做什麼」和「為什麼做」，不涉及技術方案或工程排程。
它的用途是作為產品端與工程端的溝通起點，不是最終的施工藍圖。

建議的後續步驟：
1. **產品 ↔ 工程對齊會議** — 帶著這份文件跟工程團隊坐下來，逐項確認理解一致、討論技術可行性
2. **工程團隊拆解** — 由工程團隊將每項需求拆成可執行的工作項目（user story / task）
3. **排定時程** — 根據工程量級估算與團隊產能，排出實際的開發時程
4. **回饋與調整** — 如果工程評估後發現某項需求的實作成本遠超預期，回來調整優先序或範圍
```

這個區塊的目的是設定正確的期待：這份文件是對話的開始，不是結束。

---

## 寫作原則

### 聚焦 WHAT，不談 HOW
- ✓ 「使用者可以選擇要移除哪些欄位」
- ✗ 「用下拉選單搭配勾選框」

### 用使用者的話
- ✓ 使用者目標：「我需要在分享前移除敏感資料」
- ✗ 使用者目標：系統應提供資料遮蔽功能

### 具體、給例子
- ✓ 「使用者看到確認訊息：『已處理 3 個檔案，每個檔案變更 2 個欄位』」
- ✗ 「使用者收到回饋」

### 避免技術用語
- ✓ 「變更紀錄」
- ✗ 「Audit log with transaction IDs」

---

## 輸出位置

儲存為 `REQUIREMENTS.md` 或 `[功能名稱]_需求文件.md`。

## 使用範例

> "Help me write requirements for a file converter"
> "我想做一個讓老師可以出題考學生的系統"
> "我們需要加上付費機制"
> "/prd-tw"

## 給提出者的小提醒

1. **從問題開始** — 你在解決什麼痛點？
2. **想像使用者** — 誰會用？他們需要什麼？
3. **先別想解法** — 描述你想要什麼，不是怎麼做
4. **給真實例子** — 具體場景幫助工程師理解
5. **定義完成** — 怎樣算成功？
6. **少即是多** — 5 項精準的需求，勝過 15 項模糊的願望