swyx 对谈 Stanford CS146S 讲师 Mihail Eric，解读 AI 原生软件工程课程

自动生成的文字记录，已与最终节目对齐。时间戳可打开 YouTube 上对应的片段。

0:00 swyx · 开场 —— 好的，这是一期相当特别的节目，因为我们正在庆祝 AI Engineer YouTube 频道订阅数突破 100 万。如果你还没听说过，快去那边订阅一下。嘉宾是 Mihail Eric，他不仅在斯坦福教授 The Modern Software Developer 课程——这门课现在正在走红，因为它涵盖了所有 AI 原生开发的最佳实践——而且他还是 Monaco 的 AI 负责人。所以他不仅是一位老师，还是一位实践者。

0:24 下周即将参加 AI Engineer CODE Summit 的各位，这将是你们在过去一年中所见编码领域巨大进步的一次庆典。我对所有这些主题都很期待：对抗 slop（低质代码）、系统一模型，以及提升你对基本上重写一切代码的雄心。对于 AI 工程师来说，从来没有比现在更激动人心的时刻。有了 100 万 AI 工程师，我认为一切才刚刚开始。

0:49 那么让我们进入访谈。

0:51 好，我们现在在演播室，嘉宾是斯坦福兼职教授、Monico AI 负责人 Mihail Eric。欢迎你。谢谢，很高兴来到这里。你引起了我们的注意，因为你正在第三次更新你的课程——第三次？

1:03 第二次了。第二次了。是的。CS146，或者叫146S，斯坦福的“现代软件开发者”课程。

1:09 Mihail Eric · EO Studio 节选 —— 这一代初级开发者、初级工程师，也就是现在正在进入职场的人们，我认为将成为这场新变革的第一代人。

1:18 我看了课程大纲，心想，这不就是我们覆盖的所有内容吗。所以我不时地会邀请像你这样的嘉宾，你们涉猎广泛的话题，然后我们可以逐个话题展开，让听众了解每个话题的最新进展——我猜你在自己的所有节目里也是这么做的。当然。给我们讲讲这门课的历史吧。

1:36 是什么让你想开设 CS 146 的？对，这是第二次开课，我第一次教是去年秋天，也就是 2025 年秋季。那是在 4.5、4.6 出来之前。其实早在 2025 年秋季之前，这门课就已经筹备了大约一年。课程的起源大概在 2024 年 11 月。我当时有个想法：我们看到编程智能体领域正在发生这么多事情——是的，那还是早期版本的编程智能体，但当时就已经感觉到，开发者的工作方式正在发生剧烈变化，我们完成工作的速度变快了，诸如此类的有趣变化。

2:08 而且当时，这些内容都只是零散的博客文章，如果你想学习这套方法论，只能在网上东拼西凑地找。所以我就有了一个想法：嘿，有没有办法围绕这些内容构建一套更正式一点的课程体系？

2:23 我有了这个想法，我的母校是斯坦福，我一直想回去教点什么，把得到的传承下去。我一直非常深入地投身于教育。我和 Chip 聊过，她也教过一门课，我的好朋友之一 Chip Yen，对，就是 Chip，我和她聊了，我记得她教过设计机器学习系统之类的课程，所以我问她那过程是什么样的，从她如何设计课程大纲中获得了不少启发，然后想着向学校提交一门课，把它办起来。花了大约九到十个月，也就是从 2024 年秋季到 2025 年中后期，让课程通过了委员会，

2:58 为这门课的存在提出了理由，你知道的，得准备一份提案以及所有材料。这把我带到了 2025 年秋季，我第一次开这门课，反响非常好。学生们真的很感兴趣。去年好像还有一篇《商业内幕》的文章专门写了这门课。然后，今年，很多事情变了。我觉得尤其是智能体、自主编码智能体，以前所未有的方式迅速兴起。

3:23 所以感觉是时候重新来一遍，更新内容，于是就有了现在这门课。与此同时，你还是 Monaco 的 AI 负责人，这也是一家非常热门的创业公司。是的，是的。我们现在正风口浪尖上，干得很开心。对，我很欣赏的一点是，你也算是一位实践者。你们显然在 Monaco 落实这些东西。是的。从去年到今年，在比较高的层面上，有没有什么原则或观察发生了变化？

3:53 有，有，变化很大。回想去年那版课程，我的意思是，编码智能体那时已经存在，但我们还处在那样的阶段：涌现出许多公司，去攻克 AI SDLC 的每一个环节。有专门做代码评审的编码智能体，有做规格设计的编码智能体，有做 SRE 的编码智能体。你知道，其中一些，当然，其中一些公司至今仍然存在。

4:16 但去年的感觉更多是一次广泛的巡礼：这是你可以使用编码智能体的所有地方。某种意义上，去年的很多课程内容都偏向于曝光和介绍。就是这种概览式、类似奥德赛式的旅程：嘿，你所知的一切 SDLC 正因为 AI 而改变。而今年，我觉得有一些原则正在逐渐固化，对吧？

4:38 比如非常精细的上下文工程这一理念，以及把设计和架构真正想清楚，以此应对非常复杂任务的理念。我这门课的性质决定了它不是为初学者程序员准备的。它不是传统计算机科学——比如算法——的替代品。实际上，很多那些课程正是我这里内容的前置要求。

4:59 但我确实知道你们已经有了良好的基础，接下来就是把这些原则应用到真实世界的生产环境中去，我认为现在已经到了这样一个阶段：在 Monarcha 我们处理的是庞大的代码库。我也帮很多公司思考他们庞大代码库的设计之类的问题。所以这更像是一门面向实践者的课程，针对那些已经毕业或即将进入职场的学生，教他们如何成为职场中最具生产力的成员。

5:25 你说你热衷于教育。我觉得处于大学阶段的学生正处于一个相当有趣的位置。有什么建议吗？人们现在还应该学计算机科学吗？

5:40 Claude Code 和 Codex 就是我们所需要的一切吗？比如，我想听听你的想法。是的，你可以想象，学生们有很多焦虑。这次我想传达的很多内容是，焦虑依然大量存在。去年也有焦虑。但我想论证的是，一名训练有素的 AI 原生工程师，我知道这像个流行词，但我们或许可以深入探讨一下其中最有趣的部分。

6:10 一名训练有素、AI 原生的工程师可以成为任何公司最有价值的资产之一。

6:17 其实这是开课的第一周。第一周，第一堂课，我就说：嘿，我真心相信每家公司都需要你们，但门槛高了很多。你们是毕业后进入第一份工作，但仅仅达到 L3——如果借用 Google 那种职级体系的话——是不够的。你们通常必须达到几乎相当于资深工程师的水平才行。

6:39 那么我们怎样才能更快地达到那个水平呢？对吧？所以我想说的是，仍然有一些基础的软件工程核心内容是需要掌握的。比如软件系统如何构建的一些核心价值观，以及这些系统之间的权衡。在那之后我们再继续，我认为这正是你们作为人类应该仍然有价值的地方，而其余的实现细节你们可以更多地放手交给工具。

7:02 嗯，是的。这是我以前说过的话，几乎是种争议性言论，就像那种故意说得辣耳朵的话，但我几乎真的相信这一点，那就是：大多数学生都完蛋了，其中一些人会变得非常有价值。我知道这不是什么受欢迎的说法。斯坦福的孩子会没事的，对吧，他们可是斯坦福的。但美国其他地方的学生会怎么样呢？这是个过头的问题。这是个奇怪的局面，因为我觉得教育体系的变革总是很慢。我甚至很好奇，在一门这样的课程里，你如何确定教学大纲的截止日期在哪里？

7:39 你在斯坦福教现代软件开发，一切都变了。你这是在作弊。你干脆请写编程智能体的人来做讲座，对吧？

7:48 哦，对。让他们成为那个，对。这挺有意思的。新的老客座讲师。嗯，对。我是说，就客座讲师这点来说，我觉得去年也是这样的情况。这是有意为之的，因为，你看，我是刚来的，对吧，我是实践者，正如你指出的，swyx。我是实践者，我在日常工作中就是做这个的。

8:09 我设计这些系统。你知道，在 Monaco 构建这些东西，已经见过很多次了。话虽如此，我也不想说今天我就掌握了所有答案。那样说就太狂妄了。所以这门课的结构一直是：这是一位从业者在领域内工作、与领域内很多人交流后汇总的一套见解。

8:33 但有些人就实实在在地站在最前沿，看到的甚至比那更远，邀请他们提出自己的方案、他们眼中的世界图景。这就是客座讲师存在的意义。我认为让学生看到大名鼎鼎的人物、真正在做这件事的人，直接听他们讲、向他们提问，对学生影响很大。当然，你知道，他们想实习、想找工作。

8:56 有客座讲师是好事。不，我想他说的是这个意思。好，那我换个说法。不，是这样，你知道，我们也采访过 Ange，他教 Coachella 那门课。对，对。那门课就像是，这里有所有的名字。全是名字，对。而他实际上也在产出，比如，用 200 行代码实现 cloud code，对吧？

9:15 没人会教你做这个，也不会有人来演讲讲这个。但当你想教基础、教一个可用的框架和切实的理解时，这就是你该做的事。没错，没错，对，对，正是如此。我确实认为这类材料需要一种平衡，正如你所说，它并不是 100% 定型的。

9:34 我是说，这是有意为之，可以说是特性，也可能是某种缺陷，但课程的很大一部分确实比去年有了变化，对吧？

9:42 所以整个课程的开发是有活力的。但我至少想说明，有些内容我相信会一直保留下来。是的，提示编码智能体，它们变得更聪明了。这在应对它们的新方式上意味着什么？

9:53 但话说回来，Boris 也总会知道一些我不知道的东西，对吧？所以让他也来到桌前，分享他的心得。这次我注意到一件有趣的事，其中相当一部分内容是关于开源贡献的。这背后的考虑是什么？

10:11 你有这些人……对，对。对，这确实是我最引以为豪、也最兴奋的事情之一。我是说，这门课马上就要进入第二周了。对，这些就是非常慷慨的开源合作伙伴，这是非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、

10:28 非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、非常、

10:34 非常出色的教学法，说实话相当简单。我想对很多人来说，他们可能一次就能搞定，我当时想，好吧，这没那么大帮助。到了这个阶段，智能体已经无处不在。我调查过的每一个学生，你知道，周二调查的那些，没有一个人还在手动打字了。他们都说，大家都在用编程智能体。没有，没有例外，而且这可都是斯坦福的大二、大三学生。

11:10 你调查过他们吗？市场份额是多少？比如他们用什么工具？好吧。我还没调查过，这是个好建议。你应该做一下。对，对。我会去做的。有意思，斯坦福偏好哪家。不，不。嗯，我觉得大学方面，我想他们会有一些，大多数供应商都有类似的教育项目，对吧？

11:27 我是说，对，他们对学生的套餐非常慷慨。对，对。所以我想默认情况下，甚至在开课之前，就有比如 Claude 许可，我猜还有 Cursor 许可。可能还有 Cognition 的许可。我不确定，你可能比我更清楚。但除此之外，我还能额外争取到的是，嘿，如果我不想让大家被每月 20 美元的订阅费卡住。

11:49 我希望你们去，如果想把某个东西的 token 用到极限，看看能做到什么程度，那就去做。所以，我稍后会回到合作伙伴的话题，但我通过这种方式（而不是找人谈）额外争取到的，是给学生的额外额度。比如 Factory 也参与进来了，Cognition 那边的人也参与了。OpenAI 也是。总之，对于这些开源合作伙伴，我的想法是，我在教育学生这件事上最担心的之一就是，如果大家都像 Suix 说的那样，觉得他们完蛋了，那他们会怎么样？

12:19 几乎有一种他们要被落下的感觉。我认为导师制是提升所有人水平的一个非常重要的环节，要确保不会出现巨大的鸿沟——一边是在编程智能体出现之前就已在行业内深耕、知道门道、采用编程智能体后变得超强的资深人士，另一边是那些完全不知所措的新人。

12:39 所以从某种意义上说，其中一个目标是：嘿，编程智能体已经非常强大了。我想把你们置于需要应对复杂代码库、大规模代码库的情境中。我们要与那些我认为属于最优秀的 AI 原生仓库之类的对象合作，你知道，它们都在做聚焦于 AI 的事情，要么本身就是编程智能体，要么是在为现代世界中的智能体构建工具。

13:00 我想让你们参与这些项目。我希望你们的作业之一就是实际为这些项目做贡献。在参与这些项目的过程中，你们实际上会与维护者交流。他们会审查你的代码，会帮助你建立关于优秀软件的思维模型。这样，真正的优秀软件设计就得以传承，我认为大多数学生没有机会获得这样的体验。

13:20 当然，还有一个好处是，我敢肯定他们中的一些人会因为在这些作业中表现出色而被挖走。是啊。有件有趣的事，恕我直言，如果我不说这个，会招来一堆骂声。我觉得你说 cooked 和 cracked 是为了戏剧效果。你知道，陈述极端情况挺好的。确实，确实。那我们也许应该深入讲讲课程大纲的细节了。

13:46 好的。顶层还有什么你想展开讲的吗？我是说，这已经很有帮助了。对，就这些了。好。我有一些关于学生使用工具、最佳实践的高层次问题。你支持吗？

13:59 比如作为私人导师。我假设学生们也会关注这个。所以，在深入课程之前，你在这方面有什么指导建议吗？比如在什么方面。你说过你对教育充满热情，对吧？

14:13 是的，关于 AI 还存在一种污名化，比如老师们、教授们怎么使用它？学生们又如何最好地使用这些工具？而不只是把作业丢进去，让它一次性搞定。如果有什么建议的话，如何还能真正学到东西？

14:28 对，对。我觉得课程中仍然会有一些作业，我认为这些作业并非打算成为世界上最难的东西，而是更多关于概念的，比如更偏概念性的东西。比如，你知道，skill 是什么意思？

14:39 或许更多是关于这些工具的一些战术层面的内容：skill、智能体代码库，比如 agents MD 之类的。所以有一定分量的内容就是：嘿，如果你没听过这些术语，就先熟悉起来。不过我确实认为，在真正检验这些工具方面，大部分学习会发生在开源贡献（OSS）和非常开放的期末项目中。

15:00 他们得自己去探索一些有趣的东西。不错。那好，我只是想谈谈——我们来过一遍第一、二、三、四……到第十项吧。然后再深入细节。基本上就是先广度优先。好，好。那么我们从编程智能体的内部原理开始。没错。你教人们如何编写自己的 Claude Code 克隆。它不是开源的，这一点很有帮助。

