穩定使用案例

產品意圖記錄產品為何存在，以及哪些成果和優先次序應引導產品決策。使用者角色與參與者則記錄哪些人會實質影響產品判斷，連同他們的目標、責任、權限和營運條件。在這些知識之上，交付團隊還要清楚知道：這些人經常要藉產品完成甚麼，而且產品演進後仍應達到甚麼成果。每項穩定使用案例就記錄其中一個持久目的。它可以引導多項交付作業；至於個別變更的詳細行為和驗收條件，則由後續規格界定。

返回頁頂

1. 定義與知識責任

穩定使用案例是一項可長期沿用的產品知識。它記錄一個或多個使用者角色的恆常產品用途、即使產品演進後仍可辨識的成果，以及維持該成果意義所需的產品層面條件。

每項紀錄由三項核心內容構成。

恆常產品用途說明使用者角色經常需要產品協助完成甚麼。Cockburn 提出的使用者目標層次，正好提供一個實用參考：它關注主要參與者希望透過系統達成的目標。Cockburn 指出，系統所支援的使用者目標，已能扼要概括系統功能。¹ 這個層次既能表達實質產品價值，也能把較細的步驟和技術子功能放在目標之下處理。

可辨識成果說明成功完成這項用途後，使用者應得到甚麼結果。即使介面、工作流程、服務拆分方式或基礎技術已經改變，受影響的使用者角色仍能清楚辨識這項成果。

產品層面不變條件列明哪些條件必須持續成立，才能保留用途和成果的原有意義。成果本身若可能容許幾種實質不同的產品解讀，紀錄便要列明相關條件；個別交付作業的規格再把適用行為寫得足夠精確，供團隊實作、驗證和驗收。

兩項判斷可以確認上述元素是否處於穩定使用案例應有的層次。

內容不依賴實作方式，表示恆常用途、可辨識成果和產品層面不變條件，在介面和實作方式大幅更換後仍然成立。Constantine 和 Lockwood 所說的本質使用案例，是以使用者意圖和系統責任為核心，抽象、概括而且不受技術限制的敘述；具體的使用者介面設計屬於另一個描述層次。² 穩定使用案例沿用同一原則。控制項、API 呼叫、畫面次序和實作模組通常屬於當前設計；只有代表重新設計後仍須保留的產品層面不變條件，才會寫進持久紀錄。

紀錄可以長期沿用，表示它一般可以橫跨多項交付作業。產品策略、使用者角色的恆常目標、案例所反映的運作模式、適用的不變條件或其他產品層面決策一旦改變紀錄的原有意義，團隊便應修訂紀錄。「穩定」描述的正是這兩項判斷共同形成的紀錄特質。

返回頁頂

2. 與產品意圖、使用者角色及參與者的關係

產品意圖、使用者角色與參與者，以及穩定使用案例，處理的是三個層次不同但彼此相連的問題。

穩定使用案例把相關的使用者角色目標整理成持久產品知識。不過，使用者角色還記錄專業知識、權限、工作量、限制條件、痛點、依賴和其他營運脈絡。這些資料都可能影響交付，卻未必各自代表一項需要產品長期支援的用途。

目標導向設計以使用者角色推演情境，正好說明兩者如何連接。Cooper、Reimann、Cronin 和 Noessel 所說的脈絡情境，是一段廣泛而概略的故事：它描述使用者角色如何運用未來產品追求目標，並在進入詳細互動設計前，交代相關的環境和組織條件。³ 因此，重點既包括使用者想完成甚麼，也包括哪些實際情況會影響他們達成目標。使用者角色在需求工程中的用途也不限於情境設計。一項涵蓋 78 項相關研究的系統性映射研究發現，使用者角色有助理解持份者、進行以人為本的需求工作，以及支援多類需求工程活動；建立、驗證和實際採用使用者角色，則仍有不少挑戰。⁴

穩定使用案例從這些人員脈絡中抽取需要長期支援的用途，無須在每項案例重複整份使用者角色紀錄。三者因而各有清晰責任：產品意圖確立方向，使用者角色反映實際營運情況，穩定使用案例則記下後續交付仍須認得的恆常用途和可辨識成果。

縮小

100%

放大重設縮放和位置

後續交付作業可以同時載入相關使用案例和使用者角色。參與者既能看見產品必須繼續達到的成果，也能了解使用者的實際工作情況會如何影響當前需求的解讀。

返回頁頂

3. 使用者角色可追溯性與知識一致性

穩定使用案例與營運使用者角色之間是多對多關係。一個使用者角色可以參與多項案例；同一項案例也可以適用於多個工作情況有實質差異的使用者角色。

規格優先交付訂明一項明確的一致性要求：

每項穩定使用案例都必須可追溯至至少一個營運使用者角色。

