乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > AI测试日报8.3|带你了解最新的AI测试方向

AI测试日报8.3|带你了解最新的AI测试方向

当前时间： 2026-08-14 06:38:06 分类：办公文件 评论(0)
AI测试日报8.3|带你了解最新的AI测试方向

日期：2026-08-03范围：Copilot Billing Preview app 退役、enterprise teams model policy、默认模型启用策略、Gemini 模型退役、Grok 4.5、Copilot app 指标扩展、remote control 受管设备、模型治理日历、计费与指标迁移回归

摘要

今天的核心判断是：AI 平台治理进入密集切换期后，测试团队要建立“治理日历回归”。GitHub 在 2026-07-07 公告 Copilot Billing Preview app 将于 2026-08-03 退役，原因是内置 billing settings 已经覆盖更完整的 AI credit、user-level budgets、cost centers、usage pools、usage reports 和 billing API 能力；这意味着依赖旧 app 的运营流程、截图式日报、导出脚本和财务对账都要迁移。
同时，2026-07-31 的 enterprise teams model policy targeting public preview 把模型治理从 organization/resource 级别推进到 user/team 级别。企业可设置模型为 Enabled、Disabled 或 Optional；Optional 模型可分配给 enterprise teams；团队授权采用 least-restrictive strategy，也就是用户只要从任一 enterprise team 获得模型，就能在整个企业范围内访问该模型。启用 enterprise teams mode 后，organization-level model settings 不再适用；预览期间可回滚；多数企业客户预计在 2026-08-03 获得 opt-in。
另一个更远但更危险的切换点是 2026-08-26。GitHub 2026-07-29 公告称，Copilot Business 和 Enterprise 将引入 GA 模型默认启用策略：发布模型默认可用，管理员可以在生效前 28 天配置该策略。8 月 26 日后，未显式配置的模型会变成 inherits default；如果默认策略 enabled，它们会向用户开放；如果 disabled，则保持关闭。显式 enabled/disabled 的模型不被覆盖；open-weight 模型和不在 GitHub data retention agreement 覆盖内的模型不参与默认启用。
把这些放在一起看，今天的测试重点不是单个功能，而是“切换组合”：计费入口退役是否影响对账？模型字段更名是否影响 usage dashboard？团队级授权是否让某些用户意外拿到更强模型？默认模型启用是否在 8 月 26 日突然扩大模型可用面？Gemini 2.5 Pro 和 Gemini 3 Flash 7 月 31 日退役后，脚本和 Agent 是否已经切到 Gemini 3.1 Pro Preview 或 Gemini 3.6 Flash？Grok 4.5 作为新 reasoning model 上线后，默认 policy off 是否被正确尊重？这些问题都很“无聊”，但平台事故常常就是这些无聊小齿轮咬歪了。

今日重点

1. Copilot Billing Preview app 今日退役：计费验证不能依赖旧入口

GitHub 7 月 7 日公告明确，Copilot Billing Preview app 于 2026-08-03 退役。官方建议改用 billing settings 中的 AI usage page、budgets、user-level budgets、cost centers、usage pools、usage reports 和 billing API。该 app 原本帮助用户理解 Copilot 转向 usage-based billing 时的账单，但内置体验已经覆盖 app 底层报表无法展示的更多细节。
测试团队今天要做的不是“打开旧 app 看看还在不在”，而是验证依赖它的流程是否迁完：
财务日报是否仍截图旧 app；
自动导出是否仍调用旧 app 的私有接口或页面；
成本中心对账是否改到 billing API；
user-level budgets 是否能替代旧报表里的个人维度；
AI usage page 的 group/filter/export 是否覆盖旧口径；
使用池 allocation 是否能追溯；
旧 app 退役后错误是否可理解，而不是误报权限或网络故障；
退役当天是否有监控告警检测到残留访问。
AI 测试已经不只是功能测试，也包括运营工具链测试。一个 billing app 退役，如果影响月度对账、成本归属和团队预算，就会变成管理事故。尤其是 AI credit、模型 list price、BYOK/custom endpoint、Grok 4.5 这类 provider-priced 模型叠在一起时，账单口径就是质量口径的一部分。

