階段 2：PRD - 產生產品需求文件

PRD 階段是 Agent App Factory 管線的第二個階段，負責將 input/idea.md 轉化為完整的、面向 MVP（最小可行產品）的產品需求文件。這個階段將明確目標使用者、核心功能、MVP 範圍和非目標，為後續的 UI 設計和技術架構提供清晰的指引。

學完你能做什麼

將 input/idea.md 轉化為符合標準範本的 artifacts/prd/prd.md 文件
理解 PRD Agent 的職責邊界（只定義需求，不涉及技術實作）
掌握 MoSCoW 功能優先順序框架，確保 MVP 聚焦核心價值
能夠撰寫高品質的使用者故事和可驗證的驗收標準
知道哪些內容應該在 PRD 中，哪些應該在後續階段

你現在的困境

你可能有一個清晰的產品想法（Bootstrap 階段已完成），但在轉化為需求文件時遇到困難：

"不知道應該包含哪些功能，擔心遺漏或過度設計"
"功能很多，但不知道哪些是 MVP 必需的"
"使用者故事寫得不清楚，開發團隊無法理解"
"不小心把技術實作細節混入需求，導致範圍蔓延"

這種不清晰的 PRD 會導致後續 UI 設計和程式碼開發缺乏明確指引，最終產生的應用程式可能偏離你的預期或包含不必要的複雜度。

什麼時候用這一招

當 Bootstrap 階段完成，並且滿足以下條件時：

已完成 idea.md 結構化（Bootstrap 階段輸出）
還沒開始 UI 設計或技術架構（這些在後續階段）
希望明確 MVP 範圍（避免功能過度設計）
需要為開發和設計提供清晰指引（使用者故事、驗收標準）

🎒 開始前的準備

前置條件

在開始 PRD 階段前，請確保：

✅ 已完成專案初始化
✅ 已了解 7 階段管線概覽
✅ 已完成 Bootstrap 階段，產生了 input/idea.md
✅ 已安裝並設定好 AI 助手（推薦 Claude Code）

核心思路

什麼是 PRD 階段？

PRD（Product Requirements Document，產品需求文件）階段的核心職責是定義要做什麼，而不是怎麼做。

不是技術文件

PRD Agent 不是架構師或 UI 設計師，它不會替你決定：

❌ 使用什麼技術堆疊（React vs Vue，Express vs Koa）
❌ 資料庫如何設計（表結構、索引）
❌ UI 佈局和互動細節（按鈕位置、顏色方案）

它的任務是：

✅ 定義目標使用者和他们的痛點
✅ 列出核心功能和優先順序
✅ 明確 MVP 範圍和非目標
✅ 提供可測試的使用者故事和驗收標準

為什麼要 PRD？

想像一下，你告訴施工隊："我想蓋個房子"

❌ 沒有圖紙：施工隊只能猜測，可能建成你完全不想住的房子
✅ 有詳細圖紙：明確房間數量、功能佈局、材料要求，施工隊按圖施工

PRD 階段就是把"我想蓋個房子"變成"三室兩廳、主臥朝南、開放式廚房"的詳細圖紙。

MoSCoW 功能優先順序框架

PRD 階段使用 MoSCoW 框架對功能進行分類，確保 MVP 聚焦在核心價值上：

分類	定義	判斷標準	範例
Must Have	MVP 絕對不能缺少的功能	沒有它產品無法交付核心價值	記帳應用程式：新增支出記錄、查看支出清單
Should Have	重要但非阻塞的功能	使用者會明顯感受到缺失，但可以暫時用變通方案	記帳應用程式：匯出報表、分類統計
Could Have	錦上添花的功能	不影響核心體驗，使用者不會特別注意到缺失	記帳應用程式：預算提醒、多幣種支援
Won't Have	明確排除的功能	與核心價值無關或技術複雜度高	記帳應用程式：社交分享、投資建議

MVP 核心

Must Have 功能應該控制在 5-7 個以內，確保 MVP 聚焦核心價值，避免範圍蔓延。

跟我操作

第 1 步：確認 Bootstrap 階段已完成

在開始 PRD 階段前，確保 input/idea.md 已存在且內容符合標準。

bash

# 檢查 idea.md 是否存在
cat input/idea.md

你應該看到：包含簡要描述、問題、目標使用者、核心價值、假設、非目標等章節的結構化文件。

如果 idea.md 不符合標準

返回 Bootstrap 階段重新產生，或者手動編輯補充資訊。

第 2 步：啟動管線到 PRD 階段

在 Factory 專案目錄中執行：

bash

# 如果管線已經啟動，繼續到 PRD 階段
factory run prd

# 或從頭啟動管線
factory run

CLI 會顯示當前狀態和可用階段，並產生 PRD Agent 的助手指令。

第 3 步：AI 助手讀取 PRD Agent 定義

