drawio-skill 是什麼？把文字與程式碼變成可編輯架構圖，AI 畫完還能繼續改
drawio-skill 能把自然語言、程式碼與基礎設施設定轉成可編輯的 draw.io 圖。本文介紹架構圖、來源追蹤、增量更新與圖表檢查，說明它和一般 AI 生圖有何差別，以及如何評估成果。
AI 可以畫出漂亮的架構圖，但你要修改一條箭頭或更換服務名稱時，常常只能重新生成整張圖片。drawio-skill 近期在 X 被分享，提供了另一條路：把文字、程式碼與系統設定轉成可編輯的 draw.io 文件，讓方塊、連線與結構都能繼續修改。
這個開源專案的重點，是讓圖表成為能維護的工作成果。它除了接受自然語言，也能從程式與基礎設施設定整理結構，並保存部分來源關係。當系統變動時，可以嘗試更新受影響的部分，讓人工整理過的版面繼續保留。
對開發者、產品經理與需要向同事說明系統的人，這個方向很實用。只是，圖表可編輯不代表內容一定正確，從程式整理結構也不等於已完整理解正式環境。本文會拆解 drawio-skill 的能力，說明它適合哪些圖，以及使用者如何檢查來源、關係與後續更新。
先認識 draw.io：為什麼可編輯比漂亮更重要？
draw.io 是常見的圖表編輯工具，也稱為 diagrams.net。它可以建立流程圖、架構圖與其他包含方塊和連線的文件。保存成 .drawio 格式時，圖中的元素仍是可以移動、改字與重新連線的物件，而不是只有一張平面圖片。
這個差別會影響後續工作。假設你要向客戶展示三個服務之間的資料流，會議中對方要求把資料庫改成兩個。可編輯圖表可以直接新增節點與修改連線。只有圖片的成果則可能需要回到生成工具重新描述，或用其他工具覆蓋修改，耗費更多時間。
一般 AI 生圖也能畫出看似合理的技術圖，但文字、箭頭方向與連線數量可能不精確。生成過程以影像為核心，未必保存每個元素的結構。drawio-skill 則把圖表當作有節點與關係的文件來處理，這比較接近日常架構文件需要的工作方式。
它的價值因此不只在第一張圖，而在第二次、第三次修改。系統架構會變，負責人也會交接，圖表若能追蹤來源並持續更新，就更有機會成為文件的一部分。使用者仍需要驗證內容，才能避免把一份好修改的錯誤圖表傳給整個團隊。
drawio-skill 能從哪些資料建立圖表？
依照官方 GitHub 文件，專案可以接受自然語言描述，也包含從程式碼、基礎設施設定與介面定義整理圖表的能力。文件列出多種圖類型與輸入，使用時應按自己需要的路徑確認條件，而不是假設所有資料都能用同一個指令處理。
自然語言適合最初構想，例如「建立一個包含網站、API、資料庫與快取的服務架構」。這能快速把想法放到畫面上，也方便非工程成員參與討論。它仍依賴描述是否完整，如果沒有提到權限或外部服務，圖中未必會自動補上正確的正式架構。
程式碼輸入則適合整理模組、類別與關係。文件列出 Python、JavaScript、Go 與 Rust 等路徑，能協助把某些程式結構轉成圖。這些結構較接近靜態檔案中可看到的關係，實際執行時的動態呼叫、環境變數與條件分支，仍可能需要額外確認。
基礎設施設定包含 Terraform、Kubernetes 與部分執行環境資訊。Terraform 用來描述雲端資源，Kubernetes 用來管理容器工作。從這些設定生成圖表，有機會減少人工逐個畫服務的時間，但設定檔是否與正式部署一致，是另一個需要驗證的問題。
| 輸入方式 | 適合的需求 | 需要檢查的地方 |
|---|---|---|
| 自然語言 | 討論概念與初步架構 | 是否漏掉必要服務與條件 |
| 程式碼 | 模組、類別與依賴說明 | 靜態關係是否代表實際運行 |
| 基礎設施設定 | 雲端資源與部署結構 | 設定是否對應目前環境 |
| SQL 與介面定義 | 資料結構、服務介面 | 欄位與關係是否完整 |
| 既有圖片或草圖 | 重建成可修改圖表 | 文字與連線是否辨識正確 |
官方文件也提到 SQL DDL、OpenAPI 等輸入。DDL 描述資料庫結構，OpenAPI 描述服務介面。這些格式帶有結構資訊，通常比一張照片更容易追蹤來源。但如果原始文件已過期，圖表生成得再準確，也只是更整齊地呈現過期資訊。
從來源到版面，中間有一層圖表結構
專案文件使用 DiagramIR 表示中間的圖表資料結構，可以理解為「先整理有哪些元素與關係，再決定怎麼畫」。這一層也包含來源與幾何位置等資訊。把內容與版面分開，有助於更新一個服務時，不必每次都重新排完整張圖。
來源追蹤尤其重要。假設圖中某個節點來自程式模組，另一個來自部署設定，使用者可以更有依據地檢查它們。若 AI 自行推測了一條連線，就應和有直接來源的關係區分。對正式架構文件，這種差別比配色是否漂亮更重要。
增量更新指資料變動後，修改受影響的圖表部分。官方文件強調保留人工安排的版面，讓使用者已經整理過的結構不必全部重做。實際是否能保留到符合預期，仍需要拿真實修改測試，尤其是新增很多節點或大幅改變關係時。
這個設計與一般生圖不同：使用者可以把生成結果當成起點，接著手動調整，再回來更新來源。當工具能理解哪些是內容變更、哪些是使用者的版面選擇，圖表才更有機會成為持續維護的文件。這也是評估時值得優先測試的一部分。
用產品網站示範：一句話畫圖後還要做什麼？
假設你準備做一個課程網站，包含登入、課程內容、付款與後台。這是本文的示意情境。第一版可以用文字描述主要服務，再生成架構圖，讓團隊先討論資料會從哪裡進來、在哪裡保存，以及誰能操作。
接著應核對服務邊界。付款是否由外部供應商處理？影片是否儲存在獨立平台？後台是否有不同角色？這些資訊若沒有出現在輸入裡，AI 可能只畫出一個看似完整的通用網站。圖表漂亮，卻不能代表它已經理解你的實際產品。
第二版可以補上部署與介面資料，讓圖表對應真正的系統。使用者再檢查箭頭方向與資料內容，例如付款結果是網站查詢回來，還是外部服務主動通知。兩種流程可能需要不同的錯誤處理，畫錯方向會讓討論建立在錯誤假設上。
最後保存可編輯文件與來源版本，讓下一次改動有比較基準。若只是輸出 PNG 交給同事，可編輯與來源追蹤的優勢就不容易延續。團隊可以同時保留 .drawio 文件與方便閱讀的圖片，讓展示和維護各有合適的成果格式。
官方提到的檢查與輸出，怎麼理解？
文件包含渲染後檢查與反覆修正的流程，讓代理有機會看到實際圖像，再調整版面。渲染是把圖表結構轉成畫面，這一步能暴露文字太長、元素重疊或連線難讀等問題。只看結構資料正確，仍可能得到一張不方便閱讀的圖。
但視覺檢查只能處理部分問題。一條箭頭畫得很清楚，方向仍可能不符合真實流程。圖表沒有重疊，也可能漏掉核心服務。因此，排版品質與語意正確性最好分開驗收，避免「看起來乾淨」變成唯一的完成標準。
專案也提到把圖表當作可以檢查的結構，例如依規則確認某些關係、在持續整合流程中比較差異。持續整合是程式更新後自動執行檢查的工作方式。這有助於把架構文件和程式改動連起來，但規則是否涵蓋真正風險，仍由團隊決定。
其他輸出包含互動 HTML、簡報與動態圖形等方向。它們可以讓同一份結構服務不同展示需求，但並不是每種格式都保留相同的編輯能力。要交付給同事時，應先確認對方需要修改、展示或嵌入網站，再選擇合適格式。
使用前，先檢查工具與資料權限
AI 讀取程式與部署設定時，可能接觸服務名稱、內部網址或其他敏感資訊。使用前應確認資料會在哪裡處理，以及哪些檔案真的需要提供。不要為了畫一張概念圖，就把整個工作區與所有設定都交給工具。
官方文件提到離線核心與可選的工具整合，這些路徑的使用條件可能不同。某個步驟可以在本機執行，不代表整個 AI 對話也都在本機。若模型由遠端服務提供，送出的文字與檔案仍可能經由該服務處理，應依實際流程理解資料去向。
若從正在運行的環境讀資料，也要分清楚只讀與寫入。畫圖通常需要讀取結構資訊，未必需要修改資源。把工具權限限制在必要範圍，能讓測試更容易管理，也避免圖表生成過程意外變成系統變更。
對既有圖片重建，則應保留原始圖作為核對依據。OCR 是辨識圖片文字的技術，辨識錯字或遺漏小標籤，都可能影響結構。生成可編輯版本後，先對照原圖逐項確認節點與連線，再進行後續美化，會比較容易找出差異。
怎麼判斷它真的省時間，而不只是第一張圖很快？
可以選一張團隊平常會維護的圖，先用現有方式完成，再用工具生成並修正到相同標準。記錄從資料準備到最後驗收的時間。只比較生成的十幾秒，沒有計入修正錯誤與補資料，容易高估實際收益。
第二次修改更值得測試。新增一個服務、改一條資料流或替換資料庫，看看工具能否更新正確部分並保留人工版面。如果每次都要重新整理整張圖，第一版生成得快，也未必適合持續維護。
還要測試交接。另一位同事能否打開文件、理解來源並接著改？圖表是否使用團隊熟悉的名稱？來源檔案是否可以追溯？這些問題影響長期使用，不能只用單次演示的漂亮程度決定採用。
常見問題：drawio-skill 適合不會寫程式的人嗎？
可以只用文字生成架構圖嗎？
官方文件包含自然語言路徑，適合描述概念與初步結構。使用者仍需要理解要畫的系統，並檢查生成結果。若目標是正式架構文件，最好補上實際服務與來源資料，而不是把第一次生成的通用圖直接當成真實部署。
它和 Mermaid 有什麼差別？
Mermaid 用文字描述圖表，適合把結構放在文件與程式版本中。drawio-skill 的成果則包含可在圖形介面修改的 .drawio 文件，也提供與 Mermaid 相關的工作路徑。選擇時可以看團隊偏好文字維護，還是需要手動移動節點與調整版面。
AI 產生的圖可以直接交給客戶嗎？
先完成內容與版面驗收會更可靠。尤其是服務邊界、箭頭方向、權限與資料來源，需要熟悉系統的人確認。可編輯格式讓修正容易，卻不會自動保證生成內容正確，展示前的核對仍是必要工作。
結語：讓 AI 圖表從一次展示變成可維護文件
drawio-skill 的吸引力，是把生成圖表與後續修改接在一起。文字、程式碼與設定可以提供結構，可編輯文件讓使用者接著整理，來源與增量更新則為長期維護提供方向。這比只追求一張漂亮圖片，更接近團隊日常使用架構圖的需求。
如果你要試用，可以先挑一張範圍清楚、經常修改的圖，測量生成、修正與第二次更新的總時間。當來源可核對、關係正確、同事也能接手，可編輯 AI 圖表才真正從展示效果走進工作流程。
