软件开发中 AI 的未来 | Inbal Shani(GitHub 首席产品官)

00:00使用 AI 工具开发软件的人,需要形成一种不同的思维方式。你需要开始弄清楚,该如何使用这些 AI 工具来帮助自己取得成功。这不再只是实际编写代码,而是真正把你的思考演进到全局视角、连贯的体验、相互连接的系统,而这些在今天更多出现在资深开发者身上,在初级开发者身上则越来越少。(00:24):初级开发者刚入行时,我们通常期望他们能写出简单的代码。但如果现在有一个 AI 系统帮助他们写代码,他们从一开始就可以花更多时间去理解系统、理解他们正在构建的环境,或者理解他们正在构建的产品,而今天他们没有这样的时间,因为他们还在学习如何写代码。

00:46今天我的嘉宾是 Inbal Shani。Inbal 是 GitHub 的首席产品官,此前曾在 AWS 和微软担任总经理,还曾在 Amazon Robotics 担任高级软件开发工程师。(00:58):在我们的对话中,我们探讨了 Copilot 以及基于 AI 的软件工程师工具的最终形态,AI 时代软件开发的未来是什么样子,在 AI 与软件开发领域哪些被过度炒作、哪些被低估,团队用哪些指标来判断 Copilot 是否发挥了作用,团队和公司在投入 AI 时会犯哪些错误,Copilot 的设计理念,以及是什么帮助 Inbal 成为今天的领导者,还有 GitHub 作为产品和组织将走向何方。(01:27):接下来,在听完赞助商的简短介绍之后,我为大家带来 Inbal Shani。你爱上打造产品是有原因的,但日常现实有时和你想象的有点不一样。你本该梦想着宏大的创意、与客户交流、制定战略,结果却淹没在电子表格和路线图更新里,每天基本都在救火。其实有更好的办法。隆重介绍 Jira Product Discovery,这是 Atlassian 为产品团队打造的全新优先级排序和路线图工具。(01:59):借助 Jira Product Discovery,你可以把所有产品创意和洞察集中在一个地方,自信地排定优先级,终于告别那些没完没了的电子表格,几秒钟就能创建并与任何相关方分享定制的产品路线图,而且这一切都构建在你的工程团队已经在使用的 Jira 之上。因此,真正的协作终于成为可能。伟大的产品是由伟大的团队打造的,而不只是工程师。销售、支持、领导层,甚至财务部的 Greg,任何你希望参与的人,都可以在 Jira Product Discovery 中免费贡献想法、反馈和洞察。(02:32):没有附加条件。而你自己每月只需 10 美元。告别你的电子表格和永无止境的对齐工作吧。旧的产品管理方式已经结束。用 Jira Product Discovery 重新发现各种可能。请到 atlassian.com/lenny 免费试用。就是 atlassian.com/lenny。本期节目由 Sanity 赞助播出。你的网站是增长引擎的核心。要让这台引擎带来巨大成果,你需要能够超快速地行动:发布新内容、做实验、学习并迭代。(03:06):但大多数内容管理系统根本不是为此而设计的。你的内容团队在搭建新页面时要与僵化的界面搏斗。你要花无数时间在各个页面之间复制粘贴,并为其他渠道和应用重新制作内容。而当开发者无法在过时技术的限制下实现时,他们关于新实验的想法就被扼杀了。Figma、Amplitude、Loom、Rightgames、Linear 等具有前瞻性的公司,都在使用 Sanity 打造可扩展、推动创新并加速获客的内容增长引擎。(03:36):有了 Sanity,你的团队可以梦想得更大、行动得更快。作为市面上功能最强大的无头 CMS,你可以根据自己的业务定制编辑工作流,在任何页面渠道之间无缝复用内容,并在没有开发者阻力的情况下把你的想法推向市场。Sanity 让你整个团队的工作都更轻松。开发者用它构建很快,内容管理者用起来很直观,而且能与你技术栈的其余部分无缝集成。从 Sanity 慷慨的免费方案开始吧。(04:02):作为 Lenny's Podcast 的听众,你还可以获得月用量翻倍的加强方案。请前往 sanity.io/lenny 免费开始。就是 sanity.io/lenny。Inbal,非常感谢你来到这里,欢迎做客播客。

04:22太好了。谢谢你邀请我,我很高兴来到这里。

04:25我想先问一个关于软件开发走向的宽泛问题。感觉你正处在软件开发变革风暴的中心。几乎可以说,是 GitHub 随着 Copilot 的发布掀起了这场风暴。那么我想问,在软件开发正在发生的变化中,你觉得哪些被过度炒作了,哪些又被低估了?

04:46我是一年前以首席产品官的身份加入 GitHub 的。两天前,我刚过完入职一周年。对我来说,最初的做法是先审视这个平台,审视软件开发生命周期,并形成一些信念。而对我来说,最大的信念是:开发者的幸福感和生产力在很大程度上取决于他们的环境和开发工具。因此,AI 对这一使命至关重要。(05:11):看看现在 AI 的发展情况,它在开发者的期望中已经成为基本门槛,对他们完成工作而言真正处于核心且关键的位置。我们知道,大约 92% 的开发者已经在使用 AI 工具。但在这样的格局中,被过度炒作的一点是,生成式 AI 将取代人类。我认为这在可预见的近期不会发生。在我看来,你始终需要有人参与其中,因为 AI 无法取代创新。(05:45):那种创造性的火花、那种创造性的思维是人类的核心,至少在不久的将来,这不会被 AI 取代。如果我们思考一个成功的 AI 工具意味着什么,你需要数据。要产生数据,就需要人去使用工具、与工具互动、做点什么。所以我认为,现在被过度炒作的是生成式 AI 将取代人类,以及它将成为一切问题的解决方案,而我认为它只是一个工具。(06:15):如果再具体谈谈目前在软件开发领域被低估的东西,我开始听到多一点关于 AI 驱动测试的声音,但相关提及还不多。如果我们想想 AI 的世界,我们将生成多得多的代码,生产力更高,效率更高,有更多的代码行、更多的应用,那么测试就成了这段软件开发旅程中极其关键的一环。(06:43):我希望听到更多这方面的讨论,听听各家公司在思考如何利用 AI 生成更大规模的测试套件,以验证工作成果。