2. Enterprise teams model policy：least-restrictive 策略要单独做权限测试

Enterprise teams model policy targeting 的关键变化，是模型访问从 organization-level settings 转向 enterprise/team/user 维度。企业级模型状态包括 Enabled、Disabled、Optional；Optional 可授予 enterprise teams；用户只要从任一 enterprise team 获得模型访问，就能在企业范围内访问该模型。启用 enterprise teams mode 后，组织级模型设置不再适用。
这给测试团队带来几个很具体的用例。
第一，团队交集用例。一个用户属于 Team A 和 Team B：Team A 授权 Grok 4.5，Team B 不授权。least-restrictive 语义下，该用户应获得 Grok 4.5 访问。测试要确认 UI、API、model picker、Copilot app、IDE、CLI、cloud agent 是否一致。
第二，组织级策略失效用例。启用 enterprise teams mode 后，旧 organization-level model settings 不再适用。测试要验证迁移前后用户模型可用性差异，并明确哪些差异是预期，哪些是回归。
第三，回滚用例。预览期间可回滚到 previous configuration。测试要验证回滚后模型状态、团队授权、explicit model settings、审计日志和用户可见性是否恢复。
第四，多企业许可证用例。GitHub 公告说明，如果企业不使用 Enterprise Managed Users，成员可能从其他企业获得 Copilot license；enterprise teams mode 下，如果用户使用本企业分配的 Copilot license，则只应用本企业模型策略，其他企业限制不适用。这类边界很容易在咨询、外包、多组织成员场景中踩坑。
建议把模型权限测试从“这个 org 能不能用某模型”升级为“这个用户在这个企业 license、这个 team membership、这个客户端、这个任务入口下能不能用某模型”。听起来麻烦，但这正是 user-based governance 的真实复杂度。

3. 默认模型启用策略：8 月 26 日前必须跑一次“未来日期演练”

Default model enablement for Copilot Business and Enterprise 是一个典型的延迟生效功能。7 月 29 日配置入口出现，但未来 28 天不影响用户；8 月 26 日才正式生效。生效后，未显式配置的模型会被 relabel 为 inherits default，并根据默认策略动态变为可用或不可用；显式 enabled/disabled 的模型不变；open-weight 模型和不在 GitHub data retention agreement 覆盖内的模型排除在默认启用外。
这种功能最容易出“8 月 26 日早上才发现”的问题。测试团队应在今天就做未来日期演练：
建立模型清单：explicit enabled、explicit disabled、unconfigured、excluded；
配置默认策略 enabled / disabled 两种模式；
模拟或预演 8 月 26 日生效后的 expected state；
检查 model picker、Copilot CLI、VS Code、GitHub.com、Copilot app、cloud agent 是否一致；
检查默认策略翻转时，inherits default 模型是否即时跟随；
检查 explicit choices 是否绝不被覆盖；
检查 excluded 模型是否不会被默认启用；
检查审计日志是否能说明某模型为什么可用。
这类测试最适合做成“model policy snapshot diff”。8 月 25 日保存一份策略快照，8 月 26 日保存一份生效后快照，自动比对差异是否符合规则。别靠管理员肉眼数模型，模型列表这东西一多起来，很快就像超市货架，少一瓶酱油都看不出来。

4. Gemini 模型退役：替代模型不是“名字替换”，而是质量基线重跑

GitHub 7 月 31 日公告称，Gemini 2.5 Pro 和 Gemini 3 Flash 已在所有 Copilot experiences 中退役，包括 Copilot Chat、inline edits、ask and agent modes、code completions。建议替代分别为 Gemini 3.1 Pro Preview 和 Gemini 3.6 Flash。企业管理员可能需要在 Copilot settings 中启用替代模型，并可通过个人 Copilot settings 和 VS Code / GitHub.com model selector 验证可见性。
测试团队要警惕“替代模型等于无缝替换”的假设。不同模型可能在以下方面不同：
上下文窗口；
latency；
reasoning effort；
tool calling 稳定性；
  • 代码补全风格；
  • 多语言表现；
  • 安全拒答边界；
  • 图像/文本输入能力；
  • 成本；
  • 可用客户端；
  • preview / GA 状态；
  • 企业策略默认值。
