【7】PRD 寫完不是終點——AI 幫我驗收
整理版優先睇
PRD寫完唔係終點——AI幫你逐項驗收，將完成標準變做可重複嘅流程
呢篇文章係「AI 產品經理的 AI 武器庫」系列嘅收官篇，作者 Derek 係一位 AI 產品經理，佢用 Claude Code 插件體系建立咗一套 PM 專屬嘅 AI 工作流。佢觀察到一個常見問題：PRD 寫完之後好少再被打開，開發話「做完了」但 PM 唔確定真係完成，最後上線先發現問題。佢認為根本原因唔係溝通，而係冇一個明確嘅「完成定義」。
為咗解決呢個問題，佢設計咗 `/pm:verify-feature` 呢個命令，可以將 PRD 嘅驗收清單拎出嚟，逐項對住代碼庫檢查。AI 會自動揾 PRD 文件，提取驗收標準，然後去代碼倉庫搜尋相關實現，仲會睇測試文件，最後輸出通過率同詳細結果。佢用一個「用戶註冊」功能做測試，結果通過率得 40%，明確指出邊啲未通過同點解。AI 亦識得標記「無法判定」嘅項目，唔會亂猜。
驗收完之後會自動生成報告同更新 PRD 狀態，只有 P0 全部通過先會標記為「已完成」。呢個工具令到 PM 同開發嘅對話由「感覺」變做「事實」，減少咗好多摩擦。作者強調：完成嘅定義係 PM 最重要嘅交付物之一，AI 只係執行引擎，方法論係屬於你嘅。
- 完成標準要明確，唔好靠感覺：用AI對住PRD逐項檢查代碼實現，將模糊嘅驗收變成可重複嘅流程。
- 用戶註冊功能驗收得40%通過率：AI發現郵件過期時間錯咗（24小時變1小時），跳轉邏輯冇做，密碼強度UI無法判定。
- AI識別自身侷限：對UI交互、動畫流暢度呢類驗收標準，AI會標記「無法判定」並建議人工驗證，唔會亂報結果。
- 驗收報告用業務語言：唔容許出現函數名或技術路徑，報告包含驗收總覽、每條詳細結果、未通過說明同遺留項。
- PRD狀態自動流轉：只有P0全部通過先由「待驗收」變「已完成」；P0有未通過就保持原狀，確保核心功能達標先叫完成。
內容片段
/pm:feature-flow（第 2 篇） → 從模糊想法到結構化 PRD/pm:plan-iteration（第 6 篇） → PRD 排入迭代，確定優先級prd-dev 工作流 → 開發基於 PRD 做 SDD + TDD/pm:verify-feature（本篇） → 對照 PRD 逐項驗收，生成報告PRD 狀態自動流轉 → 待設計 → 設計中 → 待開發 → 開發中 → 已完成PRD寫完就封塵？問題在「完成標準」從未被確立
作者有一個叫「PRD 歸檔」嘅文件夾，裏面有幾十份文檔，絕大多數寫完之後就再冇被打開過。佢話呢個係 PM 工作裏面最諷刺嘅事之一：你花好多時間將需求諗清楚、寫清楚，然後發出去，然後就冇咗下文。
問題唔係開發冇睇PRD，而係從來冇一個明確嘅「完成嘅定義」
以前作者覺得係溝通問題，但後來佢意識到更根本嘅原因：PRD 寫咗二十個驗收標準，但呢二十條由邊個對？點樣對？對完結果記錄喺邊？開發話「做完了」係憑感覺，PM 話「未做完」都係憑感覺，兩個感覺碰埋一齊就變成扯皮。
/pm:verify-feature 點樣將驗收變成可重複嘅動作
第七個命令 `/pm:verify-feature`，佢做嘅事好直接：將 PRD 嘅驗收清單拎出嚟，對住代碼庫逐項檢查。唔係人工翻代碼，而係 AI 真係去讀代碼，根據每一條驗收標準判斷有冇對應嘅實現。
一次完整嘅驗收：先用 /pm:verify-feature 用戶註冊
- 1 第一步：AI 自動喺 docs/prd/ 下搜索匹配嘅 PRD 文件，提取需求清單同驗收標準。呢步有個隱藏好處——連你自己都可能唔記得 PRD 擺喺邊。
- 2 第二步：逐項去代碼庫揾。AI 從每條驗收標準提取關鍵業務概念，用呢啲概念搜相關文件，讀具體邏輯，判斷覆蓋程度，仲會睇測試文件。
- 3 第三步：輸出結果。AI 會畀出通過率同詳細分析，例如「用戶註冊功能通過率：2/5（40%）」。
結果出咗之後，對話就唔同曬。以前係「你睇嚇驗收情況」「我覺得差不多了」「呢幾個地方點解？」而家變咗「F-003 過期時間代碼係幾多？」「應該係一個鐘，當時冇注意。」「改返 24 個鐘，F-004 跳轉邏輯加上，fix 咗再畀我睇。」
從「感覺」嘅對話變成「事實」嘅對話
驗收報告自動生成，PRD 狀態穩健流轉
跑完驗收之後有兩件事會自動發生。第一係生成驗收報告，放喺 PRD 同一個目錄下。報告包括驗收總覽、每條詳細結果、未通過項嘅具體說明、同埋需要人工驗證嘅項目。
報告用業務語言，唔容許出現函數名、變數名、技術路徑
第二係更新 PRD 狀態。設計得好穩健：得 P0 全部通過先會由「待驗收」變「已完成」；如果 P0 全過但 P1/P2 有遺漏，會標記為「已完成，含遺留項」；如果 P0 有任何未通過，狀態保持不變。呢個邏輯保守但啱，核心功能冇做好就唔可以話完。
系列收官：AI 係執行引擎，方法論係你嘅
呢個系列第七篇係最後一篇，回顧內容包括：將模糊功能想法變成結構化 PRD、設計用戶研究、拆穿客戶「功能好簡單」背後嘅複雜度、Bug 嚟咗 PM 可以點做、Sprint Planning 合理性檢查、同埋 PRD 驗收閉環。呢六個場景都係作者日常工作最易卡殼、最易靠感覺判斷嘅地方。
唔係叫 AI 取代 PM，而係將 PM 嘅方法論固化到 AI 插件裏面
你知道做需求要先問「邊個用」，你知道驗收標準要用業務語言寫，你知道 P0 冇過唔叫完成——呢啲判斷力係你嘅，唔係 AI 嘅。AI 做嘅係將呢啲判斷喺每次工作中系統執行一次，唔遺漏、唔靠心情。
- 完成嘅定義係 PM 最重要嘅交付物之一，驗收標準越具體，摩擦越少。
- 驗收報告要用業務語言，唔好用技術語言。
- AI 知道自己嘅邊界，標記「無法判定」比亂猜有用。
我有一個文件夾，叫做「PRD 歸檔」。
裏面有幾十份文件。絕大多數由寫完嗰日起，就冇再俾人開過。
呢樣係 PM 工作裏面最諷刺嘅其中一件事：你花咗好多時間將需求諗清楚、寫清楚，然後發出去，然後就冇咗件事。
開發做曬，話「做曬」。你心裏面其實唔確定「做曬」係乜嘢意思，但又冇一個好方法去核對，就話「好，我睇嚇」。然後打開產品點一點，覺得差唔多，就算過咗關。
然後上線，然後出咗問題，然後摷返 PRD 出嚟一睇——哦，呢度有一條驗收標準，當時冇對上。
呢個循環我經歷過唔知幾多次。
問題唔喺開發，而係「完成標準」從來冇俾人清楚確立過
我以前以為係溝通問題。開發冇仔細睇 PRD，或者 PM 冇跟進到位。
但後來我意識到，更根本嘅問題係：從來冇一個明確嘅「完成嘅定義」。
PRD 寫咗二十個驗收標準，但呢二十條邊個對？點對？對完嘅結果記錄喺邊？
開發話「做曬」，係憑感覺，係「功能行得鬱」。PM 話「未做完」，都係憑感覺，係「我㩒到某個地方覺得唔妥」。
兩個感覺撞埋一齊，就變成咗拗數。
呢個唔係任何一個人嘅問題。係件事本身缺少一個有約束力嘅流程。
我想要嘅，係將驗收呢件事變成一個可以重複嘅動作
第七個命令：/pm:verify-feature。
佢做嘅嘢講出嚟好直接：將 PRD 裏面嘅驗收清單拎出嚟，對住代碼庫逐項檢查。
唔係人手睇代碼，係 AI 真係去讀代碼，根據每一條驗收標準，判斷有冇對應嘅實現。
我第一次用嘅時候，係攞之前嗰個「用戶註冊」功能嚟試。嗰個係用 /pm:feature-flow 生成嘅 PRD，開發話我做曬，正好攞嚟驗嚇。
一次完整嘅驗收係點樣
打咗呢行命令：
/pm:verify-feature 用戶註冊
然後分咗幾步行曬。
第一步：AI 先揾到 PRD。
佢自動喺 docs/prd/ 下面搜尋匹配嘅檔案，揾到咗嗰份用戶註冊嘅 PRD，提取咗裏面嘅需求清單同驗收標準。
呢一步睇落好普通，但對我嚟講有個隱藏嘅好處——我自己都記唔起 PRD 放咗喺邊。
第二步：逐項去代碼庫裏面揾。
AI 開始讀代碼。
佢嘅做法係咁：先由每一條驗收標準裏面提取關鍵嘅業務概念，然後用呢啲概念喺代碼倉庫裏面搜尋相關嘅檔案，再去讀嗰啲檔案裏面嘅具體邏輯，判斷覆蓋程度。
同時仲會睇測試檔案——有冇對應嘅測試用例，都係覆蓋程度嘅一個證據。
呢個過程要幾分鐘，我就在旁邊等。
第三步：輸出結果。
結果出咗嚟：
驗收結果：用戶註冊功能
通過率：2/5（40%）
我望住呢個表睇咗一陣。
F-003 嘅問題我其實隱約覺得有古怪，但講唔清楚出咗喺邊。而家清楚曬：電郵可以發到，但過期時間唔啱，PRD 寫嘅係 24 小時，代碼裏面唔係。
F-004 直接唔通過。呢條我喺驗收嘅時候冇 click 到嗰個場景，實際情況係跳轉邏輯冇做到。
F-005 係「無法判定」。AI 嘅講法係：密碼強度嘅 UI 提示要實際操作先可以驗證，淨係睇代碼睇唔出。
呢四個字我覺得設計得幾好——「無法判定」。
AI 冇亂估，冇亂寫一個「通過」或者「唔通過」，而係老實話「呢個我睇唔出，建議人手驗證」。呢個比亂噏有用好多。
結果出咗之後，對話就變咗
以前嘅對話係咁：
「你睇嚇驗收情況。」
「我覺得差唔多啦。」
「咁呢幾個地方點解會咁？」
「邊幾個地方？」
而家嘅對話係咁：
「F-003 嘅過期時間，代碼裏面而家係幾多？」
「應該係一個鐘，當時冇留意。」
「咁改做 24 個鐘，F-004 嘅跳轉邏輯加上呢兩個 fix 咗先畀我睇。」
由「感覺」嘅對話，變咗做「事實」嘅對話。
呢個唔係 AI 幫我做判斷，係 AI 幫我將判斷嘅依據由模糊變成具體。
驗收結果會自動生成報告同更新 PRD 狀態
跑完驗收，仲有兩件事會自動發生。
第一係生成驗收報告。
報告保存喺 PRD 同一個目錄下面，包含：驗收總覽（驗收咗啲乜、整體結論係乜）、每一條嘅詳細結果、未通過項嘅具體說明（PRD 要求係乜、當前狀態係乜、缺少啲乜、建議點處理）、仲有需要人手驗證嗰啲項。
呢份報告係有用嘅。唔止係「驗收記錄」，更重要係，下次回溯嘅時候可以知道當時呢個功能係以乜嘢狀態交付。
第二係更新 PRD 狀態。
呢度有一個邏輯我自己都覺得設計得幾穩陣：
只有 P0 驗收全部通過，PRD 狀態先會由「待驗收」變成「已完成」。如果 P0 全部過關但 P1/P2 有遺漏，會標記為「已完成，含遺留項」。如果 P0 有任何未通過，PRD 狀態保持不變，唔會更新。
P0 係核心功能，P1、P2 係增強項。核心未做好，就唔可以話做完。
呢個邏輯保守，但係啱嘅。
由 PRD 到驗收，呢條鏈而家通咗
將成個系列串埋一齊，呢條鏈大概係咁樣：
/pm:feature-flow（第 2 篇）
→ 從模糊想法到結構化 PRD
/pm:plan-iteration（第 6 篇）
→ PRD 排入迭代，確定優先級
prd-dev 工作流
→ 開發基於 PRD 做 SDD + TDD
/pm:verify-feature（本篇）
→ 對照 PRD 逐項驗收，生成報告
PRD 狀態自動流轉
→ 待設計 → 設計中 → 待開發 → 開發中 → 已完成
PRD 唔再係「寫完就掉入文件夾」嘅文件，佢係成條鏈上面嘅主線。每個環節都引用佢、更新佢。
呢個就係我想要嘅「活文件」。唔係一個靚嘅模板，而係一個喺成個需求生命週期裏面真係用得着嘅嘢。
驗收呢件事，三個理解幫咗我
第一個：完成嘅定義，係 PM 最重要嘅交付物之一。
唔係代碼，唔係設計稿，係「點樣算做完」。
呢句聽落好似廢話，但好多項目嘅問題就出喺呢度——「做曬」係一個所有人都理解唔一樣嘅概念，但從來冇人將呢個概念寫清楚過。
驗收標準寫得越具體，開發同 PM 之間嘅摩擦就越少。唔係因為大家變好咗，係因為「事實」取代咗「感覺」。
第二個：驗收報告要用業務語言，唔好用技術語言。
「F-003 未通過：電郵驗證連結過期時間未按 PRD 要求嘅 24 小時設定。」
唔係：「validateEmail 函數嘅 expiry 參數唔符合預期值。」
前者係問題，後者係代碼。我需要知道嘅係前者，然後將前者交畀開發解決後者。
呢點我喺設計插件嘅時候專門強調過，唔準驗收報告裏面出現函數名、變量名、技術路徑。
第三個：靜態代碼分析有侷限性，AI 應該知道自己嘅邊界喺邊度。
有啲嘢睇代碼睇唔出。UI 嘅交互細節、動畫係咪流暢、表單校驗嘅時機係咪合理、頁面喺唔同設備上嘅顯示效果——呢啲都唔係代碼分析可以覆蓋到嘅。
AI 對呢類驗收標準嘅判定係「無法判定」，然後建議人手測試。
呢個比亂噏一個結果有用。工具知道自己做得啲乜、做唔到啲乜，呢樣本身就係設計質量嘅體現。
系列收官，講幾句說話
呢篇係呢個系列嘅第七篇，亦都係最後一篇。
回頭睇呢七篇講嘅內容：
將一個模糊嘅功能想法，變成結構化嘅 PRD
喺冇用研團隊嘅情況下，設計一場講得過去嘅用戶研究
面對客戶話「呢個功能好簡單」，系統拆穿背後嘅複雜度
Bug 嚟咗，PM 等緊開發嘅時候可以先做啲乜
Sprint Planning 嘅合理性檢查
PRD 寫完之後嘅驗收閉環
呢六個場景，係我日常工作中最易卡住、最易靠感覺做判斷嘅六個地方。而家佢哋都有咗一個相對可重複嘅方法。
我想講嘅核心觀點，喺第一篇已經講過，但到呢度我覺得可以再重申一次：
唔係要 AI 取代 PM，而係將 PM 嘅方法論固化到 AI 插件裏面。
AI 係執行引擎，方法論係你嘅。
你知道做需求要先問「邊個用」，你知道驗收標準要用業務語言寫，你知道 P0 未過唔叫完成——呢啲判斷力係你嘅，唔係 AI 嘅。
AI 做嘅事係：將呢啲判斷喺每次工作中系統地執行一次，唔遺漏，唔靠心情。
呢件事本身比任何一個獨立嘅命令都更加重要。
關於作者
Derek，AI 產品經理，用 Claude Code 插件體系搭建咗一套 PM 專屬嘅 AI 工作流程。
呢個系列 7 篇文章，記錄咗由功能規劃、用戶研究、客戶需求評估、Bug 調查、疊代規劃到 PRD 驗收嘅完整實戰經歷。背後嘅核心理念始終係一個：唔係要 AI 取代 PM，而係將 PM 嘅方法論固化到 AI 插件裏面，令 AI 成為你嘅方法論執行引擎。
多謝你睇到呢度。如果呢個系列對你有啟發，歡迎轉發畀同樣喺探索 AI + PM 工作方式嘅朋友。
我有一個文件夾，叫"PRD 歸檔"。
裏面有幾十份文檔。絕大多數從寫完那天起，就再沒被打開過。
這是 PM 工作裏最諷刺的事情之一：你花了很多時間把需求想清楚、寫清楚，然後發出去，然後就沒了。
開發做完了，說"做完了"。你心裏其實不確定"做完"是什麼意思，但也沒有一個好方法去核對，就說"好，我看一下"。然後打開產品點一點，感覺差不多，就算過了。
然後上線，然後出了問題，然後翻出 PRD 一看——哦，這裏有一條驗收標準，當時沒對上。
這個循環我經歷了不知道多少次。
問題不在開發，在"完成標準"從沒被清楚地確立過
我以前覺得是溝通問題。開發沒仔細看 PRD，或者 PM 沒跟進到位。
但後來我意識到，更根本的問題是：從來沒有一個明確的"完成的定義"。
PRD 寫了二十個驗收標準，但這二十條誰來對？怎麼對？對完結果記錄在哪裏？
開發說"做完了"，是憑感覺，是"功能能跑了"。PM 說"沒做完"，也是憑感覺，是"我點到某個地方感覺不對"。
兩個感覺碰在一起，就變成了扯皮。
這不是任何一個人的問題。是這件事本身缺少一個有約束力的流程。
我想要的，是把驗收這件事變成一個可重複的動作
第七個命令：/pm:verify-feature。
它做的事情說起來很直接：把 PRD 裏的驗收清單拿出來，對照代碼庫逐項檢查。
不是人工翻代碼，是 AI 真的去讀代碼，根據每一條驗收標準，判斷有沒有對應的實現。
我第一次用的時候，是拿之前那個"用戶註冊"功能來試的。那是用 /pm:feature-flow 生成的 PRD，開發跟我說做完了，正好拿來驗一下。
一次完整的驗收是什麼樣的
敲了這行命令：
/pm:verify-feature 用戶註冊
然後分了幾步走完。
第一步：AI 先找到 PRD。
它自動在 docs/prd/ 下搜索匹配的文件，找到了那份用戶註冊的 PRD，提取出裏面的需求清單和驗收標準。
這一步看起來很普通，但對我來說有個隱藏的好處——我自己都記不住 PRD 存在哪了。
第二步：逐項去代碼庫裏找。
AI 開始讀代碼。
它的做法是這樣的：先從每一條驗收標準裏提取關鍵的業務概念，然後用這些概念在代碼倉庫裏搜索相關文件，再去讀那些文件裏的具體邏輯，判斷覆蓋程度。
同時還會去看測試文件——有沒有對應的測試用例，也是覆蓋程度的一個證據。
這個過程要好幾分鐘，我就在旁邊等着。
第三步：輸出結果。
結果出來了：
驗收結果：用戶註冊功能
通過率：2/5（40%）
我盯着這個表格看了一會兒。
F-003 的問題我其實隱約有感覺，但說不清楚出在哪。現在清楚了：郵件能發，但過期時間不對，PRD 裏寫的是 24 小時，代碼裏不是。
F-004 直接未通過。這條我在驗收的時候沒有點到那個場景，真實情況是跳轉邏輯沒做。
F-005 是"無法判定"。AI 的說法是：密碼強度的 UI 提示需要實際操作才能驗證，光看代碼看不出來。
這四個字我覺得設計得很好——"無法判定"。
AI 沒有猜，沒有瞎寫一個"通過"或者"未通過"，而是老實說"這個我看不出來，建議人工驗證"。這比亂猜要有用得多。
結果出來之後，對話就變了
以前的對話是這樣的：
"你看一下驗收情況。"
"我覺得差不多了。"
"那這幾個地方怎麼回事？"
"哪幾個地方？"
現在的對話是這樣的：
"F-003 的過期時間，代碼裏現在是多少？"
"應該是一小時，當時沒注意。"
"那改成 24 小時，F-004 的跳轉邏輯加上，這兩個 fix 了再給我看。"
從"感覺"的對話，變成了"事實"的對話。
這不是 AI 替我做判斷，是 AI 幫我把判斷的依據從模糊變成了具體。
驗收結果會自動生成報告和更新 PRD 狀態
跑完驗收，還有兩件事自動發生。
一是生成驗收報告。
報告保存在 PRD 的同一個目錄下，包含：驗收總覽（驗收了什麼、整體結論是什麼）、每一條的詳細結果、未通過項的具體說明（PRD 要求是什麼、當前狀態是什麼、缺少什麼、建議怎麼處理）、還有需要人工驗證的那些項。
這份報告是有用的。不只是"驗收記錄"，更重要的是，下次回溯的時候能知道當時這個功能是以什麼狀態交付的。
二是更新 PRD 狀態。
這裏有一個邏輯我自己也覺得設計得比較穩健：
只有 P0 驗收全部通過，PRD 狀態才會從"待驗收"變成"已完成"。如果 P0 全過但 P1/P2 有遺漏，會標記為"已完成，含遺留項"。如果 P0 有任何未通過，PRD 狀態保持不變，不會更新。
P0 是核心功能，P1、P2 是增強項。核心沒做好，就不能說完了。
這個邏輯保守，但對的。
從 PRD 到驗收，這條鏈現在通了
把整個系列串起來，這條鏈大概長這樣：
/pm:feature-flow（第 2 篇）
→ 從模糊想法到結構化 PRD
/pm:plan-iteration（第 6 篇）
→ PRD 排入迭代，確定優先級
prd-dev 工作流
→ 開發基於 PRD 做 SDD + TDD
/pm:verify-feature（本篇）
→ 對照 PRD 逐項驗收，生成報告
PRD 狀態自動流轉
→ 待設計 → 設計中 → 待開發 → 開發中 → 已完成
PRD 不再是"寫完就扔進文件夾"的文檔，它是整條鏈上的主線。每個環節都在引用它、更新它。
這就是我想要的"活文檔"。不是一個漂亮的模板，是一個在整個需求生命週期裏真正被用到的東西。
驗收這件事，三個理解幫了我
第一個：完成的定義，是 PM 最重要的交付物之一。
不是代碼，不是設計稿，是"怎樣算做完了"。
這句話聽起來像廢話，但很多項目的問題就出在這裏——"做完了"是一個所有人理解都不一樣的概念，但從來沒人把這個概念寫清楚過。
驗收標準寫得越具體，開發和 PM 之間的摩擦就越少。不是因為大家變好了，是因為"事實"代替了"感覺"。
第二個：驗收報告要用業務語言，不要用技術語言。
"F-003 未通過：郵箱驗證連結過期時間未按 PRD 要求的 24 小時設置。"
不是："validateEmail 函數的 expiry 參數不符合預期值。"
前者是問題，後者是代碼。我需要知道的是前者，然後把前者交給開發解決後者。
這一點我在設計插件的時候專門強調過，不允許驗收報告裏出現函數名、變量名、技術路徑。
第三個：靜態代碼分析有侷限性，AI 應該知道自己的邊界在哪裏。
有些東西看代碼看不出來。UI 的交互細節、動畫是否流暢、表單校驗的時機是否合理、頁面在不同設備上的顯示效果——這些不是代碼分析能覆蓋的。
AI 對這類驗收標準的判定是"無法判定"，然後建議人工測試。
這比亂說一個結果要有用。工具知道自己能幹什麼、不能幹什麼，這本身就是設計質量的體現。
系列收官，說幾句話
這是這個系列的第七篇，也是最後一篇。
回頭看這七篇講的內容：
把一個模糊的功能想法，變成結構化的 PRD
在沒有用研團隊的情況下，設計一場說得過去的用戶研究
面對客戶"這個功能很簡單"，系統拆穿背後的複雜度
Bug 來了，PM 在等開發的時候能先做什麼
Sprint Planning 的合理性檢查
PRD 寫完之後的驗收閉環
這六個場景，是我在日常工作裏最容易卡殼、最容易靠感覺做判斷的六個地方。現在它們都有了一個相對可重複的方法。
我想說的核心觀點，在第一篇裏已經說了，但到這裏我覺得可以再重申一遍：
不是讓 AI 替代 PM，而是把 PM 的方法論固化到 AI 插件裏。
AI 是執行引擎，方法論是你的。
你知道做需求要先問"誰在用"，你知道驗收標準要用業務語言寫，你知道 P0 沒過不能叫完成——這些判斷力是你的，不是 AI 的。
AI 做的事是：把這些判斷在每次工作中系統地執行一遍，不遺漏，不靠心情。
這件事本身比任何一個單獨的命令都更重要。
關於作者
Derek，AI 產品經理，用 Claude Code 插件體系搭建了一套 PM 專屬的 AI 工作流。
這個系列 7 篇文章，記錄了從功能規劃、用戶研究、客戶需求評估、Bug 調研、迭代規劃到 PRD 驗收的完整實戰經歷。背後的核心理念始終是一個：不是讓 AI 替代 PM，而是把 PM 的方法論固化到 AI 插件裏，讓 AI 成為你的方法論執行引擎。
感謝你讀到這裏。如果這個系列對你有啓發，歡迎轉發給同樣在探索 AI + PM 工作方式的朋友。