需求文檔寫三天，開發第一句還是問「這裡要做什麼」？三段提示詞：先讓 AI 逼你把需求問清楚，再照問答成稿，最後扮開發和測試打回一次。含可直接複製的模板與變數說明。
菜鳥之友系列：《AI 工具實操與提示詞》・模板篇作者：業州愚公
帶過專案的人都遇過這種場景：老闆一句話「我們也做個簽到功能吧」，你埋頭寫了三天文檔，格式漂亮、配圖齊全，結果開發看完第一句話是「這個簽到，一天一次還是隨時都能簽？」，第二句是「漏簽了怎麼辦？」——三天的心血，卡在這兩個你從沒想過的問題上。
PRD（產品需求文檔）難寫，不是因為文筆，而是因為它逼你把腦子裡那團模糊的「想做個什麼」拆成一條條可執行、可驗收的條目。而大多數人卡住的方式是一樣的：對著空白文檔從「背景」開始寫，寫到「功能需求」就開始自由發揮，漏掉的地方用「等等」「相關細節後續補充」糊弄過去——這些糊弄的地方，恰恰就是開發提問、返工、扯皮的來源。
換個角度看，PRD 的本質不是文檔，是決策記錄：哪裡有空白，哪裡就還沒做決定；沒做的決定不會消失，只會變成開發階段的提問、測試階段的扯皮、上線之後的返工。所以寫草稿的正確目標不是「寫得快」，是「把空白暴露出來」——先暴露給你自己。
用 AI 寫 PRD，最忌諱的用法是直接說「幫我寫一份簽到功能的 PRD」。它會立刻給你一份格式完美、內容全是編的文檔：流程是它猜的、數字是它編的、邊界是它腦補的。你拿到的不是需求文檔，是一份看起來很專業的小說。更麻煩的是，假完整的文檔會讓你產生「已經想清楚了」的錯覺——空白被它的猜測填滿了，你連哪裡沒想過都看不出來。
正確的順序是反過來的：先讓 AI 逼你把需求想清楚，再讓它照著你的回答成稿，最後讓它扮演最挑剔的開發來挑錯。下面三段模板就是這三步，任何能對話的模型都能跑，不依賴任何特定工具的專屬功能。
適用場景：需求還是一句話，甚至只是個念頭。這一步的產出不是文檔，是一份「你被問倒的清單」。
```
你是一名資深產品經理。我想做一個功能：【一句話描述你的想法，例如：讓門店員工每天打卡簽到】。
先不要寫任何文檔，也不要給方案。你的任務是通過提問幫我把需求想清楚：
1. 每輪最多問 3 個問題，等我回答後再問下一批，問完為止；
2. 問題必須覆蓋：目標用戶是誰、要解決什麼具體問題、成功的標準怎麼衡量；
3. 對我回答裡含糊的詞（如「方便」「好用」「優化體驗」），要追問到可驗證的描述為止；
4. 全部問完後，輸出一節「你還沒想清楚的三件事」，只列影響最大的三個，各附一句為什麼關鍵。
禁止：替我補充我沒說過的需求；禁止提前給任何功能設計。
```
要替換的變數：只有一個——【一句話描述你的想法】。寫得越口語越好，就照你跟老闆複述的原話寫，別潤色。
為什麼這樣寫：這段模板最關鍵的是第一行「先不要寫任何文檔」。不寫這句，模型會急著表現，問兩個問題就開始輸出方案。「每輪最多 3 個問題」是防止它一口氣列二十條把你淹死；「追問到可驗證為止」是專門對付你自己腦子裡的含糊地帶——你說「要方便」，它會問「方便是指幾秒內完成，還是少點幾步？」，這一問你就知道該定什麼指標了。
回答的質量決定這一步的價值。舉個對照：問「目標用戶是誰」，答「門店員工」，這個答案沒有信息量；答「門店店員，早上開店和晚上關店各打一次卡，用的是店裡那台共用平板」，這就是能寫進文檔的答案。你每多給一個具體細節，模型後面替你編造的空間就少一分。整個過程大約三到五輪對話，花不了十五分鐘，但能把「漏簽了怎麼辦」這類要命的問題提前攔在文檔之外。
適用場景：模板一的問答做完之後。這一步的產出才是 PRD 草稿，而它質量的上限，就是你上一輪問答的質量。
```
根據下面兩份材料，寫一份 PRD 草稿。
【我的想法】：……
【問答記錄】：……
要求：
1. 按固定結構輸出：背景與目標／目標用戶與使用場景／功能需求（從 PF-01 開始編號）／不做的事／驗收標準；
2. 每條功能需求必須包含：觸發條件、正常流程、至少 1 個異常情況的處理；
3. 「不做的事」一節至少列 3 條，每條附一句不做的原因；
4. 驗收標準禁止使用「良好」「快速」「易用」等不可測的詞，必須寫成「在 X 條件下、Y 時間內完成 Z」的句式；
5. 信息不足的地方，插入標記【待補：缺什麼】並停筆，嚴禁自己編造數字、流程或規則補上；
6. 全文用陳述句，禁用「大概」「可能」「等等」「後續補充」。
```
要替換的變數：【我的想法】和【問答記錄】。問答記錄直接把上一輪的對話原樣貼進來，包括你答得含糊的部分——含糊處模型會標【待補】，正好提醒你去找答案。
為什麼這樣寫：「不做的事」是整份文檔裡最能省錢的一節。開發扯皮的一半來源，是他以為要做、你以為不用做的部分；白紙黑字列三條「不做」，比十條「要做」都管用。第 4 條句式限制是逼著驗收標準可測試：「載入要快」改成「在 4G 網路下，首屏 2 秒內完成載入」，測試才知道怎麼判合格。第 5 條的【待補】標記是防幻覺的核心——沒有它，模型會用最合理的猜測填滿所有空白，而猜錯的部分，代價是返工。
拿到草稿後別急著發，先做一件事：把所有【待補】標記集中起來逐條處理。每一條只有三種下場——找到答案填進去、明確寫成「本版不做」、或者帶著這個問題去問能拍板的人。三種都比留著空白強，更都比讓模型猜一個強。另外提醒一句：模板裡的固定結構（背景、用戶、功能、不做的事、驗收標準）是最小可用集，團隊有自己的模板就讓 AI 照你們的結構改，把要求第 1 條的結構名單換掉即可，其他條目照用。
適用場景：草稿完成之後、發給開發之前。這一步模擬的是「文檔評審會」，把開發的追問提前到你自己這裡消化掉。
```
下面是一份 PRD 草稿。你同時扮演兩個角色來審查它：
角色 A：要接手開發的工程師。只挑「會導致你沒法動工、或做完大概率要返工」的問題。每條指出在第幾節，說明你看到這句話時想到的兩種可能理解分別是什麼。
角色 B：負責驗收的測試。只挑「沒辦法客觀判斷合格與否」的條目，並把每一條改寫成可測試的版本。
最後輸出一張匯總表，欄位為：位置｜問題｜兩種可能理解（或不可測的原因）｜建議改法。
禁止任何誇獎和客套；禁止修改你認為沒問題的部分。
【PRD 草稿】：……
```
要替換的變數：只有【PRD 草稿】。把模板二的輸出整份貼進來即可；如果文檔很長，可以分節審，但每次都要把「背景與目標」一起帶上，否則評審會脫離上下文。
為什麼這樣寫：「兩種可能理解」是這段模板的殺手鐧。開發提問的本質就是「這句話有兩種讀法，我做哪個」——讓 AI 把兩種讀法都擺出來，你只需要選一個或補充條件，比等開發在會上問快得多。禁止誇獎這條不能省：不寫，模型會用三分之一的篇幅誇你文檔結構清晰，然後只挑兩條不痛不癢的。
評審結果拿到手，逐條消化時記得分成三類處理：改幾個字就能消除歧義的，直接改；需要補條件、補數字的，回到模板一那套追問，自己定或者找人拍板；還有一小部分會讓你發現「這條需求本身就不該存在」——這是評審最有價值的產出，砍掉它，比改十遍措辭都划算。跑完這一輪再發出去的文檔，開發的追問會少一大半，因為最容易被問倒的地方，已經被你自己的「假開發」問過一遍了。
| 你的處境 | 先用哪段 | 核心動作 | 產出物 |
|---|---|---|---|
| 只有一句話的想法 | 模板一 | 讓 AI 追問，你回答 | 需求盲點清單 |
| 問答做完，要出初稿 | 模板二 | 按固定結構成稿，缺處標【待補】 | PRD 草稿 |
| 草稿完成，發出前 | 模板三 | 雙角色評審，逼出歧義 | 修改清單＋改後終稿 |
三段可以一次跑完，也可以拆開用。時間緊的時候，最省的組合是「模板一＋模板三」：先問清楚，自己動手寫個一頁粗稿，再讓它打回一次——比直接生成一份假完整的長文檔靠譜。
另外兩個常見的坑提前說。一是別在模板二里貼競品資料讓它「參考著寫」——模型的習性是照抄，你貼了 A 產品的截圖，它就會把 A 的流程原樣搬進你的 PRD，連你自己沒打算做的功能都一併搬進來；競品信息應該出現在「不做的事」的決策過程裡，而不是需求正文裡。二是需求變更後別只改正文那一處，把模板三重跑一遍——改動往往會讓別的條目產生新的歧義，人眼檢查不出來，雙角色評審查得出來。
最後一個提醒：AI 產出的 PRD 草稿裡，所有標了【待補】的地方都是它提醒你「這裡只有你知道答案」。把這些空補完再發出去，開發的第一句話就不會再是「這裡到底要做什麼」了。
工具推薦隨身機器人（新用戶免費試用 7 天）
文中三段模板可長期保存、反覆替換變數使用。如果你想要一個隨手就能呼叫、無需折騰配置的對話入口，試試隨身機器人：新用戶免費試用 7 天，把手頭的需求直接丟進去跑一遍模板一，你就知道差在哪了。
下一篇預告：書讀完一個月，隻言片語都記不起來？下篇我們用三段提示詞，把一本書拆成能長期複用的「知識卡片」——讀書筆記與知識卡片，敬請期待。
業州愚公 ｜ SY 視野（sylogs.com）原創內容，轉載請註明出處。