我采访了 AI 版 GitHub 首席运营官——然后又和真人聊了聊

原文：https://every.to/also-true-for-humans/i-interviewed-an-ai-version-of-github-s-coo-then-spoke-to-the-real-one

我以参会者和演讲者的身份参加过许多科技会议，但今年的微软 Build——这家公司的旗舰开发者大会 ——是我第一次以媒体身份参与。

为了压制冒名顶替综合症，在坐下来采访 GitHub 首席运营官 Kyle Daigle 之前，我做了个实验。Kyle 是真正的 GitHub 老兵，13 年前作为开发者加入公司。我先构建了一个 Kyle 的模拟版本——一个基于他的公开文章、演讲和采访提炼出的 AI 虚拟人格——然后向 AI Kyle 问了一遍我准备向真人 Kyle 提出的问题。

我本来以为模拟结果要么准得可怕，要么毫无用处。但它两者都不是——而这恰恰让它变得有价值。

在 12 个问题中，有 2 个回答高度吻合，4 个部分吻合，6 个明显跑偏。值得肯定的是，当模拟版缺乏证据时，它会直接承认，而不是凭空捏造。这些空缺恰恰是最有用的备访辅助——它们告诉我哪些信息在公开记录中找不到，也因此在真人采访中应该把时间花在什么地方。

我跟 AI 虚拟人格打交道很多了。我上一家创业公司 Ask Rally 做的是虚拟焦点小组工具。我们发现，AI 无法替代真实对话，但在高风险场景下，角色扮演能帮你跳出自己的思维局限、建立策略信心，并避免代价高昂的错误。我们比自己想象的要更容易预测，有研究显示 AI 虚拟人格复制真人反应的准确率可以达到 85%。

以下是真实采访内容，附带模拟结果对了什么、漏了什么的批注，以及对比中最有趣的地方。事后我们又找了真人 Kyle——他对这个实验的看法比 AI 的回答更出乎我们意料。

1. 拓展“开发者”的定义

Mike： 客户的人口结构正在发生变化。很多以前可能从未用过 GitHub 或开发者工具的人现在都在用。这对你们决定产品路线图的方式有什么影响？

Kyle Daigle： GitHub 对开发者是什么一直持包容的态度。我本人的起点，是在我会自称开发者之前。我当时只是在给自己写代码，而且我没上过计算机专业。我读的是艺术学校，靠写代码来支付艺术学校的费用。

这段经历很重要：我可以跟团队一起做工具，然后交付给那些想给自己、家人、初创公司或企业做个应用的人。GitHub 有大型企业在用的严肃开发者工具，但当我看像 GitHub Copilot 应用这样的产品时，我既看到同时跑着多个项目和 agent 会话的专业开发者，也看到我们法务或财务团队的人在用。客户跟我们反馈的也一样。那些行业里通常被称为知识工作者、或者业务上不是开发者的人，在用这些工具构建小型应用或资产。

我们的重心仍然非常坚定地放在开发者身上，但我们希望让尝试写代码变得更容易。进入软件创造的门槛应该一直存在，包括通过像 GitHub Copilot 应用这样的工具。

模拟批注： 部分吻合。AI Kyle 准确预测了真人 Kyle 的核心观点：AI 正在扩展谁有能力构建软件——甚至给出了一个验证框架，真人 Kyle 完全有可能也会提到：“我一直用来检验的设计原则是‘没有新的增量行为’。新能力应该嵌入到软件开发本就发生的地方。”但它无法产出艺术学校的故事，也无法举出法务和财务团队在用这个工具的例子，而这些才是让真人的回答生动有力的东西。

2. 帮维护者应对海量 pull request

Mike： 你们如何帮开发者应对大量新增 pull request 带来的负担？我接触到的开源维护者已经快被淹没了。需要做什么来帮助他们？

Kyle Daigle： 对于一般的开发者，我们在构建像 Copilot 代码审查这样的工具。它现在具有 agent 能力，因此能发现更多新奇的漏洞，你可以发表意见，让 agent 实现某个改动。代码审查是一个被忽视的环节，可以在这里把 pull request 推到更容易审核的状态。

Agentic merge 是另一个例子。一个 pull request 可能接近就绪了，但要完成处理仍有一些手动步骤。换种方式，我可以定义 GitHub Copilot 被允许做什么，告诉它合并 pull request、等待 CI、等待策略执行。

