GitHub AI 产品负责人 Shuyin Zhao 在官方博客上发布了一篇文章，讲了他们在构建和扩展 GitHub Copilot 时学到的经验教训。文章中阐述了他们在三年多的时间里将项目分解为找到它、搞定它和扩展它三阶段，并最终成功推出 GitHub Copilot 的过程。

在 “找到它” 阶段，GitHub 专注于确定 AI 可以有效解决的具体问题，以一种足够集中的方式快速推向市场，它要足够强大，在业界可以引起关注，产生影响。

“搞定它” 阶段涉及迭代式产品开发，重点关注来自使用 A/B 测试的开发人员的真实用户反馈。这使得团队能够迅速进行迭代，允许团队快速尝试并学习。在通过 Web 界面与 Copilot 一起进行了短暂的实验后，团队将焦点转向 IDE，以减少编辑器和 Web 浏览器之间的任务切换，同时使 AI 功能在后台运行。观察到的开发人员在编码时同时参考多个打开的 IDE 选项卡后，后续的迭代使 GitHub Copilot 能够同时处理多个文件。

最后在 “扩展它” 阶段，团队通过确保 AI 模型的结果一致性、管理用户反馈和定义关键性能指标，优化了应用以实现普遍可用性（GA）。他们还优先考虑了安全性和负责任的 AI 使用，实施了过滤器，以避免不安全或冒犯性的代码。

下面是 Shuyin Zhao 文章的译文。

在我们正式向广大用户发布 GitHub Copilot 之前，我们花了三年的时间进行开发。要从构思到实际产品，我们遵循了三个阶段 —— 找到它、搞定它、扩展它，这些阶段大致遵循了创业产品开发中的 “先定型，后扩展” 框架。

具体来说，这三个阶段如下：
找到它：确定一个有影响力的问题领域，适用于你的 LLM 应用程序。
搞定它：创建出色的 AI 产品体验。
扩展它：准备好你的 LLM 应用程序，以便广大用户可以使用（GA）。

让我们开始吧。

一.找到它：明确你要解决的问题
有时，创建解决方案最困难的部分是明确问题的范围。问题应该足够具体，能够迅速产生影响，但也要足够大，以使正确的解决方案能够吸引用户。此外，你需要找到一个适用 LLM 的问题，而不仅仅是为了提高产品参与度而集成 LLM。

明确你想要帮助的对象。我们认识到 AI 可以提高效率，因此我们希望优先帮助那些时间经常紧张、需要频繁切换上下文的开发人员，帮助他们更快地编写代码。

首先专注于一个单一问题。与试图用 AI 解决所有开发者问题不同，我们将重点放在了软件开发生命周期的一个环节上，即在集成开发环境（IDE）中编写函数。当时，大多数 AI 编码助手只能完成单行代码。

在产品目标和质量之间取得平衡。虽然 GitHub Copilot 团队最初探讨了生成整个提交的可能性，但当时 LLM 的状态无法以足够高的质量支持这一功能。通过进一步测试，团队最终决定提供 “整个函数” 级别的代码建议。

满足用户的需求。在为开发者设计产品时，LLM 应用程序应该强化现有工具或集成到现有工作流程中。GitHub Copilot 团队的座右铭是：“如果你在使用 GitHub Copilot 时不得不改变编码方式，那就是一个失败。” 实际上，这意味着使开发人员能够在不改变工作方式的情况下接受代码建议。

二.搞定它：迭代以打造顺畅的 AI 产品体验
利用新兴技术，如生成式 AI，进行产品开发之路通常是曲折的，因为很多东西都是未知的，但是该领域的快速进步又能迅速打开新的大门。在产品开发过程中引入快速迭代周期允许团队快速失败并快速学习。在 GitHub，我们快速迭代的主要机制是 A/B 实验平台。

根据 GitHub Next 研究高级总监 Idan Gazit 的说法：“我们不仅要为输出结果需要人类评估的模型设计应用程序，还要为正在学习如何与 AI 互动的人类设计应用程序。”

