GitHub Copilot 代码审查现已面向所有 Azure DevOps 客户开放，并可用于 Azure Repos。这个变化照顾了暂时无法迁移到 GitHub 的团队，但也引入了一套需要单独治理的运行模型：审查按次计费、费用经关联的 Azure 订阅结算、成本数据最多延迟约 48 小时出现，而且每个组织最多只能同时执行五次审查。
这意味着团队不能把它简单理解成一个随时可用、成本实时可见的流水线步骤。接入之前，需要同时设计使用边界、费用监控和高峰期的并发策略。
可用性扩展了，责任边界也变了
很多企业仍在 Azure Repos 中维护核心代码，迁移平台可能受到合规要求、流水线依赖、权限模型或历史工具链的限制。Copilot 代码审查进入 Azure Repos 后，这些团队不必先完成代码托管迁移，便可以在现有 Azure DevOps 工作流中引入 AI 审查。
不过，AI 审查不能代替已有的分支策略和人工审批。更稳妥的定位是：
- 用它提前发现明显缺陷、遗漏的边界条件和可疑改动。
- 保留构建、测试、静态分析和安全扫描等确定性检查。
- 对生产配置、身份权限、账务逻辑等高风险代码继续要求人工批准。
- 将 AI 建议视为审查输入，而不是合并决策本身。
尤其需要注意的是，来源信息只说明了每个组织的并发上限为五次，并未说明超过上限后的排队顺序或等待时间。因此，不应把 AI 审查放在具有严格时限的发布关键路径上，除非团队已经通过实际压测确认其行为。
48 小时成本延迟会影响治理方式
每次审查通过关联的 Azure 订阅计费，但相关记录大约要在 48 小时后才会出现在 Azure Cost Management 中。这种延迟带来两个直接后果。
一方面，当天的成本面板不是实时用量表。周一看到的数字，可能还没有完整包含周末或周一发起的审查。另一方面，预算通知只能在费用进入成本系统并触发阈值后发出，不能阻止开发者继续提交审查请求。
因此，治理最好分成两层：
| 层级 | 解决的问题 | 推荐手段 |
|---|---|---|
| Azure 成本层 | 已经产生了多少费用 | Cost Management、预算阈值、邮件通知、标签和订阅归属 |
| 工程流程层 | 哪些请求可以发起审查 | PR 规则、团队配额、使用约定、内部审批或调用包装器 |
预算适合发现趋势和异常，但不是熔断器。需要硬性上限的组织，必须在 Azure Cost Management 之外建立执行控制，例如限制可使用该能力的项目、约束触发条件，或者通过内部服务记录并批准审查请求。
用 Bicep 建立预算预警
下面是一个可以改造的订阅级预算示例。它不会停止 Copilot 代码审查，只会在月度实际成本达到预算的 80% 和 100% 时发送通知。运行前需要修改预算金额和收件人地址，并确认部署身份有权创建订阅预算。
创建 copilot-review-budget.bicep：
targetScope = 'subscription'
@description('Monthly budget amount in the subscription billing currency')
param budgetAmount int = 500
@description('Email addresses that receive budget notifications')
param contactEmails array = [
'platform-team@example.com'
'finops@example.com'
]
@description('Budget period start, normally the first day of the current month')
param startDate string = utcNow('yyyy-MM-01T00:00:00Z')
resource reviewBudget 'Microsoft.Consumption/budgets@2023-11-01' = {
name: 'copilot-code-review-monthly'
properties: {
category: 'Cost'
amount: budgetAmount
timeGrain: 'Monthly'
timePeriod: {
startDate: startDate
}
notifications: {
Actual80Percent: {
enabled: true
operator: 'GreaterThan'
threshold: 80
thresholdType: 'Actual'
contactEmails: contactEmails
}
Actual100Percent: {
enabled: true
operator: 'GreaterThan'
threshold: 100
thresholdType: 'Actual'
contactEmails: contactEmails
}
}
}
}
使用 Azure CLI 部署：
az login
az account set --subscription '<subscription-id>'
az deployment sub create \
--name copilot-review-budget \
--location eastus \
--template-file copilot-review-budget.bicep \
--parameters budgetAmount=500 \
--parameters contactEmails='["platform-team@example.com","finops@example.com"]'
这里的 500 只是示例，不代表产品价格。应根据组织可接受的月度支出、团队规模和实际单次审查价格重新计算。由于成本数据存在约两天延迟，阈值也要留出缓冲；如果绝对上限是 500，不宜等到 500 才开始通知。
预算还可能覆盖订阅中的其他资源费用。若要单独观察代码审查成本，应先在 Cost Management 中确认该费用暴露出的计量项或筛选维度，再为预算添加对应过滤条件。不要猜测计量名称，否则预算可能监控了错误的成本集合。
五个并发名额应该留给哪些 PR
并发上限在小团队中可能不明显，但在集中式 Azure DevOps 组织里，多个项目会共享同一个组织级容量。大型批量更新、依赖升级和自动生成 PR 可能迅速占满五个并发名额。
可以这样制定触发策略：
- 默认审查面向服务代码、共享库和基础设施配置。
- 文档、自动生成文件、锁文件更新可跳过，或由人工按需触发。
- 大规模依赖升级分批提交，避免同时创建大量审查任务。
- 发布窗口前不要集中补发历史 PR 的 AI 审查。
- 记录请求时间、项目、仓库、PR 编号和发起人，用本地台账弥补成本数据的 48 小时空窗。
如果多个团队共用一个 Azure DevOps 组织，还应明确容量归属。否则，一个仓库的自动化任务可能影响其他仓库的紧急修复。由于现有摘要没有提供可编程的并发查询或取消接口，不应假设可以通过脚本直接读取和管理这五个执行槽位。
上线前检查清单
接入时可以按以下顺序推进：
- 确认负责结算的 Azure 订阅及其成本负责人。
- 先在少量仓库试运行，记录一到两个账单周期的审查数量和费用。
- 设置低于实际支出上限的预算预警，为 48 小时延迟预留空间。
- 明确哪些 PR 自动使用、哪些按需使用、哪些禁止使用。
- 观察五个组织级并发名额在高峰期是否造成等待。
- 保留人工审批、测试和安全扫描，不让 AI 审查成为唯一合并门槛。
Copilot 代码审查进入 Azure Repos，降低了采用门槛，却没有消除运营成本。真正稳妥的落地方式，是把它当作一个按次消费、数据延迟、容量有限的共享服务来管理，而不是一个没有边界的 PR 开关。