采用阶段、人数分母与影响比较
按滚动窗口理解 Phase 1–3,并区分每日活跃人数和完整阶段人群。
采用分组描述用户使用哪些功能,以及是否在过去 28 天内达到至少两个不同活跃日的门槛。它不是按总请求量排序,也不直接衡量个人能力或工作表现。
分组规则
| 阶段 | 符合门槛的活动 |
|---|---|
| No Cohort / Passive users | 尚未达到任何阶段要求;不等于完全未使用 |
| Phase 1:Code first | code_completion 或直接写入文件的 agent_edit |
| Phase 2:Agent first | 恰好一个 GitHub agent 入口:CLI、cloud agent 或 code review |
| Phase 3:Multi-agent | Copilot app,或至少两个 Phase 2 的 agent 入口 |
Code review 的主动与被动参与合起来算一个入口。每项参与按其功能信号判断,取用户符合的最高阶段;不需要先单独满足 Phase 1 才能进入 Phase 2 / 3。Partner-built agent apps 当前不影响阶段。
只在 IDE Chat 或 agent mode 问答、不产生补全或直接文件编辑时,即使频繁使用也可能属于 No Cohort。used_agent、used_chat 或接受次数不能单独替代阶段判定;Chat 中复制代码也不自动等于 code_completion / agent_edit。
阶段每天依据滚动窗口重算,旧活动移出窗口可能使阶段变化。
三种人数不要混用
| 字段或视图 | 人群 |
|---|---|
| Impact 看板 | 过去 28 天内活跃过的用户,按当前阶段分类 |
total_engaged_users | 某阶段中该记录当天活跃的用户 |
users_in_phase_28d | 截至记录当天,该阶段完整的滚动 28 天人群 |
较早日期或缺少阶段快照时,users_in_phase_28d 可以缺省;0 才表示已测得没有用户。某阶段当日无人活跃但窗口内仍有人时,可以出现 total_engaged_users=0、users_in_phase_28d>0 的记录。
按官方定义计算阶段的每用户 28 天合并 PR 指标时,先汇总每日 total_pull_requests_merged,除以同期每日 users_in_phase_28d 之和,再乘 28。不能改用仅当天活跃的 total_engaged_users 作分母。
功能参与对象
28 天聚合报告可带 copilot_feature_engagement,当前七种 feature 为 code_completion、agent_edit、code_review_passive、code_review_active、cloud_agent、copilot_cli、github_app。
这里 github_app 表示 Copilot app,与普通活动明细的 copilot_app 名称不同。参与人数要求窗口内至少两个不同日期;同一人可以参与多项,因此不能相加。当前该对象不包括 Chat 或专用 VS Code Agents window。
对象的 active_user_count 对应结束日各阶段 users_in_phase_28d 之和;对象缺失不应替换成有效的全零报告。有效零用户报告仍有七个 feature,计数均为零。
采用倍数与估算回报
Adoption multiplier 比较 Phase 1–3 与 Passive users 的每用户每月合并 PR 量和合并耗时。例如两个群体平均合并 20 与 10 个 PR,输出倍数为 2。
这是不同用户群体的比较,不是同一批用户使用前后的实验。团队组成、资历、任务大小与项目复杂度都会影响结果,不能据此声称采用深度导致确定比例的提升。
Potential ROI 比较 Phase 0–1 与 Phase 2–3,使用实际 AI credits 消耗及所选薪酬假设估算成本占比;仅看板提供,不在 API / NDJSON 中。跨组织或跨时段比较时应保持假设一致,并结合实际工作类型解释。