15:23 然后呢？对，是的。呃，第一周，全部是关于 harness 的内部原理，你知道，大致上是从零开始构建一个编码智能体。呃，第二周更多是，好，现在假设已经有……我们如何开始思考大规模的上下文工程，也就是超越纯粹的提示词。而我认为与之相结合的，就是在做这些的过程中思考工具设计、MCP。我觉得曾经有一段时间 MCP 挨了很多骂。

15:46 我仍然支持 MCP，我一直在用。所以我认为，到现在为止，它是一个已经存在、而且我认为会继续存在下去的标准。所以第二周讲的就是这些，有效的工具设计。第三周我想更多是关于技能（skills），以及把简单的单一用途工具扩展成更像是流程化的东西意味着什么。这就是我们要讲技能的地方。

16:06 这也开始引向智能体的自动化。第四周有大量内容是关于如何定制一个智能体的基础要素。这包括配置文件，比如 AgentsMD、CloudMD、hooks、子智能体。现代的 harness 中存在很多机制，你可以把它们用于不同的目的。所以我想让学生接触到这些。面向智能体的代码库。这可能是我最喜欢的话题之一。

16:33 就是说，这对于那些要进入工业界并思考大规模应用的人来说尤其相关：本质上，什么样的仓库才算得上能被智能体高效消费？

16:45 所以要深入思考设计服务层边界的权衡，同时也包括文档、可验证性之类的东西。这是第五周。对，第六周，大致是智能体化的代码评审。这里我觉得有意思的是，从第五周关于代码库的内容——也就是面向智能体的代码库——延伸过来，第六周更多是关于：好吧，代码评审现在正在成为瓶颈，我不知道学生们是否了解这一点，除非他们……其中一些是硕士生，所以他们已经在工业界待过，但很多人还没见过这种情况。

17:17 但对于今天大多数使用编码智能体的人来说，我们都在经历代码评审中的一种新瓶颈。那我们该如何解除这个阻塞，或者说稍微给这个瓶颈“松松瓶口”？

17:27 有哪些机制可以用？所以会讲可验证性之类的东西，以及我们如何把它们扩展到代码评审流程中。第七周，安全。显然，我想说的是……这在去年的课上也有，而我想再强调一次。我是说，对于任何执行大量操作的自主系统，我们今年看到很多这样的事，尤其是很多东西被黑了。

17:48 你知道，其中不仅仅是 Vercel 的核心软件组件，还有网关，乃至完全的 LM 网关。所以我想花一些时间聊聊安全领域存在哪些新的攻击向量，以及我们如何缓解其中的一些。第八周是后台智能体。这就是我想在这里开始触及的内容，你知道，你基本上如何在许多不同的产品服务领域运行智能体，不仅在传统的 IDE 中，还要有基于代码库和仓库中触发器的东西，在 CICD 期间，甚至基于事件触发的东西，比如 SRE 风格的机器人。

18:31 你甚至该如何构建这样的系统，我想就在过去一年，很多公司开始发布他们的文章，比如 ramp inspect。Spotify 有他们自己的版本，我记得还有 Stripe Minions，所以这些人都写了非常精彩的关于他们为做到这一点而构建的内部基础设施的文章。我想谈谈这个，让大家了解一下这是什么。是的，这一部分更多是关于当你身处现代世界的团队中时，团队级基础设施的核心组成部分。

19:00 所以涵盖从 LM 网关到 MCP 门户（就像是大规模的 MCP）的一切，然后还有如何思考不断演变的角色，我想说。这也许有点软性。就像现在是什么，你知道，也许比较普通、不算特别细腻的说法是“每个人都是构建者”，但我想更深入地探讨一下，比如究竟是什么东西正在被吸收？

19:22 哪些角色实际上在演变或新兴出现，而以前并不存在？学生们应该思考什么才是可防御的技能组合，而这在以前可能并非如此？

19:31 还有更多关于团队动态方面的考量。然后，是的，这一切都逐渐累积到工厂这个话题上，我认为这是当下很多人最关心的问题。一旦我们开始建造工厂，人类还存在吗，等等？

19:46 围绕人类参与而有意设置的新瓶颈是什么？比如意图，比如建立可验证的系统。当也许 80%、90% 的代码完全由智能体驱动时，在极限情况下会发生什么，我们大概会深入探讨这些。所以，是的。非常扎实的 10 周。我想说的是，你知道，其中一些模式比其他的更成熟。我认为人们需要知道，并非所有这些都是定论。

20:18 没错。但我会为所有这些背书，它们都是人们谈论的东西，你应该了解。我们知道开放的问题，但我们未必知道答案。完全正确。是的。我是说，你可能有你自己的版本。我很想听听你认为哪些还不够站得住脚，或者说不是站不住脚，而是还没那么板上钉钉。但即便是软件工厂，我们说的是黑暗工厂吗？

20:39 我们说的是工厂里那种半自动化的情况吗？我觉得这里其实也有个光谱。是的，你知道，站在最前沿的那些人，比如 Warp 和那些在建造工厂并销售工厂服务的公司。你知道，即便是他们，也只是声称大约 30% 多的程度实现了完全智能体驱动。那么，在极限情况下这意味着什么？

21:00 这很难说。而且有人走得很远很远，搞了黑暗工厂，然后又站出来说：伙计们，我错了。对吧。所以，就像我们在 AIE 上报道过的那样。要知道，不是每个人——他们当时可能真的相信自己说的话，但他们有权改变主意，而且他们确实会改。甚至 Boris 最近还发推说，是的，我经常犯错，大家都惊了，因为他创造了 Clock Code，人们把他的话当成福音。我就想说，不是这样的，有时候他自己都会自相矛盾，这没什么。这不是政治，对吧？我们还是科学家，我们是工程师，我们受——我不是说我教条，我只是希望人们去实验。

21:40 我觉得这也是一条原则。你之前问到原则。就是实验。我是说，你必须准备好……很多时候，当我做这些讲座或和人聊这些话题时，他们会说，变化太多了，我怎么才能跟上？

21:52 有个很简单的方法，就是每天实验 10 分钟。就花 10 分钟做一件你以前没做过的事。如果那是你以前解决问题的传统方式，现在有了你想尝试的新工具、新框架或类似的东西。哪怕只是用新东西来做一模一样的问题，也足以弥补大部分差距。是的。

22:10 我要提一下，比如，你们有 Cognition，在你谈 Code Review 的那期里。是的。我实际上和 Silas 在 Devon Review 上合作过。对，对。我觉得相当不错。这些东西很难做基准测试。有一个 ReviewBench，但没人用它。不过从定性角度看，Devon Review 挺不错的。嗯，我们在用你们的产品。哦，真的吗？

22:30 是的，Monaco 确实在用 Devon。Silas 去年也来演讲过，Silas 非常棒。超级、超级聪明。是的，我们在用你们的产品。所以我当时想，好吧，在我们采样过的众多代码审查工具提供商中——我们确实试了很多家——我们最终在许多使用场景上选定了 Devon。Silas 现在其实主要在模型那边，然后还有你想要的 Walden。

22:51 对，对，对。我也和 Walden 聊过。我还要提一下 Factory，你知道，谈到智能体就绪度，他们一直专注于这个。他们为此构建了信号和工具。你们用他们的产品吗？

23:02 是的，对。所以我们确实在用我们自己那种智能体就绪度评估。我的意思是，Eno 的也很棒。我觉得他们在这条路上起步非常早。我记得他在某次演讲中把它系统化了，好像是在 AIE，是什么时候来着，我忘了，但他的一场演讲。欧洲那场，对。对，欧洲，非常精彩的演讲。我觉得那在当时是相当超前的。所以我想，只有一个人最适合谈这个话题，我非常想把聚光灯给他，也超级兴奋。

23:27 是的，挺有意思的。我当时在 Cog，我们在聊这些东西，然后说：好吧，我们得对它形成一些自己的看法。结果就在我们聊的那个星期，Factory 直接上线了一个完整的产品。我心想：好吧，你赢了。我是说，大家基本上都认同同一件事，只是个问题——你想不想把它做成一个仪表盘？

23:45 因为它就是个仪表盘。对，对，对，对，对。但你知道，这有价值。而且我觉得，从营销的角度看，他们抢先推出 writings and reports 这个概念做得很成功。我确实跟不少人聊过，我也会经常向别人推荐说：对，你们应该跑自己那种 writings and reports。当然，有人做了开源版本，但我觉得那些原则非常重要。

24:04 是的。你是想逐条讲，还是有其他要说的？我可以逐条讲。好，那第一个，对吧？

24:11 你聚焦在 Claude Code 上，但你又把 Pi 作为开源赞助商，怎么回事？好吧，这条可能更偏营销一点，但行。我想强调的一点是——我去年也明确说过——我不为任何工具背书，好吗？

24:26 我觉得，那样做是不对的。工具来来去去，坦白说，去年开课的时候 Claude Code 还没这么火，还没被广泛接受。Boris 当时才 4000 个 Twitter 粉丝，现在嘛，你懂的，好几百万了，我都不知道他现在是不是有那么多。反正他粉丝涨了很多。Claude Code 真的是横空出世了。

24:49 我觉得什么。对，我想我们当时请 Boris 和 Kat 上播客的时候，也低估了 Claude Code。对，对。它当时才两个月大，我没怎么真正用过，只用了一次。一次查询花了我 50 美分，我心想：谁会用这种玩意儿？

25:00 完全同意。它还在 beta 阶段待了一阵子。不过我觉得他们值得称赞的地方在于：在模型还没准备好之前就那样构建了它。是的。就像人们常说的“为模型的未来而构建”。完全同意。非常有野心。因为当时模型还没那么好，你感受不到。然后呢——啊，我们看到了，我们看到它的来龙去脉了。是挺有意思的，因为他去年演讲的时候，我记得那套幻灯片相当高屋建瓴，但我记得其中一页写的就是：为六个月后的模型而构建。

25:23 那是去年十月份左右的事，我能理解他为什么会那样说，如果他知道六个月后 Opus 会发展到什么程度的话，因为我认为那也是一次巨大的突破，我甚至认为这正是课程内容发生如此大变化的原因之一，对吧？

25:37 当时确实围绕着这些智能体的真正自主性，比如长时间运行的智能体任务，展开了一场激烈的军备竞赛。不过回到你的观点，我并不是在为 Cloud Code 背书。我是说，Cloud Code 我当然在用，也用其他工具，但我在这里更想探讨的是，现代的编程工具框架（harness）应该是什么样的？

25:54 我实际上写过一篇博客文章，就是这篇，是今年早些时候写的，我在里面拆解了一些类似的原则。简单来说（TLDR）就是，凭借大致相当于入门算法课水平的理解，你就能找到一个本质上可以完成你称之为编程智能体大部分工作的智能体循环。当然还有一些锦上添花的功能，但没有子智能体，有 MCP 之类的，不过这些都没有。

26:18 但如果你想看到一个你可以与之对话、然后它真的会编辑你的文件、而且你可以用它完成相当复杂操作的东西，它不需要超过 200 行代码。所以我在教育中尝试做的很多事，就是剥开那些“秘方”式的外衣，向大家展示它的核心本质——毕竟这些还是学生，你要教的是概念性的原则。

26:37 这东西没什么更复杂的——在斯坦福有一门叫 106B 的课，就是入门算法课。要构建这样的东西，你不需要超过 106B 的知识。来，看，就是它。既然你已经教过这门课了，有没有遇到什么反对意见、问题，或者从学生身上观察到的奇怪现象？

26:54 他们有什么不理解的？他们的问题主要集中在哪些方面？你是指关于这个特定概念，还是泛泛而谈？

27:02 这个概念。就是从零开始构建，然后做你做的事情。因为这基本上就是 Pi 所需要的，对吧？对，对，对。完全正确，是的，是的。所以其实并不……我觉得他们，我完全没有收到对这个想法的任何反对。我认为他们大多数其实只是消费者，对吧？

27:21 大多数学生最终就只是使用这些工具。我认为他们很少有机会，至少在课程作业中肯定如此，去剥开这层洋葱看里面。所以那一周是讲 harness 的。周二，第一节课，讲课程安排之类的东西，等等等等。但前半部分——第一块真正的课程内容就是那 200 行的 harness。然后昨天，作为它的延续，我们实际上拿了 Cloud Code，还有那些代理工具——你需要用一些代理工具来拦截请求。

27:53 MITM 代理？是的，完全正确。完全正确。就用它。用那个工具。拦截请求和响应。很好。看看底层，看看到底发生了什么。然后就是说，好，我确实说过你用 200 行就能写出 Claude Code。但说真的，好，这里是真正的 Claude Code。所以我就直接拿了 Opus 5.5——就是两天前刚发布的这个模型——然后说，好，我拦截了这些请求。

28:13 这正是具体在发生的事情。这里是提示词。这里是系统提示词。这里是计划提示词。这里是压缩提示词。然后我们把所有这些内容过了一遍，展示给学生。所以现在他们拥有的是一个真正能够理解的最先进的工具框架。是的。能获得这三个层次很好。学生很大程度上是消费者。这里是基线智能体的循环，然后是真正的那种。

28:32 我很喜欢你为博客文章也配了视频讲解。你有没有发现学生处于某些极端——有些人是高级用户，消耗量很大。而对某些人来说，如果你了解智能体的工作原理，这可以说是相当直白的。在课堂环境中你如何平衡这一点？

28:53 比如你是按平均水平来设计的吗？对，我认为这在一定程度上是自我筛选的，因为课程内容都在这里，对吧？所以课程从——我是说，至少几周前就已经可用了，我想我几周前 announced 了它，但它其实已经酝酿了大概至少一到两个月。所以如果你去找，很可能就能找到。

29:12 而且我觉得现实是，如果学生对此不感兴趣，他们就不会——他们干脆不来，会选择不出席。我觉得有意思的是，确实有学生会来，但也有许多来自更广泛的斯坦福的人，其他院系的博士后。有很多跨学科的兴趣，比如在病理学或医学相关领域的人，甚至是其他非纯计算机的工程领域的人也来参加，也想接触了解这些内容。

29:41 还有不少 GSB 学生、MBA，他们也想学着不用找个技术联合创始人，或者出于其他动机。顺便说一句，如果有人还没做过 MITM 代理练习，你应该去做。是的。你会大吃一惊。Cloud Code 拥有所有编码智能体中最长的系统提示词。大概 20,000 token。是的。是的。不过，是的，确实如此。

