Azure Developer CLI (azd) 2026年4月更新

Emiliano Montesdeoca — Fri, 08 May 2026 00:00:00 +0000

本文已自动翻译。要查看原始版本，请点击此处.

Azure Developer CLI (azd) 在 2026 年 4 月发布了五个版本（1.23.14 至 1.24.2），重大主题是钩子现在可在 Python、JavaScript、TypeScript 和 .NET 中运行——而不仅限于 Bash 和 PowerShell。

azure.yaml 中的多语言钩子

除 shell 脚本外，钩子现在可以指向 .py、.js、.ts 或 .cs 文件。每种语言都可自动解析依赖关系：

Python — 检测 requirements.txt 或 pyproject.toml，创建 virtualenv 并在运行前安装依赖。通过 virtualEnvName 配置环境名称。
JavaScript / TypeScript — 检测 package.json 并自动运行 npm install。TypeScript 通过 npx tsx 执行，无需编译步骤。通过 packageManager 配置块选择包管理器。
.NET — 使用 dotnet run 运行 .cs 文件。在 .NET 10+ 上支持单文件脚本。通过 configuration/framework 块配置目标框架。

这意味着已在这些语言之一中工作的团队，不再需要仅为了连接预配生命周期事件而单独维护 Bash 或 PowerShell 钩子。

azd update 进入公开预览

azd update 现已在所有平台上推出公开预览版。单个命令即可处理更新，无论 azd 最初是如何安装的——不再需要单独追踪 Homebrew、WinGet 或 MSI 的路径。

通过 AZD_NON_INTERACTIVE 实现非交互模式

设置 AZD_NON_INTERACTIVE=true（或使用 --non-interactive / --no-prompt）现在会在 CI/CD 管道中产生一致、确定性的失败，当必需的输入无法自动解析时。此前各命令的行为不一致。

AI 模型配额预检查

azd provision 在尝试预配 AI 模型资源之前，会验证 Azure 认知服务配额。因配额限制而失败的部署现在会在流程早期显示错误，而不是在预配进行到一半时才报错。

Copilot 问题排查中的"修复此错误"

azd 的 Copilot 问题排查集成获得了直接应用建议修复的能力——而不仅仅是描述它。当代理识别出可修复的问题时，它可以直接在原地进行更改。

自定义预配提供程序和 Key Vault 密钥解析器

扩展作者现在可以使用 WithProvisioningProvider() 注册替代基础结构后端。另外，azd 在将配置传递给扩展之前会自动解析 @Microsoft.KeyVault(...) 引用，无需在自定义提供程序中手动解析密钥。

模板和监视模式的排除项

两个新的忽略文件对文件处理提供了更精细的控制：

.azdignore — 从模板副本中排除仅供贡献者使用的文件（文档、CI 配置），使最终用户获得干净的项目脚手架。
.azdxignore — 排除在 azd x watch 期间触发重新构建的目录，减少迭代开发过程中的噪音。

保留名称预检查和 docker.network 选项

azd 现在会在预配开始之前，当预测的资源名称包含 Azure 保留词（MICROSOFT、WINDOWS 或 LOGIN 前缀）时发出警告。新的 docker.network 选项将 --network 传递给 docker build，在需要特定 Docker 网络的企业代理环境中非常有用。

安全修复

Windows MSI 包现在包含代码签名验证。另一项修复关闭了可能在扩展命令边界之间暴露值的环境变量泄漏问题。

这是繁忙的一个月——多语言钩子支持尤其消除了不主要使用 Bash 的团队的一个真实摩擦点。有关所有五个版本的完整更改日志，请参阅完整发行说明。

你在Azure上的AI实验正在烧钱——这样解决

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

如果你现在正在Azure上构建AI驱动的应用，你可能已经注意到一件事：你的云账单看起来和以前不一样了。不只是更高了——更奇怪了。波动很大，难以预测。

Microsoft刚刚发布了一篇关于仍然重要的云成本优化原则的优秀文章，说实话，时机再好不过了。因为AI工作负载在成本方面已经改变了游戏规则。

为什么AI工作负载不一样

事情是这样的。传统的.NET工作负载相对可预测。你了解你的App Service层级，了解你的SQL DTU，可以相当准确地估算每月开支。AI工作负载呢？完全不是这么回事。

你在测试多个模型看哪个合适。你在启动GPU支持的基础设施进行微调。你在调用Azure OpenAI的API，而token消耗量会因prompt长度和用户行为的不同而产生巨大差异。每个实验都要花真金白银，你可能需要运行几十次才能找到正确的方法。

这种不可预测性正是成本优化至关重要的原因——不是事后才想到，而是从第一天开始。

管理与优化——了解区别

文章中有一个我认为开发者容易忽视的区别：成本管理和成本优化是不同的。

管理是跟踪和报告。你在Azure Cost Management中设置预算，收到警报，查看仪表板。这是基本功。

优化是你真正做决策的地方。你真的需要S3层级，还是S1就能处理你的负载？那个始终运行的计算实例周末是不是闲着？你能否用竞价实例来跑训练任务？

作为.NET开发者，我们往往专注于代码，把基础设施决策留给"运维团队"。但如果你在Azure上部署，这些决策也是你的决策。

真正有效的方法

根据这篇文章和我自己的经验，以下是真正能产生效果的做法：

了解你在花什么钱、花在哪里。 给你的资源打标签。我是认真的。如果你无法分辨哪个项目或实验在消耗你的预算，你就无法优化任何东西。配合适当标签的Azure Cost Management是你最好的朋友。

实验之前设好护栏。 使用Azure Policy限制dev/test环境中昂贵的SKU。为你的Azure OpenAI部署设置消费上限。不要等到账单到了才发现有人让GPU集群在周末一直运行。

持续进行合理配置。 原型阶段选的那个VM？可能不适合生产环境。Azure Advisor会给你建议——真的去看看。每月审查，而不是每年。

考虑生命周期。 开发资源应该关闭。测试环境不需要7×24小时运行。使用自动关机策略。特别是对于AI工作负载，考虑使用按执行付费的无服务器选项，而不是让计算资源一直保持运行。

衡量价值，而不仅仅是成本。 这一点容易忘记。一个成本更高但能产出显著更好结果的模型可能才是正确的选择。目标不是花最少的钱——而是花得聪明。

总结

云成本优化不是一次性的清理工作。它是一个习惯。随着AI工作负载让开支比以往任何时候都更难预测，尽早养成这个习惯可以帮你避免日后的痛苦惊喜。

如果你是一名在Azure上构建的.NET开发者，开始像对待代码一样对待你的云账单吧——定期审查，混乱时重构，永远不要在不了解成本的情况下部署。

Cloud | The .NET Blog