站在用户的角度思考。GitHub 员工有一种设身处地思考的文化，即在产品发布之前和之后都要 “自行品尝” 产品。这意味着 GitHub Copilot 团队建立了一个简单的 Web 界面，可以在其中调整基础模型并探索如何在他们自己的开发工作流中利用这些模型。

我们很快发现，Web 界面并不是合适的工具，因为这意味着开发人员必须在编辑器和 Web 浏览器之间不断切换。因此，团队决定将焦点放在将 GitHub Copilot 引入 IDE 并使 AI 能力无需模式切换，即在后台运行。

我们团队的开发人员还注意到，他们在编码时经常会引用 IDE 中打开的多个选项卡。这一观察结果促使他们尝试了一种称为 “相邻选项卡” 的技术，其中 GitHub Copilot 会处理开发人员 IDE 中打开的多个文件，而不仅仅是他们正在处理的单个文件。相邻选项卡将 GitHub Copilot 的建议接受率提高了 5%。

评估你的测试工具。随着我们测试的继续进行，我们不得不将内部测试工具扩展成更加灵活且强大的工具。尽管最初我们依赖自己的工具进行测试，但最终根据规模的反馈和互动切换到了 Microsoft 实验平台以优化功能。

避免沉没成本谬误。这种情况是指你因已经大量投入而不愿放弃某项项目，即使明显切换方向会更有利也是如此。

最初，GitHub 和 OpenAI 团队认为每种编程语言都需要其自己经过精细调整的 AI 模型。但生成式 AI 领域发展迅猛，我们的假设最终被证明是错误的。最终，OpenAI 的 LLM 显著改进，一个模型能够处理多种编程语言和任务。

养成重新审视旧想法的习惯。在一个迅速发展的领域中，今天的 LLM 无法实现的功能，明天可能就能够实现。

起初，我们探索了一个供开发人员提出编码问题的聊天界面。在早期测试中，用户对编码建议的功能和质量寄予了更高的期望，而当时 GitHub Copilot 无法满足这些期望。因此，我们降低了该功能的优先级。但随着 ChatGPT 的出现和 LLM 的不断发展，客户逐渐熟悉 AI 聊天机器人，像 GitHub Copilot Chat 这样的迭代聊天体验成为可能。

三.扩展它：优化 AI 的质量、可用性和负责任使用，以实现 GA
早期反馈和技术预览对于推动产品改进和将应用程序推向 GA 至关重要。下面内容是我们在推出 GitHub Copilot 技术预览之前采取的步骤，以及我们如何管理技术预览并优化用户反馈，以及我们如何准备内部基础设施以处理大规模需求。

优化质量和可用性

确保结果一致。由于 LLM 是概率性的，意味着它们不会总是产生相同的、可预测的结果，因此需要基于统计的测试。一个解决方案涉及建立一个质量管道，以应对构建 LLM 的独特挑战。例如，当 GitHub Copilot 团队首次决定提供整个函数编码建议时，我们还必须确保输出的可预测性和一致性，即相同的提示和上下文将从 AI 模型产生相同的建议。

为此，团队采用了两种策略：改变参数以减少输出的随机性，以及缓存回复。此外，使用缓存回复而不是对同一提示生成新的回复，不仅减少了建议的可变性，还提高了性能。

为技术预览设置等待列表。等待列表允许 GitHub Copilot 团队管理问题、反馈和评论，并确保我们能够有效地解决它们。这种方法还有助于确保我们有来自各种经验水平的早期采用者，以提供反馈。

利用真实用户的反馈。在一个例子中，开发人员分享说，更新对模型编码建议的质量产生了负面影响。作为回应，GitHub Copilot 团队实施了一个新的保护性度量标准 —— 建议的多行与单行的百分比 —— 并调整了模型以确保客户继续获得高质量的建议。

在 GitHub 团队积极开发 GitHub Copilot 以了解开发者体验的同时，我们也受益于 GitHub 外部开发者在实际使用案例中提供的各种反馈。GitHub Copilot 团队与技术预览版用户在用户偏好的平台上进行了早期、频繁的互动。这让我们能够实时积极地回应问题和反馈。

