图片来源：YouTube

Z Highlights

• 可引导性（steerability）是下一个关键点。你需要扩展问题的定义，或者Agent需要回来提出更多问题。在流程的最后，你要验证结果。

• 但与此同时，市场发展变化极快，无论是与OpenAI、Entropic还是Google会面，我们都能了解到新的模型版本，路线图每天都会发生变化。

• 虽然我们认为，从纯粹的安全性和信任角度看，代码审查不会消失，但你总是希望在将代码合并到生产环境之前，至少有另一个人参与其中。

• 可能五年前，如果我告诉你自动完成将成为一个独立的功能，由AI驱动，并且其费用超过GitHub所有功能的平均售价，你可能会说，这听起来不可能。

Thomas Dohmke是Github CEO。在视频中，他与Sarah、Elad讨论了AI驱动软件开发的崛起以及Copilot的成功，包括Copilot如何重新塑造开发者的工作流程，GitHub新推出的Agent Mode，以及开发工具市场的竞争。

GitHub Copilot的功能

Sarah：大家好！今天，我们请来了GitHub CEO——Thomas Dunk。GitHub是全球超过1.5亿开发者协作和构建软件的平台。作为首席CEO，Thomas领导了GitHub Copilot等工具的开发。

在成为CEO之前，他帮助制定了GitHub的产品战略，并推动了其全球扩张，他也曾在微软工作。今天我们将讨论软件开发的未来、AI编码的作用、开源以及Copilot的产品计划。Thomas，欢迎来到No Priors！我们可以直接进入正题：最近GitHub发布了哪些新功能？Copilot现在的情况如何？

Thomas Dohmke：非常兴奋的是，我们正在让Copilot变得更智能。几天前，我们在Copilot和VS Code中推出了“Agent模式”。

现在，你能与Copilot聊天，获得回复后将代码复制粘贴到编辑器中，或者使用自动完成（这是原始Copilot的功能）。此外，你还可以与Agent一起工作，它能帮助你实现一个功能。当它需要一个安装包时时，它会显示终端命令，你只需说“运行它”。你仍然是掌控者。

这些Agent的关键部分是，作为开发人员，你仍然需要保持在整个环节中。但我们也展示了2025年即将推出的功能的预告，我们把这个项目叫做“Padawan”，因为它像一个绝地学徒。

你必须有耐心，并学会如何借力。到2025年，我们将进入一个怎样的阶段呢？你可以把一个定义明确的GitHub问题分配给Copilot，然后它开始创建一个草拟的pull request，列出计划，并进行工作。像观察同事一样，你能看到它如何在pull request中提交更改，并可以审查这些更改，向Copilot提供反馈。

从此，GitHub Copilot从一个简单的“结对编程助手”进化成了一个“团队成员”级别的工具，能够更独立地参与开发工作。

Elad：现在的障碍是什么？是一些新的模型进展吗？是仅仅在构建其他核心技术吗？还是只是UI方面的调整？现在是什么阻碍了这个功能的实现？

Thomas Dohmke：首先是模型问题，完整的o3模型目前还没有发布，OpenAI在假期前发布的一部分就是这个模型。

我们将看到推理能力的提升。随着模型在推理能力上的进步，我们将越来越接近100%的VBench标准，这是一个由Princeton团队通过12个开源Python仓库识别的2200个左右的issue和pull request对子，所有的模型和Agent都将以此为基准进行评测。

所以这是第一点，就是模型和Agent的结合。第二点就是弄清楚什么是正确的用户界面流程。如果你想一想开发者的工作流程，你会有一个别人为你提交的问题，可能是用户、产品经理或者你自己提交的。

现在，你怎么知道是否应该将Copilot或Agent分配到这个任务上，或者是否需要进一步细化问题以使其更具体？关键在于Agent必须是可预测的，你需要知道这是一个Agent能够解决的任务。如果不是，那么你需要引导它。

可引导性（steerability）是下一个关键点。你需要扩展问题的定义，或者Agent需要回来提出更多问题。在流程的最后，你要验证结果。在demo中，正确的流程是Agent能像人类开发者一样在Pull Request中工作，能有多次提交。

然后，你可以查看这些提交或在VS Code中检查它们。对于一些现有的Agent，开发者实际上是否能容忍它们呢？它是否真的节省了时间，还是说其实浪费了时间？

如果它经常浪费你的时间，只是消耗计算资源，那么你再次使用它的可能性就会降低。如果Agent是可预测的、可引导的、可验证的且可容忍的，并且在这四个标准上都达到一定水平，能看到Agent被广泛采用。

Agent会取代开发者吗？

Elad：这些Agent距离达到中等程序员的水平还要多久？还需要多长时间才能达到超人类的水平？

Thomas Dohmke：我今天早上还在思考这个问题。无论你想到的是哪种，旅行Agent、编程Agent，或者是设计你房子的Agent，根本的挑战实际上与人类开发者面临的挑战是一样的。

比如，你脑海中有一个想法，你可以在白板上画出草图。但当你开始编码时，你需要将这个大的想法分解成小块的工作——这正是我们离Agent真正能够胜任的地方还很远的地方——它们无法在没有开发者或架构师的情况下，将一个粗略的想法分解成小块的任务。无论是编程还是规划旅行，Agent都会不断向你提出问题，询问你需要做出哪些决定，比如选择什么数据库、什么云服务。想象一下，如果你给Agent一个任务，比如“构建GitHub”或“构建一个移动应用”，这样的任务描述显然不够具体。所以，这种系统性的思考能力，中等水平的开发者不会被Agent取代。

