GitHub’s COO Explains Why AI Hasn’t Replaced Developers

大家好，我是 Mike Taylor。我是 Every 的技术咨询负责人，我和 GitHub 的 COO Kyle Daigle 坐下来聊了聊，谈的是 coding agents（编程 agent）前线正在发生的事。现在，GitHub 每个月会收到 17,000,000 个 poll requests，而且还在指数级增长，这让他们处在这场新经济中变化最前沿的位置。我们聊了这会如何影响他们的用户，也聊了这会如何影响 open source maintainers（开源维护者），还谈到了一个大家都非常关心的话题：我该怎么防止自己每月 200 美元的 coding agent 订阅，一路膨胀成每月 2,000 美元的 usage limit（使用额度）？

这次采访里，我们做了一点不太一样的事：我告诉 Kyle，我做了一个他的 AI clone（AI 克隆）来练习这次采访，而他也回报了一个让人意外的消息。下面就是这段对话。

Every 是你想站在 AI 前沿所需要的唯一订阅。如果你在意紧跟最新的 models（模型）并使用最新的 tools（工具），那你就得订阅 Every，才能从噪音里分辨出真正有价值的信号。现在就去 every.to/subscribe 订阅吧。

嘿，Carl。感谢你在会议上抽时间和我聊聊。嗯，当然。对。

前一天能见到你也很高兴。对。感觉我们其实已经聊过其中几个问题了，不过我觉得还是很有必要再讲一遍，你知道的，为了更广泛的受众，让他们也能明白这里到底发生了什么。完全同意。对。

所以我觉得我们刚才谈到的第一件很有意思的事是，客户的人口属性正在变化，对吧？比如很多以前可能根本不会用 GitHub、或者从来没用过 developer products（开发者产品）的人，现在也开始用了。那么，这一点是如何改变你们决定 product road map（产品路线图）方式的？

对，对。我的意思是，你知道，我觉得对 GitHub 来说尤其如此，我们一直以来对什么是 developer（开发者）都有一种非常宽泛的看法。我在还完全不会把自己称作 dev（开发者）之前，就已经是以开发者的方式开始了——那时候我只是写代码，而且只是写给自己用。后来我个人走上了一条完全不同的职业道路。我大学学的不是 computer science（计算机科学）。

我当时读的是 art school（艺术学校）。我靠写代码来支付 art school 的学费，现在作为成年人回头看，这大概是个非常傻的决定。但当时，你知道，那种一路走来的经历就是：我可以和团队一起创造工具，再把它们交付给别人，让他们也拥有同样的体验——那种“我就是想做一个给自己用的 app，或者给家人用的 app，也许以后会变成 startup（创业项目），也许会变成 business（企业）”的体验。我们当然也有非常严肃的 developer tools（开发者工具），你知道，几乎所有最大的企业都在使用 GitHub。但当我看到像 GitHub Copilot app 这样的东西时，我看到的同样也是大量开发者——他们每天都在使用 AI，同时跑多个项目，同时开启各种各样的 agent sessions（agent 会话）。

而且我看到，比如说，GitHub 的法务团队在使用 GitHub Copilot app，财务团队也是这样；我今天还见了一位客户，他们也在说同样的事。很多人——行业里通常会称为 knowledge workers（知识工作者）——或者说并不是以开发为职业的人，都在用这些工具为自己构建一些小型 app 或资源。所以虽然我们的重点非常明确地还是开发者，但我认为我们想让人们更容易选择去尝试写一点代码，并确保现在借助 GitHub Copilot app 这类东西，始终有一条进入软件编写的入口。

对。那么，面对所有这些额外的负担，你们是怎么处理的，或者说你们如何帮助开发者应对？现在 PR 简直是洪水一样涌来，我接触过的 open source（开源）维护者都在说，自己快被淹没了。对。你们会怎么做？或者说，需要发生什么才能帮到他们？

