深入了解我们如何使用生成式 AI 模型进行创新实验，从而拓宽 GitHub Copilot 在开发者整个生命周期中的应用。
今年伊始，无论是新闻头条还是闲聊话题，“生成式 AI”这个词汇几乎无处不在。尽管 2023 年成为了生成式 AI 应用的里程碑年份，但这项技术并非崭新之物。事实上，人工智能自 60 年代就开始萌芽，而我们今天所了解的 AI 形态，则是随着神经网络——一种机器学习框架的发明而发展起来的（更多相关信息可以点击这里查看）。
在 GitHub，我们过去几年一直在尝试使用生成式 AI 模型来创造对开发者有实际帮助的新工具。正是这些尝试催生了 GitHub Copilot。自 2021 年 GitHub Copilot 首次亮相以来，我们深入思考了生成式 AI 如何赋予开发者在软件开发生命周期的每个环节更高的生产力。这种思考促成了我们对 GitHub Copilot 在 AI 驱动的软件开发未来中的角色 的设想，我们在 2023 年 GitHub Universe 大会上对此进行了详细阐述。
在这篇博文中，我们将分享过去几年中围绕生成式 AI 模型所进行的各种实验，以及从这些实验中获得的关键经验。我们还会探讨如何将一个全新技术从概念阶段转化为实际产品。
GitHub 在 AI 实验中的四大支柱
开发者越来越依赖 AI 工具来提升工作效率。在 GitHub，我们围绕四大核心原则进行 AI 实验，以塑造开发者的 AI 使用体验：
- 可预见性。我们旨在打造的工具，应引导开发者顺利达成目标，同时避免给他们带来意外或压力。
- 容错性。我们知道，AI 模型有可能出错。用户应该能够轻松识别错误的建议，并且在不影响注意力和效率的前提下对其进行纠正。
- 可控性。如果 AI 的回应不准确或不符合用户需求，用户应该可以轻松引导 AI 找到正确的解决方案。否则，我们就只能过分乐观地期待模型给出完美的答案。
- 可验证性。解决方案必须易于评估。尽管模型不是完美的，但在用户验证了它们的输出后，它们可以成为非常有帮助的工具。
了解了这些 AI 实验的优先考虑因素后，我们接下来探讨一下导致 GitHub Copilot 最新进化的重要事件。
在 GitHub Copilot 演进之前是 GPT-4
去年，GitHub 下一个研究院（GitHub Next）的研究人员有幸提前接触到了 OpenAI 即将发布的大语言模型（LLM）GPT-4。
“那时候，这种事还闻所未闻，”GitHub Next 的高级研究总监 Idan Gazit 回忆道。“大家都在争先恐后地探索新模型的能力，想看看哪些今天能做到、昨天做不到的应用会出现。”
于是，GitHub Next 团队开始了他们最擅长的实验工作。在接下来的几个月里，他们利用 GPT-4 模型开发了一系列可能应用于 GitHub 各个平台的新工具和特性。一旦确定了哪些项目真正有价值，他们便开始了快速开发。
“就像 GitHub Next 一贯的做法，我们坐下来迅速提出了许多点子，看看哪些让我们感到兴奋或有前景，”Gazit 解释道。“然后我们就全力以赴，专注于那些我们认为能够结出硕果的方向。”
在从接收模型到 2023 年 3 月预定的模型发布公告的这段时间里，团队提出了多个概念和技术预览。
“那时候，这种事还是闻所未闻。我们都在赛跑，看谁能首先发现新模型能做什么，以及哪些新应用今天可能成为现实，昨天还是不可能的。”
– Idan Gazit, 高级研究总监 // GitHub Next
随着这些项目逐渐成型，GitHub 的高层领导开始考虑这些对 GitHub Copilot 未来的意义。产品管理副总裁 Mario Rodriguez 表示，“我们想要在 Microsoft 和 OpenAI 共同宣布 GPT-4 之际，发布我们自己的声明。那时，GitHub Next 正在进行的一系列投资我们认为非常适合用来做这个宣布。这些投资尚未准备好投入生产，更多的是对未来的投资。”他补充说，“但这启发了我们，我们便动笔规划了 GitHub Copilot 最新演进 的宏伟蓝图。”
展望未来 🤔
GitHub 团队在思考如何让 GitHub Copilot 超越集成开发环境 (IDE) 中辅助编程的角色时，他们构想了一个未来愿景：GitHub Copilot 将变得：
- 无所不在，深入到开发者使用的每个工具和完成的每项任务中。
- 默认以对话形式存在，让自然语言成为实现各种功能的通道。
- 根据具体情况个性化调整，适应个人、项目、团队乃至社区的不同需求和知识背景。
这样的思考，加上 GitHub Next 团队为了设计和打造能够彻底革新开发者工作流的新工具所做的工作，共同铸就了 GitHub Copilot 最新进化版的雏形。2023 年 3 月 22 日，GitHub Copilot 的技术预览版发布了，展示了它将如何进化，其中包括 GitHub Copilot 聊天版 以及 GitHub Next 打造的以下技术预览：
- Copilot for Pull Requests
- Copilot for Docs
- Copilot for CLI
那么，这些技术预览背后是怎样的故事呢？一起来探索吧。
探索 AI 在开发者体验中的应用
对于大多数开发者来说，谈到 GitHub 独有的特色，”拉取请求”（pull requests）绝对是不可或缺的部分。拉取请求不仅是代码协作的关键环节，也是团队审查和批准代码变更的重要通道。
当 Andrew Rice、Don Syme、Devon Rifkin、Matt Rothenberg、Max Schaefer、Albert Ziegler 和 Aqeel Siddiqui 接手 GPT-4 模型时，他们面临的挑战是探索如何将 AI 技术融入 GitHub.com。
Rice 说：“既然 GitHub 创造了拉取请求，我们就开始思考如何在这一功能上加入 AI 元素。我们尝试了多种方法：为代码审查提供自动化建议、开发总结模式，还有一些与测试生成相关的尝试。”但随着 3 月 22 日的最后期限临近，一些原型功能并没有达到预期效果。因此，Rice 和他的团队转而全力以赴，专注于开发总结功能。
在 Copilot for Pull Requests 的初期版本中，开发者提交拉取请求后，AI 模型会在第一条评论中自动生成代码的描述和解读，为审查者提供关键的上下文信息。
“我们和 Hubbers 一起对这个功能进行了内部测试，但效果不太好，”Rice 笑着说。问题不在于开发者不认同这个功能的目标，而在于用户体验上遇到了挑战，Rice 认为这是关键。 “开发者担心 AI 的准确性。但问题其实有两个层面：一是 AI 生成的内容本身，二是这些内容如何展示给用户，以及它们如何融入到工作流中。一开始，我们主要关注 AI 生成的内容，但后来发现，第二个方面在实现目标上更加关键，”他解释说。
为了解决这个问题，Rice 和他的团队决定调整策略，使用同样的 AI 生成内容，但以不同的方式呈现。 “我们不再将其作为一条评论，而是作为一个建议呈现给开发者，让他们预览拉取请求的描述可能会是什么样，然后他们可以对其进行编辑，”Rice 说。“因此，我们转向建议系统，突然之间，反馈变成了‘哇，这些建议真是太有帮助了。’虽然内容和之前完全一样，但展示方式的改变带来了全新的体验。”
没有人是完美的 – 甚至是 AI
Rice 指出，在这个过程中一个关键的发现是，向开发者展示 AI 输出的方式比提供建议的绝对准确性更加重要。这并不是说 AI 完全出错是可以接受的，而是意味着开发者对建议质量的要求有不同的层次 – 他们会根据建议如何融入他们的工作流程来判断，而不管这些建议具体是什么。当建议以一种可以由开发者接受和编辑的方式呈现时，他们对这一功能的看法也随之改变。
GitHub Copilot 另一个功能的主要研究员 Eddie Aftandilian 在开发 Copilot for Docs 过程中也有类似的体会。2022 年晚些时候，Aftandilian 和 Johan Rosenkilde 在研究嵌入和检索技术时，他们为一个不同的 GitHub Copilot 实验制作了一个向量数据库原型。“我们开始想，我们能不能用这个来检索不仅仅是代码的其他内容，”Aftandilian 回忆说。“当我们开始使用 GPT-4 后，我们意识到可以利用这个检索引擎搜索大量文档，然后把搜索结果组合成一个提示，以此来得到更好、更相关的基于文档的回答，”他解释道。
Aftandilian 表示：“鉴于 GitHub 是关于开发者工具的，我们思考如何将其转化为对开发者有用的工具？”他指出，开发者花费大量时间翻阅文档来寻找解决方案，而且“没人真的喜欢阅读文档”。他补充说：“从文档中找到正确答案有时也很困难。因此，我们看到了一个机会，可以直接回答开发者的问题，帮助他们解决难题。我们认为这是开发过程中一个尚未充分探索的领域。我们花了大量时间搜索答案，这是一个明显的难点，我们相信利用这些新的大语言模型 (LLM) 我们可以做得更好。”
Aftandilian 和他的团队成员 Devon Rifkin、Jake Donham 以及 Amelia Wattenberger 将 Copilot for Docs 的初版应用于 Hubbers，这一举措扩大了 GitHub Copilot 在内部文档及公共文档中的使用范围。然而，当这个预览版进入公众测试阶段后，他们收到了一些关于 AI 输出品质的有趣反馈。
Aftandilian 解释说：“在开发过程中，我们发现一个挑战：有时模型并不能总是提供正确的答案或文档。”为了解决这个问题，他们增加了一项功能，让输出结果能提供相关文档的参考或链接。他们发现，只要输出结果能够通过链接的参考资料帮助用户更容易评估 AI 的产出，开发者们就不太介意结果是否总是百分百正确。实际上，他们开始将 Copilot for Docs 当作一个搜索引擎使用。
用户体验需要容忍 AI 的错误 – 不能期望 AI 永远正确。
– Eddie Aftandilian，主要研究员 // GitHub Next
Aftandilian 还意识到，人类反馈是开发 AI 工具的关键。他说：“我们得出的结论之一是，应该尽早发布产品，以便通过真实的人类反馈来推动产品改进。”
正如 Rice 先前提到的，用户体验对于这些 AI 工具的成功同样至关重要。Aftandilian 表示：“用户体验需要能够容忍 AI 的错误 – 不能期望 AI 永远正确。我们最初的目标是确保一切准确无误，但很快我们就意识到，Copilot for Docs 的对话式互动让回答显得不那么权威，而当这些回答能够指引用户朝着正确方向时，用户对回答的容忍度也会提高。AI 或许不是完美无缺，但它已经是一个很好的开始。”
小巧而强大
2022 年 10 月，GitHub Next 的整个团队在英国牛津聚集，一起讨论他们正在开展的项目以及一些激动人心的创新想法，其中有些看似遥不可及。
“我在这次头脑风暴会议上提出的一个想法是，使用大语言模型 (LLMs) 来帮助用户理解 CLI（命令行界面）命令，”GitHub Next 的首席研究员 Johan Rosenkilde 回忆说。“我构想的是一个工具，它能用自然语言提示你想在命令行中执行什么操作，然后通过一个图形界面或其他接口帮你确定具体操作。”
正当 Rosenkilde 展示他的构想时，他的同事 Matt Rothenberg 开始编写一个应用，几乎完全实现了这一想法。“我讲完后，他问我是否想看看他做的东西，我简直不敢相信自己的眼睛，”Rosenkilde 笑着说。那个只用了三十分钟制作的原型，最终演变成了 Copilot for CLI。
“他展示的成果明显具有价值，当然，那时它还不够成熟，”Rosenkilde 补充道。“因此，我们花了时间将这个初步的演示改进成一个可以交给开发者的成品，”他说。到了 2023 年 3 月，他们推出了一个预览版，将 GitHub Copilot 的强大功能带到了 CLI，让开发者能够迅速获得他们所需的 shell 命令，且每个命令都附带详细解释——免去了在网上寻找答案的需要。
在回顾这个应用从初步构想到技术预览的发展过程时，Rosenkilde 对于用户体验决策的细微之处表示赞赏，这与 Rice 和 Aftandilian 的观点不谋而合。
Rosenkilde 讲到：“我主攻后端，特别是喜欢那些理论深奥、难题重重、需要我花上几周时间去思考的问题。Matt 则是擅长用户体验（UX）的高手，他能在众多选择中迅速找到最佳方案。我们这个应用的成功极大程度上依赖于 UX，这是我学到的宝贵经验。在 GitHub Next，我们做的一切核心就是创造能够提升用户体验价值的工具，所以设计的准确性和与 AI 模型的匹配度至关重要。我们都知道 AI 模型并不是完美无缺的，但即便如此，我们也要尽量减少给用户带来的不便，”Rosenkilde 如是说。
正是这一简单的事实，激发了 Copilot for CLI 中‘解释字段’的创意。“最初这个功能并不在我们的设计中。随着产品的不断成熟，我们加入了这个解释字段，但在让大语言模型（LLM）生成我们想要的那种结构化解释时遇到了难题。要让语言模型产出这种东西非常不自然，我不得不使出浑身解数，”他半开玩笑地说。“我们想要的是结构清晰的解释，但如果仅仅让 AI 解释一个 shell 命令，它只会给出一大段文字，既不易于快速阅读，也可能漏掉你需要的细节。”
Rosenkilde 还认为，添加这个解释字段对于帮助开发者学习 shell 脚本、核对他们接收到的命令是否正确非常重要。“它还是一个安全功能，因为你可以用自然语言阅读并了解命令是否会意外改动你不希望更改的文件，”他补充道。这个多用途的解释字段不仅实用，还体现了应用的优秀用户体验。“对于这样一个小型应用来说，你会希望每个功能都能有多种用途，这样就能在外观简洁的同时，包含丰富的功能性。”
我们的目标 🚀
我们致力于创造一个伟大的目标：为所有与 GitHub 平台互动的用户提供令人愉悦的 AI 体验。在这个旅程中，我们诚挚邀请您加入我们，共同参与这个过程。您可以通过加入我们当前预览版本的等待列表来参与，同时，我们期待收到您对于产品的真实反馈以及对我们未来发展方向的期望。
如果您还未体验过 GitHub Copilot，不妨尝试一下专为个人开发者准备的 30 天免费试用版。