AI 助手（如 Claude Code）會自動讀取 agents/prd.agent.md，了解其職責和限制。

PRD Agent 職責

PRD Agent 只能：

讀取 input/idea.md
寫入 artifacts/prd/prd.md
使用 skills/prd/skill.md 中的思維框架和決策原則

它不能：

討論任何技術實作細節或 UI 設計
讀取其他檔案（包括 upstream 產物）
寫入其他目錄

第 4 步：載入 skills/prd/skill.md

PRD Agent 會載入 skills/prd/skill.md，獲取以下指導：

思維框架：

目標使用者：誰會使用？背景、角色、痛點是什麼？
核心問題：產品要解決什麼根本問題？
核心價值：為什麼這個方案有價值？和競品相比優勢在哪裡？
成功指標：如何衡量成功？

MoSCoW 功能優先順序：

Must Have（必須有）：MVP 絕對不能缺少的功能
Should Have（應該有）：重要但非阻塞的功能
Could Have（可以有）：錦上添花的功能
Won't Have（不會有）：明確排除的功能

使用者故事編寫指南：

作為 [角色/使用者類型]
我想要 [功能/操作]
以便 [業務價值/目標]

PRD 文件結構要求（8 個章節）：

概述
目標使用者畫像
核心價值主張
功能需求（MoSCoW 分類）
使用者流程
非目標（Won't Have）
成功指標
假設和風險

第 5 步：產生 PRD 文件

AI 助手會根據 input/idea.md 的內容，使用技能中的思維框架和決策原則，產生完整的 PRD 文件。

PRD Agent 會做什麼：

閱讀 input/idea.md，提煉關鍵元素（目標使用者、問題、核心價值等）
按照 MoSCoW 框架對功能進行分類
為 Must Have 功能撰寫使用者故事和驗收標準
列出非目標，防止範圍蔓延
給出可量化的成功指標
將整理好的文件寫入 artifacts/prd/prd.md

關鍵限制

PRD Agent 禁止討論技術實作細節或 UI 設計。如果發現這些內容，PRD Agent 會拒絕寫入。

第 6 步：確認 prd.md 內容

PRD Agent 完成後，會產生 artifacts/prd/prd.md。你需要仔細檢查：

檢查點 ✅：

目標使用者是否具體？
- ✅ 有具體畫像（年齡/職業/技術能力/使用場景/痛點）
- ❌ 模糊："所有人"或"需要記帳的人"
核心問題是否清晰？
- ✅ 描述了使用者在現實場景下遇到的難題
- ❌ 空泛："使用者體驗不好"
核心價值是否可量化？
- ✅ 有具體收益（節省 80% 時間、提升 50% 效率）
- ❌ 空泛："提升效率"、"更好的體驗"
Must Have 功能是否聚焦？
- ✅ 不超過 5-7 個核心功能
- ❌ 功能過多或包含次要功能
每個 Must Have 功能是否有使用者故事？
- ✅ 使用標準格式（作為...我想要...以便...）
- ❌ 缺失使用者故事或格式不正確
驗收標準是否可驗證？
- ✅ 有具體可驗證的標準（可以輸入金額、顯示在清單中）
- ❌ 模糊（"使用者友好"、"體驗流暢"）
Should Have和Won't Have是否明確列出？
- ✅ Should Have 標註為"未來迭代"並說明原因
- ✅ Won't Have 說明為什麼排除
- ❌ 缺失或太少
成功指標是否可量化？
- ✅ 有具體數值（使用者留存率 > 30%、任務完成時間 < 30 秒）
- ❌ 模糊（"使用者喜歡"、"體驗好"）
假設是否可驗證？
- ✅ 可透過使用者調研驗證
- ❌ 主觀判斷（"使用者會喜歡"）
是否包含技術實作細節或 UI 設計？
- ✅ 無技術細節和 UI 描述
- ❌ 包含技術堆疊選擇、資料庫設計、UI 佈局等

第 7 步：選擇繼續、重試或暫停

確認無誤後，CLI 會顯示選項：

bash

請選擇操作：
[1] 繼續（進入 UI 階段）
[2] 重試（重新產生 prd.md）
[3] 暫停（稍後繼續）

建議先在程式碼編輯器中查看

在 AI 助手中確認前，先用程式碼編輯器打開 artifacts/prd/prd.md，逐字檢查。一旦進入 UI 階段，修改成本會更高。

踩坑提醒

坑 1：Must Have 功能過多

錯誤範例：

Must Have:
1. 新增支出記錄
2. 查看支出清單
3. 匯出報表
4. 分類統計
5. 預算提醒
6. 多幣種支援
7. 社交分享
8. 投資建議

後果：MVP 範圍過大，開發週期長，風險高。

建議：控制在 5-7 個核心功能：

