Enterprise Prd Writer

企業 PRD Writer — 施工藍圖等級的產品需求文件

1. 核心定位

一份好的 PRD 不是單純的「想法整理」，也不是 PM 的個人思考筆記。

它應該是一份可供跨職能團隊共同使用的產品施工藍圖，用來明確定義：

• 要解決什麼問題
• 為誰解決
• 系統必須呈現什麼行為
• 哪些商業規則不可被誤解
• 哪些異常與邊界情境必須處理
• 哪些內容本期明確不做
• 哪些地方仍是假設、待確認或需技術評估
• 如何驗收、如何監控、如何上線、如何回退

完成標準

PRD 的完成，不以字數、頁數或圖表數量判斷，而以以下結果判斷：

1. 工程師可理解產品行為與商業規則，不需反覆追問本應由產品定義的內容。
2. QA 可根據文件直接拆出主要測試案例與邊界案例。
3. 設計師可理解各畫面、狀態、跳轉與例外情境。
4. 利害關係人清楚知道本期做什麼、不做什麼。
5. UAT 不應因需求語意模糊而出現大量「我以為」。
6. 所有不確定內容均被標記為 Assumption、Open Question 或 Pending Decision，而不是被 AI 擅自補成既定事實。

---

2. 角色邊界

PRD 應明確區分產品需求、產品建議與技術決策，避免 PM 越界指定技術實作，也避免工程團隊誤解哪些行為不可變更。

| 類型 | 定義 | 是否可由工程團隊調整 | |------|------|----------------------| | Product Requirement | 必須滿足的產品行為、商業規則、使用者結果、法規要求或 SLA | 不可直接變更，需與 Product 確認 | | UX Requirement | 互動流程、資訊架構、提示方式與可用性要求 | 可在不影響目標與 AC 的前提下討論 | | Product Recommendation | PM 對實作或流程的建議，不是強制技術方案 | 可由 Design / Engineering 提出替代方案 | | Technical Decision | 架構、資料結構、重試演算法、Queue、Cache、服務拆分等技術設計 | 由 Engineering 在 TDD / ADR 中決定 | | Operational Requirement | 後台操作、客服處理、稽核、人工介入與異常處置流程 | 需由 Product、Ops、Engineering 共同確認 |

強制原則

• 不應將技術建議寫成不可變更的產品要求。
• 不應要求 PRD 取代 Technical Design Document。
• 若某個技術細節會直接影響 SLA、合規、資金安全或使用者體驗，則可列入 PRD，但需說明其產品理由。
• Engineering 對技術可行性、效能、架構與最終技術複雜度擁有最終評估權。

---

3. 文件結構

3.0 輕量模式（小案子的降級路徑）

觸發條件（符合任一即啟用）： 個人專案、單一功能、無合規/金流/風控需求、單人或單團隊開發。

輕量模式下只產出以下章節，其餘章節整份標記 N/A（輕量模式略過），不強制填寫：

• §5 Executive Summary（可壓縮成 3–5 句）
• §9 Scope（In / Out of Scope）
• §13 Functional Requirements
• §14 Acceptance Criteria
• §15 Edge Case Analysis（只跑相關類型，不強制 28 項全查）
• §17 Screen / System States（只列實際存在的狀態）

不啟用權限矩陣、NFR、Dependencies、Analytics、Rollout/Migration/Rollback、UAT/Release Readiness 等企業級章節，除非使用者明確要求。

> 目的：避免幫個人小工具寫 PRD 時，吐出一份 20 章的巨獸。若不確定是否為小案子，先問使用者一句「這是要走輕量還是完整企業級？」。

3.1 完整結構

PRD 應根據產品規模調整深度，但以下章節為標準結構：

1. 文件資訊
2. Executive Summary
3. 背景與問題定義
4. 產品目標與成功指標
5. 使用者與使用情境
6. Scope
   ├── In Scope
   ├── Out of Scope
   └── Phase Boundary
7. Assumptions / Open Questions / Decisions
8. Dependencies
9. Roles & Permissions
10. Functional Requirements
    ├── 功能描述
    ├── 商業規則
    ├── Acceptance Criteria
    ├── Edge Cases
    └── Out of Scope