30:07 确实如此。不过他们也缩减了体积。砍掉了 80%。是的。是的，我知道。但后来又长了回来。然后又砍、又长。像个跷跷板。是的。是的。不，我觉得挺有意思的。你会惊讶于里面放了什么，其中有些其实根本用不到。有时候它还能透露某些工具的内部运作机制。你在里面发现过什么值得聊的东西吗？

30:28 有，其实昨天我谈这个的时候，多少有点——关于 Cloud Code 早期，我认为最有意思的一点，也是它爆红的部分原因，就是他们对简洁性的专注，对吧？

30:41 所以在早期，他们是最早真正拥抱这一理念的团队之一：让更少的工具做更多的事情，对吧？拥抱 SQL，拥抱 Bash，拥抱那些像瑞士军刀一样的强大工具，并让它们成为能力的主要驱动力。我认为他们在这一点上做得非常出色。我想这也是他们如此受欢迎的原因。当我展示像系统提示词这样的东西时，情况是——嗯，两个月前还是另一套系统提示词。

31:05 现在呢，他们已经降低了系统提示词的复杂度，而事实证明，过去属于系统提示词的内容，比如如何使用 Git 之类的东西，

31:13 或者如何设置任务等诸如此类的内容，已经不再是系统提示词的一部分了。人们现在更期望这些内容被模型本身所掌握，比如模型权重本身。所以他们把许多这类经验更多地内化到了模型层面。这也引出了围绕模型与 harness（脚手架）的有趣问题，对吧？

31:26 你是如何思考这种权衡的？公司应该在什么上面投入？你应该投入什么才能真正推动自身能力的前沿？

31:34 所以我认为，即使作为整个社区，我们也在这两者之间来回摇摆。你不想因为系统提示词先膨胀后被精简而指责他们。从某种程度上说，这也是模型当时的状态使然，对吧？

31:47 对于更弱、更旧的模型，你需要给它们示例，告诉它们什么是好的、什么是坏的。然后在某个时点显然要把这些删掉，对吧？

31:54 这就是学习已完成工作的一部分，对吧？如果你在使用一个搭配不算最强模型的本地编码智能体，你也可以应用同样的方法，可能需要添加这些示例，对吧？

32:05 没错。是这样吧？是的。是的。当然，这也带来了有趣的 AI 经验教训，也就是随着模型变得更好，什么时候你添加那些示例反而是过度约束了它，对吧？

32:16 然后又该如何去掉这种过度约束？我认为这也是学习的一部分。好。第二周，你将讲上下文工程。Repit 我没见过，但 Spectre of a Development 有很多版本。你会向更广泛的受众强调这里面的什么内容，让大家应该知道？

32:35 是的。这就像是整个课程的一小时版本。对，没错。请把所有内容浓缩一下。我想这就是方向。合理，是的。其实它也是个预告片，对吧？

32:47 就是说，如果想要更多，就去看原版。如果你想明年或明秋报名课程，这就是你的一小时。这就像——哦，这就像课程的 Quibi。你明白我的意思吧？

32:56 作为预告片太长了，作为课程又太短了。我猜这就是人们会双击细看的内容。如果算是预告片，等你下次讲的时候，内容又会变了。确实，确实，确实，确实。嗯，好吧，你这个建议提得好。有意思。我在这里最想强调的一点是——即使在我面试别人的时候也能看到——行业里很少有人能超越纯粹的原始提示（vanilla prompting），对吧？

33:21 就是类似“嘿，帮我把这事做了”这种形式，对吧？“把这事儿做了”。当模型变得足够好时，这种方式当然能带你走一段路。但不可避免的是，我接触过的来自 Google 或其他拥有庞大代码库的地方的人都说，现实情况是你必须对如何摄取上下文有更深入的思考。所以要思考一下围绕如何指明……有哪些原则和技巧。

33:46 我在这里描述的快速框架在功能上类似于 DEX 的 RPI，或者类似的东西，即先做研究，提出类似规范的提案，然后进行实现，最后通过测试等方式把它们串联起来。我这里想强调的是，你应该有这个步骤——当你进入不熟悉的代码库时，当你试图向上下文中注入智能体需要理解的关于一个非常庞大代码库的信息时，一个研究阶段是有价值的。

34:16 然后在我提出的这个特定框架中，在完成研究之后，还会建议提出一个提案，列出解决某个问题的几种不同方案。这也是我让人类参与进来、在不同方案之间做决策的地方。然后你进入计划阶段，也就是规格说明。

34:35 总而言之，TLDR 就是：确实有一种方法可以扩展到数百万行代码的代码库。而且它不仅仅是原始提示。我想强调的就是这一点。如果你要去处理这些庞大的代码库，你应该使用更复杂一些的方法。关于上下文工程还有什么要补充的吗？

34:54 我觉得，就我目前对上下文的理解而言，最奇怪的地方可能在于拆分出子智能体的时候，因为子智能体可以（也可以不）从主线程继承你的全部上下文。有时候在这一点上会反复出现分歧。而且有时候你想把子智能体所做的事情压缩后放回主线程，这非常 hacky。我不喜欢我正在做的任何事。

35:24 所以我没有任何答案。我只知道，当你想扇出（fan out）工作时，不再只是你有一个大的规格说明然后做 RPI、做 Repit 之类的东西。不再是单个智能体了。关键是把工作扇出去，并确保它们都拥有正确的上下文，都获得正确的指导。如果你有一个审查智能体去审查其他所有工作，那你就得让它拥有全部信息。

35:48 而且你总是会经历这种扩展和收缩上下文的阶段。比如，天哪，这些智能体上下文不够，我要给它们更多上下文。好，很好。然后它们会抓住你之前随口说过的某句一次性评论大做文章，然后犯一些非常愚蠢的错误，因为你并不是那个意思，但它们却把它当成金科玉律。诸如此类。所以我都不知道我该用什么词来表达。

36:09 这就像是对上下文的多智能体管理。对，对，对。对，我觉得你说得完全正确。这里面有些东西可能比其他方面更像是艺术而非科学，对吧？

36:21 我想这是一些因素的组合，正如你所说。是的，用于探索的扇出，用于子任务的扇出，然后是压缩，不管你想怎么称呼它。我认为要慎重地考虑刷新上下文，了解什么时候上下文开始变得过于臃肿。我记得 Dex 有个概念叫“笨蛋区”（dumb zone），要更用心地对待这个“笨蛋区”。

36:39 他很擅长做这类类比。哦，是啊，是啊。那些小图示。对。哦，是啊。那你为什么请他来？嗯，我是说，他确实对这里的很多课程内容有所启发，所以在这些方面他是一位非常出色的思考者。不，我觉得那些图示非常重要，很有用。我想为想深入研究这个领域的人补充一些线索：最好去了解最佳上下文工程偏好，比如你的子智能体如何继承上下文。

37:02 Cloud 管理的智能体有一种模式，其中会话是独立的，上下文不继承。在推理模型出现之前，这曾是一个大热门话题，当时智能体运行时间没那么长，上下文窗口更短，每个人都在非常非常小心地管理那宝贵的上下文窗口。LangChain 曾经写过很多关于这方面的博客，好的上下文工程等等，这些东西都值得人们去了解。我想在学生的语境下也一样，你可以期待选你课的学生——因为这是一门很棒的课——会了解所有这些东西。

37:35 所以你也应该了解它们，而且要了解得更深入。这也是一个有趣的研究领域。在 AIE 上发表的研究论文中，有一篇研究了 Claude Code 系统提示词的差异，看看改动了什么。他们绘制了一大堆性能上的变化，试图进行逆向工程。这是你可以做的好研究。还有另一篇论文研究了上下文窗口管理及其如何影响下游性能。

38:03 它们不是最好的论文，但相当易于上手，而且还会发布不错的博客文章。所以对于想在这个方向努力的人，我只是推荐一下。这是一个你可以轻松切入的好领域。对，好的推荐。

38:16 智能体技能，CLI。对，对。我觉得这一切都是从单一形式的函数工具调用扩展而来的，比如 MCP，与第三方外部服务交互，然后延伸到你可以称之为流程的东西。如何反复自动化一组操作，然后把它以 skill MD 之类的形式正式固化下来？

38:38 我认为可以再进一步，让大家练习把其中一些流程固化下来。我还会在这里加入一些我觉得很好用、也挺有意思的技能。比如 Matt Peckock 的 grill me 就是一个不错的例子。还有一些我更喜欢的、偏教学性质的技能，比如 Jeffrey Litz 的。他有一个 explain diff，我觉得一旦谈到代码审查，它就变得格外有趣。

39:02 因为，你知道，整个……理解代码。理解代码，没错。对，你得理解代码。我不知道你们用过没有，但大致上就是，你把你写好的 diff 放进去，然后运行这个技能，最后你不仅会得到一个可视化的呈现，可以快速浏览并理解其中真正的核心内容。

39:22 但我真正喜欢的是它最后几乎像一个测验的环节，你可以一步步过一遍，真正检验自己是否理解了正在发生的事情。我觉得这种交互式的来回往返非常棒。对，这个领域有几篇博客文章我很想提一下。有一篇我认为是最近的，大意是：在任何情况下关闭自己的大脑都不是个好主意。

39:45 我认为这些技能实际上是在强迫你打开大脑。而当所有人都想用编程 AI 时，往往就是关闭大脑，只说“给我做个应用，读懂我的心，不用我说就把一切都做对”。没错。但很多这类技能其实属于那种“不，不，请多问我几个问题”的流派。我认为它带来的产出比人们习惯的要多得多。

40:07 比如我可以输入一行提示词，就能得到几万行代码和一整套结构，就像在说“看看我的生产力吧，各位”。但更有效的做法是，你应该清楚自己在做什么。你真的可能被隔绝在圈外。你应该花更多时间思考自己究竟在做什么。完成工作、把代码写出来，比以前容易多了。

40:33 是的，理解这一点是没有任何借口的，这是肯定的。抱歉，什么是 web 技能？嗯，大致上就是与 web 本身交互的技能。计算机使用。计算机使用，对，就是这类东西。还有别的吗？

40:45 主要是指那些涉及从 web 上提取信息的东西。在与 web 交互的技能方面有没有最佳实践？

40:53 我觉得这更多算是一次对我觉得比较有意思的东西的概览或演示。我记得可能出自……是不是像 Vercel？

41:02 我正在努力回想，得回头看看完整的阅读材料。我找到过一个网站，我觉得他们……也许是，可能是 BrowserBase。他们可能做过。你还记得这个吗？

41:12 嗯，这个词本来就是他们提出来的。只是我当时想，我是不是错过了什么？这在 skills 社区里是很大的一部分。他挺不错的。他在学习。是的，我想他们做了某种，因为他们当时，对，我是说，BrowserBase，显然。他们喜欢浏览器。他们喜欢浏览器。不过对，他们有个不错的，我觉得，网站，上面提供了一些这类有趣的能力。看起来挺靠谱的。

41:34 CLI 是个有意思的话题。你的学生里有没有很多人是第一次接触终端和 CLI，还是说这现在已经是常态了？

41:41 不，我不这么认为。我觉得，鉴于他们中的大多数人，再说一次，去年我会说其中一些人大概还记得亲手敲键盘的时代。

41:54 我想大多数学生到这个阶段都已经用过 Cloud Code 了。我是说，我很好奇现在只用应用的人占比是多少，对吧？

42:02 Cloud Code 也有桌面应用。Codex 也是。Codex 现在主要就是一个应用。你基本上不在 CLI 里，不在终端里。这一点会让很多普通人望而却步，不过这只是随口一提。对，我会说，你知道，我觉得关于 skills 还有一点，就是 skill 的集合，它们之间会互相引用。对，就像插件那样，对吧？

42:26 比如插件。然后还有，我想，编写 skill 的艺术，这也是我在 AIE 上着重关注的东西。我觉得很多内容都聚焦在消费 skill 上。你会看到各种网红，像 Matt Polcock 之类的人，他们会说，对，这个 skill 能解决你所有的问题。但其实不，你应该自己写你的 skill。而且实际上，当你天真地尝试去写的时候，它们通常很糟糕。

42:51 而且实际上，写好一个 skill 本身也需要一点技巧。完全正确。完全正确。swyx 写 skill 的最佳建议是什么？

42:58 我有一个公开的 skills 仓库。我确实经历过一个把一切都做成 skill 的疯狂阶段。不，不，不。别跟我们讲 skills。你是怎么写出好的 skills 的？

43:06 对，没错。所以我有一个用来裁剪 skill 的 skill。因为每个 Cloud Code 和 Codex 都有创建 skill 的 skill，对吧？所以我有一个 skill 裁剪器的 skill，把它裁短，因为它记录了那些默认创建出来的 skill 在哪些方面不好。所以每次创建完任何 skill 之后，你都要运行这个来把它裁短。不错。对吧？

43:30 我听起来像这样。对。确实挺烦人的，因为有时候确实有 slop（垃圾内容），但 slop 里也有好东西。然后你得慢慢把有价值的东西筛出来。对。哦，有意思。就像你说的，即使是 slop，它仍然是用智能体的语言写的。所以 slop 是有意义的。就像，对，好，明白了。这挺有意思的。每个人都有自己的一套做法。我用过，首先，对一个 skill 做 vibe check（直觉检验）是非常容易的，对吧？

43:54 你直接调用它，跑几次就行了。是的。然后我会把这些偏好提炼成一个技能，内容大概是“我喜欢这样，他不喜欢那样”，而且它会随时间不断调整。之后，你知道的，它就能自动化了。所以问题在于，没错，你确实在调用它，但最糟糕的部分是技能在你没预料到的时候被触发。比如，你写它是为了修某个东西，结果后来你在做完全不同的事情时，它却触发了。

44:18 为什么？因为它的编写很粗糙，触发条件写着“只要发生什么什么就调用我”。你心想，好吧，读了下觉得没问题。然后你换了另一个项目，它就触发了，你会想，哦，真见鬼。是的，到底该怎么办？

44:29 有些人就是“好，我有一堆技能，不断往上加，有时跑一下”。而我知道有些人，比如 Eugene Yan，他们对技能数量非常讲究。他们会修剪它们。如果没被用到，每隔几周就清理一次。是的。所以，如果你身处技能这个领域，这是个大问题。我怀疑这也是为什么 OpenAI 和 Anthropic 里有些很聪明的人希望技能消亡。

45:00 这不是个受欢迎的说法。他们不会公开这么说，但这感觉很草率。这感觉很草率。我看到自己身边搞技能的人就很草率。这感觉不太符合 AI 至上的精神。你明白我的意思吗？

