使用者角色與參與者

產品的使用者可能是資料庫管理員、市場分析師、倉庫操作員、理賠處理人員或支援工程師，也可能來自其他容易辨認的職能。職銜可以提供初步方向，亦有助理解使用者看待產品的角度，但交付團隊仍需要知道他們實際怎樣工作。即使同樣是資料庫管理員，兩個人的責任、工作環境、決策權、工作量、面對故障的程度，以及使用產品的原因，都可以有實質分別。

規格優先交付把這些會影響產品決策的差異，保存為按既定程序管理的產品知識。在共享知識系統中，**參與者（Actor）**代表人員與產品互動或實質影響產品時所擔當的角色或營運職能。**營運使用者角色（operational persona，下文簡稱使用者角色）**則代表一類工作方式有實質分別的人。他們可以擔當一個或多個參與者角色，而紀錄會保留判斷其產品需要時不可缺少的目標、責任、決策權限、工作條件、限制條件和目前營運現況。軟件設計長期運用使用者角色來保存較完整的使用者知識；以角色為本的需求研究亦指出，把一個職能視為完全同質，會掩蓋實際擔當該職能的人之間的重要差異。¹²

營運使用者角色也會隨產品和工作演進。紀錄一方面保留較穩定的核心，另一方面反映不斷轉變的營運現況。例如，資料庫管理員即使一直負責資料庫可靠性，日常工作仍可能出現以下變化：

• 產品改動前，資料庫管理員可能要人手查看複寫延遲儀表板，並在每次事故中聯絡供應商。

• 產品把應變流程自動化後，上游資料來源發生問題時，系統會自動向供應商發送電郵，並通知受影響的使用者。資料庫管理員仍然負責資料庫可靠性，但可以把時間投放在其他工作，毋須再處理例行事故協調。

實際工作改變後，使用者角色所記錄的營運現況亦要更新。責任、經常需要的人手介入、痛點、升級處理路徑，甚至某個使用者角色是否仍有需要獨立存在，都可能隨之改變。

AI 輔助工程令持續維護使用者角色變得更可行。數據驅動的研究逐步採用分析工具和軟件來建立與維護使用者角色；後續研究再利用使用者回饋和監察數據支援建立、驗證與演進。另有研究從 B2B 軟件的使用紀錄配合生成式 AI 找出行為和痛點，或在需求工程中結合大型語言模型與知識圖譜，持續生成使用者角色。³⁴⁵⁶

規格優先交付把這些能力納入責任歸屬和決策權限清晰的交付流程。AI 可以找出受影響的使用者角色、整理相關來源、比較紀錄與目前營運方式、草擬候選修改，再按照管治指示或使用者角色 Skill，把修改送交適當的人員審查。建立使用者角色時亦可採用同一分工。如果產品意圖、現有規格、專業知識和目前的營運知識已經齊備，AI 程式開發代理可以綜合這些資料，提出候選紀錄；人員則判斷內容是否真確、重要、符合現況，以及哪些內容可視為權威知識。涉及重大變更時，對相關營運現況負有責任的人員或專業職能仍然掌握決策權。

本文建立的實務模式涵蓋五個彼此相連的範疇。

產品意圖說明產品為何存在、要達成哪些成果，以及其優先次序和範圍。營運使用者角色說明誰會受到影響，以及他們在甚麼條件下工作；穩定使用案例則記錄產品需要持續支援的重複目的和互動。三者互相連接，日後接手的人便能同時理解產品要達成甚麼、哪些人受到影響，以及哪些營運脈絡會改變需求的解讀。

返回頁頂

1. 參與者與營運使用者角色

參與者（Actor）是會影響產品行為的人員角色或營運職能。它說明誰操作產品、誰可以批准重大行動、流程失敗時由誰應變、誰提供專業判斷，以及哪些工作只可由特定角色執行。

同一個人可以因應情況以多種職能行事。例如，資料庫管理員在日常工作中是一般操作人員，遇上正式環境事故時是事故應變人員，在資料庫遷移期間又可能是變更審批人員。參與者定義說明這些職能和相應權限；相關營運使用者角色則保存同一職能下，不同人群在實際工作上的差異。

