怎麼用 AI 寫好一份產品需求文件 (PRD)？
設計一套工作流程，讓 LLM 按照你的思路寫 PRD
一、PRD 是一個具備彈性的溝通工具
在 2026 年這個當下擔任產品經理，你很可能已經嘗試過把需求丟給 ChatGPT，跟它說「幫我寫一份 PRD」。
不論你是隨手丟了幾句話的需求，或者你很完整地列出了需求的規範，最終 LLM 給你的東西，就是看起來架構完整、格式也漂亮，但深入一看你會發現到處都是得花時間改的地方，你不會說那些內容有錯，但始終是差了那麼一點意思。
當你開始改動了一個小地方，很快你就開始會覺得其他地方也得修改一下，到最後你會覺得自己從頭寫一份搞不好還比較快一點。
從我的角度來看，這大致上可以歸因於 PRD 不是一種標準化的文件，不是每個人拿到同一個需求之後，都會產出差不多的 PRD。
像是我習慣在寫 PRD 的時候，放上大量的截圖、流程圖、線框稿、還有前後對比的樣貌，因為我一直認為視覺工具傳達的內容會比純文字描述來得更精確。但你也一定遇過習慣用 user story 和大量描述定義目標，強調用戶界面細節讓工程團隊自行發揮的做法。
它比較像是一個溝通工具，用來跟工程師、設計師、利害關係人們一起協作，最終達成你們對一個需求的共同理解。會隨著團隊的溝通方式、工作習慣、或是先前討論脈絡，而有不同的表達方式。
二、難以取得平衡的背景資訊
AI 寫不好 PRD 另一個原因，是因為它缺少背景資訊（Context）
你不能只丟幾句話就讓 LLM 開始寫；同樣你也不可能一股腦的把所有資訊和過往相關的討論或規格都倒給 LLM，上下文窗口撐不住，並且在幾輪對話之後就會開始發現 AI 的注意力開始渙散。
所以怎麼讓 AI 寫好 PRD 這件事，實際上的瓶頸是在“怎麼讓 AI 在適當的時間了解恰到好處的細節”上，也就是 Context Engineering。
三、設計 AI 的工作流程 (Workflow)
目前我摸索出的做法是建構工作流程，讓 AI 按照我們寫 PRD 的思路，一步一步把缺少的資訊補上，直至最後產出初稿。
整套流程是這樣運作的：
- 需求輸入：把需求直接丟給 LLM，不論是業務方發給你的幾句話需求，還是由你自主發起你可以補充各式細節的需求，總之就是一股腦地說給 LLM 聽。
- LLM 分析需求後主動追問：這是整套流程的關鍵環節之一，LLM 會根據 PRD 模板裡定義的必填區塊，去比對你目前提供的資訊，判斷哪些地方還不夠清楚。不夠的部分，它會主動產出問卷讓你回答。這個過程其實就是在模擬我們平常釐清需求時會做的事，只是現在是由 LLM 幫你問，你能省去搜索還有哪些問題沒確定下來的力氣，把精神都放在解答上。
- 比對產品知識庫 (Product Handbook)：這也是關鍵環節之一，產品知識庫是一份用 Markdown 維護的文件，記錄了產品現況、模組架構、過往的重要變更等等。LLM 會用知識庫裡的資訊來補充 PRD 裡需要的產品背景。如果知識庫裡的資訊也不夠完整，它一樣會透過問答的方式引導你補上。
- 產出 PRD 草稿：LLM 把你回答的內容、知識庫裡的產品知識、以及 PRD 模板的格式要求整合在一起，產出第一版草稿。
- 來回修訂：你看完草稿覺得哪裡不對就跟它說，幾個來回之後應該能得出一個還行的版本，接著就可以拿著這份草稿開始修改或補充細節，直到 PRD 足以應對 kick-off meeting 為止。
- 定稿回寫產品知識庫：最後經歷需求評審，確定要開發了，你再把這份定稿的 PRD 丟回給 LLM 讓他幫你更新知識庫。這一步非常重要，它意味著每一份完成的 PRD，都會成為下一份 PRD 的知識基底。
在這套流程裡面，有三個核心元件在支撐它運作：
- 產品知識庫：負責補上「產品現況」的認知。它是整套系統的知識底座，讓 AI 在寫任何新 PRD 之前，都先了解產品現在的狀態。你能進一步的細拆模組，創造跟 skill 一樣漸進式揭露的機制。
- PRD Skill：負責補上「PRD 規範」的認知。它根據公司 (或是你自己) 的 PRD 模板，定義了 PRD 裡面必須有哪些區塊、每個區塊要涵蓋什麼內容、格式長什麼樣子。
- 工作流程本身：它把整個過程拆成一步一步往前推，確保 LLM 不是一口氣瞎猜，而是有策略地把模糊的需求問清楚。
透過產品知識庫的持續累積，它會記錄越來越詳盡的產品知識，每一次基於這份知識庫產出的 PRD 也會更貼近你的理解一些。
就算最極端的情況，AI 產出的草稿你覺得完全不行，最後你自己重寫了一份，但在定稿之後，把你寫的 PRD 讓 AI 更新回知識庫裡，它還是會成爲下一份 PRD 的養分。所以不管怎樣，時間都沒有浪費。
四、目前的限制與未來可以走的方向
這套流程能讓你省些時間，但還遠遠達不到完美，最理想的情況是，在累積了一定的資料量後，你能透過這套流程跑出你只需要少量修改的 PRD，並且在任何有問題的時候隨時回頭來問問你在這流程中累積出的產品知識庫，看產品的現況是什麼、以及你們又是如何走到這步決策的？
但隨著時間過去它還是會到達極限。
限制 1: 在我目前的設計中，產品知識庫是用 Markdown 維護的純文字檔案。但產品世界裡有太多東西是文字很難完整描述的——截圖、流程圖、狀態切換的交互、跨頁面的跳轉邏輯。
限制 2: 當產品知識庫越來越大的時候，你得開始考量 LLM 對上下文的消化能力和注意力。我們在寫 PRD 的過程中，其實只需要它讀跟需求相關的那幾個模組資訊就好，但目前做不到那麼精準的切分。
有幾個改進的思路
- 把產品知識庫拆成模組以及紀錄不同模組間的層級或關聯。當你要寫某個需求的 PRD 時，LLM 只去拉相關的和次要相關的卡片，不用把整本百科全書都讀進去，就像是 Skill 一樣漸進式揭露，有效控制上下文的膨脹。
- 把截圖和流程圖也結構化。比如用文字去精確描述一個畫面的佈局——左上角是什麼按鈕、右邊是什麼入口、點下去會跳到哪裡——讓 AI 讀到這段描述的時候，能重建出這個畫面的樣貌。流程圖也一樣，可以用結構化的語法寫進 Markdown，讓原本只能靠人眼看的圖變成 AI 也能理解的資訊。
- 建立向量資料庫，用語意檢索取代全文塞入。目前產品知識庫是整份餵給 AI 的，但更好的做法是把所有產品知識，如PRD、設計文件、技術文件、會議紀錄等，拆成小段落，轉換成向量嵌入（Embedding）存進向量資料庫。當要寫 PRD 時，系統會先用語意相似度檢索出真正相關的片段，再把這些片段餵給 LLM，而不是把整個產品知識庫都塞進上下文窗口。
- 程式碼是所有產品細節的具體實踐，與其人工費盡心力的維護好產品知識庫，或許讓 AI 解析既有的 codebase，追蹤模組之間的依賴關係和呼叫流程，然後產出一份對 AI 來說最好讀、最好檢索的產品知識結構會來得更有效率。
這四個方向本質上都在解決同一件事：保存與維護足夠全面的產品知識，並且讓對的知識在對的時候進入 LLM 的上下文。
五、最後
不論如何整個思考和動手的過程對我來說都很有趣，雖然不一定幫得上忙，但我把這套 Workflow 做了一個通用版本，上傳到了 GitHub，有興趣的可以下載來試試看。