AI產品經理工作空間：規格書、探索研究，和敘事整合在一個工具

AI在產品經理一週工作中真正的定位

產品管理其實是四份不同的工作，擠在同一張行事曆裡。你要大量閱讀（用戶回饋、工單、逐字稿、分析報表匯出），大量寫作（規格書、進度更新、簡報），做一些分析（轉換率、族群分析、問卷結果），還要不斷說服別人。這些工作各自適合不同的模型，這也是為什麼單一AI訂閱大概只能涵蓋三分之二的工作，剩下的部分用起來總是卡卡的。

PM任務	最適合的模型	原因
PRD敘事、問題陳述、產品更新	Claude	能撐起長篇論證，寫出工程師真的會讀下去的文字
回饋主題分類、工單分群、結構化擷取	GPT	在嚴格輸出格式和一致的分類標籤上很穩定
探索研究、競品掃描、市場背景	Gemini	在最新的網路資料上表現最好，會附上你可以打開的來源
長逐字稿、研究簡報、上百頁的報告	Gemini	1M token的上下文視窗，整份資料一次就能讀完
規格書挑戰和邊界情境搜尋	任何沒有寫這份規格書的模型	獨立的讀者能抓到作者自己看不到的問題

這一切都不會取代你對該做什麼的判斷力。它縮短的是從有資料到把東西寫下來之間的距離，而這正是產品經理每週最容易漏掉時間的地方。切換模型的成本也很低：在Whizi Pro方案裡，一則Claude Sonnet 5訊息只花掉每月2,000點額度中的10點，一次GPT-5.6 Luna的擷取只花1點，Gemini 3.7 Flash讀逐字稿每則訊息只花2點。

寫一份工程師不會退回的PRD

大多數AI寫出來的規格書都敗在同一件事：它們描述的是一個功能，而不是一個決定。工程團隊不需要一段解釋客戶有多重要的文字。他們需要的是各種狀態、邊界情境，以及呼叫失敗時會發生什麼事。明確地要求這些，輸出結果的性質就會改變。

提示詞：先寫問題陳述

寫這份PRD的問題陳述段落。我手上的證據是：[貼上客服工單、分析數據、訪談引言]。不要提出解決方案。請回覆：誰有這個問題、多常發生、他們現在用什麼替代方式、這對他們造成什麼成本，以及如果問題解決了我們預期會改變什麼。任何沒有證據支持的說法都標註為ASSUMPTION（假設）。

提示詞：規格書本體

把這個變成給工程團隊的規格書。功能：[描述]。要涵蓋的用戶狀態：[清單]。請回覆：附驗收條件的用戶故事、每一種狀態包括空白、載入中、錯誤，和權限被拒絕、依賴項不可用時的行為、附屬性的分析事件，以及待解決的問題。不要發明我沒有提到的需求。把任何你必須假設的部分另外列在最後一段。

提示詞：挑戰環節

扮演一位資深工程師，在估時之前審查這份規格書。只列出問題：未定義的行為、缺少的狀態、互相矛盾的需求、隱藏的遷移工作，以及任何在細化會議上會被追問的地方。不要改寫這份規格書。

把第三個提示詞放到一個沒有寫過這份規格書的模型裡執行。它通常能穩定找出你的團隊原本會在細化會議上提出的三個問題，事先回答這些問題，就是20分鐘會議和50分鐘會議之間的差別。

把原始回饋變成你可以拿來排優先順序的東西

產品管理裡槓桿最大的AI任務不是寫作。而是把400則回饋讀成一個你能採取行動的形式。手動做這件事要花半天。用模型做好的話只要20分鐘，而品質幾乎完全取決於你有沒有強制使用穩定的分類。

提示詞：第一輪主題分類

這是原始的客戶回饋。請把它分成幾個主題。每個主題請回覆：標籤、項目數量、從用詞判斷出的嚴重程度、一句照抄的代表性原話，以及這個主題是錯誤、缺少的功能、可用性問題，還是期待落差。就算用詞相似，也不要合併根本原因不同的主題。不要改寫原話。回饋內容：[貼上]。

提示詞：第二輪對照固定分類

用以下這些分類重新分類同一份回饋：[貼上你現有的分類架構]。任何不符合的都放進UNCLASSIFIED（未分類），並附上說明。回覆一個分類、數量，和百分比的表格。