对。我是说，我觉得针对所有开发者，我们都在构建像 Copilot code review 这样的工具。它现在已经是 agentic（具备 agent 能力）的了，所以能发现更多新的漏洞；而且你只需要留言评论，agent 就会接手，如果你愿意，它还会去实现相应的修改。所以我觉得 code review（代码审查）这一步在某种程度上被忽视了，但它其实是一个非常好的方式，能让 PR 更容易被审查，达到更适合 review 的状态。我认为，app 里的 agentic merge 也是另一个类似的场景，我们在内部和社区里都经常看到，你可能会对某些内容发表评论。

你可能已经做过一轮 code review，也可能已经把它推进到几乎完成的程度，但最后还是有一堆手动步骤，只是为了把这个 PR 处理完。嗯。相反，我现在可以进去精确设置我希望允许 GitHub Copilot 做哪些事，然后说，好，现在去 merge 这个 PR，并等待 CI，再等待 policies（策略）之类的全部完成。我觉得这是一大部分。

在 open source 这边，需求是很独特的一套，因为你并不能控制都是谁在提交这些东西，或者至少从历史上看，你并没有真正控制过。这也正是我们一直在重点投入的地方：给维护者更多工具，让他们自己决定——你是不是想接受所有这些 PR？你想接受谁提交的？你需要对方做多少工作，才能在某种程度上证明他们会为这个项目贡献真正有意义的内容？这是我们想为 open source 维护者提供工具的方向，但真正的控制权还是要留在他们手里。

每个社区都在用略有不同的方式来处理这个问题。对 GitHub 来说，我们一直都希望把这件事交到他们手中——给他们工具，赋能他们。但如果在这个过程中形成了某种标准，或者大多数人都在使用某种实践，我们就会把它固化下来。不过我们其实并不想成为第一个去制定标准或方法的人。比如，我记得 Michel Hashimoto 分享过他们使用的 vouch system。

然后我就会被问到类似这样的问题：那你们为什么不把这个推广给所有人？但同样也有很多社区并不想用那套系统，因为他们对应该怎么运作有自己的想法。所以目前我们专注的是为维护者提供控制能力的基础模块。然后，随着大家一起摸索、随着维护者不断反馈，如果真的逐渐形成了一整套体系，我们就会把它固定下来。

对。而且我觉得你们像是坐在第一排，亲眼看着这个新的 agent economy（agent 经济）展开。因为我记得你好像在 Twitter 上公开说过，你们每个月收到的 pull requests，已经比去年全年收到的还多了。对。那这些数据现在到底是怎么爆发式增长的？

对。我的意思是，我们在 GitHub 上看到的活跃度高得多了。你知道，这么多年以来，我们一直都在谈论我们的用户，以及这种增长。但今年，很明显，我们看到的是开发者在增长，他们有了 agent，而且在用它们来构建。

所以，去年 10 月在 GitHub universe 上，我们分享过这样一个数据：GitHub 全年的 commits（提交）达到 10 亿次。照今年这个趋势看，如果增长是线性的——当然实际不会是线性的——我们今年有望达到 140 亿次。你知道，到 3 月的时候，就已经有 1700 万个 pull requests（拉取请求）是由 agents 创建的。对。

而且这还只是 agent 创建的 pull requests。

好的。对。

所以现在被创建出来的代码多了太多。我觉得有时候大家会说，哦，这些都只是垃圾，这些都只是被推上来的代码，反正也没人关心。但这其实并不完全是真的。

嗯。

我们其实都已经走到了这样一个阶段：不再处于那种极早期采用阶段了。我们肯定还没到顶峰，但我们正在往那座山上爬，去看当不只是 Kyle 一个人在构建，而是 Kyle 加上一、两个，甚至更多的 agents——它们在使用我的技能、我的资源、我的上下文等等——的时候，我们到底能构建出什么。所以我们正在大力投入，为下一波增长做准备，因为这看起来并不是那种增长后趋于平台期的走势。它只会继续增长，因为不管你在哪里构建，或者你使用什么工具来构建，所有这些代码最终都会流向 GitHub；或者说，那就是你向全世界分享代码的地方，或者你在 PR 里协作的地方。因此，我们必须能够支持每个人的这种 agent 时刻，而不只是 GitHub Copilot。

