GitHub Copilot 代码审查进入 Azure Repos：按次计费、账单延迟与成本治理

Microsoft 已向所有 Azure DevOps 客户开放 GitHub Copilot code review for Azure Repos。这项变化很现实：不少团队短期内不会迁移到 GitHub，但仍希望在现有 Azure Repos 拉取请求流程中引入 AI 审查。

真正需要工程团队关注的，不只是功能是否可用，而是它的计费和容量模型：审查通过关联的 Azure 订阅按次收费，费用大约延迟 48 小时才出现在 Cost Management 中；预算只能发送通知，不能自动阻止后续审查；每个组织最多同时运行五个审查。

按次计费改变了成本模型

传统静态分析通常按代理、用户或构建时长计费，Copilot code review 则把一次审查变成一个可计量事件。拉取请求数量、重复请求审查的频率，以及自动化触发策略，都会直接影响账单。

因此，不能只用“开发者人数 × 单价”估算成本。更合理的模型是：

月度审查成本 ≈ 每月拉取请求数 × 每个拉取请求的平均审查次数 × 单次审查价格

其中最容易失控的是“平均审查次数”。如果开发者每次推送小改动都重新请求审查，一个拉取请求可能产生多次计费事件。正式启用前，应根据实际计费条款确认哪些操作构成一次收费审查，并用历史 PR 数据估算高、中、低三档用量。

48 小时延迟意味着预算不是熔断器

费用约两天后才进入 Azure Cost Management，这意味着团队看到告警时，新的审查可能已经继续发生。Azure 预算负责通知，不负责停止服务，所以不能把预算阈值当作实时消费上限。

可以这样实践：在关联订阅上创建月度预算，同时发送预测达到 80% 和实际达到 100% 的通知。下面的 Bicep 文件监控整个订阅的成本，而不是只监控 Copilot；如需精确过滤，应先在 Cost Management 中确认 Copilot code review 对应的服务或计量维度，再增加过滤条件。

运行前修改邮箱、金额和日期：

// budget.bicep
targetScope = 'subscription'

param budgetAmount int = 500
param contactEmail string
param startDate string
param endDate string

resource reviewBudget 'Microsoft.Consumption/budgets@2023-11-01' = {
  name: 'copilot-review-watch'
  properties: {
    category: 'Cost'
    amount: budgetAmount
    timeGrain: 'Monthly'
    timePeriod: {
      startDate: startDate
      endDate: endDate
    }
    notifications: {
      Forecast80: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 80
        thresholdType: 'Forecasted'
        contactEmails: [contactEmail]
      }
      Actual100: {
        enabled: true
        operator: 'GreaterThan'
        threshold: 100
        thresholdType: 'Actual'
        contactEmails: [contactEmail]
      }
    }
  }
}

使用 Azure CLI 部署到 Copilot 计费所关联的订阅：

az login
az account set --subscription '<SUBSCRIPTION_ID>'

az deployment sub create \
  --location eastus \
  --name copilot-review-budget \
  --template-file budget.bicep \
  --parameters \
    budgetAmount=500 \
    contactEmail='platform-team@example.com' \
    startDate='2026-03-01' \
    endDate='2027-03-01'

这个预算只能提供滞后的成本信号。要实现真正的硬限制，还需要在组织流程中控制谁可以请求审查、哪些仓库默认启用，以及达到内部额度后如何暂停使用。

五个并发槽位也是容量约束

每个组织最多同时执行五个审查。小团队通常感觉不到限制，但拥有大量仓库、集中合并窗口或批量自动化流程的组织可能遇到排队。

不要把这五个槽位理解为可用性承诺。它更像组织级共享资源，需要避免所有仓库在相同时间集中提交请求。可以优先覆盖高风险变更，例如身份认证、支付、基础设施和公共 API；文档更新、生成文件和低风险依赖升级则可继续依赖常规检查或人工抽查。

同时要保留原有质量门禁。AI 审查不能替代编译、测试、静态分析、安全扫描和必要的人工批准。尤其对于权限、合规和生产基础设施变更，Copilot 的反馈应作为补充意见，而不是最终决策。

上线前的控制清单

建议先在少量仓库运行一个完整账单周期，再扩大范围：

• 确认 Azure 订阅归属、预算负责人和告警接收人。
• 记录每周 PR 数量及每个 PR 的平均审查次数。
• 为 48 小时成本延迟预留缓冲，不把预算告警视为实时止损。
• 明确达到内部额度后的人工暂停或审批流程。
• 观察高峰期是否触及五个并发审查限制。
• 保留测试、扫描、分支策略和人工审批等现有门禁。
• 定期抽查 AI 建议的有效性，避免为低价值、重复性审查持续付费。

Azure Repos 获得 Copilot code review，降低了采用 AI 审查的迁移门槛，但也把成本治理带进了拉取请求流程。稳妥的做法是把它当作一种按调用消耗、数据延迟可见、容量有限的共享服务，而不是一个开启后无需管理的仓库功能。