因此，Gemini 退役后的验证不能只看“model picker 不显示旧模型”。还要跑：
历史 prompt 回放；
Agent 长任务回归；
code completion 接受率抽样；
安全类 prompt 拒答回归；
计费和 token 指标归因；
fallback 是否落到批准模型；
preview 模型是否被合规允许；
自动模型选择是否仍符合成本质量策略。
尤其是 Gemini 3.1 Pro 是 Preview 替代，企业不能简单把生产高风险任务全部切过去。Preview 模型要有自己的风险标签和审批策略。

5. Grok 4.5 上线：新模型默认 off，也要测“未授权不可见”

GitHub 7 月 28 日公告 Grok 4.5 在 Copilot 中逐步 rollout。它是 xAI 的 reasoning model，面向 fast agentic coding 和复杂 multi-step workflows，支持最高 500,000 token context window、text/image inputs、low/medium/high reasoning effort。GitHub 内部测试称其在 VS Code 和 Copilot CLI 的 terminal-based coding tasks 表现强，尤其适合并行工具调用和直接行动。该模型面向 Pro、Pro+、Max、Business、Enterprise，但 Business / Enterprise 管理员必须启用 Grok 4.5 policy，默认 off。
新模型测试很容易只测“启用后可用”。今天更应测“未授权不可见”和“启用范围正确”：
policy off 时，所有客户端不可选择；
enterprise teams Optional 模式下，仅指定 team 可用；
default model enablement 不应意外启用它，除非符合 GA / DRA / policy 规则；
usage-based billing 是否按 provider list price 归因；
500k context 是否触发遥测、成本和脱敏策略；
image input 是否进入数据保留和合规检查；
high reasoning effort 是否需要额外预算或审批；
并行 tool use 是否遵守 tool approval 和 MCP policy。
强模型很诱人，但越强的模型越应该先过“未授权、低预算、敏感上下文、高风险工具、长上下文”这几类用例。别让默认策略、团队授权和模型 picker 合起来悄悄把它送到所有人手里。

6. Copilot app 指标扩展：采用率口径又变了，历史趋势要标注断点

GitHub 7 月 28 日公告 Copilot app usage metrics 扩展到更多 rollups：企业和组织用户报告新增 used_copilot_app；新增 per-user totals_by_copilot_app，包含 session_count、request_count、prompt_count、token_usage；copilot_app feature value 进入 feature/model/language rollups；代码生成、接受、lines added/deleted、daily_active_users 现在包括 Copilot app 活动。
这对指标测试很重要。因为历史趋势会出现口径断点：
过去 daily_active_users 不包括只在 Copilot app 活跃的用户；
现在包括；
过去 app 只作为 standalone enterprise/org totals；
现在可以归因到用户、模型、语言、feature；
过去某些 code activity 不含 app；
现在包含。
如果管理看板不标注 7 月 28 日口径变化，8 月的数据可能看起来“采用率突然上升”“代码行数突然增加”“某模型使用量突然变化”。这未必是生产力提升，可能只是统计口径变完整。测试团队要推动 metrics schema contract：
字段出现/缺失兼容；
null / omitted 行为正确；
1-day 和 28-day 报告一致；
rollup 总数和 per-user 明细可对账；
历史趋势标注 metric definition change；
BI dashboard 不因新增 totals_by_copilot_app 结构失败。
指标是治理的眼睛。眼镜度数换了，要告诉看报表的人，不然大家会以为世界突然变清楚了。

工具与平台动态

Remote control managed devices：移动/远程控制要进入设备合规测试

GitHub 7 月 30 日公告，企业和组织现在可以限制哪些设备有资格 host remotely controlled Copilot sessions。新的 remoteControl enterprise managed setting 可以定义 remote control 如何在 managed devices 上工作：requireSSO 强制特定组织 SSO 授权，disabled 阻止 remote control，enabled 则不限制；可通过 server-managed .github-private repository、MDM-managed、file-based 三种机制部署。
这与 7 月 29 日日报中的移动端/远程控制主题形成补充：不是所有设备都应该能托管远程 Agent 会话。测试建议：
非受管设备是否被拒；
MDM 部署策略是否优先于本地文件；
SSO 授权过期后远控是否中断；
多组织场景是否按组织授权；
file-based 配置被用户修改后是否可检测；
remote control policy 与 enterprise managed settings 是否一致；
日志是否记录 device id、policy source、mode、SSO decision。
Agent 可以从手机、桌面、云端穿梭，设备边界就必须重新被测。一个未受管个人设备，不应该因为用户登录了 Copilot 就天然成为企业 Agent 会话的安全宿主。