06:53你说的测试是指单元测试、集成测试之类的吗?

06:57所有这些,负载测试、负载测试、基础设施测试、安全测试、渗透测试。如果需要人来编写所有这些测试能力,你就需要很多人,而这需要形成不同的思维。我们能否利用 AI 来真正生成这样一套测试套件,测试你所需要的一切,从单元测试、功能测试到负载测试、性能测试?(07:23):我们做的很多测试,我们甚至没有把它们当作测试,所以也不一定会花很多时间去做。但如果我们现在说软件处于一切的中心,所有公司都将以某种形式成为软件公司,那么生成的代码会更多。因此,测试的重要性变得关键得多。

07:43我们顺着这个话题继续。你谈到你不认为软件工程师会完全消失。那么三到五年后,软件开发会有什么不同?你认为会有哪些不一样?另外,对于 Copilot 和类似工具越来越好、越来越好,你怎么看这一切的最终形态?你觉得它最终会走向何处?

08:02对我来说,我也一再强调,Copilot 是副驾驶,不是机长。你仍然需要有人参与其中。但这意味着,现在软件开发者,也就是使用 AI 工具开发软件的人,需要形成一种不同的思维。第一,你需要开始更多地从系统、从架构的角度思考。你需要开始弄清楚,该如何使用这些 AI 工具来帮助自己取得成功?这不再只是实际编写代码,而是真正把你的思考演进到全局视角、连贯的体验、相互连接的系统。(08:36):随着时间推移,我们会看到,第一,开发者会更多地采纳那种思维方式。别误会,今天软件开发中也有这种思维,只是它更多出现在资深开发者身上,在初级开发者身上则越来越少。初级开发者刚入行时,我们通常期望他们能写出简单的代码。(08:57):但如果现在有一个 AI 助手帮助他们写代码,他们从一开始就可以花更多时间去理解系统、理解他们正在构建的环境,或者理解他们正在构建的产品,而今天他们没有这样的时间,因为他们还在学习如何写代码。所以我认为这是一个方面。我预期会出现变化的第二个方面是硬件开发领域,因为我们知道 AI 的足迹很大,需要大量资源。(09:24):为了满足规模、满足需求,我们需要能够改进我们的硬件、CPU、GPU、算力以及代码的优化。这是另一个领域,今天只有一小群人在投入时间,我认为它将在整个软件开发生命周期中变得更加普遍一致。(09:44):与 AI 的集成肯定会成为对每个开发者而言更为常态的事情,今天我们开始看到那场变革、那种接受:AI 工具,我需要弄清楚如何与 AI 集成,我需要知道如何使用 AI。它会变得更加习以为常,我们将从很早的阶段就开始看到这些转变。当开发者开始塑造自己的思维时,他们就会开始理解所有这些组成部分。

10:14我看到一个数据,Shopify 的代码库中有超过一百万行代码是由 Copilot 编写的,我不确定自己算得对不对,但我想这比一个人一生写的还要多,可能也比许多工程师一生写的都多。我觉得这个数字提醒我们,事情变化得有多快,真正发生的改变有多大。(10:35):你还提到 92% 的工程师已经在使用 AI 工具。关于 Copilot 的使用情况、增长情况之类的,你还有没有其他可能让人惊讶的数据可以分享?

10:46好的。我们有超过 3.7 万个组织、超过 150 万名开发者在使用 Copilot。

10:54哇。

10:54而且根据我们的调查,他们写代码的速度快了 55%。想象一下,你能让一名软件开发者每天多出几分钟、半小时,他们会变得多么更有生产力,同时也因此变得多么更快乐。我们在用户中做过一项调查,85% 的参与者对自己的代码质量更有信心,而且在没有 Copilot 的情况下,代码审查完成速度快了 15%。我们知道,通常没有人喜欢做代码审查。(11:32):所以,如果我们能帮助加速,并让开发者更愿意花时间做代码审查,同时如果我们想想消除挫败感,那么 88% 的人感到挫败感减少,并且更能专注于编码能力。而这仅仅是个开始。我们还有来自客户的不同案例。我想 Accenture 是我们最近得到的一个,他们有 88% 的建议代码被保留。所以我们有很多这样的数据汇聚在一起,来展示使用 Copilot 和 AI 工具进行软件开发的规模和影响。

12:07假设公司听到这些数据,比如说我们将提高 25% 的效率。有些人可能会想,那我们就需要少 25% 的工程师,我们照样做所有同样的事情。我想你们实际发现的是,你们的工程师能做更多的事。所以并不是需要裁员,而是人可以变得更快、更好。