开源有独特的需求，因为维护者无法控制谁发送变更。我们专注于赋予维护者更多控制权：他们是否想接受 pull request、想接受谁的请求、以及贡献者需要付出多少工作量来证明其贡献是有价值的。每个社区都在选择略有不同的方法。GitHub 希望提供基础构件，让维护者保持控制权。如果某种标准实践出现，我们可以围绕它固化一个系统，但我们不想先把系统强加于人。

模拟批注： AI 抓住了治理原则，但具体内容错了。它最精彩的一句——“系统应该给维护者明确的规则和护栏，而不只是一个更大的收件箱”——是真人 Kyle 可能说出来的。但它没有提到任何产品名。Copilot 代码审查、Agentic merge、贡献者准入控制：对一个基于公开资料构建的 AI 人格而言，这些都不可见，因为它们在本次大会之前并未公开。

3. Agent 生成活动的增长

Mike： 你对这个新的 agent 经济有最前沿的观察。你公开说过，你一个月收到的 pull request 比去年全年的还多。这些数据究竟在怎样暴涨？

Kyle Daigle： 我们确实看到 GitHub 上的活动在大量增加。去年 10 月在 GitHub Universe 上，我们分享过去年全年 GitHub 上有 10 亿次 commit。如果今年保持线性增长，我们今年有望达到 140 亿次，而实际上不会是线性的。3 月份，仅 agent 创建的 pull request 就有 1700 万个。

代码的产出量大大增加了。有时候人们会把它贬低为“垃圾”（slop）：推上来没人关心的代码。这不太准确。我们正在走出超级早期采用阶段。我们还没到顶峰，但我们正爬坡，正在学习当构建者不只是 Kyle，而是 Kyle 加上一个、两个或 N 个 agent——用我的技能、资源和上下文——我们究竟能构建什么。

我们正在为下一波增长大力投入，因为这看起来不像先增长再平缓下来的态势。不管人们在哪儿构建、用什么工具，代码最终都会来到 GitHub 进行分享和协作。我们需要支持每一个人的 agent 时刻，不光是 GitHub Copilot 的用户。

模拟批注： 跑偏。AI 只是复述了去年的公开数据——它只能把你已有的数据重新摆出来。

4. 持续运转的 Agent 的商业模式

Mike： 商业模式会怎么变？在一个以人为中心的世界里，freemium 模式是合理的，因为我们要睡觉，但我们睡觉的时候 agent 还在工作。这是否会推动向按用量定价转变？

Kyle Daigle： 我想我们现在还不清楚。眼下，Kyle 有许可，或者免费使用 GitHub.com，我们一直都有 API 速率限制。通常就是在这一点上人们会碰到 agent 的反压。

如果你想做得更多，用 150 个 agent 同时做事那种，我们希望能支持你。与此同时，我希望你有很好的核心 GitHub 体验，而一定程度的 agent 用量是这个体验的必要组成部分。这有点像 GitHub 从提供免费公共仓库但不提供免费私有仓库，进化到也向个人提供免费私有仓库——因为人们完全有理由拥有不想公开的代码。

GitHub 随着行业和社区的演进而演进。我们专注于确保开发者拥有成功所需的东西，然后与企业合作，确保他们在规模上拥有所需的东西。这两类需求通常有所不同。

模拟批注： 两个 Kyle 的开场想法一样：现在没人知道答案。但真人 Kyle 的回答因为用了假设性例子来解释观点，要生动得多。

5. 横跨 GitHub 与微软的双重角色

Mike： 定价又会牵涉到更广泛的微软生态。你现在有双重角色，对更广泛的市场营销组织负有一定责任。这如何改变了你的工作？你怎么在两个角色之间排优先级？

Kyle Daigle： 我在 GitHub 13 年了，长期作为开发者本人并领导工程团队。GitHub 一直独特的地方在于，我们极度专注开发者。企业购买工具很棒，但我们不是为买家构建的，我们是为使用者构建的。

这是我一直以来作为 GitHub COO 的重心，我也仍在继续。作为微软开发者首席营销官，我的目标是审视微软的开发者工具和技术全景，确保我们提供对开发者体验而言真实可信的整体解决方案。

在像 Build 这样的大会上，我们今年的做法不同。我们在旧金山，氛围跟传统的会议中心布置不同。重点是：我能去听一场分享吗？我能亲手用起来吗？我不想被推销一个东西，我必须能亲手使用它。目标是把 GitHub 对开发者的专业能力、关怀和专注，带到微软更广泛的影响力中去。

