AI 在软件开发中的未来 | Inbal Shani（GitHub 首席产品官）

Inbal S 2023-12-01

AI 在软件开发中的未来 | Inbal Shani（GitHub 首席产品官）

AI 在软件开发中的未来 | Inbal Shani（GitHub 首席产品官）

文字记录

Inbal Shani： 使用 AI 工具进行软件开发的人需要形成一种不同的思维方式。你需要开始思考如何利用这些 AI 工具来帮助自己取得成功。这不再仅仅是实际的代码编写，而是真正将你的思维提升到全局层面，到互联体验，到互联系统。今天我们主要在更资深开发者身上看到这种思维，而在初级开发者身上则越来越少。

初级开发者刚入行时，通常我们期望他们能编写简单的代码。但现在如果有 AI 系统帮助他们写代码，他们从一开始就能花更多时间去理解系统、理解他们正在构建的环境，或理解他们正在打造的产品。而现在他们没有这个时间，因为还在学习如何写代码。

Lenny： 今天的嘉宾是 Inbal Shani。Inbal 是 GitHub 的首席产品官，此前曾在 AWS 和微软担任总经理，也曾是 Amazon Robotics 的高级软件开发工程师。

在我们的对话中，我们探讨了 Copilot 和面向软件工程师的 AI 工具的终极形态、AI 时代软件开发的未来图景、AI 与软件开发中被高估和低估的部分、团队关注哪些指标来判断 Copilot 是否发挥了作用、团队和公司在拥抱 AI 时犯的错误、Copilot 的设计理念，以及是什么帮助 Inbal 成为今天的领导者，还有 GitHub 作为产品和组织的未来方向。

软件开发中被高估与被低估的

Lenny： 我想从一个关于软件开发走向的大问题开始。你似乎处于这场变革的风暴中心。甚至可以说 GitHub 随着 Copilot 的发布点燃了这场风暴。那么，你认为在软件开发的变化中，什么是被高估的，什么是被低估的？

Inbal Shani： 我大概一年前作为首席产品官加入 GitHub。两天前，我刚好庆祝了入职一周年。对我而言，最初的思路是审视整个平台，审视软件开发生命周期，然后形成一些判断。我最大的判断是：开发者的幸福感和生产力很大程度上取决于他们的环境和开发工具。因此，AI 对这一使命至关重要。

当我们审视当下 AI 的发展态势，AI 真的已经成为开发者群体中的基本期望，对他们能否完成工作来说处于核心且关键的地位。我们知道大约 92% 的开发者已经在使用 AI 工具。但在这一图景中，被高估的部分是：生成式 AI 将取代人类。我认为这在可预见的未来不会发生。我的看法是，你始终需要人在回路（human in the loop）中进行参与，因为 AI 无法取代创新。

那种创造性的火花，那种作为人类核心的创造性思维，不会被 AI 取代——至少在可预见的未来不会。如果我们思考一个成功的 AI 工具意味着什么，你需要数据。要产生数据，就需要人类使用工具、与工具交互、做各种各样的事情。所以我认为当下被高估的就是生成式 AI 将取代人类——它将成为一切问题的解决方案。我认为它是一个工具。

AI 驱动的测试

如果深入到当下软件开发中被低估的部分，我开始听到一些关于 AI 驱动测试的讨论，但提及得并不多。而如果我们设想的 AI 时代将会生成更多代码、生产力更高、效率更高、更多行代码、更多应用，那么测试就成了软件开发过程中极为关键的一环。

我很想听到更多这方面的内容，想了解各公司在思考如何利用 AI 生成更大规模的测试套件，以便验证工作成果。

Lenny： 你说的测试是指单元测试、集成测试之类的吗？

Inbal Shani： 全部——负载测试、基础设施测试、安全测试、渗透测试。当你需要人工来编写所有这些测试能力时，你需要大量的人，而且他们需要形成不同的思维方式。我们能否利用 AI 来真正生成那样一套测试，涵盖从单元测试、功能测试到负载测试、性能测试的所有内容？

软件测试的重要性与日俱增

Inbal Shani： 我们有很多测试工作，甚至不把它们当作测试来看待，所以我们不一定会花很多时间去做。但如果现在我们说软件处于一切的中心，所有公司都将以某种形式成为软件公司，代码量会越来越多。因此，测试的重要性正变得愈发关键。

三到五年后的软件开发

Lenny： 顺着这个话题往下说。你提到你不认为软件工程师会完全消失。你对三到五年后软件开发会有什么不同有什么总体判断？你觉得会有什么变化？另外，你怎么看这一切的终局——Copilot 和类似工具越来越好、越来越好，你认为最终会走向哪里？

Inbal Shani： 对我来说，我一再强调，Copilot 是副驾驶，不是主驾驶。你仍然需要人在回路。但这意味着，软件开发者或者说使用 AI 工具来开发软件的人，需要形成一种不同的思维方式。首先，你需要开始更多地从系统层面、架构层面去思考。你需要弄清楚如何利用这些 AI 工具来帮助你取得成功。这不再仅仅是编写代码本身，而是真正将你的思维提升到全局视角，到连通的体验，到连通的系统。

随着时间的推移，我们会看到开发者更多地采纳这种心态。当然，这种思维在今天软件开发领域并非不存在，但它更多出现在资深开发者身上，在初级开发者身上越来越少。初级开发者刚入门时，我们通常期望他们能够编写简单的代码。