12:23不,让我说得非常清楚,你不能裁员。你必须有人参与其中。Copilot 是副驾驶,不是机长。这句话我一遍又一遍地说。我认为公司需要认识到的第二点,来自我们最近做的另一项开发者体验调查:多年来,我们给单个软件开发者增加了太多任务,从写代码、写测试,到与人互动,每周要与 21 个人协作,开会,等待构建,钻研遗留代码,所有这些都叠加在他们本来的基本工作,也就是写代码之上。(13:03):所以大多数开发者用于写代码的时间不到 25%,有人说不到 20%。因此,如果我们能还给他们半小时,第一,他们可以写更多代码。第二,他们可以休息一下、喘口气,这样我们就不会让他们精疲力竭,他们也更快乐。第三,我们给他们更多时间用于协作和创造性思考,从而激发创新。这不是你想要削减的东西。(13:28):这是你想作为礼物送给开发者的东西,这样他们对你满意,你也能留住他们。他们能做好自己的工作,有生产力,因此也就快乐。

13:38我和不少使用 Copilot 的工程师聊过。有一点让我意外:最出色的工程师反而最喜欢 Copilot。你可能以为它是给初级工程师用来更好更快地学编码的,但 10 倍工程师说……有人告诉我,它让他们也提升了 50%、变得更快,这太不可思议了。产品团队和工程团队在急于采用 AI、把 AI 融入工作流程时,你看到他们会犯哪些错误?

14:07我想有几点。第一,公司期望变革会神奇地发生:这里有个工具,去用吧。而它在所有公司里的推进情况并不总是一样的。所以需要投入时间,真正带领公司走完一个变革管理的过程。我看到的第二点是,由于现在 AI 被炒得太热,常常会出现这样的问题:哦,我们该拿 AI 做点什么?于是就有一种感觉,我必须用 AI 做点什么。(14:38):因为如果不这样,就是我没有做对的事。相比之下,对我的产品团队来说一个重点问题是:我们要解决的问题是什么,我们如何更好地利用 AI 来帮助解决这个问题,而不是我们拿 AI 做什么?所以,这是从客户问题出发、从我们要解决的问题出发倒推,然后认识到我们手上有哪些最好的工具可以把这项工作做得更好,并想清楚整个格局,而不是说,哦,AI 来了,我们必须用它。因为如果不用,就是我们做得不对。

15:11你能想到这方面的例子吗?比如有人做错了,或者浪费了很多时间?

15:17不一定是具体例子,但我一直在和一些客户交流,他们来找我们:“我们听说了 AI。你觉得我们应该拿 AI 做什么?我们应该如何采用 AI?我们能借鉴你们的经验吗?”我就分享我们的经验。当我们开始思考 AI 时,出发点是让开发者的生产力大大提高。我们看到了什么?开发者身上有多项任务,没有足够的时间用于编码。(15:45):那么,我们如何让他们有更多时间用于编码,编码中有哪些部分是我们可以自动化的?由此产生了这样的需要:好,我们来整合 OpenAI,整合 ChatGPT,把它们都连接起来,打造出这个帮助开发者提升生产力的、基于 AI 的工具。所以我在分享我们是如何一路走过来思考如何使用 AI 的。我经常看到客户眼前一亮,说:“哦,我们没有这样想过。”(16:15):他们更多是想把 AI 糊到很多东西上,而不是说:我有这样一个工作流,它需要大量手工操作,或者需要大量配置,也许我可以想想如何把 AI 融入其中,真正缩短时间,或者让它无缝衔接,或者减少开发者采用这个工具时的摩擦,等等。所以更多的是分享我们是如何思考的,并帮助客户理解同样的思路。

16:42顺着这个思路,你谈到你是如何与团队一起思考的。感觉你们的产品团队可能生活在未来,也就是其他产品团队未来的运作方式,因为你们能接触到别人不一定能接触到的东西。他们采用这些工具可能比其他团队快得多。你们的产品团队有哪些运作方式,是其他团队可能还没有采用的?

17:04在 GitHub,总体来说不只是产品团队。GitHub 就是 GitHub。我会说我们是自己吃自己的狗粮,这意味着我们是第一个尝试我们所开发的每一个功能、每一项能力的人。而且不只是我们的工程团队,而是遍及整个 GitHub。比如,GitHub 就运行在 GitHub 上。有好几篇博客文章和演讲。就在最近的 Universe 大会上,我们还有一场专门的演讲,讲 GitHub 如何使用 GitHub,以及如何在整个软件开发生命周期中采用 AI。(17:32):我们最大的关注点是:如果我们说 GitHub 是一个开发者平台,而且不止如此,它是一个软件开发平台,那么我们如何确保参与 GitHub 开发的所有角色也都在使用 GitHub?比如,我们的财务团队用讨论区、帖子、PR 和仓库来沟通我们的 AR 数字等等。我们的法务团队在用,我们的人力资源团队也在用。他们喜不喜欢,那是另一个问题。(18:02):但思路是,我们用 GitHub 来运营 GitHub,而产品团队与我们的工程团队一样,是最早的一批早期使用者之一。比如,当我们测试聊天功能,想看看它的数量或推荐、搜索的效果时,产品团队就是最早去摸索的用户之一。它有没有给我所需要的正确结果?它总结 PR 的方式是不是我想要的总结方式?等等。(18:27):但我们非常坚定地主张,我们必须自己来测试我们的工具。如果我们自己都用不了,我们的客户肯定也用不了。所以,没有任何东西会在 GitHub 内部经过足够几个月的打磨之前就发布出去,我们必须先判断它对我们是否有效,然后才会把它交到客户手中。

