昨天討論完 draw.io 的 XML 結構後，我不僅更深入理解圖檔背後的組成與運作方式，也開始注意到每次繪圖時都有一些固定且重複的流程。這讓我進一步思考，是否能將這些步驟整理並自動化，減少重複操作，讓整體繪圖流程更加有效率。

每次畫圖，其實都在走同一條路

回想起畫流程圖的過程，不管是哪個專案、哪個系統，節奏都差不多：

跟需求單位討論需求
  → 把討論結果整理成文件
    → 依文件畫成流程圖
      → 反覆迭代修改

即使換了功能或需求單位，實際執行時，似乎仍會反覆經過相近的四個步驟。雖然細節未必完全相同，但整體脈絡具有一定的規律。

這樣的現象或許不算特別，卻讓我開始意識到：當一套流程重複出現，而且能從中找到共同的線索時，就可能形成一種值得留意的 Pattern。

辨識出 Pattern 之後，下一步不一定是立刻將它自動化，而是先嘗試把流程整理得更清楚。因為如果每次都要重新進行類似的判斷、資料整理與文字描述，長期下來難免會耗費不少時間。回頭看 Day 17 提到的三個問題，某種程度上，也可能與這些反覆執行、卻尚未被系統化整理的流程有關。

哪些該固定，哪些該重複

要把 Pattern 變成工作流，第一件事是分清楚：什麼只做一次，什麼每次都要做。

一次性的環境建置

安裝 MCP Tool Server → 簡單測試，確認可產圖並開啟瀏覽器版 draw.io

這就是 Day 10 到 Day 11 做的事。裝好、測過，之後就不用再碰。

可重複使用的繪圖工作流程

                   有沒有流程說明文件？
                   ├─ 沒有 → AI 引導梳理流程
                   │          （涉及系統、角色、步驟、判斷點……）
                   │            → 依「流程說明文件模板」產出結構化 MD 檔
                   │              ↓
                   └─ 有 ─────→ AI 產製流程圖
                                （參考流程說明文件 ＋ 自訂繪圖規則）
                                  → draw.io MCP 開啟瀏覽器編輯頁面

整張圖的關鍵在最前面那個判斷點：有沒有流程說明文件？

這個判斷點看起來很簡單，但它正是 Day 17 那三個問題的解方所在。沒有文件時，不是直接開始畫，而是先把流程梳理成文件；有文件時，AI 才依文件產圖。畫圖這件事永遠有依據，不再是每次從口述開始。

兩份文件，各自負責不同得任務

在前面的全局圖中，可以看到兩份用途不同的文件。先釐清它們各自負責的範圍，後續在整理流程與繪製圖表時，才不容易混淆。

將兩者分開，不只是為了讓文件看起來更有條理，也是因為它們處理的問題與變動時機不同。流程說明文件模板決定需要向使用者確認哪些資訊；繪圖規格則定義圖表最後應該呈現什麼樣子。分開維護，可以在調整其中一項時，盡量避免影響另一項。
如果對照 Day 18 介紹的 XML 結構，兩者的分工會更清楚：繪圖規格主要影響 style 與 mxGeometry，也就是節點的外觀、尺寸與位置；流程說明文件則提供 value 的內容，並影響需要建立多少節點，以及節點之間如何連線。
換句話說，這兩份文件分別管理圖表的「內容」與「呈現方式」，也恰好對應到 XML 中不同的組成部分。

從 Pattern 到指令，中間還需要幾個環節

目前這張全局圖呈現的，主要是整體架構。若要讓它成為一套真正可以使用的工具，還需要逐步補上幾個環節：

Pattern → 工作流 → Skill → 素材（模板／規格）→ Slash Command

• Pattern：從重複的操作中找出共通規律
• 工作流：整理執行步驟，並標示其中的判斷點
• Skill：將工作流轉換成 AI 能夠理解與遵循的操作說明
• 素材：準備 Skill 執行時需要參考的模板與規格
• Slash Command：透過一個指令，啟動整套流程

接下來幾天，我會依照這個脈絡逐步補齊內容。不過在撰寫 Skill 之前，得先準備好它執行時所需的素材，因此會先從模板與規格著手。

明天會討論第一份素材——流程說明文件模板，進一步拆解其中需要包含哪些欄位，以及每個欄位在流程中扮演的角色。