另一方面，开发者做的很多事情是处理问题、修复漏洞、找到需要修复的地方、添加一些来自客户的功能，浏览代码库并确定需要修改哪些文件。在这方面，我们将在未来几年看到巨大的进展。实际上，当我们为Padawan录制demo时，我们让一位产品经理提出一个问题，并由Agent独立创建了pull request。

一个通常不写代码且不参与代码库编写的产品经理，能够利用这个Agent创建一个真正的pull request，随后由开发人员进行审查并合并到代码库中。所以在某些方面，我们已经走到了这一步。在其他方面，我们还需要达到一个信任的程度，能让你每天都在使用它。

Copilot的开发周期

Sarah：你们在发布Agent Mode和Padawan之前也做了很多自我测试吧？也许如果我们从评估阶段稍微放开一点，能否描述一下今天Copilot的整体开发周期是什么样的？比如你们是如何进行规划和决策的，决定尝试什么，以及如何改进它？

Thomas Dohmke：行业现在称之为AI工程，也就是说，我们正在通过AI开发扩展后端和前端开发的完整技术栈。那么应该如何使用新版本的模型，或者像现在我们在Copilot中有模型选择器一样，我们不断地处理来自多个供应商的多个模型，如何将它们集成到我们的技术栈中呢？

我们有一个应用科学团队进行评估，负责构建这些基准，供应用科学团队用来比较不同模型之间的差异，同时还有那些构建功能的团队，比如代码审查Agent、三个Agent或Agent模式下的用户，他们将验证他们的工作作为测试套件的一部分。

现在不再仅仅是数据科学家和工程师，这些角色之间的界限越来越模糊，他们经常协作。我们进行大量的实验，使用A/B测试，在离线测试之后，我们先在GitHub和微软的员工中进行在线测试，然后再进行一部分人群的测试。总体来说，显然我们有一份功能路线图，我们希望构建一个长期的待办事项列表，这不仅仅是为Copilot，而是为GitHub的所有功能。

GitHub今年已经18岁了，从2007年末创始人开始工作的时光，到2008年初它才正式发布，而微软则将在4月4日迎来50周年。我们有一个很长的客户反馈待办事项，我们正使用Copilot在Agent模式下构建这些功能，以加速我们的功能交付。

但与此同时，市场发展变化极快，无论是与OpenAI、Entropic还是Google会面，我们都能了解到新的模型版本，然后路线图每天都会发生变化。你们也看到了这种情况，市场确实变化如此之快。简直是在一个指数增长的创新曲线上，跟得上都很困难，而且你根本无法提前规划超过一个月或两个月的时间。

赢得开发者市场

Sarah：你为什么认为竞争会处于那个指数曲线的状态？像你所描述的“套件Agent”这样的东西，居然在一年前还没有这个概念。现在，我们的市场充满了那些在试验这些产品的人。

在像GitHub这样显然是非常强大的平台上，如何赢得开发者的青睐，尤其是在这个快速变化且竞争激烈的市场中，开发者真正关心的是什么？

Thomas Dohmke：胜利的原因是，我们非常关心开发者，这一直是GitHub的核心——我们把开发者放在第一位。我们是开发者，为开发者打造产品。在GitHub有一句话：我们用GitHub来构建GitHub，用GitHub来开发。所以我们在公司做的每一件事，包括我们的法律条款、HR政策、产品管理、销售、销售支持，所有这些职能，都在GitHub的issue、讨论和仓库中。

首先，我们非常关心自己的产品，且每天都在使用它。我早上做的第一件事就是打开手机上的GitHub应用，然后是Slack，因为我们公司很多操作和聊天都通过Slack进行。

第二点，你提到了竞争。我从未见过开发者领域有过像现在这样的情况。对我来说，这是开发者工具领域最激动人心的时刻。我已经做了30多年的开发者。

现在每天都在涌现出创新的新闻，这真是太震撼了。这种市场上的能量和创新驱动，无论是开源领域还是闭源领域，都是非常重要的。我们不能忘记，这不是单方面的。

虽然专有模型和软件有创新，但在开源领域，特别是GitHub上，也有同样多的创新。这股能量显然也会吸引到我们。我是一个超级F1赛车迷，所以竞争是件好事，因为如果有多个队伍有机会赢得冠军，比赛会更加有趣。

我们也有相同的感受，竞争激励我们每天醒来时更加努力，做得更好，行动更快，最终凭借市场上最好的产品赢得胜利。

Sarah：你们拥有非常丰富的数据，能看到人们是如何实际使用Copilot的呢？自从Agent Mode发布以来，最近一周你们有发现什么令人惊讶的事情吗？

Thomas Dohmke：从早期开始，我们总是感到惊讶的一点是，Copilot写了这么多代码。在你们的播客中，一些来自微软和GitHub的人曾经提到过，早在我们推出Copilot预览版后，它就已经写了大约25%的代码。我记得那次会议，在产品评审时看到这个数据时，大家都认为这一定是遥测数据中的一个错误。