11. User Flow / System Flow
12. Screen / System States
13. Data & Integration Requirements
14. Non-functional Requirements
15. Analytics & Observability
16. Risk & Mitigation
17. Rollout / Migration / Rollback
18. MVP / Roadmap / Complexity Assumption
19. UAT & Release Readiness
20. Appendix

核心不可省略項目

• Acceptance Criteria
• Edge Case Analysis
• Screen / System States
• In Scope / Out of Scope
• Assumptions / Open Questions
• Dependencies
• Roles & Permissions
• 後台安全控制清單（金融級，涉及後台/admin 時強制）
• NFR
• Rollout / Rollback
• Complexity Assumption
• Final Validation Checklist

---

4. 文件資訊

每份 PRD 開頭需包含基本治理資訊：

| 欄位 | 內容 | |------|------| | Document Title | 文件名稱 | | Owner | Product Owner / PM | | Status | Draft / In Review / Approved / Deprecated | | Version | 文件版本 | | Last Updated | 最後更新日期 | | Reviewers | Design / Engineering / QA / Ops / Compliance 等 | | Target Release | 預計版本或日期 | | Related Documents | Wireframe、TDD、API Spec、ADR、Research、Ticket 等 | | Decision Log | 關鍵決策與日期 |

---

5. Executive Summary

用最短篇幅回答以下問題：

• 這個產品或功能解決什麼問題？
• 目標使用者是誰？
• 為什麼現在要做？
• 預期帶來什麼結果？
• 本期交付的核心範圍是什麼？

避免在此處放入大量細節。Executive Summary 的目的，是讓決策者在 1–3 分鐘內理解需求價值與交付邊界。

---

6. 背景與問題定義

必須包含

• 現況
• 使用者痛點
• 商業痛點
• 現有流程的問題
• 數據或事實依據
• 不處理的代價
• 問題陳述

問題陳述格式

[目標使用者] 在 [情境] 下，因為 [根本原因]，
目前無法有效完成 [核心任務]，
導致 [使用者 / 商業 / 風險結果]。

禁止事項

• 不得把解法當成問題。
• 不得僅寫「老闆希望做」。
• 若缺乏數據，需明確標記為 Assumption，不得虛構數字。

---

7. 產品目標與成功指標

目標

每個目標應具備：

• 明確對象
• 明確行為
• 明確結果
• 可觀測性
• 與問題陳述的直接關聯

KPI 表格

| 指標 | 定義 | Baseline | Target | Measurement Window | Data Source | Owner | |------|------|----------|--------|--------------------|-------------|-------| | [指標名稱] | [計算方式] | [目前值] | [目標值] | [觀察週期] | [事件 / DB / BI] | [Owner] |

指標分類

• Business Metrics
• Product Adoption
• Conversion
• Retention
• Operational Efficiency
• Error Rate
• Latency
• Risk / Compliance
• Customer Support Impact

若 Baseline 或 Target 不確定，標記為 TBD，並列入 Open Questions。

---

8. 使用者與使用情境

使用者定義

| User Type | 目標 | 痛點 | 使用頻率 | 主要權限 | |-----------|------|------|----------|----------| | [角色] | [目標] | [痛點] | [頻率] | [權限] |

使用情境

每個主要情境需描述：

• Actor
• Trigger
• Preconditions
• Main Flow
• Alternate Flow
• Success Outcome
• Failure Outcome

---

9. Scope 管理

In Scope

明確列出本期交付內容。

Out of Scope

明確列出本期不處理的內容，避免利害關係人、設計與工程自行延伸。

**Out of Scope（[功能名稱]）：**
1. [不做的事]
2. [延後到後續階段的內容]
3. [由其他系統或團隊負責的內容]

分期表格

| 階段 | In Scope | Out of Scope | Entry Criteria | Exit Criteria | |------|----------|--------------|----------------|---------------| | MVP | | | | | | Phase 2 | | | | | | Phase 3 | | | | |

原則

• Out of Scope 不是備忘錄，而是版本契約。
• 每個主要功能區塊都要有自己的 Out of Scope。
• 後續版本內容不得混入本期 AC。
• 若 Scope 尚未定案，需列入 Pending Decision。

---

10. Assumptions / Open Questions / Decisions

AI 不得把未知事項補成事實。

Assumptions

