文件交接：azure技能流水线的编排拆解

概述

本期是 Skills 生态系列第 5 轮，方向是工作流自动化。azure-deploy 本体在早前的横评里已经逐段拆过，部署后的监控与 CI 自愈也做过专题，本期换一个更本质的问题：当“部署 Azure”这件事被拆成多个 Skill，它们之间靠什么协作？ 答案是一个磁盘文件。微软 azure-skills 家族（skills.sh 榜单显示累计 720 万安装）用 azure-prepare → azure-validate → azure-deploy 三个 Skill 加一份 .azure/deployment-plan.md，组成了一条带门禁的部署流水线。这种“文件交接式编排”是目前 Skill 生态里最接近传统 CI/CD 工程实践的写法。本文拆解它的交接协议与防绕过设计，并首拆家族里最容易被忽略的 azure-cost，最后对比“流水线型”与“单兵型”部署 Skill 的路线分歧。

一、家族地图：25 个具名 Skill，四条产品线

先看体量。skills.sh 全时段榜上，microsoft/azure-skills 仓库的 Skills 总安装量达 720 万，仅次于飞书的 1510 万（15.1M），单榜可见的成员包括：microsoft-foundry（56.05 万）、azure-diagnostics（55.38 万）、azure-messaging（54.09 万）、azure-compute（49.49 万）、azure-rbac（48.66 万）、azure-cloud-migrate（48.49 万）——榜单第 43 名附近标注“还有 12 个来自该仓库”。

仓库 README 把 25 个具名 Skill 分成四条产品线：

mindmap
  root((azure-skills 720万安装))
    构建与部署
      azure-prepare
      azure-validate
      azure-deploy
      azure-upgrade
      azure-kubernetes
      azure-enterprise-infra-planner
    排障与治理
      azure-diagnostics
      appinsights-instrumentation
      azure-compliance
      azure-resource-lookup
      azure-quotas
    架构与成本
      azure-cost
      azure-compute
      azure-resource-visualizer
      azure-cloud-migrate
    数据 AI 与身份
      azure-ai
      azure-storage
      azure-kusto
      azure-messaging
      azure-rbac
      entra-app-registration
      microsoft-foundry

README 里有一句定位值得所有 Skill 作者抄下来：“Azure 工作不只是代码问题，而是决策问题——哪个服务适合这个应用、部署前要验证什么、哪些工具该跑、哪些护栏重要。”这句话解释了为什么这个家族不是提示词包（prompt pack），而是“Skills 教方法 + MCP 工具管执行”的两层结构：Azure MCP Server 提供 200+ 结构化工具覆盖 40+ 服务，Foundry MCP 负责模型类场景。

二、评测对比表

* azure-validate 的 SKILL.md 原文本轮未能抓取，其评分依据 prepare 与 deploy 两份文档中的交叉引用还原，仅供参考。上手难度按“星越高越容易上手”计：家族全系要求 Node.js 18+、az login，部署场景还要求 azd auth login，对新手有固定门槛。

三、流水线核心：一份文件的三种状态

传统的多 Skill 协作靠 description 里的触发词互相导流，出了错无从追责。azure 家族的方案是让状态落在磁盘上：.azure/deployment-plan.md 就是流水线的唯一契约。

azure-deploy 的 SKILL.md 开头有一段措辞极其严厉的门禁：

⛔ STOP — PREREQUISITE CHECK REQUIRED。执行前必须同时满足：1. azure-prepare 已完成，.azure/deployment-plan.md 存在；2. azure-validate 已通过，计划状态为 Validated。任一缺失，立即停止。

更有意思的是防“作弊”条款。模型最常见的行为是偷懒——自己把状态改成 Validated 蒙混过关。SKILL.md 用大写 FORBIDDEN 明文封死：

你被禁止自行把计划状态改为 Validated。只有 azure-validate 在跑完真实校验后才有权设置该状态。如果你不跑校验就改状态，部署会失败。

azure-deploy 还要求检查计划的第 7 节“Validation Proof”：里面必须有实际执行过的校验命令和时间戳，如果这一节是空的，就说明校验被跳过了，必须退回。这相当于给“状态”配了证据链——不只看结果字段，还要看产生结果的痕迹。

整条流水线的状态机如下：

