archimate

archimate 技能概覽

archimate 是用來做什麼的

archimate 技能可讓你使用 !include <archimate/Archimate> stdlib 和型別化 macro，在 PlantUML 中產生 ArchiMate 圖。當你需要一個 archimate skill 來呈現分層企業架構視圖時，它特別合適：商業、應用、技術、動機，以及實作藍圖。適合用在把粗略的架構輪廓整理成結構化圖表，而不是只想畫一些泛用的方塊與箭頭。

最適合的使用情境

這個技能很適合用來製作企業架構交付物，例如 capability map、application integration 視圖、security architecture，或 migration plan。當讀者需要跨層追蹤性，以及對元素與關係有清楚語意時，它尤其有價值。如果你需要在 TOGAF 風格的各種視圖中使用 archimate for Diagramming，這個技能會比自由發揮的提示詞更有紀律，也更適合作為起點。

不適合使用的情況

除非你的目標明確就是要用 ArchiMate 來表達這些領域，否則不要拿 archimate 來做雲端參考圖、Kubernetes 佈局或網路拓樸圖。專案庫本身也明確把你導離這些情境：基礎設施比重高的雲端圖請用 cloud skill，拓樸圖請用 network skill。這個界線很重要，因為這裡的 macro 是在建模企業架構概念，不是一般性的示意設計。

如何使用 archimate 技能

安裝並找到工作流程

使用 npx skills add markdown-viewer/skills --skill archimate 安裝。安裝完成後，先讀 SKILL.md 了解必須遵守的 PlantUML 結構，再查看 examples/ 裡的範例檔，掌握各層的常見模式。最值得先預覽的檔案有 examples/enterprise-landscape.md、examples/application-integration.md、examples/business-capability.md、examples/data-architecture.md 和 examples/migration-planning.md。

給技能正確的輸入

好的 archimate usage 會從清楚的架構意圖、目標視圖，以及你已經知道的實體開始。弱的需求只會說「幫我畫一張架構圖」。更好的需求會這樣寫：「請為零售業建立一張 ArchiMate business-capability 視圖，呈現 customer engagement、supply chain 與 finance capabilities，並包含 8 到 10 個具名元素及彼此之間的關係。」請把層級、受眾、範圍，以及你是否需要 motivation 或 implementation 元素一起提供。

遵守 PlantUML 合約

這個技能期待的是一份真正的 PlantUML 圖，而不是敘述文字。核心模式是：先寫 @startuml，加入 !include <archimate/Archimate>，用像 Business_Actor(...) 或 Application_Component(...) 這類型別化 macro 宣告元素，再用 Rel_* macro 把它們連起來，最後以 @enduml 結尾。建議用 rectangle "Layer Name" { ... } 讓模型更容易閱讀。如果省略 include，或使用錯誤的 fence，圖就不會按預期渲染。

能提升輸出的提示流程

若想穩定得到高品質的 archimate guide，建議分三步走：先定義架構問題，再列出實體與關係，最後只要求輸出 PlantUML 圖。好的輸入會包含命名慣例、希望的細節層級，以及一定要呈現的關係，例如 serving、realization、access 或 triggering。如果原始素材很雜亂，先請技能把內容整理成一個目標視圖，再擴展到多層。

archimate 技能 FAQ

archimate 比一般提示詞更好嗎？

是，當你需要一致的 ArchiMate 語法，以及可渲染、可編修的圖時尤其如此。一般提示詞可能產出看起來合理的架構敘述，卻漏掉必要的 macro、層級分組或關係型別。當你重視圖表正確性與可重用性時，archimate skill 會更有用。

安裝前我應該先知道什麼？

最主要的前提是，你已經有一個符合 ArchiMate 語意的圖表目標。若你能清楚說出要建模的 actor、applications、capabilities、services 與 technology nodes，這個技能效果最好。如果你目前只有模糊概念也能使用，但若你先提供範圍明確的視圖，而不是一份過大的企業願望清單，第一版輸出通常會更好。

初學者可以用 archimate 嗎？

可以，只要願意學幾個 macro 模式。這個專案庫的實用之處在於範例展示了常見視圖與元素型別，初學者可以照著結構複製，而不必先背完整符號系統。新手最常犯的錯誤，是太早要求整張企業全景圖；應先從一個視圖、一個層級，或一段流程切片開始。

什麼時候該選別的技能？

如果圖表主要是在描述雲端資源、實體網路佈局，或沒有企業架構語意的泛用軟體元件，就應該選其他技能。如果你要的是純視覺草圖，且不在意標準化關係，也不適合用它。當價值在於結構、可追蹤性，以及利害關係人能讀懂的 EA 標記法時，才用 archimate。

如何改進 archimate 技能

先定義視圖，不要只講主題

品質提升最大的關鍵，是明確指定你要哪一種 ArchiMate 視圖。像「銀行的企業架構」這種說法太廣；「遺留帳務系統的 migration-planning 視圖，包含 baseline、兩個 plateau、work package 與 gap」才有可操作性。如果你想讓 archimate 的結果更好，請把 layer set、受眾，以及圖表要支援的決策一起說清楚。

提供完整實體與關係意圖

當你列出重要節點，以及它們如何連結時，這個技能表現會更好。舉例來說，不要只說「顯示登入流程」，而是說「Identity Provider serves Auth Service，Auth Service realizes Access Control，而 Users trigger Login Request。」這樣的結構可以減少亂編關係，也能讓圖更貼近真實架構。

一次只要求一份交付物，再逐步迭代

常見失敗模式是一次要求太多視圖，結果圖面雜亂、關係也變弱。先做一張圖，檢查 macro 選擇是否符合你的架構語言，再針對缺漏的元素、命名或分組提出修訂。對 archimate usage 而言，逐步修正通常比一次塞進超大提示詞更有效。

把範例當成模式庫來用

如果你不確定怎麼描述需求，可以直接對照專案庫範例：business-capability、application-integration、data-architecture、security-architecture、devops-pipeline 和 migration-planning。這些範例會清楚透露哪些 macro 對應哪些關注點，以及專案庫期待的分層分組方式。沿用這種結構，能讓你的提示詞更具體，也讓圖表更忠於原始架構。