对，对。那商业模式会怎么变化？因为我觉得 freemium（免费增值）在人类为中心的世界里是说得通的，毕竟我们晚上会睡觉；但现在当我们睡着的时候，agents 还在继续工作。所以这是不是会转向 usage-based（按使用量计费）呢？

比如说，你觉得事情会往那个方向发展吗？对。

我的意思是，我觉得我们现在其实还不知道最终会是什么样。我觉得目前很大程度上还是这样：Kyle 会有一个 license（许可证），或者 Kyle 正在免费使用 githubdot, .com，而且我们一直都有 API 限流（rate limits）之类的机制。通常我觉得大家就是在这些地方感受到这一点，也就是我所说的 agent back pressure（agent 反压）。我的目标是，如果你想做更多得多的事，如果你想像 Peter Steinberger 说的那样，让 150 个 agents 同时处理所有事情，那很好。我们希望能让你做到这一点，但与此同时，我也希望你依然能拥有很好的 GitHub 核心体验。

至少，其中需要包含一定程度的 agent 使用量，这是必要的。这有点像很久很久以前，当时你可以有免费的 public repos（公开仓库），但没有免费的 private repos（私有仓库）。对吧？然后我们就说，好吧。

其实，对个人来说，有一些代码不想直接公开到全世界面前，这是很合理的，所以我们会给你免费的 private repos，让你能够这样做。所以 GitHub 一直都在随着行业和社区一起演进，但我们的关注点始终是：我得确保你——开发者——拥有成功所需要的东西；然后再与 enterprises（企业）合作，确保他们也具备大规模开展工作的所需条件，而这通常会和个人开发者在做的事情有些不同。

对，对。我想商业模式和定价这些问题，某种程度上也都会回到更广泛的 Microsoft 体系里。因为你现在有双重角色了，对吧？

对。你现在还部分负责更广义上的 marketing org（市场组织）。所以你愿意讲讲这带来了哪些变化，以及你是如何在这两者之间排优先级的吗？

对。我在 GitHub 已经很久了，13 年。而且你知道，我自己本身也是开发者，这些年里也有很长一段时间在带 engineering teams（工程团队）。我觉得 GitHub 一直以来独特的地方在于，我们真的、真的非常聚焦 dev（开发者）。我们是在为开发者构建工具，而 enterprises 愿意购买这些工具，这当然很棒，也确实很好。

但我们不是为 buyers（采购者）而构建，我们是为开发者而构建的，百分之百如此。所以，这一直是我作为 GitHub COO 的工作重点，而且我现在也仍然在做这件事。而现在，作为 Microsoft 的 chief marketing officer of developer，我的目标是纵览 Microsoft 全部的 tooling（工具链）——它们的 developer tools（开发者工具）以及它们提供给开发者的技术——并确保我们带来的是你可以使用的、holistic solutions（整体性解决方案），而且这些方案对开发者体验来说是真实自然的。像这次这样的活动，我们今年对 build 采取了非常不同的方式。首先，我们在 San Francisco，整体 vibe（氛围）就和那种传统 conference hall（会场）布置有点不一样。我们的重点真的在于：我能不能去参加一个 session（分会），我能不能直接用这个东西；我不想被推销一个东西，我得能亲手用它；而不是那种 Expo Hall（展区）式的模式，诸如此类。

这其实就是把 GitHub 一直以来所拥有的那种专业积累，以及对开发者的热爱与关注，带到更广泛的层面，让它在整个 Microsoft 内部产生更大的影响。

对。还有，我刚才听你说，这是你们第一次举办有外部贡献者和演讲者参加的 build 吗？

我觉得这次 build 是有意这么做的：我们重点邀请了来自社区的演讲者，对，在这些主要场次里也是这样。包括 keynote 在内，我们请来了很多像 Peter 这样的人。还有一些场次也是由 Swix 和其他人来分享。