flowchart TD
    A[用户：部署到 Azure] --> B{azure-prepare Step 0 专项路由}
    B -->|命中专项| S[python-appservice-deploy / azure-cloud-migrate / azure-aigateway]
    S --> C
    B -->|常规路径| C[第一动作：写出 .azure/deployment-plan.md 骨架]
    C --> D[Phase 1 分析/扫描/选型/架构]
    D --> E[用户批准计划]
    E --> F[Phase 2 生成 infra + 安全加固 + 本地验证]
    F --> G[状态改为 Ready for Validation]
    G --> H[azure-validate 实测校验]
    H --> I[状态改为 Validated + 写入 Validation Proof]
    I --> J{azure-deploy 门禁检查}
    J -->|Proof 为空| H
    J -->|通过| K[azd up / azd deploy / terraform apply]
    K --> L[部署后验证 + RBAC 实查 + 输出 https:// 完整链接]

配套的是严格的职责切割。azure-prepare 写明 “Scope: preparation only——部署执行由 azure-deploy 负责”，azure-deploy 则写明 “Scope: deployment execution only”。两个 Skill 互不越界，连 azd up 这类命令都指定只能走 deploy 侧的错误恢复管线。这种“单个 Skill 只拥有一个阶段”的切法，是多 Skill 编排里最干净的范式。

四、azure-prepare 的 Step 0：Skill 内部的二次路由

拿到 azure-prepare 全文（v1.3.2）后，最值得学的是它在 Phase 1 之前插了一个 Step 0：专项技术检查。在进入常规规划前，先拿用户 prompt 的关键词和仓库代码做匹配，命中就先把活儿转给更专的 Skill：

它还特别提醒：“要检查用户的 prompt 文本，而不只是现有代码——对没有代码可扫描的绿地项目这是关键。”这是非常实战的经验：很多 Skill 只会读仓库，忘了用户嘴上说的需求也是路由信号。

azure-prepare 的 Rules 里还有两条“防灾难”条款值得点名：其一，⛔ 绝不删除用户的项目或工作区目录，改造现有项目时只许改文件；其二，⛔ SQL Server 的 Bicep 永远不许生成 administratorLogin 和 administratorLoginPassword，无条件使用 Entra-only 认证。后者直接把一类安全漏配从模板源头消灭了——用规则固化安全基线，比在 description 里写一句“注意安全”高明得多。

五、首拆 azure-cost：轻路由式 FinOps

azure-cost（v1.3.1，skills.sh 榜上未单列，属“+12 more”之列）是家族里另一极。它没有门禁、没有 STOP 段、没有大写禁令，整个 SKILL.md 短小清爽，核心是一张按意图路由的表：

它的 description 是标准的“ WHEN / DO NOT USE ”双清单写法： WHEN 里塞满 “Azure bill”、“cost spike”、“reduce storage costs”、“AKS cost” 等口语触发词， DO NOT USE FOR 里明确排除 deploying、provisioning、diagnostics、security audits——防止和兄弟 Skill 抢活。

技术底座部分给了速查表：Cost Management 的 query / forecast API（api-version 2023-11-01）、所需角色（Cost Management Reader + Monitoring Reader + Reader）、四种 scope 写法（订阅 / 资源组 / 管理组 / 计费账户），再加 Redis、Storage 两个服务的专项优化文档。典型的“路由表 + API 速查 + 专项深潜”三层结构。

把它和 azure-deploy 放在一起看，能得出一个对写 Skill 很有用结论：SKILL.md 的形态应该跟着操作风险走。deploy 侧是写操作，会真金白银地开出资源，所以用三重门禁加证据链；cost 侧是纯读操作，读错了顶多答错数，所以用轻路由把上下文占用量压到最低。很多新手给只读 Skill 也堆满 STOP 门禁，或者给写操作只写一句“小心点”，都是没想清楚这一层。

六、runbook 型选手：azure-diagnostics 的路由表（简）

azure-diagnostics（55.38 万安装，v1.2.6）的排障能力在今天另一篇调试横评里已经覆盖，这里只补一个结构视角。它是典型的 runbook 型 SKILL.md：五步诊断流（症状 → 资源健康 → 日志 → 指标 → 近期变更）打底，然后用一张“服务 × 常见问题 × 参考文档”的路由表把 AKS、VM 连通性、消息队列（Event Huts/Service Bus 的 AMQP 错误、message lock 丢失）分流到各自的深潜文档。它的 description 用了 30 多个关键词平铺（“app service high CPU”、“pod pending”、“crashloop”、“KQL”……），和 azure-cost 的短语式触发词形成两种流派——前者赌关键词命中率，后者赌语义匹配。runbook 型适合故障场景，因为排障时用户描述往往和文档术语高度重合。

七、路线分歧：流水线型 vs 单兵型

本机环境里还装着另一类部署 Skill：vercel-deploy、netlify-deploy、cloudflare-deploy、render-deploy（名单来自本会话的可用 Skill 清单，内部实现本轮未展开）。它们代表另一条路线：一个 Skill 扛一个平台，没有三段式交接，也没有计划文件。

两条路线的适用边界其实很清楚：

• 单兵型适合 PaaS：平台能力强、约定俗成，git push 级别的部署没有多少“决策”可做，一个 Skill 一步到位反而摩擦最小；
• 流水线型适合云基础设施：Azure 上有选服务、选 IaC（Bicep/Terraform）、RBAC、成本、合规一堆决策点，把 prepare/validate/deploy 拆开，每一段的失败都能定位、每一段的状态都可审计。

flowchart LR
    subgraph 单兵型
    A1[vercel-deploy] --> R1((一个平台<br>一步到位))
    A2[netlify-deploy] --> R1
    end
    subgraph 流水线型
    B1[azure-prepare] -->|计划文件| B2[azure-validate]
    B2 -->|Validated + Proof| B3[azure-deploy]
    B3 --> R2((云基础设施<br>分段可审计))
    end

八、安装与验证

Claude Code 下一条命令装全家族（含 MCP 配置）：

/plugin install azure@claude-plugins-official
# 更新
/plugin update azure@claude-plugins-official

其他主机：Copilot CLI 用 /plugin marketplace add microsoft/azure-skills 后 /plugin install azure@azure-skills；跨主机一次装可用 APM：apm install microsoft/azure-skills；通用 skills CLI：npx skills add https://github.com/microsoft/azure-skills/tree/main/.github/plugins/azure-skills/skills -a github-copilot -g -y（README 原文，参数 -a 指定 host、-g 全局）。

前置条件：Azure 订阅、Node.js 18+、az login，走 azd 部署再加 azd auth login。README 给的三个验证提问很实用，装完依次问：“这个项目部署到 Azure 需要哪些服务？”（应得到结构化决策而非泛泛云建议）、“列出我的资源组”（应触发真实 MCP 工具调用）、“Foundry 里有哪些模型？”——三问分别验 Skills 层、Azure MCP 层、Foundry MCP 层。另有 sovereign cloud 支持（中国云 / 美国政府云需给 MCP server 加 --cloud 参数），不想贡献遥测可 export AZURE_MCP_COLLECT_TELEMETRY=false。

需要说明的是：仓库 README 的技能清单中未见 github-actions-skill，本会话环境虽有同名 Skill 在列，但其原文两次抓取均失败，本轮不做评价，留待后续 CI 专题验证。

九、推荐排行榜

• 想学“多 Skill 协作”怎么写：azure-prepare 无出其右——文件契约、状态机、Step 0 二次路由、防灾难规则，一篇顶一门课。
• 想要开箱即用的排障：azure-diagnostics，runbook 结构 + AppLens MCP，55 万安装不是白来的。
• 只想做只读治理（FinOps）：azure-cost，轻、准、无副作用，适合先拿它试水这个家族。
• 保守派：等 azure-validate 原文核验后再上流水线全家桶；若只是部署静态站或 Serverless 小应用，单兵型 Skill 更省事。

一句话总结：单 Skill 拼的是 description 写得好不好，Skill 家族拼的是交接协议设计得严不严。azure 家族用一份 deployment-plan.md 证明了：Skill 生态的下一步竞争，在 Skill 与 Skill 的接口上。

参考来源

1. skills.sh Skills Leaderboard — azure 家族 7.2M 总安装、各成员安装数、飞书 15.1M 等榜单数据
2. microsoft/azure-skills README — 家族四条产品线、MCP 双服务器结构、各主机安装命令、前置条件与验证提问
3. azure-prepare SKILL.md — 计划先行工作流、Step 0 路由表、Rules 全文（v1.3.2）
4. azure-deploy SKILL.md — 门禁条款、Validation Proof 检查、十步执行表（v1.2.1）
5. azure-cost SKILL.md / azure-diagnostics SKILL.md — 轻路由与 runbook 两类结构原文

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。