AI 在产品开发中的角色 | Ryan J. Salva（GitHub 产品副总裁，Copilot）
The role of AI in product development | Ryan J. Salva (VP of Product at GitHub, Copilot)
嘉宾：Ryan J. Salva
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
本篇目录1 章节
§01文字稿 1§01文字稿 1
我们其实给 GitHub 的公开代码做过一份快照，就是我们所说的“北极代码库”（Arctic Code Vault），对吧？简单说，在芬兰北部很远的地方有一座种子库。我们当时想，你知道吗，种子库的作用是保存世界上植物的多样性，以防发生某种疯狂的天灾或人祸。但世界上另一项非常重要的资产，就是我们的代码，我们的开源。它实际上代表了现代世界相当大一部分的集体——嗯，至少是软件，如果不算智慧的话，对吧？
我们把这份公开代码仓库的快照放到银色胶片上，这些胶片将在北极代码库里保存数千年。而我们又拿着同一份数据快照去找了我们在 OpenAI 的朋友，想看看：好，用基于公开代码构建的大语言模型，我们能做些什么？结果发现，我们能做一些相当酷的事情。
Ryan Salva 是 GitHub 的产品副总裁，在他负责的诸多项目中，他孵化并推出了 GitHub Copilot，在我看来，这是你会遇到的最神奇的产品之一。如果你还没听说过它：它使用 OpenAI 的机器学习引擎，在工程师写代码时实时为他们自动补全代码。我认为这是我们近来在产品开发和生产力方面看到的最大进步之一。我一直很好奇这样一款大产品是怎么起步的，怎么争取到支持、积累势头，然后发布，尤其是在微软这样的大公司，尤其是像 Copilot 这样的产品，它面临着出人意料的伦理挑战、规模化挑战和商业模式问题。
另外，这个产品诞生于 GitHub 内部的一个小型研发团队，听 Ryan 讲讲他在大公司内部孵化大赌注、再把它们从原型推进到微软规模的心得，非常有意思。Ryan 作为一个人也特别有意思，他的背景非常不传统。我很期待你来听这场对话。好，下面有请 Ryan Salva。如果你正在搭建分析技术栈，却没有使用 Amplitude，那你在做什么呢？Amplitude 是全球最受欢迎的第一大分析解决方案，既被 Shopify、Instacart 和 Atlassian 这样的大公司使用，也被大多数科技初创公司使用。
Amplitude 拥有你需要的一切，包括强大且完全自助式的分析产品、实验平台，甚至还有集成的客户数据平台，帮助你以前所未有的方式了解你的用户。让你的团队用上自助式的产品数据，去理解用户、推动转化，提升参与度、增长和收入。抛开那些虚荣指标，信任你的数据，更聪明地工作，发展你的业务。免费试用 Amplitude，只需访问 Amplitude.com 即可开始。本期节目由 Athletic Greens 赞助。我几乎在我听的每一档播客里都听到过 AG1，比如 Tim Ferriss 和 Lex Fridman 的节目。
我今年早些时候终于试了一下，它很快成了我早晨例行流程的核心部分，尤其是在我需要深度写作或者录这样的播客的日子里。我喜欢 AG1 的三点是：第一，一小勺溶在水里，你就能摄入 75 种维生素、矿物质、益生菌和适应原。我喜欢把它看作我营养上的一张小小的安全网，以防我在饮食中漏掉了什么。第二，他们把 AG1 当作软件产品来对待。据说他们现在已经迭代到第 52 版了，并且根据最新的科学、研究以及他们自己做的内部测试不断改进。
第三，这是我每天都能做的一件简单的事，用来照顾好自己。现在正是夺回你的健康、用便捷的日常营养武装你免疫系统的时候。每天只要一勺加一杯水，就这样。你不需要为了关照健康而吃一大堆不同的药片和补充剂。让它变得简单。Athletic Greens 会在你首次购买时送你一年份的支持免疫的维生素 D，外加五份免费旅行装。你只需访问 AthleticGreens.com/lenny。再说一遍，是 AthleticGreens.com/lenny，掌握自己的健康，拿下终极的每日营养保险。Ryan，欢迎来到播客。
谢谢你，朋友。我真的非常兴奋能来这里。很高兴能和你一起好好聊聊技术。
我也很兴奋。录音开始前我们简单聊了几句，你提到了一点你的背景，对于一个领导 GitHub 产品的人来说，这背景非常独特。你能不能分享一下你在学校学的是什么，然后简要说说这是怎么引向你的产品管理职业生涯的？
哦哇！你这是要让我一路回忆到上学的时候。好吧。上学时，我不是典型的软件工程、计算机专业。比较深奥的说法是美学哲学和 20 世纪批判理论。更容易理解的说法是哲学和英语。但主要来说，这其实是关于我们人类如何彼此交流，我们如何通过创造力来表达自己。人类自古以来就在洞穴墙壁上作画，围着篝火跳舞，写故事、写小说，彼此歌唱。我只是对我们如何把自己对世界的体验传达给别人特别感兴趣。
我进入软件开发和产品管理，是因为我想从事创造力这个行当。我们正处在人类历史上一个非常非常独特的时刻，我们真的能亲眼见证一种全新媒介的出现。软件开发以及它所创造的世界，在大概 50 年、60 年前还是不可能的。如果我生在 1700 年代，我大概会是那个制造新颜色颜料和画笔的人，但我没有。我出生在 21 世纪之交前后，所以我从事工程。
这就是我过去二十多年一直在做的事，有时在初创公司工作，有的是别人的，有的是我自己的，在微软大约十年，现在在 GitHub 三年。
太棒了。我都不知道还有给画笔制造新颜色颜料这种工作。你会想出一种什么颜色呢？
哦天哪！碰巧是黄色……我想如果我做这行，我会做一种非常鲜亮的金色阳光黄。
非常积极、快乐。我喜欢。那可以成为 GitHub 的新品牌色。如今你是 GitHub 的产品副总裁。在那之前，你是微软一位非常资深的产品负责人，我一直很好奇这种转变是怎么发生的：从一个在大公司干了很久的资深产品负责人，转去承担像这样一个被收购的公司的角色。我好奇是什么让你决定迈出这一步，另外，在促成并想清楚这次转变的过程中，有没有什么有意思的内部运作值得一说？
是的，这个问题很好。就像我说的，我在微软的时候一直在做开发工具和开发者服务。具体来说，我负责的是他们所说的 One Engineering System（统一工程系统）的产品。它本质上是微软所有产品，比如 Windows、Office、Azure 等等共用的开发者基础设施，也包括微软的 DevOps 解决方案 Azure DevOps。收购发生时，很明显，围绕开发工具和服务的大量能量、大量关注点和创新，都将发生在 GitHub 周围。我是说，那里是社区进行创造的地方。
那里是人们学习的地方，是整个开发者社区的大量心智关注所在。就像我说的，我是有动力的。我在乎的是帮助人们创造。我很清楚，没有哪里比 GitHub 能让我产生更大的影响。我真的抓住了这个机会，从微软内部一个偏企业导向的角色转出来，去做各种事情，从 Copilot 这样的 AI 技术，到 Codespaces 这样的云端托管开发环境，还有代码仓库——在一个典型的年份里，地球上几乎每一位开发者都会以某种方式使用 GitHub 仓库。
这就是我想达成的：我怎样才能与社区建立更多联系，尤其是微软凭自身力量触及不到的社区。我想，这个决定也不仅仅着眼于 GitHub 当时是什么、现在是什么，也着眼于 GitHub 还可以成为什么。GitHub 有十多年、将近十五年的历史，通过代码仓库把开发者聚集起来协作写代码。但在最近几年里，我们真正把产品组合扩展到了开发者生命周期的许多不同环节。
我刚才提到了 Codespaces 和 Copilot，另外还有用于 CI/CD 的 Actions，以及高级安全功能。作为开发者，我们远不只是存放代码的地方。工具链上还有整整一大块。能有机会做这么多 V1 产品，这本身就是创造：能够从零构建一个全新的产品，把它推向市场，测试它，迭代它，并真正从社区反馈回来的能量中汲取养分。
太棒了。GitHub 确实散发着很多能量。我最想花大部分时间聊的，是你的团队参与推出并孵化的一款产品，也就是 GitHub Copilot。从我这个局外人的视角看，它像是软件开发领域近十年，甚至更久以来最大的进步之一。它绝对是市面上最神奇的产品之一，而你和你的团队可以说主导了 Copilot 的孵化与发布。
我很想把大部分时间用来聊这个。第一个问题……好，酷。我的第一个问题，是给那些不太了解 Copilot 的人的：它到底是什么？你能简单描述一下 Copilot 是什么吗？
好的，当然。过去 20 年甚至更久，开发者一直拥有的本质上是简单的智能自动补全。你敲一个句点，就会出现接下来可能用到的变量。它有助于你在代码中稍微快一点，有时也有助于记住某个方法或函数的语法大概长什么样。Copilot 本质上就是把这个能力放大到许多行代码。它是多行自动补全，其根本动力来自一个叫 CodeX 的 AI 模型，它是另一个你可能熟悉的模型 GPT-3 的衍生版本。
当你在编辑器里，可能是 VS Code，也可能是 IntelliJ，或者其他的，大体上在你打字的时候，Copilot 会给出建议，通常是以斜体灰色文字呈现，正如你所说，它能推断出来的东西真的有点神奇。基于周围的变量、类名、方法名以及你的注释，Copilot 推断你打算创建什么，然后希望能比较准确地命中，提供一段脚手架代码模板，供你在此基础上继续发挥。现在我们往往发现，开发者很喜欢它，非常享受。他们发现自己有点对它上瘾，因为它帮助他们保持心流状态。
作为开发者，我们喜欢处在那种状态里。我喜欢处在那种状态：我在创造东西，专注于某个产品、某个要交付给我的客户和用户的软件。而去记住某个 API 需要传入的参数顺序是什么，或者，嘿，我该做的这件事的具体语法是什么，或者哦，我得创建一堆虚拟数据，比如一周七天或者一年十二个月——这些只是劳作，不是创造，只是打字。
Copilot 通过把所有这些信息带进编辑器，帮助开发者保持心流，让他们不必去查文档、看教程或者去 Stack Overflow，在那里要么找到答案，要么更糟，得自己提问然后等人回答。它把这一切都带进了编辑器，并且常常给开发者多个建议供其选择，让他们挑选出哪个才是解决他们正在创造的东西所面临问题的正确方案。
太棒了。我最好奇的，也是我们要花时间聊的，是这样的产品如何在一家较大的公司里诞生。但在那之前，有没有人用 Copilot 写代码的最疯狂的故事？我先快速分享一个。我为了准备这次聊天看了一些 YouTube 视频，其中一个人——也许这就是 AI 写代码的图灵测试——他用 Copilot 来让 div 居中。他说：“哇！它做对了。”还有另一个人，他是编程讲师。
他做 YouTube 视频教人们写代码，他说：“Copilot 直接立刻就把答案给你了，所以我没法那么轻松地做这些视频了。我得把它关掉，这样它就不会直接把答案泄露出来。”我很好奇，你见过什么？
这样的例子太多了。我就说几个我最近听到的。我跟一位开发者聊过……其实他是一位教育工作者，他在教孩子们写代码，通常是高中年龄，比如 16 岁、15 岁那样。他的经历和我自己的相符：我们很多人学编程学得最好，不是靠随意设定的练习，而是靠真正去构建某个有用的、解决问题的东西。
他做的事情是，把需要开发内部工具的小型和中型企业，与一批学生班级匹配起来，比如一组大约六到八个学生，然后给这些学生提供 Copilot，并说：“给，这是一家小企业、中型企业。你们这组学生，去为这家企业开发这个内部工具。”
Copilot 本质上就是在学生耳边低语，比喻地说，“嘿，这个问题是这样解决的，这个是这样做的”，于是学生们不仅做出了企业所需的工具和软件，还能把它写进简历和大学申请材料里，同时他们还能通过使用这些工具来学习，而随着 AI 开始渗透我们整个技术栈，这些工具很可能在两三四年后成为开发者工具链核心基因的一部分。这是我最近聊到的一个相当酷的例子。
这太酷了。我之前没想到这里还有教育这个杠杆，让学编程变得容易得多，甚至不只是写代码。
正是如此，Copilot 的特别之处不只是减轻一些工作量，而且常常……学一门新语言是一回事，另一回事是深入一个你未必熟悉的代码库，对吧？我是说，天哪，有时候我连自己六个月前或一年前写的一些代码都认不出来。感觉像是涉足新领域。又或者你需要修复一个你不常碰的应用里的 bug，深入那个代码库就是在学习，并为这个代码库建立一张心智地图。
Copilot 在这方面真正神奇的一点是，这个 AI 会收集你要进入的应用的上下文。它能帮你建立那张心智地图、学会这个代码库，即使那是一门你已经熟悉的语言。
太棒了。回到 Copilot 的起点以及它是如何开始的，我一直很好奇，一个最终对大公司意义重大的项目是如何开始的，尤其是它如何积累势头、如何获得支持，并最终推出去。你能讲讲这个想法最初的种子吗，比如它来自谁，谁拥有最初的愿景，这个想法是如何出现并积累势头，直到你们为它投入资源的？
哦哇，这真是个很长的故事，而且，我不知道，取决于你的角度，可以说是曲折或令人兴奋的故事。微软和 OpenAI 在大语言模型上已经合作了相当长时间，这些模型被用到微软软件组合的各种不同实验和不同部分中，同时微软也通过提供必要的算力来帮助 OpenAI。训练这些模型需要海量算力。它们当时主要是大语言模型。几年前，我们渐渐意识到，语言模型不仅仅是英语、西班牙语、德语、韩语、日语，还有 Python、JavaScript、Java、C# 和 Closure（原文如此，疑为 Clojure）。
这些也都是语言。事实上，从 AI 的角度看它们还挺不错，因为它们在语义上相对受限，对吧？比如用 Python 能表达的词汇数量——我给“词汇”加了引号——比英语要小得多，英语有各种各样的语法规则，还有名词、动词、形容词、副词。我们开始探索，如果真的把代码引入这些大语言模型会是什么样。我最初接触到这件事的经过其实挺有意思。微软和 OpenAI 有了这个想法。
当时我负责的团队之一是 GitHub 的基础设施团队，也就是负责我们数据中心、可靠性和 rep time（原文如此，疑为 uptime，即正常运行时间）的团队。有一天我们注意到，我们正被猛烈冲击，我是说被海量的克隆请求绝对地猛烈冲击。我们想，“天哪！这是拒绝服务攻击吗？我们该如何应对？接下来会发生什么？”我们很快弄清楚，其实是 OpenAI。他们在克隆我们所有的代码仓库，从 GItHub 上收割数据。我是说，这是完全合法的做法，但确实会带来实际后果。
我们得以介入并很快缓解了这一情况。当时并没有发生可靠性或宕机事故，但我们说：“嘿，各位，很酷。我们喜欢这件事。看看能不能用一种更负责任的方式把数据给你们，用一种更贴合你们需求、打包得更好的方式。”我们做的是，就在那之前一年，我们其实已经为所谓的北极代码库（Arctic Code Vault）创建了一份 GitHub 公开代码的快照，对吧？简单说，在芬兰北部很远的地方有一座种子库。我们当时想，你知道吗，种子库的作用是保存世界上植物的多样性，以防发生某种疯狂的天灾或人祸。
但世界上另一项非常重要的资产，就是我们的代码，我们的开源。它实际上代表了现代世界相当大一部分的集体——嗯，至少是软件，如果不算智慧的话，对吧？它实际上代表了现代世界相当大一部分的集体——嗯，至少是软件，如果不算智慧的话。我们把这份公开代码仓库的快照放到银色胶片上，这些胶片将在北极代码库里保存数千年。而我们又拿着同一份数据快照去找了我们在 OpenAI 的朋友，想看看：好，用基于公开代码构建的大语言模型，我们能做些什么？
结果发现，我们能做一些相当酷的事情。就像从英语到西班牙语、从西班牙语到德语的翻译工具一样，你也可以从英语到 Python，或者从 Python 到 C#。我们觉得，好，这挺酷。我们不仅能得到翻译，还能得到一点预测文本。我想我们大多数人在代码编辑器里已经相当熟悉预测文本了，那就是 IntelliSense。但是，比如你打开自己最喜欢的文字处理软件，很可能那里也有某种预测文本在起作用。
我们开始尝试不同的用户体验，对吧？我们是否要让你右键点击，然后弹出一个小侧边栏，里面有一堆你可能想要的不同选项。那样不错，因为它能给你整个函数，但它不在光标处，对吧？你必须……即使你没有切换到另一个窗口，你仍然得切换到另一个面板，而这本身就有点分散注意力。我们最终想到了行内自动补全这个主意。
借助我们在微软那边一些朋友的合作，我们与 Visual Studio Code 的朋友合作，他们说，嘿，你们的编辑器里目前还没有针对这种多行自动补全的扩展能力，但我们有个关于它如何运作的想法。我们对它的实际呈现做了很多尝试。按键应该是什么？呈现层应该是什么？灰色斜体文字似乎是表明其临时性的好方式。很早的时候，我们就确定了这种用户体验，也就是大多数开发者今天所体验到的 Copilot。我想说那至少是 16 个月前，14、16 个月前。从那以后，我们把它带给了开发者。
我再确认一下，你是说不到一年半以前，这才真正作为一个项目开始，而现在它已经面向全世界了。是这样吗？
完全正确。完全正确。大约是一年半以前。
太疯狂了。从 OpenAI 差点搞垮 GitHub 到那个时间点，中间这段时期是怎么回事？
在 OpenAI 差点搞垮 GitHub 到我们真正确定用户体验之间的这段时期，坦率地说，一部分是 OpenAI 的许多非常聪明的研究人员在做实验，做只有世界级 AI 研究人员才能做的事。他们做了大量实验，偶尔要求更新数据集，然后把一个模型丢回给我们，让我们摆弄、调试。这些模型有数以千计的参数可以传入。当你真正思考 GPT-3 和 CodeX，以及从它们过渡到 Copilot 这样的产品时，这不仅仅是模型的事……
创建模型是一回事，但接下来要想清楚如何使用这个模型，也就是要调整哪些参数，要针对什么进行优化……一个很好的例子是性能，对吧？当你在代码编辑器里，你不会希望敲啊敲啊敲，然后得等一秒、两秒、三秒才得到一个建议，因为你的全部目标是保持心流。我们做过实验，看看多少毫秒才是合适的，使得开发者不会觉得被 Copilot 和它的建议打断。
答案是多少？
目前看来大约是 200 毫秒。取决于你身处世界的哪个地方，你的延迟可能比这个数字略高或略低。但似乎最佳点大概就在 200 毫秒左右。
好的，了解了。
我们还做了相当多的实验。这不仅关乎模型，也关乎你给模型喂什么。你如何提示模型，让它返回有用的回答？这开启了一段关于我们所说的“提示工艺”（prompt crafting）的实验之旅。
回到它的起因，听起来基本上是一次幸运的意外：OpenAI 做了一件你们没预料到的事。然后你描述的那个博士团队里有人说，“哦哇。也许我们能用这个做点真正好的东西。”事情大概是这样开始的吗？
相当准确。是的。我是说，我们当时有一个真的好得惊人的模型，在实际智能上是阶跃式的变化，对吧？然后把它与一个非常好的用例结合起来，这个用例真正改变了开发者在创造过程中的根本体验，也就是创作过程。
有没有某个时间点，你或者领导层整体明确觉得，我们应该加倍押注这件事，大干一场？还是说这个较小的团队在做这个想法，然后你们突然发现，“哦哇，这能行”？或者说一直就是“我们要押注这件事，这个想法太大太棒了，我们从一开始就一定会投入资源”？
GitHub 内部最初做 Copilot 的团队，是我们称为 GitHub Next 的团队。他们的工作本质上是做第二和第三地平线的项目。有些人可能称之为登月计划，对吧？这些东西我们从不指望在未来一两年内见效，但在三年、五年之后，可能真的会变成有意义的东西。
第二和第三地平线有具体的定义吗？是像亚马逊那样按多少年之后来定的吗？
不一定有具体定义。对我来说，我通常大致这样估计：第一地平线是未来一年，第二地平线是未来三年，第三地平线是未来五年。但我们通常更多地把它看作对模糊程度和信心水平的衡量，而不是日历上的日期。
本期节目由 Modern Treasury 赞助。Modern Treasury 是用于转移和追踪资金的新一代操作系统。他们正在为管理复杂支付流程的公司，对开发者工具和财务流程进行现代化改造。比如通过加密货币入口的数字钱包、共享出行市场、即时借贷等等。他们与 Gusto、Pipe、ClassPass 和 Marqeta 等高速增长的公司合作。Modern Treasury 强大的 API 让工程团队可以把支付流程直接构建进你的产品，而财务团队则可以通过简洁现代的网页仪表盘监控并批准一切。
Modern Treasury 的平台支持实时支付、自动对账、持续会计和合规解决方案，每月对账金额超过 30 亿美元。他们是当今市场上最火的年轻金融科技初创公司之一，获得了 Benchmark、Altimeter、SVB Capital、Salesforce Ventures 和 Y Combinator 等顶级机构的融资。欢迎访问 ModernTreasury.com 了解。我很想在这上面再多花点时间。这太有意思了。这是微软的做法吗，就是设有这三个地平线，并按一定比例的资源或赌注分配到不同的地平线上？
我会说，这不一定是微软的做法，但在 GitHub 肯定是我们对它进行具体化的方式。并不是说微软没有其他团队也可能使用这种方法，但我们可能更明确、更有意地做这件事的地方是 GitHub，我们在那里专门划出了一个团队来思考第二和第三地平线的工作，并让他们与 EPD 分开。这里的 EPD 指工程、产品和设计，也就是负责构建产品化、可运营的、我们推向市场并免费提供或以某种方式变现的产品的那些人。
这太有意思了。很多公司都有这类研发小组，Facebook 有新产品体验团队，Google 也有一个。我不确定这些团队里出过多少成功案例。据我所见，我很好奇，你有什么……而且据我目前所知，你显然取得了巨大的成功。关于如何在一家大公司内部投资这样的大登月项目，你有没有学到什么？
我是说，我认为第一步是要去投入。第一步真的是雇用非常聪明的人，吸引聪明的人，并给他们发挥创造力的机会。一开始不要指望他们做出的东西能变成摇钱树，或者要受制于安全、隐私、正常运行时间、无障碍这些乃至所有那些很酷的基本要求。他们需要创造和实验的空间。
而且，当你的团队确实有了一个想法，它明确地连接着一组有代表性的客户，这些客户有真实存在的问题，并且有至少中等信心的信号表明这个解决方案，无论它是什么，以一种新颖的方式解决了问题，那就是该开始考虑的时候了：好，我们来实际做一点……我姑且称之为市场测试。它并没有正式到可以叫市场测试的地步。其实就是，让我们开始把这个东西的原型拿给越来越多的客户看，试一试，看看，嘿，这真的在为你解决问题吗？这是你会用的东西吗？GitHub 内部从 Next 向 EPD 的过渡，就是从这里真正开始的。
这其实也是我在产品周期中的角色开始真正增加的地方。在那之前，我一直与 Next 团队保持紧密联系，关注他们的工作，也稍微做一些咨询。但正是在我们确认“好，这确实是真东西”的那一刻——客户在说，开发者在说，“这太神奇了。它做到了一些我自己做不到的非凡之事”——我们开始思考，好，我们怎么把它转交过来？从那里开始，我们就想，好，我们觉得这里有个爆款。我们觉得我们有了真正能带给开发者的东西。
我们有意做了一个决定：从 Next 团队中抽出一些研究人员，在一段有限的时间内，把他们调到一个新的 EPD 小队。我们希望他们仍然是研究人员，但我们需要进行知识转移，也需要为一个最终能够实现运营化和产品化的团队提供种子。这就开启了技术预览，我们开始邀请数万人，然后是数十万人加入技术预览。在这次技术预览中，我们开始看到各种震惊到头炸的表情符号推文，以及 Hacker News 上的帖子，人们对它感到非常非常兴奋。
这就是我们知道该开始扩大规模的信号，也是真正该开始思考如何招聘的时候，这样我们就能在这些研究人员周围建立一些隔离，让他们最终可以回到 GitHub Next 去做他们最擅长的事，也就是创新、创造，并思考下一个登月计划。这个过程花了……嗯，我们现在其实还处在尾声。就像我说的，我们现在是在产品最初创建大约一年半之后，已经经历了技术预览，达到了正式发布（general availability）。我们现在已经在他们周围组建了一个团队。
研究人员早在上个月就已经开始逐步回到 GitHub Next。现在是一个 EPD 小队，实际上是多个 EPD 小队，在推动产品向前发展，开始回应客户反馈，思考：好，作为一个产品团队，我们现在该如何把这份路线图从一个源自 GitHub Next 的想法继续推进下去？
我很喜欢这个洞见：让人一路跟着走，而不是简单地说“好，接下来由我们来”。如果你要再次在某个地方组建这样一支团队，也就是这种第三或第二地平线的研发团队，你还会有什么不同的做法吗？对于在大公司工作、想着“嘿，我们应该有这样的东西”的创始人或产品经理，你从这次经历中有什么经验教训？你觉得还有什么对让这类事情成功很重要？
把研究人员调回他们的研发团队，无论你的组织里那叫什么，调回的标准不能基于日历。必须基于接替者到位，也就是真正在做这份工作、并且掌握了所有必要技能的人，只有那时研究人员才能回去。在调走之前，确保你有专业知识、技能组合和领域熟悉度的连续性。我觉得我们今天在这点上做得相当不错。同样，至关重要的是，接手研发部门工作的团队要觉得自己能掌控自己的未来。你没法真的把路线图委托给一个研发团队。
负责维护产品、构建产品、与终端客户的反馈回路最近的团队，才是真正需要拥有路线图、并觉得自己掌控路线图的人。要确保你没有把创新完全外包给研发团队，而是在产品团队接手这个想法、这个用例和客户的过程中，创新也在产品团队内部发生。最后我想说的是，在很多方面，工程基本功就是区分研发团队和运营型产品团队的契约。
坦率地说，把这套基本功流程引入进来，对研究人员来说会觉得有点不自然。因此这需要一些文化变革管理，让每个人调整工作方式，并理解我们正从一个实验和研究项目升级为一个运营型产品。而且往往因为那些研究人员……他们是第一批过来的人。他们是这个项目的种子。这对他们来说会觉得有点不自然，而且他们可能并不具备完成这一转变所需的全部合适技能。
要确保你有一个好的搭配：既有习惯于维护服务的工程师，也有真正思考“我们创造出的想法是什么、我们带到市场上的新东西是什么”并能把这个愿景带进来的工程师和研究人员。
是的，我完全能想象其中的挑战……这是我的东西。我一直在做这个。你们对这个项目做了什么？它要往哪去？我不确定我感觉……然后又有各种新的要求朝你涌来，比如，天哪，这曾经那么有趣，而现在我得把这该死的东西规模化。
我是说，这是世界上最好的问题。说到客户的要求，尤其是 Copilot，涌进来的讨论量、客户反馈量，尤其是对我们做 AI 来说，坦率地说，世界仍在摸索 AI。我们在这方面进步很大，尤其是最近几年，有了 Dolly（原文如此，疑为 DALL·E）和 Copilot 这样的东西。但它带来的不只是工程挑战，坦率地说还有伦理挑战和法律挑战，比如搞清楚我们对 AI 的期望是什么。如果 AI 产生了冒犯性的内容，谁该负责？
我们的立场，我们最终得出的结论，实际上是把 Copilot 定位为 AI 结对程序员，我认为这是个有用的框架。结对编程，我想你们大多数听众都知道，通常是两个开发者并排坐着一起解决一个问题。一个人在键盘前，另一个人帮他把想法讲出来、讨论想法、纠正错误，诸如此类。那么，如果 Copilot 是你的 AI 结对程序员，而它在你耳边低语疯狂的东西，把政治带进来，或者把性别认同带进来，或者，我不知道，随便什么其他……
它们满口俚语、诽谤和诸如此类的东西。你大概没法专注于你的工作了，对吧？那会非常分散注意力。归根结底是要确立一些原则：我们要解决的用例是什么，与你并排坐着的 AI 机器人什么样的行为才是恰当的——我给“恰当”加了引号——这帮助我们为想要创造的开发者体验制定了一些原则或准则。
哦，我喜欢这个。就是为这个东西创建一个人设，来帮助你确定它的行为应该如何。你们是怎么处理这些挑战的？是你和法务团队的讨论吗？我想这些伦理问题肯定非常棘手。作为产品团队，你们是怎么处理的？
是与非常非常广泛的各种角色进行对话。就这个产品而言，我跟法务打交道的时间可能比我负责过的任何其他产品都多。他们都是很棒、很有创意的人。但不只是法务，还有隐私和安全方面的倡导者。坦率地说，还有开发者，也就是使用它的人，倾听他们的声音。嘿，这里什么管用？什么对你不管用？为什么这个有冒犯性？为什么那个没有？我们继续用那个在我们耳边低语疯狂内容的疯狂结对程序员的例子。我们刚开始的时候，在最最最早期，Copilot 上其实完全没有任何过滤。
后来我们想，好，它需要成为一个稍微更受控的体验。我们需要剔除一些最恶劣的内容。我们引入了一个简单的词语屏蔽列表，而这类屏蔽列表总是充满风险，比如哪些词可以，哪些词不可以。突然之间，我们成了语言的编辑者，这是个挺可怕的位置。至少我不太自在。但在某种程度上，这必须做，否则你会造成糟糕的开发者体验。
我们常常收到开发者的反馈，比如：“嘿，这个特定的词被屏蔽了。它被屏蔽这件事，要么冒犯了我，要么让我无法从这个产品中获得好的价值。”
天哪。
总是在跳着编辑内容这支舞。我们现在已经能够与 Azure 的负责任 AI 部门合作，他们创建了一些非常出色的模型，帮助检测我姑且称为情感倾向（找不到更好的词了）的东西，基本上就是当出现明显具有冒犯性的内容时。因为有些词在某些语境下可能是冒犯性的，而在另一些语境下可能完全合理，尤其是当你涉足医疗场景的软件时，对吧？
能够开始稍微转向去依靠那些比我们粗糙、简单的屏蔽列表做得更好的 AI 模型，这也许是另一个证据，既说明 AI 作为解决常见开发问题的方案，正在更好地解决我们技术栈中的更多部分或填补更多部分，也说明至少在我们这个案例中，我们相当幸运，能够交付或依赖母公司的贡献，来解决一个真正尖锐的问题，而 GitHub 靠自己可能解决不了。
我从没想过 Copilot 会……你们还得担心它说疯话。你们得处理这个，太离谱了。不就是微软曾经有个机器人变得非常负面，最终被关停了吗？
确实是。
所以那里有经验。
它叫什么来着？Talia 之类的？
差不多是这样。
对，差不多。我们可不想再来一次那样的事件。
哇。这让我想到，你的团队以这种应用的方式站在 AI 的最前沿。我好奇你怎么看这件事的走向，尤其是对开发者而言。我看到一个数据，说现在大约 40% 的代码是由 Copilot 写的。我不知道这对不对。那么未来的愿景会不会变成类似 90%？你觉得这一切会走向哪里？
具体说明一下这个数据，40% 是专指 Python 开发者的。坦率地说，它因语言而异。因为你可以想象，有些语言在公共领域的代表性比其他语言更好。而训练数据的数量和多样性通常与建议的质量相关，这种质量体现在写出的行数、接受率或其他若干指标中的任何一个上。
太好了。谢谢你澄清。
是的，当然。在所有不同的语言中，我们看到的范围是从二十几的高位到四十几。
顺便说一句，作为一个不算出色的工程师，我做过大约 10 年工程师，我欢迎我们的 AI 霸主来写我所有的代码。我很期待它做得越来越多。所以是的，我好奇你认为这会走向何方。
确实如此。它让像我这样平庸的开发者也能做一些相当惊人的事情。但它会走向哪里？首先，我想，我希望对大多数开发者来说这是显而易见的：在不远的将来，AI 将渗透我们几乎整个开发技术栈。Copilot 其实只是许多创新的冰山一角，比如更好地管理我们的构建队列，或者帮助……这里有个很好的例子。我不知道你怎么样，但我收到的提交信息和 PR 的说明往往不是特别好。这就让代码审查者要花很多力气去弄清楚开发者到底想做什么。
如果 AI 能结合你完整的请求来总结你所有的改动，而你作为贡献代码的开发者，只需要审阅一下确保准确，然后发出去，不必为此额外花力气，会怎么样？AI 有大量不同的机会，本质上能够从我们的工作中去掉一部分苦差事，让我们可以专注于创造性的行为。我从开发者那里听到的，以及我自己的体验是，Copilot 在某种程度上迫使我多思考一点：我想创建的设计模式是什么？
我用代码想要推动的最终用户体验或成果是什么？我可以依靠 Copilot 把其中很多部分搭出脚手架，这样我就能专注于更有创造性的工作。这才是我对五年、十年后我们这个行业真正的期望：不仅通过提供某种程度的抽象层，或者至少在开发中搭一把手，邀请更多的开发者、更多的人成为开发者，而且那些非常有经验的开发者可以专注于大得多的问题，专注于成果和创造力，而不是语法、参数顺序之类真正底层、困难的死记硬背。
太好了。至少，这会让人们不必再开着一个 Stack Overflow 标签页，把想弄明白的每个函数都复制粘贴过来。
我希望 Stack Overflow 继续经营下去，但我自己确实希望少一点上下文切换。
在把这个东西规模化的过程中，你觉得最大的挑战是什么，无论是技术上，还是运营上，就是把它扩展成人们愿意付费的真正产品？
这有几个方面。一个是非常属于我们这个时代的问题，也就是过去几年里供应链受到了剧烈冲击。事实证明，Copilot 无论是训练还是运行模型，都需要一些非常稀有、独特的 GPU，而全球的供应量并不多。一部分问题就是，我们能不能拿到足够的硬件来运行这些东西？我们实际上已经预留了相当多的容量，而且我们在全球范围内对更多容量贪得无厌、贪得无厌、贪得无厌。只要能生产出这些芯片并放进数据中心，我们就会这么做。
这是一种独特的挑战。我还要说，在运营方面，另一个挑战是，我们如何创造一个让社区真正觉得有归属感的模型，对吧？当我们把一个 AI 工具推向市场，尤其是一个用公开代码训练的工具时，必须进行的对话需要我们与社区之间大量的交流。每个好的产品经理都应该尽可能多地把时间花在客户身上，花在潜在客户身上。
Copilot 尤其是一次更复杂的推出，因为我们作为一个行业、作为一个社会，仍在摸索如何理解它。开发者与我们产品团队之间大量的往来交流，实际上要求我们扩充产品团队的规模，多于扩充工程团队。
有意思。为什么会这样？
有几个不同的原因。我是说，一方面，就像我说的，我们是用公开代码训练的。并不是整个社区都真的确定，什么时候可以用公开代码训练模型？什么时候不可以用公开代码训练模型？Copilot 给出的建议安全吗？Copilot 给出的建议有 bug 吗？有很多疑虑。也有很多非常健康的怀疑。其实我是真心这么说的。我希望人们对 Copilot 保持怀疑。作为一个社区，我们有责任对任何 AI 保持怀疑。
因为就像它有巨大的潜在益处一样，它也有巨大的潜在危害。人们让我们担起责任，比如，你们如何防止模型投毒之类的事情？围绕 AI，会不会出现一种我们还没真正想到的新攻击向量，造成负面后果？我们认为我们在这方面做得相当好、相当负责，首先是确保我们非常明确地表示：Copilot 不是开发者的替代品。它永远不会是。
我们不希望 Copilot 在键盘另一端没有一个会思考、会推理、活生生的人在做合理决策的情况下自动生成代码。我们不希望 Copilot 取代技术栈中的任何其他部分，无论是静态分析工具、你的单元测试，还是你今天为确保人类写出高质量代码而采取的任何措施。我们希望你保留所有这些同样的系统，以确保使用 Copilot 这类工具的人类继续写出高质量的代码。
但与此同时，有很多焦虑，比如，AI 的位置在哪里？AI 最终会不会……这又回到你关于五年、十年后我们会在哪里的问题。它会写 90% 的代码吗？我们不希望 Copilot 成为那样……我们不希望它取代任何东西。我们希望它增强。这里的想法实际上是，AI 是一个赋能者，让开发者能专注于创造性工作，保持心流，能够更快地前进。化解这些焦虑，化解这种健康的怀疑，需要交谈，需要对话。这就需要我们产品这一方与社区进行有引导的对话。
这感觉又连回了你当年的教育背景，哲学和文学。多方便啊？
经常觉得很有关联……我是说，教育那一面确实教会了我，对话的重要性和怀疑精神的重要性，其价值远不止于深奥的书斋空想。它在现实世界里真的适用。
在我们进入非常令人兴奋的快问快答环节之前，也许还有最后一个问题。
喔！
回顾这整段经历：一方面是在大公司里构建、孵化、推出这个大胆的赌注，你可以往两个方向谈：要么是关于大胆押注与渐进式胜利的任何经验教训，以及你如何考虑在这两类之间投入；要么是在大公司内部，如何构建这样一个从一个想法的种子发展成可能是大型新业务线的巨大新产品的经验。
作为产品经理，同时也是多个产品的组合管理者，我在 GitHub 负责多条产品线，时间、专注、精力和资源的分配成为一个非常具有挑战性的问题。这个问题的答案并不总是相同，取决于时间、世界形势、组织情况、技术情况。作为一般规则、一般原则，我当然会努力确保我们始终为大胆、无畏的实验性研究项目保留一些容量。你可以把那些真正不确定的赌注看作团队容量的 5% 到 10%。大约 25%，也许 30% 的团队容量一般应该放在日常运营上。
也就是如何让我们已上市的产品满足客户期望。然后剩下的部分，大概是 60% 左右，真正用于我们终端市场产品的渐进式进步。我们如何做迭代式改进，并持续真正兑现我们一、二、三、四年前所下的更大赌注带来的回报？从粗略的分布来看，我通常就是这样运作我较大的团队的。不过这在你有较大团队时才行得通。在初创公司，我们基本上就只有一个大赌注，显然你的百分比会非常不同，变成你把一切都押在那张俗话说的彩票上。
太棒了。谢谢你的分享。我本来想问你推荐的比例是多少，谢谢你主动讲到了。接下来，我们进入非常令人兴奋的快问快答环节。我会简短地问你五个问题，你想到什么、有什么答案都行。我们开始吧？可以吗？好。有哪两三本书是你最常推荐给别人的？
哦，好问题。其中一本是关于用户体验的书，叫 Make It So。它指涉的是《星际迷航》，核心想法本质上是：科幻作品中呈现给我们的用户体验，常常会在二三十年后进入我们的日常产品和工具。这是一本很开眼界、很有启发，而且非常好玩的书。这是一本。然后换个完全不同的角度，我从科技之外选一本，纯粹看娱乐价值。有一本 David Foster Wallace 的书叫 Brief Interviews with Hideous Men，我很喜欢。它是一本短篇小说集。
本质上，就像你在看电影时，反派有机会发表他的大段演讲，解释他为什么成为现在这样的人，这让他在那一刻也许有点脆弱，这本书就是把那种演讲针对不同的可憎之人、可怕可怕的人重复了十遍。读起来很有意思。我推荐。
我喜欢。这让我想起一本书，是关于独裁者的室内设计，里面展示了萨达姆·侯赛因、希特勒这些人的住所。
老兄！天哪，太棒了。我得找到这本。你得发给我。
我是在一家旧书店找到的，二手书店。我不知道它们现在还在不在，但我会找到的。第二个问题。有没有你喜欢听或者推荐的其他播客？
哦天哪，太多了。我每个月要听几百个小时的播客。太疯狂了。我可以选很多。我只说一个。Nate DiMeo 主持的 The Memory Palace 是一档出色的讲故事播客。他做大约 20 分钟的小片段，通常选自美国历史。他还曾是华盛顿特区某家博物馆的驻馆艺术家。如果你去过，我想是美国历史博物馆之类的，如果你去那里，你可以走进博物馆的不同房间，他会给你讲你在那里看到的物品或房间的故事。那是一种神奇的体验，推荐给任何人。
哇！我喜欢这些。最近有没有你特别喜欢的电影或电视剧？
我不知道这算不算最近，但这是我最近看的一部，Arrival（《降临》）。对，这算。《降临》。表面上是关于外星人的电影，但其实是关于语言和记忆。我觉得它非常非常引人入胜。
你读过 Ted Chiang 的书和短篇小说吗？
没有。没有读过。
哦哇！哦，你会喜欢的。《降临》出自他的一篇故事，我相信，还有一整本书收录了同一位作者的更多短篇小说。它们太棒了。
太好了。那我这个周末有安排了。
就是这样。下班就去读吧。你在面试中喜欢问的一个面试问题是什么？
让我想想。我给你一个有趣的，而不是有挑战性的。这是我的破冰面试题，尤其是针对职业早期到中期的产品经理。我让他们在一分钟内教我一样新东西。通常我会拿出手机开始计时。我会给他们一秒钟想一想，然后开始计时。他们按三条标准被评分。第一是完整性。他们是否真的在一分钟内完成了这节课？第二是复杂度。如果你教我的是，比如，一边拍头一边揉肚子，那是一回事。
如果你教我的是关于 18 世纪的 ardent（原文如此，疑为 art，即艺术）与当时宗教潮流之间的联系，那是另一回事。最后是清晰度。哦对，清晰度是最后一条。清晰度就是，我是不是真的理解了？到课程结束时我是不是学到了东西？他们是否完整、全面地传达了这个想法？
我得问一下，在这个问题里，有人教过的最有意思的东西是什么？
我那个顺口举的例子，也就是他们有没有教我关于 18 世纪艺术及其与当时宗教潮流联系的东西，有人真的教了我这个。太惊人了。那其实是一位大学生候选人，也就是还在上大学的人，她来自范德比尔特大学。
那是强烈的“录用”吗？
是极其强烈的“录用”。她太棒了。是那么聪明的人。
太棒了。最后一个问题，业内你最尊敬的思想领袖或有影响力的人还有谁？
有很多，但我想今天如果我不说 Uga Damore（原文如此，人名拼写可能有误），我会责备自己。Uga 是主要的研究员，真正是 Copilot 的真正创新者。他应该为最初的工作获得认可，他是一位杰出的技术专家和未来学家。我真的非常非常尊敬他。
太棒了。很酷的点名。Ryan，这次聊得太精彩了。你们站在这么多有趣工作的最前沿。老实说，我迫不及待想要用于我的通讯的 Copilot，这样我可以少干点活。也许有一天会实现的。不管怎样，我很期待看到这一切走向何方。感谢你来到这里。最后两个问题。如果听众好奇想了解更多、想联系你，可以在网上哪里找到你？还有，听众有什么办法能帮到你吗？
简单。大家怎么找到我？我在各处都是 Ryan J. Salva，Twitter、GitHub，随便选。LinkedIn 上也是 Ryan J. Salva。然后大家怎么能帮到我？请大家去试用，Copilot 有 60 天的免费试用，人人都可以领取使用。去试试。试用之后，请在 Twitter、Hacker News，或者 GitHub Discussions 讨论区发布你的体验。
给我们好的反馈。也给我们坏的反馈。我非常渴望看到人们如何以新颖的方式使用它，也想知道他们在哪里碰到了粗糙的棱角。就像我说的，我们还有很大的成长和改进空间，但我相当有信心，开发者会对它现在已经能做到的事情感到相当惊叹。
太棒了。谢谢你来，Ryan。
好的，老兄，非常感谢你。真的非常非常有趣。
非常感谢收听。如果你觉得本期内容有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。也请考虑给我们评分或留下评论，这真的能帮助其他听众发现这档播客。你可以在 lennyspodcast.com 找到所有往期节目，或了解更多关于本节目的信息。下期再见。