回去验证一下。不能是真的只运行了25%的代码，因为它只是自动补全而已。虽然这很酷，但在早期，它还是犯了很多错误。

但我们很快意识到，其一，那个数字是对的；其二，那只是软件开发者的习惯行为。就像你在输入代码时，总会有需要查找的地方。于是你会去浏览器，找到Stack Overflow、Reddit、博客或者GitHub上的代码，然后复制粘贴，之后再进行修改。

实际上，内部循环总是这样的：你写点东西，尝试用编译器和调试器调试，然后不断修改，直到它能正常工作。这个数字很快就上升到了大约50%，具体取决于编程语言。如果现在看这些Agent就会很难再测量这个数字，因为可以直接进入Agent mode，告诉它，我想用Python做一个贪吃蛇游戏，然后它就会为你写出所有代码。

它会写多个文件，因此分母变成零了。就像是无限的百分比，因为你唯一写的东西就是一个提示，而两年前需要15分钟的demo现在只需要1分钟。这在很多方面仍然令人惊讶，我们已经走在那条“曲线”的前面。

相反的情况也是真的。你可以让它处于一种状态，不断重写同一个文件，或者删除文件，因为在某种程度上说，它在逻辑上卡住了。所以，这也让我们更接近现实：我们还远未接近一个可以自主处理我的所有GitHub问题，并为我修复所有积压工作的Agent。

我所做的唯一事情就是验证并成为软件开发智能体的代码审阅人。所以，我们现在在这之间摇摆：一方面，它的进步让人兴奋；另一方面，它会在一些非常简单的场景中卡住。比如你尝试通过提示告诉它做一件事，它最终还是让你自己去文件中改背景色。

GitHub的未来发展方向

Elad：很有道理。除了你们正在做的很多智能体相关工作——这确实目前最有趣的事情，此外你们还希望GitHub在接下来的几个季度有什么其他重要的演变吗？是否有其他重要的方向，还是说一切都聚焦在AI上，成为公司关注的重点？

Thomas Dohmke：目前为止，我们只讨论了通用智能体：你可以提出一个问题，它会生成一个pull request。但如果你了解开发者的日常生活：在大多数公司里，实际上写代码的时间可能只有你一天的两三个小时。然后你会花同样多的时间审查同事的代码。虽然我们不认为从纯粹的安全性和信任角度看，代码审查会消失，但你总是希望在将代码合并到生产环境之前，至少有另一个人参与其中。

同时，我们认为代码审查Agent和代码审查是一个大话题，AI可以在其中提供帮助，特别是当你和分布在不同时间区的团队合作时：团队成员不希望等到西海岸的人醒来后才能得到初步反馈。所以代码审查是我们关注的一个重要话题。

再次强调，AI是其中的一个部分，但用户界面同样重要。理想情况下，你可以在得到反馈后，与代码审查Agent一起处理反馈，形成循环。因为你不可能每次都得到完美的反馈，以至于只需要点击接受、接受、接受。你需要一个用户界面和云环境，在那里你可以直接打开它。如果每次都需要在本地机器上克隆仓库、安装依赖、切换分支，那依然在做过多的繁琐工作。

所以，迁移到云环境，让你可以直接尝试来自代码审查的变更，并能够修改它们使其生效，有快速的外部反馈循环，这是同样适用于安全漏洞的领域，我们希望代码扫描不仅能发现漏洞，还能修复它们。一个更简单的版本是linter错误，比如代码格式化等问题，希望这些都能消失，AI直接修复，而不是你需要逐一浏览100个linter警告，告诉你应该在哪里放置括号里的空格。但如果你查看任何一个中等规模的软件项目，你会发现它有过时的依赖，存在许多已知的、可能不是高风险的软件漏洞，虽然这些漏洞大多是低风险的，或者有些人决定现在不修复，因为这些代码无法访问，或者我们有其他优先事项。有AI来消除这些安全积压，将大大提升开源生态系统和许多商业软件项目的质量，因为它能降低一些工作量，例如每个工程经理会在技术债务、遗留代码、安全性、可访问性、欧洲法规等方面来回摇摆。

同时，创新积压也是一个问题。二者之间没有真正的平衡。是销售团队告诉你，如果不获得那个特性就无法销售产品，还是安全团队告诉你，必须修复那个问题，否则我们会向管理层报告？所以，这是AI方面的内容。但是同样，GitHub作为一个平台需要发展，以支持并提供所有必要的原语，使这些Agent和AI能够与人类协同工作。

面对 AI 带来的新挑战

Sarah：在这个转变过程中，还有哪些问题是人们尚未解决的？这种转变是关于软件开发的方式的变化。举例来说，你是否觉得我们已经处于一个临界点，可能今年大部分代码都已经由AI生成，甚至在某些情况下，所有的代码或某些任务都将由AI生成？这会如何改变我们对测试、技术债务等的看法？

Thomas Dohmke：通常来说，并不是所有的代码都是由AI编写的。这种方式的运作是，我们有两层结构。有机器语言层，就是Python、Ruby或Rust。这些实际上是芯片指令集的抽象。那是最后一层确定性的层次，编程语言本质上确切地做我想让它做的事。

而人类语言本质上是非确定性的。我们三个人可以说同样的句子，却表达不同的意思。所以，尽管我们会使用人类语言来描述我们要构建的许多功能和行为，但下面依然会有编程语言这一层。