我觉得这很重要。软件开发是一项团队运动。你会觉得，如果认为有哪一家公司、哪一个团队——包括 GitHub、Microsoft 以及其他所有人——可以回答每一个问题，那就太不现实了。软件不是这样做出来的。我们大家至少都在使用 open source（开源），而且都是站在这些庞大的 open source 项目的肩膀上继续构建。

我们应该邀请那些能一起讲述各自那部分故事的人加入进来，因为我由衷地相信，这正是开发者想要的。我知道这是我想要的。也知道我那些做开发者的朋友想要的也是这个。而且当我们回看这些活动、听取反馈时，他们确实会因为能在同一个活动上看到来自 Microsoft、来自 GitHub 的人，然后又能看到一种外部视角而感到兴奋。

这真的、真的很有意义。对。

这说得通。而且这是一个竞争非常激烈的市场，对吧？当然。对。

就像，你知道的，这可能是竞争最激烈的市场。也可能是最后一个竞争激烈的市场，我不确定。但是，在变化速度这么快的情况下，你们要怎么在这一切之中实现差异化？

对。我的意思是，我觉得我们会继续专注于我们的根基，也就是，我们一直非常在意 developer choice（开发者选择权）。这一点始终如此。我们关心的是为 builders（构建者）打造产品，并赋能 builders。所以我觉得我们现在所处的这个阶段非常有意思，因为我们已经从一个拥有大量 API、各种访问能力的时代，走到了某种有点无意形成的 walled garden（围墙花园）式格局里，在这种格局下，你会对某一类东西产生一种偏好。

有时候我会说，这有点像一个小小的 mousetrap（捕鼠器）。对吧。你懂的？然后你就会意识到，哦，这边这个东西其实特别有意思，于是我又得去学一个新东西，或者一个新工具，或者新开一个账户。我觉得对我们来说，我们一直都希望让那些基于 GitHub 进行开发的开发者，能够去使用这些其他工具；我们也会和所有人合作，尽可能把这件事变简单。

虽然我觉得，确实也有其他人在做类似的事情，但我认为，能够把这件事覆盖到软件构建的全过程，而不只是 cogen 这一侧，或者不只是协作审查这一侧，而是真正覆盖一切，这是我们非常独特、非常强大的能力。所以，我想你会看到我们持续投入自己的技术。比如我们提到过新的 Microsoft AI models（AI 模型），我们会继续把它们带给开发者。与此同时，我们也会继续和 Anthropic、OpenAI、Google，以及基本上任何把 model（模型）或 coding agent（编码 agent）推向市场的人合作。我们会和你合作；我们既可以让你把这些东西带到我们这边，也可以通过 GitHub 和 GitHub Copilot 把它提供出去。

对，选择权是核心。这也是我认为我们永远都不会退让的一点。因为如果我们退让了，开发者依然会做出选择——他们只是会被困在另一种 mousetrap 里。

而我们不希望软件世界变成那个样子。

对，对，对。那你们在内部做决策时，是怎么处理这个问题的？比如前阵子有一轮新闻在讨论 cloud code cancel licenses 正在被取消。那像这种情况下，你们怎么权衡：一方面是 dogfooding（内部先用）自家的产品，比如使用你们新做的 models（模型），或者使用 GitHub Copilot app desktop app；另一方面又要让开发者去尝试别的工具？

对。我的意思是，我们所有人其实都在使用各种不同的工具，因为不然的话，你就会失去对外部情况的感觉，或者说，你会过度沉浸在自己手头做的东西里。对。所以对我来说，这么多年来我一直都把 MacBook 当作 daily driver（日常主力设备）。而到了周末我玩电子游戏的时候，我会用 Windows PC。

我接下这个角色之后，我有我的 Mac，有我的 PC，还有我的 Almarquee Linux box，这样我就能确保自己——基本上每个周末我都会写代码，大多数周六都是这样。早上我会陪孩子参加体育活动，到了下午我就在写代码，并且在这些机器之间来回切换，因为我想真正理解：好，那种体验到底是什么样的？比如 GitHub Copilot app，我只在 Windows 上用，因为我想确保使用 Windows 的开发者也理应拥有优秀的 app。