當差異足以改變需求、工作流程、產品行為、權限、營運支援或驗收方式時，營運使用者角色便要把它們記錄下來。Miller 和 Williams 在以角色為本的需求工程研究中也提出相近觀察：角色通常呈現較同質的視角，但實際擔當同一角色的不同類型使用者，可能需要更深入的描述。²

例如，一個組織可以只有一個 Database Administrator 參與者角色，但同時維護多個營運使用者角色：

• Alex，Database Performance DBA：主要處理查詢效能、複寫行為、索引健康狀況、容量，以及大型正式環境資料庫的事故。

• Priya，Cloud Database Infrastructure DBA：主要處理託管資料庫服務、基礎設施設定、修補、雲端網絡、存取控制和平台可靠性。

• Chen，Data Platform Operations DBA：主要處理資料攝取健康狀況、上游資料供應商故障、資料時效性、復原，以及向下游使用者作營運溝通。

名字是方便討論的識別方式，團隊可自行決定是否採用。多個使用者角色共用同一廣義職銜時，名字尤其有用，因為團隊可以直接指出某種營運專長，毋須每次重述整套工作情況。真正界定使用者角色的是名字背後的工作差異；個人資料則只在確實會影響產品判斷時才需要記錄。

一個營運使用者角色可以同時履行多個參與者角色，而同一個參與者角色亦可以由多個營運使用者角色代表。這種多對多關係，讓產品模型能保存真正不同的工作方式，即使組織在職銜上把所有人都歸入同一類別。

縮小

100%

放大重設縮放和位置

返回頁頂

2. 營運使用者角色應記錄甚麼

營運使用者角色應保存足以改變產品判斷的資料。年齡、相片、興趣或家庭狀況等個人資料，只有在確實影響產品時才需要加入；營運資料亦採用同一準則。會改變決策、需求、工作流程、限制條件或驗收結果的資料，才值得保存。

2023 年一項系統性映射研究檢視了 78 篇需求工程研究，發現使用者角色有助理解持份者、支援以人為本的需求工作和其他需求工程活動；研究亦指出，建立、驗證使用者角色並把它納入需求工程活動時會遇到挑戰。⁷ 一份可供交付使用的營運使用者角色紀錄，因而要保存決策所需的重要資料，而非只作展示。

規格優先交付把營運使用者角色知識分成三個部分。

穩定核心通常較少改變，因為它說明為甚麼這群人仍然值得被視為一類獨立的營運使用者角色。營運現況則會隨產品交付、組織改變、自動化、法規、工具、規模和實際營運經驗而更頻繁地演進。

一份較完整的紀錄可以包括：

使用者角色 ID：
顯示名稱：
摘要：

參與者角色與職能：
相關專業知識：
重複出現的目標：
長期責任：
決策權限：
持續依賴：
長期限制條件：
成功條件：

目前工作流程：
目前規模與工作量：
頻率與時間特性：
工具與資訊來源：
人手介入：
值班或升級處理責任：
目前故障情況：
目前變通方法：
目前痛點：
目前自動化程度：

團隊只需選用會實質影響產品判斷的欄位。小型產品可能只需為每一類重要使用者寫一小段文字；複雜的營運產品則可能需要較完整的紀錄，因為時間、權限、規模、故障應變或專業決策權的差異，都可以直接改變交付決策。

返回頁頂

3. 範例：Database Performance DBA

假設某個內部資料平台的資料庫營運團隊，管理約 2 PB 正式環境資料。其中一個營運使用者角色可以這樣記錄：

使用者角色 ID：dba-database-performance
顯示名稱：Alex
摘要：資深資料庫效能工程師，負責正式環境資料庫效能，並對複寫及資料可用性事故
進行第一線診斷。

參與者角色與職能：
- 資料庫管理員
- 正式環境事故應變人員
- 資料庫變更審查人員

相關專業知識：
- 查詢與索引效能
- 複寫行為
- 容量與儲存增長
- 正式環境故障轉移與復原

重複出現的目標：
- 維持正式環境資料可用，並確保資料時效性足以支援下游使用者。
- 快速診斷重大效能或複寫退化。
- 執行資料庫變更時避免造成不必要的正式環境風險。

決策權限：
- 可以啟動已獲批准的營運復原程序。
- 可以在既定授權政策內審批例行資料庫變更。
- 涉及產品、供應商合約或架構的決策，交由相應負責人處理。