45:14 是的。这不是 AGI 本应呈现的样子。就像每个人都有一大堆 Markdown 文件。我觉得部分原因在于……从某种意义上说，确实存在一个“园艺”问题。实际上很多人根本不去看自己的 Markdown 文件，对吧？

45:28 比如它的用户体验，就是直接在聊天里说想要什么，在对话中创建一个技能，使用它，查看输出。你可以在从不查看 Markdown 的情况下获得大量价值。在某种程度上，别把它搞得太复杂。你能获得很多价值。如果你重复做某件事，直接说“看看我们最近五次是怎么做的，给我生成一个技能”。然后你可以通过对话来迭代它。

45:53 它也有好的一面，对吧？还有另一种看待它的方式。可以把技能当作智能体随时运行的一个流程，用来做代码评审之类的。但在像 Devon 这样的案例中，我们把技能固化为呈现最佳实践的方式，然后把它暴露给智能体或代码评审系统，让它按照我们喜欢的方式去实现 API，按照我们定义的方式落实服务级别的约束。

46:22 这是一种替代方式，用来表示组织层面的知识，而不只是“你想让智能体随便做点什么、免得每次都写提示词”的随意产物。所以我很喜欢这一点。我感觉这一定位、这个用途，可能比这些随意的流程存在得更久。

46:42 我刚 Google 了 Monaco AI skills，结果给我的是那个国家。

46:48 有一天，总有一天，我们肯定会在 AEO 上击败他们。你能不能干脆把这个国家买下来？事情是这样的，这个嘛，我们马上就要——不，我们不会去买这个国家，但是你知道吗，我们买下 monaco.com 域名的时候，确实招来了一些麻烦。我得说，我们还被他们告了。所以呢？对，这事儿有一整个公开的，有一整个公开的事件，对，他们不喜欢我们这么做，但结果就在这里，我们赢了。

47:17 我们赢了。好，那这段就保留。我刚想说这也太劲爆了，但你们赢了。对，对，没错，没错。所以那些到处飞的旗帜是因为这个？

47:27 因为这像是一种胜利。就是因为这是一场胜利。是我们的胜利。哈哈，有意思。在旧金山的朋友，抬头看看就知道了。对，音频听众们，我们在 YouTube 上展示这个——你们让飞机绕城飞行。我觉得你们还是少数真正坚持这么做的公司之一。这是 Sam Blond 想出来的，每天 6,000 美元。我不觉得这会直接让我去谷歌搜 Monaco 是什么，但 Monaco 的所有广告都只是“Monaco + 美元符号”。

47:58 没错。我们代表金钱。以美元符号开头，然后是某个数字。这就开启了对话。广告的全部目的就是：Monaco 到底是什么鬼？

48:07 是的。这值得商榷，但从某种意义上说，营销的目的如果不是吸引注意力，那又是什么？对，而且，也许在这之上还有一个层次，就是如果有人……我去参加活动的时候，人们会说，哦你们就是那个开飞机的，就是那个在广告牌上放个大数字的，什么 1.93 亿之类的。然后他们会说，但你们到底是做什么的？但这就是重点所在，对吧？我只是需要有人拿它来当个破冰话题。我得说，你走进来的时候我也就是这么说的，就像，啊，那些飞机，然后呢，你们是做什么的？

48:42 好吧，让我来告诉你我们是做什么的。作为一个亲身参与过那些会议、决定 Devin 广告牌内容的人，我们在措辞上花了太多时间。也许我们就该直接写，Devin。我觉得你可以这么做。那也太蠢了吧。不过，你看，我想 Sam 上周又发了一个帖子，他谈到——Sam 基本上算是我们的营销军师。

49:07 而且，对，我觉得飞机这事背后还有一点历史。不过简单来说，他的一贯作风就是：我没有所有答案，你就得去尝试。我觉得很多事都是这样，我们就是去尝试。如果火了，很好。那，你们当时知道它会火成这样吗？

49:21 呃，说实话不太知道。但现在既然火了，这就是个点子。对，没错。而且极简主义，从小做起、做大，而不是从大做起、做小。对，从小做起、做大要容易得多。没错。而且，你知道，一天才 6 千美元，就是纯粹的尝试。我觉得人们……比广告牌便宜。比广告牌便宜，这是肯定的。对。而且很有趣。也没什么坏处。不过呢，值得提的是这种简单性：当我们想超越飞机的时候，我们就会想，你知道比一架飞机更好的是什么吗？

49:50 两架飞机。两架飞机？什么？我的火箭方案。好吧，好吧，我也有过那个想法。我也希望那个想法在某个时候能实现。不过走着瞧。这是下一次 SpaceX 发射。我们看到摩纳哥了。对，就是这里。为了拍星空。就是这里。就是这里。得先跟 SpaceX 的朋友们热络一下。我很开心。你不想吗？

50:15 嗯，我是说，我们刚才提到摩纳哥了。值不值得稍微聊聊摩纳哥？还是留到最后？对，对，对。因为话题之间总得有个中场休息。你决定吧。好吧。我们提到了摩纳哥，对吧？

50:26 比如说，让我们……我觉得提了一嘴摩纳哥到底是什么，然后却不解释，有点让人恼火？确实。你能解释一下吗？

50:33 当然，希望可以。好。这就是那个国家。它是个很小的地方，我猜。看这里。来了。好了。这就是摩纳哥。这是我所认识和喜爱的摩纳哥。对。我们是一家 B 轮公司，在 Basin SF。我们实际上在打造一个一体化销售平台。完全 AI 原生的智能体来做所有有趣的事，或者至少做那些人类不喜欢做、但智能体喜欢做的事，因为它们没什么主观偏好，而且出错率更低，这样销售人员和销售团队就能专注于做人类擅长的事，也就是达成交易。

51:12 那么按理说 Mark Benioff 不喜欢你们。大概不喜欢。不过说实话，他也是个非常 AI 原生的人，在 Agentforce 和各方面都很激进。你们在做什么是他没做或做不到的？

51:26 好吧，现在我们……我们创立公司时，选择切入的市场从一开始就不是企业级市场，对吧？

51:35 我们的想法是，如果我们的目标是打造一体化平台，那就需要和一批客户一起以迭代的方式逐步构建，并和他们共同成长。把人从 Salesforce 那里拉走要难得多；而如果说，嘿，我们在你还只用 Google 表格追踪销售管道的阶段就遇见你，给你展示一个更具 AI 吸引力的解决方案，那我们就能和你一起成长。

51:59 从某种意义上说，这有点类似 Brex 或者所有 YC 公司的模式：先卖给同批次的伙伴，和他们一起成长，然后再往高端市场走。所以我敢说，我们是最好的，或者说至少是最好的面向初创企业的销售平台之一。我们所有的客户都是早期初创公司。目前主要聚焦在 A 轮左右，大概是种子轮到 A 轮。

52:24 现在我们正向更高端的市场迈进。在过去一年半里，我们对一体化模式有了很多了解。而你是 AI 负责人？

52:32 对，没错。你们做了哪些很酷的 AI 东西？嗯，我们为销售场景打造了自己的智能体 harness。也就是说，呼应前面谈到的编程 harness，我们从 Codex、Claude 这类系统汲取了很多灵感，构建非常面向销售的定制工具和定制工作流，全部围绕 GTM（入市）场景打造。

52:55 所以我们构建了自己的版本，它驱动着 monocle 平台几乎所有的功能。从 TAM 评分、ICP 评分和 ICP 定义，到管道演进，再到那些销售员可能不想做的琐碎事情，比如更新会议、会前笔记、更新摘要等等。我们用智能体驱动所有这些工作流。

53:22 我们已经做到了这一点。它基本上是开箱即用的。是的，在 GTM 用例中，既有长周期智能体，也有某些情况下的短周期智能体。它相当领域专用，构建在基础模型之上。你们会为此训练自己的模型吗？

53:42 是的，这是个好问题，因为到目前为止，我想这对很多垂直 AI 公司来说普遍成立：你一开始会像使用第三方服务一样使用前沿模型，看看能实现什么，因为它们就是最前沿的。然后我想我们在过去一周也看到了这一点，就是那个 +50% 到 -50% 利润率的问题。

54:03 我是说，抛开数字不谈，我认为有趣的是，到了某个阶段，从成本角度来看事情确实变得有吸引力了。你会开始琢磨，能不能用开放权重模型更快地做到？

54:14 然后很大程度上，我认为 AI 部分的意义就在于对那些模型进行调优、构建环境，用强化学习之类的方法来打磨它们。所以，我们现在正处于那个阶段。哦，有意思。是的，我一直把这个打法称为“智能体实验室打法”，这是我自己的说法：智能体从用户出发，然后用任何需要的模型来构建产品。

54:38 但一旦你有了用户群，就可以回头补足模型这一侧。而模型实验室则相反，它们从大规模预训练开始，然后再去找用户。希望这种分工能奏效。Monocle 属于面向收入的 GTM 那一侧。没错。是的。我觉得有意思的是，他们会想为你服务，同时又以 monolabs 的身份试图与你竞争。

55:04 确实如此。在我涉猎过的这些事情里，我认为其中一个难题其实是数据增强。

55:14 可以说我在 SEO 和研究之类的事情上花了很多时间做这个。我猜对你们来说，它实际上是核心部分。没错。你觉得模型在这方面表现好吗？

55:29 有没有你喜欢合作的供应商，想给他们打个广告？当然有。我们是 Parallel 的早期采用者，我觉得他们非常强。就是通用搜索。不是像 Zoom Info 那样的。不，不，不是。是的，我们用 Parallel，也用 Exa。所以给这两家都点个赞。能比较一下它们吗？

55:50 他们俩都是朋友。他们俩都是朋友。他们都是我们喜欢分享的人。如果你喜欢其中之一，你会很感兴趣。抛硬币吧。我会保持中立。我今天保持瑞士中立态度。是的，然后当然我们也会做我们自己的数据增强版本。所以在我们的大多数数据系统中，我们构建的最有价值的软件之一或最有价值的系统之一就是我们的世界数据库。

56:13 比如公司数据库，经过增强的公司、增强的账户、增强的联系人。这样，每当我们为客户构建 ICP 时，我们就掌握了此时此刻你应该联系哪家公司哪些人的最新信息。我想说，我们的优势之一——我认为我们毫无疑问达到世界级水平的地方——就是需求生成。我们是一家非常擅长需求生成的公司。我们帮助公司增加预约会议数量，而且是以真正有效的方式。

56:36 所以是在合适的时间找到买家？在合适的时间找到买家，对吧？这基本上是这两个要素的结合。在合适的时间是什么意思？

56:41 比如，有时候——举个例子。假如你在销售给销售副总裁。联系他们的合适时机不是当他们处于某种中间状态的时候，比如他们过去五年一直待在同一个地方。如果他们刚换了工作，那是一个好信号——如果他们从一份工作跳到了新工作，他们现在进入了一个新环境，在那里他们更有可能购买或者更愿意考虑购买新的销售平台，因为他们正处于工作转换期。

57:11 所以对于销售副总裁从 A 公司跳到 B 公司这种情况，判断你是否应该在此刻联系他们的一个好信号是：你是否检测到他们的 LinkedIn 发生了变化，或者类似的？

57:19 这其中有多少是你们把专业知识注入模型和 harness 中，又有多少是模型本身就很好、存在通用最佳实践？显然两者都有价值。是的。是不是只是把胶水做好、让它可靠、在一个平台上全部完成并做好？

57:36 看起来还有一些我们不知道的东西，是你们作为领域专家的积累，内置在里面的。是的，我认为如果没有前者，它就会完全商品化。我是说，不完全是，因为一体化方案本身仍然有很大价值。我认为这确实是我们开创的东西。销售领域的大多数公司一开始都只是单点解决方案，我想他们更多尝试的是 YC 的那种方式，即先落地再扩展。

57:59 就是先选一个细分领域，然后从那里扩展。而我们从一开始——这就是为什么我们在隐身模式里待了一年多的主要原因——只是在埋头构建，因为我们从最开始就想做一体化方案。但仅凭这一点就很强大、很有意义。但我认为真正的力量在于，今天的 Monaco 已经拥有世界级的 go-to-market 团队。

58:16 就像一支真正的世界级市场推广团队，当然是在销售 Monaco。但我们销售 Monaco 的同一批市场推广人员，也就是我们所说的前线部署客户经理，简称 FDAE。他们实际上是类似顾问的人类销售人员，帮助所有客户完成入驻，让他们构建智能体工作流，并在客户自己的销售市场推广生命周期的每个环节为他们提供指导。

58:39 所以你的问题，一体化，是的，但同时也因为我们有像 Sam 这样的人，我们还招了很多曾经的 Sam 团队成员，他们是在 Brex 和其他公司里最出色的 GTM 人才。我们正在把所有这些经验固化到平台里。是的。有意思，你的谈话方式和我平时聊的其他 AI 负责人很不一样，因为你自己也是一位曾经的创始人，对吧？

59:03 而且你也习惯于用这种方式思考这些问题。在你的角色中拥有这样的背景很重要。好的。嗯，我觉得你已经把 Monaco 介绍得够多了。随着 Monaco 这个故事的发展，我们可以再回头聊。也许回过头来说，在 Monaco 内部，智能体原生编程或现代软件开发是什么样的？

59:31 我想你在教学时，可能是在给大家描绘整体概貌，但在 Monaco 内部，你们在某些事情上是不是更有自己的倾向？

59:40 是的。我们基本上从第一天起就在编程智能体上进行了投入，也学到了很多。我们积累了不少“伤疤”和经验教训。我觉得我们现在正在更深入地分享一些经验。比如在我们的博客上，可能值得在这里分享一下，我们越来越多地发布一些内容，嗯，也许不是那个。那个更像是一个产品，是这些东西最顶上的那一个。

1:00:03 我想说的是，是的，当 AI 变得迫切、在扩展贡献之前，是自建还是购买 SRE。我们花了很多时间研究不同的提供商和供应商，也考虑了很多自建方案。对我们来说，像后台智能体平台这样的东西，我们有自己类似 ramp inspect 的版本，我们称之为 Monocoder，它构建在 Coder 平台之上，而我们正是用它来扩展我们的工程产能的。

1:00:26 Coder，是指 Coder.com 吗？Coder.com，对。哦，好的。我们实际上根据自己的一些使用场景对它做了适配。我们的很多智能体开发都发生在那里。它就是一款设计得非常出色的软件，本质上用于隔离开发环境、扩展到多智能体，能够运行这些长时程的智能体编程任务。Monocoder，向 John Tracy 和团队致敬。

