前言

這篇文章的對象讀者是這樣的人：

• 讓生成式 AI 幫忙把架構圖或流程圖「清稿」過，但覺得「如果是圖片，之後就沒辦法再修改」的人（就算沒讀過前一篇也沒關係）
• 想把用來說明的圖全部都交給 AI 製作的人
• 想讓 AI 畫 AWS 架構圖，但又在意圖示或版面跑掉的人

這篇文章是上一回的續篇，不過我會寫得讓沒看過前一篇也能懂。先花 30 秒簡單總結一下上一回的內容。

這次的續集是：把清稿的輸出從圖片（Nano Banana）改成 draw.io 之後，前面那些麻煩就整個消失了。前一篇文章雖然放在這裡，但不看也能跟上下文。

前一回做了什麼（摘要）
工程師平常快速畫的結構描述裡，有一種叫 Mermaid 的文字記法。不過 Mermaid 的圖看起來比較樸素，不太適合拿去做給業務方看的簡報。所以前一回是先用 Mermaid 把結構固定下來，再把它丟進 Gemini 的圖片生成（俗稱 Nano Banana），讓 AI 幫忙清成「白底、日文黑體、易讀的資訊圖表」。簡單說就是 結構交給 Mermaid、外觀交給 AI 的分工。

這方法當然也有它方便的地方。不過在自己的工作（ID-POS 分析平台）裡實際用久了之後，只會卡住一件事：「這是圖片，之後沒辦法修改啊。」每次開會被說「這裡加個 WAF」，我都得重新整張丟回去。

用圖片清稿的方式的極限：「已經沒辦法改了」

讓 AI 用圖片方式清稿，實際用起來會浮現一些不起眼的弱點。前一篇文章也列了 3 個踩雷點：官方圖示不夠準、日本語會跑掉、圖一複雜就會被省略元素。回頭看才會發現，根源其實都一樣：因為回傳的是「圖片」。

圖片作為成品很漂亮，但沒有任何可編輯的把手。就算只想把一根箭頭稍微移一下，也得改 prompt 然後整張重新生成。而且這還是抽卡，常常不只你想改的那個箭頭，連其他版面也一起變掉。結果就是「欸，剛剛那張比較好」的情況一直發生。

你是不是也有過在審稿時被說「只改這裡就好」，結果整張圖都得重做的經驗？我自己做過幾次之後，開始覺得「讓 AI 幫忙清稿本身是對的，但輸出格式是圖片，這件事可能才是錯的」。

解法：不是清稿，而是讓 Claude 直接寫「.drawio 的 XML」

想法很單純。前一回是讓 Nano Banana 產生「圖片」。這次改成讓 Claude 直接產生 draw.io 的原始檔（.drawio）本身。

角色分工可以這樣看。

Mermaid 還是跟前一篇一樣，是「固定結構的中介語言」。不同的是清稿的負責人。Nano Banana 回傳的是「把外觀燒成固定結果的圖片」；Claude 回傳的是「可以在 draw.io 開啟與編輯的 XML」。後者不是成品，而是拿得到 可編輯素材，這就是這次的重點。

原理：.drawio 只是 XML，所以很適合 LLM

為什麼 Claude 做得到？答案簡單得有點意外，因為 .drawio 檔案的內容本來就是 XML。

draw.io 的檔案是 mxGraphModel 這種格式的 XML，節點（圖形）和邊（箭頭）都只是用一行一行文字寫出來而已。不是二進位，也不是獨有格式。也就是說，圖的製作其實剛好落在 LLM 最擅長的「文字生成」與「差分編輯」範圍裡。

AWS 圖示也只要指定專用的樣式字串就能顯示。比如 RDS 圖示可以這樣寫。

rds-icon.drawio

<mxCell id="rds" value="RDS (Multi-AZ)"
  style="sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=#2E27AD;
  strokeColor=#ffffff;verticalLabelPosition=bottom;verticalAlign=top;
  align=center;html=1;fontSize=12;aspect=fixed;
  shape=mxgraph.aws4.resourceIcon;resIcon=mxgraph.aws4.rds;"
  vertex="1" parent="1">
  <mxGeometry x="600" y="280" width="48" height="48" as="geometry" />
</mxCell>