一項恆常用途要成為穩定使用案例，至少要有一類使用者確實需要它，而這類使用者也要在知識系統中有所記錄。如果擬議案例找不到適用的使用者角色，結構化討論便要查明缺少了哪一部分產品知識。可能是使用者角色庫漏掉了真實使用者或工作情況；也可能所謂「使用案例」其實只是一項擬議功能、方便實作的安排，或已經過時的假設，背後沒有持久的使用者需要。

反過來檢查使用者角色，也會發現另一類缺口：某個重要目標可能沒有對應的穩定使用案例。部分目標本來就不屬於目前的產品意圖，或可在產品以外滿足；其餘目標則可能是知識系統一直漏記的恆常用途。

這類關係本身就能用來分析產品知識。Sim 和 Brouse 的概念開發流程，把使用者角色連接至觀點、情境、任務、目標和需求，藉此加深對使用者的理解，並及早找出遺漏的需求。⁵ 使用者角色不再是各自孤立的文件，彼此關係也成為可以檢查的資料。穩定使用案例採用同一道理：缺少一項應有的連結，便會形成一個具體的產品問題，再交由有權決定的人處理。

縮小

100%

放大重設縮放和位置

如何實作，可按產品規模決定。小型產品用連結或識別碼可能已經足夠；大型平台則可採用索引、導向 Skill、知識圖譜、需求工具，或按既定程序維護文件之間的關係。無論採用哪種方式，團隊都要能夠檢查使用者角色與使用案例的連結，並知道相關決定由誰負責。

返回頁頂

4. 具代表性情境與可辨識成果

研究、客戶支援、日常營運、現有工作流程、需求和領域知識，往往會帶出許多具體情況。團隊可用這些情況建立和檢驗穩定使用案例。幾個情況若都反映同一恆常用途、可辨識成果和產品層面不變條件，便可保留為同一案例下的具代表性情境。

情境式需求工程為這種做法提供了實用模型。Sutcliffe、Maiden、Minocha 和 Manuel 把情境視為使用案例中一條可能出現的行為路徑，再沿着路徑發掘更多需求。⁶ 具體情境因而可以暴露遺漏的條件、例外、假設和差異，卻不必改變持久使用案例本身的抽象層次。

以 AI 旅程規劃工具為例。研究和營運資料可能提到惡劣天氣、交通取消、場地關閉、固定活動、分批抵達，或小組分途出發。產品團隊首先要問：這些情況分別反映哪些恆常用途？答案確定後，再把每個具體情況放到相應的穩定使用案例之下，作為具代表性情境。

這些紀錄只確立日後仍須認得的恆常用途和可辨識成果。如何搜尋替代方案、顯示衝突、計算取消費用或讓旅客確認變更，留待有需要的交付作業處理，再由適用的功能規格、架構、專項規格、技術規格或測試規格作出具體決定。

要檢查紀錄是否不依賴實作方式，可以設想產品換上完全不同的介面和實作方式。恆常用途、可辨識成果和產品層面不變條件在替換後仍然成立，便代表紀錄處於穩定使用案例應有的層次。目前的控制項、服務呼叫、畫面次序和詳細錯誤路徑，則應由更具體的規格處理。

返回頁頂

5. 結構化討論與決策權限

團隊透過結構化討論建立穩定使用案例。討論時，參與者把使用者角色目標和具代表性情境，與產品意圖、現有行為、領域知識及目前需求互相對照，再判斷哪些恆常用途值得長期記錄。

討論應確立：

• 要記錄哪項使用者角色目標，以及哪些使用者角色共有該目標；

• 哪些已觀察情況屬於同一恆常用途、可辨識成果和產品層面不變條件；

• 哪些差異已實質改變恆常用途或可辨識成果，需要另立穩定使用案例；

• 要保留哪些產品層面不變條件，才足以維持用途或成果的意義；

• 紀錄是否通過「不依賴實作方式」的檢查；

• 紀錄是否包含應由後續規格負責的目前實作細節；

• 每項擬議使用案例是否都有適用的使用者角色；以及

• 重要的使用者角色目標是否揭示遺漏的使用案例或另一項產品決策。

具體情境為討論提供可供檢驗的材料，決策權限則決定誰可以確認結論。某項恆常用途是否屬於產品，通常由產品負責人、產品經理或同等的產品決策負責人決定。領域參與者帶來營運知識，工程人員指出實作假設和技術後果，各專業職能則在本身的權限內作出判斷。

AI 可以整理候選情境、找出相關使用者角色、標示可追溯性缺口、比較成果，並草擬修改建議。哪些內容可成為權威產品知識，仍由具明確責任歸屬的人員決定。任何參與者都可以指出不一致之處；背後的產品或專業決定，則交由具備相關權限的角色處理。

返回頁頂

6. 與個別交付作業規格的關係

