用戶故事 vs 功能說明書，選擇判斷標準的分水嶺是什麼？評測後的三條幹貨建議
整理版優先睇
用戶故事與功能說明書非二選一，而是根據問題成熟度接力使用：模糊想法用故事揾方向，清晰規格用說明書鎖邊界。
呢篇文章係作者對用戶故事同功能說明書兩種餵畀AI嘅口吻嘅評測覆盤。作者本身係產品經理，做咗一個Vibe Coding評測系列，通過AB測試比較兩種模式嘅表現。佢發現，兩種口吻唔係好壞之分，而係取決於「問題成熟度」：當你重未諗清楚件事係乜，用用戶故事可以逼AI幫你發掘模糊位；當你已經諗掂曬，用功能說明書可以令AI順住約束穩步推進。A組（用戶故事）贏在發散，B組（功能說明書）贏在收斂。
作者進一步分析，AI會跟住你畀嘅「錨點」往下推，而且唔會幫你補你唔知嘅嘢。即係如果你唔寫「未來要做報表」，AI唔會自動保留未來擴展空間。呢個發現對PM好重要：用戶故事適合資深PM做需求驗證，但對新人反而更危險，因為AI會順住佢嘅模糊做出一個看似可行但跑唔遠嘅玩具。相反，功能說明書嘅「自信」對應嘅係工程師角色嘅本分，唔應該扣分。
最後作者提出嘅最終結論係：PM應該根據自己處於需求生命週期嘅邊個階段，切換對應口吻。初期用用戶故事做發散，中期修訂成功能說明書，後期交畀AI做工程實現。佢仲畀咗三條實操建議，包括唔好故意省略技術約束、將中間產物視為獨立文檔、同埋警惕AI提出嘅「提升類提示」。呢篇文章對所有用AI做產品開發嘅PM都極具參考價值。
- 用戶故事適合需求模糊時做發散探索，功能說明書適合需求清晰時鎖定工程邊界。
- AI會跟住你畀嘅「錨點」推展，唔會補你無講嘅未來需求。
- 資深PM用用戶故事有紅利，但新人用反而更危險，因為AI會順住模糊做出跑唔遠嘅玩具。
- 功能說明書嘅「自信」係應該嘅，因為工程師收到PRD後唔應該再質疑範圍。
- 真實做法係接力：先用用戶故事挖需求，再修訂成功能說明書，最後交畀AI做實現。
用戶故事模式產品原型
體驗用戶故事模式下做出嘅產品原型
核心結論：問題成熟度決定口吻
作者比較咗用戶故事同功能說明書兩種口吻後發現，你嘅選擇取決於問題成熟度：如果你重未諗清楚件事係乜，用用戶故事可以逼AI幫你發掘模糊位；如果你已經諗掂曬，用功能說明書可以令AI順住約束穩步推進。
問題成熟度係分水嶺
發散與收斂
關鍵差異：AI點樣跟住錨點行
作者發現兩條關鍵規律：第一，AI會跟住你畀嘅錨點往下推。你畀故事，佢錨到用戶場景；你畀規格，佢錨到約束條款。第二，AI唔會幫你補「你不知道你不知道」嘅事。如果你唔寫未來要做報表，佢唔會自動保留擴展空間。
錨點決定形狀
你不知道你不知道
隱含意圖與硬約束
- A組（用戶故事）：AI切入用戶語義，追問隱含意圖；推薦純前端靜態方案，需要PM手動拉返去服務端。
- B組（功能說明書）：AI直接進入服務端方案，一次到位；追問技術選型，如SQLite定Postgres。
- A組最終文檔：用戶故事殼+工程化骨架；B組：一份可執行規格。
修正與補充：接力而非二選一
作者最初認為「用戶故事=需求驗證，功能說明書=工程化SDD」，但經過分析提出三點修正。
資深PM紅利
- 1 修正一：A組嘅「高光」相當一部分係資深PM紅利，換新人用用戶故事反而更危險，AI會順住模糊做出跑唔遠嘅玩具。
- 2 修正二：B組AI嘅「自信」對應工程師本分，唔係bug；用工程師標尺量可能滿分。
- 3 修正三：真實做法係接力——先用用戶故事挖需求，再修訂成功能說明書，最後交畀AI做工程實現。
接力取代二選一
三條實操建議
作者畀咗三條具體建議，值得所有PM記低。
- 第一，唔好喺用戶故事度故意省略技術約束。如果你已經知道未來要做報表，就寫出嚟，AI唔會幫你保留你冇講嘅未來。
- 第二，將「中間產物」當成獨立文檔形態。唔好糾結佢寫得似唔似傳統用戶故事，因為佢係畀下一個AI讀嘅，唔係畀人讀嘅。
- 第三，警惕AI幫你「加分」嘅提升類提示。AI提出嘅「不如加埋XX」，默認先拒絕，除非你講得出佢服務邊個核心場景。
省略技術約束好危險
中間產物係畀AI讀
提升類提示要警惕
核心場景先好加
呢個係 Vibe Coding PRD評測系列嘅覆盤，評測實錄：
產品經理Vibe Coding 評測實錄：用戶故事模式嘅高光同風險
Vibe Coding 評測實錄：功能說明書令 AI 更穩，亦更自信
作為產品經理，下次開一個新需求，到底應該用邊種口吻餵俾 AI？
我嘅評測意見係：用戶故事同功能說明書唔係好壞之分，而係「問題成熟度」之分：
• 你個心仲未諗清楚呢件事係乜 → 用用戶故事，等 AI 幫你逼出模糊嘅地方。 • 你個心已經諗清楚咗，只係冇寫規範 → 用功能說明書，等 AI 順住約束推落去。
A 組（用戶故事）贏在發散，B 組（功能說明書）贏在收斂。兩組嘅差距唔係「AI 更鍾意邊個」，而係 PM 喺前一秒將自己放咗喺邊個角色。
2. 兩組過程嘅關鍵差異
兩條規律值得劃重點：
規律一：AI 會按你俾嘅「錨點」推落去。 錨點唔同，最後文檔嘅形狀都唔同。
你畀故事，佢錨到用戶場景、追問隱含意圖；
你畀規格，佢錨到約束條款、追問技術選型。
規律二：AI 唔會幫你補「你唔知你唔知」嘅事。
A 組之所以差啲將個項目做咗純前端，唔係因為用戶故事唔夠好，而係因為原文冇寫「以後要做報表」。
AI 幫你挖咗用戶視角嘅隱含需求，但挖唔出產品戰略視角嘅隱含需求 —— 除非你主動話畀佢知。
3. 點解呢個唔係「二選一」：思考同自我批評
我睇完過程同結果，第一個反應嘅判斷係：用戶故事=需求驗證，功能說明書=工程化 SDD。但經過分析，提出三處補充同修正：
修正一：A 組嘅「高光」，相當一部分係「資深 PM 紅利」。
A 組將架構由純前端拉返去 PG，唔係 AI 嘅功勞，係 PM 嘅功勞。換一個冇架構常識嘅 PM 行同樣嘅用戶故事：AI 推薦純前端靜態 → PM 覺得「AI 比我識，聽佢嘅」 → 做 Kanban 嗰陣成個 codebase 要重寫。
所以更精確嘅版本係：用戶故事適合「已經知道結局、但當下需求模糊」嘅資深 PM 做需求驗證。
對新人 PM 反而更危險 —— AI 會順住佢嘅模糊，人機合力做出一個睇落行得鬱、但係行唔遠嘅玩具。
修正二：B 組「AI 過於自信」唔係 bug，係 feature。
SDD 嘅前提，本來就係規格已經經過決策。真實研發體系入面，長期路線圖可能喺另一份產品規劃文檔裏面，跨模塊依賴可能喺架構評審裏面討論過，呢一版範圍俾產品總監同技術負責人顯式鎖死。
工程師收到 PRD 之後唔應該再追問「未來使唔使擴展更大嘅系統」—— 呢個唔係佢嘅判斷範圍。
所以 B 組 AI 嘅「自信」對應嘅係工程師角色嘅本分。我之前俾嘅分數低，係因為我拎住「PM 需求驗證」嘅標尺去量佢。換做「工程師收到可以開工」嘅標尺，可能係 8 分甚至滿分。
修正三：邊個更好？真正嘅答案係「接力」，唔係「二選一」。
我自己做過一個定義：
AI 產出嘅嘢，下一步係畀 AI 用定係畀人用，其實係完全唔同嘅兩種需求文檔。
呢句說話模糊指向咗答案，但當時冇展開。真實嘅 PM vibe coding 應該係前後接力。
A 組 PM 自評 9 分嗰個產物，其實就係呢條接力鏈嘅中段交付物 —— 披住用戶故事外皮嘅功能說明書。
| 用戶故事 | ||
| 用戶故事 → 修訂 → 功能說明書 | ||
| 功能說明書 | ||
| 功能說明書 | ||
| 用戶故事 |
5. 畀 PM 嘅三條實操建議
1. 唔好喺用戶故事裏面「故意省略」技術約束。 如果你已經知道「呢樣嘢未來要做報表」，就喺用戶故事裏面寫出嚟。AI 唔會幫你保留你冇講嘅未來。
2. 將「中間產物」當做一種獨立文檔形態嚟對待。 唔好糾結佢寫得像唔像傳統用戶故事 —— 佢本來就唔係畀人讀嘅，係畀下一個 AI 讀嘅。交付物形態由下游使用者決定，AI 係新嘅下游。
3. 警剔 AI 幫你「加分」嘅提升類提示。 三種佈局合一，本質係鍍金，唔係核心需求。AI 喺 brainstorming 階段提出嘅所有「使唔使都加上 XX」，默認先拒絕，除非你講得出佢服務邊個核心場景。
6. 最後一句
「用戶故事 = 需求驗證，功能說明書 = 工程化 SDD」喺形狀上係啱嘅，但佢假設咗 PM 係一個穩定、單一嘅角色。
真實情況係：同一個 PM 喺一個需求嘅生命週期裏面會切換兩次角色 —— 早期係需求發現者，後期係工程對接者。所以更準確嘅命題係：
唔係 PM 應該揀邊種口吻，而係 PM 應該知道自己而家處於需求生命週期邊個階段、對應用邊種口吻。
5:5 嘅平局其實就係呢個結論嘅體現 —— 投票嘅人冇站錯隊，佢哋只係企咗喺唔同階段嘅視角。
AI 時代嘅各種方法論、工具鏈同實踐日日都出「炸裂」款，但營銷賣課嘅太多，唔易甄別。針對 PM 嘅一個關鍵實踐，我還是更穩妥咁進行咗測試同自我內化，歡迎各位專家批評指正。
亦可以去我嘅呢個產品集網站體驗一下用戶故事模式下做出嚟嘅產品原型：https://stemlearn.cloud/
這是 Vibe Coding PRD評測系列的覆盤，評測實錄：
產品經理Vibe Coding 評測實錄：用戶故事模式的高光與風險
Vibe Coding 評測實錄：功能說明書讓 AI 更穩，也更自信
作為產品經理，下次啓動一個新需求，到底該用哪種口吻餵給 AI？
我的評測意見是：用戶故事和功能說明書不是好壞之分，而是「問題成熟度」之分：
• 你心裏還沒想清楚這件事是什麼 → 用用戶故事，讓 AI 替你把模糊的地方逼出來。 • 你心裏已經想清楚了，只是沒寫規範 → 用功能說明書，讓 AI 順着約束往下推。
A 組（用戶故事）贏在發散，B 組（功能說明書）贏在收斂。兩組的差距不是「AI 更喜歡誰」，而是 PM 在前一秒鐘把自己放在了哪個角色。
2. 兩組過程的關鍵差異
兩條規律值得劃重點：
規律一：AI 會按你給的「錨點」往下推。 錨點不同，最後文檔的形狀也不同。
你給故事，它錨到用戶場景、追問隱含意圖；
你給規格，它錨到約束條款、追問技術選型。
規律二：AI 不會替你補「你不知道你不知道」的事。
A 組之所以差點把項目做成純前端，不是因為用戶故事不夠好，而是因為原文沒寫"以後要做報表"。
AI 幫你挖出了用戶視角的隱含需求，但挖不出產品戰略視角的隱含需求 —— 除非你主動告訴它。
3. 為什麼這不是"二選一"：思考和自我批評
我看完過程和結果，第一反應下的判斷是：用戶故事=需求驗證 ，功能說明書=工程化 SDD。但經過分析，提出三處補充和修正：
修正一：A 組的"高光"，相當一部分是「資深 PM 紅利」。
A 組把架構從純前端拉回 PG，不是 AI 的功勞，是 PM 的功勞。換一個沒有架構常識的 PM 跑同樣的用戶故事：AI 推薦純前端靜態 → PM 覺得"AI 比我懂，聽它的" → 做 Kanban 時整個 codebase 重寫。
所以更精確的版本是：用戶故事適合"已經知道終局、但當下需求模糊"的資深 PM 做需求驗證。
對新人 PM反而更危險 —— AI 會順着他的模糊，人機合力做出一個"看起來能跑、其實跑不遠"的玩具。
修正二：B 組"AI 過於自信"不是 bug，是 feature。
SDD 的前提，本來就是規格已經經過決策。真實研發體系裏，長期路線圖可能在另一份產品規劃文檔裏，跨模塊依賴可能在架構評審裏討論過，這一版範圍被產品總監和技術負責人顯式鎖死。
工程師收到 PRD 後不該再追問"未來要不要擴展更大的系統" —— 這不是他的判斷範圍。
所以 B 組 AI 的"自信"，對應的是工程師角色的本分。我之前給的分數低，是因為我拿着「PM 需求驗證」的標尺去量它。換成「工程師拿到能開幹」的標尺，可能是 8 分甚至滿分。
修正三：誰更好？真正的答案是「接力」，不是"二選一"。
我自己做過一個定義：
AI 產出的東西，下一步是給 AI 用還是給人用，其實是完全不同的兩種需求文檔。
這句話模糊指向了答案，但當時沒展開。真實的 PM vibe coding 應該是前後接力。
A 組 PM 自評 9 分的那個產物，其實就是這條接力鏈的中段交付物 —— 披着用戶故事外皮的功能說明書。
| 用戶故事 | ||
| 用戶故事 → 修訂 → 功能說明書 | ||
| 功能說明書 | ||
| 功能說明書 | ||
| 用戶故事 |
5. 給 PM 的三條實操建議
1. 不要在用戶故事裏"故意省略"技術約束。 如果你已經知道"這個東西未來要做報表"，就在用戶故事裏寫出來。AI 不會替你保留你沒說的未來。
2. 把"中間產物"當成一種獨立文檔形態來對待。 別糾結它寫得像不像傳統用戶故事 —— 它本來就不是給人讀的，是給下一個 AI 讀的。交付物形態由下游使用者決定，AI 是新的下游。
3. 警惕 AI 幫你"加分"的提升類提示。 三種佈局合一本質是鍍金，不是核心需求。AI 在 brainstorming 階段提出的所有"要不要也加上 XX"，默認先拒絕，除非你能說出它服務於哪個核心場景。
6. 最後一句
「用戶故事 = 需求驗證 ，功能說明書 = 工程化 SDD」在形狀上是對的，但它假設了 PM 是一個穩定的、單一的角色。
真實情況是：同一個 PM 在一個需求的生命週期裏會切換兩次角色 —— 早期是需求發現者，後期是工程對接者。所以更準確的命題是：
不是 PM 應該選哪種口吻，而是 PM 應該知道自己現在處在需求生命週期的哪個階段、對應用哪種口吻。
5:5 的平局其實就是這個結論的體現 —— 投票的人沒站錯隊，他們只是站在了不同階段的視角。
AI時代的各種方法論、工具鏈和實踐天天出“炸裂”款，但營銷賣課的太多，不好甄別。針對PM的一個關鍵實踐，我還是更穩妥地進行了測試和自我內化，歡迎各位專家批評指正。
也可以去我的這個產品集網站體驗一下用戶故事模式下做出來的產品原型：https://stemlearn.cloud/