1:00:50 来构建它。然后，从那时起，我们也构建了自己的版本，比如一个类似 Slack 机器人的东西，就是 HAL。实际上 HAL 就像是 AI SRE、客户成功和 QA 工程师的结合体，因为它驻留在我们的 Slack 中，既帮助我们调试问题、在出现故障时提交 PR，也被我们自己的销售人员用来了解产品的工作原理、弄清楚如何查明问题的根源。

1:01:21 所以我们必须回答一些有趣的问题，比如 HAL 需要根据对象不同而具备不同的个性——是和销售人员对话还是和开发者对话。像这样的系统我们在过去一年左右的时间里构建了很多。要感谢 Yunja 打造了 HAL，还有 John Tracy。

1:01:41 所以你们自研了很多东西。是的。你们也使用其他工具。我们确实使用其他工具，是的。那界限在哪里？嗯，是这样。自建还是购买。那是什么？

1:01:49 对，自建还是购买。这是个好问题。我们有一个我认为很普遍的原则，就是购买是为了学习，而自建是为了长期保留。对，我刚才说反了。也就是说，你购买是为了学习，而自建是为了保留。我认为这在这里总体上是对的，早期当我们还在摸索、站稳脚跟的时候，比如代码审查就是一个例子，我们花了很多时间研究不同的代码审查平台。

1:02:18 结果直到今天我们仍然在使用 Devon，因为我们确实发现这个系统的构建方式有很多价值。所以，要向 Cognition 团队致敬。但在这个过程中，我们也尝试过一些 SRE 工具，尝试过一些现成的、可能更像是后台智能体的平台，最终决定，考虑到我们的基础设施、考虑到我们自己云平台的搭建方式，在内部构建这套系统更合理。

1:02:37 当然，我们并不教条。如果有新的东西出现，我们愿意重新评估。但在这里，我觉得通常我们最终选择自建，是因为当时没有成熟的产品。代码审查可能是个有意思的例子，因为大概一年多以前我们确实对代码审查工具做过一次全面调研。当时——我要提一下 CodeRabbit，对吧？

1:02:59 对，CodeRabbit 和它们。还有 CodeRabbit、Graphite，在被收购之前我们用了一段时间 Graphite。还有 Ellipsis，它算是 YC 孵化的公司。但选择很多，对吧？

1:03:09 我是说，我们尝试过很多家的产品。它们还不错，但我觉得它们还没达到立刻就能派上用场的门槛。所以我们就把它暂时搁置了。那是——我指的是一年多以前的事。后来我们又回到了这个话题，可以说很自然地，再次感谢 Devon 团队和 Cognition 的人，我们又试了一次。

1:03:28 我觉得当时是有人告诉我，嘿，你应该试试这个。看起来它已经进步了很多。实际上去年我在课堂上一直在用 Silas 的演讲。效果很好，而且是自然而然地流行起来的。我觉得就是这样。所以纯粹凭感觉，对吧？

1:03:41 比如，你不可能凭空知道这个。确实有过。对。这个嘛，我的意思是，好吧，好吧，我是这么说的。当我们做第一次评估的时候，那时我们其实没有选任何供应商，我们觉得没有一个供应商让我们特别满意。我确实做过一个分析，查看了我们的 PR，基本上做了一套饼图，比如：这就是它在解决的问题。

1:03:59 我们对冗长度和它发布频率与实用性之间的权衡满意吗。所以那时候更多是靠数据驱动，而不只是凭感觉。第二次的时候，我不打算再大力推动了。第一次我说，嘿，我们应该采用一个 AI 代码工具。第二次我说，不，我不会再那么做了。但后来大家自然而然地就说，嘿，Devin 挺好。

1:04:17 能把我加进去吗？所以今天大家都是自然而然地被加进来的。所以这是供应商的一种情况，我们仍然倾向于这家供应商。长期来看会怎样，我们拭目以待。但除此之外的一切，我们都觉得成熟度还不够。是的。而且还没有到让你会重新考虑 Devin 或者去写你自己的那种痛苦程度。没错。这很有意思。对。这场关于 Devin 的讨论很好，我都不知道……声明一下，我现在只是一名顾问，参与不多了，但从外部听这些还是很有意思的，因为内部有一种可以说是……信息茧房，就是在 Slack 上你只能听到正面的事情，因为大家只想传播正面的东西，而你在这里没有利益关系，你就是自己选。我是说，

1:05:04 如果你能给我们弄点免费额度，那当然也很好。我不会拒绝的。我想 Silas 会帮你搞定。好，就是这些，对吧？

1:05:14 而这些也会为你的教学工作提供依据。是的，没错。我觉得这非常好。只要你愿意，我们可以引入更多这样的内容，因为我觉得这种亲身经历非常宝贵。

1:05:25 我很乐意回到智能体友好的代码库这个话题。所以第四周和第五周，大致是匹配的。对，它们有一点重叠。是的，有一点重叠。没错。你有哪些在 Monaco 中确立的强烈观点，并推荐大家从这里开始。对，当然。对，第四周和第五周，我想说它们有一点——第四周可能更偏概念基础和方法，因为自定义智能体的方式有很多种。

1:05:53 然后我想说，第五周是我真正开始深入的地方，就是让我们思考并在一个真正的代码库上付诸实践。所以在这里我一定要向 factory 团队致意，并想强调一下类似 readiness report 这样的东西的价值。我认为我想强调的重点是，像“智能体就绪的代码库”这样的东西，在我看来是通向之后所有内容的一个先决条件，也是一块基石。

1:06:18 当我说“之后的所有内容”时，我是指，大家长期以来——我想现在依然如此——对多智能体、并行智能体、几十个智能体同时做各种事情超级兴奋。但实际上，你需要先打好基础才能把这做好。而这个基础就是：你的代码库可验证性有多高、结构有多良好、智能体理解起来有多容易。

1:06:36 所以在我看来，智能体就绪性几乎是接下来四到五周的第一块拼图——大概直到第八或第九周之前，届时我们会花更多时间讨论广义上的 AI 软件团队以及组织层面的结构。但这绝对是在为后台智能体、软件工厂打下基石。我认为从这个角度来看，一切正是从这里开始变得有趣起来。是的。有一件我注意到你谈 Monaco 时提过但这里没提的事情，就是 SRE 这一侧。

1:07:05 当你闭环时，你实际上是希望让智能体去读你的构建日志，最好还能读你线上生产的分析数据。没错。没错。是的。虽然没有明确提到，但这是一个非常好的提醒。所以我打算在两个地方把它融入进去：一是在后台智能体那一周，另一个是在软件工厂那一周。完全正确，这是一个非常好的提点。

1:07:27 这种基于触发器/事件来闭环的想法，现在可能是人们谈论智能体在软件工厂中启动任务时的两三个入口点之一。完全正确，那部分会讲到。是的。有意思的是，人们把它叫作基于触发器或基于事件——我猜这确实是它的实际技术实现方式。是的。只是这听起来几乎太底层了。触发器通常就是一个 cron 任务，对吧？

1:07:54 说实话就是这样。是啊是啊。所谓基于事件的，通常就是一个会抛出事件的 cron 任务，然后它就成“基于事件”的了，但归根结底都是 cron。是啊，没错没错。对对对，或者像 webhooks 之类的，但你说得完全对。是的，而技术术语嘛，毕竟说到底——我算是科班出身的 CS 人吧——我们就是这么称呼这些东西的，所以我想我就沿用了那套术语。

1:08:19 是的，那有没有哪些 AI SRE 公司给你留下了印象？嗯，我觉得 Resolve 那帮人在这个领域做得不错。Resolve 做得不错。我想说 Night Shift 在后台智能体这方面也做得相当好。我很欣赏他们——他们是 Greylock 投资的。我认为他们在这个领域也做得不错。是的，我想说，SRE 是一个很有意思的应用场景，而这可能会回到自建还是购买的那个问题。

1:08:47 我觉得有意思的地方在于，什么时候，什么时候它会变成，就是说，一个 SRE、一个 SRE 真正能体现最大价值的地方在哪里？

1:08:55 通常是当你面对数量庞大的服务依赖、这些巨型系统、海量的 Kubernetes，还有到处都是的 Helm 文件，就是一个规模极其庞大、Helm 文件散落各处的 Kubernetes 基础设施。我认为这就是 Resolve 在企业市场做得非常出色的原因：你去向福特、向沃尔玛销售，你说，嘿，你们的服务级别依赖关系简直是一团乱麻。

1:09:19 你看看那些展示系统如何搭建的图表。然后他们进去说，我们来试着理清这一切。我觉得在较小的规模下，通常还是可以应付的，你可以自己搞定。但我想说，在企业级场景，他们确实做得很好。是啊。对于那些从没在这种规模下工作过的人来说——因为我自己也是花了很久才意识到——这个规模大概是，这么说吧，几万个代码仓库，仓库比开发者还多。

1:09:44 在这种情况下，你根本不知道公司里任何地方在跑什么代码，因为写代码的人很可能早就离职了。这太荒唐了。而且顺便说一句，它居然还能跑。这才是最可怕的地方。完全正确。然后你就是那个值班的人，你在跟一个挂掉的系统打交道，而写它的人已经不在了。还有一堆过时的运维手册，你会想，这到底是怎么回事？

1:10:10 这真的很吓人。是啊，在企业级别，这完全是另一回事。对，所以那种大学黑客型的人，一个仓库一个人，他们从来没有体会。但我想，如果你直接给他们这个概念，把他们扔进一个模拟环境：好，入职第一天，这件事发生了，现在怎么办？

1:10:32 是啊。嗯。这里我还要再提一家。Resolve 的团队，其实去年为课程设计了一个作业，他们有效地为学生们搭建了一个沙盒。沙盒里有很多服务，各自做着自己的事情。沙盒里的服务甚至故意埋了 bug。作为作业的一部分，学生们必须实际使用 Resolve 智能体，去探测系统，扮演值班的工程师，描述正在发生的情况。

1:11:06 他们的网站挺有意思的。是啊，网站确实有意思。我倒没有。我很久没看过这个了。这个非常互动。哦，他们现在在扮演 PagerDuty 了。是啊，还有这个视频。我，呃，你知道的，你刚才在提。有意思。有意思。不过好吧。嗯。那么，好吧。你知道，除了像这样的对话，我们很少有机会聊到这个领域。还有其他片段吗？

1:11:32 因为我觉得“AI SRE”这个话题可能太宽泛，或者甚至太狭窄，呃，取决于你怎么看。对。比如说太宽泛的意思是，为什么 AI SRE 有好几个值得关注的细分方向。呃，或者太狭窄的意思是，嗯，其实这甚至不是我们最大的问题。所以怎么理解都随你。嗯，是啊。你是指专门针对 Monaco，还是泛指正在思考这个问题的各类组织？

1:11:53 广义上讲，因为这就是我们的受众。是的，我想，再说一次，这只是我们如何扩展的一个函数。我认为对企业来说，有许多问题并不总是……我几乎觉得答案甚至不一定总是更多的智能体。既然我们还在第五周的智能体就绪代码库上，当我与一定规模的公司交谈时，真正阻碍他们的其实更多是底层的 DevOps、CI/CD 之类的东西，对吧？

1:12:21 他们的合并队列积压了。搭建一个应用耗时太长。实际上有更基础的问题，几乎与再多加一个 SRE 机器人或机器人毫无关系，因为那不是解决之道，他们需要解决的是更系统性的问题。所以……

1:12:37 那么这就到了第六周。是的，完全正确。所以这就是我们要进入的……是的，完全正确。就是它了。所以是合并队列及之后的内容。是的，这某种程度上是一封写给现代智能体代码审查的情书。是的，我觉得去年到今年之间发生的最大的事情，可能就是代码审查是一个瓶颈这件事突然变得非常明显，尤其是当人们真正被赋能、生成速度变得如此之高，以至于理论上你一天可以提交 30 多个 PR。

1:13:08 然后呢？到什么时候你会决定要么亲自介入，把自己放在中间，以某种传统方式进行把关和审查，但那样你实际上就成了约束，成了速度的瓶颈。这可不好，对吧？

1:13:24 那大规模生成的意义又何在？或者说，你会说，好吧，

1:13:33 And I think a good that's thing. I think a good that's thing. I think that's a good thing. I a that's think good thing. I think that's I a good thing. think that's I a good thing. think that's I a good thing. think that's a I good thing. think that's I a a good that's thing. think good thing. I a good that's think thing. I a good that's think thing. I think that's a good thing.

1:13:45 I think that's a good thing. I think that's a good thing. I think that's a good thing. 在某种程度上，比如说自动批准？

1:13:58 从设计角度，从架构角度来说，要实现自动批准，需要满足什么条件？而什么时候你必须介入并说，实际上，这里我还是想仔细审查一下？

1:14:08 即便你真的仔细审查了，你还是在做逐行审查，还是在做别的事情，对吧？所以是的，这是一部分内容。这是我们今年的热门话题之一，我们为 Latent Space 设有客座作者计划。这篇来自 Aviator 的 Ankit。不错，不错。他有一整篇关于取消代码审查的文章，因为你知道，那也许就是最终的 Boss。那是一个瓶颈。

1:14:28 他有几个用于此的关卡。不知道你们有没有和 Fanket 聊过。是的，我读过这篇文章。我没和他本人聊过，但我确实读过这篇。基本正确吧？

1:14:38 有什么批评意见吗？没有，我觉得这是对的，大体上是对的。我猜你提到了一件事——最终把关人。我认为有两个瓶颈点：一个是代码审查，另一个可能是最上面的意图或者说需求本身。还有一些我喜欢的统计数据可以拿出来讲。每个人的数据都不一样。确实，确实。但很明显，合并代码的人越来越多了；很明显，审查的数量并没有随着合并量同步增长。

1:15:02 是的，没错。如果你看看任何真正在这方面投入并认真思考过的现代公司——有些人已经发过相关文章了，我相信我们也会发——比如最近的 Amplitude，还有 Cloudflare 写过一篇不错的；我觉得 Augment 也写过一篇很好的，讲他们的 AI 代码审查系统的设计。

1:15:23 这些都是非常棒的内容，你想分享一些链接吗？我觉得这些文章写得非常出色。是的，要为 Cloudflare 说句好话，我实际上——要向 Cloudflare 致敬，因为作为一家某种程度上传统的公司，或者说规模更大的公司，他们在围绕 AI、AI SDLC 方面的内容做得非常出色。所以他们那边有一篇不错的文章。

