4.1 KiB

Raw Blame History

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 文件（或使用者指定的路徑）。

若使用者沒有指定路徑：

先檢查 docs/prd/ 目錄下最新的 PRD 文件
若有多個，列出讓使用者選擇

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 參考，先讀取再做任何分析

4.1 KiB Raw Blame History Unescape Escape