用戶故事 vs 功能說明書，AI更愛哪種？評測標準
整理版優先睇
呢篇文介紹一個評測框架，比較用戶故事同功能說明書邊種輸入方式更適合PM用AI編程。
呢篇文章係由一位產品經理（PM）寫嘅，佢想搞清楚一個問題：當用AI編程工具（例如Codex CLI）嚟將粗略需求變成可演示嘅產品時，PM用「用戶故事」定係「功能說明書」嘅口吻會更快見效？作者唔係關心代碼質量，而係想加速需求驗證同產品決策。所以佢設計咗一個好嚴謹嘅評測框架，用證據去支持或推翻三個假設。
評測環境設定得好詳細：工具鏈用Claude Code做編排，Codex CLI做主力編碼，仲有個brainstorming skill輔助澄清。技術棧係React+Vite+FastAPI+PG，確保PM可以驗證完整業務閉環，唔係得個前端樣板。輸入材料分A組（用戶故事）同B組（功能說明書），兩組功能邊界嚴格等價，只係口吻唔同。工作流程分六個階段，由PM輸入需求開始，到AI整理、PM核對、編碼實現、本地驗收，最後評分。
評測有五個維度：需求易讀性、意圖識別準確度、Skill反饋深度、編碼效果、端到端效率。仲有一份12項嘅驗收清單，例如一鍵啟動、後端真係存在、倒計時精準呢啲。作者希望透過呢個框架，俾出一個PM實踐建議。如果你對評測方法有意見，可以私信或留言。
- 評測比較用戶故事（第一人稱、口語化）與功能說明書（第三人稱、規範化）兩種PM輸入方式，從五個維度衡量效率。
- 假設：功能說明書意圖識別更準，用戶故事更能激發AI主動澄清，但最終可用性差距不大。
- 控制變量嚴格：同一PM、全新會話、迭代上限3輪、人工修訂只改不補。
- 技術棧要求全棧（React+Vite+FastAPI+PG），確保PM驗證業務閉環。
- 驗收清單包含12項具體功能點，如後端真實存在、倒計時精準、不同階段主題色等。
內容片段
[階段 1] PM 輸入粗略需求 (A 或 B) │ ▼[階段 2] Codex · brainstorming + visual-companion │ ① 複述意圖 ② 主動澄清（必要時配可視化） ③ 輸出"整理後的需求文檔" ▼[階段 3] PM 人工核對修訂 ★評測點★ │ 對照原文逐句檢查：意圖識別是否準、覆蓋是否全、有無誤讀、有無幻覺 │ 記錄修訂量（增/刪/改的條目數與字符數） ▼[階段 4] Codex high · 實現計劃 + 編碼 │ 生成 monorepo：frontend/ + backend/ + db/schema.sql ▼[階段 5] 本地啓動 + 驗收 │ 按 §3.4 驗收清單逐項驗證 + 盲測試用 → 必要時迭代（≤2 輪追問） ▼[階段 6] 評分彙總評測背景與核心問題
呢篇文嘅核心問題係：PM用「用戶故事」定係「功能說明書」嘅口吻，可以更快將想法變成可演示嘅產品？作者嘅立場係PM vibe coding嘅目標係加速需求驗證同產品決策，唔係同工程師爭代碼質量。
用戶故事 vs 功能說明書：邊種更快將想法變成可演示嘅產品？
- H1：功能說明書讓AI嘅意圖識別準確率更高（整理產物與原文偏差更細）。
- H2：用戶故事更能激發AI主動澄清（提問更深、覆蓋隱藏需求）。
- H3：喺≤3輪迭代內，兩種輸入嘅最終產品可用性可收斂（差距唔顯著）。
評測環境與方法
評測工具鏈：用Claude Code做外層編排，負責將PM嘅話轉交給Codex；Codex CLI（high reasoning模式）做主力，負責具體澄清同編碼。仲有強制啟用嘅brainstorming skill同visual-companion，用嚟展示mockup、狀態機、數據模型等。技術棧係React+Vite+FastAPI+PG，因為PM要驗證嘅係業務閉環，唔係得個前端。
Claude Code
Codex CLI
brainstorming skill
visual-companion
React+Vite+FastAPI+PG
業務閉環
- 1 階段1：PM輸入粗略需求（A或B口吻）。
- 2 階段2：Codex用brainstorming + visual-companion複述意圖、主動澄清、輸出整理後需求文檔。
- 3 階段3：PM人工核對修訂，記錄修正量（係評測點之一）。
- 4 階段4：Codex生成實現計劃同編碼，產生monorepo。
- 5 階段5：本地啟動並按驗收清單驗證，必要時迭代（≤2輪追問）。
- 6 階段6：評分彙總。
評測維度與驗收標準
評測有五個維度，對應工作流嘅關鍵節點：人讀→AI懂→人核對→Skill問→演示出。分別係：需求易讀性、意圖識別準確度、Skill反饋深度、編碼效果、端到端效率。
需求易讀性
意圖識別準確度
Skill反饋深度
編碼效果
端到端效率
- 一鍵啟動，無報錯
- 後端真存在：API可被curl，數據寫進SQLite（非mock）
- 25分鐘專注結束後自動進入5分鐘短休息
- 完成4個專注後下一次休息為15分鐘（長休息）
- 暫停後繼續，剩餘時間精準（誤差<1秒）
- 跳過專注階段時「今日完成數」唔增加
- 重置後所有計數歸位且需二次確認
- 完成數跨天自動清零，關閉瀏覽器再開仍保留當日數據
核心問題：作為 AI 編程工具嘅粗略需求輸入，PM 用「用戶故事」定係「功能說明書」邊種口吻，可以更快將想法變成可以演示、可以被外部用戶試用嘅產品？
立場：PM vibe coding 嘅目標係加快需求驗證同產品決策，唔係同工程師爭代碼質量。所以呢個評測唔會打代碼風格分，睇嘅係「想法到可演示」嘅端到端效率。
1. 評測假設
評測目的係用證據去證偽或者支持上面三條假設，俾出 PM 實踐建議。
2. 評測環境
2.1 工具鏈
| Claude Code | ||
| 需求澄清＋編碼 | Codex CLI | superpowers:brainstorming skill |
| 強制啟用 |
2.2 技術棧（兩組完全一致）
• 前端：React + Vite • 後端：FastAPI（Python 3.11） • 數據庫：PG
點解要求全棧而唔係單文件 HTML：PM vibe coding 驗證嘅唔淨止係「前端用唔用得」，更加係「業務閉環行唔行得通」。
2.3 輸入材料
• A 組（用戶故事口吻）：第一人稱、口語化、諗法級 • B 組（功能說明書口吻）：第三人稱、規範化、諗法級 • 兩個版本功能邊界嚴格等價，淨係 PM 口吻同視角唔同 • 兩個版本都刻意停留喺諗法級：唔包含狀態機、字段、API、狀態命名等工程細節，工程細節由 AI 喺階段 2 補番
2.5 工作流（兩組完全一致）
[階段 1] PM 輸入粗略需求 (A 或 B)
│
▼
[階段 2] Codex · brainstorming + visual-companion
│ ① 複述意圖 ② 主動澄清（必要時配可視化） ③ 輸出"整理後的需求文檔"
▼
[階段 3] PM 人工核對修訂 ★評測點★
│ 對照原文逐句檢查：意圖識別是否準、覆蓋是否全、有無誤讀、有無幻覺
│ 記錄修訂量（增/刪/改的條目數與字符數）
▼
[階段 4] Codex high · 實現計劃 + 編碼
│ 生成 monorepo：frontend/ + backend/ + db/schema.sql
▼
[階段 5] 本地啓動 + 驗收
│ 按 §3.4 驗收清單逐項驗證 + 盲測試用 → 必要時迭代（≤2 輪追問）
▼
[階段 6] 評分彙總2.6 控制變量
• 同一個 PM、同一時段、相同嘅提示前綴（見 §4.3） • 每組開全新 Codex 會話，避免上文下理污染 • 每組由階段 4 開始嘅迭代上限 3 輪（包括初次生成） • 階段 3 嘅人工修訂淨係改唔補：只能夠修正 AI 誤讀、幻覺、漏讀，唔可以喺修訂稿度補加原文冇嘅功能 • 階段 2 PM 淨係回答 AI 提出嘅問題，唔主動追加文件以外嘅資訊
3. 評測維度
五個維度對應工作流嘅關鍵節點：人讀 → AI 明 → 人核對 → Skill 問 → 演示出。
3.1 維度 1 · 需求易讀性（Human-side · 階段 1）
PM 自己讀兩份文件嘅體驗，重點關注：閲讀時間、翻睇次數、主觀感覺嘅清晰度同資訊密度。
3.2 維度 2 · 意圖識別準確度（AI-side · 階段 3）
Codex 整理出嚟嘅嘢同 PM 原意嘅吻合度。重點關注：漏咗需求要扣分、提出有效需求補充就加分
3.3 維度 3 · Skill 反饋深度（Process-side · 階段 2）
同一個 brainstorming skill 加 visual-companion 喺兩種輸入底下行為有咩唔同，邊個對需求優化嘅幫助更大。
3.4 維度 4 · 編碼效果（Output-side · 階段 5）
最終交付嘅演示係咪真係用得，編碼來回修改嘅次數同時間。
4. 驗收清單
• [ ] 啟動順利：一撳就起，冇報錯 • [ ] 後端真係存在：API 接口可以用 curl 存取，而且數據真係寫入 SQLite（唔係 mock） • [ ] 25 分鐘專注完咗之後自動進入 5 分鐘短休息 • [ ] 完成 4 個專注之後下一次休息係 15 分鐘（長休息） • [ ] 暫停之後繼續，剩餘時間準確（誤差 < 1 秒） • [ ] 跳過專注階段嘅時候「今日完成數」唔會增加 • [ ] 重置之後所有計數歸零同埋需要二次確認 • [ ] 完成數跨日自動清零，閂咗瀏覽器再開仍然保留當日數據 • [ ] 切去後台標籤頁之後倒計時依然準確 • [ ] 提示音喺後台標籤頁識響 • [ ] 標籤頁標題實時反映剩餘時間同階段 • [ ] 唔同階段用唔同主題色
4. 評測流程
核心問題：作為 AI 編程工具的粗略需求輸入，PM 用「用戶故事」還是「功能說明書」哪種口吻，能更快把想法變成可演示、可被外部用戶試用的產品？
立場：PM vibe coding 的目標是加速需求驗證和產品決策，不是跟工程師爭代碼質量。所以本評測不打代碼風格分，看的是"想法到可演示"的端到端效率。
1. 評測假設
評測目的是用證據證偽/支持以上三條假設，給出 PM 實踐建議。
2. 評測環境
2.1 工具鏈
| Claude Code | ||
| 需求澄清 + 編碼 | Codex CLI | superpowers:brainstorming skill |
| 強制啓用 |
2.2 技術棧（兩組完全一致）
• 前端：React + Vite • 後端：FastAPI（Python 3.11） • 數據庫：PG
為何要求全棧而不是單文件 HTML：PM vibe coding 驗證的不只是"前端能不能用"，更是"業務閉環能不能跑通"。
2.3 輸入材料
• A 組（用戶故事口吻）：第一人稱、口語化、想法級 • B 組（功能說明書口吻）：第三人稱、規範化、想法級 • 兩版功能邊界嚴格等價，僅 PM 口吻/視角不同 • 兩版都刻意停留在想法級：不含狀態機、字段、API、狀態命名等工程細節，工程細節由 AI 在階段 2 補全
2.5 工作流（兩組完全一致）
[階段 1] PM 輸入粗略需求 (A 或 B)
│
▼
[階段 2] Codex · brainstorming + visual-companion
│ ① 複述意圖 ② 主動澄清（必要時配可視化） ③ 輸出"整理後的需求文檔"
▼
[階段 3] PM 人工核對修訂 ★評測點★
│ 對照原文逐句檢查：意圖識別是否準、覆蓋是否全、有無誤讀、有無幻覺
│ 記錄修訂量（增/刪/改的條目數與字符數）
▼
[階段 4] Codex high · 實現計劃 + 編碼
│ 生成 monorepo：frontend/ + backend/ + db/schema.sql
▼
[階段 5] 本地啓動 + 驗收
│ 按 §3.4 驗收清單逐項驗證 + 盲測試用 → 必要時迭代（≤2 輪追問）
▼
[階段 6] 評分彙總2.6 控制變量
• 同一 PM、同一時段、相同的提示前綴（見 §4.3） • 每組開全新 Codex 會話，避免上下文污染 • 每組從階段 4 起的迭代上限 3 輪（含初次生成） • 階段 3 的人工修訂只改不補：只能修正 AI 誤讀/幻覺/漏讀，不能向修訂稿補加原文沒有的功能 • 階段 2 PM 只回答 AI 提的問題，不主動追加文檔外信息
3. 評測維度
五個維度對應工作流的關鍵節點：人讀 → AI 懂 → 人核對 → Skill 問 → 演示出。
3.1 維度 1 · 需求易讀性（Human-side · 階段 1）
PM 自己讀兩份文檔的體驗，重點關注：閲讀耗時、回看次數、主觀感受的清晰度和信息密度。
3.2 維度 2 · 意圖識別準確度（AI-side · 階段 3）
Codex 整理產物與 PM 原意的吻合度。重點關注：遺漏需求扣分、提出有效需求補充加分
3.3 維度 3 · Skill 反饋深度（Process-side · 階段 2）
同一個 brainstorming skill + visual-companion 在兩種輸入下行為有何不同，哪個對需求優化的幫助更大。
3.4 維度 4 · 編碼效果（Output-side · 階段 5）
最終交付的演示是否真能用，編碼反覆的次數和時間。
4. 驗收清單
• [ ] 啓動順利： 一鍵起，無報錯 • [ ] 後端真存在：API 接口可被 curl，且數據真寫進 SQLite（非 mock） • [ ] 25 分鐘專注結束後自動進入 5 分鐘短休息 • [ ] 完成 4 個專注後下一次休息為 15 分鐘（長休息） • [ ] 暫停後繼續，剩餘時間精準（誤差 < 1 秒） • [ ] 跳過專注階段時"今日完成數"不增加 • [ ] 重置後所有計數歸位且需二次確認 • [ ] 完成數跨天自動清零，關閉瀏覽器再開仍保留當日數據 • [ ] 切到後台標籤頁後倒計時依然準確 • [ ] 提示音在後台標籤頁能響 • [ ] 標籤頁標題實時反映剩餘時間與階段 • [ ] 不同階段使用不同主題色