对吧？不是说只有用 Mac 的用户才算受众。我们团队里普遍都是这样，尤其是当我们在看：那 coding agents（编码 agents）怎么办？harnesses 呢？desktop apps（桌面应用）呢？

那 memory management（内存管理）怎么办？还有，你知道，其他所有这些怎么办？我们的文化非常好的一点就是会不断做实验。每个人都在构建并使用这些工具。当然，很显然，我们大部分精力还是放在我们自己的工具上。

这是一个很大的盲点，我觉得 GitHub 过去就发生过这种情况：当你在做一件事，而且做得很好时，你就会进入一种高度聚焦的状态，而这也是创业公司的每一分能量都会驱使你去做的，对吧？就是埋头往前冲，不断前进，快速前进。而我觉得这其实很短视。你知道，我并不是说我每天都要花时间去用每一个工具，但当有新东西出来时，我想知道它为什么真的这么好。

人们为什么会对这个东西有很好的体验？不仅仅是为了让我理解它，也是为了让我搞清楚：好吧，就我们的目标而言，就 developer choice（开发者选择权）这个目标来说，也许我并不需要这个。比如说，我想把重点放在别的方向上，但我还是想知道开发者为什么会选择这些工具。我们的团队也是一样，道理相同。

对。那你们是怎么筛选的？因为很显然，很多这些想法的生命周期都比较短。对，对。

而 enterprise（企业级）产品的开发周期会更长。对。那你怎么做判断？

对。我觉得现在我们正处在这样一个阶段：我们非常关注短期，关注如何抓住支持大量 agent（智能体）session（会话）的能力。就是这种思路，因为这件事看起来已经相当明确了。你知道，大家都在做。我们怎么把它真正巩固下来？

但从长期路径来看，有些事情似乎也很清楚。model（模型）会继续变得更强。token（词元）的价格，也就是 token economics（token 经济学），会越来越成为决定大家使用什么模型的更大因素。而且我非常相信，我们离这样一种能力已经不远了：能够在本地设备上真正严肃地使用比 small language model（小型语言模型）更强的东西，去完成我们的一部分工作。所以如果我假设，在 token 这件事上我拥有所有这些 optionality（可选择空间），那么实际上，我认为从一开始到 OpenClaw 再到现在，一直成立的一个核心概念就是 personalization（个性化）、或者说“属于我”的东西、或者 context（上下文）、或者结合 context 的 fine-tuning（微调），再或者，你知道，memory（记忆）。

所有这些想法看起来都是某种一直存在的真实需求，从 ChatGPT 出来，或者 GitHub Copilot 出来时就是如此。对。也有一些实验，但我觉得整个行业并没有一个针对这件事的长期 vision（愿景）。所以我觉得这是个很好的例子：我需要让你把 agents（智能体）用得非常好，而且是很多个一起用。因为如果你真的喜欢用 agents，你就不会只是盯着一个单独的 agent 在那里工作。

但那并不会带来长期优秀的体验。使用一个让你感觉它是在替你把一个想法补全的 agent，会带来那种很棒的体验，尤其是在你不需要亲自把那个想法编码给你的 agent 的情况下。永远记住，我会插入一些东西。

那工作量可太大了。

对，百分之百。我的意思是，它应该能够直觉地领会这一点，或者也可以——再说一次——通过 post-training fine-tune（后训练微调）或者 frontier tune，去把一个 model 调到能够深度理解我，以及理解我是如何使用这项工作的状态。对，这大概就是我们的看法。

这有点像，有时候是在做短期的事，而有时候我们得为长期目标多啃几口苹果，或者说多做几次尝试。

对。

这样才能得到一些真正具体、可感知的东西。对，来帮助我们继续往前推进。

很好。我昨天大概听了有一百次 hill climbing 这个说法。而且我非常支持这种思路，因为你知道，像用 DSpy 做实验、order research，还有其他一些。我想请你讲讲，为什么这已经成了一个重点方向？