在规模扩大的同时保持不断迭代。当 GitHub Copilot 普遍可用后，团队不仅需要改进产品，还需要改进基础设施。当我们尝试并迅速迭代 GitHub Copilot 时，它直接与 OpenAI API 一起运行。随着产品的增长，我们扩展了对 Microsoft Azure 基础设施的使用，以确保 GitHub Copilot 具有大规模、企业级产品的质量、可靠性和负责任的保护措施。

定义产品的关键性能指标。为了优化 GitHub Copilot，我们使用早期开发者反馈来确定正确的性能指标，如代码接受率，以及最终的代码保留率（度量开发者保留或编辑的原始代码建议的程度）。

优化成本。团队努力优化提供 GitHub Copilot 建议的成本，同时平衡了对开发者的影响。例如，在我们决定使用幽灵文本之前，即在你输入时闪烁一个编码建议的灰色文本，该工具会急切地生成 10 个建议并一次性显示它们。当大多数人选择第一个建议时，这会产生建议 2 到 10 的前期计算成本。而且这也会带来用户体验成本，因为这 10 个建议会将开发人员从其工作流程中拉出来，转入评估思维模式。Gazit 说：“这就像付费计算搜索引擎第二页上出现的结果一样，让第二页吸引你的注意力，尽管大多数人最终都会使用顶部的结果。”

优化成本是一个持续的项目，我们正在探索新的想法，以降低成本同时提高用户体验。

优化 AI 的负责任使用

优先考虑安全和信任。在 GitHub Copilot 的技术预览期间，反馈强调了建议安全代码的重要性。作为回应，团队集成了代码安全功能，以过滤可能包含安全漏洞（例如 SQL 注入和硬编码凭证）的建议，并使用 Azure OpenAI Service 的自然语言过滤器来过滤出冒犯性内容。

允许社区帮助你。在 GitHub，我们非常重视我们广泛的开发者社区对我们产品的反馈，并与他们合作改进我们的产品。对于 GitHub Copilot，我们的开发者社区对于理解 AI 潜力以及一些担忧至关重要。

例如，开发者社区担心 GitHub Copilot 的建议可能与公共代码匹配。作为回应，GitHub Copilot 团队创建了一个过滤器，以阻止与 GitHub 公共存储库中长度超过 150 个字符的公共源代码匹配的建议。

根据社区的意见，GitHub Copilot 团队还开发了一个代码参考工具，其中包含指向可能与 GitHub Copilot 建议匹配的公共代码的链接，以便开发人员可以审查潜在的匹配项（以及相关的许可信息），并做出明智的选择。

制定上市策略

与产品推广者一起推出你的产品。在 2021 年推出 GitHub Copilot 技术预览之前，团队向软件开发人员社区的有影响力的成员和 GitHub Stars 展示了原型。这使我们能够以现有的支持基础推出技术预览，并将技术预览的覆盖面扩展到更广泛的用户。

在追求企业用户之前先将产品呈现给个人用户。团队决定首先直接向开发人员销售许可证，这些开发人员显然会从 AI 编码助手中受益。我们将此方法与免费试用计划和基于用户调查结果的月度定价相结合，因为个人用户更喜欢简单而可预测的订阅。在个人用户中获得关注有助于建立支持基础，并推动企业级采用。

四.主要收获
我们仍然处于生成式 AI 的早期阶段，因此我们密切关注对这项新技术的需求和需要。虽然每个公司和产品都需要定义自己的方法来构建 LLM 应用程序，但以下是我们在 GitHub Copilot 产品之旅中的一些关键经验教训：
确定一个明确的问题并慎重地辨别 AI 的用途。这将确保你的应用程序具有更大的影响力和更快的上市时间。
将实验和紧密的反馈循环集成到设计过程中。在与 LLM 合作时，这一点尤为关键，因为输出是概率性的，而大多数最终用户正在学习如何与 AI 模型互动。
随着规模扩大，继续利用用户反馈并优先考虑用户需求。这将确保你的产品能够提供一致的结果和真正的价值。