GitHub在2026年11月5日更新了Copilot用量指标：一组字段标出客户端遥测缺口和版本门槛问题，另一组记录代码审查评论是否得到开发者回应或处理。对负责团队周报的人，这次变化的价值是把“看不到细节”和“没有使用”分开，也让审查反馈不再只按点击应用建议来统计。
本文依据两份官方公告和11月9日核对的字段文档，给出两组合成算例及报表接入判断。A—F、仓库名称和数字均为本站自拟，不是实际组织数据；没有读取企业报表、启用遥测或进行效能评测。
活跃用户有记录，明细仍可能缺失
遥测与版本缺口公告新增了用户级的client_telemetry_present和usage_metrics_requirements。前者记录当天是否收到了合格的客户端用量遥测；后者把可识别的IDE和扩展分别归入met、unmet、unknown，检查其最后已知版本是否满足指标要求。
字段文档对边界写得更清楚：false表示服务器观察到用户活动，但没有收到合格客户端遥测；true也不保证所有遥测完整。null或缺项表示未知或未评估，不能改成false；只有云端代理或代码审查活动等情形也可能没有这个判断值。
因此，活跃人数没有下降而代码行数或功能明细减少时，先看数据覆盖。不能直接推出“开发者停止使用Copilot”，也不能仅凭版本达标就认定传输正常。版本检查和遥测到达是两个独立信号。
| 示例用户 | 遥测标记 | 本例版本摘要 | 能得出的判断 |
|---|---|---|---|
| A | false | unmet | 两种缺口重叠 |
| B | false | met | 版本达标，仍缺客户端遥测 |
| C | true | unmet | 收到遥测，不代表所有版本达标 |
| D | null | unknown | 保留未知，不能算成没有使用 |
| E | true | met | 仍需核对报告所需明细是否齐备 |
上表为阅读练习，把多组件版本结果压缩成摘要，不是API的原始JSON结构。真实usage_metrics_requirements会分别列出IDE与插件标识，不应只保存一个“通过/不通过”而丢掉具体组件。
两项人数相加，会把A算两遍
日报新增missing_client_telemetry_user_count和below_usage_metrics_minimum_user_count。在上面的合成例中，缺遥测的是A、B，共2人；低于版本门槛的是A、C，也是2人。受任一问题影响的已知用户只有A、B、C三人，直接相加却得到4。
这个交集结果由本站集合计算核对。若你手头只有两个聚合计数，不能反推出实际交集；应分别展示两个指标，或在已有权限、同日同范围的用户级记录上去重。没有明细时，不能凭空填写一个“受影响总人数”。D的未知状态还应单列，不加入“已确认正常”组。
跨日相加也要改单位。假设第一天缺遥测的是A、B，第二天是B、F，两天计数相加为4，但不同用户只有A、B、F三人。每日人数之和不能直接标成周内独立人数。
用户字段出现在企业或组织用户报表中，聚合计数按日提供，包括28日报表的每日条目。公告明确发布前日期没有这些值；历史记录中的null或缺项不是零。接入新字段时，应保留“不具备数据”的状态，并在周报中交代有效日期范围，避免把新字段上线误读成突然出现了一批问题。
评论被处理，不等于代码问题已经修复
同日的代码审查指标公告为仓库级日报增加copilot_code_review对象。其中，total_comments_evaluated是纳入判断的评论数，total_comments_addressed是开发者作出处理的评论数，两者构成评论处理率。
“处理”不只包含点击应用建议，还包括自行修改、让Copilot修改，以及回复将在后续PR处理。因此，某条评论被计入addressed，并不足以证明当前PR已经修复了相应问题。它也不能直接替代只计点击应用的旧建议指标，更不应改名为“AI审查正确率”。
这组评论在PR合并时评价，归到合并日。比如11月5日发出的评论，如果PR在11月8日合并，这组统计属于11月8日；报表何时可下载，还要看数据处理状态。通常不评价机器人创建PR上的评论，而“Copilot审查后无人请求变更的已合并PR数”仍包含这类PR。后者以PR为单位，不能拿来充当评论处理率的分母。
合并两个仓库的比例，要先合并计数
下面是第二组合成算例，假定两行来自同一报告范围、同一日期，仓库互不重叠，且采用相同口径：
| 示例仓库 | 已评价评论 | 已处理评论 | 仓库处理率 |
|---|---|---|---|
| 小样本仓库 | 2 | 2 | 100% |
| 大样本仓库 | 98 | 49 | 50% |
直接平均两个百分比得到75%；但100条已评价评论中，已处理的是51条，合并处理率应为51%。本站用分数运算核对了两种计算，差别来自权重，不是产品性能变化。
合并处理率 = (2 + 49) / (2 + 98) = 51%
不能用作合并率的简单平均 = (100% + 50%) / 2 = 75%报表应同时保留分子和分母，不只存最后一个百分比。分母为0时应显示“不适用/无法计算”，不能硬填0%；前者表示没有这组评价样本，后者会被读成“有评价但没有一条得到处理”。合并多日时还要排除重复的仓库—日期行，不能把28日汇总和其中某一天再加一次。
即使合并率上升，也只能先说明这个统计口径下处理比例变化。样本规模、评论类型、合并节奏和机器人PR范围都可能影响它。判断代码质量还需要实际差异和测试证据，不能由这个比例独立完成。
周报接入时，留下哪些可以追查的字段
对已经获授权读取指标的管理员或分析人员，可以把下面三项作为本次报表改造的验收，而不是只新增两张趋势图：
- 同一张记录明确企业或组织范围、报告粒度与day。用户级缺口和仓库级审查数据分开处理；不同组织的用户总数不直接当成企业去重人数。
- 遥测部分保留false、true、未知三类，保存具体未达标组件；分别展示两个受影响计数，只有有依据时才给出去重并集。版本全达标但仍缺遥测的对象，继续核对有效客户端设置和传输路径。
- 审查部分保存evaluated、addressed及合并日期，以相同口径、非重复行计算比例；同时标注0分母和小样本，保留具体PR复核入口，不把“以后修”当成当前已修复。
REST API文档说明，接口提供的是有期限的报告下载链接，数据对应已经处理完成的报告日期。下载时间不是活动时间；接入程序应保存报告的day和范围，而不是用“今天下载”覆盖它们。访问还取决于Copilot usage metrics策略及相应指标读取权限，本文没有替任何账户调整这些设置。
本次两项更新更适合用来修正报表的覆盖度与统计口径。它们与本站之前介绍的原始内容采集开关、OpenTelemetry执行轨迹、PR等待阶段各有用途；看到一个新字段，不代表这几套数据可以不加区分地互换。
原公告日期均为2026年11月5日，资料核对日期为11月9日。正文两张表是本站合成算例，封面为浅色资讯阅读概念图，均非企业实测截图。进一步核对可查看官方字段类型和空值说明及指标范围、版本要求与缺失数据说明。
相关旧稿：遥测身份归属与内容采集控制、OpenTelemetry中的Agent执行轨迹、PR审查阶段与等待时间的统计口径。
资料查阅与编辑日期：2026年11月9日。作者：玖柒。
