cloud-solution-architect
作者 microsoftcloud-solution-architect 技能可帮助智能体像 Azure Cloud Solution Architect 一样做出云架构决策。可用于评审设计、选择架构风格、对比 Azure 服务，并结合设计原则、模式和最佳实践来判断，减少通用提示词带来的猜测成本。
该技能评分 78/100，属于目录中值得收录的候选：它提供了清晰聚焦的 Azure 架构工作流，并配有足够的参考深度来减少猜测；不过它更偏向指导型，而不是强任务导向型。对目录用户来说，如果希望获得结构化的云架构辅助，而不是一个薄封装提示词，它值得安装。
- 触发场景明确：说明中直接指出可用于云架构设计、系统设计评审、架构风格选择、设计模式应用以及 Well-Architected 评审。
- 运维参考基础扎实：仓库包含 10 条设计原则、6 种架构风格、44 个设计模式、技术选型框架以及性能反模式等详细参考内容。
- 对智能体的支持力度好：较长的 SKILL.md 加上 7 个参考文件，提供了具体的 Azure Architecture Center 指南，有助于减少泛化提示，支持系统化的架构决策。
- 没有安装命令或脚本：看起来需要手动接入，智能体可能需要直接浏览这些 Markdown 参考文件。
- 文档参考很丰富，但可见内容中的具体执行步骤偏少，因此智能体在端到端评审时仍可能需要自行补充一定解释。
cloud-solution-architect 技能概览
cloud-solution-architect 技能帮助 agent 像 Azure 架构工作的 Cloud Solution Architect 一样思考：选择架构风格、审查设计、比较服务，并对照 Azure 最佳实践检查工作负载。它最适合你需要的是可落地的答案，而不是泛泛的云端提示词时使用。
这个技能适合做什么
当你在设计或审查需要明确权衡的系统时，使用 cloud-solution-architect skill：可靠性、可扩展性、成本、运维适配度，以及技术选型。它尤其适合 Cloud Architecture 决策，因为正确答案取决于工作负载形态，而不是某个固定模板。
它为什么不一样
这个技能以 Azure Architecture Center 的指导为基础，并围绕决策辅助内容组织：设计原则、架构风格、设计模式、技术选择和性能反模式。相比“帮我设计云系统”这类宽泛提示词，它更强的地方在于给 agent 提供了具体、可追溯的参考路径。
最适合哪些读者
它适合架构师、平台工程师、高级开发者和技术负责人，用来把应用想法、迁移方案或评审发现转化为站得住脚的云设计。如果你要的是代码生成，或者一份通用的 DevOps 清单，它就没那么合适。
如何使用 cloud-solution-architect 技能
安装并打开正确的文件
按 cloud-solution-architect install 路径执行：
npx skills add microsoft/skills --skill cloud-solution-architect
然后先阅读 SKILL.md，再看 references/design-principles.md、references/architecture-styles.md、references/technology-choices.md、references/design-patterns.md 和 references/mission-critical.md。这些文件包含真正影响架构工作的决策逻辑。
给这个技能一份真实的工作负载简报
cloud-solution-architect usage 的效果取决于你的输入。不要只说“设计一个可扩展应用”这种模糊请求，而要明确写出：
- 工作负载类型：Web 应用、API、事件驱动系统、数据管道、迁移
- 流量模式：稳定、突发、全球分布、批处理、低延迟敏感
- 状态/数据需求：关系型、NoSQL、缓存、文件、流式处理
- 约束：预算、合规、区域、运维团队规模、现有 Azure 服务
更强的提示词可以这样写：“请审查这个 Azure 设计：一个 B2B SaaS API，要求 99.95% 可用性、多区域读流量、PostgreSQL，以及一个小型运维团队。请推荐最合适的架构风格，并指出风险。”
提升输出质量的推荐工作流
先说明目标结果，再让技能在三种模式里选一种：架构选型、设计审查或技术选型。如果你已经有草案，就让它把方案映射到 Azure 原则，标出反模式，并提出一个更简单的替代方案。如果工作负载是 mission-critical，开头就把 SLO 和恢复目标说清楚。
快速阅读顺序建议
如果你想快速做决定，按这个顺序看：
SKILL.md：了解范围和预期工作流references/architecture-styles.md：判断可能的架构模式references/technology-choices.md：做服务选型references/design-patterns.md：看可靠性和集成方案references/performance-antipatterns.md：当问题出在延迟或吞吐时重点看
cloud-solution-architect 技能常见问题
这只适用于 Azure 特定设计吗？
是的，cloud-solution-architect skill 的核心就是 Azure 架构指导。它也能帮助你梳理通用云权衡，但推荐和参考内容都以 Azure 为原生背景。
它和普通提示词有什么区别？
普通提示词也能问架构问题，但这个技能给 agent 提供了一套结构化的事实依据：设计原则、模式、风格和服务选择参考。通常这意味着更少遗漏权衡点，也更不容易给出脆弱的建议。
适合新手吗？
适合，前提是你的目标是理解架构选项，或者对已有想法做评审。它不能替代云基础知识，但能通过告诉你该比较什么、该避开什么，减少试错成本。
什么时候不该用？
当你需要实现代码、IaC 生成，或者想要的是非 Azure 的架构观点时，不要用它。如果你没法描述工作负载约束，它也不太适合，因为 Cloud Architecture 选择本来就依赖这些条件。
如何改进 cloud-solution-architect 技能
说清楚要做的决策，而不只是话题
最好的 cloud-solution-architect guide 请求会指向一个具体决策：“我该选哪种架构风格？”“这次评审里我应该改什么？”“哪种 Azure 服务最适合这个工作负载？”这样比开放式头脑风暴更容易产出有用结果。
提供会改变答案的约束条件
提升质量最大的地方，来自具体限制：要求的可用性、RPO/RTO、数据驻留、预期请求量、团队规模，以及工作负载是否 mission-critical。没有这些信息，技能很可能只会给出一个合理但泛化的设计。
要求输出权衡和失败模式
如果你想要更好的结果，就让 agent 解释为什么某个方案更优，以及什么情况下它会失效。比如：“比较这个 API 的 App Service、Functions 和 AKS，并指出各自的运维成本和扩展风险。”
从架构选型逐步迭代到评审
一个高效的工作流是：先定架构风格，再选服务，最后检查反模式。如果第一轮答案太宽泛，就把下一轮提示收窄到设计中的某一层。这是提升 cloud-solution-architect usage 的最快方式，而且不会过度堆砌提示词。