GitHub Copilot：做出一个划时代的产品，只需要 6 个人

当前，Copilot 已经成为国内开发者常用的辅助工具。就像有的开发者评价称， “编码时，我希望干扰最少。在这方面，Copilot 给我提供了巨大的帮助。它减少了我可能花在网络上寻找解决方案的时间，而且它们在我最喜欢的 IDE 中触手可及。”Copilot 带来了很多便利。

虽然人工智能和自动化很早就成为开发者工作流程中的一部分了，但由 GitHub 和 OpenAI 开发的、基于云的人工智能工具 Copilot 让大家真正感受到了“智能”的力量。根据 Stack Overflow 最新发布的开发者报告，Copilot 如今是最受欢迎的开发者搜索工具。那这样一款“划时代”的工具是如何打造出来的呢？

六个人的默默研发

“我们差不多就是个臭鼬工厂（特指以秘密研究计划为主的项目），没有人知道我们。”GitHub Copilot 创建者之一的Alex Graveley回忆道，Copilot 是根据创业原则，由一个小团队在不到一年的时间里，在“非常不正常的 GitHub/MSFT 组织中”开发出来的。在这个团队里，开发者只有 6 位，此外还有一个 PM 和一个 VP 主要负责登陆页面和图标方面的工作。

Alex 不确定具体是从什么时候开始的，但当时 OpenAI 和微软已经就超级计算设施达成了协议，想要构建一套大型训练集群。他们还在制定另外的合作协议，可能会把 AI 相关条款引入 Office 和 Bing。GitHub 当然也不例外，他们想试试 AI 在开发中能发挥什么作用。

OpenAI 打算对模型做一点微调，看能不能用小模型更好地辅助编程。什么叫“小”模型？当时不团队里的人都不知道该把规模控制在怎样的程度，但能确定的是绝不搞得参数巨多、体量巨大。Alex 回忆道，这个“小”模型还没有 Davinci 大。

OpenAI 的基础模型就像是个训练工件。他们想把代码引入进去，看看自己的基础模型会作何反应。“我觉得这对思维链产生了积极的影响。毕竟代码推理具有明确的线性，而 AI 模型应该比较适应这种一件件事做下去、前一件事对后一件事产生影响的应用场景。”Alex 表示。

但刚开始的效果并不理想，甚至可以说相当糟糕。毕竟这只是一款底层工件，又遇上了 GitHub 上的一小部分数据样本。当时就只有 Alex 和另一位机器学习工程师 Albert Ziegler 在摆弄这套模型。他觉得虽然多数情况下都不起作用，但这套 AI 模型似乎正在积蓄力量。

最开始，他们投喂的数据只有 Python 代码，想据此让它做出有用的输出。“我们啥也不懂，所以就先从简单处入手，投身去试。看看这样行不行，看看那样行不行。坦白讲，我们根本不知道自己在干什么。所以第一项任务就是多做测试，看它能做什么。”

Alex 他们在内部众包整理出一大堆 Python 问题，这些都是肯定不会出现在训练集中的内容。之后他们开始挑选 repo 并设计测试，看看模型生成的函数到底能不能过关。基本过程就是要求模型生成相应函数，然后运行测试看给出的函数能否通过。

刚开始的通过率很低，大概是 10%的水平。之后团队开始给模型更多的尝试，试着让它慢慢摸索出解决思路。在其他独立测试中，Alex 他们还会编写测试函数，然后试着让它填充函数体。如果可以过关，就证明它确实有效。在野外测试中，他们会下载一个 repo 并运行所有测试，而后查看通过了哪些测试、调用了哪些函数、能否正确生成函数体，再重新运行测试看是否顺利通过。最后，把结果记录下来再核算百分比。

可以想见，前期测试的通过百分比是相当相当低。因此，团队开始把 GitHub 上的所有代码都投喂给模型，还引入了其他一些新的、起步阶段根本没想到过的技巧。最终，它在野外测试中的通过率从不到 10%提升到了 60%以上。换言之，随便给它两项代码生成测试，它基本就能通过其中一项。“这是个循序渐进的过程，从 10%到 20%，再到 35%和 45%，就这样慢慢提升。”

在探索过程中，团队还尝试提高提示词的设计质量，在特定环节上对它做出引导。这套模型接触到的可是代码的所有版本，而不只是最新版本，配合 diffs 让模型能理解不同版本间的微小区别。