模拟批注： 完全跑偏。AI Kyle 质疑我的事实前提：“可用的人物资料……并未记录横跨更广泛市场营销组织的双重角色。我会先验证这个前提，再把它当做既定事实。”这证明，基于公开资料构建的模拟是有保质期的。

6. Build 大会上的社区讲者

Mike： 我是不是听你说，这是第一次有外部贡献者和讲者参与主议程的 Build？

Kyle Daigle： 这是第一次 Build 有意识地让社区讲者登上主会场。主题演讲中有像 Peter 这样的人，还有来自 Svelte 等团队的分享。

软件开发是一项团队运动。认为一家公司或一个团体，包括 GitHub 或微软，能回答所有问题，那是天真的想法。我们都在使用开源，并构建在那些重要的开源项目之上。我们应该邀请人们来，共同讲述属于他们那部分的故事。这正是开发者想要的，反馈也表明，人们对能在同一场活动中看到微软、GitHub 和公司外部的多元视角，感到非常兴奋。

模拟批注： AI 拒绝回答：“我无法从现有的人物资料中确认这一点。”但这恰恰是你希望模拟版做的——在它不知道的时候坦承不知道。

7. 在竞争激烈的市场中实现差异化

Mike： 市场竞争非常激烈，变化节奏很快。你们如何实现差异化？

Kyle Daigle： 我们持续聚焦于我们的根基：开发者选择权、为构建者而构建、赋能构建者。我们从一个拥有很多 API、广泛开放的时代，进入了一个有点无意中形成的“围墙花园”格局——人们先对某个工具产生认同，然后发现想在其他地方尝试有趣的东西，意味着要学一个新工具或开一个新账号。

我们希望让使用 GitHub 构建的开发者也能使用其他工具，我们会与各方合作，让这变得尽可能简单。其他公司也做类似的事情，但我们在支持跨越整个软件构建过程的自由选择权方面的能力——不只在代码生成或协作审查的单一环节——是一个真正的优势。

我们将投资自己的技术，包括新的微软 AI 模型，同时继续与 Anthropic、OpenAI、Google，以及任何将模型或编程 agent 推向市场的人合作。我们会让开发者把这些工具带到 GitHub，或通过 GitHub 和 GitHub Copilot 来使用它们。选择权是核心。如果我们在这点上退让，开发者仍然会选择，他们只是会被困在另一座围墙花园里罢了。

模拟批注： 在 12 个回答中，这个回答与真人 Kyle 回应的匹配度最高。AI Kyle 说：“差异化不是在一个拥挤的市场中再多一个 agent……而是做到跨供应商的选择，而无需锁定在单一模型上。”真人 Kyle 甚至用了同样的比喻——围墙花园。这是在整场采访中，我最不需要靠模拟预演就能应对的部分。

8. 既要用自己的产品，也要对别的工具保持开放

Mike： 最近有一个关于 Claude Code 许可被取消的新闻周期。你们如何在“吃自己的狗粮”——比如你们的新模型或 GitHub Copilot 桌面应用——和让开发者自由探索其他工具之间做取舍？

Kyle Daigle： 我们所有人都用各种工具，因为不然你会失去视野，变得只关注自己的工作。我多年来每天用 MacBook，打游戏时用 Windows 电脑。得到这个角色后，我配了 Mac、PC 和一台装有 AlmaLinux 的设备。我大多数星期六会写代码，然后在几台设备之间切换，因为我想理解每种体验。我只在 Windows 上用 GitHub Copilot 应用，因为 Windows 上的开发者也值得有好的应用，这不只是 Mac 用户的事情。

这在我们各团队中也是常态。我们关注各种编程 agent、执行框架、桌面应用、内存管理等方方面面。每个人都在构建并使用这些工具。我们把大部分精力放在自己的工具上，但如果视野过窄到失去外部视角，那是一个盲点。当有新东西出来，我想知道人们为什么跟它交互的体验很好。那能帮我理解应该聚焦哪里，以及开发者为什么会选择某个特定工具。我们的团队也一样。

模拟批注： 这是第二个最强匹配。AI 用一句真人 Kyle 会很乐意署名的话抓住了核心概念：“吃自己的狗粮应当是为了打磨产品。它不该成为一种忽略其他开发者觉得好用的工具的理由。”但 AI 不可能知道，GitHub 的 COO 每个周六在三台设备——Mac、PC 和一台 AlmaLinux 设备——之间来回切换写代码。

9. 过滤短期想法和更长期的押注

