昨天先定義了節點分類與配色，但還有一個問題尚未處理：這些節點該怎麼排列，彼此之間的連線又該怎麼畫？今天繼續補上排列方向、外部系統呼叫、連線繞線與圖例，完成這份繪圖規格文件。

排列方向：由上到下

這次將主流程的排列方向固定為由上到下（top-to-bottom）。原因很單純：它符合一般閱讀文件的順序。即使流程中有多個判斷點，讀者仍能沿著頁面由上往下閱讀，不需要另外猜測流程從哪裡開始、往哪個方向進行。

這條規則本身不複雜，卻先替所有流程圖固定了閱讀方向。接下來真正需要處理的，是外部系統呼叫如何呈現，以及連線如何避開其他節點。

外部系統呼叫：U 型資料流

在退換貨流程中，智慧客服平台不會自行處理所有工作：它需要透過 MCP Server 查詢訂單，也需要呼叫金流系統執行退款。如果把這些外部呼叫直接穿插在主流程中間，主線與外部路徑就容易混在一起，增加閱讀上的負擔。

這次採用「U 型資料流」：主流程節點向右發出呼叫箭頭 → 進入 MCP Server → 進入外部系統 → 再由外部系統往左回傳，銜接下一個主流程節點。這樣可以把外部呼叫安排在主流程右側，形成一條獨立的側邊路徑，避免與由上而下的主線混在一起。

每一段箭頭也要加上標籤，寫清楚呼叫內容與資料傳送方向，例如「呼叫查詢訂單資料」與「回傳訂單明細」。沒有標籤的箭頭只能看出兩個節點彼此相連，無法得知這次連線實際傳送了什麼。

連線繞線交給 libavoid

節點與外部呼叫的位置確定後，剩下的問題就是：連線要如何避開其他節點？

這裡的規則很明確：將連線繞線交給 draw.io 的 libavoid 引擎處理，呼叫 open_drawio_xml 時帶上 routing: "libavoid"。它會保留已經排好的節點位置，再把連線重新計算為避開節點的直角路徑。

由於 libavoid 會重新計算連線，規格中特別註明，不要手動加入 mxPoint 轉折點，也不要設定 exitX、exitY、entryX 或 entryY。這些手動路由設定可能會在重新計算時被覆蓋，因此每條連線只需要宣告 source 與 target。

回頭箭頭也交給 libavoid

Day 17 提過，子流程 2 有一條迴圈：連線失敗時，流程會回到前面已經出現的錯誤彈窗。如果回頭箭頭與主流程線疊在一起，讀者就不容易分辨哪一條是正常路徑、哪一條是返回前面步驟的路徑。

這類連線同樣交給 libavoid 處理。回頭箭頭只需要宣告 source 與 target，再由引擎自動避開中間節點，讓它與主流程線分開，形成一條容易辨識的獨立路徑。

用圖例說明顏色對應

最後一項是圖例（Legend）。Day 22 已經提過，顏色本身沒有特定意義，因此不能期待讀者只看顏色就知道節點類型。每張圖的頂部都要列出六種節點類型及其對應顏色，讓讀者可以直接在圖內查找，不必記住整套配色，也不需要反覆回頭對照繪圖規格文件。

兩份文件合起來，解決了哪些問題

流程說明文件（Day 20、21）加上繪圖規格文件（Day 22、23），到這裡可以回頭檢視 Day 17 提出的三個問題：

• 每次都要重頭口述 → 將內容記錄在流程說明文件裡，不需要每次重新說明
• 資訊不足時，AI 需要自行判斷 → 流程內容由模板規範，呈現方式則由繪圖規格約束
• 缺少基準，不容易驗收 → 模板中的「必須呈現的元素」，加上這兩天定案的配色與版面配置規則，共同構成核對清單

流程說明文件負責回答「畫什麼」，繪圖規格文件則回答「怎麼畫」。兩者合在一起，才算補上 Day 17 留下的缺口。

不過，這兩份文件目前仍是獨立的參考資料。每次使用時，都得手動告訴 AI「請依照這份模板」與「請依照這份規格」。明天要處理的，就是如何把這套流程包裝成一個可以直接呼叫、不必每次重新說明的 Skill。