穩定使用案例先確立持久脈絡，個別交付作業的規格再據此處理當前變更。大部分交付作業都會改動與一項或多項穩定使用案例相關的行為，因此結構化討論要先以適用案例解讀擬議變更。功能規格其後界定當次要支援的行為、正常和例外路徑、無效狀態、使用者可見成果及驗收條件。其他專項規格按各自的專業責任補充決定；技術規格和測試規格則把經審查的條件寫成可執行、可驗證的內容。提案若會實質改變案例的恆常用途、可辨識成果、產品層面不變條件或參與案例的使用者角色，便須接受產品層面審查。

早期使用案例方法也曾處理同一難題：既要保留使用者目標的整體視角，又要容許團隊逐步交付。Jacobson、Spence 和 Kerr 為此發展 Use-Case 2.0。完整使用案例保留系統應支援甚麼的整體視角；「使用案例切片」則選出一次交付可以實作的部分行為，並連接架構、設計、測試和使用者體驗。⁷ 對穩定使用案例而言，值得借鑑的是持久產品脈絡與單次交付工作的分工。恆常用途、可辨識成果和產品層面不變條件保存在穩定使用案例；當次交付所需的行為、專業職能、技術和驗證決定則寫入規格體系。

在規格優先交付中，穩定使用案例的知識責任更為集中：它跨多項交付作業保存恆常用途、可辨識成果和產品層面不變條件；每項交付作業的規格體系則負責具體的功能、專業職能、技術和驗證決定。以 AI 旅程規劃工具為例，「重新規劃部分行程」可以一直沿用同一項穩定使用案例，而鐵路服務取消處理、取消費用預覽和全新行程介面，則可由不同交付作業逐一加入。

返回頁頂

7. 建立與維護程序

團隊可以直接從現有產品知識着手，無須先建成完整目錄。第一步是記錄目前交付真正依賴的使用者角色和恆常用途，形成足夠的持久脈絡。往後每次結構化討論發現重要缺口，再逐步補充和整理。

整理紀錄時，較短期的決定應放進真正負責該項知識的工作產物。UI 控制項、工作流程次序、API 決定、模型提示、實作模組、錯誤訊息、門檻和可執行的驗收檢查都可能十分重要，但應由相應規格或實作文件處理。

恆常用途、可辨識成果、產品層面不變條件或適用的使用者角色若有實質改變，便要交由對應的產品或領域決策負責人處理。這項修訂門檻讓紀錄得以跨多項交付作業長期沿用。若新知識來自交付本身，則可透過交付作業生命週期中的知識收斂，把經確認的結果更新至權威現況知識。

返回頁頂

8. 參考表示方式

穩定使用案例可以採用不同格式。只要讀者能清楚查看恆常用途、參與案例的使用者角色、可辨識成果、產品層面不變條件、決策權限和相關連結，便符合規格優先交付的要求。

穩定使用案例識別碼：
標題：

恆常用途：
參與案例的使用者角色：
可辨識成果：
產品層面不變條件（如適用）：
具代表性情境：
相關產品意圖：
決策負責人：

選填情境群組：

選填來源資料：
- 提出者：
- 觀察或討論日期：
- 參考資料：

恆常用途、可辨識成果和產品層面不變條件讓三項核心內容一目了然。參與案例的使用者角色建立必要的可追溯關係，一項案例可以列出多個角色。具代表性情境用具體情況檢查案例是否充分，同時保留案例本身的抽象層次。相關產品意圖指出案例服務哪項產品成果或優先次序；決策負責人則說明誰有權確認重大的解讀或修訂。團隊以三項核心內容檢查紀錄是否不依賴實作方式，再透過產品層面的修訂權限，確保紀錄可以長期沿用。選填情境群組只適用於已採用這層分類的大型目錄。

來源資料可按需要選填。穩定使用案例用來指引產品方向，並不承擔後續驗收證據的責任。不過，若記下誰提出案例、何時討論，以及案例源自哪項研究、支援個案或營運觀察，日後接手的人會較容易還原當時的脈絡。

以 AI 旅程規劃工具為例，紀錄可以寫成：

穩定使用案例識別碼：travel-partial-replan
標題：外在干擾發生後重新規劃部分行程

恆常用途：
當外在事件令既定計劃的部分內容失效，讓旅客可以恢復可行行程。

參與案例的使用者角色：
- 獨立旅客
- 團體旅程統籌員

可辨識成果：
旅客取得一份連貫的修訂行程，妥善處理原有行程中受干擾的部分。

產品層面不變條件：
- 未受影響的固定安排會繼續保留。
- 旅客在確認前能夠了解重要後果。
- 修訂後的行程對參與旅客而言仍然連貫。

具代表性情境：
- 交通取消
- 惡劣天氣
- 場地關閉

相關產品意圖：
即使實際旅遊情況改變，行程規劃仍然清晰易明並可靈活調整。