Must Have:
1. 新增支出記錄
2. 查看支出清單
3. 選擇支出類別

Should Have（未來迭代）:
4. 匯出報表
5. 分類統計

Won't Have（明確排除）:
6. 社交分享（與核心價值無關）
7. 投資建議（需要專業資質，技術複雜度高）

坑 2：使用者故事缺失或格式不正確

錯誤範例：

功能：新增支出記錄
描述：使用者可以新增支出記錄

後果：開發團隊不清楚要為誰做、解決什麼問題。

建議：使用標準格式：

功能：新增支出記錄
使用者故事：作為一個預算意識強的使用者
我想要記錄每一筆支出
以便了解我的消費去向和控制預算

驗收標準：
- 可以輸入支出金額和描述
- 可以選擇支出類別
- 記錄立即顯示在支出清單中
- 顯示當前日期和時間

坑 3：驗收標準不可驗證

錯誤範例：

驗收標準：
- 使用者介面友好
- 操作流暢
- 體驗良好

後果：無法測試，開發團隊不知道什麼算"友好"、"流暢"、"良好"。

建議：寫具體可驗證的標準：

驗收標準：
- 可以輸入支出金額和描述
- 可以從 10 個預設類別中選擇
- 記錄在 1 秒內顯示在支出清單中
- 自動記錄當前日期和時間

坑 4：目標使用者描述太泛

錯誤範例：

目標使用者：所有需要記帳的人

後果：後續 UI 設計和技術架構無法明確方向。

建議：明確畫像：

主要使用者群體：
- 角色：18-30 歲剛工作的年輕人
- 年齡：18-30 歲
- 技術能力：中級，熟悉智慧型手機應用程式
- 使用場景：日常消費後立即記錄，月底查看統計
- 痛點：月底發現超支，但不知道錢花在哪，沒有預算控制

坑 5：非目標缺失或太少

錯誤範例：

非目標：無

後果：後續 PRD 和 Code 階段可能過度設計，增加技術複雜度。

建議：至少列出 3 項：

非目標 (Out of Scope)：
- 社交分享功能（MVP 聚焦個人記帳）
- 財務建議和投資分析（需要專業資質，超出核心價值）
- 與第三方金融系統整合（技術複雜度高，MVP 不需要）
- 複雜的資料分析和報表（Should Have，未來迭代）

坑 6：包含技術實作細節

錯誤範例：

功能：新增支出記錄
技術實作：使用 React Hook Form 管理表單，API 端點 POST /api/expenses

後果：PRD Agent 會拒絕這些內容（只定義需求，不涉及技術實作）。

建議：只說"做什麼"，不說"怎麼做"：

功能：新增支出記錄
使用者故事：作為一個預算意識強的使用者
我想要記錄每一筆支出
以便了解我的消費去向和控制預算

驗收標準：
- 可以輸入支出金額和描述
- 可以選擇支出類別
- 記錄立即顯示在支出清單中
- 顯示當前日期和時間

坑 7：成功指標不可量化

錯誤範例：

成功指標：
- 使用者喜歡我們的應用程式
- 體驗流暢
- 使用者留存高

後果：無法衡量產品是否成功。

建議：寫可量化的指標：

成功指標：
產品目標：
- 第一個月獲得 100 個活躍使用者
- 使用者每週至少使用 3 次
- 核心功能（新增支出記錄）使用率 > 80%

關鍵指標 (KPIs)：
- 使用者留存率：7 日留存 > 30%，30 日留存 > 15%
- 核心功能使用率：新增支出記錄使用率 > 80%
- 任務完成時間：新增一次支出 < 30 秒

驗證方法：
- 透過後端日誌記錄使用者行為
- 使用 A/B 測試驗證使用者留存
- 透過使用者反饋問卷收集滿意度

坑 8：假設不可驗證

錯誤範例：

假設：使用者會喜歡我們的設計

後果：無法透過使用者調研驗證，MVP 可能失敗。

建議：寫可驗證的假設：

假設：
市場假設：
- 年輕人（18-30 歲）存在"不知道錢花在哪"的痛點
- 現有記帳應用程式過於複雜，年輕人需要更簡單的解決方案

使用者行為假設：
- 使用者願意在每次消費後花費 2 分鐘記錄支出，如果能幫助控制預算
- 使用者更喜歡極簡的 UI，不需要複雜的圖表和分析

技術可行性假設：
- 行動端應用程式可以實現快速的 3 步記帳流程
- 離線儲存可以滿足基本需求

本課小結

PRD 階段的核心是定義需求，而非實作：

輸入：結構化的 input/idea.md（Bootstrap 階段輸出）
過程：AI 助手使用 skills/prd/skill.md 的思維框架和 MoSCoW 優先順序框架
輸出：完整的 artifacts/prd/prd.md 文件
驗證：檢查使用者是否明確、價值是否可量化、功能是否聚焦、是否包含技術細節