| ID | Assumption | Impact if Wrong | Validation Method | Owner | Due Date | |----|------------|-----------------|-------------------|-------|----------| | A-01 | | | | | |

Open Questions

| ID | Question | Why It Matters | Owner | Due Date | Status | |----|----------|----------------|-------|----------|--------| | Q-01 | | | | | Open |

Decision Log

| ID | Decision | Options Considered | Rationale | Decision Maker | Date | |----|----------|--------------------|-----------|----------------|------| | D-01 | | | | | |

強制原則

• 無法確認的法規、技術限制、商業規則、API 能力、第三方行為均不得猜測。
• 未確認內容使用 TBD、Assumption、Open Question 或 Pending Decision。
• 重大決策需保留 Rationale，避免後續重複爭論。

---

11. Dependencies

| Dependency | Type | Owner | Required By | Risk | Fallback | |------------|------|-------|-------------|------|----------| | [依賴項] | Internal / External / Legal / Data / Design / Platform | | | | |

依賴類型

• Internal Service
• External API
• Design System
• Data Pipeline
• Legal / Compliance
• Security Review
• Vendor
• Operations
• Customer Support
• Migration
• Other Team Delivery

---

12. Roles & Permissions

所有涉及不同角色的產品，都應建立權限矩陣。

| Capability | End User | Admin | Ops | Support | Compliance | Super Admin | |------------|----------|-------|-----|---------|------------|-------------| | View | | | | | | | | Create | | | | | | | | Edit | | | | | | | | Delete | | | | | | | | Approve | | | | | | | | Export | | | | | | |

權限規格需補充

• 權限來源
• 權限更新時機
• 權限快取行為
• 權限變更後的 Session 處理
• 未授權時的 UI 與 API 行為
• 稽核紀錄
• 高風險操作的二次驗證或覆核流程

---

12.5 後台安全控制清單（金融級 · 完整版）

任何涉及後台 / admin panel / 有登入的管理介面的金融產品，都必須完成本清單。 不適用項標 N/A 並說明原因，不得為填表而虛構。每項需給明確規格與建議預設值。

存取層（Access）

| 控制 | 必須定義 | 建議預設值 | |---|---|---| | IP 白名單 | 允許登入的網段 | 僅限公司固定 IP + VPN 網段 | | 地理封鎖 | 是否封鎖非營運國來源 | 封鎖營運國以外登入，例外走申請 | | 裝置綁定 / 指紋 | 是否綁定可信裝置 | 高權限帳號綁定裝置，新裝置需二次驗證 + 通知 |

身分驗證層（Authentication）

| 控制 | 必須定義 | 建議預設值 | |---|---|---| | 2FA / GA 綁定 | 強制與否、類型、綁定時機 | 全後台強制 TOTP（Google Authenticator），首次登入強制綁定 | | 登入錯誤凍結 | 失敗次數、凍結時長、告警 | 連續 5 次 → 凍結 30 分鐘 + 通知本人與安全團隊 | | Session 政策 | 逾時、閒置、多裝置 | 閒置 15 分登出、絕對逾時 8 小時、同帳號新登入踢舊 |

操作授權層（Authorization）— 金融後台核心

| 控制 | 必須定義 | 建議預設值 | |---|---|---| | 高風險操作二次驗證 | 哪些操作要再驗一次 | 提領、改參數、改權限、改風控規則需再輸入 OTP | | Maker-Checker（四眼原則） | 哪些操作需一人提交、另一人覆核 | 出金、參數變更、權限授予採雙人覆核，提交者不得自審 | | 覆核門檻 | 什麼條件觸發強制覆核 | 金額 ≥ 門檻、或風險等級 High 的操作強制進覆核佇列 | | 覆核時效與逾時 | 覆核多久內要完成、逾時如何處理 | 覆核 SLA 內未處理則告警升級，不自動放行 |

稽核層（Audit）

| 控制 | 必須定義 | 建議預設值 | |---|---|---| | 不可竄改 Audit Log | 記什麼、留多久 | 記操作者/時間/內容/來源 IP/前後值，寫入不可竄改儲存，留存符合當地金融法規 | | 敏感操作即時告警 | 哪些行為即時告警、給誰 | 出金、批次改動、權限變更即時告警至安全/風控 | | 定期權限盤點 | 多久盤一次、離職轉調如何回收 | 每季盤點；離職/轉調 24 小時內回收權限 |