決策負責人：
產品負責人

選填情境群組：
行程受阻與復原

日後的功能規格可以另行決定如何偵測問題、選擇替代方案、計算費用、處理無法提供服務的情況，以及確認變更。只要這些細節沒有改變案例的恆常用途、可辨識成果、產品層面不變條件或參與案例的使用者角色，原有紀錄便可以繼續沿用。

返回頁頂

9. 驗證與就緒條件

驗證穩定使用案例，就是檢查現有知識是否足夠。合資格參與者應能從紀錄掌握產品要長期支援的用途，也要知道遇上哪類問題時，必須請相應的決策負責人作出更具體決定。

這些檢查把不熟悉產品的參與者測試延伸至穩定使用案例。一位沒有相關產品經驗的合資格參與者，閱讀產品意圖、適用的使用者角色和穩定使用案例後，應能說明產品服務哪些人、哪些恆常用途最重要、日後交付必須繼續達到哪些成果、維持哪些產品層面條件，以及重大不一致之處應由誰處理。

通過這項審查，代表紀錄已清楚交代足夠的持久脈絡。日後的交付作業可以從已確立的恆常用途出發，無須再從目前實作反推產品原意。新情境可能為現有案例補充證據，也可能揭示遺漏的使用者角色或使用案例；如果產品的根本需要已經改變，團隊便要實質修訂相關紀錄。

返回頁頂

10. 擴展穩定使用案例庫

一開始只需採用最簡單、又足以查找和審查的形式。小型產品可以把整份目錄放在 docs/use-cases.md，每項使用案例用一段簡短而清晰的紀錄，列出參與案例的使用者角色、恆常用途、可辨識成果、產品層面不變條件、具代表性情境和決策負責人。

目錄逐漸增長後，不同使用案例可能有各自的負責人、證據、審查歷程或載入需要，這時分拆檔案會更容易維護。團隊可以把 docs/use-cases.md 改成 docs/use-cases/ 目錄，以 docs/use-cases/README.md 作為總索引和導向入口，再為每項穩定使用案例建立獨立的 Markdown 紀錄。

當案例多得難以用單層索引瀏覽，團隊可以加入情境群組。它把同一產品使用範疇的多項穩定使用案例歸在一起，方便查找；每項案例仍各自保留恆常用途、可辨識成果、產品層面不變條件、使用者角色可追溯性、權限和生命週期。情境群組只是一個選用的整理層，不是穩定使用案例定義的必要部分。

早期使用案例方法也有相近的分層方式。Cockburn 把使用者目標層次的使用案例，與更高層的摘要使用案例分開；摘要使用案例把多個使用者目標連接起來，提供較完整的脈絡。¹ 情境群組的責任更輕，只協助讀者和 AI 在大型知識系統中找到相關案例，既不新增產品需求，也不取代群組內的紀錄。

例如，AI 旅程規劃工具可以把「外在干擾發生後重新規劃部分行程」、「錯過接駁交通後恢復可行行程」和「替換未能提供的已預訂活動」，歸入「行程受阻與復原」群組。若產品只有幾項使用案例，維持單層索引反而更直接。

大型使用案例庫也可以採用按需分層載入上下文。當單靠檔案搜尋已不敷應用，團隊可選用 use-case-directory Skill，列出精簡摘要、情境群組和載入路徑。AI 代理先讀索引，再載入與當前問題相關的穩定使用案例，無須一次讀取整個目錄。

導向索引可以保持精簡，例如：

# 穩定使用案例索引

## 行程受阻與復原

- `travel-partial-replan` – 在外在干擾後修改受影響的部分行程
  - 載入：`docs/use-cases/travel-partial-replan.md`
  - 適用於：干擾處理、恢復行程、保留未受影響的固定安排

- `travel-missed-connection-recovery` – 錯過接駁交通後恢復可行行程
  - 載入：`docs/use-cases/travel-missed-connection-recovery.md`
  - 適用於：錯過接駁、對後續交通的影響、恢復行程

這項 Skill 只負責導向，因此每項案例只需一段簡短描述。完整而權威的恆常用途、可辨識成果、產品層面不變條件、使用者角色關係和決策負責人，仍保存在穩定使用案例紀錄。規格優先交付的知識系統就緒度另行說明程式碼儲存庫根目錄下 skills/ 的整體慣例、AI 程式開發代理的查找路徑，以及選用的符號連結相容安排。

以下範例展示一個規模較大、以程式碼儲存庫為中心的做法：

無論目錄大小，穩定使用案例都必須容易找到、按既定程序維護，並可靠連接至適用的使用者角色。單一檔案、多檔案目錄、情境群組和導向 Skill 只是不同規模的實作選擇；產品真正出現瀏覽或維護需要時，才逐步加入相應結構。