工程师会来回讨论，看看AI编写的代码是否真的正确，它是否符合成本配置，毕竟我们还是必须要有正利润率。

作为工程师，我们会有这两层结构。而且我们正在走向一个更多使用人类语言而少用编程语言的世界。但与此同时，很多金融服务机构仍然在大型主机上运行COBOL代码。

我们距离把那些三四十年前的代码直接转化为云应用程序的那一天还很远。这一天会到来的，但就像自动驾驶汽车一样也会到来，只是我们不知道何时会发生，在那时你可以拥有一辆没有方向盘的车，带你穿越国内每一个地方。

它在旧金山的Waymo系统上工作得很好，但从SFO到San Jose的Waymo系统还不能完全实现。范围会扩大，但离解决所有技术债务和遗留代码还很远。所以，至少在未来十年，我们仍然会有软件开发人员在处理很多老式的，比如PHP代码、COBOL代码等等。

与此同时，在网络开发和AI的另一端，你将能够……而我们已经到了这一步。只要看看一个10岁的孩子，给他们一个像Copilot、Repl.it、Bolt之类的工具，让他们输入几个问题，并让他们探索这些工具如何工作，他们就能自己渲染软件并进行迭代，类似于Fusion Mixed Journey。

Sarah：你领导着一个庞大的软件工程师团队。正如你所说，你们有更多的人类语言指令而不是机器语言。这是否改变了你对团队的要求，或你想要在团队中开发的内容？

Thomas Dohmke：这是一个关于如何具体描述一个足够明确的问题，以便一个Agent可以接手对吧？基本上是软件开发中的计划和跟踪问题，这个问题通常是你在有了一个不错的团队规模后会遇到的最大挑战。

比如一个10人初创公司没有问题，而且大多数10人的初创公司并没有产品经理，创始人就是产品经理，其他人只是负责构建东西。

如果你有一个问题要解决，沟通路径非常短。如果你有一千个工程师，他们最大的问题是：你想构建什么？你怎么构建它？

当你写下这个东西时，你到底是什么意思？如果你看这个领域，目前还没有太多AI在帮助你。我们自己也处在这个早期阶段，和Copilot Workspace一起，我们有一个规格和一个头脑风暴Agent，它基本上会查看你在GitHub问题中写的内容，将其与代码库进行比较，并用人类语言描述前后的变化。

然后你可以像编辑Notion文档一样修改它，并基本上向规格中添加内容。所以这将是我们在产品管理领域带入的一整套Agent行为。对于设计师来说也是类似的。

今天，很多设计都是在Figma中手绘的。未来，作为设计师，你将有效地像产品经理一样编写相同的规格，并且有一个AI来渲染线框图的代码，然后根据你的设计系统应用基础内容，使它看起来像你的产品。这些学科将更加紧密，产品经理如果擅长写规格，将能够创建整个变更集。

设计师将能够接管部分产品管理角色，而工程师如果擅长描述功能，也能接手那部分。所以这将是很多创新发生的地方，并重新思考，随着我们拥有越来越多这些Agent，它们实际上擅长自己所做的事情，未来几年软件工程团队中传统学科如何发展。

开发工具市场的形成

Elad：当你思考这些不同的Agent和这些不同的应用场景时，是同一家公司或产品去提供这三者吗？会是同一个界面吗，还是不同的？我有点好奇你如何看待实际的流程，虽然在某些方面有不同的用户，但它们在某种程度上有重叠的责任或目标。

他们使用的工具集是什么？是单一的工具还是很多工具？是一个公司还是很多公司？它是从哪里启动的？你是怎么理解这些事情的？

Thomas Dohmke：在GitHub，我们最强烈的信念之一是开发者的选择。如果GitHub只是一个平台，只有JavaScript库可用，或者只有React可用。

我们会告诉你，这就是你开发应用所需要的唯一开源库。那时会有一部分用户因为喜欢React而使用GitHub，其他人则会去其他地方，因为其他平台会提供这些其他开源组件。在AI领域，我们会看到同样的事情。

我们将看到一个由不同公司组成的技术栈或生态系统，这些公司提供软件开发生命周期中的不同部分。开发者会选择他们最喜欢的、最有经验的、对未来有信念的公司。很多这类选择都是基于一种信念体系。

在很多方面，编程语言是非常相似的。如果你看一下开发者之间的讨论，你会感觉它们彼此之间差异很大。归根结底，它们都在编译成可以在你的Apple M1芯片、Intel CPU、AMD或者NVIDIA等平台上运行的指令集。

所以我们将会有一堆不同的工具栈，并且会有公司提供所有这些工具……当然不是所有工具，因为你永远不可能从一个公司手中获得所有的开发者工具。想想GitHub，我们是一个大型平台，但你仍然需要一个编辑器、操作系统、容器解决方案，以及一个不来自GitLab的云服务。

比如说，HashiCorp的Terraform或Vault，或者Vercel和Next.js，都是另外的例子。你可以去湾区的任何一家公司，他们都会有一套不同的工具栈，因为他们相信这是当前最适合他们的。在这个AI的世界里，也会有相同的情况。

你将会有不同的选择。你已经可以选择不同的模型，有些人认为Claude模型更好，其他人认为OpenAI模型更好。事实上，现实情况介于两者之间，在不同的场景下，不同的模型会有不同的优势。