但如果现在有 AI 助手帮助他们写代码，他们从一开始就可以花更多时间去理解系统、理解他们所构建的环境、理解他们所构建的产品——而这些在今天他们没有时间去做，因为他们还在学习如何写代码。所以我认为这是第一个方面。

我预期会看到变化的第二个方面是硬件开发领域，因为我们知道 AI 占用资源巨大，需要大量的算力支撑。

为了能够满足规模、满足需求，我们需要提升我们的硬件——CPU、GPU、计算能力以及代码优化。这是今天只有一小群人在投入的领域，我认为它会变得更加贯穿整个软件开发生命周期。

与 AI 的集成将成为每个开发者的常态。今天我们已经看到这场变革的开端——那种接受和认同，AI 工具，我需要搞清楚如何与 AI 集成，我需要知道如何使用 AI。它会变得更加普遍，而且我们会看到这种转变从很早就开始。当开发者开始塑造自己的思维方式时，他们就会开始理解所有这些组件。

Copilot 的使用数据

Lenny： 我看到一个数据，说 Shopify 代码库中有超过一百万行代码是由 Copilot 编写的。我不知道怎么算，但我猜这比一个人一辈子写的代码还多，可能比很多工程师一辈子写的都多。我觉得这个数字提醒我们，事情变化有多快，实际发生了多大的改变。

你还提到 92% 的工程师已经在使用 AI 工具了。关于 Copilot 的使用情况、增长情况之类的，还有没有其他可以分享的、可能会让人惊讶的数据？

Inbal Shani： 有的。我们有超过 37,000 个组织、超过 150 万开发者在使用 Copilot。

Lenny： 哇。

Inbal Shani： 根据我们的调查，他们的代码编写速度提高了 55%。想象一下，如果你能给一个软件开发者每天哪怕多出几分钟、半小时，他们的生产力会提升多少，同时他们也会因此更加愉快。我们通过用户调查还了解到，85% 的参与者对自己的代码质量更有信心，代码审查的速度也提高了 15%。而且我们知道，通常没有人喜欢做代码审查。

所以如果我们能帮助加速、让开发者更愿意花时间去做代码审查——同时考虑到消除挫败感——88% 的人感到更少挫败、更专注于自己的编码能力。而这仅仅是个开始。我们有来自不同客户的案例。比如 Accenture 是最近的一个，他们 88% 的建议代码被保留了。我们有很多这样的数据汇聚在一起，展示了使用 Copilot 和 AI 工具进行软件开发的规模和影响。

AI 不会取代工程师

Lenny： 假设一些公司听到这些数据，觉得”哦，我们会提高 25% 的效率”，有些人可能会想，那我们就可以少用 25% 的工程师了，同样的事情照样做。但我想你实际发现的是，工程师能做更多的事情。所以不是说你需要裁人，而是人可以更快、做得更好。

Inbal Shani： 不，让我说清楚，你不能裁人。你必须有人在回路。Copilot 是副驾驶，不是主驾驶。这句话我一再说。我觉得公司需要意识到的第二件事——这也是我们最近做的另一项开发者体验调查——是这些年来我们给单个软件开发者堆加了太多任务：写代码、写测试、与人沟通、每周与 21 个人协作、开会、等构建、翻遗留代码——所有这些都是在他们需要写代码这一基本工作之上叠加的。

所以大多数开发者花在写代码上的时间不到 25%，有些人说不到 20%。如果我们能给他们每天多出半小时，第一，他们可以写更多代码。第二，他们可以喘口气休息一下，这样我们不会让他们过劳，他们也更快乐。第三，我们给了他们更多时间去协作和进行创造性思考，这能激发创新。这不是你想要削减的东西。

这是你想要作为礼物送给你的开发者的东西——让他们对你满意，你能留住他们。他们能做好自己的工作，有产出，因此也快乐。

Lenny： 我和不少使用 Copilot 的工程师聊过。有一件事让我惊讶：最优秀的工程师反而最热爱 Copilot。你可能以为这主要是给初级工程师用的，帮助他们写得更好更快，但 10X 工程师也说……有人告诉我 Copilot 让他们的效率也提高了 50%，这太不可思议了。你在产品团队和工程团队匆忙开始采用 AI、将 AI 集成到工作流程中时，看到他们犯了哪些错误？

采用 AI 的常见误区

Inbal Shani： 我觉得有几个方面。第一个是公司期望变革神奇地发生——给你一个工具，去用吧。但实际情况并不是在所有公司都一帆风顺。所以需要投入时间，真正带领公司走过一个变革管理的过程。第二个我看到的现象是，由于 AI 现在非常火热，经常会有这样的问题：“我们该用 AI 做什么？“于是就有一种”我必须用 AI 做点什么”的感觉。

因为否则，就不是在做正确的事。而我的产品团队真正聚焦的问题是：我们要解决的问题到底是什么？如何更好地利用 AI 来帮助解决它？而不是”我们要拿 AI 做什么”。所以关键在于从客户问题出发、从我们要解决的问题出发，往回推导，然后判断我们手头有哪些最好的工具可以更好地完成这项工作，并在此基础上进行通盘思考——而不是”AI 来了，我们必须用它，否则就是落伍了”。

Lenny： 你能想到某个具体的例子吗？有人在这方面做错了，或者浪费了大量时间？