对。我的意思是，我觉得，Satya 和 Mustafa 经常会谈到这个，Jacob 也是，他在负责 copilot 团队。我们目前学到的最重要的一点是：我们必须把工具的使用，当作改进底层 model 使用方式、改进我们自己的 model 等等的核心手段，同时也要落实那些必要的 evals（评估），以确保我们确实在进步。比如，从收到的 thumbs up、thumbs down 数据，到你是否接受它、以及你接受了多少。你知道，所有这些数据对于打造那种神奇的体验都是极其重要的，而且不仅是为你一个人，而是为所有人。所以我们每周都在讨论 hill climbing 的结果，我们会看数据，看改进情况，同时看 hard measures（硬指标）和 soft measures（软指标），因为有时候 hard measures、evals 和 rubrics（评分标准）会显示我们确实改进了，但用户情绪却可能会崩掉。

对，是吧？即使 latency（延迟）和 performance（性能）都还是一样。

对，本质上就是 overfitting（过拟合）。

绝对是，100%。所以，能够以惊人的速度真正跑完那个 loop（循环）非常关键。Mhmm。而我认为，主要目标是把这种 hill climbing machines（爬山式优化机器）交到每个人手里，而不是让你还得像我们一直以来那样，用那种比较难的方式去做。尤其是如果你，知道吧，在 enterprise（企业）环境里，并且你在用 m three six five。我们对那些数据知道得非常多，或者说，基于所有这些 assets（资产）、documents（文档）、chats（聊天记录），我们本可以知道得非常多。所以，能够，知道吧，开启像 Frontier tuning 这样的东西，并且用，那个，用 MAI thinking one 作为 base model（基础模型）。

它能在不用做所有那些额外工作的情况下，展示出真实结果。这也挺有意思的，因为我第一次听到这件事的时候，老实说，我当时的反应是，这就像个 magic parlor trick（魔术把戏）。对。你知道，这不可能——它不可能真的有效。对。

你知道吗？而我觉得现实是，有时候 alpha（超额价值、关键信息）就在那儿。就是那种让你感觉“这也太简单了，怎么可能有用”的地方。Mhmm。你知道吗？

你知道，我们手上都有这么多数据，那我们该拿它做什么呢？我们总觉得必须付出这么多 effort（工作量）才能让它发挥作用。但我认为，最近出现了很多东西，让我们可以直接利用这些数据并持续改进。看看 workflow（工作流），去改进，然后不断做 hill climbing（爬山式优化）。所以我觉得我们才会反复这么说：这不是那种 moonshots（登月式豪赌），更像是一次次 hill climb（爬坡式推进）。

它就是不断地爬、不断地爬、不断改进：新的 eval（评估）带来改进，新的 data（数据）带来改进，然后就这样一直持续下去，直到，知道吧，我们能够为自己发布这些 models（模型），七个 models。对。然后，再让客户也能用同样的，或者类似的，知道吧，tooling（工具链）去做到这件事。

这是不是阻止 $200 subscription（订阅）变成 $2,000 subscription 的答案？

我的意思是，我觉得，从 $200 subscription 到 $2,000，关键真的不仅仅是，知道吧，去构建这些 models，或者说，对这些 models 做 frontier tuning，让它们能以那种方式更了解你；我也觉得，这还会非常非常关键地取决于，我们怎么做，尤其是针对 developers（开发者），知道吧，帮助你自动选择 models，并且有可能在那个步骤里直接用上某个 model。

就像 model router 一样，而且完全同意。

对，没错。比如说，你知道的，带有 task intent（任务意图）和 GitHub 的自动 model router。Microsoft Foundry 也有一个 model router，也能做到这个，可以算是在 API 层面来使用。对。