在我们即将步入的智能体未来中，情况也将是一样的。

Elad：考虑到我们现在看到的泛化能力（generalizability），这种情况是否成立？换句话说，如果你去掉X%的模型，只剩下你提到的某一个模型，到了一定程度，你还是会非常满意的，考虑到四五年前我们拥有的相对能力。

这有点像是，我们有很多很棒的选择，而有些东西比其他的更好。但从根本上讲，任何一个这些选择，无论用什么基准衡量，都会非常出色。

Thomas Dohmke：这取决于我们谈论的最终状态是什么。比如如果奇点来了，那这些都不重要。

Elad：五年后？

Thomas Dohmke：你知道，我们几乎是在五年前，2020年6月，开创了Copilot。

Elad：那时是什么？是GPT3吗？

Thomas Dohmke：GPT3其实是最初的实验阶段。然后我们得到了CodeX，这是一个专门针对代码的版本。而今天，这个版本实际上已经不再存在了。现在，每个人都在更强大的基础模型之上运作。

Elad：没错。这正是我想说的，从某种程度上说，泛化性开始占主导地位。所以我有点好奇，你是如何看待泛化性与专业化的关系，以及对于智能体的五年时间预期。

Thomas Dohmke：我能看到这种情况在模型层面发生。但这又像是预测一个问题——我们什么时候真正会有自动驾驶汽车呢？我有一辆特斯拉已经10年了，配备了自动驾驶和自动驾驶辅助系统，但它依然无法顺利左转进入我的小区。

我能看到那个未来，但我不知道它会是什么时候。而当所有的模型基本上都差不多的时候，对于软件开发者来说，最低层次的区别并不重要，直到在更高层次的技术栈中有所差异。

我觉得编程语言或者开源库就是很好的例子，因为如果你把视角拉得足够远，它们其实都差不多。从本质上讲，无论你是用Swift、Kotlin，还是React Native来构建一个应用，究竟有什么不同呢？这就像是软件开发的细节和我们所持有的信念体系。

所以这种区分将来自两个方面：开发者在日常工作中能获得最佳体验的地方。比如说，在哪里我可以开启新的一天，挑选我想要处理的工作，发挥我的创造力，并且在最少的挫折下高效地完成工作，获得最大回报。软件开发在过去的30年，或者如果回溯到1970年代，当微型计算机出现时，你不再需要和别人共享大型机，一直以来的目标就是，如何将所有我作为个人无法完全实现的宏大想法付诸实践。

我如何能更快地实现这些呢？我们还没有达到那个指数增长的顶端，仍然有很多东西要出现。

另一个可以提出的问题是，GitHub的CEO什么时候才能做到让我的待办事项清单为空？我不相信那个时刻会到来。

Elad：这个问题跟你说的非常相关且有趣，那就是：人类还会在多长时间内做出关于使用哪些工具的决策？因为如果你仔细想想，有些角色，比如你提到的开发者、设计师等，传统上总是受一些趋势的影响。某些开发者使用的工具几乎像是一种模仿，当然也有一些明显优越的产品，某些工具的选择也有明确的标准。有时，它看起来“很酷”，所以大家都在用。编程语言也一样。所以，这是一个有趣的问题：人类在决策时的因素何时会被抛开？决策会发生根本性的变化。因为你去掉了时尚潮流的影响。你知道，你不会再用Go，而是只用Python或其他的。

Thomas Dohmke：在我的团队，作为CEO，我需要多频繁地和他们核对，确保他们正在构建的内容真的是我当初交给他们任务时所想要的。所以第一点，负责任务、功能或者重大项目的人，仍然需要和其他团队成员保持互动，确保他们正在构建的东西是正确的。

在为智能体分配任务时，我并不觉得能做到足够具体，它能够完全独立完成所有工作，除非任务单元非常非常小。这个问题的另一个方面是：我们什么时候能达到一个阶段，所有的软件都变成个人化软件？我再也不需要从应用商店安装应用，而是通过自然语言界面自己构建所有应用。我的个人计算机和智能手机上基本上完全是个人化的软件，而不是那种所有人都使用的标准化软件，其中用户界面实际上是完全个性化的。我们有科幻电影或者动作片，比如《钢铁侠》，其中Java是完全个性化的，专为Tony Stark设计。未来五年内，这种情况一定会发生。问题只是Java到底能做到什么程度？

比如我可以直接告诉它：“春假快到了，还是老地方，和家人一起去。”然后它就帮我预订了行程。我唯一需要确认的问题是：我要选择5,000美元的旅行吗？

关于GitHub和Copilot以及其他所有相关内容，还有一个非常引人注目的方面，就是它们在商业上的成功。最近在财报电话会议上，这一点非常突出。你能分享一些关于商业和财务指标的信息吗？Copilot和GitHub对微软的影响到底有多大？

Thomas Dohmke：除了财报中提到的内容，没什么可以透露的了。我们上次分享的数字是在几个季度前，当时77,000个组织在使用Copilot，付费用户大约有180万。自那以后我们没有更新这个数字，所以我无法提供最新的数字，但我觉得从这些财报电话会议中最有趣的是，Satya提到的这些公司logo，涵盖了各个行业。这不仅仅是一些很酷的初创公司，也不仅仅是金融服务机构，实际上几乎每个行业都在用Copilot。