Inbal Shani： 不一定是某个具体案例，但我一直在和我们的一些客户交流，他们会来找我：“我们听说了 AI，你觉得我们该拿 AI 做什么？我们该怎么采纳 AI？能从你们的经验中学习吗？“我就把我们的经验分享给他们。当我们开始思考 AI 时，出发点是让开发者大幅提升生产力。我们观察到了什么？开发者身上背负着多项任务，他们没有足够的时间花在编码上。

那我们如何给他们腾出更多时间来编码？编码过程中哪些环节可以自动化？由此才引出了这样的需求：好，那我们把 OpenAI 接入进来，把 ChatGPT 接入进来，把它们全部串联起来，帮助打造一个基于 AI 的、能提升开发者生产力的工具。我分享了我们是如何走过这条路径来思考 AI 使用的。很多时候客户会恍然大悟：“哦，我们原来不是这么想的。”

他们更多是想把 AI 贴到很多东西上面，而不是说”我有这样一个工作流，它需要大量手工操作，或者需要大量配置。也许我可以想想怎么把 AI 融入其中，真正缩短时间，让流程更顺畅，或者降低开发者采纳这个工具的摩擦”，如此等等。所以更多的是分享我们的思维方式，帮助客户建立同样的理解。

GitHub 如何”吃自己的狗粮”

Lenny： 顺着这个思路，你在谈自己团队内部的思考方式。感觉你们的产品团队可能正活在其他产品团队未来的工作方式里，因为你们能接触到其他人未必能接触到的东西，采纳这些工具的速度也比其他团队快得多。你们的产品团队有哪些运作方式是其他团队可能还没有的？

Inbal Shani： 在 GitHub，不仅仅是产品团队。GitHub 就是 GitHub。我想说，我们吃自己的狗粮（eat our own dog food），意思是我们是第一个试用每项功能、每项正在开发的能力的人。而且不只是工程团队，这贯穿整个 GitHub。比如，GitHub 本身就运行在 GitHub 上。有好几篇博客文章和演讲讲过这件事。甚至在最近的 Universe 大会上，我们还专门有一个演讲，讲的是 GitHub 如何使用 GitHub，以及如何在软件开发生命周期中全面采纳 AI。

我们最大的关注点是：如果我们说 GitHub 是一个开发者平台——不仅如此，它是一个软件开发平台——那我们如何确保参与 GitHub 开发的所有角色也都在使用 GitHub？比如，我们的财务团队在用 discussions、posts、PR 和 repos 来沟通我们的 AR（应收账款）数据等等。我们的法务团队在用，人力资源团队也在用。至于他们喜不喜欢，那是另一个问题。

但核心理念是：我们用 GitHub 来运行 GitHub。产品团队和工程团队一起，是最早的采纳者之一。比如，当我们测试 chat 功能、想看推荐质量和搜索效果时，产品团队就是最早去试用的一批人——它给我的建议是我需要的吗？它对 PR 的摘要方式是我想要的吗？诸如此类。

但我们非常坚定地主张，我们必须是测试自己工具的人。如果我们自己都用不了，客户肯定也用不了。所以任何东西在发布之前，都必须在 GitHub 内部经过足够长时间的打磨，我们确认它对我们有效之后，才会交付到客户手中。

Copilot 的设计哲学

Lenny： Copilot 最神奇的一点就是它如何融入背景，几乎让人感受不到它的存在。你不需要和它对话，不需要告诉它任何东西。它自己就能推断——你在做什么，这是你要的答案。你想用就用，不想用也没关系。你能分享一下 Copilot 的设计哲学吗？

Inbal Shani： 好的。Copilot 的设计哲学与刚才提到的”从客户出发、往回推导”的理念高度一致。就是真正把自己放在客户的位置上，弄清楚他们需要什么，他们的体验会是什么样的。如果它是一个额外工具，需要你主动去请求它，需要你等待它，那开发者就不会采纳它。

正因为我们是先为自己开发的，并且想要进行实验，所以设计哲学就是：把自己放在开发者的鞋子里，你希望这种体验是什么样的？2020 年，我们有一群 GitHub 工程师与设计团队以及 OpenAI GPT 一起合作，真正探索如何构建这个东西，以及它如何帮助开发者更高效地工作、提升生产力、改善协作与幸福感，如此等等。

但最根本的原则是：开发者必须愿意使用这个工具。你增加的摩擦越多，增加的混乱越多，增加的复杂度越高，开发者就越不想用。我们刚才谈到了开发者每天需要做的所有事情。现在再往这个组合里加一条”我需要学习如何接纳 AI”，我们很清楚这行不通。所以它必须是无缝集成，必须是对开发者来说非常直觉化、拿来就能用的东西。

如何衡量 Copilot 的成功

Lenny： Copilot 的成功指标是什么？衡量工程师的效率提升和生产力增长是一个非常有趣的问题。你们关注哪些指标来判断这件事是否达到了预期？

Inbal Shani： 在我们所处的领域里，没有所谓的”正确指标”。没有一个指标可以统领一切。它是一组你需要从 AI 采纳中去衡量的东西的组合。你可以考虑用 AI 来衡量代码质量——你能提升代码质量吗？你能通过引入比如我们的 GitHub Advanced Security 来提升代码的安全性吗？

所以有很多不同的指标，组合在一起就能呈现给你开发者的生产力。然后还有开发者生产力、开发者协作、节省的时间，这些汇聚在一起就产出了开发者的幸福感。我们目前最大的聚焦领域是对”生产力”的定义，因为有大量用户来到 GitHub，他们追求的就是生产力的提升。