1:15:43 简而言之，是的，我认为这是对的。我们仍在寻找那个最佳平衡点：什么是可以自动批准的？什么实际上不能自动批准？

1:15:53 如果不能自动批准，那么即使在那种需要一定程度人工审查的情况下，我们审查什么？

1:16:00 我们还在逐行审查吗？还是在结合规格说明来审查？我认为这又是一个单独的问题：大家有没有始终让规格说明保持最新？

1:16:15 这不可能做到，对吧？嗯，好吧，这有几种不同的场景，对吧？一种规格说明是线性 issue 里的那种，还有一种规格说明存在于 PR 描述的上下文中，对吧？

1:16:25 你可以把 PR 描述作为这样一个地方：用更精炼的格式大致描述整个实现。只要它是代表代码库当前这一时刻的最新内容，我认为这就足够了。所以我们非常用心地撰写 PR 描述。我们不会只写一段话，而是让它实际上就像一份描述这个 PR 中发生了什么的规格说明。

1:16:46 甚至还有指向变更所在的文件和行级别的指引。这样你不仅能了解发生了什么的高层概览，还能看到文件的构建方式以及你正在触及的服务级边界。所以，是的，我们在这方面投入了很多。所以我要反驳一下，因为在我看来，这至少应该在内部与 PR 的规格说明保持一致，这是最低要求。

1:17:07 好的。是的。不，我指的是这个功能的规格说明（spec），代码库，因为它是所有 PR 的总和。这就好比，如果你的 PR 规格说明写错了或遗漏了什么，那差距就是整个代码库或整个代码库历史本应实现的功能与你这个 PR 想要做的事情之间的差异。所以我的意思是，我不指望你有答案，因为我自己也为此很焦虑。

1:17:30 试着指示模型去做这件事。它们做得很糟。就这样。所以人类才是规格说明之神，比如“五周前我做了另一件事，现在你却把它推翻了”。你看过 Basis 的那篇帖子吗？

1:17:44 就像他们发了一条推文，小小的推文，推文文章。我觉得他们在谈论文件产物（file artifacts）方面做得很出色。他们通过 Git 追踪这些东西，其中一些是规格说明，即事物的意图；另一个则是他们所说的代码的规范状态（canonical state），这可能更接近你描述的那种，即隐性知识、隐性意图，这些也必须在某个地方被固化下来。

1:18:07 对吧？所以那部分，全部都是版本控制的。我认为他们发现这对他们有效。所以也许这也是可以分享的东西。是的，Viboo 正试图做到这一点。这是 Basis，那家会计公司。会计公司，没错。对，对。我们很快会在我的纽约大会上请来 Mitchell。跟我谈谈那个吧。我喜欢他们提出这种做法。我对此的解决方案是，嗯，我不确定我是否准备好谈它，因为我可能永远不会发布它，就是某种用来取代 Git 的东西，以便捕获所有这些内容。

1:18:36 嗯，我称之为程序数据库（program database），它捕获所有追踪记录和所有内容，并将规格说明具体化为某种我们可以忽略并保留的东西。它还控制着附加在其上的技能（skills）。因为我认为基本上 Git 只关注代码，那么你需要一个不仅涵盖代码之外的所有其他东西的事实来源，包括隐性的——你怎么称呼来着？是的，它，

1:19:00 就像隐性的假设或约束、意图。其他东西。是的。而且还要高度并发。对。因为 Git 从设计上就在各处引入了互斥锁，这很糟糕。是的。所以你需要超级并发。你看过吗，是叫 Kid Butler 吗？

1:19:20 那位曾经当过 CTO 的人。我想他叫 Ian。我忘了他的名字，但是的。Scott，Scott。所以，是的，我认为有很多人在攻克这个问题。而且我认为有一个问题，即任务（task）的理想表示形式究竟是什么？

1:19:36 我认为赢家，可能不是我，是 Linear。真的吗？因为任务就在那里。而且显然他们已经决定成为一家编程智能体公司。只要你认同 Linear，所有的事实来源都在那里。是的，确实如此。我在想，我一直有个 somewhat 固执的想法，我认为很多公司会演变成某种版本的编程智能体公司，也就是任何与 B2B 软件有交互、收集用户相关信息或某种产品洞察的公司，我认为你也可以闭环。

1:20:12 因为归根结底，编码智能体的目的是针对发生的某些事件采取行动，其中涉及用户或客户，然后利用这些信息来修复产品上的某些资产。我认为 Linear 正在做的事情，我猜想 Amplitude 也可以做同样的事，因为它们也在获取用户分析和用户问题的洞察。我甚至设想，如果你想把它发挥到极致，你也可以用 Decagon 或 Sierra 做类似的事情，就是：这里出了问题，去把闭环补上。

1:20:37 是的，好的。所以要为智能体就绪的代码库做好所有这些准备，设置代码审查。安全是第七周的内容，不是第一周的。学生问：你的意思是安全不重要？

1:20:48 我拿这个开玩笑是因为我总说，你知道吗，在 Amazon，job zero 就是安全。他们总是这么说。是的，是的。总之，安全审查放在最后。我在 Amazon 呆过，我不记得这个，但我相信。这是 Andy Jassy 说的话。好吧，好吧，好吧。我明白了。我猜他……我在 Amazon 的时候，一部分是在 Jeff 的时代，一部分是在他向 Andy 过渡的时期。

1:21:08 但是是的，我想这个话题去年也有，今年也有。我觉得……Isaac 去年也演讲过。我发现他是一位思考非常深入的人……深入的思考者。是这个领域一位有思想的领导者。我觉得 Semgrup 是一家有意思的公司，因为他们在智能体出现之前就已经存在了。我是说，他们的 OSS 代码库早在……之类的传统 SAST 防御机制之前就存在了。

1:21:36 但我认为他们在转向——或者说不是转向——而是把自己的产品增强到这个领域，做得很好。你知道，我觉得这是个有意思的时刻，对吧？

1:21:45 现在有很多事情在发生，这些攻击向量开始浮出水面。有更多粗制滥造的 AI 生成代码。我想我这里想强调的一个核心观点，就是依赖跟踪和供应管理这个概念，基本上就是供应链。你必须小心你的依赖，适当地固定版本，不要随便敲个 npm install 就指望一切顺利。

1:22:10 是的。所以，最安全的代码库可能就是没有任何依赖的代码库。是的。没错。你看着那个依赖，心想：实现得不错，老兄，但我要自己写一个。完全正确。完全正确。这是一个有意思的见解，因为它算是走到了极限。你知道，我觉得说起来容易做起来难。但如果你相信现在代码已经商品化，代码变得容易且廉价，那为什么不全部自研呢，对吧？

1:22:36 比如，当然，那会是最安全的，因为所有东西你都看过了，一切都在你的掌控之中，而不是依赖 Axios 或别的什么。但是，你知道，我们要看看有多少人会真的这么做。那确实是最安全的。我同意你的看法。不，那种说法很危险，因为那样你就只会犯自己的错误，而不是依靠别人来发现错误。开源的全部意义就在于，怎么说来着？

1:22:57 阳光是最好的消毒剂，就像 Linus Torvalds 说的那样。就是，好吧，是的，你自己的定制软件依赖会很难被发现，因为你只有自己的用户，而他们不会向你报告。但如果这个东西在全球有 10 万用户，总会有人发现点什么。这样你就能更放心地依赖它了，对吧？

1:23:17 嗯，是的。这个嘛，基本上，我不想，我是在试图做一个理性的声音。对，对。你不能在两方面都绝对化。你，你看，我有点把你将了一军。我说服你走上了“全部依赖供应商”的思路，对吧？而那里确实有个 bug。是，是，是。这是个有意思的话题。我想知道那有多，有多少是……

1:23:40 但有多少是因为一切都……我有这么一个信念：大多数乃至所有的开源软件仓库，将来都会变成实际上由智能体运行的软件工厂。到那时会怎样……我是说，看看 Warp 就知道了，对吧？

1:23:54 Warp 是一个现代化的编码智能体，当然他们也在卖软件工厂产品，但他们把自己的开源 warp 终端当作软件工厂来运营。这几乎表明，人类仍然参与其中，但参与得越来越少。所以肯定不是每个人都像过去那样逐条审查每一个进来的东西。这会让这个代码库在安全性上更脆弱还是更安全？

1:24:17 这有点难说，对吧？我觉得这里面还有一些细微之处，我们还……就连我认识的那些从事开源工作的人，也还在试图搞清楚那个稳定的平衡点在哪里。是的。还有几个相关的论点，然后我们可以继续。安全是一个永不停歇的、巨大的、巨大的攻击面。Vercel 的 Malta 有一个论点是：好吧，让我们把每一个高度依赖的用 C、C++ 编写的软件都移植到 Rust。

1:24:48 这样会更快、更安全，可能不需要 600 万美元就能搞定。然后还有另一个论点，这也与模型实验室的开源“ pacing the frontier ”有关，他们说：好吧，我们放慢速度，或者我们来做 Daybreak、做 Glasswing，确保所有人都打了补丁，然后我们就可以放开手脚疯狂加速。所以我觉得这里面隐含着一种信念：模型会解决所有安全问题。但在我看来这还没有被证实，因为如果它们引入了新的 bug，只是不同的 bug 呢？

1:25:26 没错。没错。我是说，我在寻求反驳，我在寻求类似“不，你是个白痴，显然模型在这方面强得多”这样的回应。

1:25:37 是的。我想这几乎是一个极限情况。问题在于，我们是否相信模型能创造完美的软件，对吧？

1:25:46 如果模型能创造完美的软件，那问题就解决了。真有这种事吗？如果有的话，那就到此为止了，对吧？那我们今天就到这儿就行了。我们就可以回家，余生都在海滩上享乐了。我觉得还有一个问题：先在安全上做到“足够好”行不行？

1:26:00 那么让人们先打补丁，然后推迟发布，之后再做？还是说有个问题是，哦不行，它发现漏洞的能力会强得多。即使你已经打了补丁，你还可以用完整的测试集更长时间地测试它。要多久呢，对吧？

1:26:14 你可以给它三个月。有人可以花六个月尝试利用漏洞。问题并没有解决，对吧？对，对。是的。我在这方面的一个大问题，再说一次，这整是个我们不必展开的长篇大论，你说出100个次要的组织，好吧，这些是优先目标。他们能访问一个你刚刚为之创造了100个攻击面的网络模型，好让我去入侵。而且顺便说一句，它们还相当容易被入侵。

1:26:40 是啊。我也说不清。总之，这超出了我们的级别了。聊安全总是很有意思，聊到劲爆话题。我是说，安全现在正处在风口上，对吧？

1:26:52 我觉得其实安全领域的人很喜欢这样，因为他们通常得不到那么多关注，而现在他们有了大量的关注。是这样吗？

1:26:58 你是什么意思？我是说他们得不到关注。至少从风投的角度来看，我发现风投喜欢投资安全公司，而且成绩相当不错，比如 Wiz 之类的，做得非常非常好。Wiz 和 Socket，我两天前刚跟一位风投有过这样的对话。 Apparently，Wiz 和 Socket 是过去五年里仅有的两家成功的安全公司。那 Abnormal 呢？

1:27:21 我不知道。从风投的角度来看，从经济学的角度来看是成功的。有意思。这不该由我来评判。显然那个领域有很多优秀的玩家，但我认为那是个艰难的行业。所以基本上，最好的时机——我觉得这一点没有争议——对任何安全公司来说，最好的时机就是在刚刚发生一起高知名度事件之后。是的。对吧？

1:27:44 显然。然后你显然就能卖出一大堆安全产品。完全正确。是的，所以我认为这是个合理的说法。人们应该有所意识。应该了解基本的缓解措施。我确实认为代码扫描很重要，但我只是想让大家明白，模型会引入一些作为人类你不会犯的漏洞。而如果你不检查这些漏洞，就像……问题甚至不在于它们会制造漏洞，而在于你对自己写出的东西缺乏感知，对吧？

1:28:13 比如当人类。是的，因为你知道，你会审查每一行代码。是的，是的。先不谈漏洞。模型相当不错。平均而言，我会说它们的漏洞更少。问题还在于，你甚至不知道你发布出去的是什么。比如，是的。这种情况很多。是的。而这，是的，我认为我们必须认真对待缓解措施，以及安全与 CRD 作为代码审查一部分的结合，对吧？

1:28:35 我认为做这些检查也很重要。是的，所以也许我在这里再多说一点，或者验证一下我的直觉，就是代码库的各个部分并非生而平等。代码库中安全至关重要的部分是数据存储和计费。我们可以称之为数据、计费和鉴权。而鉴权显然与所有这些事情都相关。

1:29:03 那些基本上不要用 Vibe coding，然后其他一切就随便来。对，我觉得完全正确。完全正确。有趣的是，比如说，如果你不知道 off N 和 off Z 的区别是什么，请去学一下。还有，如果你从没看过 AWS IAM——你肯定看过——请去学一下。这些都是很基础的概念性的东西，理解了之后你才能据此进行提示。

1:29:28 一旦你掌握了这些语言，你就能据此提示。如果你没有这种语言，那就完蛋了。完全同意，完全同意。对，在某种程度上，我想把这个扩展到某些云平台相关的东西上，对吧？

1:29:38 我记得，我忘了是哪家公司出过那次大事故，就是一个 DNS 问题把……搞挂了，是不是？

1:29:44 你还记得吗？DNS 问题？那你得把范围缩小一点。是，我知道。有一个特别著名的事件。是……

1:29:52 著名的 DNS 事故其实也有很多。我现在不记得了。我们一个个列举吧。总是 DNS 的锅。所以 DNS 更多是可靠性、正常运行时间方面的问题。行，行。你知道，安全性方面，人们会问：你亏钱了吗？

1:30:06 你泄露客户信息了吗？对，对，对。我肯定会把安全排在那个之上，这是肯定的。DNS 只是排在后面，因为对，就正常运行时间而言。对。后台智能体。现在你把高通那位朋友请来了。不过，你的嘉宾并不一定和那一周的内容相关，对吧？

1:30:21 是，不相关。比如第九周其实是排期的问题，我把 Ilaad 加进来了，我只是——其实并不是每周九都有课。Ilaad，我本来想把他安排在课程末尾，但我觉得纯粹是时间上没能协调好。所以是有点奇怪，第九周我好像一节课都没讲，但我们在第十周会回到那些主题。

