cloud

雲端 skill 總覽

雲端 skill 的用途

雲端 skill 能幫你產生帶有特定雲端供應商服務圖示的 PlantUML 雲端架構圖，讓輸出看起來像真正的 AWS、Azure、GCP、Alibaba Cloud、IBM Cloud 或 OpenStack 架構，而不是一張泛泛的草圖。當你需要一份 Cloud Architecture 的雲端指南，能清楚呈現真實服務、邊界與流量走向時，它特別好用。

什麼情況最適合用這個 skill

如果你在整理部署文件、提案架構、比較雲端服務，或把一段粗略的系統描述轉成帶官方 stencil 圖示的架構圖，就很適合使用雲端 skill。它非常適合雲端安裝決策、設計審查，以及需要圖示精準度的架構交接情境。

這個 skill 的差異在哪裡

它最大的差異在於支援 stencil 感知的 PlantUML 語法：它期待的是 mxgraph.* 的服務圖示、雲端容器與方向性流程，而不只是方框和箭頭。這讓雲端 skill 比一般的繪圖提示更精準，尤其是當讀者在意圖上是否正確呈現了 VPC、區域、子網、負載平衡器、資料庫與受管服務時。

如何使用雲端 skill

安裝並打開正確的檔案

使用 npx skills add markdown-viewer/skills --skill cloud 安裝雲端 skill。接著先看 SKILL.md 與 examples/ 裡的範例，再開始自己寫圖。這裡沒有 helper scripts 或額外的 rule 資料夾，所以範例就是最好的雲端安裝脈絡與模式參考。

把模糊目標轉成可用的提示詞

給這個 skill 的內容要具體的架構，而不是模糊的結果。好的輸入會寫明供應商、工作負載類型、流量路徑，以及一定要包含的服務。例如：「建立一張 AWS web app 圖，包含 users、CloudFront、ALB、EC2 Auto Scaling、RDS 和 S3；顯示 public 與 private subnets。」這會比「畫我的雲端架構」好得多，因為 skill 才能把每個服務對應到正確的 stencil 與版面。

提升輸出的實務工作流程

先決定供應商與邊界模型：region、VPC、subnet、zone 或 cluster。接著依照流向順序列出服務，從入口點一路寫到運算、儲存或事件。如果你想讓雲端 skill 發揮得更好，也要包含架構是同步、事件驅動、multi-AZ、hybrid 還是 serverless，因為這些選擇會改變容器結構與箭頭畫法。

範例裡要先看什麼

先讀 examples/aws-basic.md、examples/aws-serverless.md、examples/azure-hybrid-network.md、examples/gcp-log-processing.md 和 examples/alibaba-web-app.md。它們示範了最直接的雲端使用方式：供應商命名、巢狀容器、多行標籤、非同步箭頭，以及何時要在不同 zone 或路徑中複製元件。把它們當作模式參考，不要直接照貼成模板。

雲端 skill 常見問題

雲端 skill 只適合畫雲端圖嗎？

是。雲端 skill 是用來畫有供應商 stencil 的雲端架構圖。如果你需要一般軟體建模，請用 uml。如果你需要的是沒有雲端受管服務的網路拓樸，請用 network。這個界線很重要，因為這個 skill 是為雲端服務圖示與部署結構最佳化的，不是為所有類型的圖而設計。

我需要先會 PlantUML 嗎？

不太需要。你可以直接提供一般架構需求，讓 skill 處理 stencil 語法；但如果你知道 @startuml、@enduml、箭頭方向與容器的基本概念，結果通常會更好。雲端 skill 對雲端架構新手很友善，但它不能取代清楚的系統輸入。

這跟一般提示詞有什麼不同？

一般提示詞可以描述架構，但雲端 skill 會加入可安裝的慣例：正確的供應商圖示家族、版面預期，以及雲端特有的分組方式。當你需要一張工程師看得懂、而且跨團隊一致的圖時，這能大幅減少猜測。

什麼情況下不該用雲端 skill？

如果你的圖大多是泛用應用邏輯、純序列行為，或是不含雲端受管服務的網路地圖，就不該用它。當你無法指出供應商或服務組合時，它也不是好選擇，因為結果會變得太抽象，實用性不足。

如何改善雲端 skill

提供更強的架構事實

雲端 skill 最適合在你明確指定供應商、區域數量、網路邊界與服務角色時使用。較好的輸入像是：「AWS、兩個 AZ、public ALB、private app tier、RDS primary/standby、S3 存放資產、NAT gateway 對外連線。」較弱的輸入像是：「現代化、可擴充的 app。」前者能讓 skill 產出具體的雲端指南；後者只會逼它自己補架構。

說清楚這張圖的用途

告訴它這張圖是給 ops、review、onboarding、migration，還是 cloud architecture 文件用的。這會影響圖裡該放多少細節。例如，給主管看的安裝決策頁可能不需要太多內部服務；工程交接則需要子網與資料流細節。

留意常見失敗模式

最常見的失敗模式是 stencil 名稱錯誤、容器階層缺漏，以及明明有供應商圖示卻大量使用泛用方框。另一個常見問題是把雲端範圍和非雲端範圍混在同一張圖裡。如果第一版看起來太發散，就要求更緊的邊界、更少的服務，或是更明確的模式，例如「serverless event flow」或「multi-AZ three-tier app」。

用限制條件迭代，不只是改字眼

如果第一版已經接近目標，就用限制條件來修正：例如「只保留 8 個核心服務」、「用虛線表示非同步流程」、「標示 public 與 private subnets」，或是「只使用 AWS service names」。這類雲端使用指引比單純要求「排版好一點」更有效，因為它會改變 skill 實際編碼的架構本身。