但有一点我们非常清醒：随着我们持续演进 Copilot，将 AI 推向软件开发生命周期的各个环节和所有工具，生产力并不是适用于每一个组件的正确指标。当我们在 GitHub Advanced Security 中引入 AI 时，写出更安全的代码才是正确的衡量维度——比如我们阻止了多少密钥泄露？在代码中我们检测、发现并修复了多少问题，在它们随产品发布之前？

AI 指标的探索

Inbal Shani： 所以我认为 AI 相关指标的世界确实是一个很大的课题。我们正在与客户进行大量合作，因为他们在问同样的问题，并在各自的公司内部进行自己的实验，想弄清楚到底想要衡量什么。最简单的一个指标是时间，但时间——说起来有点好笑——时间并不是一个可量化的成功指标，因为你可以非常快地写出非常糟糕的代码。

所以真正的问题在于，我们如何将时间转化为效率、转化为生产力、转化为那些更难衡量的东西，然后再看它如何导向开发者的幸福感——这又是一个更难衡量的指标。所有这些输入指标的组合，最终指向开发者幸福感，这才是我们聚焦的方向。

Lenny： 是的，这很有意思，因为工程师最终可能会花更多时间写代码——因为他们更享受这个过程了，也做出了更多成果。而且，代码行数也不是一个好指标，因为你无法知道那些是不是好的代码行。这是一个经典的错误衡量工程师的方式。所以对我来说，开发者幸福感才是终极指标。我们之前邀请过 Nicole 来播客，她提出了 DORA 框架，那是一种衡量开发者体验和开发者幸福感的有趣方式。

从时间到价值

Inbal Shani： 没错。我们在与客户交流时，一直在思考如何重新表述这个问题——与其谈时间，不如谈 value to value（价值实现时间）？也就是说，从你把一个开发者放到一项任务上的那一刻起，到实现其全部潜力或全部价值，花了多长时间？无论这个价值是产生收入、用户采纳，还是产品上市速度——你可以用不同方式来定义你的价值实现时间。

但归根结底，你投资 AI 工具是为了帮助开发者更高效、更快乐，那么它是否影响了你的价值实现时间？这正是业务方想要衡量的东西。

[广告段落已跳过]

AI 作为协作工具

Lenny： 回到这一切的发展方向——你应该见过那些演示：有人在纸上画一个网站草图，拍张照发给 ChatGPT，它就帮你把网站建好了。

Inbal Shani： 是的。

Lenny： 你怎么看这类应用的发展？你觉得未来会不会有 CEO 说，“这是我要的 iPad 应用”，画个草图，然后直接丢给 Copilot 第十版，它就帮你写好了？我知道你说工程师不会被削减，反而会增加、变得更高效，但我想问的是，这种”画个草图，帮我建好”的模式会走向何方？

Inbal Shani： 我把它看作一个更好的协作工具，而不是一个生产工具。因为目前我们看到，很多表达想法时的困难来自于沟通——思路不够清晰。如果我们能利用 AI 来改善协作，比如你把一张草图放到 Copilot 面前，它帮你讲清楚你到底在要求开发者做什么，这样就能省去大量反复沟通的来回。比如”你说的按钮在这里吗？""你想要粉色的吗？""你想要那个应用吗？""你想要那个操作系统吗？”

如果 Copilot 能帮助精炼沟通，它很可能成为市场上最好的协作工具，尤其是在我们当今这个全球化的环境中——不同角色的人在一起碰撞创意时，沟通始终是一个持续存在的挑战。在我们看来，AI、具体来说就是 Copilot，正在成为下一个自然语言对话的载体。

它就像一个翻译器，帮助所有人达成共识，因为它创造了一种通用的对话语言——就像数学曾经扮演的角色一样。

开发者的工具选择

Lenny： 这让我想起我之前和一位工程师的对话，他说他特别喜欢写那些简单的小函数，而现在 Copilot 替他做了这些，他有点失落，但他也不会关掉这个功能。他就觉得，“那才是我真正享受的东西，那些我能轻松搞定的小东西，比如某种排序函数。“我在想，当这么多代码都替我们写好了，我们是不是会失去什么？

Inbal Shani： 我认为每个开发者都有自己喜欢做的部分。你并不是非得用 Copilot 来写简单的代码。你可以通过聊天的方式使用 Copilot，把它当作 AI 助手来头脑风暴。我们提供的是一套工具，我们心里有一个使用场景的设想，但我们观察到的是，开发者们使用这些工具的方式各不相同。每个人都在选择自己偏好的使用方式，没有对错之分。

它是一个工具，一种语言。我学编程的时候，用的是 C，后来 Java 流行起来了，我心想，这不是在抢我的活儿吗——以前那些函数和库都是我自己写的，现在 Java 全都有了。后来 Python 出来了，又是一个更高的抽象层——好吧，现在我连这些都不用想了，因为 Python 全能搞定。所以关键在于你如何使用工具、用它们来做什么。有些领域我到现在还是会用 C 来写。

比如，如果某个东西需要在一个很小的 CPU 上运行，我才不信别人能替我高效地发明出那些算法——我会自己动手。但另一方面，有些东西我会委托给更高层的抽象工具，而这正是我看待 AI 的方式。你来选择如何使用它。没有什么放之四海而皆准的绝对真理让每个人都要照搬。你需要思考的是，如何使用你的工具来完成你的工作，同时保留那些让你感到快乐的部分。