1:30:39 所以排期有点错开，方式有点奇怪。但第八周是 Rajesh，他在 cloud infra 领域、dev exits 及更广泛的方面领导了不少基础设施工作，就在 Cloudflare——正如我之前说的，我觉得他们在这方面做得非常好，以他们这种规模的公司、上市公司的规模来看，他们的采用率非常出色。而且我觉得他们的内容也真的很棒。

1:31:00 这 fundamentally 是关于使用异步后台智能体的所有方式。我想我还会花不少时间讲 Stripe 的 Minions、Spotify——我忘了他们那个版本叫什么名字、Ramp 的 Inspects，诸如此类的东西，我觉得它们都在展示把这种东西规模化之后是什么样子。Cloud Tag。Instinct。对。是的。Muse？

1:31:23 Muse？对，我想重点不在消费者端，而更多在软件团队大规模使用它们。它们底层全都是编码智能体。没错，什么都是编码智能体。对，比如 GrokBot 就是其中一个有意思的例子，它被包装得很偏消费级。它是 Grok，但底层是 Cursor。对，对，对。是 Cursor 团队。不，不，绝对是。所以我已经看到 Cursor 在点点点地工作了。

1:31:49 但他们没有基于代码的集成，对吧？他们有。好吧，我没用过。我只用它来订 Open Table 的餐位。没错。我觉得这就是他们想做的事情的意义所在。我明白了。他们想表达的是，你可以用它来做消费级的事情，但如果你懂得怎么用好它，还有额外的强大能力，因为底层其实是围绕代码构建的。我认为这适用于所有编程智能体，对吧？

1:32:14 就像 Cloud Code、Cloud Design，人们在使用 Codex 却不知道自己在用 Codex，对吧？一个随机的代码解释器窗口弹出来，而你只是在向 JetGPT 提问。在某种程度上，底层就是编程智能体，对吧？

1:32:29 对，我再给你举一个实际的例子。我用 Codex 来管理我所有的 SEO 和 AEO，它有一个代码库，尽管传统的营销人员只会检查一个地址之类的。因为我会编写各种脚本来做各种复杂的事情。而且我需要存储数据。而且我还需要将数据可视化。很快你就会发现，只要你长期持续做任何事情，只要有比较多步骤或者比较多的数据，你就需要一个代码库。

1:32:58 嗯，这是个有意思的观点。我觉得模型也喜欢构建代码库。不，但这可能只是暂时的情况。我想我的意思更多是关于界面层面的，对吧？

1:33:09 就像，你会……你会不会说得那么远，比如 Grokbot 会有一个地方，让高级用户能够看到底层的代码？

1:33:16 是那样，还是说会被抽取出来？也许他们会直接跳到 cursorize，我猜。你是这个意思吗？没错，因为不然的话，你基本上就是在蚕食 Cursor。如果从极限来看，你所说的就是 GrokBot 就是 Cursor，那你甚至不需要 Cursor 了，因为底层的一切都变成了……是同一个团队。所以他们……现在他们不在乎。但没错，反正都是 GrokBot。

1:33:34 对，对。我认可这个说法。我是说，我确实接受，即使那些表面上看起来完全是像非技术性的用例，底层其实也是技术的，可以用代码来编写、设计和实现。这一点是绝对正确的，对吧？

1:33:47 问题只是在于，开发者是不是那个唯一的入口？对。我觉得甚至都不用是开发者，对吧？你想想一个做营销的普通人，他正在使用 Cloud Code 或者只是应用里的 Cloud，其实是在一个他永远不会知道、永远碰不到的代码库里工作，但背后有一个代码库管理器。我觉得 Cloud Tag 对后台智能体来说就是个很好的例子。

1:34:09 Anthropic 的工作方式在很大程度上就是这样，你知道，他们做出了这套东西，你应该看看他们是怎么工作的。对，对。先截个图。好，AI 原生团队。我们聊了很多关于网关这类话题。我们今天刚发布了一期关于路由的节目，还有 MCP Portal。我觉得 MCP Portal 可以说是最不成熟的。看好 MCP 吗？谈不上看好还是看衰，它现在就是整个版图的一部分了，对吧。

1:34:37 这是个断言。曾经有过一整套“MCP 回来了”“MCP 已死”的争论。

1:34:42 MCP Portal 还是一门未经证实的生意。我想过要开一个。我实际上为一个可能开设 Portal 的指南和话题做过推介，然后我就失去了兴趣。我对很多事情都会失去兴趣。不过这里面都有些什么？

1:34:55 所以我在这里想的是，这一周更多是关于如何把这套东西扩展开来——当你把某些原则付诸实践时会发生什么。这些内容很大程度上来自我与各公司领导 AI 原生团队的负责人交流所得。所以在这里，我认为 MCP Portal 只有在达到一定规模后才会真正变得有趣，那时你实际上需要一个单一入口来做治理、安全、审计、成本优化之类的事情。

1:35:25 所以我很想听听你如何看待这类东西的未来，或者它可能没有未来。但对我来说，如果你相信一个开放路由器，或者说一个许多事情都连接到它并受到有效治理的单一入口，我觉得存在一个它能轻松立足的世界。是的。是的，我对此唯一的调整是：它会并入 LLM 网关。

1:35:48 它们是完全相同的平台。这点我认可。这点我认可。我可以接受。这一点你确实可以同意。顺便说一下，这也呼应了我之前说的另一件事——我刚才说什么来着？

1:36:00 是权限管理和计费这些东西。所以归根结底，所有基础设施都会收敛到完全相同的问题上：中间有一个盒子，两边各有盒子。上帝盒子会解决一切，对吧？

1:36:14 对企业而言。只有理解了上帝盒子的职责，这话才成立。因此把 MCP Portal 和网关分开，意味着你不承认它们是同一层的问题。非常类似地，我还发现人们不理解数据库查询其实有很多相似之处：他们会把过滤与排序或一般性推荐分开。它们是同一个问题。所以当你把这些东西都放进同一层时，就能以有用的方式相互依赖。

1:36:50 如果是不同的层，就没法做到。是的。实际上我不会反驳这一点。我想也许，嗯，稍微有点说教意味——把这些术语拆开与合并为一，我认为有一点是绝对正确的：底层架构就是那个上帝盒子，一边输入进来，而另一边存在一堆其他东西——有第三方的，也有第一方的——都处在上帝盒子的另一侧。

1:37:15 所以是的，我实际上同意这一点。我有一条劲爆的推文。天哪，那条关于上帝盒子的推文在哪里？这就是从 M×N 到 M+N 的架构。所以任何从事基础设施工作的人都需要理解。恭喜你现在有了基础设施领域的工作，或者你想成为基础设施工程师，你需要明白你的全部工作就是造出上帝盒子，然后再把它们拆开。所以你的问题要么是你没有足够好的上帝盒子，要么是你不喜欢别人的上帝盒子。

1:37:50 于是你就得把它拆开，造自己的。那很好笑。确实很好笑。我喜欢。非常有趣。直到宇宙热寂。哇。真有趣。也就是说，这其实是对“做软件只有两种方式”的重述：要么捆绑，要么拆分，对吧。但问题是，你捆绑的是什么？

1:38:07 这是那些应该放在一起的东西，希望如此。然后，也许随着时间推移，人们的看法会随着什么应该放在一起、什么不应该放在一起而转变。对，对。所以，你知道，就有那么一整套说法，也许 Monaco 应该更偏向单点解决方案，也许 Monaco 应该什么都掌控，对吧？

1:38:25 还有一个问题：在某种程度上，你是在为所服务的初创公司群体做打包（bundling），在某种程度上，你是在从 Salesforce 身上做拆分（unbundling），因为从 Salesforce 手中赢得市场份额的方式就是从它那里拆分出来。这很有意思。这是一个更宏观的表述，我的意思是，把它联系到整个垂直 AI 领域。而现在，打包、拆分，这就像整个 Craigslist 和 Airbnb 的故事，还有 Tinder，那些都是被拆分出来的独立产品。

1:38:53 Tinder。嗯，你知道，基本上就是交友分类广告那种。对，对，对。我以前从没这样想过。但是的，你知道，就是其中一件事，所以我们今天刚发布了 OpenRouter pod，对吧？

1:39:05 OpenRouter 取得了巨大成功。很多人尝试构建网关，但没有人取得 OpenRouter 这样的成功。OpenRouter 只做网关。所以这就是一个这样的例子。他们不同意我的观点，即路由层还应该做运维，因为 Arise 在做运维和可观测性之类的东西。还有 MCP 网关，他们没有做那些。他们只处理模型路由。

1:39:31 我喜欢这样被打脸，因为他们会说：我们是单点解决方案，我们只把这一件事做到极致。这是我们的工程重点，这很好。但这也是营销重点，这也很棒。我认为你所描述的一站式商店在理念上是合理的。但我认为实际发生的情况，部分原因可能也在于营销，是当你看企业级市场时，它大体归在基础设施、大体归在平台之下，但会有不同的团队负责技术栈的不同部分。

1:40:04 而且我认为在企业规模上，部分整合工作——如果我们只是 MCP 门户和网关——总得有人站出来说：现在对于这两件事，你们访问的是一个统一的端点。而这从根本上说是很难让所有人达成一致的事情。所以很多时候，这更多是政治问题，甚至是人的问题，而不是从纯软件设计的角度来说这多么合理。

1:40:25 但事情不止于此。软件系统有时候更多是由人的问题催生的，而不是纯软件层面的原因。我对这个问题的看法是，你知道你会交付你的组织架构图吗？

1:40:34 我忘了这个原则叫什么名字。康威定律，你交付你的组织架构图，你购买你的组织架构图。当你创办一家初创公司或做一个工具时，你是在为公司里的谁做最好的朋友？

1:40:47 如果是为所有人，那就是为没有人。有意思。确实有意思。所以在 AIE 中，Latent Space 有意关注的一点是：有一类软件工程师真的、真的、真的非常在乎 AI。这会不会成为他们的本职工作？

1:41:05 我们就只为他们做。对，对，对，对。不是工程的捆绑。永远不会是面向所有人开发的。对，你看，我们谈数据库，谈安全，但这里面也有 AI 的角度。拭目以待吧。这说得通。

1:41:22 软件工厂。有一点我还想提一下，和刚才的观点相关，我认为未来的角色中，越来越重要的是平台工程师。我觉得这是个巨大的角色。好，补充点背景。Temporal，我在做这一切之前的工作，本来是想……对，我们本来想拥有平台工程师这个定位。如果我没有创办 AIE，我就会去做平台工程师。因为正是这个角色决定所有这些关键任务的事情，然后应用那边的小孩子们可以在我们的平台上随便折腾。

1:41:51 不过，你知道的，大公司才搞平台。对，我认为在如今，他们掌控云，掌控开发者体验（DevEx），掌控安全，所以我认为是所有这些事情的总和。所有那些真的可能让公司完蛋或成败攸关的事情，都归平台的人管。然后产品的人可以调调 CSS。

1:42:14 这话有杀伤力。你这是在挑起争端啊。我不是调 CSS 的，但我尊重每一个人。我是说，这是个有趣的时代。未来会怎样？

1:42:24 我觉得所有人都能调所有东西。对，对，对。这里有几个方面。好，这里有上周内容的一点延续。所以是的，编码智能体、大型团队这些概念，然后呢，我们会聊聊软件工厂。我希望大家真正开始思考这台制造机器的机器的世界，在这里，如果还有的话，人在哪些环节仍然参与其中？

1:42:44 今天，我认为答案是意图和某种审查的结合，或者说意图指的是你在定义规格和需要构建什么，审查指的是你自己对系统做一定程度的检查。当然，我认为这个瓶颈会比意图那一端更早被放松。但目前，我认为在一个完全自动化的系统里，这两个就是卡点。

1:43:07 嗯，所以是的，我只是想让大家接触到这个概念。作为 OSS 合作伙伴之一，Warp。作为他们对 OSS 项目的贡献的一部分，他们在做这样一件事：他们基本上会做一个运行工厂的 Warp 版本，学生们就可以去构建工厂、为工厂做贡献并维持它运行。就像在我们的工厂里干活。在我们的工厂里干活，没错。

1:43:26 所以那会是途径之一。然后他们会在那里发现有意思的东西并吸收回来。这是那种我也不太确定的事情，显然工厂本身对此非常热衷。我觉得每个人都想自己造一套。对，我认为这确实是个好问题。而且我认为，当然，他们有权尝试推销自己的产品。

1:43:48 我认为这是一个很难被一家独占全流程的系统。事情太多了。请替我决定一切吧。是啊，确实太多了。我一直在尝试……我还没太深入去了解他们在这一块的 GTM 策略。但我猜你必须得做的是逐块切入，对吧？

1:44:02 你得这么说：嘿，我们首先做的是你的编程智能体。哦，然后呢，基本上就是登陆再扩张，对吧？我们谈过这个捆绑与拆分的问题。你不能一上来就说，这是你的整座工厂。不可能让福特那样的人接受这种方案，你明白我的意思吧？

1:44:14 就直接把整套东西一股脑摆在人家桌上。至少我是这么想的：先成为他们首选的编程智能体，为他们搭建一个后台智能体，接管他们一部分 SRE 的工作。然后你再说，好吧，只要你们把一切都用代码或配置文件定义好，我们现在就能把这一切整合起来。

1:44:32 OpenAI 有一篇相关的博客文章挺有意思的。我们的朋友 Ryan，我们请他上过播客。基本上，他们花了五个月开发一个内部工具，手写的代码是零行。他们大致讲了讲过程。这个项目叫 Harness Engineering，你可以去学学 Harness Engineering。但其中的心得是，一开始会有个低谷期或者说慢一点，然后你把工作卸载出去，就有人工审查了。

1:44:56 这篇文章是二月份的，但它描绘的是一个软件工厂的愿景，对吧？就是全速前进，让智能体完全负责所有代码的编写，以及如何把这做好。是的，没错。是的，我的意思是，某种形式的这种未来一定会出现。就像 swyx 说的，我确实好奇这里的销售环节，也就是这门生意本身怎么做。这是个有意思的问题。但从原则层面来看，我认为这一直是未来的一种图景。

1:45:25 除此之外，我觉得还会探讨到——说到这个——未来做开发者意味着什么？

1:45:34 人们谈品味，谈对系统、架构的理解和软件品味。我想在这里稍微深入一点，至少试着为这个问题给出一些答案。好的。所以这就是你对 AI 软件工程下一步走向的回答。是的。工厂是战术层面的，但我觉得在那之外，还有一个关于角色的问题。这个角色会演变成什么？

