昨天附上了 flow-chart-creator 的完整 SKILL.md，這套工作流程的規則也說明完畢。今天改從實際成品來檢視：以系列持續使用的電商退換貨案例為例，選擇資訊量較多的子流程 5「建立退貨單與退款申請」，對照 Day 20～23 定案的模板與規格，逐項確認顏色、版面配置與連線規則是否確實呈現在成品中。
子流程 5 是這份流程說明文件的最後一段。完成登入、進入客服平台、辨識退換貨意圖，以及選擇訂單與描述原因後，會員端的輸入便告一段落；接下來的退貨單與退款申請，都由系統接手處理。
觸發條件是會員已確認退貨商品與退貨原因。系統取得這兩項輸入後，會呼叫 MCP Server，同時向訂單系統送出「建立退貨單」請求，並向金流系統送出「建立退款申請」請求，再接收兩個系統的處理結果。
系統會先檢查退貨單是否建立成功。若建立失敗，就提示會員稍後再試或轉接人工客服，並結束流程；若建立成功，才會繼續檢查退款申請。無論退款申請成功或失敗，前台都會顯示退貨申請成功訊息，但後台收到的通知不同：兩者都成功時推送成功通知；退款申請失敗時則推送異常通知，並列入客服待處理清單。
因此，這個子流程共有三種結果：退貨單建立失敗、退貨單與退款申請都成功，以及退貨單成功但退款申請失敗。後兩種結果對會員呈現相同訊息，客服後台則依實際處理結果收到不同通知。
在子流程清單中，子流程 5 是唯一同時呼叫兩個外部系統的段落。訂單系統與金流系統分別處理請求並回傳結果後，系統還要綜合兩個結果，判斷應該推送成功通知或異常通知。
相較於子流程 1 的登入流程，這種「平行呼叫、分別回傳、合併判斷」的結構更為複雜，也更適合用來檢驗繪圖規格能否維持清楚且一致的版面。
檢視 .drawio 中的節點座標與連線設定後，可以依照畫面由上到下的順序，逐項對照 Day 20～23 定案的規格：
主線由上到下：開始 → 系統呼叫 MCP Server → 系統接收回傳結果 → 退貨單是否建立成功 → 退款申請是否建立成功 → 前台顯示成功訊息 → 系統推送成功通知 → 流程結束。主要成功路徑沿著畫面左側由上而下排列，沒有因為加入外部系統呼叫而改變閱讀方向。
外部呼叫採用 U 型側邊路徑：「系統呼叫 MCP Server」節點向右連到 MCP Server，再向下分成訂單系統與金流系統兩條路徑。兩個系統分別回傳結果後，連線再向左匯入「系統接收回傳結果」。外部呼叫集中在主線右側，不會打斷由上而下的閱讀順序。
失敗分支獨立排列：「退貨單是否建立成功」判斷為否時，流程會前往「提示會員稍後再試或轉接人工客服」，接著結束。這條路徑位於主線右側，能清楚看出它是離開主要成功路徑的分支。退款申請失敗時的「前台仍顯示成功訊息」與「系統推送異常通知」也採相同方式，與成功路徑左右並列。
決策節點使用菱形：「退貨單是否建立成功」與「退款申請是否建立成功」都使用規格定義的菱形，與一般的圓角矩形步驟節點區隔。「是」與「否」也直接標示在對應連線上，讀者可以從圖中辨識分支邏輯。
呼叫與回傳皆有文字標籤：「呼叫建立退貨單／退款申請」「轉發建立退貨單請求」「轉發建立退款申請請求」「回傳退貨單建立結果」「回傳退款申請建立結果」五段連線都有標示，能直接看出資料的傳送方向與內容。
兩條通知路徑匯入同一節點：成功路徑的「推送成功通知」與退款失敗路徑的「推送異常通知」，最後都指向畫面右側的「客服後台通知中心」。兩條連線分別標示「成功通知」與「異常通知」，與流程說明文件中「兩種結果都要推送至同一個通知中心」的描述一致。
圖例位於最上方：六色圖例橫向排列在畫面頂端，對應 Day 22 定案的六種節點類型：使用者操作、系統處理、MCP Server、外部系統、決策節點、開始／結束。由於子流程 5 沒有會員操作步驟，實際節點只使用其中五類，但圖例仍保留完整的六種類型。
連線路徑交由 libavoid 計算：成品中的連線帶有 exitX、entryX 等進出點座標；MCP Server 分流至兩個外部系統，以及通知匯入客服後台通知中心等路徑，還包含額外的轉折點。這與 Day 23 的規則並不衝突：規格要求的是產生 XML 時不要預先手動指定路徑，而 routing: "libavoid" 完成計算後，成品本來就會寫入這些座標資料。
子流程 5 包含兩個外部系統的平行呼叫、兩層判斷與三種處理結果，資訊量明顯高於前面的單一路徑流程。從成品可以看出，顏色分類、U 型外部呼叫、菱形決策節點、連線標籤與圖例位置都依照 Day 20～23 的規則呈現，整體閱讀順序仍然清楚。
這也說明，繪圖規格不只適用於簡單流程。面對平行呼叫與多個分支時，同一套規則仍能提供一致的呈現方式與明確的檢查依據。
明天將回到系列一開始提出的痛點，逐項檢視導入整套工作流程後，實際改善到什麼程度。
iThome鐵人賽
看影片追技術