cloud

云技能概览

云技能能做什么

云技能可以帮你生成带有各云厂商专属服务图标的 PlantUML 云架构图，让输出看起来更像真实的 AWS、Azure、GCP、Alibaba Cloud、IBM Cloud 或 OpenStack 架构，而不是一张泛泛的草图。它最适合用在需要展示 Cloud Architecture 的云指南场景中，尤其是要呈现真实服务、边界和流量走向的时候。

什么时候适合用这个技能

如果你在记录部署、提议架构、对比云服务，或者把粗略的系统描述转成带官方 stencil 图标的图，云技能就很合适。它非常适合云安装决策、设计评审和架构交接这类对图标准确性要求很高的场景。

它的不同之处

它最核心的差异在于对 stencil 语法的感知：它预期的是 mxgraph.* 服务图标、云容器和有方向的流向，而不只是方框和箭头。相比普通的画图提示词，这让云技能更精确，尤其适合读者很在意图里是否正确呈现了 VPC、Region、Subnet、负载均衡器、数据库和托管服务的情况。

如何使用 cloud skill

安装并打开正确的文件

先用 npx skills add markdown-viewer/skills --skill cloud 安装 cloud skill。然后在自己写图之前，先看 SKILL.md 和 examples/ 里的示例。这里没有辅助脚本，也没有额外的规则目录，所以这些示例才是了解云安装上下文和模式匹配的最佳来源。

把模糊目标转成可用提示

给技能输入具体架构，而不是笼统结果。高质量输入会明确说明云厂商、工作负载类型、流量路径和必须包含的服务。比如：“创建一个 AWS Web App 架构图，包含用户、CloudFront、ALB、EC2 Auto Scaling、RDS 和 S3；展示公有和私有子网。”这比“帮我画云架构”要好得多，因为技能可以把每个服务映射到正确的 stencil 和布局。

提升输出质量的实用工作流

先确定云厂商和边界模型：Region、VPC、Subnet、AZ 还是 cluster。然后按流向顺序列出服务，从入口到计算，再到存储或事件。如果你想更充分地发挥 cloud skill 的作用，一定要说明架构是同步、事件驱动、多 AZ、混合云还是无服务器，因为这些选择会改变容器结构和箭头走向。

先看示例里该注意什么

优先阅读 examples/aws-basic.md、examples/aws-serverless.md、examples/azure-hybrid-network.md、examples/gcp-log-processing.md 和 examples/alibaba-web-app.md。它们展示了最直接的 cloud 使用路径：厂商命名、嵌套容器、多行标签、异步箭头，以及什么时候要按可用区或路径重复组件。把它们当作模式参考，不要原样复制成模板。

cloud skill 常见问题

cloud skill 只适合画云图吗？

是的。cloud skill 专门用于带厂商 stencil 的云架构图。如果你需要通用软件建模，请用 uml。如果你需要不包含云服务的网络拓扑，请用 network。这个边界很重要，因为这个技能是围绕云服务图标和部署结构优化的，不是为了覆盖所有类型的图。

我需要先会 PlantUML 吗？

不需要太多。你可以直接从简单的架构需求开始，让技能处理 stencil 语法；不过如果你了解一些 @startuml、@enduml、箭头方向和容器的基础知识，效果会更好。cloud skill 对云架构新手比较友好，但它不能代替清晰的系统输入。

它和普通提示词相比有什么区别？

普通提示词也能描述架构，但 cloud skill 额外提供了可安装的约定：正确的厂商图标族、布局预期，以及云场景特有的分组方式。这样在你需要一张工程师能读懂、且团队之间风格一致的图时，就能减少试错。

什么时候不该用 cloud skill？

如果你的图主要是通用应用逻辑、纯顺序行为，或者只是没有云托管服务的网络图，就不要用它。若你连云厂商或服务集合都说不出来，它也不合适，因为结果会过于抽象，难以真正派上用场。

如何改进 cloud skill

给模型更明确的架构事实

当你明确指定云厂商、Region 数量、网络边界和服务职责时，cloud skill 的效果最好。更好的输入是：“AWS，两个 AZ，公有 ALB，私有应用层，RDS 主备，S3 存放静态资源，NAT Gateway 负责出站。”较弱的输入是：“现代、可扩展的应用。”前者能让技能产出具体的云指南；后者只会迫使它自己去补结构。

先说明这张图的用途

告诉它这张图是给运维、评审、入职培训、迁移，还是 cloud architecture 文档用的。这会直接影响图里该保留多少细节。比如面向管理层的安装决策页可能只需要少量内部服务，而工程交接则需要子网和数据流细节。

注意常见失败模式

最常见的问题是 stencil 名称错误、容器层级缺失，以及本来有厂商图标却还大量使用通用方框。另一个常见问题是把云范围和非云范围混在同一张图里。如果第一次输出显得太宽泛，就要求更明确的边界、更少的服务，或者指定某种模式，比如“serverless 事件流”或“multi-AZ 三层应用”。

用约束迭代，而不只是改措辞

如果第一次结果已经接近目标，可以通过增加约束来继续优化：比如“只保留 8 个核心服务”、“用虚线表示异步流”、“标出公有/私有子网”，或者“只使用 AWS 服务名称”。这类 cloud 使用指导比单纯说“格式更好一点”更有效，因为它会改变技能实际编码的底层架构。