如何撰寫使用者故事（附範例與驗收條件）

使用者故事是從使用者角度描述功能的簡短說明：「作為[某類使用者]，我想要[目標]，以便[理由]。」在它下面，你要寫下驗收條件，也就是數條具體的條件，必須全部成立，故事才算完成。讓每個故事小到能一次建置並測試完成，並且把條件寫得讓任何人都能檢查。

使用者故事是由敏捷軟體團隊推廣開來的，但當你獨自使用 AI 應用程式建置工具時，它同樣有用。好的故事就是好的提示詞。

格式

一個使用者故事包含三個部分：

作為 [誰]，我想要 [什麼]，以便 [為什麼]。

• 誰是具體的一類使用者：第一次造訪的訪客、付費會員、診所櫃台人員、管理員。不要寫「使用者」這種泛稱。
• 什麼是他們想做的事，用他們自己的話來說。不是描述畫面如何運作。
• 為什麼是他們在意的結果。這是人們最常跳過的部分，卻能防止你做出錯誤的東西。

範例：

作為健身房會員，我想要用手機取消課程預約，以便候補名單上的人可以補上我的名額，而且我不會被收取未到課罰款。

「為什麼」告訴你「做什麼」沒有說清楚的兩件事：它必須能在手機上運作，而且候補名單與罰款規則都牽涉其中。

驗收條件

故事說的是要什麼，驗收條件說的是何時算完成。它們應該具體到讓兩個人都能同意每一條是否通過。

常見的寫法是 Given／When／Then：

• **Given（給定）**某個起始情境
• **When（當）**使用者做了某件事
• **Then（則）**這就是結果

以健身房預約的故事為例：

1. 給定我有一筆距離現在超過 12 小時的預約，當我點選取消並確認，則預約會被移除，並且我會看到「預約已取消」。
2. 給定我取消了一筆預約，而該課程有候補名單，當取消儲存成功，則候補名單上的第一位會獲得名額，並收到一封電子郵件。
3. 給定一筆預約距離現在不到 12 小時，當我點選取消，則我會在確認前看到會適用晚取消費用。
4. 給定我在手機寬度的螢幕上，則取消按鈕無需橫向捲動即可看到。

一份普通的核取清單也可以，只要每一項都可以測試。「取消很容易」無法測試；「從預約列表最多只需點兩下即可取消」就可以。

逐步說明：撰寫好的故事

第一步：從真實的使用者與真實的問題出發

選擇一類使用者，以及他們今天所苦惱的一件事。如果你做過客戶訪談，就用他們的話。「我總是忘記取消，然後被收費」比「新增取消功能」更適合作為起點。

第二步：寫出一行的故事

填入範本。如果你寫不出令人信服的「以便」，就先問問這個功能是否真的需要。

第三步：加入三到六條驗收條件

先涵蓋主要的成功情境，再加入重要的變化情況：不同的角色、空白狀態、限制、錯誤。如果你寫了超過六條，這個故事可能太大了。

第四步：註明排除的範圍

一行說明就能省下許多來回討論：「排除範圍：付費課程的退款；管理員代會員取消預約。」它能防止故事在你建置時不斷膨脹。

第五步：對照 INVEST 檢查

INVEST 是檢視好故事的常見清單。一個好的故事應該是：

你不必為每個故事打分數。當某個故事感覺不對、而你想知道原因時，這個清單最有用。

好與壞的範例

如何拆分太大的故事

大型故事是專案停滯的地方。常見的拆分方式：

• **依使用者角色。**會員取消自己的預約；員工可以取消任何人的預約。
• **依流程中的步驟。**瀏覽課程；預約課程；收到提醒。
• **先做簡單的情況。**先取消一堂免費課程；費用與退款留到之後的故事處理。
• **依資料的變化。**先支援一個據點，之後再支援多個。
• **先做正常流程，再處理錯誤。**先讓它正常運作，再加入課程已滿、通行證過期等情況的處理。

每一個拆出來的部分，仍然應該是使用者能夠使用並察覺到的東西。

把使用者故事當作提示詞

附有驗收條件的使用者故事，非常接近 AI 應用程式建置工具的好提示詞。它提供 AI 誰、做什麼、為什麼，以及完成的定義。每則訊息送一個故事：

作為健身房會員，我想要用手機取消課程預約，以便候補名單上的人可以補上我的名額。 驗收條件：

1. 「我的預約」中的每筆預約都有取消選項，並有確認步驟。
2. 若在課程開始前 12 小時以上取消，只需移除預約。
3. 若在 12 小時以內，確認前顯示「將收取 5 美元的晚取消費用」，並在預約上記錄該筆費用。
4. 若課程有候補名單，第一位候補者獲得名額並收到電子郵件。
5. 在手機寬度的螢幕上可正常運作。 排除範圍：退款、員工代會員取消。 請建置這些內容，然後在預覽中逐條檢查驗收條件，並告訴我哪些通過。

你也可以請 AI 根據粗略的想法草擬故事，然後由你自己編修：

這是我的應用程式構想：[兩到三句話]。請為第一版撰寫使用者故事，依使用者類型分組，每個故事附上 3 到 5 條 Given／When／Then 的驗收條件。標出哪些是上線必備，哪些可以之後再做。

務必閱讀並編修結果。AI 不了解你的使用者，你才了解。

驗收條件同時也是你的測試計畫。故事建置完成後，請自己逐條走過每一條驗收條件。我們關於上線前如何測試你的應用程式的指南正是建立在這個基礎上。

使用者故事與其他文件的關係

• 產品需求文件描述整個產品：問題、使用者、範圍。使用者故事是其中的細部內容。參見如何用 AI 撰寫 PRD。
• 錯誤回報描述的是已建置的故事中某件壞掉的事。參見如何撰寫好的錯誤回報。
• MVP 是能傳遞核心價值的最小故事集合。參見什麼是 MVP。

常見錯誤

• **「作為使用者……」**太籠統。請寫出實際的使用者類型。
• **省略「以便」。**沒有理由，就無法做出合理的取捨。
• 寫出解決方案，而不是需求。「我想要一個下拉選單」在任何人還沒思考過之前就鎖定了設計。
• 無法測試的條件。「簡單」、「快速」與「直覺」是願望，不是條件。
• 實際上是史詩（epic）的故事。「管理我的帳號」其實是十個故事。
• **一次把所有故事都寫好。**先詳細寫下接下來幾個，其餘的保留為一行的摘要，等到要做時再展開。

Mythex 中的故事

在 Mythex 中，Plan 模式很適合把構想轉化為故事：代理會在編輯任何東西之前先討論做法。當故事準備好時，切換到 Build 並貼上，一次一個故事。每次完成後，/test 可以在預覽中點擊操作、檢查流程；如果某次回覆方向錯誤，你還可以用還原到此處回退。參見文件中的有效提示詞，以及我們關於為 AI 應用程式建置工具撰寫提示詞的指南。

使用者故事檢查清單

• 指明具體的使用者類型
• 描述的是需求，而不是設計
• 包含真正的「以便」理由
• 有三到六條可測試的驗收條件
• 至少涵蓋一個邊緣情況或錯誤
• 說明了排除的範圍
• 小到能一次建置並測試完成
• 建置完成後，逐條檢查驗收條件

常見問題