1:45:57 如果工厂全速运转、有条不紊地做着自己的事，传送带不断产出代码，那我们在这其中该做什么？

1:46:05 你和我，我们几周前的一次晚宴上和 Jerry 讨论过这个问题，还有 Dex 和 Jerry，就是围绕工厂的讨论。是的，我觉得那场讨论里至少有一点我是非常认同的，那就是抽象层次不断提高，但总得有人——哪怕是公司的 CEO——也要对各组成部分有足够的监督和理解，才能对方向做出判断，才能纠正航向，才能设定各种指标之类的东西。

1:46:34 我觉得这个类比有一种版本可以转化过来，适用于某个负责技术监督的人。我们称之为智能体管理者。我们有各种不同的说法，都是些流行词。但从某种意义上说，这个人理解产品需求、约束条件、技术约束，能在这些之间循环权衡，并知道如何裁决。是的。我想说的是，在你之前坐的那几位嘉宾，我们刚采访了 Anthropic 平台的产品负责人和工程负责人。

1:47:03 我就问，你们的工作什么时候会被取代？他们说，还没到时候。所以如果 Anthropic 都还没到那一步，你就不该觉得这事迫在眉睫。好，好，好。那他们有没有说大概多久，还是只说还没到时候？

1:47:18 就是还没到时候，但谁知道呢？而且确实，当时有很多那种感觉，好吧，我在做她的工作，她在做我的工作。是的。我觉得这对学生来说也是个很有意思的视角，对吧？

1:47:28 你说这里有很多大二本科生。也就是说你还有两三年时间去规划自己想做什么。从那个角度看，思路可以有很多种，对吧？

1:47:37 你还没直接进入工业界。我最近思考很多的一点是，这场讨论中让我更有共鸣的部分是那个循环，就是，嗯，好吧，你一开始自己写提示词，现在你不再自己写提示词了。你写提示词，它们写提示词。没错。对。然后它们会不断往上层走。对我来说，那种递归的、同心圆式的结构，既向外扩展也向内深入，正是在构建工厂。

1:48:05 我认为是自上而下构建工厂，而不是自下而上。但我觉得很多人最终会开始自下而上地构建。比如你从最顶层开始，我的目标是什么？

1:48:14 然后你再 figuring 出各个系统。目前这样做会产生大量垃圾输出，你现在不该这么做。但总有一天你就可以了。

1:48:22 是的。所以，嗯，这就是我想抛给你的问题。

1:48:31 那就是，人们存在的意义所要解决的那个根本问题是什么？那是你的核心价值，对吧？比如说今天的工程师，你以 PR 合并率、PR 贡献率来衡量。那么两年后，这就变得很荒谬了。好吧，那你的核心指标是什么？

1:48:54 钱？人们总是太快就想到钱。答案应该在钱和 PR 之间的某个东西。客户满意度，你负责的功能的 CSAT 分数。不过那更像是产品决策，而不完全是代码决策，对吧？

1:49:05 嗯，我也说不准。但如果工程正在演变成更像 PM 工程师，也就是产品工程师之类的混合角色，那我觉得这就是对“这个角色会演变成什么”这个问题的一种回答。

1:49:17 我想不用说也知道，我今天会建议学生花更多时间思考整体系统，而不仅仅是工程拼图中你负责的那一小块，还要思考它如何与整体关联。而且这种做法已经在实践中发生了，比如学生的毕业设计项目，我会鼓励他们走出去，实际上，我给他们的毕业项目创意种子就是 YC 的创业项目征集。

1:49:39 我几乎想说，去创办一家公司吧，你懂我的意思吧？就是，去做点有意思的东西。去年人们都做了些什么呢？各种各样的事情都有。比如有个人，来自电子工程系，学的是电子工程（EE）。他做了一个实际上相当于翻译器的东西，用来解析那种在 C 语言里带有内存地址的手册，然后把它转换成可以解释甚至可视化的代码。

1:50:05 所以是针对他们具体使用场景的东西。还有一个人原本是设计师，现在真的去了 Vercel。她做了类似拍摄我的设计笔记本，然后根据拍下的内容生成一个应用这样的功能。对，她的演示真的是，我说“来吧”，她随手拍了一张她随便涂鸦的草稿，然后就从中得到了一个完整成型的 Vercel 应用。

1:50:23 我想正因为如此，她可能因此得到了一份在 Vercel 的工作，做某种类似的事情。哇，不错。这其实是个很高的门槛了。Vercel 以他们的设计工程师而闻名。是的，是的。而且我记得她现在在做 Eve。啊，不，Eve 是你们的应用吗？

1:50:37 Eve 是一个开源项目，或者说是开源合作伙伴。我的意思是，与我们合作的卖点之一就是他们让学生用 Eve 来构建东西。是的。所以这就是元测试框架（meta-harnesses）的概念，对吧？

1:50:49 框架的框架。你总是可以再往深走一层。但我确实认为这是有道理的，至少对我而言，就像模型路由器封装模型 API 一样，你也需要封装测试框架。这说得通。我认为在某种程度上，学生们也应该保持脚踏实地。在边缘地带有很多事情正在发生。也有很多公司仍然在生产环境里玩着单次调用的 ChatGPT，甚至还没试过，你知道，有很多这样的情况。所以仍然有时间去探索什么能行得通。不过我认为你关于品味的观点很好——要有品味，多尝试，比如每家公司是否都有自己的软件工厂版本，或者你在构建工具来帮助公司做到这一点，

1:51:34 持续关注，真正去使用这些工具，动手把玩，你会在过程中摸索出来。是的，我百分之百同意这一切。首先，正如你所说，很多公司还停留在给 ChatGPT 输入提示词，或者某种 ChatGPT 的变体上？

1:51:49 也许他们刚买了 Cursor 的许可证，现在才刚开始让人上手。这比我们想象的要普遍得多，当然在硅谷这里也是如此。我可以百分之百肯定地说这一点。是的，我认为对于接触到这些的学生来说，从某种意义上说，他们了解这些并且站在前沿，这最终会让他们在进入那些在前沿方面可能还不到位的地方时，也能成为更有意思、更有价值的贡献者。这是一场这种渐进式演进主题的演讲，虽然已经有一年了仍然很有影响力，Yeggy 谈论他所说的“精神错乱级别”，现在他已经一路讲到了第 10 级。

1:52:27 那里提到他已经放弃并搬去农场了。不过是的，你想说说吧，抱歉，我是在调侃他。他建了 Gastown。对，我记得。对对对。所有这些事，搬到了 Gas City。现在他把城市烧了，说：我要做我的游戏，不再要 Gastown 了。我记得，我是说，我今年早些时候在工程师大会上跟他聊过，他当时的核心观点不就是，Gastown 里唯一有用的东西就是 Gastown 本身吗。

1:52:53 是啊。没错。那是一次惨烈的失败。惨烈。完全如此。完全。嗯，所以人们应该意识到，精神失控（psychosis）是真实存在的。如果你不对交付真实的产品负责，你只是在拿着 LLM 瞎折腾。对。这算是可能相关的话题，但我很好奇有多少，我是说，我稍微玩过一下 Gastown，系统非常复杂，可能有点超前于时代，但我也怀疑他们是否在营销上有些受限，因为从术语角度看，这东西很难让人理解。

1:53:24 就是里面有太多东西在同时进行。这对他自己来说说得通。我觉得 Gastown 的营销也是推动它的因素之一，对吧？

1:53:30 比如，在 Gastown 之前是什么？Beats。对，Beats。除非你说的是别人的东西。不不，当时有整个 open claw，还有别的东西，然后是 Gastown。而且那份宣言也确实帮它在概念层面火了起来。那些绝不会用 Gastown 的人，也因为可以去读宣言而了解了 Gastown。这里头有营销的角度。嗯，所以说，Steve 不一定要逐字当真，但大方向是对的，你懂吧？

1:54:04 所以我觉得他在这件事上大方向是对的。如果你还处在 IDE 阶段，那就该进入高级用户阶段了。如果你还是单智能体，那就该转向多智能体，诸如此类。而且你可能应该试着构建自己的编排器，对吧？

1:54:16 这就是全部内容了。可以说，这部分现在已经有点过时了。软件工厂的内容远不止这些。但这篇文章写于软件工厂之前。我确实会考虑这些事，作为一个雇主，我今天在我的公司里就遇到这个问题：我不想雇用任何没有经历过精神失控并走出来的人，因为我现在正在付钱让某个人经历这种状态，这非常昂贵——从他的工资来说很贵，从 token 消耗来说也很贵，而我什么都得不到，他自己也没意识到。

1:54:48 我的反馈传达不进去。所以我几乎可以说是会鼓励你的学生们去经历一次精神失控，然后走出来，问问自己：我之前到底哪里不对？因为这正是 Steve 刚刚以非常公开的方式经历的两年历程。是的，在学生这边很奇怪，行业里有太多情况是你自以为很高效，其实并没有。这大概就是学生版本吧——你在 Notion 里画图表，做各种个人优化，然后发现：天哪，我经历了这种失控，但什么都没改变。所以就去经历吧，去经历吧。对，这个我还没看过。

1:55:22 其实我见过 Boris 做过一个类似的版本。显然更偏向 Claude 的使用场景，但我记得他做了一个 Claude artifact，展示的我觉得更多是团队层面，他分了四个阶段而不是八个阶段，但大致遵循了同样的演进路径，从零采用一直到……对，四个阶段就很好。这个级别太多了。嗯，看看 Vivo 能不能把它拉上来。

1:55:44 除此之外，回顾一下，我们把所有话题都聊到了吗？就是这个。哦，是这个？好，来吧。这是一个 RFS。好的。所以是 gated、assisted、parallel。最后一个是什�么？

1:55:55 Supervised autonomy 和 AI native。所以是从零开始计的。那就是五个级别，对吧？好的。你是从零开始的？对。哇，这个其实相当不错。我需要更深入地读一遍。还有 AI native。对，对。我要为 dynamic workflows 点个赞。这是子智能体模式之一，OpenAI 那边也在探索，显然非常契合。基本上就是为你想做的事情按需编写一个 harness。

1:56:26 所以这可能是……很多子智能体的讨论其实只是复制父智能体，但实际上应该写更多代码，然后把它作为子智能体来运行。这就是 Anthropic 的人选择称之为 dynamic workflows 的东西。好的。你知道吗。嗯。我们也构建过一个这样的版本。嗯。这是个好模式。用在 Monaco 上？

1:56:49 它做什么的？嗯，就是即时生成那种面向 GTM 场景的 harness 用例。哦，那很棒。对。我要指出，当 Boris 写这个的时候，它是面向团队采用的，给正在收听的各位。而且他说，你看，Anthropic 处于第三阶段，我们还在努力达到第四阶段。哇。他就像在说“我已经在第四阶段了，我就是那个人”，但你知道，这不像 Steve 那样简单，Steve 是非常出色的个人执行者，做这个做这个做这个。如果你在管理一个团队，想给你的团队“AI 药丸”（全面 AI 化），而不只是做一个用户，你知道的，Anthropic 还在第三阶段。

1:57:28 别，别像那样，对。好的。我是说，你应该把这个教出去。这个很棒。这里面包含的东西就是我们聊过的所有内容。就是它了。真不敢我之前没发现这个。嗯，非常非常好。好的。这真是一场疯狂的旅程，一两个小时讲完斯坦福一学期的内容。谢谢你来做这个。有什么结束语吗？有什么行动号召吗？

1:57:49 没有，这真是……谢谢，我是说，非常开心。这个准备了九个月。我很兴奋。这是第一周的结束。有很多要做的，有很多要学的。我很期待看看会发生什么，尤其是 OSS 合作伙伴，以及让学生深入复杂代码库的代码，让他们构建一些东西。会很有趣。我会随时告诉你们进展。你明年还会再办一届吗？

1:58:10 如果 OSS 的朋友想参与，学生们需要积分（credits），他们可以联系你？当然。这些积分很重要。他们想要积分吗？他们真的想要那些积分吗？

1:58:20 学生们吗？你们确实有信用卡。我觉得没多少学生愿意花钱。我正在做一个 EIU 信用卡。嗯，不，我觉得……听着，我记得肯定有一个固定的学分额度，但在那之上，他说，你看，如果他们想放开手脚大干一场，告诉我一声，我们就搞一些一次性的实验，让他们可以扩展到 1000 个以上的智能体。

1:58:39 这是来自 Factory 的 Eno。对，Factory 的 Eno。对，对，对。不，那种人是很有价值的。所以这是来自 Cursor 的 Wilson，对吧？他说，我要写一个浏览器，对吧？

1:58:48 是的，没错。那些有雄心壮志并且能真正执行的人，是非常有价值的，这基本上就是一个招聘号召。没错。对，这说得好。对，但我确实认为学生应该明白如何有雄心壮志，

1:59:04 因为恕我直言，在当今时代，拍张照片然后做成一个应用并不算多有雄心。写一个浏览器才算，而且实际上还有很多类似的项目。对，我觉得说得对。对，关键在于抬高底线。我是说，我想，是的，去年……功劳要归功于去年的学生。但今年，显然我们会有更高的期望。现在那已经算不及格了。

1:59:24 我们会有更高的期望。我是说，是啊。但这正是重点所在，对吧？不断提升，对吧？去年就像是，嘿，你听说过提示词吗？

1:59:30 比如，它是什么。我花了一些时间讲像 K-shot 提示词之类的课程。而现在我觉得你们甚至都不会再去想那些了。我觉得有一种方式可以让你在同学中脱颖而出，还有一种情况是你也身处一群行业人士之中的早期工程岗位，很多人还在努力找工作。

1:59:51 而且不是说要点名某个演示，但你可以做很多事情来脱颖而出。我送学生一个第 11 周的免费建议：做基准测试，做基准测试和评测。这会让你拿到一个好成绩。它能让你进入每一个前沿实验室、每一个顶级智能体实验室的大门。写出有严谨性的、关于任何有趣内容的优秀工程博客。这方面有很多唾手可得的成果，而工程博客确实表现很好，对吧？

2:00:19 你在一件事情上钻研得很深。对，而且很可能，这里面还有很多钱可以赚。所以不只是进门的机会，如果你把它做成生意，你真的可以大赚一笔。对，人们不知道，C-Bench 就是一个本科项目。对，对，对，没错。是普林斯顿的，对吧？

2:00:37 是的，对，对，对。太好了。很棒。就到这里。非常感谢。谢谢大家。