目前營運現況：
- 約每兩星期參與一次主要值班輪值。
- 檢查複寫延遲、儲存增長、備份健康狀況和叢集警報。
- 人手把複寫延遲與部署、供應商和網絡事件互相對照。
- 懷疑上游資料延誤或格式錯誤時，聯絡資料供應商。
- 資料時效性對下游使用者造成重大影響時，負責通知相關人員。

目前痛點：
- 複寫儀表板無法把延遲與可能的上游原因連接起來。
- 聯絡供應商仍靠人手，而且通常要等 DBA 完成初步診斷後才開始。
- 下游使用者仍依賴 DBA 判斷並通知他們，尚未更新的資料是否可以安全使用。

資料規模、值班頻率、決策權限和人手事故處理流程都會影響產品設計。對一般 DBA 看來有用的功能，放到這個情境未必合適。例如，在事故期間再增加一個必須檢查的儀表板、把審批所需資訊隱藏起來，或假設正在處理正式環境事故的 DBA 可以等待同步流程完成，都可能令工作更困難。

這類紀錄亦讓改善變得可觀察。產品團隊可以先指出希望移除哪一種營運負擔，交付後再驗證實際工作是否真的改變。

返回頁頂

4. 交付如何推動使用者角色演進

營運使用者角色描述目前的工作方式，而成功交付本身就可能改變這種工作方式。規格優先交付因此把更新使用者角色納入知識系統生命週期，讓它持續反映現況，成為後續工作可用的產品知識。

相關研究亦支持把維護使用者角色視為持續工程工作。一項涵蓋 77 篇數據驅動使用者角色研究的調查指出，研究人員愈來愈常運用線上使用者數據、分析技術和軟件工具來建立使用者角色。³ Patkar 和 Seyff 提出以使用者回饋和監察數據建立、驗證和演進使用者角色。⁴ 在 B2B 軟件情境中，Sera 等人結合點擊串流（clickstream）數據、聚類和生成式 AI，從既有服務的使用紀錄整理使用者行為與痛點。⁵ Sugiyama 等人進一步以大型語言模型和知識圖譜持續生成數據驅動使用者角色，並明確把持續更新連接到軟件開發生命週期。⁶

規格優先交付把已驗收的交付成果定為更新觸發條件，並為修改訂明審查程序。交付作業一旦改變某個使用者角色所代表的實際工作，團隊除了確認軟件是否符合規格，亦要檢視責任、經常需要的人手介入、痛點、決策路徑、工具依賴，以及其他後續交付會依賴的使用者角色知識有沒有改變。跨交付作業生命週期的知識收斂說明如何按照適當權限，把交付過程產生的重要新知識帶回知識系統。

沿用上述例子，假設一項可靠性交付作業改變了資料庫事故處理流程。平台現在能夠識別某一類上游資料故障，自動把結構化診斷報告送給供應商，把受影響資料標記為尚未更新，透過可作準的狀態渠道通知下游使用者，並只在自動復原或供應商回應失敗時才升級交由 DBA 處理。

這項改動通過驗收，而且營運效果得到確認後，Alex 的日常工作便有所不同。正常事故流程已毋須由他聯絡供應商，下游使用者亦毋須再依賴他發出例行的資料時效通知。對這類故障而言，第一線人手介入只在自動化或供應商無法解決問題時才需要。如果同一運作模式日後涵蓋更多故障類別，值班負擔可能進一步下降，或轉移到另一個角色。

更新使用者角色本身就是知識收斂的一部分。下一次需求討論要從新的營運現況出發，避免再以產品已經移除的工作為前提。

返回頁頂

4.1. AI 輔助的使用者角色演進

AI 可以把來源審查、前後比較和導向工作整理成可重複程序，降低維護這套生命週期的成本。在以程式碼儲存庫為中心的做法中，管治指示可以規定：已驗收的交付作業一旦實質改變使用者工作流程、責任、權限、支援路徑或痛點，便要進行使用者角色影響審查。使用者角色 Skill 則說明如何找出受影響紀錄、整理適用的現況知識、比較紀錄與已驗收的產品現況、草擬候選修改，以及找出需要一併審查的使用案例或規格。