> 上表為金融後台的最低要求。若產品另涉及冷熱錢包隔離、API 金鑰輪替、 > 提領地址白名單等，於 §18 Data & Integration 與 §21 Risk 補充。

---

13. Functional Requirements

每個功能點使用統一格式。

13.1 功能描述

• 功能名稱
• 使用者價值
• 商業目的
• Actor
• Preconditions
• Trigger
• Expected Outcome

13.2 規則 / 邏輯

| Rule ID | 規則名稱 | 條件 | 系統行為 | 優先級 | 備註 | |---------|----------|------|----------|--------|------| | R-01 | | | | | |

規則撰寫原則

• 使用可判定、可重現、可測試的語言。
• 避免「適當」、「盡快」、「正常情況」、「視情況」等模糊字眼。
• 涉及金額、比例、時間、日期、狀態、權限時，需明確定義。
• 若同時存在多條規則，需寫明優先級。
• 若涉及精度、四捨五入或資料來源，需明確標註。

---

14. Acceptance Criteria

每個功能點都必須附上 Acceptance Criteria。

標準格式

| AC ID | Rule | Given / When / Then | Edge Cases | Priority | |-------|------|---------------------|------------|----------| | AC-01 | [規則名稱] | Given [可重現的前置狀態、資料或數值]When [可觀測事件]Then ① [系統行為] ② [系統行為] ③ [系統行為] | [邊界情境] | Must |

撰寫原則

Given

必須包含可重現的：

• 狀態
• 權限
• 資料
• 數值
• 時間
• 系統條件

不要求每條都一定有數字，但必須讓 QA 能建立前置條件。

When

必須是可觀測事件，例如：

• 使用者點擊
• API 收到請求
• 系統收到事件
• 狀態改變
• 時間到達
• 數值跨越門檻

Then

• 使用編號列出所有系統行為。
• 順序代表執行順序。
• 包含 UI、資料、通知、稽核、狀態、權限等必要結果。
• 若結果非同步，需標示最終一致性或可接受延遲。

AC 品質標準

AC 必須具備：

• Testable
• Observable
• Deterministic
• Traceable
• Unambiguous

禁止事項

• 不得把內部實作細節當作 AC，除非該細節本身是產品要求或 SLA。
• 不得使用「系統正確處理」、「顯示適當錯誤」等無法測試的描述。
• 不得為了湊數而虛構 Edge Case。

---

15. Edge Case Analysis

每個功能都必須完成 Edge Case 分析。

若無額外合理邊界情境，應標記：

無額外 Edge Case：此功能為單一狀態切換，沒有並發、時間、權限或資料邊界。

Edge Case Checklist

至少檢查以下類型：

• Duplicate Request
• Concurrent Actions
• Race Condition
• Idempotency
• Retry
• Timeout
• Partial Failure
• Network Interruption
• Permission Change
• Session Expiry
• Missing Data
• Invalid Data
• Stale Data
• Date Boundary
• Timezone
• Daylight Saving Time
• Precision
• Rounding
• Currency Conversion
• Maximum / Minimum Value
• Pagination Boundary
• Empty Result
• Third-party Failure
• Rate Limit
• Service Degradation
• Data Consistency
• Event Ordering
• Rollback / Recovery

優先級

| 等級 | 定義 | |------|------| | P0 | 可能造成資金、安全、法規或大規模資料損失 | | P1 | 阻塞核心流程或造成高比例失敗 | | P2 | 有替代路徑，但影響體驗或效率 | | P3 | 低風險、低頻率、可延後處理 |

---

16. User Flow / System Flow

每個 Flow 至少包含

• Actor
• Entry Point
• Preconditions
• Main Path
• Alternate Path
• Failure Path
• Exit State
• Related API / Event
• Related AC

建議使用

• Flowchart
• Sequence Diagram
• State Diagram
• Swimlane Diagram

原則

PRD 只定義產品行為與跨系統互動目的。

服務拆分、Queue、Cache、DB Schema、Retry Algorithm 等技術設計，應由 Engineering 在 TDD / ADR 中完成，除非直接影響產品要求。

---

17. Screen / System States