18:47Copilot 神奇的地方之一,是它能淡入背景。你不需要和它聊天,不需要告诉它任何事。它自己推断:你正在做这个,这是给你的答案。你想用就用,很酷;不想用,也没关系。关于 Copilot 的设计理念,你能分享些什么吗?

19:05好的。Copilot 的设计理念与我刚才提到的“从客户需求倒推”的概念高度一致。就是真正设身处地站在客户的角度,弄清楚他们需要什么,这种体验对他们来说会如何运作。如果它是一个额外的工具,如果你需要去请求它,或者需要等待它,那么开发者就不会采用。(19:27):因此,由于我们首先是为自己开发它,并且想用它做实验,设计理念就是设身处地站在开发者的角度,你希望那种体验是什么样的?2020 年,我们有一组 GitHub 工程师与设计团队和 OpenAI GPT 合作,真正弄清楚我们要如何构建它,以及它如何能帮助开发者更高效、更有生产力地完成工作,改善他们的协作和幸福感,等等。(19:57):但基本原则是,开发者必须想要使用这个工具。你增加的摩擦越多、增加的流失越多、增加的复杂度越多,开发者就越不想用他们的工具。我们刚才谈了开发者每天需要做的所有事情。现在再加上一件:我需要学习如何采用 AI,我们知道那行不通。所以它必须是无缝集成的。它必须是对开发者来说非常直观、能让他们取得成功的东西。

20:24Copilot 的成功指标是什么?衡量工程师的效率提升和生产力提升,是一个非常有意思的问题。你们关注哪些指标,来告诉你们它正在做我们希望它做的事?

20:35我们所处的世界里没有正确的指标。没有一个指标可以统领一切。这是你想通过采用 AI 来衡量的多种东西的组合。你可以考虑用 AI 来衡量代码质量。你能提高代码质量吗?你能通过引入 AI,例如我们的 GitHub Advanced Security,来提高代码的安全性吗?(21:00):所以有很多不同的指标,把它们组合在一起,就能反映开发者的生产力,然后还有开发者生产力、开发者协作、时间收益,把这些结合起来,就带来开发者的幸福感。我们目前最大的关注领域是生产力的定义,因为有这么多用户来到 GitHub,他们在寻找生产力的提升。(21:27):但随着我们不断在整个软件开发生命周期、所有工具中演进 Copilot 和 AI,我们非常清醒地意识到一点:生产力并不是针对其中每一个组成部分的正确指标。当我们把 AI 应用到 GitHub Advanced Security 时,写出更安全的代码才是正确的要素。比如我们能阻止多少机密信息泄露?在你发布之前,我们能发现并修复代码中的多少问题?(21:51):所以我认为 AI 的指标世界真的是个大课题。我们正与客户密切合作,因为他们也在问同样的问题,并且在各自公司内部做自己的实验,弄清楚他们想衡量什么。最容易衡量的是时间,但时间,我这么说有点好笑,时间不能作为可量化的成功指标,因为你可以非常快地写出非常糟糕的代码。(22:18):所以关键在于,我们如何把时间转化为效率、转化为生产力,转化为更难衡量的东西,然后这又如何带来开发者的幸福感,而这是另一个更难衡量的指标。因此,我们关注的是所有这些输入指标的组合,最终导向开发者的幸福感。

22:40是啊,这很有意思,因为工程师可能最终花更多时间写代码,因为他们更享受。他们完成的事情更多。而且,更多的代码行数也不是一个好指标,因为你并不知道那些是不是好的代码行。这是衡量工程师的经典错误方式。所以对我来说,感觉开发者幸福感才是终极指标。我们在播客里请过 Nicole,她提出了 DORA 这个框架,是衡量开发者体验、开发者幸福感的一种有趣方式。

23:05对。我认为我们在和客户交流并试图弄清楚如何表述的一点是,与其谈时间,不如谈价值实现时间(time to value)?也就是从你让开发者着手一项任务的那一刻起,到你意识到它的全部潜力或全部价值,需要多长时间,不管是产生收入、被采用,还是上市时间。你可以用不同方式定义你的价值实现时间。(23:28):但归根结底,你投资 AI 工具是为了帮助开发者更有生产力、更高效、更快乐,然后问它是否影响了你的价值实现时间,这是业务方面希望衡量的东西。

23:44本期节目由 Chameleon 的 HelpBar 赞助播出,这是一款专为 SaaS 打造的免费应用内通用搜索方案。你的帮助内容存放在应用之外,分散在许多地方,迫使用户浪费时间去寻找答案。HelpBar 解决了这个问题。它直接在你的应用内提供答案,消除了上下文切换。用户可以搜索或提问,获得 AI 生成的答案,以及来自你所有帮助来源(包括知识库、文档、博客和视频库)的最相关文档列表。(24:15):你还可以用 HelpBar 在应用内导航并启动操作,例如安排会议或查看交互式演示。如今最好的产品都用 Command-K 进行应用内搜索和导航。HelpBar 让你无需工程投入或新代码,就能在应用内轻松实现,给用户提供更快、更愉悦的自助体验,减少摩擦并提升应用内参与度。用这个现代化组件升级你的用户体验,为你的产品驱动增长注入动力。(24:43):今天就注册 HelpBar 吧。它免费,几分钟就能轻松设置好。请访问 helpbar.ai/lenny 了解。就是 helpbar.ai/lenny。回到这一切将走向何方的话题,想象你看过所有这些演示:有人画一个网站草图,拍张照片,发给 ChatGPT,它就为你把网站建出来?

