120 lines
4.1 KiB
Markdown
120 lines
4.1 KiB
Markdown
|
---
|
|||
|
|
description: 讀取現有 PRD 文件，針對指定部分進行深化、修改或補充。支援局部改寫與全文增強。
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# /pm-edit — PRD 編輯與深化指令
|
|||
|
|
|
|||
|
|
這個指令讓你針對**已存在的 PRD**進行修改、補充或深化，不需要重跑完整的多 agent 流程。
|
|||
|
|
|
|||
|
|
## 使用方式
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
/pm-edit [PRD路徑或直接在編輯器中開啟] [編輯指令]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 常見使用情境
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
# 深化功能規格（最常用）
|
|||
|
|
/pm-edit 目前 PRD 的功能規格太少，幫我把 Must Have 功能從 3 個擴充到至少 10 個
|
|||
|
|
|
|||
|
|
# 補充競品體驗分析
|
|||
|
|
/pm-edit 競品分析只有功能比較，幫我加入完整的 UX 體驗評估（Onboarding、情緒曲線等）
|
|||
|
|
|
|||
|
|
# 加入 EARS 驗收標準
|
|||
|
|
/pm-edit 把所有功能的驗收標準改為 EARS 格式，並加入錯誤處理表格
|
|||
|
|
|
|||
|
|
# 參考競品網站重寫定位
|
|||
|
|
/pm-edit 參考：https://notion.so 和 https://coda.io ，重新分析我們的差異化定位
|
|||
|
|
|
|||
|
|
# 更新 Roadmap
|
|||
|
|
/pm-edit 把 Phase 1 的時程從 3 個月改成 6 個月，重新估算功能範圍
|
|||
|
|
|
|||
|
|
# 補充用戶洞察
|
|||
|
|
/pm-edit 用戶 Persona 太薄弱，幫我深化為 3 個完整 Persona，每個都要有 JTBD 三層分析
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 工作流程
|
|||
|
|
|
|||
|
|
### Step 1：讀取現有 PRD
|
|||
|
|
使用 `Read` tool 讀取當前開啟的 PRD 文件（或使用者指定的路徑）。
|
|||
|
|
|
|||
|
|
若使用者沒有指定路徑：
|
|||
|
|
1. 先檢查 `docs/prd/` 目錄下最新的 PRD 文件
|
|||
|
|
2. 若有多個，列出讓使用者選擇
|
|||
|
|
|
|||
|
|
### Step 2：理解編輯意圖
|
|||
|
|
分析使用者的編輯指令，判斷需要：
|
|||
|
|
|
|||
|
|
| 編輯類型 | 需要的 Agent | 處理方式 |
|
|||
|
|
|---------|------------|---------|
|
|||
|
|
| 深化功能規格 | Prioritization Planner + PRD Writer | 重新規劃並局部重寫 |
|
|||
|
|
| 補充競品分析 | Competitor Analyst | 呼叫 sub-agent 補充後合併 |
|
|||
|
|
| 深化用戶洞察 | User Insight Researcher | 重新搜尋並更新 Persona |
|
|||
|
|
| 格式轉換（改 EARS） | PRD Writer | 直接轉換格式 |
|
|||
|
|
| 參考 URL 更新 | 對應 Agent + PRD Writer | 讀取 URL 後針對性更新 |
|
|||
|
|
| 風險評估更新 | 直接推理 | 不需要呼叫 sub-agent |
|
|||
|
|
|
|||
|
|
### Step 3：若提供 URL 參考
|
|||
|
|
若使用者在指令中包含 `參考：https://...`：
|
|||
|
|
- 使用 `Read` tool 讀取該 URL（競品網站、文章、既有文件）
|
|||
|
|
- 將讀取到的關鍵資訊摘要，傳遞給對應的 sub-agent
|
|||
|
|
|
|||
|
|
### Step 4：執行局部更新
|
|||
|
|
**只更新受影響的章節**，不重寫整份 PRD。
|
|||
|
|
|
|||
|
|
更新原則：
|
|||
|
|
- 保留原有 PRD 中已有的好內容
|
|||
|
|
- 在指定章節進行深化或修改
|
|||
|
|
- 新增章節時插入適當位置
|
|||
|
|
- 確保整份文件風格與格式一致
|
|||
|
|
|
|||
|
|
### Step 5：儲存更新版本
|
|||
|
|
使用 `Write` tool：
|
|||
|
|
- 儲存為新版本：`docs/prd/[原檔名]-v2.md`（或 v3、v4...）
|
|||
|
|
- 在文件末尾的「變更記錄」表格中加入此次修改說明
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 常用快捷編輯指令
|
|||
|
|
|
|||
|
|
### 功能深化
|
|||
|
|
```
|
|||
|
|
/pm-edit 把所有功能的驗收標準改為 EARS 格式表格，並補充錯誤處理
|
|||
|
|
```
|
|||
|
|
→ PRD Writer 直接轉換現有功能規格格式
|
|||
|
|
|
|||
|
|
### 競品補充
|
|||
|
|
```
|
|||
|
|
/pm-edit 幫我補充 [競品名] 的完整使用體驗分析，包含 Onboarding 和情緒曲線
|
|||
|
|
```
|
|||
|
|
→ Competitor Analyst 針對指定競品深化分析
|
|||
|
|
|
|||
|
|
### 功能擴充
|
|||
|
|
```
|
|||
|
|
/pm-edit Must Have 功能只有 [N] 個，幫我至少擴充到 10 個，優先考慮 [方向] 相關的功能
|
|||
|
|
```
|
|||
|
|
→ Prioritization Planner 重新規劃，PRD Writer 補充功能規格
|
|||
|
|
|
|||
|
|
### 參考競品重新定位
|
|||
|
|
```
|
|||
|
|
/pm-edit 參考：https://[競品URL] 重新分析我們的差異化定位並更新第 2 節
|
|||
|
|
```
|
|||
|
|
→ 讀取 URL → Competitor Analyst 更新 → PRD Writer 更新第 2 節
|
|||
|
|
|
|||
|
|
### 格式對齊
|
|||
|
|
```
|
|||
|
|
/pm-edit 把使用者故事改為標準格式 "AS a..., I WANT to..., SO THAT..."
|
|||
|
|
```
|
|||
|
|
→ PRD Writer 直接格式化，不需要呼叫其他 agent
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 重要原則
|
|||
|
|
|
|||
|
|
- **局部更新優先**：不要因為一個小改動就重寫整份 PRD
|
|||
|
|
- **版本保留**：每次修改都存為新版本（v2, v3...），不覆蓋原版
|
|||
|
|
- **說明改了什麼**：在「變更記錄」中清楚記錄本次修改範圍
|
|||
|
|
- **保持一致性**：新增的內容要與原有文件的語氣、格式、詳細程度一致
|
|||
|
|
- **URL 優先讀取**：若使用者提供了 URL 參考，先讀取再做任何分析
|