Copilot code review Skills/MCP GA：审查上下文更强，证据归因也要更强

GitHub 7 月 29 日公告 Copilot code review 支持 agent skills 和 MCP servers 已 GA。Agent skills 可通过 .github/skills//SKILL.md 引入团队内部工具和编码标准；MCP server 可从 issue trackers、documentation systems、service catalogs 等第三方平台拉取上下文；Copilot code review 的 MCP tool calls 限定为 read-only；已为 cloud agent 配置的 MCP 会自动应用到 code review；GitHub 和 Playwright MCP 默认开启；评论会标注使用了 skill 或 MCP context。
这对测试有两个重点。
第一，read-only 不等于低风险。读取 issue tracker、服务目录、文档系统，仍可能引入敏感信息、过期规范或 prompt injection。要测 MCP 返回内容是否被标为 external/untrusted context，是否进入遥测脱敏。
第二，评论归因要能被验证。Copilot comment 标注使用了 skill 或 MCP context，测试要确认：
使用哪个 skill；
调用哪个 MCP server；
调用是否 read-only；
token 存在 Secrets and variables → Agents；
评论是否能追溯到具体上下文；
skill 版本变化是否影响 review 结果；
删除 skill / MCP 后评论质量是否按预期变化。
Code review 是质量门禁，接入更多上下文后会更聪明，也会更复杂。聪明不是问题，不可追溯才是问题。

Gemini 退役 + Grok 上线 + 默认启用：模型目录正在变成动态系统

过去很多团队把模型列表当静态配置。最近一周的 Changelog 说明这已经不现实：
Grok 4.5 新增；
Gemini 2.5 Pro / Gemini 3 Flash 退役；
Gemini 3.1 Pro Preview / Gemini 3.6 Flash 作为替代；
默认模型启用策略将在 8 月 26 日生效；
enterprise teams model policy 按用户团队授予 Optional 模型；
open-weight 和非 DRA 模型默认启用例外。
模型目录现在是动态系统。测试要覆盖新增、退役、替代、预览、默认继承、团队授权、显式覆盖、排除规则、计费归因和客户端可见性。否则模型治理就会变成“管理员手动追 Changelog”，这在 2026 年听起来已经很像在雨里记账。

研究与工程观察

日历型故障：AI 平台的新常见事故形态

所谓“日历型故障”，就是系统本身昨天没坏，今天到点切换后坏了。AI 平台特别容易出现这类问题，因为它有很多日期驱动变化：
模型退役；
模型默认启用；
字段弃用；
billing app 退役；
pricing 生效；
credit pool 切换；
preview 转 GA；
policy preview opt-in；
DRA / data retention 覆盖变化；
provider availability 变更。
这些变化往往跨多个系统：客户端、API、BI、账单、Agent routing、model picker、policy engine、docs、培训材料、support runbook。测试团队要把它们放进同一张治理日历，而不是每条公告各自处理。

Least-restrictive 授权会放大“团队 membership 数据质量”问题

Enterprise teams model policy 的 least-restrictive 语义本身合理：如果用户属于某个被授权团队，就应获得额外模型。但它也让 team membership 数据质量变得更重要。一个用户被遗留在“Frontier Pilot Team”，可能就会在全企业范围内获得强模型；一个 contractor 被误加到高权限 team，也可能拿到不该拿的模型。
测试建议把 team membership 当作模型权限的输入数据：
离职/转岗用户是否及时移除；
contractor 是否有单独 team；
pilot team 是否有过期日期；
training-completed team 是否由 LMS 自动同步；
membership 变更多久生效；
用户多 team 冲突如何审计；
模型访问日志能否反查 team grant 来源。
AI 模型权限不该只看模型策略，还要看组织目录。目录脏了，策略再漂亮也会漏风。