25:04是的。

25:05你怎么看这类事情会如何融入其中?你会看到 CEO 们说“这是我想要的 iPad 应用”,我给你画个草图,然后直接交给 Copilot 第 10 版,它就替你写出来吗?我知道你说工程师不会被裁减,只会增加并变得更高效,但我想知道你认为这方面会走向何方:比如,这是一张草图,帮我做出来?

25:27我把它看作一种更好的协作工具,而不是生产工具。因为现在很多时候,我们在表达想法上遇到的挑战在于沟通,在于思路的清晰度。所以,如果我们能利用 AI 来改善协作,你基本上把一幅草图放在 Copilot 面前,它帮助讲清楚你要求开发者做什么,就能缩短很多周期和来回沟通。比如,你是什么意思?(25:53):你是指这里的按钮,还是你想要粉色的,还是你想要那个应用,还是你想要那个操作系统?所以,如果 Copilot 能帮助提炼沟通,它就可能成为市面上最好的协作工具,尤其是在我们所处的全球化世界里,我们看到参与提出一个想法的不同角色之间,沟通一直是个挑战。基本上我们看到 AI,在我们看来是 Copilot,正在成为下一种自然语言对话。(26:26):它是一个翻译者,帮助让所有人达成共识,因为它在创造一种通用的对话语言,就像过去数学所扮演的那样。

26:37这让我想起我和一位工程师的另一次对话,他说他很喜欢写那些简单的函数,而现在 Copilot 在替他写,他为此感到难过,但他并没有把它关掉。可他有点觉得,“那才是我真正享受的。这些我能轻松搞定的小事,比如某种排序函数。”我想问,你觉得我们的代码有这么多是别人替我们写的,我们会失去什么吗?

27:01我认为每个开发者都有自己喜欢做的部分。而且你不必用 Copilot 来写你的简单代码。你可以通过聊天体验使用 Copilot,把它当作 AI 助手来头脑风暴。我们给你一套工具,并且我们心中有一个你应该如何使用它们的场景。但我们看到的是,开发者使用它们的方式非常不同。每个人都在选择自己使用这些工具的风格。没有对错之分。(27:32):它是一个工具。它是一种语言。我刚学编程的时候用 C 写代码,后来 Java 出现了。我当时想,哦,但这会抢走我的工作,因为我以前要写所有这些函数、所有这些库,而现在 Java 都有了。然后 Python 出现了,它是又一个抽象层。我就想,好吧,那我现在连这个都不用想了,因为 Python 都能做。所以关键在于你如何使用这些工具,用它们去做什么。有些领域,即使今天,我仍然会去用 C 来写。(28:04):如果某些东西需要在非常小的 CPU 上运行,我不信任别人以高效的方式替我发明 metrics。所以我会自己做。另一方面,也会有一部分内容,我会委托给更高层次的工具,这正是我思考 AI 的方式。你可以挑选自己想怎么用它。没有一种放之四海而皆准的绝对真理,让所有人都必须遵循。你需要想清楚如何使用你的工具来完成工作,同时仍然保留那些让你快乐的事情。(28:34):另一方面,用 AI 去做你不那么喜欢的事情。也许你喜欢写函数,但不喜欢写测试,那就生成单元测试等等,让 AI 替你完成这部分工作,而你继续专注于你喜欢的事情。

28:48你现在还能抽出时间写代码吗?你还会在业余时间写一些 C 吗?

28:52现在有一点。现在我主要是和我的大儿子一起玩,他有更多时间去钻研,但有时我喜欢花时间和他一起头脑风暴,聊聊各种事情和架构。我记得几个月前,他做了一个关于传感器和传感器集成的项目,他接触到了 common filter,那是我很多很多年前做过的东西。(29:16):他就问,好吧,这是什么,是怎么做的?然后我们一起过了一遍,我帮他思考结构和传感器融合之类的。然后有时我会说,“好了,让开,来,这是你应该……”

29:29打开 Copilot。开玩笑的。

29:29妈妈的 Copilot。

29:33太有意思了。这让我想起,我看过你的一场演讲,你很久以前,在这还不流行的时候,就在训练、调优模型和大语言模型。所以你在这个领域已经很久了。回头看,现在有没有什么你看到的、关于事情发展方向的东西,是当时你没有预见到的?

29:51我成长在一个小众 AI 的世界里,你必须是专家,需要经过多年训练,理解如何调优模型、什么是正确的输出,你需要理解如何构建仿真来测试它、如何摄取数据、专注于优化。这些年我见证了 AI 的演进,有各种会说话的设备和对话式 AI,一开始是单轮的,后来变成了多轮的。(30:22):所以我开始看到 AI 更加大众化的趋势,但我没有预料到生成式 AI 的爆发。每个人,甚至连 AI 是什么都不知道的人,都觉得自己需要使用 AI。我认为这是让我感到意外的事情,因为我所受的训练是,你必须是专家才能使用 AI。所以对我来说,那是顿悟时刻,心想,嗯,这很有意思。那么下一步是什么?

30:47你对大语言模型是否就是这一切的终极形态,只要继续增加算力和数据就行,有看法吗?还是你认为地平线上还有别的什么东西,会再次彻底改变 AI 的 Transformer 模型?