Mike： 这些想法中有很多寿命相对较短，而企业级产品的开发周期更长。你们怎么过滤各种想法，决定到底做什么？

Kyle Daigle： 在短期，我们聚焦于支持大量的 agent 会话，因为这方向看起来很清晰：每个人都在做这件事，那我们怎么把它固化下来？在更长期，模型会持续改进，token 经济学将在人们选择什么工具时扮演更重大的角色，而且我相信，我们离能在本地设备上真正用好一个超越小型语言模型的东西，来做一部分工作，已经不远了。

如果在 token 层面有那么多可选方案，那么自 ChatGPT 和 GitHub Copilot 涌现以来，始终如一的真理是个性化、上下文、用上下文做微调，以及记忆。行业里有各种实验，但还没有一个长期愿景。支持大量 agent 很重要，但原因不只在于某个用 agent 的人不会坐等一个 agent 做完。单靠这一点，无法产生出色的长期体验。出色的体验是，用到一个 agent，感觉它在你还没完全把想法结构化出来之前，就已经在帮你完成那个想法了。

Agent 应该能直觉到这一点，或者通过后训练、微调或前沿调优来深度理解我的工作方式。有些时候我们在短期工作上投入，有些时候我们在长期方向上一次又一次地尝试，直到出现某个实实在在的东西，能帮我们往前走。

模拟批注： 这正是模拟版最喜欢的拐杖失效的地方。AI Kyle 再次——又一次——动用真人 Kyle 在资料中体现最充分的框架：“我用一个‘约束优先’的层次：MUST、SHOULD 和 COULD。”在我 12 个问题中，它用了这个框架五次，而真人 Kyle 一次都没提。当一个虚拟人格用尽了证据，它会过度应用自己最熟悉的那套模式。这是比幻觉更微妙的失败，但仍然是失败。随着模型变得更好，它们应当减少对单个上下文片段的固着，像人类一样松弛规则。

10. 爬山（Hill Climbing）作为产品开发循环

Mike： 我昨天听了 100 遍“爬山”这个词。能谈谈它为什么变成这么大的重点吗？

Kyle Daigle： Satya [纳德拉]、Mustafa [苏莱曼] 还有领导 Copilot 团队的 Jacob [Andreou] 经常谈这个。我们学到的最重要的一件事是，使用这些工具必须成为改进模型底层体验的核心方式。评估（evals）至关重要。点赞和点踩的数据、人们是否采纳一个建议、以及在多大程度上采纳，这些都在为每个人创造有用的体验贡献力量。

我们每周都在讨论爬山的结果。我们既看硬指标也看软指标，因为有时候评估和评分表显示在进步，但用户实际感受却崩塌了，即便延迟和性能都没变。你可能会过拟合。

目标是快速跑通这个循环，然后给每个人一台“爬山机器”，而不必让他们非得用最笨的办法去做。在一个使用 Microsoft 365 的企业里，资产、文档、聊天记录中潜藏着丰富的数据。开启像前沿调优这样的功能，用 MAI Phi-3 模型做基底，就能在无需额外投入大量工作的情况下展现出真正的效果。一开始这听起来像是不可能成真的魔术。但有时机会恰恰就藏在那些看起来简单得不像真事的地方。

这就是为什么我们老在说爬山。它不是登月。就是爬坡、改进、加一项评估、继续改进、加新数据、再改进。我们就是这样一步一步地来到了今天——能为自己的场景推出模型，并且允许客户使用类似的工具链。

模拟批注： AI 拒绝猜测，说：“可用的人物资料中并未记载我把‘爬山’作为一个具体的组织术语使用，所以我不会凭空制造一段起源故事。”然后提供了一些关于快速迭代的抽象解释。真人的回答包含了模型永远拿不到的新信息。

11. 让 AI 订阅价格保持可负担

Mike： 爬山是不是那个让 200 美元订阅不要变成 2000 美元订阅的答案？

Kyle Daigle： 前沿调优让模型更懂你，是答案的一部分。另一个重要部分是帮助开发者自动选择模型。

Mike： 就像 GitHub Copilot 里的模型路由？

Kyle Daigle： 正是。GitHub 有一个基于任务意图的自动模型路由，Microsoft Foundry 在 API 层面也有模型路由。我们越能让人们告诉我们他们的标准线在哪里，比如“这是个超级难的问题，我愿意一路用到顶级模型”，或者“我只想保持在这个层级”，我们就越能帮他们选择模型。

