目的

建立清晰簡潔的使用者故事，結合 Mike Cohn 的使用者故事格式與 Gherkin 風格的驗收條件。用於將使用者需求轉化為可執行的開發工作，聚焦於成果、確保產品與工程團隊之間有共同理解，並提供可測試的成功標準。

這不是功能規格書，而是一個對話起點，捕捉誰受益、他們想做什麼、為什麼重要，以及如何確認它有效。

輸入

最佳搭配： 故事所捕捉的功能或使用者需求。
也適用： 使用者角色、他們想要的成果，以及驗收條件必須涵蓋的邊界案例。

任何在呼叫時提供的內容——技能名稱後的文字、貼上的上下文，或附加的 ARGUMENTS: 行——都視為已提供的答案。直接使用並跳過已涵蓋的部分，不要重複詢問。

空手而來？也沒問題。 技能會在草擬故事和 Gherkin 條件前，先詢問使用者是誰以及他們想達成什麼。

範例呼叫： Write user stories for password reset via SMS for our banking app — include the lockout edge case.

關鍵概念

Mike Cohn + Gherkin 格式

使用者故事結合了：

使用案例（Mike Cohn 格式）：

作為一個 [使用者角色/身份]
我想要 [達成成果的行動]
以便 [期望的成果]

驗收條件（Gherkin 格式）：

情境： [情境的簡短描述]
Given： [初始上下文或前提條件]
and Given： [額外前提條件]
When： [觸發行動的事件]
Then： [預期結果]

為什麼這個結構有效

以使用者為中心： 強制聚焦於誰受益以及為什麼
成果導向： 「以便」強調交付的價值，而不只是行動
可測試： Gherkin 驗收條件具體且可驗證
對話式： 故事是討論的開端，而非最終規格
共同語言： 產品、工程和 QA 都理解這個格式

反模式（這不是什麼）

不是任務： 「作為一個開發者，我想要重構資料庫」（這是技術任務，不是使用者價值）
不是功能列表： 「我想要儀表板、報表和分析」（太大，需要拆分）
不是模糊描述： 「我想要更好的體驗」（無法衡量，沒有明確成果）
不是合約： 故事是對話的佔位符，不是鎖定的規格

何時使用

將使用者需求轉化為開發工作
待辦事項梳理和衝刺規劃
向工程和設計團隊傳達價值
確保在開發前存在可測試的驗收條件

何時不使用

純技術債或重構（改用工程任務）
故事太大時（先拆分——參見 skills/user-story-splitting/SKILL.md）
在了解使用者問題之前（先撰寫問題陳述）

應用

步驟 1：收集背景

在撰寫故事前，確保你具備：

使用者角色： 這是為誰設計的？（參考 skills/proto-persona/SKILL.md）
問題理解： 這解決了什麼需求？（參考 skills/problem-statement/SKILL.md）
期望成果： 成功是什麼樣子？
限制條件： 技術、時間或範圍限制

如果缺少背景： 先進行探索性訪談或問題驗證工作。

可選輔助腳本（範本產生器）

如果你想要一致的 Markdown 模板，可以從 CLI 輸入產生。此腳本是確定性的，不會擷取資料或寫入檔案。

python3 scripts/user-story-template.py --persona \"試用使用者\" --action \"使用 Google 登入\" --outcome \"無需建立新密碼即可存取應用程式\"

步驟 2：撰寫使用案例

使用 template.md 取得完整的填空結構。

填入範本：

### 使用者故事 [ID]：

- **摘要：** [簡短、好記的標題，聚焦於使用者的價值]

#### 使用案例：
- **作為一個** [如有名稱則用使用者名稱，否則用角色，否則用身份]
- **我想要** [使用者為達成成果所採取的行動]
- **以便** [期望的成果]

品質檢查：

「作為一個」的具體性： 是特定角色（例如「試用使用者」）還是通用（「使用者」）？
「我想要」的清晰度： 這是使用者採取的行動，還是你要建立的功能？
「以便」的成果： 是否解釋了使用者的動機？還是只是重述行動？

常見錯誤：

❌ 「作為一個使用者，我想要一個登入按鈕，以便我可以登入」（重述行動）
✅ 「作為一個試用使用者，我想要使用 Google 登入，以便我可以無需建立新密碼即可存取應用程式」

步驟 3：撰寫驗收條件

填入範本：

#### 驗收條件：

- **情境：** [簡短、易讀的情境描述，說明價值]
- **Given：** [初始上下文或前提條件]
- **and Given：** [額外上下文或前提條件]
- **and Given：** [視需要增加的上下文]
- **and Given：** [以 UI 為主的上下文，確保「When」可以發生]
- **and Given：** [以成果為主的上下文，確保「Then」被交付]
- **When：** [觸發行動的事件——與「我想要」對齊]
- **Then：** [預期結果——與「以便」對齊]