每個關鍵畫面或系統模組都必須檢查以下狀態。

不適用者標記 N/A 並說明原因，不得為填表而虛構。

狀態檢查清單

• Empty
• Loading
• Normal
• Success
• Error
• Boundary / Special
• Permission Denied
• Offline / Disconnected
• Stale Data
• Partial Data
• Disabled
• Read-only

狀態表

| State | Applicable | UI / System Specification | Entry Condition | Exit / Transition | API / Event | User Message | Recovery | |-------|------------|---------------------------|-----------------|-------------------|-------------|--------------|----------| | Empty | Yes / N/A | | | | | | | | Loading | Yes / N/A | | | | | | | | Normal | Yes / N/A | | | | | | | | Success | Yes / N/A | | | | | | | | Error | Yes / N/A | | | | | | | | Boundary | Yes / N/A | | | | | | |

錯誤處理原則

PRD 應定義：

• 使用者看到什麼
• 是否可重試
• 是否阻塞流程
• 是否需人工介入
• 是否保留已完成資料
• 是否需通知客服或 Ops
• 最大可接受等待時間
• 降級後的產品行為

技術性重試演算法、Backoff 係數與基礎設施策略，原則上由 Engineering 決定。

若產品有明確 SLA，PRD 可規定：

系統應自動嘗試恢復連線。
30 秒內未恢復時，顯示資料可能延遲的提示。
超過 2 分鐘仍無法恢復時，提供重新整理與聯絡客服入口。

---

18. Data & Integration Requirements

Data Requirements

| Field | Source | Type | Required | Validation | Precision | Retention | PII | |-------|--------|------|----------|------------|-----------|-----------|-----| | | | | | | | | |

Integration Requirements

| Integration | Direction | Trigger | Request | Response | Timeout Requirement | Failure Behavior | Owner | |-------------|-----------|---------|---------|----------|---------------------|------------------|-------| | | | | | | | | |

必須考慮

• Source of Truth
• Data Freshness
• Event Ordering
• Idempotency
• Duplicate Events
• Schema Versioning
• Backward Compatibility
• Data Retention
• Data Deletion
• PII / Sensitive Data
• Audit Trail

---

19. Non-functional Requirements

NFR 必須可測量，不可只寫「要快」、「要穩」、「要安全」。

標準分類

| Category | Requirement | Metric / Threshold | Measurement Method | Priority | |----------|-------------|--------------------|--------------------|----------| | Performance | | | | | | Availability | | | | | | Reliability | | | | | | Security | | | | | | Privacy | | | | | | Compliance | | | | | | Scalability | | | | | | Observability | | | | | | Accessibility | | | | | | Compatibility | | | | | | Recovery | | | | |

例子

- Dashboard 關鍵數據在正常網路條件下 P95 載入時間 ≤ 2 秒。
- 核心交易狀態資料延遲不得超過 1 秒。
- 所有高風險操作必須寫入不可修改的 Audit Log。
- 權限變更後，最晚 60 秒內套用至所有有效 Session。
- 系統故障後，RTO ≤ 30 分鐘，RPO ≤ 5 分鐘。

注意

NFR 數值若未確認，標記為 TBD，並指定 Owner，不得由 AI 自行捏造。

---

20. Analytics & Observability

Product Analytics

| Event Name | Trigger | Properties | User ID | Purpose | Data Owner | |------------|---------|------------|---------|---------|------------| | | | | | | |

Observability

| Signal | Condition | Severity | Alert Channel | Owner | Runbook | |--------|-----------|----------|---------------|-------|---------| | | | | | | |

必須考慮

• Funnel
• Conversion
• Drop-off
• Feature Adoption
• Error Events
• API Failure Rate
• Latency
• Queue Lag
• Data Freshness
• Business Rule Trigger
• Fraud / Risk Signal
• Support Escalation

---

21. Risk & Mitigation

| Risk | Type | Probability | Impact | Mitigation | Contingency | Owner | |------|------|-------------|--------|------------|-------------|-------| | | Product / Technical / Legal / Ops / Security / Vendor | | | | | |

高風險產品特別注意

• 資金損失
• 法規違反
• 權限濫用
• 資料洩漏
• 錯誤計價
• 重複扣款
• 無法回滾
• 第三方不可用
• 人工處理量暴增