Token 往往很贵，因为人们选择当天、当周甚至当时最火的那个模型，而那个模型可能很贵。但一次思考链条会在难题和简单任务之间切换。我可能让 agent 做大量的工作，然后最后一步只是改个名字。我大概不会为了省这一步的 token，手动从昂贵的模型切到一个很小的模型，但工具是可以做到的。这将帮到企业、个人开发者、以及用 Copilot SDK 构建自动化流程的人。

模拟批注： AI 抓准了问题的大意，但它解决不了这个问题。它给出了问题的框架，指出模型做更多工作并不自动意味着账单更便宜，而真人 Kyle 谈的是解决问题的一个具体东西：自动模型路由。

12. 用 Agent 做罕见的个人用途

Mike： 我做了一个 AI 版的你来练习这次采访，并且发现它非常有用。你们内部或外部看到的，还有什么其他不寻常的 agent 用法？

Kyle Daigle： 我也做类似的事。我在应用这边有一套设置，另外还有一个不能访问工作系统的 Claude 实例，这样状态是隔离的。我花很多时间让它阅读我写的东西。这次采访的内容最终也会喂给它。我每天会收到一份沟通报告，写着类似“Kyle，你老在说这个”，或者“这个表达不够清晰”。因为我写作和说话有特定的方式，喜欢用隐喻，它会给出我哪些隐喻是清晰的。

这种人对自身的自改进循环威力巨大。我们以前在 GitHub 讨论 Hubot 和 ChatOps 时就说：人类远比接受其他人的批评，更愿意从机器人那里接受批评性反馈。当我的 Claude 实例告诉我某件事我做得有多糟糕时，我会更乐意请它解释原因，并在写邮件、写脚本或审查细节时使用这些反馈。

我的 agent 循环中有很大一部分是关于我自己，而不是软件。它是回顾性的：阅读 Kyle 过去七天的邮件和 Slack 消息，给出反馈，然后再回看建议，检查 Kyle 是否照着做了。这个循环极其强大。这正是我想要的那种个人消费者 AI 体验。

模拟批注： 有趣的是，这个关于模拟采访的问题也跑偏了。当被要求举出不寻常的 agent 用法时，AI Kyle 承认它没有什么可提供，转而含糊地谈减少重复劳动。真人 Kyle 的回答揭示出了一个具体、个人化的工作流，才真正有趣又有帮助。

最好的采访准备，是知道该往哪里深挖

Every 的主编 Eleanor Warnock 最近写了她称之为 Socrates-as-a-service 的东西：那种把人们尚未付诸语言的想法牵引出来的人类技能，比如一个趣闻轶事如何变成头条故事，或者一个细节如何将一种思想结晶，变成读者会记住的东西。

这正是这次实验帮我看清的那个差距。模拟版知道 Kyle 在开发者选择权和围墙花园问题上的立场，因为他多年来一直在公开场合把这些讲得很清楚。但它无法知道，他每个周六都写代码，并在三台设备间来回切换，只为对其他人的工具保持诚实。

在一次在真实采访后的反馈中，Daigle 对这个实验评论道：“我觉得这个模拟采访挺不错的！总的来说，它过度索引了我的书面作品，而不是我的口述采访和播客。因为没有办法访问到我在内部写的所有内容，它对我在博客之类的平台上谈到的话题，比我实际通常会讲的，要更深入。”

这正说明了在采访前做一次 AI 模拟演练的真正理由。它会让你看到公开记录中的缺口在哪里，这样你就可以花采访的时间去填补那些缺口，为你的读者和这个世界，萃取出真正原创、稀缺的知识。

Daigle 也为我的回答找到了用途。“即便只是看 AI 的回答，我也发现它在帮我厘清思考和提升回答的锐度，所以它对我也有帮助。”

然后他补充说：“我其实也为 Mike 做了类似的事情。我预估他会问我什么问题。我没有保存输出——我会给很多这类东西做垃圾回收——所以挺有趣的，原来我们都在这么干。”

也许从头到尾，我才是那个被套路的人。

模拟的 Kyle Daigle 基于截至 2026 年 5 月 31 日的公开材料构建，使用了开源库 SynthTeam 的一个修改版本，并在事后与真实转录稿对比评分：2 个强匹配，4 个部分匹配，6 个跑偏。完整方法论及未删节的合成采访可应要求提供。

核心启示： 这次实验的真正价值不在于 AI 能多准确地复制真人，而在于它精准暴露了公开信息的盲区——而正是在这些盲区里，才藏着能让采访与众不同的原创性洞察。