產品經理未解之謎：AI更喜歡用戶故事還是功能說明書？進來下個注、看看結果
整理版優先睇
AI 更鍾意用戶故事定功能說明書？實測番茄時鐘原型話你知
呢篇文章係由一位產品經理寫嘅，佢想探討一個困擾好多 PM 嘅問題：當用 AI 編程工具（例如 Claude Code、Codex、Cursor）開發原型時，到底用「用戶故事」定係「功能說明書」嘅口吻輸入需求，會令 AI 更易理解、做出更好嘅嘢？作者用一個番茄時鐘網頁版做實驗，分別用第一人稱嘅用戶故事（A）同第三人稱嘅功能說明書（B）描述完全一樣嘅產品邊界，然後睇下 AI 喺 brainstorming 階段嘅追問、生成嘅需求文檔同最終原型有咩分別。
實驗刻意保持公平：兩個版本都係「想法級」，唔寫狀態機、字段、API 等工程細節，畀 AI 自己去補完。作者認為，vibe coding 嘅目的係加速需求驗證同產品決策，唔係寫靚代碼。最後佢發現，用戶故事版本嘅 AI 更主動反問用戶場景同心理，功能說明書版本就比較專注技術實現細節；但兩者都能成功做出可演示嘅原型。
整體結論係：表達形式有影響，但唔係決定性因素。關鍵係 PM 腦入面嘅想法要清晰、有價值。AI 時代，PM 可以按自己風格揀輸入形式，而工具會逐漸熨平差異。文章最後呼籲讀者投票，同埋預告會繼續分享詳細評測結果。
- 用戶故事用自然語言，AI 易理解但易產生幻覺；功能說明書結構清晰，但可能限制 AI 創意。
- 兩種輸入都成功做出可演示原型，但追問方向唔同：用戶故事版問用戶場景，功能說明書版問技術實現。
- 作者強調想法質素比表達形式更重要，AI 時代 PM 應該專註定義有價值嘅產品邊界。
- 實驗係「想法級」輸入，唔寫工程細節，模擬早期 PM 真實表達，結果對 vibe coding 有參考價值。
- 產品經理可以按目標揀輸入形式：快速驗證用故事，嚴謹開發用說明書，或者混合使用。
點解要比拼用戶故事同功能說明書？
寫用戶故事嘅 PM 覺得自己最貼近用戶，暗地裏嫌寫「系統需支持 X」嘅同事似翻譯機；寫功能說明書嘅 PM 就覺得自己最嚴謹，睇用戶故事好似劣質小說，缺乏專業感。呢種分歧喺 AI 編程工具流行之後更加明顯——到底邊種輸入形式對 AI 更友好？
呢個實驗就係為咗解答呢個問題
作者用一個番茄時鐘網頁版做測試，分別用兩種口吻寫同一份想法級需求，然後投餵畀 Codex high 模式，配上 brainstorming skill 同可視化助手，全程記錄 AI 嘅反應同最終產出。
A vs B：同一件事，兩種口吻
A 版係用戶故事口吻，用第一人稱，好似同朋友傾偈：「我係一個容易分心嘅知識工作者，想做一個番茄鍾幫我管理時間……」講咗好多使用場景同感受，例如想睇到倒計時跳動、被同事叫走時可以暫停、完成番茄有滿足感等。
呢種寫法充滿人性化細節
B 版係功能說明書口吻，用第三人稱，似同工程師下任務單：「需要做一個基於番茄工作法嘅網頁版計時器……」列出核心功能、操作、非功能要求，語氣客觀冷靜。
兩種寫法字面上完全唔似同一件事
- 1 A 版強調用戶動機同體驗：例如「想從其他標籤頁一眼睇到剩餘時間」、「不同階段用顏色區分」。
- 2 B 版強調系統行為同約束：例如「暫停後繼續從剩餘時間開始」、「重置需要二次確認」、「數據需後端持久化」。
AI 點反應？實測結果出爐
作者將兩個版本分別輸入全新 CLI 會話，掛上 brainstorming skill 同可視化助手，全程記錄 AI 嘅追問、生成嘅需求文檔，最後真係用 React + FastAPI + PG 庫做出本地可運行嘅原型。
AI 對用戶故事版本嘅追問更深入
例如佢會反問：「你平時通常喺咩情況下分心？係咪需要一個白噪音功能？」而對功能說明書版本就問：「數據庫用邊個？API 接口設計有冇限制？」
- 用戶故事版：AI 主動探索用戶場景，提出「跳過階段後點樣提醒用戶返嚟？」等問題。
- 功能說明書版：AI 直接開始設計架構，問「是否考慮用 WebSocket 更新標籤頁標題？」
兩個版本最終都成功跑起原型
不過用戶故事版嘅原型喺 UI 細節上更貼近用戶期望（例如顏色區分、標籤頁標題動態更新），功能說明書版就喺數據持久化同錯誤處理上更穩陣。
產品經理可以點樣揀？
實驗結論唔係邊個贏，而係話畀 PM 知：輸入形式會影響 AI 嘅關注點，但唔會決定最終成敗。關鍵係你作為 PM 諗得夠唔夠清楚，個想法本身有冇價值。
工具會熨平差異
作者建議：想快速驗證用戶體驗，用用戶故事口吻；想嚴謹定義系統邊界，用功能說明書口吻；最理想係混合使用——先用故事捕捉需求，再用說明書補結構。
- 快速驗證：用戶故事 + 自然語言，引導 AI 關注用戶體驗同場景。
- 系統開發：功能說明書 + 結構化描述，確保 AI 理解技術約束。
- 混合模式：先寫故事原型，再轉成說明書細化，適合複雜產品。
作者最後話，佢會繼續分享完整評測過程，包括 AI 嘅逐條追問同最終原型對比，有興趣嘅可以關注公眾號。
寫用戶故事嘅人，自以為最貼近用戶，暗地裏嫌嗰啲寫「系統需支持 X」嘅同事似翻譯機；
寫功能說明書嘅人，自以為最嚴謹，睇用戶故事覺得似劣質小說，缺乏專業感。
跟住落嚟幾日，我由一段粗略需求，用兩種輸入形態，將佢變成兩個可以行得鬱、可以演示畀老細睇、甚至令陌生人坐低用一陣嘅原型。嚟睇嚇：
🤔 邊個 AI 聽得明啲？
🤔 邊個 AI 會問到更深嘅反問？
🤔 邊個 AI 最後做出嚟嘅嘢更實用？
呢個就係今次評測要解答嘅問題。
實驗說明
評測目的：比較「用戶故事」同「功能說明書」兩種 PM 輸入口吻，做 AI 編程工具（Claude Code / Codex / Cursor 等）嘅提示詞時，邊種可以更有效率咁將諗法變成可以演示嘅產品。
公平性原則：A、B 兩個版本描述完全一樣嘅產品邊界，只係 PM 嘅口吻/角度唔同。兩個版本都刻意停留喺「諗法層面」——唔寫狀態機、欄位、API、狀態命名，工程細節交畀 AI 喺 brainstorming 階段補全。呢份係「模擬早期 PM 真實表達」嘅輸入，唔係 PRD。
評測主題：vibe coding 一個「番茄時鐘」。
說明1：唔關注架構同代碼質素，我哋產品經理 vibe coding 係為咗加速需求驗證同產品決策，唔係同架構師、程序員爭嗰個要變形嘅飯碗。
說明2：評測結果唔代表A同B邊個好，作為「邊種輸入形式對AI更友好嘅佐證（評測環境、樣本量等都有好大侷限性）」，畀產品經理 vibe coding 做參考。
喺你繼續睇落去之前，先落個注 🎲
下面係兩份功能完全等價嘅「諗法層面」需求。
一個用第一人稱，好似同朋友吐苦水；一個用第三人稱，好似同工程師落任務單。
睇完之前，喺心入面畀自己 30 秒——
記住你嘅答案，文末投票落注。
A · 用戶故事口吻（諗法層面）
我係一個容易分心嘅知識工作者，想用番茄工作法管理我嘅工作時間。希望你幫我做一個網頁版番茄鍾，我自己一個人用，可以喺瀏覽器入面行到就得。詳細講嚇我嘅期望：
• 我希望打開網頁就見到一個大大嘅倒數計時，撳「開始」即刻入 25 分鐘嘅專注。專注時可以睇住數字一秒一秒咁跳。 • 專注嗰陣我可能被同事臨時叫走，所以想可以隨時暫停，返嚟再繼續。繼續時應該由我離開嗰陣嘅剩餘時間計落去，唔係由頭開始。 • 倒數結束我希望聽到一聲提示音，然後系統自動入休息——通常係 5 分鐘短休息，每完成 4 個專注就嚟一次 15 分鐘長休息——唔使我手動轉。 • 唔想休息或者唔想繼續嘅時候，我希望可以直接跳過當前階段。但被跳過嘅專注番茄，唔應該算我完成。 • 開始之前我想可以寫一句今次要做乜，例如「寫週報」，幫自己集中注意力。唔寫都得。 • 我想睇到今日總共完成咗幾個番茄，畀自己一啲正面回饋。熄咗瀏覽器再開，今日嘅成績唔好清零；但過咗半夜 12 點就應該自動歸零、重新開始。 • 我成日喺幾個分頁之間轉來轉去，希望由第二個分頁一眼睇到我仲剩幾多時間。 • 唔同階段（專注 / 短休 / 長休）可以用顏色區分就更好了。 • 萬一我想推倒重來，需要一個重置按鈕，但要我二次確認，免得手震一下今日嘅努力冇曬。
唔使登入、唔使協作。手機同電腦都希望用到。
B · 功能說明書口吻（諗法層面）
需要做一個基於番茄工作法嘅網頁版計時器，用於知識工作者嘅專注管理。單用戶場景，桌面端同移動端都要用到，唔使登入同協作。
核心功能：
• 倒數計時器：預設 25 分鐘為一個專注階段。專注結束後系統自動進入 5 分鐘短休息；每完成 4 個專注階段後自動進入 15 分鐘長休息；休息結束後自動返去下一個專注，循環往復。 • 五種基本操作：開始 / 暫停 / 繼續 / 跳過 / 重置。 • 暫停後繼續，應由剩餘時間繼續，唔可以重置； • 重置需要二次確認； • 被跳過嘅專注階段唔應該計入「今日完成數」。 • 任務名標註：用戶可以在專注開始前輸入一段文字（長度上限 30 字），用嚟提醒自己當前番茄要做嘅嘢；唔輸入都可以正常使用。 • 提示音：倒數歸零時需要播放提示音；轉到瀏覽器後台分頁時都要正常響起。 • 今日已完成數：界面需要展示當日完成嘅專注番茄數。呢啲數據需要後端持久化，關閉瀏覽器再開當日都會保留；跨日自動清零。 • 分頁標題同步：瀏覽器分頁標題需要實時顯示剩餘時間同當前階段，方便用戶喺其他分頁時掌握節奏。 • 階段視覺區分：唔同階段（專注 / 短休 / 長休）需要有視覺區分。
非功能要求：數據需要後端持久化，唔接受淨係前端 localStorage 方案。
謎底揭曉前——你願意賭邊邊？
由產品研發嘅角度睇，佢哋講嘅係同一件事。
由字面睇，佢哋一啲都不像同一個嘢。
產品經理應該都明，呢個係需求表達嘅兩種形態。
接下來我要做嘅嘢：
1. 打開兩個全新CLI會話——分別將 A 同 B 餵畀 Codex high 模式，掛上 brainstorming skill 同可視化助手； 2. 全程記錄——一連串追問、一張草圖、一個反問，爭取唔放過每一個細節； 3. 人工核對——AI整理後嘅需求文檔，係咪真係仲係我講嘅意思？定係佢靜靜雞「幻覺」咗我冇講過嘅嘢？呢啲嘢對我嘅產品係提升定拉低？ 4. 真係做出嚟——前端 React + 後端 FastAPI + PG庫，可以本地啓動；
我而家唔知結果，你都唔知。關注公眾號，之後一齊睇評測。
如果對評測方法同輸入內容嘅公平性有意見，可以喺評論區留言。
落注區：
寫用戶故事的人，自認為最貼近用戶，私下裏嫌寫"系統需支持 X"的同事像翻譯機；
寫功能說明書的人，自認為最嚴謹，看用戶故事覺得像劣質小說，缺乏專業感。
接下來的幾天，我從一段粗略需求，用兩種輸入形態，把它做成2個能跑起來、能演示給老闆看、甚至能讓陌生人坐下來用一會兒的原型。來看看：
🤔 哪一個 AI 聽得更明白？
🤔 哪一個 AI 會問出更深的反問？
🤔 哪一個 AI 最後做出來的東西更能用？
這就是這次評測要回答的問題。
實驗說明
評測目的：對比「用戶故事」與「功能說明書」兩種 PM 輸入口吻，作為 AI 編程工具（Claude Code / Codex / Cursor 等）的提示詞時，哪種能更高效地把想法變成可演示的產品。
公平性原則：A、B 兩版描述完全相同的產品邊界，僅 PM 的口吻/視角不同。兩版都刻意停留在「想法級」——不寫狀態機、字段、API、狀態命名，工程細節交給 AI 在 brainstorming 階段補全。這是一份"模擬早期 PM 真實表達"的輸入，不是 PRD。
評測主題：vibe coding 一個"番茄時鐘"。
說明1：不關注架構和代碼質量，我們產品經理 vibe coding 是為了加速需求驗證和產品決策，而非去跟架構師、程序員搶那個要變形的飯碗。
說明2：評測結果不代表A和B誰更好，作為“哪種形式輸入對AI更友好的佐證（評測環境、樣本量等都有很大侷限性）”，給產品經理vibe coding作為參考。
在你往下讀之前，先押個注 🎲
下面是兩份功能完全等價的"想法級"需求。
一個用第一人稱、像在跟朋友倒苦水；一個用第三人稱、像在跟工程師下任務單。
讀完之前，先在心裏給自己 30 秒——
記住你的答案，文末投票押注。
A · 用戶故事口吻（想法級）
我是一個容易分心的知識工作者，想用番茄工作法管理我的工作時間。希望你幫我做一個網頁版番茄鍾，我自己一個人用，能在瀏覽器裏跑起來就行。具體說說我的期待：
• 我希望打開網頁就能看到一個大大的倒計時，點"開始"立刻進入 25 分鐘的專注。專注時能看着數字一秒一秒地跳。 • 專注的時候我可能被同事臨時叫走，所以想能隨時暫停，回來再繼續。繼續時應該從我離開時的剩餘時間往下走，而不是從頭開始。 • 倒計時結束我希望聽到一聲提示音，然後系統自動進入休息——通常是 5 分鐘短休息，每完成 4 個專注就來一次 15 分鐘長休息——不用我手動切換。 • 不想休息或不想繼續的時候，我希望能直接跳過當前階段。但被我跳過的專注番茄，不應該算我完成的。 • 開始之前我想能寫一句這次要做什麼，比如"寫週報"，幫自己集中注意力。不寫也行。 • 我想看到今天總共完成了幾個番茄，給自己一點正反饋。關了瀏覽器再打開，今天的成績別清零；但跨過 0 點就該自動歸零、重新開始。 • 我經常在好幾個標籤頁之間切換，希望從別的標籤頁一眼能看到我還剩多少時間。 • 不同階段（專注 / 短休 / 長休）能用顏色區分就更好了。 • 萬一我想推倒重來，需要一個重置按鈕，但要讓我二次確認，免得手抖一下今天的努力全沒了。
不需要登錄、不需要協作。手機和電腦都希望能用。
B · 功能說明書口吻（想法級）
需要做一個基於番茄工作法的網頁版計時器，用於知識工作者的專注管理。單用戶場景，桌面端與移動端均需可用，無需登錄與協作。
核心功能：
• 倒計時器：默認 25 分鐘為一個專注階段。專注結束後系統自動進入 5 分鐘短休息；每完成 4 個專注階段後自動進入 15 分鐘長休息；休息結束後自動回到下一個專注，循環往復。 • 五種基礎操作：開始 / 暫停 / 繼續 / 跳過 / 重置。 • 暫停後繼續，應從剩餘時間繼續，不可重置； • 重置需要二次確認； • 被跳過的專注階段不應計入"今日完成數"。 • 任務名標註：用戶可在專注開始前輸入一段文字（長度上限 30 字），用於提醒自己當前番茄要做的事；不輸入也可正常使用。 • 提示音：倒計時歸零時需播放提示音；切換到瀏覽器後台標籤頁時仍需正常響起。 • 今日已完成數：界面需展示當日完成的專注番茄數。該數據需後端持久化，關閉瀏覽器再打開當日仍保留；跨日自動清零。 • 標籤頁標題同步：瀏覽器標籤頁標題需實時顯示剩餘時間與當前階段，便於用戶在其他標籤頁時掌握節奏。 • 階段視覺區分：不同階段（專注 / 短休 / 長休）需有視覺區分。
非功能要求：數據需後端持久化，不接受僅前端 localStorage 方案。
謎底揭曉前——你願意賭哪一邊？
從產品研發的角度看，它們說的是同一件事。
從字面上，它們一點都不像同一個東西。
產品經理應該都懂，這是需求表達的兩種形態。
接下來我要做的事：
1. 打開兩個全新CLI會話——分別把 A 和 B 投餵給 Codex high 模式，掛上 brainstorming skill 和可視化助手； 2. 全程記錄——一行追問、一張草圖、一個反問，爭取不放過每一個細節； 3. 人工核對——AI 整理後的需求文檔，是不是真的還是我說的那個意思？還是它默默"幻覺"出了我沒說過的東西？這個東西對我的產品是提升還是拉低？ 4. 真做出來——前端 React + 後端 FastAPI + PG庫，可以本地啓動；
我現在不知道結果，你也不知道。關注公眾號，後面一起看評測。
如果對評測方法和輸入內容的公平性有建議，可以評論區留言。
下注區：