31:06我认为我们已经非常强烈地转向了这样的想法:生成式 AI 和通用 AI 可以解决一切。我相信未来会回到稍微收缩一点,回到小众 AI。所以我们会生活在一个混合的世界里,仍然会有特定的 AI 模型来解决非常具体的问题,而生成式 AI 会有它的局限。它是一个通用工具,所以它的好坏取决于数据集,而且它也试图给出某种统计意义上的推荐。好不好?不好?所以它受限于它所拥有的训练集,而且它试图成为面向所有人的一切。(31:43):仍然会有一些领域需要训练模型。比如,我在航空航天行业和汽车行业待过。我不认为自动驾驶汽车那些需要极其精细、特定的模型、调优和严格安全监管的东西,会在 ChatGPT 上开发出来。我可能是错的,但我认为最终我们会发现自己处在混合模型和多模型的世界里,会有多个 LLM 模型一起协作,因为每一个都有各自的优势。(32:19):然后还会有小众 AI,或者说针对特定用例、可配置性更强的定制模型。这就是我对未来的预测。但十年后,我们都会更聪明。

32:32是啊,未来很难预测。

32:34是的。

32:35我想问,GitHub 提出了整个 Copilot 的想法。我们请 Ryan 上过播客,他讲到有一位研究员在试验我们能用一大堆数据做些什么。然后这本质上变成了,哇,这真的行得通。我们快速扩大规模并发布吧。(32:54):我想问,你从 GitHub 和微软内部的这一巨大成功中学到了什么,可以用来发现其他重大机会吗?你在团队的结构设置上,或者为人们创造空间来试验这类事情以找到下一个 Copilot 方面,有没有什么做法?

33:10很大程度上就是这样。很大程度上是为团队创造创新和试验的带宽,并把这段时间划出来,同时也要接受并非每个试验都会成功。所以向“边学边做”或“向前失败”的转变,这些是我所信奉的理念。如果你不尝试,如果你不试验,你就永远不会创新。如果你不失败,你就永远不会从错误中学习,永远不会从经验中学习,也就无法向前进步。(33:36):所以,真正创造这种试验的能力,就像我们在 Copilot 上做的,或者在 GitHub Advanced Security 上做的,甚至 GitHub 本身被创建的方式,这一切都来自团队的创新思维:他们在思考下一代用例是什么?未来的开发者需要什么才能快乐、更有生产力、完成他们的工作?在软件开发变化如此之快的世界里,你必须为下一代、为下一个创新创造这样的带宽。(34:08):如果你没有机会看到 Universe 大会为期两天的主题演讲,我强烈推荐,因为我们基本上分享了 Copilot 的下一个愿景,即 Copilot Workspace。我们还请到了 Satya Nadella 上台,他非常兴奋。他说,“哦我的天,GitHub,如果你们做出来,这太棒了。”所以你能看到,我们一次又一次地提出这个愿景,至少比市场上出现产品早六个月到一年,因为我们已经在思考,已经在创新,已经在做下一件事了。

34:38除了这些“边发布边学习”、“失败也没关系”的原则之外,你们还做了什么来促成这一点吗?你们在团队结构或资源配置上有什么方式吗?比如有一定比例的时间用来思考其他想法,还是总体上就是我们可以接受失败,自己找时间去做别的事?

34:55有几件事。第一,花时间和客户在一起,向客户学习,因为很多创新的想法基本上来自与客户的交谈,因为他们会和你分享他们的挫败,和你分享他们想要什么,和你分享什么会是对他们而言了不起的发明。所以第一件事就是创建这样的机制。我们花很多时间与客户交流,也与我们的社区交流。(35:21):我们很幸运,成为所有开发者的家园,所有开源的家园。大型开源基金会和小型开源基金会都运行在 GitHub 之上。所以这是我们的另一个反馈循环,用来真正收集这些想法和诉求,帮助我们塑造未来。第二件事真正在于团队提出想法。比如,“我有这个想法。我做了一些研究。这是一篇论文,描述了我想做的事”,然后我们弄清楚,好,我们什么时候能为它提供资金?(35:49):怎么为它提供资金?我们能分配一部分特定的带宽吗?我们能做一个概念验证(POC)吗?是在那个团队里做,还是作为一个虚拟团队(V team)来做?所以我们保持灵活。我们还有一个研究团队,就是 GitHub vNext,他们的日常工作就是思考下一个大创新。但在 GitHub,创新来自各处。它来自我们的一线团队,他们与客户交谈,为客户实施不同版本的 GitHub。他们会带回一些反馈或想法。(36:18):它来自产品团队。来自设计团队,来自工程团队。它来自四面八方。所以,如果你试图把创新结构化,你就会失去那种有机的火花,那是人性的东西。想象一下,有人说你每天有 15 分钟的时间可以发挥创造力。我不认为那会奏效。所以更多的是鼓励这种思考,而不是结构化。

36:50你能多谈谈你提到的那个团队吗?它叫什么?vNext 团队?

36:50GitHub Next。对。

36:51Next 团队。你能多讲讲这个团队是什么、怎么运作的吗?

36:53他们基本上是应用科学家、研究科学家,一起工作,真正思考三到五年的视野。他们不考虑眼下。他们思考的是软件开发的未来会是什么样子。他们撰写论文,运行实验,做概念验证。他们的工作就是发明未来。(37:16):但同样,这真的是一种协同,因为他们与产品、与工程团队交谈,从中获得想法。他们与客户交谈,或者我们把反馈分享给他们。这就是我们的 GitHub Next。基本上就是我们的研究团队。

37:28Copilot 就是从那里诞生的,对吗?

37:28对。