另一方面，把你不那么享受的事情交给 AI。也许你喜欢写函数，但不喜欢写测试，那就让 AI 生成单元测试，让 AI 帮你做这些，你仍然专注于你享受的部分。

编程的乐趣

Lenny： 你现在还有时间写代码吗？还会在业余时间写一些 C 吗？

Inbal Shani： 现在有一点。目前主要是在陪我大儿子，他有更多时间钻研，但有时候我喜欢和他一起待着，一起头脑风暴、讨论问题和架构。几个月前，他做了一个关于传感器和传感器集成的项目，接触到了 common filter——那正是我很多很多年前做过的事情。

他就问，这是什么，怎么做的？然后我们就一起过了一遍，我帮他理清结构、传感器融合这些东西。有时候我会说：“好了，让开，看我的。这样就行了……”

Lenny： 打开 Copilot。开玩笑的。

Inbal Shani： 妈妈就是 Copilot。

Lenny： 太好笑了。这让我想起来，我看过你的一次演讲，你在很早以前——远在它变得很酷之前——就在做模型调优和训练 LMS。所以你在这个领域已经很久了。回头看，有没有什么你现在看到的发展趋势，是当时没有意识到的？

Inbal Shani： 我成长在一个小众 AI 的世界里——你必须成为专家，需要经过多年训练才能理解如何调优模型、什么是正确的输出，你需要懂得如何构建仿真来测试它、如何摄取数据、聚焦于优化。这些年我见证了 AI 的演进，从各种语音设备和对话式 AI，到后来从单术语发展为多术语。

所以我已经开始观察到 AI 更加民主化的趋势，但生成式 AI 的爆发是我没有预料到的。甚至连不知道 AI 是什么的人，都觉得自己需要用 AI。我觉得这是让我意外的地方，因为我一直被训练成”你必须成为专家才能使用 AI”的认知。所以对我来说那是一个顿悟时刻——嗯，这很有意思。接下来会怎样？

Lenny： 你对大语言模型是否就是这一切的终极答案有什么看法？只要持续增加算力和数据就够了？还是说你觉得地平线上会出现别的东西，再次彻底颠覆 Transformer 模型范式？

混合 AI 的未来

Inbal Shani： 我觉得我们非常激进地转向了生成式 AI 和”通用 AI 能解决一切”的方向。我认为未来会一定程度上回归小众 AI。我们将生活在一个混合的世界里——你仍然会有专门的 AI 模型来解决非常特定的问题，而生成式 AI 会有它的局限性。它是一个通用工具，上限取决于数据集的质量，而且它本质上是在做某种统计推荐——好不好？行不行？所以它受限于训练集，同时试图对所有人做所有事。

有些领域仍然需要训练专门的模型。比如我在航空航天和汽车行业花了很多时间。我没看到自动驾驶汽车模型——那需要极其精密的专用模型、精细调优、严格的安全法规，这些能在 ChatGPT 上开发出来。我可能是错的，但我认为最终我们会发现自己处在一个混合模型和多模型的世界里，会有多个大语言模型协同工作，因为每个都有自己的优势。

然后还会存在小众 AI，或者说针对特定用例的、更可配置的定制化模型。这就是我对未来的预测。不过十年之后，我们都会更聪明。

Lenny： 是啊，未来很难预测。

Inbal Shani： 没错。

Copilot 的诞生与创新机制

Lenny： 我想问一下，GitHub 提出了整个 Copilot 的概念。我们之前请 Ryan 来过播客，他讲过一个研究员只是在实验——我们用大量数据能做什么？然后这基本上就变成了，哇，这真的能用，赶快规模化并发布。

我想问的是，你从 GitHub 和 Microsoft 内部的巨大成功中学到了什么，来发现其他大机会？在产品团队的结构上，或者在为人们创造实验空间这方面，你有什么做法来找到下一个 Copilot 吗？

Inbal Shani： 很大程度上就是围绕这个。很大程度上就是为团队创造创新和实验的带宽，把那部分时间划出来，同时也要接受并非每个实验都会成功。所以转向”通过学习”或者”向前失败”——这些是我信奉的理念。如果你不去尝试、不去实验，你永远不会创新。如果你不失败，你永远不会从错误中学习，不会从经验中学习，也就不会进步。

所以真正创造那种实验能力——就像我们做 Copilot 时那样，或者我们做 GitHub Advanced Security 时那样，甚至 GitHub 本身的诞生也是如此——都是团队拥有那种创新思维，思考下一代用例是什么？未来的开发者需要什么才能开心、更高效、做好自己的工作？在一个软件开发变化如此之快的世界里，你必须为下一代、下一个创新创造那样的带宽。

如果你还没看过 GitHub Universe 两天的主题演讲，我强烈推荐，因为我们基本上分享了 Copilot 的下一个愿景——Copilot Workspace。我们还请了 Satya Nadella 上台，他非常兴奋，说：“天哪，GitHub，如果你们把这个做出来，太了不起了。“所以你会看到我们不断把这个愿景向前推进，至少在产品上市前六个月到一年就开始了——因为我们已经在思考、已经在创新、已经在做下一件事了。

Lenny： 除了”发布来学习”和”失败也没关系”这些原则之外，你还有做什么来促成这一点吗？在团队结构或资源配置上有没有什么方法？比如有没有规定一定比例的时间去思考其他想法？还是说基本上就是”我们接受失败，自己找时间做别的事”？

