前 26 天，鼠勾以做的事都是往裡面挖：一題一題問，把模糊的需求挖成清楚的輪廓。今天講反方向的收斂。對話問得再仔細，如果最後沒有變成一份能交出去的文件，後面的人還是接不到。

一段聊得很好的對話，沒人想看

先講個畫面。某次一個需求方PM 同事用鼠勾以聊完整整 8 個區塊，背景、角色、流程、資料、例外都問過一輪，聊得很開心。聊完他問我：「那我現在要把這個丟給 SA 嗎？」

我問他要丟什麼，他說就把這串對話複製貼上。

一串往返幾十輪的對話，SA 打開看到的是問一句、答一句、再追問、再補充的流水帳。重點散在各處，前面講的後面又改過，中間還夾著鼠勾以的鼓勵文字。SA 得先花 20 分鐘讀完，才能拼出這個需求到底要做什麼。

所以鼠勾以最後一定要輸出一份結構固定、SA 能直接讀的「需求討論書」，這趟流程才算走完。接下來的問題是：這份文件的格式要不要先定死？

要不要用固定模板？

我認真考慮過兩種做法。

讓 GPT 自由發揮排版

優點：彈性高，每份需求的重點不同，理論上 GPT 可以「看菜下飯」，重要的多寫、不重要的少寫。

缺點：

• 每次長得不一樣：今天把流程放最前面，明天又把角色放最前面，SA 每次都要重新找東西在哪。一份好文件最重要的是「可預期」，讀的人知道第幾段會看到什麼。
• 容易漏段：沒有固定骨架，GPT 可能就漏掉例外情境或工時估算。漏了也沒人會發現，因為沒有對照基準。
• 品質飄忽：同樣的需求，運氣好排得漂亮，運氣不好排得亂七八糟。一個要交付的工具不能靠運氣。

固定 PRD 模板

優點：

• 可預期：第 2 段永遠是需求摘要，第 5 段永遠是流程圖。SA 翻第二份、第三份的時候，不用重新找內容在哪一節。
• 不漏段：模板就是一張檢查表。每個段落都在，缺內容也看得出來是「缺」，而不是「忘了」。
• 逼出結構：8 個區塊的問答，本來就對得上文件的各個段落。模板把這個對應關係固定下來，等於替前面 26 天的設計收尾。

缺點：偶爾會有段落填不滿，看起來有點空。但這個缺點我反而當成優點用，後面講。

把這兩個攤開來看，結論很清楚。一個要拿去跟人討論、會被翻很多次的文件，可預期性遠比彈性重要。所以鼠勾以走固定模板。

真正讓我把這件事定案的，是下游。這份 PRD 不是交出去就結束，它後面還要接兩段：一段是後端與 SA 自己的 AI 工具，他們設計 skill 的時候，是預期讀進來的規格長在固定位置的，功能規格在哪一節、AC 用什麼句型、畫面清單有哪幾欄，都是寫死的假設；另一段是開卡，Epic、Feature、Story 這幾層的欄位跟拆分規則本來就有固定格式，需求描述要能一段一段對進去。

上游每份文件都長得不一樣的話，這兩段都得先做一次人工轉譯，等於把省下來的時間又賠回去。所以固定模板不只是為了 SA 讀起來方便，它是整條鏈路對接的前提：模板的段落順序、AC 的寫法、畫面清單的欄位，都是照下游會怎麼吃它來排的。

11 個段落，為什麼這樣排

模板的順序不是隨便排的，它跟著前面 8 個區塊的挖掘順序走，讀起來就像「從為什麼，一路推到怎麼做、要多久」。

幾個刻意的設計：

第 4 段一定要寫「明確不做」。需求文件最常出現的爭議來源，是雙方對「這件事到底算不算在範圍內」的認知不同。把 Out of Scope 寫出來，範圍的邊界就先定下來了，可以省掉後面幾輪確認。

第 5 段的流程圖必附。文字描述流程，十個人讀出十種版本。一張 Mermaid 流程圖加上 UI-01、UI-02 的畫面清單，比三段文字都清楚。Day 29 會講怎麼把它變成 Word 裡能看的圖。

工時一律給區間，不給單一數字。鼠勾以不會寫「這個要 5 人天」，它會寫「樂觀 4、保守 7」。因為單一數字會被當成承諾，區間才是討論的起點。這個明天整篇講。

驗收標準的兩條死規矩

模板裡每個功能都要配驗收標準（AC），就是那種「當使用者做了 X，系統要出現 Y」的句子。它是 SA 拆任務、QA 寫測試的依據，也是後面開卡時直接被搬進 Story 的內容，寫得不對，後面每一段都會跟著歪。所以模板對 AC 訂了兩條死規矩。

第一條，不准寫實作。AC 只寫使用者看得到的行為，不寫系統底下怎麼做到的。「點數扣完後餘額正確減少」是行為，可以；「呼叫扣點 API、寫進交易表」是做法，不行。原因是需求方PM 還在釐清需求的階段，這時候把實作寫死，等於替還沒上場的 SA 先做了技術決定，多半也決定錯。唯一的例外是那種交付物本身就是技術介面的 PRD，比方說要做一包 SDK 或 API 給別人串，那介面長怎樣、回什麼錯誤碼，本來就是要寫清楚的內容，這種就不在限制內。

