Day 21 整理出一份完整的流程說明文件，但結尾也留下另一個問題：文件回答了「這個流程做了什麼」，卻還沒說明「這些內容要怎麼畫」。今天就從節點分類與配色開始，把繪圖規格逐步補齊。

內容固定了，呈現方式卻不一定

Day 17 測試子流程 2 時，其實就已經注意到這個問題，只是當時暫時擱著，沒有繼續處理：

顏色、節點大小、開始與結束節點的樣式，每次產出時都有可能不同。單看一張圖或許沒什麼感覺，但把多張圖並排放進同一份文件裡，就可能發現它們不像出自同一套規則。

流程說明文件處理的是「內容」，例如判斷點有沒有遺漏、迴圈是否完整；它沒有規定圖表該使用哪些顏色與節點樣式。少了這一層規格，即使輸入同一份文件，AI 仍需要自行決定呈現方式：這次可能以藍色代表使用者操作，下次也可能改用綠色；「建立退貨單」這次使用矩形節點，下次則可能變成圓角矩形。

這些差異不一定每次都會出現，單看一張圖時也未必構成問題。不過，退換貨流程共有五個子流程；當多張圖放進同一份文件裡，只要其中幾張採用不同的配色或節點樣式，整體看起來就可能不像出自同一套規則。

從「涉及系統」清單反推節點分類

回頭看 Day 21 那份流程說明文件的「涉及系統」欄位：

# 涉及系統
- 電商購物網站
- AI 智慧客服平台
- MCP server
- 訂單系統
- 金流系統
- 客服後台通知中心

Day 21 提過，當時只是如實列出相關系統，還沒有特別思考這份清單的用途。直到開始規劃配色，才發現它正好可以作為節點分類的依據。清單中的系統大致可分成三類：

• 平台本身負責的畫面與處理邏輯，例如智慧客服平台的意圖辨識與退貨單建立
• 負責串接後端系統的 MCP Server
• 平台需要呼叫的外部系統，例如訂單系統、金流系統、客服後台通知中心

再加上流程圖中原本就會出現的「使用者操作」「決策節點」與「開始／結束」，一共形成六種節點類型。

真正重要的不是分成幾類，而是每一類如何對應流程說明文件中的資訊。只要先建立明確的分類規則，往後填好「涉及系統」清單，AI 就能判斷各節點應套用哪一組顏色，不必在每次繪圖前重新確認。

定案的顏色規範

這些顏色本身沒有特定意義，也不是業界通用的固定標準。這次選色主要是為了區分不同類型的節點，並以較淺的底色維持文字的清晰度。重點不在於「使用者操作為什麼是藍色」，而是規則定案後，所有使用者操作都固定使用同一組藍色色碼。

依照這個原則，最後定案的配色如下：

以退換貨案例來看，會員輸入帳號密碼、點擊按鈕，屬於「使用者操作」；智慧客服平台執行的辨識與處理，屬於「系統處理」；MCP Server 獨立列為一類；訂單系統、金流系統與客服後台通知中心等被呼叫的對象，則歸為「外部系統」。需要依結果產生分支的條件使用「決策節點」，流程的起點與終點則使用「開始／結束」。

表格不只列出顏色名稱，也明確指定代表底色的 fillColor，以及代表邊框色的 strokeColor。這麼做是為了讓 AI 繪圖時直接套用固定色碼，避免自行解讀「藍色」究竟是哪一種藍，讓不同圖表維持一致。

配色固定了，版面配置還沒有

配色表定案後，Day 17 提到的「顏色可能不一致」就有了可以核對的標準：無論用同一份文件重畫幾次，或改用哪一種工具，同類型的節點都應套用相同色碼。

不過，配色只能回答「這個節點該使用什麼顏色」，還無法決定「這些節點該怎麼排列」。使用者操作與系統處理要放在同一條線上，還是分成兩欄？呼叫外部系統時，箭頭要如何繞過其他節點？這些版面配置問題，單靠顏色規範仍無法解決。

明天會接著整理版面配置規則：節點如何排列、連線如何避開其他元素，以及是否需要加入圖例，把整份繪圖規格文件補完整。