Inbal Shani： 有几件事。第一，花时间和客户在一起，向客户学习，因为很多创新的想法基本上都来自与客户的对话——他们会跟你分享他们的痛点，分享他们想要什么，分享什么样的发明对他们来说会很棒。所以第一件事就是建立这样的机制。我们花大量时间与客户交流，也与我们的社区交流。

我们很幸运地成为了所有开发者的家园、所有开源的家园。大型开源基金会和小型开源基金会都运行在 GitHub 之上。所以那是另一个反馈循环，帮助我们收集那些想法和需求，从而塑造未来。第二件事就是让团队来提案。“我有一个想法，我做了一些研究，这里有一篇论文描述了我想做什么”，然后我们一起想办法——什么时候能资助它？怎么资助？能不能分配专门的带宽？能不能做一个 POC？是在那个团队里做，还是组建虚拟团队？我们保持灵活性。我们还有一个研究团队，叫 GitHub Next，他们的日常工作就是思考下一个重大创新。但在 GitHub，创新来自四面八方。来自我们的现场团队——他们在与客户交流，为客户实施不同版本的 GitHub，然后带回来反馈或想法。

来自产品团队，来自设计团队，来自工程团队。无处不在。所以如果你试图把创新结构化，你就会失去那种人性化的有机火花。想象一下有人说你每天有 15 分钟用来发挥创意——我觉得这不是重点。所以更重要的是鼓励那种思维方式，而不是去结构化它。

Lenny： 能多说说你刚才提到的那个团队吗？叫什么名字？vNext 团队？

Inbal Shani： GitHub Next。是的。

Lenny： Next 团队。能多说说这个团队是什么、怎么运作的吗？

Inbal Shani： 他们基本上是应用科学家和研究科学家在一起协同工作，他们真正思考的是三到五年的远景。他们不是思考当下，而是在思考软件开发未来会是什么样子。他们在写论文，做实验，做概念验证。他们的工作就是发明未来。

但同样，这确实是一种协同效应，因为他们会与产品团队、工程团队交流，从中获得创意。他们也与客户对话，或者我们共享反馈。这就是我们的 GitHub Next，基本上就是我们的研究团队。

Lenny： Copilot 就是从这个团队诞生的，对吗？

Inbal Shani： 对。

Lenny： 这非常有趣，因为我想我和 Ryan 也聊过这个话题，很多公司都有类似的团队。比如 Facebook 有一个很有名的，叫新产品体验团队。Google 也有一个 Google……名字我忘了。但据我了解，它们都没有真正成功过，而这个团队成功了。你觉得你们有什么不同的做法吗？是不是更偏科学和研究导向，而不是产品经理们尝试一堆不同的应用？我不知道，你觉得这个团队成功的关键是什么？

GitHub Next 成功的原因

Inbal Shani： 我觉得有两个要素。一是团队中有对的人、对的思维方式，并给予他们创新的带宽和自由。二是我们专注于把事情落地。所以我们不会让他们远离产品、与工程脱节。

团队之间有很多协同、很多讨论，因为在我所见到的那些不成功的团队中，一种情况是团队基本上变成了一个大学——他们写论文，但什么成果都没有产出，所以没有任何东西最终走向生产环境。如果你不从第零天开始引入”我们如何把它带到生产环境”这个视角，当你构思一个新想法的时候，它就很难跨越那个鸿沟自行落地。第二种情况是，公司往往把这些团队用得过于战术化了——“我们六个月内需要某样东西，现在就去发明它”，然后他们基本上又创造了另一个工程团队或产品团队，去思考的不过是当前视野内的东西。

所以我认为在 GitHub，我们找到了恰当的平衡：拥有对的人、对的思维方式，同时也在未来思考和如何将其落地之间创造协同效应。所以我们建立了很强的联系，特别是产品团队和 GitHub Next 之间，确保这种关系持续运转，创意双向流动。

首席产品官的技能成长之路

Lenny： 你现在是 GitHub 的首席产品官，我觉得这是很多人梦寐以求的工作。初级产品经理、高级产品经理都想知道如何走到你今天的位置。我很好奇，你觉得什么最有助于你培养胜任这个角色所需的技能？是导师、高管教练，还是长期实践积累？或者其他方面？

Inbal Shani： 各种因素的结合。从来不是单一因素，因为首席产品官的角色范围太广了。你不仅仅是产品负责人。这也是行业内正在演变的一种认知——首席产品官不仅仅是产品负责人。他们需要具备商业思维，需要理解市场进入策略（go-to-market strategy），需要理解销售打法，需要理解工程师如何构建产品。这不仅仅是”让我写一组需求文档”或者”思考愿景和未来”那么简单。

而是公司内所有这些组件如何协同运作来构建产品。其中一部分是从你跟随的领导者身上学习，观察他们的思维方式。从我在航空航天行业的第一位老板那里，我学会了系统性思维——不只是思考我当下正在解决的那个问题，而是我负责解决的这个问题、我负责调优的那个滤波器，如何与整个控制系统、点火系统等连接起来，以及最终如何呈现出来。这就要求我从一开始就着眼于更大的解决方案，而不仅仅是我自己的组件。