第二條，不准用需要猜的形容詞。「畫面要順暢」「回應要即時」「操作要友善」這種，每個人心裡的標準都不一樣，QA 拿到根本沒法判斷到底算過還是沒過。模板逼它換成測得出來的門檻：「順暢」變「3 秒內載入完成」，「即時」變「5 秒內收到通知」。一條 AC 如果不靠詮釋就能判 pass 或 fail，它才算寫好了。

昨天講產出前自檢的時候提過，它最後會回頭把每條 AC 照這兩條規矩掃一遍，挑出洩漏實作跟含糊形容的，附上建議改法。模板負責定規矩，自檢負責抓漏網的，兩道合起來才接得住。

待確認清單

模板裡我最在意的是第 10 段。

鼠勾以有一條死規矩：缺的內容不准編。哪裡沒問清楚、哪裡使用者也還沒想好，就在那裡標一個「⚠️ 待確認」，然後集中收到第 10 段的清單裡。它寧可承認「這裡我不知道」，也不會為了讓文件看起來完整而硬掰一段。

這就是前面說的「填不滿」的缺點，反過來變成最大的優點。一份每格都填滿、看起來很完美的需求文件，通常是最危險的，因為你不知道哪些是真的想清楚了、哪些是硬湊的。鼠勾以把所有「還沒想清楚」的點明明白白列成一張清單，SA 打開文件直接翻到第 10 段，就知道這次討論該聚焦哪幾題。

換句話說，這份 PRD 從頭到尾都是一份「討論用」文件，不會假裝自己是定案版。語氣保持開放，留白的地方誠實留白。它的目的很單純：讓 SA 和需求方PM 那場會議能從第 30 分鐘開始，跳過開頭那段「所以你到底想做什麼」的暖身。

一張會讓人誤判的總覽表

文件最前面有一張「需求完整度總覽」，把 8 個區塊各自完成到什麼程度列成一張表，SA 翻開第一眼就能掌握全貌。這張表後來補過一個洞。

問題出在小需求。Day 9 講過，小調整走快速模式，只談 3 個區塊就收工。我最早讓總覽表「談幾塊就列幾列」，所以快速模式產出的文件，總覽表上只有 3 列，每一列都打了勾，看起來乾乾淨淨。SA 打開一看，很容易以為這份需求就只有這 3 塊要顧。

可是那沒列出來的 5 塊，意思是「這次沒談到」，不代表這個需求沒有這些面向。一張只列 3 列的表，把這兩種情況顯示成一模一樣，SA 因此漏追了一整塊也不奇怪。

修法是把總覽表釘死成 8 列，一列都不准省。快速模式還是只談 3 塊，但另外 5 塊照樣列在表上，標成「本次未討論」，後面附一句這塊大概涵蓋什麼。表頭的整體完成度也改成「本次討論 N/8 區塊」，讓人知道這份只走了一部分。最底下加一句註腳，講明白未討論是這次沒涵蓋，不是確認過不存在。

這跟前面講的待確認清單其實是同一招。待確認清單把「這題我還沒想清楚」標出來，總覽表的「本次未討論」把「這塊我這次沒碰」標出來，做的是同一件事，該空的地方就讓它空著、寫清楚為什麼空，不拿打勾去填。

22 項待確認，結果沒人注意到

總覽表釘成 8 列之後，還是漏了一次。

那次我看一份請假需求的產出，總覽表那行結尾寫著「待確認 22 項」。但那就只是一個數字，細節全在第 10 段的附錄裡，需求方PM 從頭滑到尾都沒有停下來看，只覺得這份文件看起來挺完整。

而且就算翻到附錄，那 22 項該找誰確認還是得自己分類。有些要問法遵、有些要問資安、有些其實需求單位自己回去確認就好。全部堆在一張長清單裡，讀的人得先整理一輪才知道要約幾場會。

所以總覽表下方多了一小張摘要，按「負責確認單位」分組：

數字直接從附錄那份清單彙整，不用另外維護。翻開第一頁就看得到有多少事還要討論、該找誰，不用等滑到最後才發現。

本來還想多一欄「這項可以先預設」，讓大家知道哪些不開會也能往下走。做到一半拿掉了。「可預設」這三個字在需求單位跟工程之間很容易變成吵架的起點，一邊覺得可以先照常識做，一邊覺得沒確認就是不能動。這欄先擱著，等想清楚該怎麼定義再說。

有次為了讓產出結構不要走樣，我重寫了一段「產出時照模板骨架逐節填」的規則，寫的時候從 1.0 開始列，剛好漏掉排在 1.0 前面的總覽表。模板裡它還在，產出的 Word 裡它就這麼不見了。這種漏法特別難抓，因為文件其他部分都好好的，你只會隱約覺得哪裡怪怪的。後來是把產出的三條路徑都明寫「總覽放最前、不可漏」才補回來。

把這些攤開來看，PRD 模板其實就是把前 26 天挖到的東西，按一個 SA 熟悉的順序排好、缺的地方誠實標出來。結構固定、缺漏透明、語氣開放，這三件事讓對話真的變成可以交付的文件。

模板裡留了一段最不好寫的：工時估算。需求方最想知道、又最怕被當承諾的數字。鼠勾以怎麼在「給個起點」和「不亂開支票」之間抓平衡？明天講。

這是 iThome 鐵人賽系列文章。明天見。