团队采用与效果评估

官方团队采用教程面向已有协作习惯的团队，使用两周 onboarding sprint 帮助成员把 Copilot app 和 CLI 用到真实工作中。两周可以提供早期采用信号，不能证明长期生产率、成本或因果效果。

准备真实工作与基线

选择有负责人、愿意分享经验的资深成员、适合代理处理的任务和稳定交付指标的团队。参与者应有代表性，避免只邀请已经热衷使用工具的人。

先确定一个重复使用目标，再选择一到两个业务结果，例如准备 PR 的耗时、维护任务完成量、熟悉陌生代码的时间或评审质量。记录试用前基线，避免把生成代码行数当作成功目标。

确认用户的许可证来源、app 和 CLI 各自政策、安装登录、项目访问及预算。组织政策的实际影响范围可能大于参加 sprint 的团队，不能把参与名单视为技术隔离范围。

两周各自做什么

第一周由团队负责人演示真实任务，成员结对完成小范围工作，随后在日常任务中使用选定的两到三个流程。示例包括调查失败、规划跨文件修改、运行测试、检查 diff 和准备 PR。

第二周讨论哪些流程有帮助、哪些障碍仍存在，再分别处理：

• 不知道如何开始：提供经过试用的起始提示。
• 缺少上下文：改进仓库指令、任务描述或工具配置。
• 不信任输出：演示 diff 审阅、权限限制、测试和丢弃修改。
• 工具不可用：核对许可、政策、认证、网络及安装。
• 其他入口更适合：保留该任务原有流程。

试用期间持续检查费用、支持问题、实际行为和政策范围。无需为了统一入口而阻止正常 IDE 使用。

从日粒度数据计算持续使用

教程举例要求每位参与者每周至少三天使用 app 或 CLI；这是可调整的试点目标，不是 GitHub 对所有企业的合格标准。

在用户日粒度报告中：

1. 筛选 sprint 日期。
2. 保留 used_cli 或 used_copilot_app 为 true 的行。
3. 按用户及周分组。
4. 计算每组不同 day 的数量，分别检查每周是否达到目标。

更深入的会话、请求和提示统计可参考 totals_by_cli、totals_by_copilot_app。按团队分析时，按正确实体、用户和日期关联用户团队报告，见团队指标。

临时 PR 标签或提交标记可以帮助寻找案例，但属于自报线索，不是权威使用遥测。Impact dashboard 的 cohorts 使用过去 28 天，且包含超出这两种工具的代理活动，不能把 cohort 变化直接归因于两周 sprint。

区分不同指标的覆盖范围

官方试用成功教程仍将主要 dashboard 描述为 IDE 数据，并列出未包含 CLI 等入口的限制；较新的团队教程则使用专门的 CLI/app 日字段。不要因此推断全部指标都已覆盖所有客户端，也不要丢弃确有定义的客户端专用数据。逐字段范围见指标覆盖与口径及CLI 与 app 指标。

同样，试用教程给出的首月激活比例只是示例成功指标，并非统一 SLA。是否满意、是否节省时间，应结合调查、访谈和真实工作记录，不能直接用接受率代替。

评估并决定下一步

将重复使用情况与团队结果一起观察，例如人均合并 PR、合并耗时中位数、维护任务完成率、缺陷与返工，再加入开发者反馈。项目复杂度、人员和工作类型都会影响这些数字，不能将所有变化归因于 Copilot。

记录哪些流程能够自然重复、主要障碍、支持成本、使用费用和质量结果，再决定扩大、调整或停止。涉及成本的推广决定仍需等待足够的完整计费周期证据，见企业试点。