這兩輪的結構很重要。第一輪告訴你資料裡實際上有什麼。第二輪讓結果可以和上一季做比較，這才是讓它在排優先順序的討論裡真正可用的原因，而不只是有趣而已。

要問什麼	你會得到什麼	適合用在哪裡
附數量的主題	一份排序過的問題領域清單	產品路線圖輸入、季度規劃
只要原話	未經修改的客戶用語	文案、定位、說服高層
嚴重程度與頻率的交叉分析	一張痛點對數量的2x2圖	決定先修哪個
矛盾之處	哪些客群想要相反的東西	及早發現假共識

最後一行值得做成一個常用提示詞：「這份回饋裡，哪些不同的用戶想要互相衝突的東西？請說出各個客群和取捨。」主題清單會把分歧抹平，而分歧通常才是資料裡最有用的部分。

探索研究、競品分析，和你永遠沒時間做的功課

探索研究是發布延遲時最先被砍掉的工作，而那正是做錯決定代價最高的時候。有模型輔助的掃描並不能取代和客戶對話，但它確實能取代在毫無所知的情況下就做決定的藉口。

提示詞：競品拆解

分析[競品]如何處理[待完成的工作]。請涵蓋：他們自己陳述的定位、根據他們說明中心記載的流程、公開的定價、過去12個月有附日期的變化，以及公開評論中看得到的抱怨主題。每個說法都要附上網址來源。區分清楚哪些是該公司自己說的，哪些是第三方觀察到的。

提示詞：訪談綜合分析

讀這些訪談逐字稿。請回覆：用戶想完成的工作、他們自己想出來的變通方法、他們表達出挫折感的時刻並附上確切原話，以及任何用戶說的話和他們描述的行為互相矛盾的地方。不要超出逐字稿範圍做通則化推論。如果一個模式只出現在少於三場訪談裡，請標註為單一觀察，而不是一種模式。

最後這條限制是產品經理最常忘記的一條。模型很樂於產生乾淨的模式，而一個只從兩場訪談得出的乾淨模式，正是路線圖最後服務到一個根本不存在的客戶的原因。每個說法都要求附上數量。

高層敘事和上市溝通

同樣的內容必須存在於四種高度：給工程團隊的規格書、給團隊看的更新、給高層審查的一段話，以及給客戶的上市說明。在這些高度之間改寫，是這份工作裡最機械化，也最容易交出去的部分。

提示詞：改變高度

把這段內容改寫給[受眾]看。他們在意[具體的關注點]。他們對這個產品領域有[程度]的背景了解。保留每一項事實陳述不變。長度限制：[限制]。以決定或結果開頭，而不是先講背景。草稿：[貼上]。

提示詞：高層那段話

把這份更新壓縮成120字，給只會讀一次的高層主管看。結構：發生了什麼變化、對我們承諾過的指標代表什麼意義、我們需要他們做什麼，以及唯一值得他們注意的風險。不要用沒有量測依據的形容詞。

提示詞：事前驗屍

假設這次發布在六個月後失敗了。只根據下面的計畫，寫出三個最可能的原因，按可能性排序。每一個都說明我們可以觀察的早期訊號。計畫：[貼上]。

把這四種高度都放在同一個Whizi對話串裡。上市說明會繼承規格書和回饋分析的脈絡，這樣每次換受眾就不用重新解釋這個功能一次。

AI在哪裡特別容易誤導產品經理

有三種失敗模式在這份工作裡，比在大多數其他工作裡更要命。

捏造的原話。 如果你要求代表性引言卻沒有把模型釘死在原始文字上，有時候會得到一句聽起來合理、但沒有任何客戶說過的話。務必指示「逐字照抄原話，不要改寫」，並且在任何原話進到簡報之前，抽查其中三則對照原始資料。

小樣本帶來的過度自信。 模型分析八則客服工單時的語氣，會和分析八百則時一樣篤定。每個主題都要求附上數量，任何低於個位數的實例都當作觀察，而不是訊號。

路線圖劇場。 請模型幫你的待辦清單排優先順序，會得到一份看起來很篤定、但只是根據工單文字推導出來的排序。它完全看不到你的策略、你的產能、你的技術債，或是下季即將成交的合約。用它來整理取捨，但絕對不要用它來做最終決定。