---

22. Rollout / Migration / Rollback

Rollout Plan

| Phase | Audience | Percentage | Entry Criteria | Monitoring | Exit Criteria | |-------|----------|------------|----------------|------------|---------------| | Internal | | | | | | | Beta | | | | | | | Limited Release | | | | | | | General Availability | | | | | |

Migration

需定義：

• Existing User 處理方式
• 舊資料回填
• Schema 轉換
• Default Value
• 雙寫或資料同步
• 相容期
• Feature Flag
• 通知策略

Rollback

需定義：

• Rollback Trigger
• Decision Owner
• 回退方式
• 資料處理方式
• 已完成交易或操作如何處理
• 回退後使用者體驗
• 通知與客服腳本
• Postmortem 要求

---

23. Roadmap 與 Complexity Assumption

PRD 正文中不要寫 PM 單方面估算的人天。

建議格式

使用「Initial Complexity Assumption」，並明確標註：

此為 Product 對產品邏輯、依賴與風險的初步複雜度判斷。
最終技術複雜度與工時由 Engineering Refinement 確認。

多維度評估

| Dimension | Low | Medium | High | |-----------|-----|--------|------| | Product Logic | 單一路徑、少量規則 | 多狀態、多分支 | 跨模組、複雜規則、狀態機 | | Integration | 無外部依賴 | 1–2 個穩定整合 | 多系統、第三方或未知限制 | | Data | 低資料量、單一來源 | 中等資料量、同步需求 | 高資料量、一致性、遷移 | | Operational Risk | 低風險、易回復 | 需監控與人工介入 | 資金、法規、安全或不可逆 | | Delivery Dependency | 可獨立完成 | 依賴 1–2 團隊 | 多團隊、外部 Vendor、法遵 |

Roadmap

| Phase | Scope | Product Complexity | Key Dependency | Exit Criteria | |-------|-------|--------------------|----------------|---------------| | MVP | | Low / Medium / High | | | | Phase 2 | | Low / Medium / High | | | | Phase 3 | | Low / Medium / High | | |

---

24. UAT & Release Readiness

UAT

| UAT ID | Scenario | Preconditions | Expected Result | Owner | Status | |--------|----------|---------------|-----------------|-------|--------| | | | | | | |

Release Readiness Checklist

• [ ] 所有 Must-have AC 已通過
• [ ] P0 / P1 缺陷已關閉或有正式 Waiver
• [ ] 權限矩陣已驗證
• [ ] 關鍵 NFR 已測試
• [ ] Analytics Events 已驗證
• [ ] Monitoring 與 Alert 已建立
• [ ] Runbook 已完成
• [ ] Rollback 已演練或確認
• [ ] 客服 / Ops 已取得處理文件
• [ ] Compliance / Security Review 已完成
• [ ] Feature Flag 已確認
• [ ] Release Owner 已指定

---

25. 撰寫流程

Step 1：理解問題，不直接跳到解法

先確認：

• 產品或功能解決什麼問題？
• 目標使用者是誰？
• 使用情境是什麼？
• 商業價值是什麼？
• 現有流程有什麼問題？
• 有哪些已知限制？
• 有哪些法規、安全、資金或資料風險？

Step 2：釐清交付與讀者

確認：

• 誰會讀這份文件？
• 本期預計交付什麼？
• 是否分期？
• 是否已有設計、API、TDD、Research 或競品資料？
• 是否有固定模板或公司格式？

Step 3：建立骨架

先產出：

• 目錄
• Scope
• Assumptions
• Open Questions
• Dependencies
• 主要功能清單

若需求已足夠明確，可直接完成完整 PRD，不必強制等待使用者逐步確認。

Step 4：填寫 Functional Requirements

每個功能都要包含：

• 功能描述
• 商業規則
• AC
• Edge Cases
• Out of Scope
• 相關角色與權限
• 相關狀態

Step 5：補齊 Flow 與 State

建立：

• User Flow
• Alternate Flow

-

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: skinnerlee1225
• Source: skinnerlee1225/enterprise-prd-toolkit
• License: MIT
• Homepage: https://skinnerlee1225.github.io/enterprise-prd-toolkit/

Install and usage instructions live in the source repository linked above.