37:32这很有意思,因为我想我和 Ryan 聊过这一点,有很多公司都有这样的团队。比如 Facebook 有一个著名的,叫 New Product Experience 团队。Google 有 Google……忘了叫什么了。但据我了解,它们都没有真正成功,而这个成功了。你觉得你们做得有什么不同吗?是更基于科学和研究,而不是产品经理尝试一堆不同的应用?我不知道,你认为这个团队成功的关键是什么?

37:59我认为有两个要素。一是团队里有合适的人、合适的心态,允许他们并给予他们创新的带宽和自由。第二是我们专注于让事情落地。所以我们不会让他们远离或脱离产品和工程。(38:15):这里有很多协同,有很多讨论,因为在不成功的团队里发生的情况,至少据我所见,一是这个团队基本上变成了一所大学,他们写论文,但没有任何成果产出,所以没有任何东西能进入生产环境。所以,如果你没有引入这一点,即在你思考一个新想法时,从第零天起就想好如何把它带到生产环境,那么它很少能走完那个坎坷的周期并最终落地生产。第二点是,公司往往把这些团队用得过于战术化。(38:47):比如,“我们六个月后需要某样东西,现在就去发明它”,这样他们基本上就是在另外创建一个工程或产品团队,去思考那些现在已经处于第一地平线的事情。所以我认为在 GitHub,我们找到了合适的平衡:既有合适的人、合适的心态,也在面向未来的思考与如何让它成真之间创造了协同,因此我们有牢固的关系,特别是产品团队与 GitHub Next 之间,确保这种关系持续,想法在双方之间双向流动。

39:20今天你是 GitHub 的首席产品官,我认为这对很多人来说是一份梦想的工作。早期的产品经理、资深产品经理都想弄清楚如何才能走到你今天的位置。我很好奇,你觉得最能帮助你建立起在这个角色上取得成功所必需的技能的是什么?是导师、高管教练,还是长年累月地做这份工作?还有别的类似的东西吗?

39:47是综合作用。从来不是单一的因素,因为首席产品官这个角色非常宽泛。你不仅仅是产品负责人。业界现在正在演进的观念就是,首席产品官不止是产品负责人。他们需要有商业思维。他们需要理解自己的进入市场策略。他们需要理解销售打法。他们需要理解工程团队是如何构建产品的。这不只是写一套需求,或者思考愿景和未来。(40:16):而是公司里所有这些组成部分如何协同运作来构建那个产品。其中一部分是你通过观察你所效力的领导者、看他们怎么思考而学到的。从我在航空航天行业的第一位老板那里,我学会了如何进行系统性思考。不是只想着我现在要解决的问题,而是我负责解决的问题,也就是我负责调优的那个滤波器,如何与他们的控制系统、点火系统等等相连,以及它最终是如何显示出来的。(40:47):所以这要求我从一开始就考虑更大的解决方案,而不只是我的那个组件。我认为这是第一点。第二点是真正思考人和变革管理,以及如何让人们与你同行,因为产品经理这个角色是非常有影响力的角色,你所做的很多事情都是在影响他人。尽管每个人都以为作为产品经理你可以去做事情,去写文档,但你需要影响工程团队去构建你希望他们构建的产品。(41:17):你需要影响营收团队按你设想的方式进行市场推广并销售产品。所以有很多影响工作在发生。你需要理解如何做到这一点,而且作为产品经理从一开始就培养这项技能非常关键。所以对我来说,我很幸运能在行业里承担不同的角色,向不同的人学习,同时也向上看、向旁边看、向下看我所管理的人,看看我能从他们身上学到什么?(41:47):他们有哪些技能是不一定在我的工具箱里的,我如何采纳它们?成功是什么样子,哪些事情会让人不开心?你不一定想把这些放进你的工具箱。所以这是多种“要”与“不要”的组合。

42:04是的,正如你所说,是所有这些东西的组合。我特别喜欢你的最后一点,就是找出那些在你想要提升的方面很出色的人,向他们学习,观察他们,也许问他们一些关于他们如何运作的问题。我正在尝试播客的一个新环节,叫“失败角”,我想问你的是,你职业生涯或产品方面最大的失败是什么,你从那段经历中学到了什么?

42:30我会称之为最大的学习,因为我不相信失败。我相信学习。每次你失败,都是一次重大的学习,我更愿意把它看作机会。我想最大的一次可能是在早期,我刚开始成为领导者、团队经理的时候,我是一个非常“冲冲冲”的人,精力充沛。当我接手某件事,看到所有需要修复的问题时,我就会想,好,把工具箱拿出来,去把一切都修好。这包括推动变革。(43:03):而我发现,当我开始这样做,却没有建立起人们对为什么需要变革、为什么这是我们需要去修复的问题的理解时,你就无法让人们在这段旅程中与你同行。所以要真正分析清楚,并不是每个人都像你一样欣赏变革,并不是每个人都有那种“冲冲冲,我们去做吧”的心态。要真正弄清楚,退一步评估正在发生什么,这样你才能带着团队一起走过变革的旅程。(43:35):对我来说,那是最大的学习,而当时我从团队那里得到的很多不那么支持的反馈大概是,“你走得太快了。慢下来。解释一下为什么。我们为什么要这样做?我们该如何推进?”

43:52这具体发生在哪里?哪家公司?什么职位?