我觉得这是其一。第二是真正去思考人和变革管理，以及如何带领人们一起前行，因为产品经理的角色是一个非常有影响力的角色，你做的很多事情都是在影响他人。虽然大家都觉得作为产品经理你可以做很多事情，可以写各种文档，但你需要影响工程团队去构建你希望他们构建的产品。你需要影响营收团队按照你设想的方式去做市场推广和销售产品。所以这里有大量的影响工作。你需要理解如何做到这一点，而且作为产品经理，从一开始就培养这套技能非常关键。

对我来说，幸运的是我在行业中做过不同的角色，从不同的人那里学到了东西，同时也在向上看、向平级看、向下看——管理的人身上我能学到什么？他们有哪些技能是我工具箱里没有的，我怎样才能吸收采纳？成功是什么样的，哪些因素会让人不快乐——而有些工具你并不想放进自己的工具箱里。所以这就是大量的”什么该要、什么不该要”的组合。

Lenny： 对，正如你所说，是所有这些因素的结合。我非常喜欢最后那一点——识别出那些在你想要提升的方面做得好的人，然后向他们学习，观察他们，也许问他们一些关于他们工作方式的问题。我想在播客中尝试一个新环节，叫做”失败角落”（Failure Corner），我的问题是：你职业生涯中最大的职业或产品失败是什么？你从那次经历中学到了什么？

失败角落

Inbal Shani： 我称之为最大的学习，因为我不相信失败这种说法。我相信的是学习。每次你失败，都是一次重要的学习，我更愿意把这些看作机会。我觉得最大的一个可能是在我刚开始做领导者、做团队管理者的时候。我是一个非常”冲冲冲”的人，精力充沛。当我面对一件事，看到所有需要修复的问题时，就会想：好，把工具箱拿出来，把所有东西都修好。这其中包括推动变革。

我发现当我开始这样做时，如果没有先建立对”为什么我们需要做这个变革”或”为什么这是我们必须要去解决的问题”的理解，你就无法带领人们一起走过这段旅程。所以真正要认识到的是，不是每个人都能像你一样欣赏变革，不是每个人都有那种”冲冲冲、干就完了”的心态。真正需要做的是退后一步，评估当前的状况，这样你才能带领团队一起走上变革的旅程。

对我来说，这是最大的学习。可能当时团队给我的很多不太支持性的反馈就是，“你走得太快了。慢下来。解释一下为什么。我们为什么要这样做？我们应该怎么推进？”

Lenny： 这具体是在哪里发生的？哪家公司？什么角色？

Inbal Shani： 是在 TomTom，当时我负责领导基于位置服务的团队。对我来说，一方面这是我第一次在国际化公司工作，所以我真正体会到我的性格并不总是能适应每一种文化。那我该如何调整自己去适应？另一方面，那个团队已经非常习惯于在特定的环境中以特定的方式工作。是的，我被雇来推动变革，但团队并不一定要接受——推动变革是你的工作。

而且他们未必认同”你来这里就是为了推动变革”这件事。所以如何带着他们一起走过这段旅程，是一个很大的学习；能够用一种通用的沟通方式来推动清晰度，这也是一个很大的学习。

Lenny： 这其实是”失败角落”中反复出现的主题——我想到的那些失败故事，都是某人加入一家公司后试图太快地改变太多东西。

Inbal Shani： 对，这非常常见，因为我们是人。我们觉得自己来了，带着过往的经验，来到一个新环境，你立刻就能看到所有不正常的地方、所有需要修复的问题。如果你在同一个团队、同一个领域工作了很长时间，你往往已经看不到这些差距了，因为你已经习惯了与它们共处。

所以作为一个新人，你一进来就立刻看到所有的漏洞和裂缝。你会想，好，这些就是我需要修的。但你的团队一直在那里待着呢。所以你怎么找到那座桥梁，去沟通你所看到的和他们认为没问题的事情——“你为什么要推这些变革？现在不是挺好的吗？别动它。”

Lenny： Inbal，在我们进入非常令人期待的快问快答环节之前，还有什么想分享的吗？

GitHub 宇宙大会与职业感悟

Inbal Shani： 对我来说，这是一个令人兴奋的时刻。我刚刚庆祝了加入 GitHub 的第一年，上周还第一次在 GitHub Universe 的舞台上亮相。对我来说，与我们的客户和合作伙伴见面，大量讨论开发者体验的重要性、我们的 AI 驱动平台，以及我们如何塑造未来——这是一段非常棒的经历。所以在 GitHub 的这段旅程中，我正处于一个非常令人兴奋的阶段。

如果你没有犯过一些错误、做过一些学习、取得过一些成功，然后走了正确的转弯，有时走了错误的转弯，但最终找到一条让你感到快乐、作为产品领导者感到充实的道路——你就不会走到今天这个位置。

Lenny： 太棒了。我们会在节目备注中放上那场演讲的链接，供想看的人观看。那么，我们到了非常令人期待的快问快答环节。准备好了吗？

Inbal Shani： 准备好了。

快问快答

Lenny： 你最常向别人推荐的两三本书是什么？

Inbal Shani： John Maxwell 的《Failing Forward》，Jim Collins 的《Good to Great》中的飞轮理论，以及我最近读的一本叫 Dalia Feldheim 写的《Dare to Lead Like a Girl》。

Lenny： 这本书在节目中是首次被提到，很棒。你最近最喜欢的电影或电视剧是什么？