shape=mxgraph.aws4.resourceIcon 和 resIcon=mxgraph.aws4.rds 這組合，會呼叫 draw.io 內建的 AWS 官方圖示。fillColor 是服務類別色（資料庫是深藍、運算是橘色）。把這些服務一個個排好，再用箭頭（edge）串起來，就是架構圖。Claude 知道這個模式，所以只要用日文或中文去要求，它就能把這份 XML 寫出來。

strokeColor=#ffffff 對 AWS 圖示來說是必須的。若設成 none，圖示外圍那圈白邊就會消失，看起來會變成實心方塊。這個我一開始沒注意到，還以為是圖示沒出來。

實際試做看看（AWS 三層架構）

紙上談兵不如實作，所以就用標準的三層 Web 應用來測試。先一樣用 Mermaid 把結構寫好，這是 Before。

我把這段 Mermaid 直接貼上去，然後請 Claude 這樣做：

請把這個 Mermaid 轉成 AWS 架構圖，輸出成 draw.io 格式（.drawio 的 XML）。
請使用 AWS 官方圖示，並把 ALB、ECS、RDS 用 VPC 的框包起來。

把回傳的 .drawio 用 draw.io 打開後，就是這樣（After）。

VPC 的框、官方圖示、箭頭方向，全部都已經到可以直接貼進簡報的程度。跟前一篇的 Nano Banana 不一樣，這不是圖片。你可以在 draw.io 畫布上拖曳每個圖示，也可以重新接線。生成出來的 .drawio XML 很長，所以我就先折疊起來。

生成的 aws-3tier.drawio 內容（節錄）aws-3tier.drawio

<mxfile host="app.diagrams.net">
  <diagram name="AWS-3tier">
    <mxGraphModel dx="900" dy="600" pageWidth="850" pageHeight="600">
      <root>
        <mxCell id="0" /><mxCell id="1" parent="0" />
        <!-- VPC 的框 -->
        <mxCell id="vpc" value="VPC"
          style="shape=mxgraph.aws4.group;grIcon=mxgraph.aws4.group_vpc;
          strokeColor=#8C4FFF;fillColor=none;verticalAlign=top;container=1;"
          vertex="1" parent="1">
          <mxGeometry x="140" y="180" width="600" height="320" as="geometry" />
        </mxCell>
        <!-- ALB / ECS / RDS 的圖示，以及把它們串起來的 edge 會接續出現 -->
      </root>
    </mxGraphModel>
  </diagram>
</mxfile>

最大的價值是「可以用對話直接改圖」

這裡是我最想講的重點。圖做好之後，我接著對 Claude 說：

在 CloudFront 和 ALB 中間加一個 WAF。

結果回來的是這樣。

WAF 多加了一個，箭頭也只改了必要的連接。其他圖示的位置完全沒動。這在 Nano Banana 那邊其實很容易卡住。

draw.io 的 XML 可以做差分編輯，所以只要「新增 1 個 WAF 節點，然後把 CloudFront→ALB 的邊改成 CloudFront→WAF→ALB」這種最小修改就好。若是做需要透過審查持續調整的圖，這個差異真的非常大。老實說，這時我才真正理解「不是清稿，而是持有原始碼」到底是什麼意思。

其他例子也一樣可行（Mermaid → draw.io）

只有三層架構可能會讓人懷疑只是巧合，所以我再放兩個風格不同的例子。兩個都是上面那張 Mermaid（Qiita 直接可渲染，作為 Before），下面是讓 Claude 寫 .drawio 後在 draw.io 打開的圖（After）。

例：ID-POS 資料分析平台

這個比較接近我自己的工作。原始資料放到 S3，透過 Glue 做整理，再從 Redshift 和 Athena 做分析，最後用 QuickSight 呈現。

在跟非工程師說明「資料從哪裡來、怎麼加工、最後給誰看」時，這種有圖示的細緻程度最容易傳達。只用 Mermaid 的話，對方多少還是得先有一點背景知識。

例：無伺服器 API

API Gateway → Lambda → DynamoDB，再加上用 Cognito 做驗證的架構。虛線則是用標籤表示「驗證流程」。

像虛線、標籤這種「小小的表現差異」，它也能把 Mermaid 的語法直接理解後，轉成 draw.io 的 edge。走到這一步，我真的會覺得 Mermaid 是「設計」，而 Claude + draw.io 是「製圖」，兩者的角色分工變得非常清楚。

用官方技能會更快

