iT邦幫忙

2026 iThome 鐵人賽

DAY 28
0
自我挑戰組

用 AI + draw.io MCP 建立可重複使用的流程圖工作流系列 第 28

# Day 28|痛點解決了嗎:重新檢視三個問題

  • 分享至 

  • xImage
  •  

昨天透過子流程 5,確認繪圖規格套用在資訊量較高的流程時,仍能維持一致的呈現方式。今天回到 Day 2、Day 3 提出的問題,逐項檢視導入整套工作流程後,哪些已有明顯改善,哪些仍保留限制。

回顧三個痛點

Day 2 討論的是需求反覆變動時,修改流程圖所累積的成本;Day 3 則進一步指出,即使改用 draw.io 並請 AI 協助產圖,這些成本也不會自然消失。兩篇文章提出的問題可以整理成三項:

  • Mermaid 的限制:版面主要由演算法決定,流程規模擴大後可讀性容易下降,修改也需要透過語法進行
  • 產圖、檢視與編輯分散在不同工具,還需要下載或匯入圖檔
  • 修改局部內容時,其他節點、連線或格式可能連帶改變,因此仍須重新檢查整張圖

痛點一:Mermaid 的限制

Day 2 提到,Mermaid 的版面主要由演算法計算。當使用者已有明確的版面構想時,節點位置與連線路徑不容易精確調整;流程規模擴大後,也較容易出現線條交錯或區塊集中等問題。若要修改內容或樣式,還得先找到對應語法,操作較不直觀。

目前的做法改用 draw.io XML。Day 18 說明 XML 如何描述節點文字、樣式與位置,Day 22、23 再把節點分類、配色、排列方向與 U 型外部呼叫等要求寫成繪圖規格。相較於 Mermaid 的自動版面配置,XML 可以直接指定座標與樣式,讓這些規則落到明確欄位,而不是只用「畫整齊一點」等抽象描述。

使用者也不必親自修改 XML,可以直接用自然語言提出「將這個節點改成外部系統的橘色」等需求,再由 Claude 依照規格調整。Day 27 的子流程 5 顯示,即使流程包含平行呼叫與多個分支,成品仍能維持一致的顏色分類與閱讀方向。

不過,這項痛點是大幅改善,而不是完全消失。節點座標仍由 Claude 產生,連線路徑也會經過 libavoid 計算;若對位置有非常精確的要求,仍可能需要進一步調整或人工檢查。

痛點二:產圖後還要下載匯入

Day 3 提到,網頁版工具產出 .drawio 檔後,通常需要先下載,再透過 draw.io 網頁編輯器開啟或匯入。在 IDE 中,如果沒有安裝視覺化編輯器或串接 draw.io,AI 完成產圖後,仍要切換到其他工具才能檢視。

Day 8~15 實測四種整合方式後,Day 16 最後選擇 MCP Tool Server。呼叫 open_drawio_xml 時,Claude 產出的 XML 會直接在瀏覽器版 draw.io 中開啟,省去下載與匯入步驟;使用者檢視結果後,也能回到同一段對話繼續提出修改需求。

MCP Tool Server 也將 XML、Mermaid 等輸入格式拆成不同工具。當 Skill 明確要求使用 XML 時,Claude 便會呼叫對應的 XML 工具,降低同一套工作流程在不同格式之間切換的可能性。這裡固定的是輸入格式與工具路徑,不代表模型每次都會產生完全相同的版面。

因此,下載與匯入的操作已明顯減少,但視覺檢查仍會在瀏覽器版 draw.io 中進行。它縮短了工具切換流程,並沒有把所有操作合併到同一個畫面裡。

痛點三:想改一個地方,卻必須重新檢查整張圖

Day 3 提出的第三個問題是:Claude 修改 draw.io 圖檔時,未必只調整指定內容,也可能連帶改變其他節點的位置、連線或格式。這些非預期變動很難只從對話或局部預覽察覺,因此每次修改後仍須重新檢查整張圖。

目前的做法不是直接在既有圖檔上進行局部修改,而是把「畫什麼」與「怎麼畫」分別寫進文件:流程說明文件(Day 20、21)定義內容,繪圖規格(Day 22、23)定義呈現方式,再由 Skill(Day 24~26)安排讀取與執行順序。後續若業務流程、判斷條件或輸出內容等需求有所變更,只需先修改流程說明文件中的對應段落,不必在對話中重新描述完整需求;若要調整配色、版面配置或連線方式,則更新繪圖規格。完成文件修改後,再依更新後的內容重新產圖。

這種做法的改善之處,是把產圖依據留在文件中。即使成品需要重新產生,也能回頭確認流程內容與繪圖規格,而不是只靠上一版圖檔作為參考。模板中的必備元素與繪圖規格,也提供了重新檢查時可以逐項核對的基準。

但它仍無法保證「只改指定節點,其他內容完全不變」。重新產圖時,未指定的節點座標或連線路徑仍可能改變。因此,第三項痛點目前只能算部分改善:非預期變動比較容易檢查。

哪些已改善,哪些仍有限制

回到 Day 2 最初的問題:改圖成本是否真的降低?目前的結果可以整理如下:

痛點 導入工作流程後的改善 仍然存在的限制
Mermaid 難以精確控制版面 改用 XML,將座標、樣式與連線要求寫成明確規格 Claude 產生的座標仍可能需要人工調整
產圖後需要下載與匯入 透過 MCP Tool Server 直接開啟瀏覽器版 draw.io 視覺檢查仍需在 draw.io 畫面中進行
局部修改可能影響其他內容 以流程文件與繪圖規格作為固定依據,降低任意變動並提供檢查基準 重新產圖仍可能改變未指定的節點或連線,尚未達成真正的增量修改

因此,前兩項痛點已有明顯改善,第三項則只解決了部分。這套工作流程的價值,不是讓修改與檢查完全消失,而是把原本散落在對話與圖檔中的依據整理成可重複使用的文件,讓每次修改都有相同的起點與核對標準。

明天將改用另一種視角:同一份流程說明文件,除了目前使用的 User Flow,是否也能產生其他圖表。下一篇先從 Swimming Lane 開始,同樣使用子流程 5,但觀察重點會從操作順序改為角色分工,呈現會員、系統、MCP Server、訂單系統、金流系統與客服後台通知中心各自負責的工作。


上一篇
# Day 27|套用規格後的成品:子流程 5 User Flow 解析
系列文
用 AI + draw.io MCP 建立可重複使用的流程圖工作流28
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言