Inbal Shani： 我很喜欢奇幻类和历史题材的电影和剧集。最近 Netflix 上出了一部《All the Light We Cannot See》，非常棒。制作精良，讲述了一段非常有趣的二战历史。

Lenny： 既然你喜欢奇幻，你看过 Amazon Prime 上的《Wheel of Time》吗？

Inbal Shani： 看过，我很喜欢。拍得很好。

Lenny： 对，尤其是第二季，真的很惊艳，比第一季好很多。下一个问题——你有没有一个最喜欢的面试问题，喜欢在面试候选人时问的？

Inbal Shani： 我非常喜欢问的第一个问题是：你做过的最具创新性的事情是什么？为什么你认为它具有创新性？很有意思的是，有些人觉得他们需要回答自己做出的最伟大的发明，而有些人则非常坦诚，会谈论一些他们在个人层面所做的创新。

这很能体现一个人的性格。我经常喜欢问的第二个问题是：举一个你与你的经理产生分歧的例子，你和经理意见不合，然后你做了什么，怎么处理的？因为这能很大程度地展示你的性格——你是否愿意在必要时坚持自己的立场并向上推动？以及你的沟通技巧和影响力如何？

Lenny： 你有没有一个最喜欢的人生格言，经常分享给他人，在工作或生活中时常回想起并觉得有用的？

Inbal Shani： 我觉得是：如果你不冒险，就无法创造未来。我忘了是谁说的，好像是动画《Monkey Luffy》里的。但它基本上概括了我的人生信条——你必须冒险，必须尝试。如果你感到舒适，那不是一件好事。你总是需要感到不舒适，才能拉伸自己走向下一个阶段。这也是我一直以来的做法。你刚才听到了我的职业故事——从应用科学家到首席产品官，谁能想到呢？

Lenny： 我很喜欢这个格言。Inbal，非常感谢你来参加节目。最后两个问题：大家如果想在网络上找到你、跟进相关内容，去哪里找？以及，听众怎样才能帮到你？

Inbal Shani： Universe 上有很多精彩的演讲和分享。如果大家想更多了解我们在做什么、我们如何思考 AI，LinkedIn 可能是找到我的最佳社交媒体平台，在那里我有机会与很多人交流。这些是最好的渠道。

Lenny： 那听众怎样才能帮到你？

Inbal Shani： 如果你能分享类似的经历或故事，觉得对我在思考”担任 GitHub 首席产品官意味着什么”这件事上有帮助的话；或者关于你如何使用 GitHub 的技巧和窍门，也许我能学到些什么；又或者分享你的经历和故事，让我也能从中学习。

Lenny： 太棒了。Inbal，非常感谢你来到节目。

Inbal Shani： 非常感谢你的邀请。

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

术语表

原文中文
10X engineers10X 工程师（指产出远超普通工程师的顶尖开发者）
Accenture保留原文（埃森哲，全球咨询公司）
All the Light We Cannot See保留原文（Netflix 剧集，改编自 Anthony Doerr 同名小说）
applied scientist应用科学家
AR (Accounts Receivable)应收账款
change management变革管理
code review代码审查
common filter保留原文（疑为 Kalman filter / 卡尔曼滤波的转录错误，一种传感器数据融合算法）
Copilot Workspace保留原文（GitHub 推出的 AI 辅助开发工作空间）
CPO (Chief Product Officer)首席产品官
Dalia Feldheim保留原文（作者）
Dare to Lead Like a Girl保留原文（书名，意为”敢于像女孩一样领导”）
discussions and postsdiscussions 和 posts（GitHub 功能）
DORA保留原文（DevOps 研究与评估框架，由 Nicole Forsgren 等人提出，用于衡量软件交付效能）
eat our own dog food吃自己的狗粮（指公司内部使用自己开发的产品）
Failing Forward保留原文（书名，意为”向前失败”）
Failure Corner失败角落（播客环节名称）
GitHub Advanced Security保留原文（GitHub 高级安全产品）
GitHub Next保留原文（GitHub 的前沿研究团队，原称 GitHub vNext）
GitHub Universe保留原文（GitHub 年度开发者大会）
go-to-market strategy市场进入策略
Good to Great保留原文（书名，意为”从优秀到卓越”）
human in the loop人在回路
Inbal Shani保留原文（GitHub 首席产品官）
Jim Collins保留原文（美国管理学者与作家）
John Maxwell保留原文（美国领导力作家与演讲者）
Lenny保留原文（播客主持人，即 Lenny Rachitsky）
LMS保留原文（此处指语言模型系统/大型语言模型的前身）
load testing负载测试
Monkey Luffy保留原文（疑为动漫《One Piece》角色 Monkey D. Luffy 的简称）
Nicole保留原文（指 Nicole Forsgren，DORA 框架的提出者之一）
one metric to rule them all一个指标统领一切（源自《指环王》的经典表达）
penetration testing渗透测试
POC (Proof of Concept)概念验证
PR (Pull Request)保留原文
Ryan保留原文（Lenny 在其他访谈中提到的对话对象）
sales play销售打法
Satya Nadella萨蒂亚·纳德拉（微软 CEO）
Shopify保留原文（电商平台公司）
time to value价值实现时间（从任务启动到实现业务价值的时间跨度）
TomTom保留原文（荷兰导航与地图技术公司）
Wheel of Time保留原文（Amazon Prime 奇幻剧集，改编自 Robert Jordan 同名小说系列）

此文档由 AI 分片翻译（translate_long_document）