很多準備工作都適合交由 AI 處理。AI 代理可以檢查獲准存取的事故紀錄或已審批營運摘要，比較交付前後的工作流程，草擬差異，標示已經失效的紀錄，並指出某個使用者角色是否可能需要拆分、合併或退役。監察數據和使用者回饋亦可以揭示其他變化，與前述數據驅動使用者角色演進研究的方向一致。⁴⁵⁶

流程產生的是一項有待審查的知識系統修改。例行事實資料可依照來源本身的維護程序更新；涉及重複出現的責任、決策權限、主要營運條件、核心目標、參與者關係，或使用者角色的拆分、合併與退役，則要交由權限受到影響的人員或專業職能確認。AI 的作用是減輕維持現況知識的工作，使用者角色背後的人員決策權仍由相關人員掌握。

隨着產品演進，使用者角色庫的結構也可以改變。平台自動化可能消除原本足以區分兩個資料庫使用者角色的工作差異，讓兩份紀錄合併；產品進入受規管環境時，亦可能需要新增專業使用者角色。某項職能退出營運模式後，對應的使用者角色可以退役，相關歷史交付紀錄則按需要保留。

審查要求取決於變更後果，而非資料位於哪個欄位。把觀察所得的資料庫規模由 1.8 PB 更新為 2.0 PB，可能只是例行事實更新；移除值班責任則會改變營運模式。即使兩項資料同樣位於「持續演進的營運現況」，後者仍要由對該責任有決策權的人員審查。

返回頁頂

5. 以使用者角色為脈絡的結構化討論

營運使用者角色直接用於結構化討論時，團隊便能在下游規格依賴某套使用者假設之前，先根據每個受實質影響的使用者角色所記錄的營運脈絡檢視需求。

一套實際可行的討論次序是：

1. 找出需求涉及哪些參與者角色；

2. 在這些參與者角色之中，找出工作方式有實質差異的營運使用者角色；

3. 只載入目前問題真正相關的使用者角色紀錄；

4. 按每個使用者角色的目標、責任、決策權限、限制條件、工作流程、故障情況和目前痛點檢視擬議結果；

5. 找出互相衝突的需要、遺漏情境、已改變的責任、未經確認的假設或知識缺口；

6. 把重大決策和使用者角色修改交由具備相應決策權限的人員處理；以及

7. 把已審查結論保存在討論紀錄和後續規格內。

以資料庫例子而言，AI 參與者可以按照 Alex 的目前營運現況檢視一項擬議維護流程，集中找出它會否改變值班責任、事故期間所需資訊、審批決定或升級處理路徑。再從 Priya 的雲端基礎設施使用者角色檢視同一流程，便可能發現另一組問題，即使兩個使用者角色同樣擔當 Database Administrator 參與者角色。

使用者角色為討論提供推理脈絡，本身則是按既定程序管理的組織紀錄。任何重大解讀或修改，都要遵從相應的人員決策權限。

大型語言模型研究亦顯示，權責劃分必須清晰。Aher、Arriaga 和 Kalai 發現，語言模型在模擬參與者的條件下可以重現部分既有人體研究結果，但在另一項實驗中亦呈現系統性偏差。⁸ 因此，以使用者角色為脈絡的 AI 討論適合用來提出問題和測試不同解讀；關於人員實際如何行動或作決定的陳述，仍須由相關人員，以及熟悉營運環境並對此負有責任的職能確認。

返回頁頂

6. 使用者角色庫與按需分層載入上下文

知識系統需要一個清晰而可供查找的途徑，讓參與者取得適用的使用者角色。使用者角色庫是持續維護的營運使用者角色集合，當中包括使用者角色與參與者的關係、責任歸屬、狀態和導向資料，讓交付工作能夠取得與目前問題相關的人員營運脈絡。

儲存方式應按複雜程度決定。只有兩三類簡單使用者的小型應用程式，可以一直把完整資料放在一份 docs/personas.md。當不同使用者角色開始有各自負責人、審查歷程或適用條件時，拆成獨立紀錄會更容易維護，也更適合按需要載入。

返回頁頂

7. 使用者角色 Skill：按需分層載入上下文的導向層