“总之，它最后变得更好、更强。但至少在起步阶段，一切都只能从零开始，我们就像懵懵懂懂的孩子。唯一的想法就是，也许这东西终有一天能取代 Stack Overflow 以及其他开发工作流工具。”Alex 说道。

再前进一步

Copilot 的首个迭代版本只能算是一种内部工具，能帮人们编写一些简单测试。之后团队开始试着生成常用的 UI。“毕竟刚开始它生成代码的通过率只有 10%，而 UI 设计其实是个比较开放的问题，也许能回避 AI 能力不行的事实。如果成功那就太棒了。”

所以，接下来，团队开始对模型做微调和测试。另外，他们又想让他实现 VS Code 扩展的功能，比如说代码自动补全？当时的 Alex 觉得这应该没有问题，而向自动补全的探索也代表着巨大飞跃的来临。“虽然终极目标仍然是替代 Stack Overflow，但起步阶段我完全想不出这一切要怎么实现，先在 VS 里实现点功能才是真的。”

“作为我们的一小步，自动补全功能实现了，而且有趣且有用。它会像其他自动补全功能一样弹出一个提示框，供大家选择其中的字符串。这种使用形式便捷且容易上手，很舒服。我们还试过其他一些功能交付方法，比如在空函数上添加一个小按钮，由它为开发者快速生成；或者开发者可以点击控制键，再从弹出的大列表中随意选择。总之，我们几乎试遍了自己能想到的所有 VS Code UI。” Alex 说道。

虽然一切暂时还处于起步阶段，但它提供的推荐列表可以说“日新月异”来形容。毕竟这时模型只接触过小部分样本，所以仅可作为技术爱好者和测试设计人员的玩具。团队希望它能变得像 Gmail 的文本自动补全功能一样好用。

“我特别喜欢那款产品。那可是大语言模型的首次部署成果，速度很快、效果也很好。谷歌还专门发论文分享了具体技术细节和细节调整。我们就朝着这个方向努力，刚开始补全效果很不好，但却让人感觉它一直在朝正确的方向前进。就这样反复尝试和调整之后，终于拿出了一段小小的演示视频。” Alex 表示。

Alex 回忆称，当时团队每天工作 12 小时，克服阻碍，忽略最佳实践。当时只有 CEO、副总裁和团队的人相信这件事，其他人比较质疑。

微软推向全球的努力

在发布通用版之前，Copilot 已经开放过公测，免费供大家使用，而且针对不同群体做了很多优化。比如经验丰富的程序员会怎么用，新人开发者会怎么用，还有不同国家的地区的用户会有怎样的习惯和倾向。

Copilot 团队收集了一大堆统计数据，并意识到速度在任何群体中都是最重要的指标。“我们发现延迟每增加 10 毫秒，就会有 1%的用户放弃这项功能。另外在新功能公开发布的头几个月，印度的使用完成率是最低的——不确定为什么，但完成率确实明显低于欧洲。”

后来团队发现，这是因为 OpenAI 只有一处数据中心，而且位于美国得克萨斯州。可以想见，如果数据需要从印度穿过欧洲和大西洋再最终抵达得克萨斯，那来来回回的延迟肯定令人抓狂。这就会导致提示节奏和输入节奏脱节，功能完成率必然会受影响。

在找到症结之后，团队成员们也就释然了。而跟得州不远的用户们纷纷给出好评，比如有人会评论说，“我不会编程，但出于工作需要，我想了解怎么编写某个 100 行长的脚本。”事实证明，AI 模型特别擅长这种开发模式，而在找到模式之后，设计出来的 UI 就能派上用场。

后面就迎来了团队的“高光时刻”：发布成果，获得市场好评，然后尽快再更新和迭代。

“有客户表示，他们听说 Azure 打算在未来半年内全面承接 OpenAI，但他们等不及了，最好下个月就开放。”Alex 说道，团队当时就想办法满足这些要求，比如在欧洲和亚洲提供基础设施，把 AI 模型拉近到西海岸、得克萨斯乃至欧洲所有用户身边。微软在这方面投入了巨大努力，而在设施准备就绪并投入运行之后，Copilot 就这样正式跟大家见面了。

“没有 OpenAI 的天才和有原则的 VSCode 编辑人员，Copilot 是不可能的。”Alex 表示。

参考链接：

https://sarahguo.com/blog/alexgraveley

https://twitter.com/alexgraveley/status/1607897474965839872