關鍵原則

❌ 不做什麼：不討論技術實作、不設計 UI 佈局、不決定資料庫結構
✅ 只做什麼：定義目標使用者、列出核心功能、明確 MVP 範圍、提供可測試的使用者故事

下一課預告

下一課我們學習 階段 3：UI - 設計介面與原型。
你會學到：
如何根據 PRD 設計 UI 結構
如何使用 ui-ux-pro-max 技能產生設計系統
如何產生可預覽的 HTML 原型
UI 階段的輸出檔案和退出條件

附錄：原始碼參考

點選展開查看原始碼位置

更新時間：2026-01-29

功能	檔案路徑	行號
PRD Agent 定義	`agents/prd.agent.md`	1-33
PRD Skill	`skills/prd/skill.md`	1-325
管線定義（PRD 階段）	`pipeline.yaml`	20-33
排程器定義	`agents/orchestrator.checkpoint.md`	1-100+

關鍵限制：

禁止技術實作細節：prd.agent.md:23
禁止 UI 設計描述：prd.agent.md:23
必須包含目標使用者：pipeline.yaml:29
必須定義 MVP 範圍：pipeline.yaml:30
必須列出非目標：pipeline.yaml:31
輸出檔案必須儲存到 artifacts/prd/prd.md：prd.agent.md:13

退出條件（pipeline.yaml:28-32）：

PRD 包含目標使用者
PRD 定義 MVP 範圍
PRD 列出非目標（Out of Scope）
PRD 不包含任何技術實作細節

Skill 內容框架：

思維框架：目標使用者、核心問題、核心價值、成功指標
MoSCoW 功能優先順序框架：Must Have、Should Have、Could Have、Won't Have
使用者故事編寫指南：標準格式和範例
PRD 文件結構要求：8 個必需章節
決策原則：以使用者為中心、關注 MVP、非目標明確、可測試性
品質檢查清單：使用者和問題、功能範圍、使用者故事、文件完整性、禁止項目檢查
不要做 (NEVER)：7 條明確禁止的行為

PRD 文件必需章節：

概述（產品概述、背景和目標）
目標使用者畫像（主要使用者群體、次要使用者群體）
核心價值主張（解決的問題、我們的方案、差異化優勢）
功能需求（Must Have、Should Have、Could Have）
使用者流程（主流程描述）
非目標（Won't Have）
成功指標（產品目標、關鍵指標、驗證方法）
假設和風險（市場假設、使用者行為假設、技術可行性假設、風險表）

階段 2：PRD - 產生產品需求文件 ​

學完你能做什麼 ​

你現在的困境 ​

什麼時候用這一招 ​

🎒 開始前的準備 ​

核心思路 ​

什麼是 PRD 階段？ ​

為什麼要 PRD？ ​

MoSCoW 功能優先順序框架 ​

跟我操作 ​

第 1 步：確認 Bootstrap 階段已完成 ​

第 2 步：啟動管線到 PRD 階段 ​

第 3 步：AI 助手讀取 PRD Agent 定義 ​

第 4 步：載入 skills/prd/skill.md ​

第 5 步：產生 PRD 文件 ​

第 6 步：確認 prd.md 內容 ​

第 7 步：選擇繼續、重試或暫停 ​

踩坑提醒 ​

坑 1：Must Have 功能過多 ​

坑 2：使用者故事缺失或格式不正確 ​

坑 3：驗收標準不可驗證 ​

坑 4：目標使用者描述太泛 ​

坑 5：非目標缺失或太少 ​

坑 6：包含技術實作細節 ​

坑 7：成功指標不可量化 ​

坑 8：假設不可驗證 ​

本課小結 ​

下一課預告 ​

附錄：原始碼參考 ​

階段 2：PRD - 產生產品需求文件

學完你能做什麼

你現在的困境

什麼時候用這一招

🎒 開始前的準備

核心思路

什麼是 PRD 階段？

為什麼要 PRD？

MoSCoW 功能優先順序框架

跟我操作

第 1 步：確認 Bootstrap 階段已完成

第 2 步：啟動管線到 PRD 階段

第 3 步：AI 助手讀取 PRD Agent 定義

第 4 步：載入 skills/prd/skill.md

第 5 步：產生 PRD 文件

第 6 步：確認 prd.md 內容

第 7 步：選擇繼續、重試或暫停

踩坑提醒

坑 1：Must Have 功能過多

坑 2：使用者故事缺失或格式不正確

坑 3：驗收標準不可驗證

坑 4：目標使用者描述太泛

坑 5：非目標缺失或太少

坑 6：包含技術實作細節

坑 7：成功指標不可量化

坑 8：假設不可驗證

本課小結

下一課預告

附錄：原始碼參考