还没有任何开发者工具能像这样以如此快速的速度，在各类公司、任何规模的企业、任何行业中被广泛采用。你想想看，20美元与美国平均软件开发者的薪资相比，差不多是0.1%，如果有的话。生产力在端到端上提升了25-28%，在编码任务上提升了55%或更高。但正如我们之前所说，开发者做的不仅仅是编码。这是投入的每一美元都带来了极大的投资回报。

这就是驱动起这种曲线的原因。现在任何公司，尤其是软件公司，他们都会面临之前提到的同样问题——他们有长时间的待办事项积压和过多的工作量，每当某个经理去询问团队，实施一个功能需要多长时间。

这就成了Jim Kirk和Scotty的笑话——“修复曲速引擎需要多长时间？”你得到的估算是极其漫长的，然后这就变成了谈判，船长设定了最后期限，而不是工程师根据实际情况来估算可行性。这就是Copilot商业成功的来源之一。

所有写软件的人都对完成任务所需时间感到沮丧，并不是因为他们认为工程师不够好，而是因为软件开发的复杂性。

AI 如何改变软件定价

Elad：这种定价变化会如何？我知道现在只是猜测，但当你实际上在替代人力时，会怎样？我知道在许多行业中，可能是法律、会计或编码。

人们说，最终这将转向基于价值的定价。因为最终，代替一个每年成本为50万、100万或200,000美元的人，或者根据角色不同会有所不同的人的工作，与你现在每月支付20美元让一个人更高效工作是不同的。所以我只是想知道你的想法。

这最终会变成租用程序员，并且它的定价像程序员一样吗？它是否会变得商品化，最终那些通常需要花费10万美元、20万美元、30万美元的年薪的工作，变成每年仅需3000美元？你怎么看这个市场的未来发展？

Thomas Dohmke：它将是基于算力的，或者是某种算力衍生单位作为衡量标准。所以它会变得很便宜，就像你厨房里的洗碗机一样，它的成本并不是由人类每天洗碗的价格决定的。

但买方的心态不会愿意为机器支付一个与人类开发者相当的价格，无论它是洗碗机还是Agent。而这实际上是正确的心态，因为这个Agent并不会真正取代开发者。创造性的部分仍然来自软件开发人员。

系统思维和预测未来总是有趣的。我一两年后再回到播客上，你会告诉我我的预测有多错误。但在软件开发中，有很多决定是必须由人类做出的。

选择什么数据库、什么云服务，很多决策取决于业务运作的方式。你使用哪个云服务，不一定是基于云的成本问题，而是CTO或工程领导团队的战略决策。

越来越多的公司开始使用多个云服务，因为他们不想仅依赖一个供应商，就像任何随机的汽车制造商会有多个气囊供应商一样，因为他们不想在气囊供应商无法提供时被困在生产线上。随着这些Agent变得越来越强大，它们的价格点肯定会提高。我们在OpenAI上看到了这种情况，现在最高层次的价格是200美元，用于深度研究和o1 Pro模型。

显然人们看到了它的价值。两年前如果我们预测这一点，可能不会相信。你愿意为一个聊天Agent每月支付200美元吗？因为往往在软件中，人们觉得5美元的移动应用订阅费已经是很贵了。

你可以从那些从一次性支付变成订阅模式的应用评论中看到这一点，很多人不喜欢这种模式，因为他们觉得软件就像一张CD，买一次就拥有了。显然，它们会根据你获得的价值进行价格上涨。因为另一方面，人类开发者的成本很高，因为供应有限。Agent的供应是无限的，唯一的限制是数据中心中GPU计算能力的多少。

Agent将拥有无限的供应量，唯一的限制是数据中心中可用的GPU计算能力。

Sarah：说到供应的解锁，我们一直在讨论代码生成的定价问题。我觉得还有一个问题就是软件的价值会发生什么变化。每个人都在讨论Javon悖论（Javon’s paradox）一段时间了。

我不想问这个问题，但也许可以问一些更具体的事情。你来自东德，记得Trabant车吗？

Thomas Dohmke：我记得。我有一辆，我父母有一辆。

Sarah：那你可以告诉我它到底是什么样的吗？对你们来说是个不错的车，虽然它只是一辆普通车，但由于全球的供应限制，它成了那种需要10年排队才能买到的车。然后，墙壁一倒，需求完全崩溃了，因为你能接触到世界上所有的车，价格也至少崩塌了。我通常对软件需求的弹性非常乐观，但我把它看作是体量、质量和变化。当AI消除了工程领域的一些稀缺性后，有哪些类型的软件会崩塌价值呢？

Thomas Dohmke：Trabant的等待名单实际上在80年代末是17年。

Sarah：哦，17年不是10年。对的。

Thomas Dohmke：顺便说一下，那条路到今天依然存在。如今它出现在超跑身上。比如，你可以买一辆顶级的保时捷911 RS3之类的超跑。然后转售价格高于新车价格，因为你无法直接去经销商那里买到一辆车，因为在经销商那里，你得先买100辆保时捷，才能获得购买那款独家顶级保时捷的资格，法拉利也是一样。所以，Trabant车实际上是我父亲拥有的那辆，他在1984、85年间把它以比我们买时更高的价格卖给了邻居，因为这样你可以绕过17年的等待时间。很多父母会提前为他们的孩子“预定”一辆车，即使孩子还很小。