43:55在 TomTom,当时我领导基于位置的服务团队。对我来说,一是这是我第一次在国际公司工作,所以真正认识到我的性格并不总是适用于每一种存在的文化。那么我该如何调整?第二点是,他们非常习惯在特定环境中以特定方式工作。是的,我是被雇来推动变革的,但一方面,团队并不必须接受。推动变革是你的工作。(44:31):而且他们也不一定认同你来这里是为了推动变革。所以如何让他们在这段旅程中与你同行,是一次重大的学习,还有能够以一种通用的沟通方式来沟通以带来清晰度,这也是一次重大的学习。

44:48这实际上是“失败角”里反复出现的主题,在我想到的那些失败故事里,就是有人进入一家公司,试图太快地改变太多东西。

44:55对。这非常常见,因为我们是人。我们认为,当我们带着自己的经验来到一个新的环境,你会立刻看到所有不起作用的东西,或所有需要修复的东西。如果你在同一个空间、同一个团队里工作了很长时间,你往往就看不到这些差距了,因为你已经习惯了与它们共存。(45:15):所以作为新人,你进来,立刻就看到所有这些漏洞和裂缝。你会想,好,这些都是我需要修复的。但你面对的是一个已经在那里待了很久的团队。那么,你如何找到那座桥梁,在你所看到的和他们认为没问题的之间沟通?比如,“你为什么要推动这些变革?它一直运转得好好的。别去修它。”

45:35Inbal,在进入我们非常精彩的快问快答环节之前,你还有什么想分享的吗?

45:40对我来说,这是一个令人兴奋的时刻。我刚刚庆祝了在 GitHub 的第一年,上周还在台上参加了我的第一次 GitHub Universe。能见到我们的客户、合作伙伴,并大量谈论开发者体验的重要性、我们由 AI 驱动的平台,以及我们如何塑造未来,对我来说是一次奇妙的经历。所以我正处在我在 GitHub 旅程中非常令人兴奋的阶段。(46:05):你不会走到这里,除非你犯过一些错误,做过一些学习,取得过一些成功,然后你做出正确的转向,有时也会转错弯,但你找到了一个让你快乐、让你作为产品领导者感到充实的地方。

46:19太棒了。我们会在节目说明里附上那场演讲的链接,方便大家观看。接下来,我们进入非常精彩的快问快答环节。准备好了吗?

46:26准备好了。

46:28你向别人推荐最多的两三本书是什么?

46:32John Maxwell 的《Failing Forward》,Jim Collins 的《从优秀到卓越》中的飞轮,以及我最近读的一本书,叫《Dare to Lead Like a Girl》,作者是 Dalia Feldheim。

46:45这是节目里第一次被提到的书。太棒了。你最近有没有特别喜欢的电影或电视剧?

46:51我很喜欢奇幻类的,也很喜欢基于历史的电影和理论。最近 Netflix 上出了一部,《我们看不见的光》。太棒了。制作得非常精良。真的讲述了第二次世界大战历史中一段有趣的部分。

47:06如果你喜欢奇幻,你看过 Amazon Prime 上的《时间之轮》吗?

47:09看过。是的,我喜欢那部。它已经播完了。是一部好剧。

47:13是啊,尤其是第二季,简直惊艳。好多了。下一个问题,你面试候选人时有没有特别喜欢问的面试问题?

47:22我想我真正喜欢问的第一个问题是:你做过的最具创新性的事情是什么,你为什么认为它有创新性?很有意思的是,有些人觉得他们需要回答自己做过的最大发明,而有些人则非常坦诚,谈到他们创新过的某件非常个人的事情。(47:41):这很能显示他们的性格。我想我很喜欢问的第二个问题是:举一个你和你的经理意见不合的例子,你和你的经理持不同立场,然后你是怎么做的,结果如何?因为这能很好地展现你的性格,以及你是否愿意在需要的时候坚持立场、向上反映。还有你有什么样的沟通技巧、什么样的影响力技巧?

48:09你有没有一句喜欢与人分享的人生格言,无论在工作还是生活中,你经常回头想起、觉得有用的?

48:15我想是,如果你不冒险,你就无法创造未来。我忘了是谁说的。如果我没记错,我想是出自某部动画里的蒙奇·D·路飞。但它基本上总结了这条人生格言:你必须冒险,你必须尝试。如果你觉得舒适,那不是好事。你总是需要感到不舒服,才能拓展自己,迈向下一步。这是我一直在做的事。你刚刚听了我的职业故事,从应用科学家到首席产品官。谁能想到呢?

48:46我喜欢这句格言。Inbal,非常感谢你来到这里。最后两个问题。如果大家想联系你、跟进任何事情,可以在网上哪里找到你?还有,听众怎样能对你有所帮助?

48:57Universe 大会上有很多有趣的分享和演讲。所以如果大家想更多地了解我们在做什么、我们如何思考 AI,LinkedIn 可能是找到我的最佳社交媒体平台,我在那里有机会和很多人交流。这些是最好的地方。

49:12那么听众怎样能对你有所帮助?

49:16如果你能分享类似的经历或故事,你认为对我思考成为 GitHub 首席产品官意味着什么会有帮助,或者关于如何使用 GitHub 的任何技巧和窍门,这样我也许可以学习,或者分享你的经验和故事,让我也能从你的经验中学习。

49:31太棒了。Inbal,非常感谢你来到这里。

49:35非常感谢你邀请我。

49:36再见,大家。非常感谢收听。如果你觉得有价值,可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。也请考虑给我们评分或留下评论,这真的能帮助其他听众发现这档播客。你可以在 lennyspodcast.com 找到所有往期节目,或了解更多关于节目的信息。下期节目见。