前面講的是「直接叫 Claude 幫你做」的方式，但其實還有更省事的路。2026 年 2 月 23 日，draw.io 官方推出了給 Claude Code 用的技能。

裝上之後，只要用 /drawio 這個指令，給它說明，就能直接產出 .drawio，還可以輸出 PNG、SVG、PDF。更厲害的是，輸出的圖片檔裡還會嵌入原本的 XML（--embed-diagram），所以只要把 PNG 拖回 draw.io，就能再次編輯。「明明是圖片卻還能編輯」這件前一篇最大的痛點，等於在結構上直接解掉了。

這個官方技能是給 Claude Code 用的。不過 Claude Desktop 或 Web 版也可以像這篇前半段那樣，直接要求「請輸出成 .drawio 的 XML」，一樣能拿到相同素材。如果你想要一鍵指令的爽感，就用 Claude Code；如果只是想在手邊快速試試，就直接在聊天裡做就好。

圖片方式的弱點是怎麼消失的

把以前用圖片清稿時會踩的雷，和這次只把輸出格式從圖片改成 XML 之後的變化，整理如下。

過去（用圖片清稿）這次（Claude × draw.io＝XML）因為是圖片，所以之後沒辦法修改因為是文字，所以可以透過對話做差分編輯官方圖示會偏向感覺派圖示mxgraph.aws4 內建的官方圖示可以正確顯示第一代模型容易讓日文亂掉因為是向量標籤，所以不會變成亂碼把整張圖丟給雲端圖片生成會有不安輸出是文字，也比較容易做假資料化與本機完結踩過的雷

雖然方便了，但也出現了新的卡點。把我實際踩過的坑記下來。

第一個是 圖越大，版面越容易亂掉。當節點超過 20 個之後，Claude 很難把所有座標都擺得恰到好處。圖示會重疊，箭頭會斜斜穿過去。我後來的做法是：把「配置」交給它做大方向即可、重點放在「結構正確」，最後的對齊交給 draw.io 的自動版面配置（Arrange → Layout）。

第二個是 圖示名稱寫錯，就只會變成方塊。如果 resIcon=mxgraph.aws4.xxx 裡的 xxx 不是實際存在的名稱，就不會報錯，只會默默顯示成普通方框。新一點的服務最容易發生這種事。懷疑有問題時，直接在 draw.io 的 Shape 搜尋裡確認正確名稱，再貼回去最快。

第三個是，最後 細節外觀還是得靠 draw.io 手動微調。與其逼 AI 去追到字型大小、顏色這種最後 20% 的細節，不如讓 Claude 先完成 80% 的結構，剩下 20% 自己手動修，速度反而最快。

處理對外保密的架構圖時要特別注意。Claude 也是雲端服務，所以像具體主機名稱、IP、帳號 ID 這些資訊，最好先替換成假資料再送出去。不過因為 XML 是文字，你可以清楚看出「哪裡被遮掉」，比起整張丟給圖片生成，更容易確認有沒有漏遮。我還是建議一定要先確認公司的資料處理政策。

總結

• 只要把清稿輸出從「圖片」改成「.drawio 的 XML」，架構圖就會變成「之後還能修改的素材」
• mxgraph.aws4 的官方圖示能正確顯示，所以和 AWS 架構圖很合拍
• 最有價值的是「能用對話只改差分」這件事。越是需要在審查中持續演進的圖，價值越大
• 如果想更快，2026 年 2 月推出的 draw.io 官方 Claude Code 技能（/drawio）會更方便

我原本在前一篇結尾說「下一篇要寫排程執行，自動更新例行簡報」這件事，但寫到這裡突然很想先插入 draw.io 這篇。要給業務方快速看的清稿，用 Nano Banana；要自己持續修改的圖，用 draw.io——現在的做法就是依用途分流。

你們現場的架構圖，修改頻率大概有多高呢？如果是那種「每次都要微調一點」的圖，把清稿流程往 draw.io 靠攏應該會很有感。如果你有更好的提示詞寫法，也歡迎留言告訴我。

參考連結

• draw.io 官方 X：Claude Code 技能發表（2026/2）
• Claude Code Gets Draw.io Skill（ClaudeCode JP）
• 使用官方 Claude Code × draw.io Skill 試畫 AWS 架構圖（DevelopersIO）

原文出處：https://qiita.com/ktdatascience/items/735ebfa8504fc658c812