所以等到孩子长大，能够拿到驾照时，就能拥有一辆车。所以，你知道，回到你的软件问题，我们会看到两种情况同时发生。

如果你考虑一下Copilot，它对企业的费用是每个用户每月20美元。这个价格实际上几乎和你为GitHub Enterprise支付的费用相同，GitHub Enterprise是每个用户每月21美元。存储所有仓库、管理所有问题，以及整个软件开发生命周期的费用就是每个用户每月21美元。

很多人曾经认为这对于DevOps来说是一个很大的开销。然后我们推出了Copilot自动完成，这个服务是每月20美元。所以突然间，软件开发生命周期中的一个子功能——自动完成的费用就是每月20美元。

这就回到了Elad的问题。如果它有价值，能够带来ROI，能够提高25%的生产力，你愿意为这种东西付更多的钱。可能五年前，如果我告诉你自动完成将成为一个独立的功能，由AI驱动，并且其费用超过GitHub所有功能的平均售价，你可能会说，这听起来不可能。我们将会看到软件价格的通货紧缩。这两者的情况都会同时存在。有些东西我们就不再为其付费了，像操作系统，现在没有人再为操作系统付费了。

与此同时，你可能比以往任何时候都要为Netflix订阅、Office订阅和其他类似的东西支付更多费用。所以这两种情况将会同时发生。关键是你为你的业务支付这个解决方案时，能够获得多少价值，无论是自己做，还是使用你自己管理的东西，或者安装在你自己的服务器上。

Sarah：GitHub是开源的基础设施。我相信你对开源生态系统正在发生的事情有一些普遍的看法。现在，你可以在Copilot和Gemini中使用Claude和OpenAI，但目前不一定能使用开源模型。

Thomas Dohmke：没错。所以在Copilot中，我们有Claude、Gemini和OpenAI。OpenAI有不同的模型。我刚刚在脑海中分析了一下，其实不止三个模型，但它是4.0模型、o1和o3 mini模型.在 GitHub模型中，也就是我们的模型目录里，我们有像LLM这样的开源或开放基础的模型，还有其他各种各样的模型，比如Mistral、Cohia、微软的Phi-4模型。这个模型目录虽然是GitHub中的一个独立功能，但你可以在Copilot中添加模型，因为Copilot有扩展功能，你可以从Copilot访问到模型目录。如果你想快速运行Phi-4的推理，你可以通过在Copilot中使用添加模型扩展来实现。这样，我们就有了比仅仅打包进Copilot中的模型更多的选择。

Sarah：开源与专有模型的API对开发者未来的相关性是什么？

Thomas Dohmke：最大的一个因素是，开源将推动创新。我们已经看到了这个例子，比如今年早些时候的DeepSeek，或者实际上几周前的事情，其实也不算太久。

Sarah：这一年真长。

Thomas Dohmke：感觉已经过去了半年，而不只是一个半月。但开源将推动创新。我们从图像模型，如Stable Diffusion，看到了这一点，现在还有Flux模型，来自一家在弗莱堡的初创公司。

Black Forest Labs实际上是Flux背后的公司。所以，我们会看到开源模型推动创新，进而影响其他供应商。开源生态系统与专有封闭源公司之间的这种来回互动，将加速整个领域的发展。

DeepSeek是目前最突出的例子。论文是公开的，模型也是公开的。其中一些完全是MIT许可证下的开源，其他的则是开放的定价方式。您可以查看定价和运行代码是开源的，但定价本身则是某些专有许可证下的，并且受中国法律等约束。

这将推动创新，开启这一领域，并且使其更加民主化，因为如果你只是想尝试一个模型，你不需要使用商业API进行推理。你可以直接在本地机器上尝试，自己玩一玩。如果考虑到孩子、学生和研究人员，这将开辟一个巨大的空间，这也正是GitHub一直以来的DNA。这个回答满意吗？

Sarah：嗯，最令人满意的回答是，有人赢了。但现在很难预测这一点。

Thomas Dohmke：那谁赢了呢？是iPhone还是Android？Windows还是Linux或者MacOS？我们喜欢把这些看作技术行业中的二元对立，实际上并不是那样，尤其在开发者领域。比如React并没有“赢”。总会有下一个东西。在React之前，有jQuery或者其他你喜欢的库。在Python、TypeScript和Rust之后，会有下一个编程语言。

而且，五年前Rust并没有真正成为主流。所以，未来可能会有更多的语言，可能会更接近人类语言，尤其是针对AI的自然语言层与编程语言层之间的转换，后者会被转换成CPU或GPU可执行的代码。没有什么是能“赢”的。

你正在进行一场无限的游戏。这就像Minecraft。软件就像Minecraft，在Minecraft中没有“赢”。你可以赢得一些小战斗，它们是针对某个特定子挑战或类似的事情的。但最终，我们正在构建一个越来越大的软件世界，而这将永远是下一个大的事情。

开源与专有API的对比

Sarah：这是一个有趣的类比。如果我考虑到任何个别开发者，有人曾对我说过，某些类型的开发者，特别是那些技术能力强、经验丰富的开发者——并不是所有人，但更多的是那些Gremlin系统开发者，通常他们非常依赖Rust。

