本教程将逐步指导你如何端到端地开展试点:设置预算、为受控群体启用该功能、监控结果,并根据证据做出并汇报是否继续推进的决定。
开始试点之前
在启用任何内容之前,请确保已评估功能或模型,并确认它符合合规性要求。 请参阅“准备新功能和模型”。
如果您不确定某项功能或模型是否可以安全启用,请在开始试点之前先咨询贵公司的安全与合规团队。
明确成功的标准
在开始之前,先明确什么才算“可以推进”,这样你就能对照预先制定的计划来评估试点,而不是事后再判断。 记下一些具体的成功标准,包括采用(例如,最小活跃用户份额)、成本(保持在你设置的上限内)和定性反馈(例如,大多数参与者会推荐该功能)。 你将在做出继续或停止决定中,对照这些标准检查试点项目的实际结果。
还要规划试点运行的时间。 预算以及 AI credits 的共享池会在每个计费周期重置,因此请将试点安排为至少持续一个完整的计费周期,通常为四到六周;试运行时间过短可能导致成本和采用情况数据过少,无法得出可靠的结论。
选择要包含在试点组中的人员
由于功能和模型是在组织级别启用的,因此,凡是通过该组织获得其 Copilot 许可证的人都将获得使用权限,而不只是少数经过人工挑选的人,也不一定涵盖该组织的所有成员。 因此,与其选择个人,不如寻找其持证人数已经符合以下标准的组织:
- 开发人员正在做真正的有意义的工作。 试点参与者应在对贵组织重要的语言、框架和代码库中使用该功能,而不是在临时项目中使用。 使用和成本信号仅当它们来自真正的工作时才可信。
- 技能和资历级别的混合。 包括经验丰富的工程师,以及对你的代码库或对 Copilot 还不太熟悉的人。 不同级别的体验使用不同的功能,并发现不同的价值和不同的问题。
- 一系列团队和工作流。 帮助一个团队工作流的功能可能无法帮助另一个团队。 涵盖几个团队能让你更可靠地判断该功能在哪些方面能带来价值,在哪些方面不能。
- 愿意提供反馈的人。 试点的大部分价值都来自定性反馈,而不仅仅是指标。 选择那些会积极参与、会反馈哪些做法有效哪些无效,并且在你征求他们意见时会作出回应的参与者。
如果现有组织都不合适,例如合适的人员组合分散在多个组织中,或者组织规模太大,不适合作为一个封闭的试点范围,则可以创建一个专门的组织,并且只将选定的用户添加到该组织中。 这样可以精确控制纳入哪些用户,但这也意味着需要为这些用户迁移或复制仓库访问权限,而且对于像 Copilot云代理 这样依赖深层仓库级上下文的功能,这种做法可能并不适用。 本教程假设你使用的是现有组织;如果你选择使用专用组织,请在 为试点组启用该功能 之前,将设置组织并添加成员视为一个额外步骤。
估算成本并设置预算上限
要试点的许多功能和模型都通过使用情况计费,因此支出不会由你分配的许可证数固定。
使用边界模型或代理功能的少数活跃开发人员可能会消耗超过预期。 大致估计试点的成本,并决定在启用该功能之前愿意花费的上限。
首先了解功能或模型的计费方式。 按使用量计费的功能会消耗 GitHub AI Credits,每次交互的成本取决于所用模型和消耗的令牌数量。 若要了解哪些功能会计入用量、已含额度如何在整个企业范围内统一汇总,以及超额用量如何收费,请参阅 组织和企业的基于使用情况的计费。
若要生成估计值,请组合三个数字:
- 您在上一部分中定义的试点组人数。
- 你期望它们使用该功能的频率。 这一点只有在人们真正开始使用它之后才会知道,因此应选择一个有意偏高的估计值,而不是试图精确预测它。 如果已推出可比较的功能或模型,请使用其实际使用情况作为参考点。 如果不是这样,则按每位开发者高频、重度使用来估算,因为智能体功能和前沿模型每次交互的成本都高于一次简短的聊天提问。 执行密集工作的小型组有时使用该功能的成本可能高于大型组。
- 您可以使用的已含津贴。 每个已分配的许可证都包含每月一定额度的 AI credits,这些额度在企业层面统一共享,因此,在产生任何超额费用之前,试点项目的部分用量可能已由该共享额度覆盖。
用这些来设定一个上限:在你觉得需要暂停并重新评估之前,你愿意为试点项目投入的最高金额。 选择一个合适的数值,既能让试点有足够空间产生有意义的使用数据,又能在用量高于预期时控制您的风险敞口。 如果稍后调整试点组大小,请重新评估这一估算值。
例如,假设你在 Copilot业务 上向 20 名开发人员试点一项代理式功能。 每个许可证每月包含 1,900AI credits,因此在开始任何按量计费之前,您的试点组可共享使用 20 × 1,900 个已包含的AI credits。 如果预计当月每个开发人员的使用量约为 3,000 AI credits ,则估计总使用量为 20 × 3,000。 减去套餐内包含的用量,以估算按量计费的用量,然后再乘以 $0.01 USD 来估算超额成本,并将上限设置得略高于该金额。 在启用该功能后,你将创建强制实施此上限的预算,在 “设置预算”中限制试点成本。
为试点组启用该功能
现在,既然你已经估算了成本并确定了要纳入的人员,就可以在受控范围内启用该功能。 目标是为试点组提供真实、正确的治理体验,同时使其余企业不受影响。
你将在四个步骤中执行此操作:
- 确认组织成员身份和许可证分配。
- 配置管理该功能的策略。
- 仅为该组织启用该功能。
- 设置预算以限制试点的成本。
确认组织成员身份和许可证分配
仅成员身份是不够的:大多数 Copilot 策略都基于哪个组织分配用户的 Copilot 许可证,而不仅仅是他们所属的组织。 如果某人属于多个组织,请确认其许可证是通过试点组织专门分配的。 如果通过其他策略分配,则试点组织的策略不会控制其访问权限,本教程中的功能启用将不适用于它们。
如果某些试点用户尚未成为成员,或者虽已是成员但其许可证是通过其他组织分配的,请先将他们添加到试点组织中,并通过该组织为其分配 Copilot 许可证,然后再继续。
启用该功能之前配置策略
Copilot 策略控制用户可以访问哪些功能和模型以及处理其数据的方式。 在启用该功能 之前 ,请为试点组织配置这些策略,以便试点用户从其第一次交互中获得正确的治理体验,而不是一个简短的窗口,其中没有你打算的护栏即可使用该功能。
确定试点应允许哪些功能和模型,并在组织级别设置策略,使更改仅影响试点组织;在企业级别设置的策略适用于企业中的每个组织。 如果企业策略不允许组织设置自己的价值,企业所有者必须更改此值,然后才能继续。 若要了解策略如何从企业逐级传递到各组织,以及谁可以在各级别替换设置,请参阅 针对企业和组织的 GitHub Copilot 策略。
为单个组织启用该功能
作为组织所有者,请仅从组织的 Copilot 策略设置中为试点组织启用特定功能或模型。 有关完整步骤,请参阅 管理组织中GitHub Copilot的策略和功能。 确认该设置适用于试点组织,而不是整个企业,然后再保存它。
设置预算以限制试点成本
早些时候,你决定为飞行员设置支出上限。 现在,您将创建用于落实它的预算。
首先,了解组织预算的作用。 它仅对 按量计费 的费用设定上限,并且只有在 AI credits 共享池耗尽后才会生效。 它不会对总支出设上限,因此应将限额设置为你愿意为超出已包含额度的部分支付的超额费用,而不是试点的总成本。 关键是,预算默认并非硬性停止:超出限额后,费用仍会继续累计,除非你在创建预算时启用 在达到预算限额时停止使用。
作为组织所有者或计费经理,创建限定为试点组织的预算,将其限制设置为所选超额上限,并在 达到预算限制时启用“停止使用”。
如果您想防止某个试点用户的用量过快增加,还应设置统一的用户级预算。 这是唯一一个始终执行硬性停止的控制项,它会将用户在共享池和计量使用中的用量共同计入同一限额。 将其设置为适度的金额,使参与者能够执行实际工作,但阻止任何一个用户消耗试点预算的超大份额。
有关预算如何在用户、组织和企业级别计量用量并阻止使用,请参阅 基于使用情况的计费预算。
监控试点项目
在整个试点过程中,跟踪采用,收集开发人员反馈,并针对在开始时定义的成功标准监视成本和代理活动。 这些信号一起有助于决定是否扩展该功能。
使用 Copilot 指标跟踪采用和使用情况
使用 Copilot 使用情况指标查看试点用户的数量、使用该功能的频率,以及这些数字在试点期间的趋势。 保持稳定或持续增长的采纳率是一个强有力的信号;而使用量短暂激增后又回落,则可能意味着该功能并未真正融入开发者的实际工作流程。
- 若要了解指标涵盖的内容以及如何解释它们,请参阅 GitHub Copilot使用情况指标。
- 若要查看组织或企业的仪表板,请参阅 查看 Copilot 使用情况指标仪表板。
从试点组收集开发人员反馈
指标能告诉你人们是否使用了该功能,但不能告诉你为什么使用,以及该功能对他们的效果如何。 收集定性反馈以填补这一差距。 开展简短调查、定期沟通,或设置一个专门渠道,让试点用户反馈哪些方面运作良好,哪些方面存在问题。
这时,你所选择的那些愿意提供反馈的参与者就显出价值了。 提出具体问题:该功能在哪些方面节省了时间、在哪些情况下效果不佳,以及它是否改变了他们的工作方式。 这种反馈通常显示单独数字不会透露的问题和机会,它为你提供了以后与领导层分享的具体示例。
监视预算和审核日志中的成本和代理活动
在整个试点过程中,持续关注支出相对于你制定的预算的情况,而不是只在最后才关注。 如果使用量比预期更早接近上限,这就能为评估更大范围推广的成本提供有价值的早期证据。 有关跟踪支出与预算对比情况的步骤,请参阅 监控您的GitHub AI Credits使用情况。 有关跟踪随时间推移的支出,请参阅 管理公司对 GitHub Copilot 的支出。
除了成本外,还观察该功能是否被安全使用。 这是领导层会问的第三个问题,而试点正是你用证据而非口头保证来回答这一问题的机会。 对于代理式功能,请查看代理会话,以了解该功能实际上在代替您的开发人员执行什么操作,并发现任何意外或不希望出现的行为;审核日志仅记录该功能何时被启用或禁用,但不会记录这一级别的详细信息。 确认你设置的策略和预算是否按预期发挥作用,并留意哪些方面在更大规模下需要更严格的防护栏。 请参阅“监视企业中的代理人活动”。
做出继续或不继续的决定
在试点结束时,对照你预先设定的成功标准评估结果,并决定是扩大该功能的范围、暂缓推进并收集更多数据,还是将其回滚。 故意做出决定,并记录其背后的证据。
确认你有足够的证据来决定
在决定之前,请检查试点是否在计划期间运行,并生成了足够的数据来支持可防御的结论。
试点使用会先消耗共享池中的额度(无需额外费用),之后才开始按量计费,因此在试点初期出现 0 美元支出是正常的,而较短的运行时间可能会使成本数据产生误导。
当你具备以下条件时,你就可以做出决定:
- 呈现稳定趋势而非早期一次性激增的采纳指标。
- 实际成本数据,跨越至少一个计费周期,可以与估算进行比较。
- 来自试点用户的代表性范围的反馈。
如果这些方面中有任何一项证据不足,例如使用量仍在持续上升,或者只有少数参与者加入,那么应考虑延长试点,而不要依据不完整的证据作出决定。 有数据支撑的决策更容易向领导层交代,也更不容易被推翻。
向领导报告
为了证明你的决定是正当的,并为更广泛的推出建立案例,请向领导报告试点的结果。
标识要共享的数据
将你在试点期间收集的信号组合在一起:
- 采用指标,显示有多少试点用户处于活动状态,以及使用情况随时间推移的趋势。
- 实际成本与预算相比,将试点支出与设置的上限和原始估算值进行比较。
- 反馈主题,总结参与者发现价值的位置,以及他们遇到问题的位置。
- 安全和治理观察结果,包括从审核日志中了解到的任何情况,以及策略和预算的实际表现。
从 ROI 角度审视采用情况、成本和安全性
以业务术语显示数据,而不是原始数字。 将采用情况和反馈与该功能带来的价值联系起来,例如节省的时间、得以推进的受阻工作或质量提升,并将这些价值与其实际成本以及你观察到的任何治理或风险因素进行权衡。
最后给出明确的建议:扩大推广、维持现状还是停止,以及如果要进行更大范围推广,成本会是多少。 将试点定位为一个关于投资回报、成本可预测性和风险可控性的问题,能够为管理层提供其所需的依据,从而有信心批准更大范围的推广。
根据你的决定采取行动
根据收集的证据和做出的决定,执行下一步。
在整个企业范围内扩大部署
如果有证据表明可以推进,就应分阶段逐步扩大发布范围,而不是一次性全面铺开。 将功能策略扩展到更多组织,并在每个阶段看起来正常后再扩展到企业的其余部分。 随着用户数量增加,提高预算或新增预算,使支出控制能够随着用户规模扩大而相应扩展,并在每一步持续监控使用情况和成本。
有关如何在整个企业范围内部署推广的更全面指导,请参阅 大规模推广GitHub Copilot。
干净地回滚并禁用该功能
如果证据表明不可行,就应彻底停用该功能,以免留下持续的成本或造成混乱。 关闭试点组织的功能或模型策略,并告知参与者试点已经结束,因此他们不会想知道为什么该功能消失。
确认没有任何剩余用量会继续从你的预算中扣费,并检查或删除试点预算,以免其影响今后的报告。 保留你收集到的数据和反馈:即使得出的结论是不可行,这仍然是值得与领导层分享的有用结果,并且在该功能成熟后,还可能为后续的重新评估提供参考。