複雜的使用者角色庫可以加入一層精簡的導向資料。使用者角色 Skill 只需用簡短摘要說明每個使用者角色的適用情況，讓 AI 在載入全文前選出相關紀錄。摘要毋須複製完整內容。這樣，Skill 負責索引和程序，docs/personas/*.md 則繼續保存具權威性的完整使用者角色知識。

以資料庫例子而言，skills/persona-directory/SKILL.md 可以這樣寫：

---
name: persona-directory
description: 把產品與交付工作導向適用的營運使用者角色。
---

# 使用者角色索引

當產品、工作流程、需求、規格或交付後審查可能影響某類人員
履行營運角色的方式時，使用這個 Skill。

## 使用者角色一覽

- `dba-database-performance` – Alex, Database Performance DBA
  - 載入：`docs/personas/alex-database-performance-dba.md`
  - 適用於：查詢效能、複寫、容量、資料庫事故、值班應變和資料庫變更審查。

- `dba-cloud-infrastructure` – Priya, Cloud Database Infrastructure DBA
  - 載入：`docs/personas/priya-cloud-database-infrastructure-dba.md`
  - 適用於：託管資料庫服務、雲端網絡、修補、存取、基礎設施設定和平台可靠性。

- `dba-data-platform-operations` – Chen, Data Platform Operations DBA
  - 載入：`docs/personas/chen-data-platform-operations-dba.md`
  - 適用於：資料攝取健康狀況、上游供應商故障、資料時效性、復原和下游營運溝通。

## 載入程序

1. 找出受影響的參與者角色和營運問題。
2. 對照使用者角色索引判斷哪些紀錄適用。
3. 只載入足以實質改變目前決策的使用者角色紀錄。
4. 如果沒有任何使用者角色涵蓋一項重要營運脈絡，先記錄缺口並交由產品或領域負責人處理，
   不應自行假設使用者模式。
5. 如果兩個適用的使用者角色提供互相衝突的脈絡，保留兩者並把決定交由對相關需求有權負責的人員處理。

## 交付後使用者角色審查

當已驗收交付改變工作流程、重複責任、權限、支援路徑、
人手介入頻率或痛點時：

1. 重新載入受影響的使用者角色紀錄；
2. 把已記錄營運現況與已驗收的交付結果互相對照；
3. 草擬候選修改，並找出可能受影響的使用案例或需求；
4. 把重大修改交由權限受到影響的人員或專業職能審查；
5. 完成所需審查後，才更新具權威性的使用者角色紀錄。

這個索引刻意保持精簡。工作涉及複寫延遲和正式環境事故應變時，AI 可以先選擇 Alex，再載入詳細紀錄；雲端網絡變更會指向 Priya；上游資料供應商故障則指向 Chen。有些工作需要同時載入多個使用者角色，但 AI 仍可從幾句簡短的導向描述開始，毋須每次都把整個使用者角色庫放進上下文視窗。

管治指示與 Skill 各有不同作用。管治指示可以規定哪些工作必須考慮使用者角色，也可以要求已驗收的改動一旦改變營運現況，便要進行交付後使用者角色審查。Skill 則提供可重複使用的導向和維護程序。兩者結合就是按需分層載入上下文的實際做法：恆常載入的強制指示保持精簡；工作需要人員營運脈絡時才載入使用者角色索引；確定哪些使用者角色適用後，才載入完整紀錄。

在這個以程式碼儲存庫為中心的例子中，skills/persona-directory/ 是放在根目錄並由團隊維護的唯一一份使用者角色 Skill。如果不同 AI 程式開發代理要求其他尋找位置，儲存庫可以透過符號連結或等效的相容路徑，公開同一份根目錄 Skill。規格優先交付的知識系統就緒度會完整說明這類儲存庫設定與單一來源導向方式；本文只展示使用者角色知識本身所需的結構。

每份使用者角色紀錄仍然是相應營運脈絡的權威來源；根目錄 Skill 只負責導向和維護程序。不同 AI 程式開發代理的尋找設定屬於儲存庫層面的相容安排，因此不在這個使用者角色結構中展開。

文件平台、產品管理系統、知識圖譜或其他持續維護的系統，都可以提供相同能力。框架要求人員與 AI 能夠找到按既定程序管理的使用者角色知識，並可靠地選出與目前決策相關的紀錄。Markdown 檔案配合使用者角色導向 Skill，是其中一種以程式碼儲存庫為中心的實作方式。

返回頁頂

8. 由 AI 草擬，再逐行由人員確認

詳細的使用者角色系統很適合由 AI 輔助建立。如果產品意圖、既有需求、專項規格、架構與營運知識、目前實作現況，以及使用者研究資料已經存在，AI 程式開發代理可以一次綜合多個權威來源。這些紀錄往往比任何一名參與者在空白頁前即時想起的內容更完整，也更容易把既有決定、限制條件和例外帶進草稿。團隊可以先與代理進行結構化討論，再由具相應權限的人員嚴謹審查成果。

既有研究已支持這種人機分工。Shin 等人的研究發現，由人員專家先辨認重要特徵和使用者分組，再由大型語言模型把已整理證據綜合成使用者角色，所得結果在其研究中比單靠人員或單靠 LLM 更具代表性，也更能引發對使用者的同理心。⁹ Amini 等人其後在 Kinaxis 評估代理式批評與修訂（agentic critique-refinement）方法；領域專家把 PerGent 生成內容中的 96.9% 原樣批准，而生成的使用者角色亦補充了既有人工使用者角色沒有記錄、但被評為有用且不重複的內容。¹⁰ 這些結果支持由 AI 綜合資料和草擬紀錄，並由人員以專業判斷完成驗證。

規格優先交付把這種分工納入按既定程序管理的知識系統。AI 程式開發代理可以先載入已有的權威產品知識，再提出參與者關係、候選使用者角色的劃分、完整紀錄、知識缺口，以及供日後工作導向使用的使用者角色 Skill。既有規格尤其重要，因為當中保存了空白頁討論容易遺漏的決定，包括權限、故障行為、專業職能要求、曾經否決的假設、營運限制和既定術語。

一套實際可行的建立流程是：

1. 載入產品意圖、既有使用者研究、適用的穩定使用案例、現有規格與專項規格，以及相關架構、營運紀錄和目前實作現況；

2. 讓 AI 程式開發代理提出參與者關係和使用者角色組合，說明哪些差異足以影響產品，並指出互相矛盾或資料不足之處；

3. 由代理草擬完整使用者角色紀錄與使用者角色 Skill，並標示需要由人員確認的重要陳述；

4. 由實際履行相關參與者角色的人員，以及掌握相應決策權限的負責人，對各自有權確認的內容進行逐行確認；以及

5. 完成審查後才把紀錄視為權威知識，再讓後續結構化討論和規格工作依賴它。

逐行確認比一次過批准整份文件更嚴格，因為不同內容各有其權威來源。實際從業人員確認工作流程、工作量、人手介入、升級處理路徑、痛點，以及其他描述工作現實的內容；產品和領域負責人確認產品層面的解讀，以及產品應依賴哪些使用者角色差異；安全、可靠性、合規、無障礙、架構或其他專業職能，則確認自己專業權限範圍內的陳述。重大分歧要保持可見，直到具相應決策權的負責人作出決定。

使用者角色 Skill 亦需要相同審查紀律。persona-directory/SKILL.md 只要有一句導向規則寫錯，後續需求工作就可能完全沒有載入一個本來適用的使用者角色。因此，使用者角色摘要、適用於 規則、缺口處理、衝突導向和交付後審查觸發條件，都應按它所導向的使用者角色採用同一套權限模型逐行確認。

規格優先交付把權威起始知識、AI 輔助綜合、按需分層載入上下文和逐行人員確認，結合成一套運作模式。細緻管理規格，而非程式碼這項原則在此向上游延伸一層。使用者角色紀錄和導向 Skill 本身屬於按既定程序管理的產品知識，亦是形成需求與專項規格的材料。入門文章規格優先交付說明了知識與規格之間的關係。未經確認的使用者角色假設一旦進入這條鏈，便可能傳到多份下游規格，再變成生成的實作。因此，在知識傳播之前逐行確認，比到程式碼階段才發現錯誤更能直接控制風險。

返回頁頂

9. 與穩定使用案例及專項規格的關係

營運使用者角色和穩定使用案例回答互相連接但層次不同的問題。營運使用者角色說明一類在工作方式上有實質差異的人群，以及影響他們作出決定的營運現況；穩定使用案例則記錄一項重複目的或互動，讓產品即使改變個別功能和實作方式，仍能持續支援該目的或互動。

Alex 的使用者角色可能記錄他參與值班，而且目前仍要人手診斷複寫故障；某個穩定使用案例則可能要求「獲授權操作人員必須能夠調查並處理重大複寫問題」。自動化可以移除 Alex 的人手診斷步驟，但較高層次的使用案例仍然成立。如果產品日後把第一線人手應變完全移除，使用案例本身才可能需要重新審查。

兩者也是多對多關係。一個使用者角色可以參與多個穩定使用案例，而同一使用案例亦可以涉及多個限制條件和權限不同的使用者角色。結構化討論應按需求載入相關組合，讓各份使用者角色紀錄繼續保存其完整細節。即將發表的穩定使用案例文章會進一步說明這項關係。

返回頁頂

10. 決策權限與維護

使用者角色的品質取決於知識是否真確、重要並符合現況。團隊可因應使用者角色，從訪談、工作觀察、支援紀錄、營運指標、事故檢討、存取模型、工作流程文件、產品分析、問卷和領域專家取得資料。對使用者角色負有責任的產品或領域負責人，應能說明每項重要陳述為何屬於目前紀錄。

使用者角色庫要讓相關人員能夠提出質疑和修正。Matthews、Judge 和 Whittaker 訪問了 14 名具經驗的以使用者為中心設計從業者，發現受研究組織主要把使用者角色用作溝通，而非直接用於設計；受訪者亦認為使用者角色有時過於抽象、缺乏人性化特質、容易誤導或令人分心。作者因而指出，使用者角色無法取代對實際使用者數據的深入理解。¹¹ 權限模型需要讓日後參與工作的人員質疑可疑陳述，並把問題交由對相關營運現況負有責任的人員處理。

誰有權確認修改，應按被修改的內容決定：

• 產品和領域負責人通常負責確認哪些使用者角色足以代表產品的重要使用者和營運人員；

• 營運領導者和實際從業人員確認自己範疇內的責任、工作流程、升級處理路徑、工作量和目前痛點；

• 安全、私隱、可靠性、無障礙、合規或其他專業職能，確認屬於其專業權限的陳述；

• 工程師和 AI 可以指出使用者角色知識與目前實作或觀察所得營運現況之間的矛盾；任何涉及相關責任的重大修改，則由相應決策負責人確認。

一般事實更新可以沿用來源本身的正常維護程序。如果修改涉及重複責任、決策權限、主要營運條件、使用者角色的核心目標、它與參與者的關係，或使用者角色的拆分、合併和退役，就需要由權限受到影響的人員或職能審查。

返回頁頂

11. 按比例建立與驗證

使用者角色庫應保存會實質改變產品行為、需求解讀、工作流程、決策權限、存取權限、限制條件、營運應變或驗收方式的差異。這些差異足以支持建立獨立的營運使用者角色；其他特徵可留在產品模型以外，日後有決策需要時再納入。

簡單應用程式可以在整個產品生命週期只用一份 personas.md。產品變得複雜後，如果獨立紀錄、不同負責人、審查歷程或 AI 載入規則可以改善維護工作，這份檔案便可變成索引，或演進為 personas/ 目錄。設計和交付工作需要在多個使用者角色之間重複套用適用條件，或需要一套可重複執行的交付後演進審查程序時，使用者角色 Skill 便會發揮作用。知識系統只在產品出現實際需要時增加下一層複雜度。

一項實用驗證方法，是把相關使用者角色紀錄交給一名合資格但過往未接觸產品的參與者，確認他能否判斷：

• 這類人實際負責甚麼工作；

• 哪些參與者角色與營運職能適用；

• 使用者角色可以作出或批准哪些決定；

• 哪些工作條件、限制、規模和頻率會實質影響工作；

• 使用者角色依賴哪些資訊和其他參與者；

• 哪些目前痛點或人手介入仍然存在；

• 紀錄中哪些部分屬於較穩定的使用者角色核心，哪些屬於目前營運現況；

• 哪些人有權確認重大修改。

同一名參與者還應能把使用者角色套用到一項具代表性的需求，並指出實作依賴某套使用者假設之前，還有哪些問題必須先解決。

通過這項測試，代表使用者角色已成為可用的產品知識：內容具體得足以影響交付決策，現況準確得足以描述今天的工作方式，而且責任歸屬與維護程序清晰，日後的人員與 AI 因而能在保留相關人員決策權限的前提下依賴它。