他们基本上在说，他们担心下一代开发者在建立架构选择、权衡取舍和角落案例的理解上，可能无法获得足够的经验，这些角落案例可能涉及到某个特定实现如何根据数据形态失败，基于他们在实际实现中的经验。他们担心。显然，对于任何想在2025年赢得Minecraft下一阶段的人来说，正确的做法是积极使用人工智能。

学习如何使用它。但是，这种担忧我敢肯定你也听过，你是否能理解这个担忧？当我们不再编写代码时，我们是否能够培养出足够深刻的工程理解，达到抽象层面？还是说，这只是一个无关紧要的担忧？

Thomas Dohmke：我不会称之为无关紧要，因为显然这其中有一定的真理。做编程练习或类似的活动时很容易作弊。随着这些AI模型的不断进步，这些谁是最好的黑客或程序员的竞争，将不得不进入一个全新的层次，你假设开发者在解决挑战时使用AI，否则这些挑战就太容易了。

如果你考虑到下一代开发者，也许不是2025年，而是2035年。我之前提到过我在东德长大的事，然后墙倒塌了，他们买了一台Commodore 64，但没有互联网，于是他们买书和杂志，就仅此而已。那时没有论坛可以去提问。我每周三都会去计算机俱乐部，直到那里没人能说我已经知道的东西为止。

如果你拿这个和今天的情况做比较，今天的孩子，尤其是那些想学编程的人，能够接触到无尽的知识。他们还拥有无尽的耐心，因为Copilot不会失去耐心，家长可能会，我就是其中之一。所以，如果你想学编程，AI的可用性极大地实现了知识的民主化。你的父母不需要任何技术背景，你只需要一部手机和一个互联网连接，配合这些Copilot或者ChatGPT，或者你更喜欢的工具，你就可以开始提问编程问题，问关于布尔逻辑、系统思维的内容，你可以对这些问题深入探索，甚至可以自由切换到其他话题，完全没有限制。

我们将看到新一代的人类，他们从小就与技术一起成长，对他们来说，利用个人系统、个人Agent集群（他们称之为Agent交响乐团）是自然而然的事情，而你就是这个交响乐团的指挥，他们知道如何操作这些系统，所以他们可以在同样的时间内比我们过去30年能做得更多，我觉得这非常令人兴奋。因为，再次强调，找找看有没有开发者没有那个“大创意”，那个他们一直想做的计算机游戏、软件系统或功能，但由于时间不足一直没能实现的。

我的工程师们更多谈论的是承受过多工作压力、感到筋疲力尽、没有足够的时间去做我要求的事情，客户要求的事情，安全团队要求的事情。所以这正是我们未来发展的方向，这会非常令人兴奋，实际上也适用于开源，开源的可持续性是另一个大话题，我们可能还可以花一个小时来探讨。而且适用于任何人们想要构建的软件。

在东柏林成长

Sarah：我完全同意这种兴奋和乐观。我想到了我的三个孩子，他们能够在有AI资源的情况下，以怎样的速度学习，我非常羡慕。我觉得，如果有了你所说的今天的模型的无限耐心和理解，我作为一个工程师会变得更加高效，速度也会更快。

顺便说一下，我非常幸运，我的父母都是工程师，但那种非常人性化的动态是：我会问一个问题，我的爸爸会说，“这是逻辑，Sarah。”我心想，哦不。

我能问你一个更私人的问题来结束吗？、你有这种在reunification后经历技术快速变化的独特体验。这对你如何看待当前AI过渡的速度以及用户和人类如何反应有影响吗？

Thomas Dohmke：我一直想相信，我一生中的很多事情都是由1989年那个改变时刻定义的。我记得墙倒塌的那一晚，或者是宣布墙要开放的那一晚。那是个星期四，第二天是正常上学。

星期六仍然是上学，半天的课程。我想我是班上四个到场的孩子之一，他们把我们送回家。我们实际上越过了柏林墙，到了西柏林。

对于经历过这一变化的那代孩子来说，重要的是，他们再也不能回到他们的童年。家已经不再是原来的模样。街角的商店也已经不同了，40年前的样子已经不见了。学校都不见了，系统消失了，传统都融入了那个新世界。

这有点像你从一个国家搬到另一个国家，我也做过这样的事情，十年前微软收购了我的公司。做了这个人生的步骤后，你会获得一种全新的视角。1990年的统一，以及我通过随机的决定成为GitHub CEO的过程，都是这样。

当时这些感觉很随机，这就是我走到今天的方式，也是我展望未来的方式。我对未来充满乐观，同时也会铭记我的过去，将这些经历带入和你们的对话中，并反思在90年代使用Commodore 64编程的经历，互联网之前，开源之前，云计算之前，移动互联网之前，现在是AI之前和之后。未来没有回头路。

未来会是，几乎我们生活中所有的事情都可以由AI来完成，只要我们愿意。你依然可以把手机丢到一边，度过没有互联网的日子。

Sarah：这次对话非常棒，非常感谢你和我一起聊天。

Thomas Dohmke：非常感谢你邀请我。

Elad：我很高兴，我非常感激能有这一段时间。

原视频：No Priors Ep 106 | With GitHub CEO Thomas Dohmke

https://www.youtube.com/watch?v=XqvNnl2AJko

编译：Christine Liu

请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。

Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。

——-

（文：Z Potentials）