计费指标和质量指标不能分开看

Copilot Billing Preview app 退役、AI usage page 扩展、Copilot app metrics 进入 rollups，说明成本、采用率、模型选择、代码产出越来越绑定。测试团队应避免把 billing 当纯财务问题。
例如：
强模型启用后成本上升，但缺陷率是否下降？
Copilot app 代码行数增加，但 review 返工是否增加？
Grok 4.5 high reasoning effort 消耗更高，但长任务成功率是否提高？
默认模型启用后，用户是否选择更多高价模型？
team-level 授权后，pilot team 是否真正产出质量收益？
billing API 与 usage metrics API 是否能对齐用户、模型和 feature。
好的 AI 质量报告应该同时看质量、成本、速度和风险。只看成本会压模型，只看质量会烧预算，只看速度会冒险。像调一锅汤，盐、火、时间都要看。

理念与方法

方法一：建立 AI Governance Calendar

建议维护一份 ai-governance-calendar.md 或自动化日历，记录：
日期
事件
影响面
必测项
2026-07-31
Gemini 2.5 Pro / Gemini 3 Flash 退役
model picker、Agent、completions
替代模型回归
2026-08-01
used_copilot_coding_agent
 字段弃用节点
usage dashboard
字段迁移
2026-08-03
Copilot Billing Preview app 退役
billing、预算、对账
旧入口残留
2026-08-03
enterprise teams model policy 多数客户可 opt-in
model governance
team 授权矩阵
2026-08-26
default model enablement 生效
模型可用性
inherits default 快照
每个日期至少要有 owner、影响系统、回滚方案、监控指标和验证脚本。治理日历不是 PM 文档，是测试触发器。

方法二：做 Model Availability Snapshot

每天或每次策略变更保存模型可用性快照：
enterprise id；
org id；
user id；
team memberships；
license source；
client surface；
model id；
state：enabled / disabled / optional / inherits default / excluded / deprecated；
source：explicit / default / team grant / rollback；
policy version；
visible in picker；
callable by API / Agent；
billing category。
然后自动 diff。任何模型从不可用变可用、从可用变不可用，都必须能解释。解释不了的变化就是风险。

方法三：把字段弃用当作契约测试

Usage metrics 和 billing API 字段变化要有契约测试：
新字段存在；
旧字段缺失或保留符合时间表；
null / omitted 行为符合文档；
rollup 总和一致；
dashboard schema 不崩；
历史数据口径断点被标注；
alert 不因字段迁移误报。
例如 Copilot cloud agent 从 used_copilot_coding_agent 迁移到 used_copilot_cloud_agent，以及 Copilot app 新增 used_copilot_app、totals_by_copilot_app、copilot_app feature value，都应该进入 schema contract。别等 BI 周报空白了才发现字段换名。

方法四：为“默认启用”设计反向测试

默认启用类策略不能只测 happy path。要做反向测试：
管理员关闭默认启用后，新 GA 模型是否保持 off；
excluded 模型是否绝不被默认启用；
explicit disabled 是否不被 default enabled 覆盖；
preview 模型是否不会被当作 GA；
team Optional grant 是否不会泄漏到非成员；
用户离开 team 后访问是否撤销；
切换 default policy 是否实时影响 inherits default 模型；
审计日志是否记录模型从 inherits default 获得访问。
默认启用是效率功能，也是风险扩散器。测试的任务就是确保它扩散的是管理员允许的东西。

落地建议

今天可以立刻做的 8 件事

  1. 检查是否仍有流程、脚本、文档依赖 Copilot Billing Preview app。
  2. 将 AI usage page、billing API、usage reports 的导出结果与旧报表口径做一次对账。
  3. 盘点 Gemini 2.5 Pro / Gemini 3 Flash 残留引用，并为替代模型重跑关键任务基线。
  4. 为 enterprise teams model policy 建立用户 × team × model × client 的访问矩阵。
  5. 记录当前所有模型 explicit enabled / disabled / unconfigured / optional / excluded 状态。
  6. 在 8 月 26 日前做 default model enablement 未来日期演练。
  7. 为 used_copilot_app、totals_by_copilot_app、copilot_app rollup 更新 BI schema contract。
  8. 检查 remote control 是否只允许受管设备，并验证 requireSSO / disabled / enabled 三种模式。

