產品經理別再只讓 AI 寫 PRD 了，先把用戶反饋整理成一張問題地圖
整理版優先睇
產品經理應先建立問題地圖，釐清用戶反饋背後嘅真實問題，再俾AI幫手寫PRD
呢篇文章係一位有經驗嘅產品經理分享佢對AI輔助產品管理嘅反思。佢指出好多產品經理一上嚟就叫AI寫PRD，但其實用戶反饋通常「唔乾淨」，夾雜住客服、銷售、實施同事嘅轉述，仲有用戶抱怨。直接將呢啲碎片掉俾AI，AI好擅長將佢哋整理成一份睇落好完整嘅文檔，但其實會放大根本性嘅錯誤——因為AI唔識得分辨用戶真正嘅問題。
作者嘅核心論點係：產品管理嘅重點唔係更快生成文檔，而係更早形成證據。佢提出一個「問題地圖」框架，用六個字段（原始反饋、真實問題、使用場景、影響範圍、證據強度、潛在機會）將用戶講嘅說話還原成問題本身。呢張地圖唔需要用複雜工具，Excel或Notion就得。關鍵係防止團隊直接跳到解決方案。
作者用一個常見例子說明：用戶話「加個批量導出」，真實問題可能係財務人員對賬時無法快速定位異常單據。問題地圖可以帶出多個潛在機會，而唔係單純做導出功能。佢亦提醒，AI可以幫手做第一輪整理，但產品經理一定要自己做判斷：AI有冇過早將功能請求當成真實問題？有冇忽略證據強度？有冇混淆唔同問題？總括嚟講，先整好問題地圖，先至寫PRD，咁樣團隊討論就會由「做唔做呢個功能」前置到「呢個問題值唔值得解決」。
- 直接叫AI寫PRD會放大錯誤，因為用戶反饋本身唔乾淨，AI只係將可能做錯嘅嘢寫得更似真。
- 問題地圖包含六個欄位：原始反饋、真實問題、使用場景、影響範圍、證據強度、潛在機會，用Excel或Notion就得。
- 每個功能請求背後可能隱藏唔同嘅真實問題，例如「加個導出」可能係對賬流程卡住，要拆開分析。
- AI可以幫手初步整理反饋，但產品經理一定要覆核三個位：有冇過早轉換問題、有冇忽略證據強度、有冇混淆問題。
- 先建立問題地圖再寫PRD，可以將團隊討論由「做唔做功能」前置到「問題值唔值得解決」，提升決策質量。
直接叫AI寫PRD嘅陷阱
好多產品經理一上嚟就將用戶反饋掉俾AI，叫佢生成PRD。睇落好快，格式好完整，但其實好危險——如果AI一開始就唔明用戶真正卡喺邊，佢寫出嚟嘅PRD只係將一件可能做錯嘅事寫得更似真。
AI唔係唔寫得PRD，而係產品經理唔可以一上嚟就叫佢寫PRD
真正混亂嘅唔係文檔，而係反饋。產品經理手上嘅用戶反饋通常「唔乾淨」：客服話客戶催、銷售話大客戶要呢個功能、實施同事掉嚟羣組截圖、用戶訪談入面有幾句看似無關嘅抱怨。有人話「加個導出掣」，有人話「每次對賬都好麻煩」，仲有人淨係話「呢個系統太難用」。產品經理如果直接將呢啲嘢當需求，好快就會變成：邊個大聲、邊個近老細，邊個需求就入PRD。
AI會放大呢個問題——佢特別擅長將碎片整理成一份體面嘅文檔
你俾佢一句「用戶需要導出」，佢可以寫出完整嘅導出功能說明，但佢唔知道用戶真正要嘅可能唔係導出，而係對賬時缺少一張可追溯嘅異常明細。
問題地圖：六個字段拆開用戶原話同真實問題
國外幾個產品工具最近都走向同一個方向：Productboard Spark、Pendo Listen、Dovetail——佢哋將散落嘅反饋變成主題、證據同路線圖輸入。呢個變化指向一個重點：AI產品管理唔係「更快生成文檔」，而係「更早形成證據」。
- 1 原始反饋：保留用戶原話、工單摘要、銷售轉述、會議紀要片段，防止需求變成二手傳話
- 2 真實問題：將「我要呢個功能」翻譯成「我喺邊個任務卡住咗」，防止直接跳到方案
- 3 使用場景：用戶喺咩角色、咩流程、咩時點遇到問題，判斷係咪高頻主流程
- 4 影響範圍：涉及幾多用戶、邊個客羣、頻率如何，避免被個別強聲音帶偏
- 5 證據強度：原話數量、數據指標、收入影響、流失風險，俾優先級一個支點
- 6 潛在機會：可能轉成咩產品方向或驗證動作，等反饋進入路線圖，唔好停喺抱怨
真實案例：由「加個批量導出」還原成對賬問題
- 1 用戶點解要導出？
- 2 導出之後用嚟做乜？
- 3 如果唔導出，真正卡住嘅業務動作係咩？
整理之後，真實問題可能變成：「財務人員喺月末對賬時，冇辦法快速定位異常單據，焗住將明細導出到Excel做二次篩選。」呢個時候，潛在機會就唔止一個：可以係批量導出，亦可以係異常篩選、對賬視圖，甚至自動生成對賬報告。
問題地圖嘅價值：唔急住幫用戶實現佢講出口嘅功能，而係先將佢講出口嘅話，還原成佢冇講清楚嘅問題
AI做整理，人做判斷
- 1 AI有冇將「功能請求」過早當成「真實問題」？
- 2 有冇忽略證據強度？
- 3 有冇將唔同問題混成一個大主題？
例如「導出慢」「字段唔齊」「對賬麻煩」睇落同導出有關，背後可能分別係性能、權限、流程設計三個問題
作者嘅做法係：叫AI先將信息攤平，自己做取捨。
一旦問題地圖成形，PRD反而更加易寫
背景唔再係空泛嘅「用戶反饋較多」，功能點亦唔再係孤零零嘅需求清單，而係由真實問題推出來嘅一組解決方案。所以總結好簡單：AI寫PRD之前，產品經理要先令佢睇明問題。
產品經理用 AI 嘅起手式，基本上都係叫佢寫 PRD。
掉幾條用戶反饋入去，叫 AI 生成背景、目標、功能點、驗收標準。表面睇好快，格式又齊全。
但問題都係一樣：如果 AI 一開始睇唔明用戶到底卡喺邊度，佢寫出嚟嘅 PRD 只係將一件可能做錯嘅事，寫得更似真嘅。
我越嚟越警惕嘅係：AI 唔係唔可以寫 PRD，而係產品經理唔可以一開波就叫佢寫 PRD。
真正亂嘅唔係文檔，而係反饋
產品經理手上面嘅用戶反饋，通常都「唔乾淨」。
客服話客又催喇，銷售話大客要呢個功能，實施同事掉咗段羣組對話截圖，用戶訪談入面仲有幾句好似冇關嘅投訴。有人話「可唔可以加個導出掣」，有人話「每次對數都好麻煩」，仲有人淨係話「呢個系統太難用」。
產品經理直接將呢啲說話當成需求，下一步就好容易變成：邊個大聲啲，邊個近老細，邊個嘅需求就優先入 PRD。
AI 喺呢度會放大問題。因為佢特別擅長將碎片整理成一份體面嘅文檔。你畀佢一句「用戶需要導出」，佢可以寫出完整嘅導出功能說明。
但佢唔知道，用戶真正要嘅可能唔係導出，而係對數嗰陣缺咗一張可以追溯嘅異常明細。
首先將「用戶講咩」翻譯成「問題係咩」
國外幾個產品工具最近都向同一個方向行：Productboard Spark、Pendo Listen、Dovetail 都係將散落嘅反饋變成主題、證據同路線圖輸入。
佢哋共同指向一個變化：AI 產品管理嘅重點，唔止係「更快生成文檔」，而係「更早形成證據」。
PRD 係解決方案文檔，問題地圖先係決策前嘅證據層。冇問題地圖，PRD 寫得越完整，團隊越容易產生一種錯覺：呢件事已經諗清楚咗。
等等，我唔係推銷軟件，亦唔係話產品經理每次都要做一套複雜研究。
一張問題地圖，先放 6 列就夠
問題地圖唔需要複雜工具。Excel、飛書表格、Notion、Obsidian 表格都得。關鍵唔係軟件，而係將用戶原話、真實問題同證據強度拆開。
舉個好常見嘅例子。
原始反饋係：「可唔可以加個批量導出？」
唔好即刻寫「新增批量導出功能」。先問三層：
第一，用戶點解要導出？
第二，導出之後攞去點用？
第三，如果唔導出，真正卡住嘅業務動作係咩？
整理之後，真實問題可能變成：「財務人員喺月尾對數嗰陣，冇辦法快速定位異常單據，唯有將明細導出到 Excel 度再篩選。」
嗰陣潛在機會就唔止一個喇。佢可能係批量導出，亦可能係異常篩選、對數視圖，甚至係自動生成對數報告。
呢個就係問題地圖嘅價值：佢唔急住幫用戶實現佢講出口嘅功能，而係先將佢講出口嘅說話，還原成佢冇講清楚嘅問題。
叫 AI 做整理，但唔好叫 AI 幫你下判斷
呢張表適合叫 AI 參與第一輪整理。
你可以將 20 條反饋掉畀 AI，叫佢先按「原始反饋、真實問題、使用場景、影響範圍、證據強度、潛在機會」做初稿。
產品經理真正要睇嘅，係三件事：AI 有冇將「功能請求」過早當成「真實問題」；有冇忽略證據強度；有冇將唔同問題撈埋成一個大主題。
例如：「導出慢」「欄位唔齊」「對數麻煩」表面睇都同導出有關，背後可能分別係效能、權限、流程設計三個問題。
叫 AI 先將信息攤平，你做取捨。
先做地圖，再寫 PRD
呢套動作嘅好處，係可以將團隊討論由「做唔做呢個功能」，推前到「呢個問題值唔值得解決」。
一旦問題地圖成形，PRD 反而更容易寫。背景唔再係空泛嘅「用戶反饋較多」，功能點亦唔再係孤零零嘅需求清單，而係由真實問題推出來嘅一組解決方案。
AI 寫 PRD 之前，產品經理首先要令佢睇得明問題。
講到呢度先，我去將我呢套機制改一改，再繼續加深度。
產品經理用 AI 的起手式，基本都是讓它寫 PRD。
把幾條用戶反饋丟進去，讓 AI 生成背景、目標、功能點、驗收標準。看起來很快，格式也很完整。
但問題也都很一致：如果 AI 一開始沒看懂用戶到底卡在哪裏，它寫出來的 PRD 只是把一件可能做錯的事，寫得更像真的。
我越來越警惕的是：AI 不是不能寫 PRD，而是產品經理不能一上來就讓它寫 PRD。
真正混亂的不是文檔，而是反饋
產品經理手裏的用戶反饋，通常是“不乾淨”的。
客服說客戶又催了，銷售說大客戶要這個功能，實施同事丟來一段羣聊截圖，用戶訪談裏還有幾句看似無關的抱怨。有人說“能不能加一個導出按鈕”，有人說“每次對賬都很麻煩”，還有人只說“這個系統太難用了”。
產品經理直接把這些話當需求，下一步就很容易變成：誰聲音大，誰離老闆近，誰的需求先進 PRD。
AI 在這裏會放大問題。因為它特別擅長把碎片整理成一份體面的文檔。你給它一句“用戶需要導出”，它可以寫出完整的導出功能說明。
但它不知道，用戶真正要的可能不是導出，而是對賬時缺少一張可追溯的異常明細。
先把“用戶說什麼”翻譯成“問題是什麼”
國外幾個產品工具最近都在往同一個方向走：Productboard Spark、Pendo Listen、Dovetail 都在把散落反饋變成主題、證據和路線圖輸入。
它們共同指向一個變化：AI 產品管理的重點，不只是“更快生成文檔”，而是“更早形成證據”。
PRD 是解決方案文檔，問題地圖才是決策前的證據層。沒有問題地圖，PRD 寫得越完整，團隊越容易產生一種錯覺：這件事已經想清楚了。
等等，我不是在推銷軟件，也不是說產品經理每次都要做一套複雜研究。
一張問題地圖，先放 6 列就夠了
問題地圖不需要複雜工具。Excel、飛書表格、Notion、Obsidian 表格都可以。關鍵不是軟件，而是把用戶原話、真實問題和證據強度拆開。
舉個很常見的例子。
原始反饋是：“能不能加一個批量導出？”
不要馬上寫“新增批量導出功能”。先問三層：
第一，用戶為什麼要導出？
第二，導出以後拿去做什麼？
第三，如果不導出，真正卡住的業務動作是什麼？
整理之後，真實問題可能變成：“財務人員在月末對賬時，無法快速定位異常單據，只能把明細導出到 Excel 裏二次篩選。”
這時潛在機會就不止一個了。它可能是批量導出，也可能是異常篩選、對賬視圖，甚至是自動生成對賬報告。
這就是問題地圖的價值：它不急着替用戶實現他說出口的功能，而是先把他說出口的話，還原成他沒說清楚的問題。
讓 AI 做整理，但別讓 AI 替你下判斷
這張表適合讓 AI 參與第一輪整理。
你可以把 20 條反饋丟給 AI，讓它先按“原始反饋、真實問題、使用場景、影響範圍、證據強度、潛在機會”做初稿。
產品經理真正要看的，是三件事：AI 有沒有把“功能請求”過早當成“真實問題”；有沒有忽略證據強度；有沒有把不同問題混成一個大主題。
比如：“導出慢”“字段不全”“對賬麻煩”看起來都和導出有關，背後可能分別是性能、權限、流程設計三個問題。
讓 AI 先把信息攤平，你做取捨。
先做地圖，再寫 PRD
這套動作的好處，是它能把團隊討論從“要不要做這個功能”，往前挪到“這個問題到底值不值得解決”。
一旦問題地圖成形，PRD 反而更容易寫。背景不再是空泛的“用戶反饋較多”，功能點也不再是孤零零的需求清單，而是從真實問題推出來的一組解決方案。
AI 寫 PRD 之前，產品經理先要讓它看懂問題。
先聊到這兒，我去把我的這套機制改造一下，再繼續加深度。