品質檢查：

多個 Given 是允許的： 前提條件可以堆疊（例如「Given 我已登入」+「Given 我的購物車中有商品」）
只有一個 When： 如果你需要多個「When」陳述，很可能有多個故事——請拆分它們
只有一個 Then： 如果你需要多個「Then」陳述，很可能有多個故事——請拆分它們
對齊： 「When」是否與「我想要」匹配？「Then」是否與「以便」匹配？

紅旗：

多個 When/Then： 範圍蔓延的跡象——拆分故事（參考 skills/user-story-splitting/SKILL.md）
模糊的 Then： 「Then 我看到效能改善」（無法衡量——請具體化）

步驟 4：加入摘要

撰寫一個簡短、好記的摘要，捕捉故事的價值：

- **摘要：** [簡短、易讀的標題]

範例：

✅ 「允許試用使用者使用 Google 登入，以減少註冊障礙」
✅ 「大量刪除項目，為進階使用者節省時間」
❌ 「加入刪除按鈕」（以功能為中心，非價值為中心）

步驟 5：驗證與優化

向團隊大聲朗讀： 每個人都理解誰、什麼、為什麼嗎？
測試驗收條件： QA 能否從中撰寫測試案例？
檢查是否需要拆分： 如果故事感覺太大，使用 skills/user-story-splitting/SKILL.md
確保可測試性： 你能證明「Then」發生了嗎？

範例

請參閱 examples/sample.md 取得完整範例（好、壞和需要拆分的故事）。

迷你範例摘錄：

### 使用者故事 042：

- **摘要：** 允許試用使用者使用 Google 登入，以減少註冊障礙

#### 使用案例：
- **作為一個** 首次造訪應用程式的試用使用者
- **我想要** 使用我的 Google 帳戶登入
- **以便** 我可以無需建立和記住新密碼即可存取應用程式

#### 驗收條件：
- **情境：** 首次試用使用者透過 Google OAuth 登入
- **Given：** 我在登入頁面
- **and Given：** 我有一個登入帳戶
- **When：** 我點擊「使用 Google 登入」按鈕並授權應用程式
- **Then：** 我成功登入應用程式並被重新導向至入職流程

常見陷阱

陷阱 1：偽裝成使用者故事的技術任務

症狀： 「作為一個開發者，我想要重構 API，以便程式碼更乾淨」

後果： 這是工程任務，不是使用者故事。沒有交付使用者價值。

修正： 如果沒有使用者成果，就不是使用者故事——改用工程任務或技術債票據。

陷阱 2：「作為一個使用者」（過於通用）

症狀： 每個故事都以「作為一個使用者」開頭

後果： 沒有角色清晰度。不同使用者有不同的需求。

修正： 使用特定角色：「作為一個試用使用者」、「作為一個付費訂閱者」、「作為一個管理員」等（參考 skills/proto-persona/SKILL.md）

陷阱 3：「以便」重述「我想要」

症狀： 「我想要點擊儲存按鈕，以便我可以儲存我的工作」

後果： 沒有洞察使用者為什麼在乎。只是重述行動。

修正： 深入挖掘動機：「以便如果頁面當機，我不會失去進度」（真正的成果）

陷阱 4：多個 When/Then 陳述

症狀： 驗收條件中有 5 個「When」陳述和 5 個「Then」陳述

後果： 故事太大。很可能多個功能被捆綁在一起。

修正： 使用 skills/user-story-splitting/SKILL.md 拆分故事。每個 When/Then 配對應該是一個獨立的故事（或至少評估是否需要拆分）。

陷阱 5：無法測試的驗收條件

症狀： 「Then 使用者有更好的體驗」或「Then 它更快」

後果： QA 無法驗證成功。「完成」的定義模糊。

修正： 使其可衡量：「Then 頁面在 2 秒內載入」或「Then 使用者看到成功確認訊息」

參考資料

可選輔助工具

skills/user-story/scripts/user-story-template.py — 確定性的 Markdown 模板產生器（無網路存取）

外部框架

Mike Cohn, User Stories Applied (2004) — 「As a / I want / so that」格式的起源
Gherkin (Cucumber) — 「Given/When/Then」驗收條件格式
INVEST 準則（Independent, Negotiable, Valuable, Estimable, Small, Testable）

Dean 的作品

[如有相關，連結至 Dean Peters 的 Substack 文章]

來源

改編自 https://github.com/deanpeters/product-manager-prompts 儲存庫中的 prompts/user-story-prompt-template.md

技能類型： Component
建議檔案名稱： user-story.md
建議放置位置： /skills/components/
依賴： 參考 skills/proto-persona/SKILL.md、skills/problem-statement/SKILL.md
被使用於： skills/user-story-splitting/SKILL.md、skills/epic-hypothesis/SKILL.md

user-story

相關技能

目的

輸入