把 Bicep 文件写好、参数配齐、敲下
azd up的那一刻，你敢说你心里没有一丝紧张？反正我有。Azure 的资源变更可不像本地改几行代码那样随便 rollback，一个资源组的意外删除能在凌晨三点把你从床上拽起来。
这个 Skill 做的事很朴素但很关键：在部署真正执行之前，帮你把整条变更链跑一遍。它不止做语法校验，还跑 what-if 分析、检查权限是否够用、最后生成一份结构化的预检报告。说白了，它是在替你把那句“万一”追问到底。
我第一次看到这个 Skill 的流程设计时，觉得它步骤有点多，五个 Step 串下来像是把简单的事搞复杂了。但翻了翻它的错误处理策略才明白，每多一个环节就多一层安全网，而真正有价值的不是“不出错”，是“错了还能继续往下跑”。
读完这篇文章，你会知道怎么在 Azure 部署前用这个 Skill 做一次完整的预检，包括项目类型检测、Bicep 语法校验、what-if 模拟和最终报告解读。不会多讲大道理，全是实操导向。
环境准备
跑这个 Skill 之前，环境得先对上。它同时支持两套工具链：Azure CLI 和 Azure Developer CLI。前者是传统 az deployment 流派，后者是带有项目编排能力的 azd 流派。
前置条件不复杂：Azure CLI 版本 ≥ 2.76.0，因为 --validation-level 参数是 2.76 之后才有的。如果你用的是 azd 项目，还得配上 Azure Developer CLI，版本没有特殊要求但建议保底 1.0+。Bicep CLI 是可选的，它主要负责语法层面的静态校验，缺了不影响主干流程，Skill 会在报告中标注出来。
安装命令就两行：
az --version
azd version
跑完后确认版本号都出来了就行。这里有个很容易踩的坑：azd 的登录状态和 az 是独立的，很多人 az login 过了就以为万事大吉，结果 azd provision --preview 直接报 401。不管走哪条工作流，第一步都先确认自己确实登录了。Skill 在运行时也会检测这个，没登的话它会标在报告里，不会静默 fail。
操作流程
这个 Skill 的工作流分五步，但实际跑起来比五个数字看上去轻得多。核心设计在第二步到第四步之间，每一步的输出都是下一步的输入：
-
语法校验：本地跑 bicep build，不连 Azure -
Preflight 预检：azd provision –preview 或 az deployment what-if -
结果捕获：解析五类资源变更 -
报告生成：Markdown 结构化输出
第一步是项目类型检测，说穿了就是看项目根目录有没有 azure.yaml。有，走 azd 路线；没有，走独立 Bicep 的 az deployment what-if 路线。这一步的巧妙之处在于它是自动判断的，不用你手动告诉它“我用的是 azd”，Skill 自己翻目录。
第二步 Bicep 语法校验，它跑 bicep build --stdout。这一步快且便宜，本地就能做，不用连 Azure，但报出来的语法错误能省你后面不小的麻烦。如果 Bicep CLI 没装，它会跳过这一步把信息放进报告，不影响后续链路。
第三步才是重头戏：preflight validation。azd 项目走 azd provision --preview，独立 Bicep 文件走 az deployment group what-if，Scope 从 Bicep 的 targetScope 声明里自动读。四种 Scope 全部覆盖，命令行参数自动适配：
-
Resource Group（默认） -
Subscription -
Management Group -
Tenant
这里有一个我看了好几遍才意识到的细节：--validation-level Provider 是默认首选，但如果权限不够，它不会直接报错退出，而是自动降级到 ProviderNoRbac 再跑一次。这种 fallback 策略在实际生产中非常实用，CI/CD 管道的 service principal 权限往往不够开完整 Provider 校验，降级后虽然少了 RBAC 维度但至少其他检查还能跑。
第四步解析 what-if 输出，每种变更用一个符号标记：
-
+Create：新资源将被创建 -
-Delete：资源将被删除 -
~Modify：资源属性将变更 -
=NoChange：资源不变 -
*Ignore：因分析限制未覆盖
对 Modify 类型的资源，还会往下深挖具体哪些属性变了。这个输出直接作为报告第五章的核心数据。
最后一步则是生成一份 Markdown 格式的预检报告，固定文件名 preflight-report.md，放在项目根目录，共五个章节：
-
Summary：整体状态、时间戳、目标 Scope -
Tools Executed：命令记录、验证级别 -
Issues：错误和警告，含严重度分级和修复建议 -
What-If Results：资源变更明细表 -
Recommendations：可执行的下一步动作
关键设计
用了几轮之后我发现，这个 Skill 最值得聊的不是功能本身，而是它在一套严格的验证流程里埋下的几个“人性化”设计权衡。
第一个设计是 Continue on Error。很多验证工具遇到第一个错误就 stop，你必须先修掉这个错误才能看到后面还有哪些问题。而 azure-deployment-preflight 的策略恰好相反：Bicep 语法报错了？没关系，记录一下，继续跑 what-if。没想到用户没登录？继续跑，有多少算多少，最后在报告里一次性摊开所有问题。这个策略的价值不在技术层面，在工作流层面：它尊重用户的时间，不让你反复“修一个、重新跑一遍”。
第二个聪明的选择是自动参数文件检测。它会按固定优先级去找 <filename>.bicepparam → .parameters.json → parameters.json → parameters/<env>.json。对多环境项目来说这太实用了，你不用每次手动指定参数文件，Skill 自己从目录结构推断。
但有一个设计让我有点犹豫：报告文件直接写在项目根目录，文件名硬编码为 preflight-report.md。对于有 CI/CD 的项目，这意味着每次运行都会覆盖上次的报告。如果你的 pipeline 是串行的那还好，但如果多个分支在同时跑预检，就得自己做路径隔离。这个点在 FAQ 和文档里没有明确提到，算是当前版本下需要自己多留一个心眼的地方。
整体看下来，这个 Skill 的设计哲学是“宁可多跑几步，不放过一个风险”，而且在降级策略上的把控非常到位，知道在哪个环节可以放水、哪个环节必须较真。
使用场景
这个 Skill 最自然的出场时机是在 azd provision 或 az deployment group create 之前，作为一道人工闸门。但把它放进 CI/CD pipeline 里才真正放大了价值。
典型场景是 PR 阶段的自动校验。你在 infra/main.bicep 里改了几行，PR 一推，pipeline 自动跑这个 Skill 的 preflight 检查，报告作为一个 artifact 挂在 workflow 上。reviewer 点进去就能看到一个清晰的变更清单：哪些资源要新建、哪些要改属性、哪些会被删除。比对着几千行 Bicep diff 瞎猜靠谱一万倍。
另一个是团队协作场景下的权限验证。一个新的 team member 想跑 azd provision 但不确定自己的 SP 权限够不够。先跑这个 Skill，ProviderNoRbac 的降级结果会告诉他差在哪里，不用等到部署到一半被 Azure 返回 403。
它也有明确的边界。如果 Bicep 模板里引用了外部模块或 registry，what-if 阶段需要能访问这些远程资源，纯离线环境下效果会打折。另外，这个 Skill 跑的是“预检”不是“prevent”，它告诉你风险是什么但不替你拦，决策环节仍然在你手里。这一点把它和那种自以为是的 Guardrail 工具区分开了，反而让我觉得更务实。
一个有意思的观察：这个 Skill 的输出和 Azure 官方的 what-if 体验本质上是同一份数据，但 Skill 做了两件事让阅读体验质的提升：结构化分章和自动捕获上下文。前者让你不用在终端里滚屏找 Modify 项，后者补上了权限信息框这类你在裸 what-if 里看不到的东西。
洞察与反思
深度用过几轮之后，我最大的感受不是“这个工具很好用”，而是“为什么 Azure 官方不把这种能力直接做进 CLI 的默认行为里”。
说实话，Skill 做的大部分事情 Azure CLI 本来就能做。az deployment group what-if 是内置命令，bicep build 也是标准操作。真正让价值翻倍的是那层编排逻辑，几个关键动作串联起来就不是 CLI 命令的简单堆叠了：
-
自动检测项目类型 -
自动选择参数文件 -
Fallback 降级策略 -
结构化报告输出
这些拼在一起，让原本零散的命令行操作变成了一个可复用的流程资产。
跟同类方案对比，这个 Skill 的差异化不在于技术深度，在于“给问题排优先级”的方式。大部分预检工具要么事无巨细全报出来，要么一刀切只在校验失败时抛异常。azure-deployment-preflight 走的是中间态：把所有问题分类、标严重度、给修复建议，然后在报告核心位置展示资源变更的净影响。这种做法让运维团队和管理层能看同一份报告各取所需，操作人员看 Issue 章节，项目经理看 Summary 和 Resources 变更表。
不过它有一个挺明显的局限：它偏向于“验语法 + 验权限 + 验变更”，但不涉及基础架构的最佳实践校验。它不会告诉你某个 NSG 规则是否过于宽松，也不会检测到你的 App Service 是否漏了 private endpoint。这些是下一层的事情了，不在当前 Skill 的射程范围内。
如果你已经在用 Bicep 做 IaC 并且部署频次不低，这个 Skill 值得放进日常 workflow。如果你还在 ARM 模板阶段，它是个不错的迁移理由：Bicep 的 what-if 比 ARM 的 what-if 更快且输出更清晰，而这个 Skill 恰好建立在那个能力之上。
资源地址
| 资源 | 链接 |
|---|---|
| Smithery Skill 页面 | https://smithery.ai/skills/github/azure-deployment-preflight |
| Azure CLI 文档 | https://learn.microsoft.com/azure/developer/azure-developer-cli/ |
| Bicep 官方文档 | https://learn.microsoft.com/azure/azure-resource-manager/bicep/ |
总结
azure-deployment-preflight 本质上是在做一件事：把部署前的那句“万一”变成有据可查的风险清单。它不追求技术上的标新立异，而是在 Bicep 部署的标准流程上叠了一层自动化编排，让校验、模拟、报告三个环节无缝串在一起。
如果你只打算记住一句话：部署前先跑一遍 Skill，把报告从头到尾过一眼，比你部署到一半才发现权限不够要省至少半小时。
下一步可以做的尝试：把这个 Skill 接进 GitHub Actions 的 PR 校验流程，让每一次 IaC 变更都在 merge 前留下一条 what-if 记录。这比任何 code review checklist 都更能防住那种“我以为改的是小配置，没想到删了整条 VNet”的惨案。