昨天透過 Swimming Lane 將子流程 5 拆成六條泳道，清楚呈現各角色的活動分布與跨系統交接。今天是系列最後一天，我會使用相同流程與參與者，改畫 Sequence Diagram（時序圖），將焦點轉向呼叫順序與訊息往返。

為什麼最後要補一張時序圖

前兩張圖分別回答不同問題：User Flow 說明「接下來會發生什麼」，Swimming Lane 呈現「這一步由誰負責」。兩者都能表達流程走向，但較難精確說明呼叫的先後與巢狀關係。

以子流程 5 為例，系統呼叫 MCP Server 後，訂單系統與金流系統是依序處理，還是同時開始？外部系統完成處理後，結果會先回到 MCP Server，還是直接送回系統？若只觀察流程箭頭或跨泳道連線，仍可能有不同解讀。

Sequence Diagram 的生命線與執行條（activation bar）適合呈現這類資訊。時間由上而下推進，每則訊息都有對應位置；執行條則標示參與者在某段時間內正在處理工作。

圖表的組成方式

• 沿用六個參與者：會員、AI 智慧客服平台、MCP Server、訂單系統、金流系統與客服後台通知中心。角色名稱與配色皆延續 Day 29，方便並排比較兩張圖。

• 生命線由上而下代表時間：每個參與者下方都有一條虛線，訊息位置越低，表示發生時間越晚。雖然位置本身已能表達順序，圖中仍保留十二則訊息的編號，以便文章引用。

• 執行條標示處理區間：

  • AI 智慧客服平台：從第 1 則訊息開始接手，並在後續流程中持續處理
  • MCP Server：從接收第 2 則訊息到回傳第 7 則訊息為止
  • 訂單系統與金流系統：各自在接收請求至回傳結果的區間內執行
  • 客服後台通知中心：分別在接收成功通知與異常通知時啟用

  執行條的長短與位置，可用來比較各參與者介入流程的時間點與持續範圍。

• 以實線表示請求、虛線表示回傳：這項視覺規則延續 Day 29，也符合常見的 UML 時序圖表達方式。圖中實線箭頭用於送出請求，虛線箭頭則用於回傳處理結果。

十二則訊息

1. 會員 → 系統：確認退貨商品與退貨原因（承接子流程 4）
2. 系統 → MCP Server：呼叫 MCP 工具，建立退貨單與退款申請

第 3 至第 6 則訊息位於 par 片段中，分成兩組並行互動。下列編號是圖上的訊息識別，不代表第 5 則一定要等第 4 則完成後才開始：

3. MCP Server → 訂單系統：建立退貨單

4. 訂單系統 ⇢ MCP Server：回傳退貨單建立結果

5. MCP Server → 金流系統：建立退款申請

6. 金流系統 ⇢ MCP Server：回傳退款申請建立結果

7. MCP Server ⇢ 系統：回傳兩系統的建立結果

接著依建立結果分成三種情況：

8. 【退貨單建立失敗】系統 → 會員：提示稍後再試或轉接人工客服
9. 【退貨單成功、退款申請成功】系統 → 會員：顯示退貨申請成功訊息（可點擊放大鏡查看細節）
10. 【退貨單成功、退款申請成功】系統 → 客服後台通知中心：推送建立成功通知
11. 【退貨單成功、退款申請失敗】系統 → 會員：仍顯示退貨申請成功訊息（可點擊放大鏡查看細節）
12. 【退貨單成功、退款申請失敗】系統 → 客服後台通知中心：推送建立異常通知，並列入客服待處理清單

par 與 alt：兩種組合片段

Sequence Diagram 使用組合片段（combined fragment）表達並行與條件分支，這張圖採用了兩種：

• par（並行）包含第 3 至第 6 則訊息：框內以虛線分隔兩組互動，上半部是 MCP Server 與訂單系統，下半部是 MCP Server 與金流系統，表示兩組請求可並行處理。這對應流程說明文件中「同時建立退貨單與退款申請」的敘述。

  User Flow 與 Swimming Lane 可以透過分岔連線表達同時處理，但 par 能更明確地標示兩組互動之間沒有固定的先後順序。

• alt（條件分支）包含第 8 至第 12 則訊息：框內分成三個區段，分別標示 [退貨單建立失敗]、[退貨單成功、退款申請建立成功] 與 [退貨單成功、退款申請建立失敗]。這三項條件對應 Day 27 整理的三種流程結果。

  後兩個分支尤其值得比較：會員看到的訊息相近，但客服後台接收的是成功或異常通知。將兩者置於同一個 alt 片段中，可以直接看出不同接收者取得的資訊並不相同。

三張圖的分工

同一段子流程 5，使用三種圖表可以分別回答不同問題：

這次沒有繪製 ER Diagram，原因是流程說明文件著重於動作與判斷，並未定義退貨單、退款申請等資料實體的欄位與關係。在缺少資料模型的情況下繪製 ER Diagram，內容將建立在過多假設上。這再次說明：圖表能呈現多少資訊，取決於來源文件提供了多少依據。

系列總結

三十天下來，這套工作流程逐步整理出兩份基礎文件、一個 Skill 與一項繪圖工具：

• 流程說明文件（Day 20、21）定義「要畫什麼」
• 繪圖規格（Day 22、23）定義「要怎麼畫」
• flow-chart-creator Skill（Day 24～26）定義互動步驟與資料讀取順序
• draw.io MCP Tool Server（Day 10、11、16）負責開啟產出的 XML，供使用者檢視與後續編輯

Day 29 與 Day 30 也顯示，同一份流程說明可以作為多種圖表的共同基礎，不必每次都重新整理完整需求；不過，不同圖表關注的資訊不同，也可能進一步揭露文件尚未討論到的細節。例如，這兩張圖採用了「MCP Server 彙整兩系統結果」的架構假設，實際做法仍應另行確認。

這正是 Day 1 希望達成的方向：將過去散落在對話中的判斷，整理成可重複使用、也能持續修正的依據。

三十天的實作與整理到此告一段落，謝謝。