如果我们越来越能帮助你——你知道的——让你告诉我们一点你的标准在哪里，比如：这是一个特别难的问题，我愿意一路用到最顶级的模型。或者我其实不想那样，我只想大概停留在这个层级，然后让我们来帮你选模型。因为很多时候，token 贵的很大一个原因，就是我们都在不停地选“今天的模型”“这周的模型”甚至“这一小时的模型”，你知道的，而那些模型都特别贵。不过我现在的思路有点在一个复杂问题和一个简单问题之间来回跳。对。

我个人会觉得，我会让一个 agent 去做大量工作，但总会有最后一步，是个不大不小的小事，比如说，哦，我其实并不想把这里所有的命名都改成那个。

对。那种事情就像是——不需要

一个 find and replace（查找替换）。你明白我的意思吧？但是我会不会真的去想，哦，我现在要省 token，所以我要从 four eight 或 five five 切到 Haiku 之类的，你知道的？大概率不会。对。

但是工具可以。

对。

我觉得这会真的帮到我们，尤其是在企业场景里，不过即便是对个人开发者，以及那些在构建 automation（自动化）并使用他们的 Copilot、SDK 来驱动这些东西的人，也会有帮助。对，他们也会受益。

我做了一件有点奇怪的事。

我希望

你不会觉得这很 creepy（令人毛骨悚然），不过我做了一个 AI 版本的你，来练习这次采访。不会吧。对。而且到目前为止它其实相当准，希望你会觉得那些问题问得不错。

而且确实，它们都很棒。不过现在我想看看 AI Kyle 说了什么。

对，没错，它就在 terminal（终端）里。我没有，就是说，我没有一口气做到头再给它做成什么视频之类的东西，

但是——我是

但我发现这特别有用。我只是想问一下，比如，你现在看到人们在内部或外部还会做哪些类似这种奇怪的事？

天哪。所以，你这么说真的太好笑了，因为我也会做非常类似的事。就是，我既会通过 app（应用）来用，然后我还有一个不能接触工作内容的 claw，你懂吧，这样我就能把边界分开。我会花很多时间让它读我写的所有东西和我说的所有话。比如这次采访，最后也会喂给它。对。然后每天，我都会收到一份类似 comms report（沟通报告）的东西，不是那种“Kyle 说了什么”，而更像是：“Kyle，你老是在说这个。”

对。好吧。这个其实不是特别清楚。嗯。比如说，你知道的，按照你说话的方式来看，因为我发现我写作和说话都有一种非常特别的风格，我会想用很多隐喻。

所以它就会给我一些清晰的隐喻例子。对。我发现，像这种人类的自我提升闭环，嗯，借助这些 agent，力量非常强大。我们很早以前在 GitHub 做 Huebot 的时候就聊过这个，比如 chat ops，我们当时常说，人类比起接受其他人的批评性反馈，往往更愿意接受来自机器人的。

这带来的威胁感更小。完全同意。所以当我的 open claw——我亲切地给它起名叫 Baxter——告诉我我在哪件事上做得有多糟时，对，我会感觉好受得多，会说，告诉我为什么。然后确保当我在写 email、写脚本，或者审阅细节时，你都在给我这种反馈。

所以我的很多 agent loop，其实更多是围绕我自己，而不是软件那一侧。我当然也还有那些工具，你知道，但它总是在回头看。它会说，好，过去七天里，我要读完 Kyle 的所有 email、Slack 消息之类的，然后给我反馈。接着再回看 agent 之前告诉我该做什么，Kyle 有没有做到，然后再往前回看七天。这个闭环真的、真的、真的非常强大。

而且老实说，我觉得这就是我想从 AI 中获得的那种个人消费者体验，你知道，能够用这种方式去调校这些工具。

对。我们也需要递归式地自我提升。完全同意。对。非常感谢，

我很感激。对。对。对。

这段交流很愉快。

天哪，各位。你们真的、绝对一定要猛点那个 like 按钮并订阅 AI and I。为什么？因为这个节目简直就是精彩到极致。就像你在自家后院发现了一个宝箱，只不过里面装的不是黄金，而是满满纯粹、毫无掺假的关于 chat GPT 的知识炸弹。