本周建议补的专项测试

Copilot Billing Preview app 退役残留访问测试；
AI usage page export 与 billing API 对账测试；
model picker 中退役模型不可见测试；
替代模型质量基线回放测试；
enterprise teams least-restrictive 授权测试；
多企业 license source 策略测试；
enterprise teams mode 回滚测试；
default model enablement 8 月 26 日生效演练；
Grok 4.5 未授权不可见与授权后可用测试；
Copilot app usage metrics rollup 对账测试；
remote control managed device / SSO 授权测试；
code review Skills/MCP 只读调用和评论归因测试。

指标建议

可以把今天主题落成一组运营指标：
retired_billing_app_access：旧 Billing Preview app 残留访问数；
model_availability_drift：模型可用性非预期变化数；
deprecated_model_reference_count：退役模型残留引用数；
default_inherits_model_count：处于 inherits default 状态的模型数量；
explicit_policy_coverage：显式配置模型占比；
team_grant_auditability：模型访问可追溯到 team grant 的比例；
usage_schema_breakage：BI / ETL 因字段变化失败次数；
app_metric_rollup_delta：Copilot app 纳入 rollup 后的口径变化幅度；
remote_control_unmanaged_block_rate：未受管设备远控阻断率；
billing_quality_join_rate：成本数据与质量指标可关联比例。
这些指标能帮助团队把治理从“看公告记日期”升级为“有自动化感知的生命周期管理”。

今日结论

2026-08-03 的关键词是：日历。
Copilot Billing Preview app 今天退役，enterprise teams model policy 预览开始向多数企业开放，Gemini 模型刚刚退役，Grok 4.5 刚刚上线，Copilot app 指标刚进入更多 rollups，default model enablement 又将在 8 月 26 日真正生效。AI 平台越来越像一个不断变动的运行时，模型、计费、指标、策略和设备控制都在按日期切换。
测试团队今天最该推动的一句话是：治理日历必须变成回归测试。
不要只在功能发布当天测功能，也要在退役日、字段弃用日、默认策略生效日、preview opt-in 日、计费迁移日测系统。AI Agent 能力越强，治理切换的副作用越大。把日期变成自动化用例，才不会让某个安静的周一早上，突然变成“为什么这个团队多了一个模型、为什么账单看不到、为什么仪表盘跳了”的集体找锅现场。

参考链接

- GitHub Changelog：https://github.blog/changelog/

- GitHub Changelog：Copilot Billing Preview app will be retired on August 3：https://github.blog/changelog/2026-07-07-copilot-billing-preview-app-will-be-retired-on-august-3/

- GitHub Changelog：Enterprise teams model policy targeting in public preview：https://github.blog/changelog/2026-07-31-enterprise-teams-model-policy-targeting-in-public-preview/

- GitHub Changelog：Default model enablement for Copilot Business and Enterprise：https://github.blog/changelog/2026-07-29-default-model-enablement-for-copilot-business-and-enterprise/

- GitHub Changelog：Gemini 2.5 Pro and Gemini 3 Flash deprecated：https://github.blog/changelog/2026-07-31-gemini-2-5-pro-and-gemini-3-flash-deprecated/

- GitHub Changelog：Grok 4.5 is now available in GitHub Copilot：https://github.blog/changelog/2026-07-28-grok-4-5-is-now-available-in-github-copilot/

- GitHub Changelog：GitHub Copilot app usage metrics now expand across report rollups：https://github.blog/changelog/2026-07-28-github-copilot-app-usage-metrics-now-expand-across-report-rollups/

- GitHub Changelog：Limit remote control to managed devices：https://github.blog/changelog/2026-07-30-limit-remote-control-to-managed-devices/

- GitHub Changelog：Copilot code review: Agent skills and MCP now generally available：https://github.blog/changelog/2026-07-29-copilot-code-review-agent-skills-and-mcp-now-generally-available/

- GitHub Changelog：Copilot cloud agent fields added to usage metrics：https://github.blog/changelog/2026-04-23-copilot-cloud-agent-fields-added-to-usage-metrics/