昨天把四種整合方式測完，也選定了 MCP Tool Server。工具的部分算是告一段落，但工具只負責把圖畫出來，不負責圖畫得對不對。

今天換一段比登入更複雜的子流程，實際跑一次，看看問題會從哪裡冒出來。

這次換成子流程 2

在 Day 8 到 Day 15 裡，我用的範例是流程文件中的「子流程 1：電商登入」。這段邏輯非常單純——八個步驟、兩個判斷分支加一條回頭線。拿來對照四種工具的呈現方式很剛好；但若想拿它來抓 AI 繪圖的邏輯盲點，難度比較低，較不易測出破綻

所以這次換成子流程 2「AI 智慧客服平台頁面」。它的判斷點是這樣寫的：

## 判斷點
- 網頁是否已開啟麥克風權限
  - 否：
    - 麥克風呈現禁用狀態
    - 僅文字框可供輸入
    - 進入智慧客服對話頁面
  - 是：系統檢查是否已建立 WebSocket 連線
- 是否已建立 WebSocket 連線
  - 是：進入智慧客服對話頁面，麥克風按鈕呈現啟用狀態，文字框可輸入文字
  - 否：
    - 麥克風呈現禁用狀態，文字框不可輸入文字內容
    - 系統顯示錯誤訊息彈窗，告知會員未連線成功
    - 會員點擊彈窗確認
    - 系統重新刷新頁面
    - 再次確認系統是否連線成功
      - 是：進入智慧客服對話頁面
      - 否：返回系統顯示錯誤訊息彈窗，告知會員未連線成功

比起登入流程，這段多了三件事：判斷點有巢狀、兩條不同路徑最後匯流到同一個結果、而且有一個真正的迴圈——連線失敗會一直繞回錯誤彈窗。

問題一：起點通常不是文件，而是一段口語描述

先釐清一件事：上述的那些判斷點以及流程說明內容，是我跟 Claude Code 反覆討論後才定版出的架構。

一般人若使用 AI 畫流程圖，通常是在對話框裡輸入一段內容，預想如下：

幫我畫一個流程圖，使用者進到 AI 客服頁面，
系統會先看有沒有開麥克風權限，沒開的話麥克風就不能用，只能打字，然後進對話頁。
有開的話再檢查 WebSocket 有沒有連上，連上就正常進對話頁，
沒連上就跳錯誤彈窗，使用者按確認之後重新整理，再檢查一次。

講的是同一件事，但可以看到一些存在的問題：

• 分支容易漏掉：「再檢查一次」之後呢？連上了進對話頁，那還是沒連上要回到哪裡？口語講到這邊通常就斷了，剩下的細節容易變成 AI 自行腦補。
• 每次講法都不一樣：同一段流程，今天這樣講、下週再換個方式說，許多順序、用詞與細節都會有出入，產出的圖自然跟著不一樣。
• 改版就要整段重講：流程多一個等待提示，沒辦法只跟 AI 說「這裡加一個節點」——它下一次產圖是重新產一張，不是在舊圖上動刀，要重畫整張圖就需要完整的流程資訊。同一個對話裡還好，AI 記得前面講過什麼；但換個對話視窗、或隔幾天回來，上下文沒了，就只能整段重講。

這件事在只畫一張圖時感受不深。但若遇到多個子流程，像本案的流程說明文件就有五個，而且實務上跟需求單位來回確認的過程中，流程改個兩三版是很常見的事。每次改完都要重新口述一遍，時間幾乎都花在重複描述同一段流程上。

問題二：沒有參考依據，AI 就會自己決定

第二個問題是發散。

流程說明文件寫的是「做什麼」，沒有寫「怎麼畫」。中間那段空白，AI 會自己補完——而它每次補的答案不見得一樣。

一句話到底是幾個節點

看這一段：

否：麥克風呈現禁用狀態、僅文字框可供輸入、進入智慧客服對話頁面

這是三個節點串起來，還是一個節點裡寫三行說明？文件沒有規定，兩種畫法都說得通。AI 這次拆成三顆，下次可能併成一顆，同一份文件產出的兩張圖就長得不一樣。

節點的顆粒度沒有標準答案，但一張圖裡至少要一致。沒有依據時，連一致都做不到。

迴圈容易被畫成直線

更麻煩的是最後那條：

否：返回系統顯示錯誤訊息彈窗，告知會員未連線成功

「返回」的意思是連回前面那顆已經存在的彈窗節點，形成迴圈。但 AI 有時候會照字面再畫一顆一模一樣的彈窗接在後面——流程圖就從迴圈變成了直線。

這種錯特別危險，因為圖看起來完全正常：形狀對、文字對、連線也沒斷。只有真的去追邏輯，才會發現這張圖說的是「失敗一次就結束」，而不是文件寫的「失敗會一直重試」。

問題三：沒有基準，就沒辦法驗收

前兩個問題還有一個共同的後果：你很難判斷這張圖到底對不對。

Day 9 和 Day 11 測登入流程時，我的檢查點是自己臨時想的——兩個判斷節點在不在、兩條錯誤路徑有沒有正確返回。流程只有八步，用眼睛看完全沒問題。

但子流程 2 的判斷點有巢狀、有匯流、有迴圈，光是要確認「每一條分支都有對應的線」，就得對著文件一條一條數。而完整的端到端流程有五個子流程，圖再大幾倍，這種檢查方式就失效了。

沒有寫下來的規格，就沒有可以逐項核對的清單。圖對不對，最後只能靠印象判斷。

這些問題指向同一件事

三個問題長得不一樣，但根源相同：產圖的依據沒有留下來。

流程講在對話裡，改版時就要重講；畫法沒有寫下來，AI 只好每次自己決定；驗收標準沒有文件化，就沒有東西可以核對。

順帶一提，還有一個我先擱著的問題：顏色、節點大小、開始與結束節點的樣式，每次產出來也都不太一樣。單看一張圖沒什麼感覺，但把兩張並排放進同一份文件裡，就會發現它們不像出自同一套規則。這個之後談繪圖規格時再處理。

要讓這套流程能重複運行，得先把「依據」從對話裡搬到文件裡。但在寫文件之前，我想先弄懂一件事：draw.io 產出的 XML 到底長什麼樣子？知道圖是怎麼被描述的，才知道規格能約束到哪些地方。

明天就來讀一次 draw.io 的 XML 結構。