> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 斯坦福 CS146S：作业是给开源项目提一个 PR
- URL: https://www.hubwiz.com/blog/stanford-cs146s-ai-native-engineering/
- Published: 2026-11-09T08:57:33.000Z
- Updated: 2026-11-09T08:59:18.000Z
- Description: 九次作业一晚上就能 one-shot，于是作业改成了给开源仓库提 PR：维护者来审你的补丁。十周课表，和一份完整实录。
- Author: admin
- Tags: AI 编程, Stanford, CS146S, 智能体, 软件工程

AI Engineer 的 YouTube 频道刚刚跨过一百万订阅。谢谢每一个看过一场演讲、把它转给同事、或者把学到的东西真正用到生产里的人。为了这期特别节目，我们想坐下来聊一个人：他必须在两处给出答案，而这个问题我们很多人上班时都在问——**现在的软件工程师到底该学什么？**

**Mihail Eric** 有两个地方可以检验他的答案。他在[斯坦福教 The Modern Software Developer](https://themodernsoftware.dev/?ref=hubwiz.com)，同时在 Monaco 带 AI 团队——他的同事用编码 agent 交付软件、排查线上故障。我请他带我们走一遍课表，然后告诉我们：哪些部分在他的工程团队里经受住了检验。

这期也算给下周来旧金山参加 [AIE Code](https://aie.codes/?ref=hubwiz.com) 的各位做个预习，把它当作你和演讲嘉宾、赞助商、其他参会者对话前的**必备知识**。如果你是 LS 订户还没买票，可以[用这个码打七折](https://app.ai.engineer/e/aie-code-summit?discount=LS30&ref=hubwiz.com)（抱歉，不退票）。

## 去年的作业，一句话就能做完

CS146S 第一次开课时有九次作业加一个结课项目。其中一次练习是让学生在一个仓库上跑 AI 代码评审工具，然后评估它的反馈质量。到下一轮，Mihail 觉得学生基本能 one-shot 掉其中大部分练习。当他问一屋子斯坦福大二大三学生“你们怎么写代码”时，他调研到的每一个人都已经在用 agent 了。

所以这一次，作业的一部分变成了给一个开源项目做贡献。仓库的维护者来评审学生的补丁。我喜欢这个改动对作业本身做了什么：你可以让 agent 用一个下午实现一个功能，但你仍然要搞清楚维护者到底要不要这个功能、这段代码为什么是这种行为、以及你的补丁还可能弄坏什么。而这场对话，也正是初级工程师向资深工程师学习的方式。

节目里有一个练习，你可以借来用在下一个 PR 上。Geoffrey Litt 的 explain-diff 技能会把一处改动变成可视化的走查，然后就它来考你。拿你 agent 刚写的补丁试一次：哪一个是你不重新打开代码就答不出来的问题？[看这段讨论](https://youtu.be/dpY7YzZo4kE?t=2295&ref=hubwiz.com)。

## Monaco 买什么，建什么

在 Monaco，团队评估过一批代码评审产品，最后留下来继续用的是 Devin。而 agent 工作区是反过来的：一个后台 agent 需要有地方去跑起产品、复现故障、测试补丁。这些细节取决于 Monaco 的云是怎么搭的，所以团队自己造了工作区。Mihail 的经验法则是：**“你买来学，自己建来留。”**

其中一个成果叫 Hal。工程师可以让它去调查某个坏掉的东西并开一个 PR；销售人员可以让同一套系统解释产品是怎么工作的。在一种情况下，有用的答案是别人可以评审的一处改动；在另一种情况下，是你可以讲给客户的一段解释。你给这两个人都塞一堵调试输出，就只服务了其中一个人。

我一直回到的问题是：PR 的另一端会发生什么。agent 看到的是当前的代码。它去哪里查“六个月前团队为什么拒掉了同一个改动”？这就从 [Basis 的 Authority Map](https://www.getbasis.ai/blogs/how-we-made-our-monorepo-ergonomic-for-agents?ref=hubwiz.com#canon-vs-not-canon) 一路引到 Mihail 的预测：开源仓库会变成 agent 运营的软件工厂。也正因为如此，今天就应该把一个学生送到维护者面前——总得有人决定哪个改动属于这个项目。

如果你在拿编码 agent 做东西，来 [AI Engineer CODE](https://aie.codes/?ref=hubwiz.com) 找我们。而如果你自己也在教这些东西，我很想知道你第一个不得不重写的作业是哪一个。

## 节目笔记

- [斯坦福 CS146S](https://themodernsoftware.dev/?ref=hubwiz.com) —— 十周课表、作业和开源合作方。你也可以切到上一年的课程做对比。
- [造一个编码 agent](https://www.mihaileric.com/The-Emperor-Has-No-Clothes/?ref=hubwiz.com) 和[看看 Claude Code 里面](https://www.mihaileric.com/Demystifying-Claude-Code/?ref=hubwiz.com) —— Mihail 对工具循环和它外围 harness 的拆解。
- [理解成了新的瓶颈](https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck.html?ref=hubwiz.com) —— Geoffrey Litt 的方法：怎么学明白一个 AI 写的 diff 里改了什么。
- [Monaco 的 agent 开发者工作区](https://www.monaco.com/blog/agent-developer-workspaces?ref=hubwiz.com) —— 团队为“让 agent 能跑起来、能测”造一块地方的理由。
- [如何杀死代码评审](https://latent.space/p/reviews-dead/?ref=hubwiz.com) 和[背后的 Faros 研究](https://www.faros.ai/blog/ai-software-engineering?ref=hubwiz.com) —— AI 采用率高的团队合并的 PR 多 98%，而 PR 评审时间长了 91%。
- [Basis 的 Authority Map](https://www.getbasis.ai/blogs/how-we-made-our-monorepo-ergonomic-for-agents?ref=hubwiz.com#canon-vs-not-canon) —— agent 应该去哪里找当前行为、早先的决定和意图。
- [Stripe 的 Minions](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents?ref=hubwiz.com) —— 给后台编码 agent 一个环境和一条通向“工程师评审过的 PR”的路，在生产里的例子。
- [Boris Cherny 的 AI 采纳五阶段](https://x.com/bcherny/status/2077929379661844559?ref=hubwiz.com) —— 节目接近尾声时我们放在屏幕上的那五步。
- [Mihail 在 The Thinking Mode](https://www.youtube.com/watch?v=wEsjK3Smovw&ref=hubwiz.com) —— EO Studio 的访谈，我们这期开头引用的就是它。

## 时间轴

0:00 · AI Engineer 一百万订阅与 CODE Summit 0:51 · Mihail Eric 与斯坦福 CS146S 5:26 · 初级工程师现在该学什么 10:02 · 开源维护者来审学生的代码 15:04 · 十周课表导览 24:04 · 编码 agent 内部的循环、工具与 harness 32:18 · 为大型代码库做上下文工程 38:15 · 让你读懂 diff 的技能 46:42 · Monaco.com 的域名之争与飞机横幅 50:23 · Monaco 为销售团队做什么 59:21 · Monaco 工程团队内部 1:01:40 · “你买来学，自己建来留” 1:05:24 · 让仓库对 agent 友好，以及合上 on-call 的闭环 1:12:37 · 当代码评审变成瓶颈 1:20:37 · 安全、依赖与权限 1:30:13 · 后台 agent 与 Stripe 的 Minions 1:34:16 · MCP 门户与基础设施为什么会收敛 1:41:22 · 造软件工厂 1:45:24 · 还剩什么工作给人做？ 1:52:16 · 从个人采纳到团队自主

## 实录

*自动生成的实录，已对齐最终成片。时间戳对应 YouTube 上的那一刻。*

**\[2:58\]** 我做了论证这门课应该存在的工作，得写提案之类的。那把我带到了 2025 年秋季，第一次开课，反响很好。学生们真的感兴趣。去年甚至还出了一篇关于这门课的《商业内幕》报道。然后今年，很多东西变了。我会说真正的 agent、自主编码 agent，真的以一种我们之前没见过的势头起来了。

**\[3:23\]** 所以感觉是时候再来一次、把东西刷新一遍了，然后就有了现在。与此同时，你还是 Monaco 的 AI 负责人，那也是一家很热的创业公司。是的。我们现在正处在风口浪尖上，玩得挺开心。我挺喜欢你同时也是个实践者这一点。你们显然在 Monaco 把这一切都落地了。就高层来看，从去年到今年，有什么原则或者观察上的变化？

**\[3:53\]** 有，很多。我想当回顾去年那版课时——我是说，编码 agent 那时候已经存在了，但我们还处在那种阶段：不断有公司在啃 AI 软件开发生命周期的每一个环节。有专门做代码评审的编码 agent，有做规格设计的，有做 SRE 的。当然，其中一些公司今天还在。

**\[4:16\]** 但去年感觉更像是一场广角巡游：这是你能用编码 agent 的所有地方。去年的课程很大程度上是为了“曝光”。就是这种游览式的、奥德赛式的课程：你以为你熟悉的整个 AI 软件开发生命周期，现在都因为 AI 在变。今年我觉得有一些原则在固化下来。

**\[4:38\]** 比如非常谨慎的上下文工程，比如把设计和架构真正想透，作为处理极复杂任务的方法。所以我这门课的性质是：它不是给编程初学者的。它也不是传统计算机科学的替代品——我说的传统是指算法那种。实际上那些课里的很多是这门课的先修。但我知道你底子不错，现在要往“把它用在真实世界的生产环境里”走，那是另一件事。

**\[4:59\]** 在 Monaco 我们要面对超大的代码库。我也帮很多公司思考他们超大代码库的设计之类的事。所以这更像一门实践者的课：学生毕业或者即将进入职场，怎么成为团队里最高产的那个成员。

**\[5:25\]** 你说你对教育很有热情。我觉得处在这个阶段的大学生，位置挺有意思的。有任何建议吗？现在人还该不该学计算机科学？

**\[5:40\]** Claude Code 和 Codex 是不是我们要的全部？我想听听你怎么想。学生当中有大量焦虑，你大概能想象。这次我试图传达的很大一部分是：这种焦虑，很多还在。去年也有焦虑。但我想论证的是，一个训练有素的 AI 原生工程师——我知道这是个流行词，但我们深入看看哪些方面最有意思——一个训练有素的原生工程师，可以是任何公司身边最有用的资产之一。

**\[6:17\]** 这其实是上课第一周。第一周第一节课我就说，我真相信每家公司都需要你，但门槛高多了。你是毕业后的第一份工作进来的，但如果用谷歌那套职级，只做到 L3 是不够的。走这条路，你基本上得比接近 senior 的人更好。

**\[6:39\]** 那怎么才能更快到那儿？我在试着说明：仍然有一块核心的基础软件工程是重要的。软件系统怎么搭、这些系统的取舍是什么。然后在那之上，我们才往下走。这也就是我认为作为人你仍然有价值的地方——剩下的实现细节你越来越可以交出去。

**\[7:02\]** 嗯。这是我之前说过的东西，它有点像那种“为了辣而说”的话，但我其实真的相信：大多数学生是“熟了”（cooked）。其中一些人会非常有价值。我不觉得这话受欢迎——“斯坦福的孩子没事，他们来自斯坦福”——但美国其余的人呢？那是个更大的问题。这是个奇怪的处境，因为我觉得教育动得很慢。我甚至好奇：一门课，你怎么确定课表的截止日期该放在哪儿？

**\[7:39\]** 你在教斯坦福的现代软件，它在改变一切。作弊就行了，你直接把编码 agent 的人请来讲，对吧？

**\[7:48\]** 哦对。让他们来当——哈哈，新老客座讲师。嗯，关于客座讲师这点，我觉得那也是去年就有的做法，是有意设计的。因为你看，我进来的时候，我像你说的那样，是个实践者。我每天在做这件事。

**\[8:09\]** 我设计这些系统。在 Monaco 造这些东西，见过很多次了。话虽如此，我不想声称我今天有全部答案，那样声称会很傲慢。所以这门课的结构一直是：这是一个实践者从现场、从和现场很多人交流中汇总出来的一组洞见。

**\[8:33\]** 但另外有一些人literally在前沿，看到的甚至更远，邀请他们把自己的提案、自己的世界观摆出来。这就是客座讲师存在的理由。我觉得对学生来说，亲眼看到大名字、看到真在做的人、能直接问他们，影响很大。当然，他们想实习、想找工作。有客座讲师是好事。

**\[8:56\]** 我想他说的是……好，我换个说法。我们也采访过 Ange，他教那个“Coachella 课”。那门课是“这是所有名字”，只有名字。而他实际上也在产出，比如“这是 200 行的 Claude Code”。对吧？

**\[9:15\]** 这话没人会告诉你去做。没人会来给你演讲讲这个。但当你想教原理、教一个你能用起来的框架和可用的理解时，这就是你会做的事。对，正是。而且我确实认为这类材料有个平衡：它没法 100% 固化。

**\[9:34\]** 按设计它既是特性也许也是缺陷，但课表很大一部分去年到今年确实变了。所以整个课程的开发带有动态性。但我至少在试图提出：有些东西我认为会留下来。而且是的，提示编码 agent 这件事，它们变聪明了。那意味着对待它们的新方式是什么？

**\[9:53\]** 但话又说回来，Boris 也知道一些我不知道的东西。所以也让他上桌分享他学到的东西。这次我注意到一件有意思的事：相当一部分内容是关于开源贡献的。这背后的想法是什么？

**\[10:11\]** 有，有。这说实话是我最自豪、最兴奋的事情之一。这差不多是上课第二周。是的，这些是非常慷慨的开源合作方，我花了这个夏天的大部分时间跟他们聊，

**\[10:28\]** 让他们对这件事兴奋起来、产生兴趣。基本上想法是这样：去年我教这门课的时候，

**\[10:34\]** 我们有九次作业，然后一个开放式的结课项目。那九次作业基本上是我编出来的教学练习。比如“这里有个仓库，用一个 AI 代码评审工具发一条评审，然后看：它为什么好？为什么不好？”相当教学化，说实话挺简单的。对很多人来说，他们可以 one-shot 掉。我就想，好吧，这帮助不大。到这个时候，agent 已经在身边了。我周二调研的每一个学生，没有一个人还在手打代码。全都在用编码 agent。而这还是斯坦福的大二大三学生。

**\[11:10\]** 你做调研吗？市场份额呢？他们用什么工具？我还没做，这是个好主意。你应该做。我会做的。“斯坦福偏好”会很辣。不不。我觉得大学——大多数厂商都有教育计划。

**\[11:27\]** 他们对学生的套餐非常慷慨。所以在开课之前，默认就有 Claude 的授权，我猜还有 Cursor 的授权，大概还有 Cognition 的。这你比我清楚。但我还能在此基础上加码的是：我不想让大家被每月 20 美元的订阅卡住。我想让你们去——如果你想 token 拉满看看能做到什么，那你就去。所以我会回到合作方的话题，但我通过沟通额外争取到的是给学生的额外额度。Factory 也参与进来了，Cognition 的人也参与进来了，OpenAI 也是。

**\[11:49\]** 但总之，关于开源合作方，我当时想的是：教学生的时候我最担心的一件事是——用 swyx 的话说，大家都在说他们“熟了”，那他们会怎么样？

**\[12:19\]** 几乎有一种被落在后面的感觉。而我认为导师制是把所有人拉齐、避免出现巨大鸿沟的一个非常重要的部分——鸿沟的一边是编码 agent 之前就在行业里、知道怎么回事的资深人士，他们采纳编码 agent 之后变得惊人地强；另一边是刚毕业的初级工程师，“好吧，那我们现在干什么？”

**\[12:39\]** 所以某种意义上，目标之一是：编码 agent 确实很好，我想把你们放到要面对复杂代码库、大规模代码库的场景里。我们要和一些在我看来最好的 AI 原生仓库合作——它们要么本身就是编码 agent，要么是在为 agent 造工具。

**\[13:00\]** 我想让你们参与到这些项目里。作业的一部分就是真的给这些项目做贡献。在参与这些项目的过程中，你会真的和维护者对话。他们会评审你的代码，会帮你建立对好软件的心智模型。这样，“什么才是真正好的软件设计”这件事就等于完成了交接——我觉得大多数学生没有机会得到这个。

**\[13:20\]** 当然还有好处：我确信其中一些人会因为作业做得好而被挖走。对。顺便说一句，我要是漏了这句会被骂：我觉得你说 cooked 对 cracked 是为了戏剧效果。就是，说极端一点好听。当然当然。那也许我们该进课表的细节了。

**\[13:46\]** 好。顶层上你还有别的想聊的吗？我觉得这很有帮助了。都在那儿了。好。我有一些高层问题，关于学生用工具、最佳实践。你支持吗？

**\[13:59\]** 比如一对一的导师。我猜学生也会用上。在我们直接进课程之前，这方面你有什么指引？就什么方面的。你说你对教育有热情，对吧？

**\[14:13\]** 是。还有一个污名是：老师、教授怎么用它？学生怎样才能最好地用这些工具，而不是把作业扔进去、one-shot 掉？如果有什么想法，你怎么还能学到东西？

**\[14:28\]** 有有。而且我觉得还是留了一些作业在里面的，那些不是要当世界上最难的东西，而是更偏概念——更概念化的东西。比如，技能（skill）是什么意思？

**\[14:39\]** 更偏一些工具和技能的具体操作，比如 agent 代码库、AGENTS.md 之类。所以有一部分就是：如果你没听过这些词，先把它们补上。但我觉得大部分学习——把工具真正拿去试的那部分——会发生在开源贡献里，以及最后的开放式项目里。

**\[15:00\]** 他们得自己去探索点有趣的东西。酷。那也许我们就一件件过，从一到十。然后再深入。先广度优先。

**\[15:16\]** 好。我们从编码 agent 的内部开始。对。你教人怎么写自己的 Claude Code 克隆。它不开源这一点很有帮助。

**\[15:23\]** 然后呢？第一周全是 harness 的内部，从零造一个编码 agent。第二周更多是：好，现在假设已经有这些东西，我们怎么开始思考规模化的上下文工程？超出 vanilla 提示之外。我觉得和它耦合的，是在做这件事的时候思考工具设计和 MCP。有段时间 MCP 挨了很多骂。

**\[15:46\]** 我一直看好 MCP，我到处都能看到它。这个阶段它已经是一个存在的标准，我觉得它会继续存在。所以谈这个、谈有效的工具设计，是第二周。第三周我会说更多是关于技能，以及“从简单的专用工具扩展到过程式的做法”意味着什么。那里我们会谈 skills。

**\[16:06\]** 然后这开始引到 agent 的自动化。第四周很多是关于定制 agent 的基础件。比如配置文件，像 AGENTS.md、CLAUDE.md，hooks，子 agent。现代 harness 里有很多机制，你可以按不同目的使用。我想把这些暴露给学生。Agent-ready 代码库，这大概是我最喜欢的话题之一。

**\[16:33\]** 这对要进工业界、要思考规模化的人尤其相关：本质上，一个“准备好被 agent 高效消费”的仓库意味着什么？

**\[16:45\]** 所以要大量思考：设计服务边界时的取舍，还有文档、可验证性这类东西。这是第五周。第六周，是 agent 化的代码评审。这里我觉得有意思的是，从第五周延伸出来——第五周是代码库、agent-ready 代码库——到第六周更多是：代码评审现在正在变成瓶颈。

**\[17:17\]** 这一点学生不一定见过，除非他们已经在行业里待过（有些是硕士生，待过）。但对今天大多数在用编码 agent 的人来说，我们都在经历代码评审上的新瓶颈。那怎么解开它、或者至少把瓶口放宽一点？

**\[17:27\]** 那里有哪些机制？所以是可验证性这类东西，以及怎么把它延伸到评审流程里。第七周，安全。显然我认为有个时点……这在去年的课里也有，我这次想强化。任何自主系统大量采取动作，我们今年看到很多，尤其很多被黑。不只是别的东西，还包括一些核心软件，从 Vercel 到各种网关、LLM 网关整个。

**\[17:48\]** 所以我想花点时间谈安全里出现了哪些新的攻击面，以及我们怎么缓解其中一些。第八周是后台 agent。这里我想开始触及的是：怎样在很多不同的产品、服务领域里跑 agent，不只是传统意义上的 IDE 里，还包括基于代码库和仓库里 CICD 触发的、基于事件触发的、SRE 风格的 bot。

**\[18:31\]** 你怎么搭这样一个系统。我觉得过去这一年，很多公司开始发他们的文章，比如 Ramp、Inspect；Spotify 有自己的一套；我想还有 Stripe 的 Minions。这些人都在写他们为了做这件事而在内部搭的基础设施的酷文章。我想触及这个，让人看到那是什么。对，这一周更多是关于你在一个团队里时会发生什么，以及团队级基础设施的核心部件。

**\[19:00\]** 所以从 LLM 网关到 MCP 门户——MCP 的规模化——再到怎么思考不断演变中的角色。这个可能偏软一点。现在那种 vanilla 的、不太细致的说法是“人人都是构建者”，但我想比这再深一点：到底什么东西在被吸收？

**\[19:22\]** 哪些角色实际上在演化、或者在新生、而从前不存在？学生应该怎么想一套“可防御的技能集”，而这在以前并不成立？

**\[19:31\]** 所以更多是团队动态层面的考量。然后这一切都在往“工厂”上叠，我觉得这是今天很多人最关心的事。一旦我们在造工厂，人类还存在吗？等等。

**\[19:46\]** 围绕人类参与，有意设置的新瓶颈是什么？比如意图，比如搭建可验证的系统。以及在极限情况下——也许 80%、90% 的代码完全由 agent 驱动——我们把什么填进去？就是这样。漂亮扎实的十周。

**\[20:12\]** 我想说的是，其中一些比另一些更成熟。我觉得人们需要知道，不是所有这些都是定论。

**\[20:18\]** 当然。但它涵盖的一切，我会为之背书：这些是人们都在谈、你应该知道的东西。我们知道开放问题，我们未必知道答案。完全正确。

**\[20:25\]** 你大概有你自己的版本。我好奇你觉得哪些还没那么可防御——不是“不可防御”，是还没那么板上钉钉。但即便是软件工厂，我们在说暗工厂吗？

**\[20:39\]** 我们在说这些半开灯的工厂吗？我觉得那里也有一个光谱。而且在最前沿的人，比如那些自己在造工厂、又卖服务的，他们说即便是他们，也只有三成左右是真正全 agent 驱动的。那么极限情况下意味着什么？

**\[21:00\]** 很难说。而且有人走了非常非常远的暗工厂，然后出来说“我错了，各位”。对。我们在 AIE 上覆盖过。要知道不是每个人——他们当时大概真的相信自己说的话，但他们有权改变主意，而且他们确实会改。连 Boris 最近都发帖说“我经常错”，而大家因为他造了 Claude Code，就把他的话当福音。我说不，他有时自己跟自己不一致，这没关系。这不是政治。我们还是科学家、是工程师。

**\[21:40\]** 我不声称自己是教条的，我只是想让人去实验。我觉得这也是一条原则。你前面问原则。就是实验。你必须准备好……而且我讲这些课、跟人聊这些时，他们常说：事情太多了，我怎么跟上？

**\[21:52\]** 有个很简单的办法：每天实验 10 分钟。就花 10 分钟做一件你以前没做过的事。如果那是你以前解决问题的方式，现在有个你想试的新工具、新框架，那就花 10 分钟——哪怕就用这个新东西把同一个问题再做一遍——这就能补上大部分差距。

**\[22:10\]** 我要点名一下：比如你讲代码评审那一周，你有 Cognition。我其实和 Silas 一起做过 Devin Review。对，挺好的。这些东西很难量化地评测，有个 ReviewBench，但没人用。但定性地看，Devin Review 相当不错。“我们用你们的。”

**\[22:30\]** 哦真的？对，Monaco 确实在用 Devin。Silas 去年来讲过，他非常聪明。但我当时想：在代码评审工具的提供方里，我们采样了很多，很多用例下我们确实收敛到了 Devin。Silas 现在据说是模型那边，然后是你想找的 Walden。

**\[22:51\]** 我和 Walden 也聊过。我也要点名 Factory，因为谈 agent readiness，他们一直在做这个。他们做 Signals 那套工具。你们用吗？

**\[23:02\]** 我们用自己的那套 agent readiness。Eno 也很棒，我认为他们上这趟车很早。我记得他在 AIE 的演讲里把它系统化了，是哪次我忘了，有一场。欧洲那场，对，欧洲，那场演讲非常棒，我觉得超前于时代。所以我想，谈这个最合适的人我只看到一个，我很想把聚光灯打给他，非常兴奋。

**\[23:27\]** 挺有意思，我当时在 Cog，我们聊这些，说我们需要形成一些观点。然后 Factory 就在我们聊的那周把一个完整产品发出来了。我说好吧，你赢了。大家其实都同意同一件事，问题只是你要不要把它做成一个仪表盘。因为那就是个仪表盘。对，对。但它有价值。我觉得他们从营销角度做得很好，抢着发了那些写作和报告。我也一直在向别人推荐，说你应该给自己做类似那种写作与报告。

**\[23:45\]** 当然开源版本也有，但我觉得那些原则非常重要。

**\[24:04\]** 好。你想一块一块过，还是有别的？我可以一块一块过。好。那就第一个。

**\[24:11\]** 你聚焦 Claude Code，但你也把 Pi 作为开源赞助方。怎么回事？这个可能有点营销味，但好吧。我唯一想强调的，去年我也说清楚了：我不为任何工具背书，好？

**\[24:26\]** 我觉得那不是对待这类事情的正确方式。工具来来去去。坦白说，去年开课时 Claude Code 没那么流行，没那么被接受。Boris 当时只有 4,000 个 Twitter 粉丝，现在大概是几百万，我也不知道。Claude Code 确实横空出世了。

**\[24:49\]** 我认为……我们在播客上请 Boris 和 Kat 的时候，也低估了 Claude Code。那时它才两个月大。我没怎么用过，一次查询花了我 50 美分，我当时想：谁会他妈用这个。

**\[25:00\]** 完全同意。它 beta 了一段时间。但我觉得他们值得称赞——他们在模型还没准备好的时候就先把东西造出来了。你总听到“照着模型将要去的地方去建”。非常有野心。当时模型没那么好，你感觉不到。然后我们看到了。

**\[25:13\]** 挺有意思，因为去年他来讲的时候，我记得那套片子层级很高，但有一页幻灯片literally是照着“模型六个月后会在哪”做的。

**\[25:23\]** 而那是去年 10 月。如果他知道六个月后 Opus 会在哪，我能理解他为什么那么讲，因为我认为那也是一个巨大的解锁，我甚至会说那是课表变化这么大的原因之一。

**\[25:37\]** 当然，围绕这些 agent 的真正自主——长时间运行的 agent 任务——有一场巨大的军备竞赛。但回到你的点：我并不背书 Claude Code。我当然在用 Claude Code，也用别的东西。这里更多是：一个现代编码 harness 长什么样？

**\[25:54\]** 我写过一篇博客，今年早些时候，拆解了类似的一组原则。TL;DR 是：你用差不多入门算法课的水平，就能找到那个完成了“所谓编码 agent”大部分的 agent 循环。当然还有很多花活——子 agent、MCP 等等都没有。但如果你想要一个能对话、然后真的会改你文件、还能做出挺复杂事情的东西，200 行以内就够。所以我在教育里想做的很多事，是把“秘方”那层剥掉，让你看到核心——毕竟他们还是学生，你想教概念性的原则。

**\[26:37\]** 这里面没有比——斯坦福有门课叫 106B，就是入门算法——更多的东西。造这样一个东西，你不需要超过 106B。所以就是这样。

**\[26:45\]** 那儿就是了。既然你已经教过这门课，反弹呢？问题呢？你从学生身上观察到的怪事？

**\[26:54\]** 他们哪里不懂？他们的问题似乎聚集在哪儿？你是说这个概念，还是一般？

**\[27:02\]** 这个概念。从零造，然后做你做过的事。因为这基本就是 Pi 需要的东西。对，正是。所以我觉得——这个想法我完全没收到反弹。我觉得他们其实更多是消费者。

**\[27:21\]** 大多数学生最后就是使用这些工具。我认为他们没多少机会——在这门课里肯定没有——把洋葱剥开看。所以这是 harness 那一周。周二第一节课，讲后勤什么的。但然后前半是，第一块真正的课程内容是那 200 行的 harness。然后昨天，做它的后续，我们真的拿了 Claude Code，然后用那些代理工具——你需要类似代理的东西去拦截请求。

**\[27:53\]** MIT 和 proxy？对，正是。用那个工具拦截请求和响应。看进引擎盖下面，看看发生了什么。然后就像——我说过你有 200 行的 Claude Code，但好吧，这是真正的 Claude Code。所以我literally 拿了 Opus 5.5——这个模型才出来两天——然后我拦截了那些请求。

**\[28:13\]** 这里正是发生了什么。这是提示词。这是系统提示词。这是规划用的提示词。这是压缩用的提示词。然后我们就把这些都过了一遍，展示给学生看。所以他们现在真的拥有一个他们能理解的最先进 harness。对。三层都给到很好：学生大部分是消费者——这是循环里的基线 agent，这才是真的那个。

**\[28:32\]** 我挺喜欢你博客文章还配了视频走查。你会不会看到学生处在两端：有些人是重度用户，消费很多；对另一些人，你可以假设只要你懂 agent 怎么运作，这些就非常直接。在课堂环境里你怎么平衡？

**\[28:53\]** 你会往平均水平去裁吗？我觉得它有点自我筛选，因为课表全都在那儿。课表公开已经——至少几周了，我大概几周前宣布的，但它其实已经筹备了至少一到两个月。所以如果你去找，你大概能找到。

**\[29:12\]** 而且我觉得现实是：如果学生不感兴趣，他们就不会来，他们会选择不来。我觉得有意思的是，确实有学生来，但也有很多斯坦福更大范围的人，别的系的博士后。有很多跨学科的兴趣：有人在病理学、医学领域，甚至一些不是纯 CS 的工程领域，也来并且对接触这个感兴趣。

**\[29:41\]** 还有很多 GSB（商学院）的学生、MBA，他们想学怎么不用找个技术联合创始人之类，动机各不同。但顺便说，如果有人还没做过那个中间人代理的练习，你应该做一次。你会震惊。Claude Code 的系统提示词是所有编码 agent 里最长的，大概 20,000 token。对，是这样。

**\[30:07\]** 是这样。虽然他们也缩减过规模，砍掉了 80%。对，我知道。但然后它们又长回来。然后再砍再长。像跷跷板。对。我觉得有意思的是，你会惊讶里面装了什么——有时是你根本用不到的东西，有时它确实暗示了某些工具的内部运作。里面有什么你觉得可以聊的？

**\[30:28\]** 有。事实上昨天我讲到这个时——我觉得当年 Claude Code 最有趣的一点，也是它为什么在人气上真正爆掉的部分原因，是他们专注在简单上。

**\[30:41\]** 早期他们是真正押注“让更少的工具做更多事”的第一批人。押注 SQL，押注 Bash，押注那些强大的东西，像瑞士军刀一样的工具，让它们成为能力的主要驱动器。我觉得他们这件事做得极好，我觉得那也是他们为什么这么受欢迎。我展示系统提示词的时候会顺带说：两个月前是另一份系统提示词。

**\[31:05\]** 现在他们降低了复杂度，结果就是，原先属于系统提示词的东西——比如怎么用 Git，

**\[31:13\]** 或者怎么设置任务之类——现在已经不在系统提示词里了。实际上它被期望更多由模型本身承载，比如模型权重里。所以他们把很多这类学习内容烘进了模型层。这就提出了模型与 harness 之间那个有趣的问题。

**\[31:26\]** 你怎么想这个取舍？公司该把钱投在哪？你自己该投在哪，才能真正推动能力的前沿？

**\[31:34\]** 所以我觉得，即使作为一个社区，我们也在两者之间来回摆。我觉得不该因为他们把系统提示词养大又砍掉而苛责他们。某种意义上，那也和模型有关。

**\[31:47\]** 更弱、更老的模型，你需要给它例子：这是好的，这是坏的。然后到某个时刻你显然要把这些砍掉。

**\[31:54\]** 而这只是学习“已经做到了什么”的一部分。同样适用于：如果你用一个本地编码 agent，模型不是最强的那种，你可能需要加这些例子。

**\[32:05\]** 对。然后当然，从中能引出有意思的 AI 学习结论：随着模型变好，你什么时候是在用这些例子过度约束它？

**\[32:16\]** 然后你怎么把过度约束撤掉？我觉得那也是学习的一部分。好。第二周你要谈上下文工程。Replit 我没看过，但“开发之魂”有很多版本。你会向更广的听众强调什么——你在这里放的东西里，哪些是大家该知道的？

**\[32:35\]** 这就是这门课的一小时版。对，正是。请把所有东西压缩一下。我觉得方向就是这个。说得对。不过它也是预告片，对吧？

**\[32:47\]** 就是：想要更多，去源头。如果你明年或明年秋季要上这门课，这就是你的一小时。这就像——像这门课的 Quibi。你懂我意思吧。

**\[32:56\]** 当预告片太长，当正课又太短。我猜这大概就是人们会双击进去看的东西。如果它是预告片，那你下次教的时候它又会变。对，对，对。是啊。所以没关系。这一点你说得对。挺有意思。我最想在这里强化的主要一点是——我面试人的时候也看到——**行业里很少有人走得比 vanilla 提示更远**。

**\[33:21\]** 基本就是那种：嘿，给我把事儿办了。就是“办事”。随着模型变好，那确实能把你送一段距离。但不可避免，我聊过的、从谷歌之类超大型代码库出来的人，现实是你必须在“怎么摄入上下文”上想得多得多。所以想一想那些原则和技巧：怎么去指……

**\[33:46\]** 我在这里描述的这套快速框架，功能上类似 Dex 的 RPI 之类：你先研究、给出提案、差不多是个规格，然后做实现，再用测试之类把它缝起来。所以我这里想强调的是：当你进入陌生代码库、想把 agent 需要理解的某个东西注入上下文时，一个“研究阶段”是有价值的。

**\[34:16\]** 而在我提出的这个具体框架里，研究做完之后还建议给出几个提案——解决同一个问题的几种不同路子。这里我也就是把人类请回环里，让他做那个“选 A 还是选 B”的决定。然后你进入计划，也就是那个规格。

**\[34:35\]** 总之 TL;DR 是：确实有一种做法能真正扩展到你几百万行的代码库。而不只是 vanilla 提示。这是我想强调的。如果你要去碰这些大代码库，你该用更讲究一点的东西。关于上下文工程还有什么要补的？

**\[34:54\]** 我现在想上下文这件事最怪的地方，是当你拆到子 agent 的时候——因为子 agent 能不能从你主线上下文的全量继承中获益，有时是有分歧的。然后有时你又想把子 agent 做的东西压缩、再塞回主线。它非常 hacky。我不喜欢我做的任何一件事。

**\[35:24\]** 所以我没答案。我只知道，当你想把工作扇出（fan out）时，这不只是“你有一份大规格、你 RPI、你 Repit”那套。它已经不是一个 agent 了。它关乎把工作扇出去，并确保它们都有正确的上下文、都有正确的指引。如果你有一个评审 agent 要评所有人的活，你得让那家伙拥有一切。

**\[35:48\]** 而你总会经历这个“扩展契约”的阶段：天啊，这些人上下文不够，我要给他们更多上下文。好，很好。然后他们就会抓着你很久以前随口说的一句一次性评论，犯下真的很蠢的错误，因为你当时不是那个意思。但他们把它当成了法律。类似这样。所以我不知道我在说什么词。

**\[36:09\]** 就像是多 agent 的上下文管理。对，对。我完全同意。这里有一部分可能是最偏艺术而非科学的地方。

**\[36:21\]** 我觉得是某种组合，就像你说的：为探索扇出、为子任务扇出，然后是压缩，随你怎么叫。我觉得是对上下文刷新的考量，理解什么时候东西开始变臃肿了。Dex 有这个“笨区”（dumb zone）的概念，就是在笨区这件事上更用心一点。

**\[36:39\]** 他很擅长这些类比。对，那些小图。对。你为什么不请他？我觉得他确实给这门课提供了很多输入，他在这些事情上是个极好的思考者。不，我觉得那些图很重要，很有用。我会给想深入的人加些面包屑。看到好的上下文工程偏好很有用，比如子 agent 的继承。

**\[37:02\]** Claude 的托管 agent 有个版本是会话分离的、不继承。这在推理模型之前是个大话题——那时 agent 跑得没那么久，上下文窗口更短，所有人都在非常非常小心地管理那个宝贵的上下文窗口。很多人以前写了很多关于这个的博客。好的上下文工程这些，对大家了解都有好处。我觉得在学生语境里也一样：你可以预期一个普通学生上你的课，是因为课好，他们会知道这些东西。所以你该比他们知道得更好。

**\[37:35\]** 这也是个好玩的研究空间。AIE 上有一篇论文，看的是 Claude Code 系统提示词的 delta——改了什么。他们把一堆性能变化画了出来，试着逆向工程它。这就是你可以做的很好的研究。还有另一篇看上下文窗口管理以及它如何影响下游性能。

**\[38:03\]** 它们不是最好的论文，但相当平易近人，也产出了好博客。所以想在这上面动手的人，我推荐。这是个很容易戳进去的好领域。对，说得好。

**\[38:16\]** Agent 技能、CLI。对。我觉得这些算是从单一的函数式工具调用——比如 MCP 与第三方外部服务交互——往“过程”延伸。你怎么把一组动作反复自动化，然后把它形式化成一份 SKILL.md 之类的东西？

**\[38:38\]** 我觉得就是让它更……给人练习去把那些过程编码下来。我也会在这里放几个我觉得好用的好玩技能。我觉得 Matt Pocock 的 grill me 是个好例子。还有一些我从教育角度更喜欢的，比如 Geoffrey Litt 的 explain diff——一旦你开始谈代码评审，它就变得特别有意思。

**\[39:02\]** 因为整个……理解代码。理解代码，正是。你必须要理解代码。我不知道你们用过没有，但效果是：你把 diff 放进代码，跑那个技能，最后你不仅有一份可视化的呈现——你可以扫一眼就知道核心发生了什么——

**\[39:22\]** 而且我最喜欢的是最后那个像小测验的环节，它会考你，真正强化你是否理解了发生的事。我觉得那种交互式来回相当不错。对，这个领域有几篇我很喜欢拿出来讲的博客。最近有一篇大概是说：没有任何一种情形下，把脑子关掉是个好主意。

**\[39:45\]** 而我觉得这些技能实际上逼你把脑子打开。当所有人都想用编码 agent 时，你就把脑子关了。他们就像：给我做个 app，读我的心，不用我告诉你任何事就全部做对。正是。但这些技能很多都属于这个类型：不，不，请多问我几个问题。我觉得产出比人们习惯的多得多。

**\[40:07\]** 我可以敲一行提示就拿到几万行代码和一整套结构。你看我的生产力，各位。但更有效地，你该知道自己在做什么。不然你真的会被踢出局、脱出环路。你该花更多时间想你实际在做什么。真正做工作、把代码写出来，比过去容易太多了。

**\[40:33\]** 对，理解这件事完全没借口。抱歉，什么是 web 技能？就是那些与 web 本身交互的技能。计算机操作。计算机操作，对，这类东西。还有别的吗？

**\[40:45\]** 主要就是涉及从网上抓信息的东西。与 web 交互的技能有最佳实践吗，相对于……

**\[40:53\]** 我觉得这更多是一种survey，或者是我找到的、觉得有意思的东西的演示。它会不会是来自 Vercel？

**\[41:02\]** 我现在记不清了。我得回头翻完整的阅读材料，但我找到一个站点——我觉得可能是 BrowserBase，真的。他们可能做过。你记得吗？

**\[41:12\]** 嗯，那应该是他们造的这个说法。我当时就想，我是不是漏了什么？这在技能社区里是很大一块。“他很懂。他正在被教育。”对，我觉得他们做了某种——因为，毕竟 BrowserBase，他们喜欢浏览器。对，他们喜欢浏览器。但他们有一个很好的站点，把其中一些有意思的能力做成了服务。看起来靠谱。

**\[41:34\]** CLI 这个挺好玩。你有很多学生是第一次进终端、用 CLI 吗，还是这已经是常态了？

**\[41:41\]** 我不这么认为。考虑到他们大多数——去年我会说，有些人大概还记得手指敲键的日子。

**\[41:54\]** 但大多数学生到现在应该都和 Claude Code 打过交道了。我好奇现在只用手打 App 的人占多少。

**\[42:02\]** Claude Code 也有桌面 App，Codex 也有。Codex 现在主要就是一个 App。你不在 CLI 里、不在终端里。这件事会让很多普通人退缩，随口一提。对，我还想说，技能还有另一种：技能的集合，它们互相交叉引用。就像插件。

**\[42:26\]** 像插件。然后我觉得，还有“写技能的技艺”，这也是我为 AIE 关注的一件事。我觉得很多内容聚焦在技能消费上。你有那些网红比如 Matt Pocock 之类，他们说：这个技能会拯救你，它会解决你所有问题。但不，你该自己写技能。而且实际上，当你天真地试着写它们时，它们通常很糟。

**\[42:51\]** 写一个技能其实需要一点技能。完全正确。完全正确。swyx 关于写技能的最佳建议是什么？

**\[42:58\]** 我有一个公开的技能仓库。我肯定经历过一个“把一切技能化”的躁狂阶段。不不不。别给我们技能。你怎么写出好技能？

**\[43:06\]** 正是。所以我有一个“砍技能”的技能。每个 Claude Code 和 Codex 都有技能创建技能，对吧？所以我有一个 skill cutter 技能，把它砍短，因为它会把那些默认创建的技能糟糕的每一种方式都记录下来。所以任何技能创建之后你都要跑一下这个把它砍掉。很好。对吧。

**\[43:30\]** 我听起来像这样。对。真的很烦人，因为有时确实有 slop，但 slop 里有好东西，然后你得把里面的东西一点点削出来。对。哦有意思，如你所说，即便是 slop，它仍然是 agent 的语言。所以 slop 是有意义的。对，好吧，懂了。挺好玩。每个人都有自己的版本。我第一件事是——技能很容易 vibe check，对吧。

**\[43:54\]** 你就调用它、跑几次。对。然后我把这些偏好蒸馏进一个技能：这是我喜欢的，这是他不喜欢的。它会随时间调整。然后它可以自动化。所以问题是……对，你确实在调用它，但最糟的部分是技能在你没预期的时候触发。你写它是为了修那个东西，然后现在你在做完全另一个项目，它触发了。

**\[44:18\]** 为什么？因为它写得太糙了，因为触发条件说：每当 blah blah blah 发生时调用我。你说好吧，读起来还行。然后你做另一个项目，它触发了，你说：操。对，到底该怎么办？

**\[44:29\]** 有些人就是：好吧我有一堆技能，一直在加，偶尔跑一下这个。我认识一些人，比如 Eugene Yan，他们对有多少技能相当讲究。他们会修剪。没用的，每几周清一次。对。所以，如果你在那个技能世界里，这是个巨大的问题。我怀疑这正是为什么 OpenAI 和 Anthropic 有些非常聪明的人想让技能消失。

**\[45:00\]** 这话不受欢迎。他们不会公开这么说，但就是感觉邋遢。这感觉很邋遢。我看我自己那些技能的人也很邋遢。它不像是 AI-pilled。你懂我意思吗？

**\[45:14\]** 对。那不是 AGI 该有的样子。不是每个人都有一大堆 markdown 文件。我觉得其中一部分是……某种意义上有个“园艺问题”。很多人其实根本不看自己的 Markdown 文件，对吧？

**\[45:28\]** 它的 UX——就在聊天里说你要什么、在聊天里创建一个技能、用它、看输出。你可以完全不去看 Markdown 就获得很多价值。某种程度上别给自己overcomplicate。你可以拿到很多价值。如果你反复做某些事，你就说：看我们过去五次怎么做的，给我做个技能。然后你可以用聊天迭代它。

**\[45:53\]** 也有好的一面，对吧。还有另一种看法：技能就是 agent 需要做代码评审之类时运行的过程。但在 Devin 那样的场景里，我们把技能编码成表达最佳实践的方式，再把它暴露给 agent 或评审系统，让它按我们喜欢的方式实现 API、按我们定义的方式实现服务边界。

**\[46:22\]** 那是另一种表达组织级知识的方式，也许不太像“你希望 agent 干的这件任意的事，这样你不用每次写提示词”。所以我喜欢这个。我觉得这个定位、这个目的，可能比那些随机的过程活得更久。

**\[46:42\]** 我刚谷歌了“Monaco AI skills”，它给我的是那个国家。

**\[46:48\]** 有一天，有一天。我们在 AEO 上会赢过他们的，肯定的。你能直接买下那个国家吗？事情是这样的——不，我们不会买下那个国家，但我们确实因为买下 [monaco.com](https://monaco.com/?ref=hubwiz.com) 这个域名而挨了点骂。我要说，我们确实被他们告了。什么？对，有一整个公开事件。他们不喜欢那件事，但我们在这儿，而且我们赢了。

**\[47:17\]** 我们赢了。好，那这段保留。我正想说这有点辣，但你赢了。对对对。这就是我们看到那些旗子到处飞的原因吗？

**\[47:27\]** 因为它是一场胜利。因为它是我们的胜利。挺好玩的。在旧金山的人，抬头看就知道了。对，给听音频的人说一下：我们在 YouTube 上展示的是，你弄了一架飞机绕圈飞。我觉得你仍然是少数真的经常做这件事的人之一。Sam Blond 想出来的，一天 6,000 美元。我并不觉得它直接导致我去谷歌 Monaco 是什么，但 Monaco 所有的广告都是“Monaco $”。

**\[47:58\]** 对。我们代表钱。以美元符号开头，然后是 X 数字。它开启了对话。整个广告的点就是：Monaco 到底是什么鬼？

**\[48:07\]** 对。这值得讨论，但某种意义上，如果营销不是为了吸引注意力，那是为了什么？而且是的，也许还有一层：我去活动，人们会说“哦你们就是弄飞机的那些”“你们就是广告牌上写着那个大数字的”——1.93 亿还是多少——“但你们到底做什么？”也许那恰恰就是全部要点：我只需要有人来把它当破冰句。我要说，就像你进来时我说的那样：啊那些飞机。然后呢，你们做什么？

**\[48:42\]** 好吧，让我给你讲讲我们做什么。作为一个参与过那些“Devin 广告牌上写什么”决策的会议的人，我们在文案上花了太多时间。也许我们就该写“Devin”。我觉得你干得出来。那太他妈蠢了。但好吧。你知道，Sam 上周还有一篇帖子，他就是那种——Sam 基本上是我们这里的营销军师。

**\[49:07\]** 对，我觉得那些飞机背后也有一点历史。但 TL;DR 是，他的整套风格就是：我没有全部答案，你只能去试。我觉得这里面很多就是：我们就试试。如果扎得住，很好。如果说我们能预知它会爆成这样吗？说实话不能。但既然它爆了，那就是个点子。对，正是。而且从最小开始、往上走，而不是从大开始、往下缩。从小的做大的容易得多。对，正是。还有，一天 6K。它非常就是“试一试”。我觉得人们……比广告牌便宜。肯定比广告牌便宜。对。而且好玩，没什么伤害。

**\[49:50\]** 但这里值得一提的那种简单是：当我们想“压过飞机一头”时，我们就说——你知道什么比一架飞机更好吗？两架飞机。两架？什么？我的路是火箭。好吧，我也有那个想法。我希望某个时候那也能发生。但再看吧。这是下一次 SpaceX 发射。我们就看到 Monaco。对，就是这样。为了和星星合影。就是这样。得跟我们 SpaceX 的朋友们搞好关系。我很乐意。你不想？

**\[50:15\]** 我们在 Monaco 上。值不值得聊一下 Monaco？还是留到最后？对，对，因为话题之间像个中场休息。你决定。好。我们提了 Monaco 了，对吧？

**\[50:26\]** 我觉得提了“Monaco 到底是什么鬼”然后不回答，有点烦人。当然。你能回答吗？

**\[50:33\]** 我希望可以。对。所以这是那个国家。它是个小小的，我猜。就是这个。这就是我认识和热爱的 Monaco。我们是 B 轮公司，在旧金山的 Basin。我们在做一个某种意义上的一体化销售平台。全 AI 原生的 agent 去做那些好玩的事——或者至少是人类不喜欢做、但 agent 喜欢做的事，因为它们其实没什么意见，而且能做得没那么容易出错——这样销售人员和销售团队就能专注于人类擅长的事：成交。

**\[51:12\]** 所以想必 Marc Benioff 不喜欢你们。大概不喜欢。但说实话他也是个非常 AI 原生的人，在 Agentforce 之类上非常激进。你们在做什么是他不做、或者他做不到的？

**\[51:26\]** 好吧，我们现在——我们创办公司时的市场定位不是一上来就做企业级，对吧？

**\[51:35\]** 我们大概是这样说的：如果我们的目标是做一体化，那我们就需要和一组客户迭代着把它建起来，和他们一起长成这个东西。把一个人从 Salesforce 抢走，比“在你还在用 Google 表格管销售管道的时候就接住你、给你一个更 AI 的答案、然后跟你一起长大”要难得多。

**\[51:59\]** 某种意义上它很像 Brex 或者很多 YC 公司的模式：你先卖给同期的伙伴，和他们一起长大，然后往上打。所以我可以说，在专注创业公司的销售平台里，我们是最好的之一——如果不是最好的。所以我们所有客户都是早期创业公司，到现在主要集中在 A 轮前后：种子轮到 A 轮。

**\[52:24\]** 而现在我们在往上走。过去一年半做这件事，我们对“一体化”学了很多。你是 AI 负责人？

**\[52:32\]** 对。你们做的一些酷 AI 东西是什么？我们为销售用例造了自己的 agent harness。回到刚才说的编码 harness——我们从 Codex、Claude 那一类系统里吸收了很多灵感，然后造了很销售的专用工具和专用工作流，都面向 GTM 用例。

**\[52:55\]** 我们造了自己的那一版，基本上驱动了 Monaco 平台上几乎所有东西。从 TAM 打分、ICP 打分和 ICP 定义，到销售管道演进，再到所有销售人员不想干的琐事——比如更新我的会议、会前笔记、更新摘要，所有这些。我们有 agent 驱动这些工作流。

**\[53:22\]** 所以我们做了这个，开箱即用。既有长程 agent，也有短程 agent，面向 GTM 用例。而且相当领域特定，建在基础模型之上。你们会自己做模型吗？

**\[53:42\]** 这个问题值得提，因为到目前为止——我觉得很多垂直 AI 公司都这样——你先用前沿模型当第三方服务，看看能做什么，因为它们就在最前沿。然后我觉得我们过去一周也看到了这一点，就是那个“加 50% 到减 50% 毛利”之类的问题。

**\[54:03\]** 我是说，不管那些数字，我觉得有意思的是：到某个时点，从成本角度就变得有意思了。你开始想：能不能在开放权重模型上做得更快？

**\[54:14\]** 然后那里面很大一块——我觉得 AI 那部分的目的很多就是为这些模型做后训练、用 RL 之类搭环境。所以我们现在就在那个阶段。哦，好玩。对，我一直把这套打法叫 Agent Lab 打法：agent 先从用户出发，然后用你需要的任何模型去造产品。

**\[54:38\]** 但一旦你有了用户群，你就可以回填模型那一侧。而模型实验室走的是反方向：它们从大规模预训练开始，然后去找用户。希望它能分成两条道。Monaco 会在收入／GTM 那一侧。对。我觉得有意思的是，它们会想服务你，同时又想作为模型实验室跟你竞争。

**\[55:04\]** 正是。我涉及的这些东西里，我觉得难题之一是数据丰富化（enrichment）。

**\[55:14\]** 我会说我大量时间花在为 SEO、调研之类做这件事上。我猜对你来说它其实是核心的一部分。对。你觉得模型擅长这个吗？

**\[55:29\]** 有没有你喜欢的、想点名的合作方？绝对有。我们是 Parallel 的采用者，我觉得他们非常强。就通用搜索。对。不是 ZoomInfo 那种？不不不。但我们用 Parallel，也用 Exa，两家都点名一下。你能比较一下吗？

**\[55:50\]** 两家都是朋友。两家都是我们喜欢一起玩的。你如果喜欢其中一个另一个你也会很感兴趣。抛硬币吧。我保持中立。我今天当瑞士。对，当然我们也做自己版本的丰富化。我们大部分数据系统——可以说是我们造的最有价值的软件之一——就是我们的世界数据库。

**\[56:13\]** 公司库、丰富过的公司、丰富过的客户账号、丰富过的联系人。这样当我们为客户构造 ICP 时，我们拥有关于“此时此刻你应该联系哪家公司的谁”最新的信息。我会说我们真正世界级、毫无争议的地方是需求：我们是一家非常好的做需求的公司。我们帮公司以一种真的有效的方式提升约到的会议数。

**\[56:36\]** 所以是在对的时间找到买家？在正确的时间找到买家，对。它差不多是这两块的组合。“在正确的时间”是什么意思？

**\[56:41\]** 有些时间点——举个例子：如果你要卖给销售副总裁。联系他们的正确时机不是他们在同一个地方待了五年的时候。如果他们正在换工作，一个很好的信号是他们从一份工作到了一个新工作：他们刚进入一个新地方，更可能采购、或者更愿意考虑一个新的销售平台，因为他们正处于职业转换中。

**\[57:11\]** 所以对销售副总裁来说，从 A 公司到 B 公司，一个“该不该此刻联系他们”的好信号，就是你有没有检测到他们的 LinkedIn 变了之类。

**\[57:19\]** 这里面有多少是你们把专业经验灌进模型和 harness，有多少是模型本来就好、存在通用最佳实践？显然两者都有价值。是不是就是把胶水做可靠、在一个平台上全做、做好？

**\[57:36\]** 看起来还有一些我们不知道、但你们是领域专家、已经烘进去的东西。对，我觉得没有前者，它就会完全商品化。不能说完美商品化，因为一体化本身仍有很大价值——那是我们肯定首创的。销售领域大多数公司一开始都是点状解决方案，我觉得它们更多走 YC 那种 land and expand 的路子。

**\[57:59\]** 先选个利基，然后往外扩。而我们从一开始——这也是我们隐身了差不多一年多的原因——就是在建，因为我们一开始就知道要做一体化。但光有一体化就很强、很有意义。而真正的力量是：今天的 Monaco 拥有一支世界级的 GTM 团队。

**\[58:16\]** 真的是世界级的 GTM 团队，当然是卖 Monaco。但同一批卖 Monaco 的 GTM 人员，也是我们称之为前方部署客户经理（FDAE）的人。他们实际上是充当顾问的人类销售，帮我们所有客户上线、让他们把 agent 工作流建起来，并在他们自己的销售 GTM 生命周期里全程引导他们。

**\[58:39\]** 所以回答你的问题：是一体化，但也是一体化加上这些人——Sam 和我们招来的很多前 Sam 团队成员之类，他们是 Brex 等地方最好的 GTM 人。我们在把这一切编码进平台。挺有意思，你讲话的方式和我平时聊的普通 AI 负责人很不一样，因为你也曾是创始人，对吧？

**\[59:03\]** 你也习惯用这种方式想这些事情。在这个角色上这很重要。酷。我觉得你把 Monaco 介绍得够多了，随着 Monaco 的故事发展，我们可以再回来。也许衔接回来的一条路是：Monaco 内部的编码、或者 agent 原生的编码、现代软件开发是什么样？

**\[59:31\]** 我觉得你教书时是在给出全景，但在 Monaco 内部，你们在某些事上可能更有立场？

**\[59:40\]** 对。我们从基本第一天就在编码 agent 上投入，学到了很多。我们有自己踩的坑和学到的教训。我觉得我们现在越来越深地在分享其中一些，比如在我们的博客上，也许值得在这里分享。可能不是这一篇，那篇更像是产品。

**\[1:00:03\]** 我会说：当 AI 变得绝望时，与其扩大贡献，不如建或买 SRE。我们花了很多时间看不同的提供方和厂商，也自己造了很多东西。对我们来说，比如后台 agent 平台，我们有自己版本的 Ramp Inspect，叫 Monocoder，建在 Coder 平台上，但它是我们真正用来扩大工程产出的东西。

**\[1:00:26\]** Coder，就是 [Coder.com](https://coder.com/?ref=hubwiz.com)？对，Coder.com。我们把它适配到了一些自己的用例。我们大量 agent 开发就发生在那里。它真的是设计得很好的一块软件：隔离开发环境、扩到多 agent、能跑那种很长很长的 agent 编码任务。Monocoder，点名 John Tracy 和团队。

**\[1:00:50\]** 然后从那里，我们也造了自己版本的 Slack bot，也就是 HAL。但 HAL 实际上是三分之一个 AI SRE、三分之一个客户成功、三分之一个 QA 工程师，因为它住在我们的 Slack 里，但它既要帮我们debug、东西坏了时提 PR，也被我们自己的销售人员用来搞清产品怎么工作、怎么把一个问题查到最底层。

**\[1:01:21\]** 所以我们回答过一些有意思的问题：HAL 面对销售人员和对开发者时，要有不同的性格。像这样的系统我们过去一年多主要是在自建。点名 Yunja 负责 HAL，以及 John Tracy。

**\[1:01:41\]** 所以你大量自建。对。你们也用其它工具。我们确实也用其它工具。那线画在哪？对。建还是买？什么？

**\[1:01:49\]** 对，建还是买。问得好。我觉得有条通则：建来学、买来留——或者抱歉，是买来学、建来留。对，反过来那个。买来学，建来留。我觉得这里总体是对的：早期我们还在摸索、站稳脚跟时，比如代码评审，我们花了很多时间看不同平台。

**\[1:02:18\]** 结果今天我们还在用 Devin，因为我们确实依然觉得它的系统设计方式很有价值，所以点名 Cognition 团队。但这一路上我们也试过一些 SRE 工具、试过一些现成的、更像后台 agent 平台的东西，最后决定：考虑到我们的基础设施、我们自己云平台的搭法，内部建更合理。

**\[1:02:37\]** 当然我们不是教条的，如果有新东西出来我们愿意重新看。但通常我们在觉得外面没有成熟方案时，最后会自建。代码评审是个有意思的例子，因为我们一年多前确实把代码评审工具做了一轮完整调研。当时——我点名 CodeRabbit。

**\[1:02:59\]** 对，CodeRabbit 他们。还有 Graphite，被收购前用了一段时间。还有 Ellipsis，YC 公司。但有一大批，对吧？

**\[1:03:09\]** 我们试了很多人。它们都还行，但我觉得还没跨过“立刻有用”的门槛。所以我们先放一边了。那是一年多前。然后我们又回过头来，很自然地——再说一次，点名 Devin 团队和 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\]** 我很乐意回到 agent-ready 代码库。第四周和第五周是配套的。对，它们有点混在一起。对，混一点。那你在 Monaco 引入的、并且推荐大家先开始的信念是什么？当然。第四、五周，我会说四下更偏概念基础和做法，因为定制 agent 有很多做法。

**\[1:05:53\]** 然后第五周是我真正扑进去的地方：好，我们来想这个，把它用在真实代码库上。这里我一定要点名 Factory 团队，强调一下“就绪度报告”这类东西的价值。我想强化的主要一点是：agent-ready 代码库对我来说是之后一切的前置条件，也是一块积木。

**\[1:06:18\]** 我说“之后的一切”是指：人们一直——我觉得现在还是——对多 agent、并行 agent、几十个 agent 干各种事非常兴奋。但你实际上需要先打好地基才能把它做好。而地基就是：你的代码库有多可验证、结构有多好、agent 有多能看懂它。

**\[1:06:36\]** 所以对我来说，agent 就绪度几乎是接下来四到五周的第一块，直到第八、九周花更多时间谈广义的 AI 软件团队和组织级结构。但确实是在为后台 agent、为软件工厂打积木。我觉得从这个角度看，有意思的部分都在那里。对。我注意到你聊 Monaco 时提到过、但这里没写的一点是 SRE 那一侧。

**\[1:07:05\]** 当你把闭环合上时，你实际上想让 agent 读构建日志，理想情况下还让它读生产环境的分析数据。对，对。没有明写，但这是个很好的提醒。我会把它织进两个地方：后台 agent 那一周，以及软件工厂那一周。完全正确，这是很好的提醒。

**\[1:07:27\]** 这个“由触发／事件驱动的闭环”想法，现在大概是人们谈 agent 在软件工厂里发起任务时的两三个入口之一。完全正确，会放进去。挺有意思，人们叫它触发或事件驱动，我猜那确实是它的技术实现。对，听起来层级太低了。触发通常就是个 cron 任务，对吧？

**\[1:07:54\]** 说实话就是这样。当然当然。事件驱动通常就是一个 cron 任务把一个事件浮出来，然后就叫事件驱动，但全都是 cron。对，对，就是这样。或者 webhook 之类，但完全正确。对，技术术语当然是这样，因为说到底，作为一个 CS 出身的人，我们就是这么叫的，所以我大概会回到那套术语。

**\[1:08:19\]** 有哪个 AI SRE 公司给你留下印象吗？我觉得 Resolve 那帮人做得不错。Resolve 做得不错。我会说 Night Shift 在后台 agent 方面也做得很好。我是它的大粉丝，他们是 Greylock 投的，我觉得在这个领域做得挺好。对，我会说 SRE 是个有意思的用例，这可能又回到建还是买的问题。

**\[1:08:47\]** 我觉得有意思的是：SRE 到底在哪里真正看到最大的价值？

**\[1:08:55\]** 通常是当你有巨量的服务依赖、这些超大的系统、一堆 Kubernetes 和 Helm 文件散落各处，一个巨大的 Kubernetes 基础设施。我觉得这就是为什么 Resolve 在企业里做得很好：你去卖给福特、卖给沃尔玛，你说，你们的服务依赖疯了。

**\[1:09:19\]** 你看那些系统怎么搭的图。然后他们进去，说我们试着把这一切理清。我觉得小规模通常还管得住，你可以自己滚。但我得说，在企业级，他们做得不错。对。没在这种规模工作过的人——我花了一阵才看明白——这个规模是上万级仓库，仓库比开发者多。

**\[1:09:44\]** 这种情形下，你不知道公司里任何地方跑的是什么代码，因为写它的人大概已经不在了。太离谱了。而且顺便说，它还在低负载运行。这才是最吓人的。完全正确。然后你就是那个 on-call 的人，你面对一个在挂掉的系统，而那个人还是不在了。还有过期的 runbook，你只能想：这他妈到底怎么回事。

**\[1:10:10\]** 这是很吓人、很吓人的事。对，在企业层面，完全是另一种野兽。对，所以那种大学黑客式、一人一个仓库的人，从来没有体会。但我觉得你只要给他们这个想法，把他们丢进一个“上班第一天，这事发生了，现在怎么办”的模拟里。

**\[1:10:32\]** 对。所以这里再点名一个。Resolve 的人去年其实给这门课做了一个作业：他们造了一个沙箱，沙箱里有很多服务在做各自的事，甚至服务里还埋了 bug。作为作业的一部分，学生要真的去用 Resolve 的 agent，扮演 on-call 的人去探测系统、描述发生了什么。

**\[1:11:06\]** 他们有个有意思的网站。对，很有意思的网站。我有一阵没看了。这个交互性很强。他们在做 PagerDuty 那类事。对，还有这个视频。有意思。但好吧。我们除了这种对话，很少有机会聊这一侧。还有别的部分吗？

**\[1:11:32\]** 因为我觉得 AI SRE 可能要么太宽、要么太窄，取决于你怎么看。太宽的意思是：AI SRE 里有几个细分子领域很有意思。太窄的意思是：其实那不是我们最大的问题。你随意理解。对。你说的是 Monaco 具体，还是泛指组织在想这件事？

**\[1:11:53\]** 泛指，因为那是我们的听众。对，我觉得还是我们怎么扩展的函数。我觉得对企业来说，有一堆问题并不总是……我几乎觉得答案甚至不总是“更多 agent”。既然我们还在第五周 agent-ready 代码库，我跟某些规模的公司聊时，拦住他们的是更底层的 DevOps、CI、CD 问题。

**\[1:12:21\]** 他们的合并队列在堵。起一个应用要太久。其实就是更基础的东西，几乎跟“再扔进一个 SRE bot”无关——再扔一个 bot 不是问题的答案，因为他们有更系统性的东西要解决。所以……

**\[1:12:37\]** 这就把我们带到第六周。对，正是。这就是我们进入……对，正是，就是这里。合并队列及以后。对，这算是一封写给现代 agent 化代码评审的情书。我觉得去年到今年最大的变化就是：突然变得非常清楚，代码评审是瓶颈——尤其当人们真的被 AI 赋能，生成速度高到理论上一天能提 30 多个 PR。

**\[1:13:08\]** 然后呢？你到哪个点决定，要么把自己插到中间，用传统方式把关和评审——但那样你literally就是限制、就是速度的瓶颈。那不好，对吧？

**\[1:13:24\]** 那规模化生成的意义在哪？或者你说：我们怎么才能两头都要——既让自己介入到足够信任被合并的东西，

**\[1:13:33\]** 又能规模化地合并，同时又不是完全放任、什么都能进？所以我想在这里触及的很多就是那个中间地带，就是：

**\[1:13:45\]** 有一类问题，如果你在 agent 就绪度上做过用心的设计、在可验证性上做过用心的设计，那你可以在一定比例的、这一类问题上放心地自动批准。

**\[1:13:58\]** 而从设计角度、从架构角度，要自动批准，必须成立的条件是什么？什么时候你必须插进来说：不，这个我还是要仔细看？

**\[1:14:08\]** 而且即便你仔细看，你还在做逐行评审，还是在做别的？对，就是这一部分。今年我们最热的话题之一——我们有个客座作者计划，这篇来自 Aviator 的 Ankit。他有一整套关于“杀死代码评审”的文章，因为我觉得，那才是最终 boss。那是瓶颈。

**\[1:14:28\]** 他有几道闸来做这个。我不知道你有没有和 Ankit 聊过。我读过这篇，没亲自聊过，但我肯定读过。大体上是对的？

**\[1:14:38\]** 有什么批评？没有，我觉得这是对的，大方向对。你提到一件事，“最终 boss”。我觉得有两个瓶颈：一个是评审，另一个大概是意图，或者说最上面的那件事。还有些统计我很喜欢拿出来。每个人的统计都不一样。肯定。但很明显，更多人在合并。很明显，评审的数量没有跟着合并线性增长。

**\[1:15:02\]** 对。如果你看任何真的在这上面投入、认真想过的现代公司——有些人已经发过文章，我确信我们也会发——最近比如 Amplitude，我觉得 Cloudflare 也写了一篇好的。Augment 也有一篇好的，讲他们 AI 代码评审系统的设计。

**\[1:15:23\]** 这些都是一批非常好的——你要不要分享几个链接，我觉得写得极好。对，点名 Cloudflare，因为我觉得它某种程度上是家“传统”公司、或者更大的公司，但他们在 AI、AI 软件开发生命周期方面的内容做得非常好。我觉得他们那篇不错。

**\[1:15:43\]** 但 TL;DR：对，我觉得这是真的。我们还在找那个甜点：什么可以自动批准？什么真的不能自动批准？

**\[1:15:53\]** 而如果它不能自动批准，即便在那个必须有人类的世界里，我们评审什么？

**\[1:16:00\]** 我们还做逐行评审吗？我们做规格的某种组合吗？对，这里又是另一个问题。人们会让，你们会让规格一直保持最新吗？

**\[1:16:15\]** 不可能，对吧？嗯，我觉得，好吧，有几个不同的地方。线 issue 里存在的那份规格，和 PR 描述语境里存在的那份规格，对吧？

**\[1:16:25\]** 所以你可以把 PR 描述当作那个地方：用更紧凑的格式、大致描述整个实现。只要它是最新的、代表代码库这一刻状态的东西，我觉得实际上就足够了。所以我们在 PR 描述上是用了心的。我们不把它写成一段话，它实际上就是这份 PR 里发生了什么的一份规格。

**\[1:16:46\]** 甚至还有行级、文件级的指针指出哪里变了。所以你不只有高层的“发生了什么”，还有文件的构造、你碰到的服务边界。对，我觉得那就是我们投入很多的地方。

**\[1:16:59\]** 我要反推一下，因为对我来说，它当然是最低要求——它得和 PR 规格内部一致。

**\[1:17:07\]** 当然。不，我说的是**功能**的规格、代码库的规格，因为代码库是所有 PR 的总和。如果你的 PR 规格搞错了或漏了什么，它就会成为“整个代码库、或者说代码库的全部历史应该做什么”和“你这个 PR 在做什么”之间的差。所以我不期待你有答案，因为我自己也为此很焦虑。

**\[1:17:30\]** 我试着让模型去做，它们做不好。就是这样。所以人类才是那份规格的神——“五周前我做了另一件事，现在你在把它反回去。”你看过 Basis 那篇吗？

**\[1:17:44\]** 他们有条推、有篇小文章。我觉得他们讲“文件产物”讲得很好：他们通过 Git 跟踪这些东西，其中一些是规格、是“应该是什么”的意图，另一些是他们称之为代码“正典状态”的东西——那更接近你在描述的：隐性知识、隐性意图，它也必须被编码在某处。

**\[1:18:07\]** 对吧？那部分全在版本控制里。我觉得他们发现这对自己有效。所以也许这也是另一个可以分享的东西。对。这是 Basis，那家会计公司。会计公司，正是。对，我们很快会请 Mitchell 来纽约的会。跟我讲讲那个。我喜欢他们在提出这个。我的解决方案是——我不知道我有多准备好谈这个，因为我可能永远不会发布它——是一个**取代 Git**、用来捕捉这一切的东西。

**\[1:18:36\]** 我叫它程序数据库（program database），它捕捉所有 trace，并把规格物化成我们可以忽略又保留的东西。它也控制挂在上面的技能。因为我觉得基本问题是，Git 只关注代码，你需要一个只关于代码以外一切东西的真相源，包括那些隐性的——你刚才怎么说？

**\[1:19:00\]** 比如隐性假设或约束、意图。其它东西。对。但同时还要高并发。对吧。因为 Git 按设计到处引入互斥锁，这很讨厌。所以你需要超强并发。你见过——是 Kid Butler 吗？

**\[1:19:20\]** 那个曾经是 CTO 的人。Ian，我觉得他叫这个。我忘了他名字，但对的。Scott，Scott。所以我觉得有很多人在弄这个。而且有个问题是：任务的理想表示到底是什么？

**\[1:19:36\]** 我觉得赢家大概不是我，是 Linear。真的？因为任务就在那儿。而且显然他们已经决定变成一家编码 agent 公司。只要你买进 Linear，那里就有各类真相。对，是这样。我有个被半信半疑的看法：我觉得很多公司会演化成某种版本的编码 agent 公司。任何与 B2B 软件有交互、在收集关于用户的东西或某种产品洞见的公司，我觉得也能合上这个闭环。

**\[1:20:12\]** 因为最终，编码 agent 的目的是：对某种用户或客户参与其中的、正在发生的事做出行动，然后理想情况下用它修好产品的某个资产。我觉得 Linear 正在做的，我想 Amplitude 也能做同样的事，因为它们也在获得关于用户分析、用户问题的洞见。我甚至觉得，如果你想拉得很远，Decagon 或 Sierra 也能做类似的事：这里是坏掉的东西，去把闭环合上。

**\[1:20:37\]** 好。所以把这些都摆好：agent-ready 代码库摆好、代码评审摆好。安全是第七周，不是第一周。学生。你什么意思，安全不重要？

**\[1:20:48\]** 我开这个玩笑是因为我总说：在亚马逊，第零号工作是安全。他们总这么说。对。总之，安全评审放在最后。我在亚马逊待过，我不记得这个，但我信。这是 Andy Jassy 的说法。好吧好吧，我明白了。我在杰夫时代待过一部分，然后在他交接给 Andy 的时候又待了一部分。

**\[1:21:08\]** 对，我觉得这也是去年的一个话题，今年也是。我觉得那里……Isaac 去年也讲过。我觉得他是个极其深思的思考者——深思的思考者，这个领域的深思的领导者。我觉得 Semgrep 是家有意思的公司，因为它们在 agent 之前就存在了。那个开源仓库在传统 SAST 防御机制之前就存在了。

**\[1:21:36\]** 但我觉得它们很好地转向了——或者说不是转向，是把自己的产品扩展到这个领域。你知道，我觉得现在是个有意思的时期。

**\[1:21:45\]** 事情很多，这些攻击面正在浮出水面。AI 生成的代码和 slop 多得多。我想在这里驱动的核心之一，是依赖跟踪和供应链管理这个想法：你必须小心依赖、适当地钉版本，不要随便敲个 npm install 就指望整条链没事。

**\[1:22:10\]** 对。所以潜在最安全的代码库是一个没有依赖的代码库。对，正确。你看到那个依赖，你说：实现挺酷的兄弟，但我自己写一个。完全正确。这是个有意思的洞见，因为它走到了极限。我知道说比做容易。但如果你相信代码现在被商品化了、便宜了，那为什么不全部自己建？

**\[1:22:36\]** 当然，而且那会是最安全的，因为你看过一切、你控制一切，而不是依赖 Axios 之类。但我们看看有多少人真会这么做。那确实最安全，我同意你。不，这个说法危险，因为那样你只是在犯自己的错，而不是靠别人去发现错误。开源的全部意义是——那句话怎么说？

**\[1:22:57\]** 阳光是最好的消毒剂。Linus Torvalds 那派。就是：你会非常慢地发现自己自研依赖里的问题，因为你只有自己的用户，而他们不会向你汇报。但如果这个东西在全球有 10 万用户，总会有人发现什么。然后你就能更放心地依赖它，对吧？

**\[1:23:17\]** 嗯。这里面基本没有——我不想做那种人，我想做理性的声音。对，对。你不能在两头都绝对主义。而且我把你绕进去了，我把你带进了“一切外购”的论调。对。那里有个 bug。是啊。有意思。我好奇有多大程度、有多少方面是……

**\[1:23:40\]** 但有多少是被这个事实影响的：几乎一切都……我有一个信念：大多数开源仓库、如果不是全部，未来都会变成实际上由 agent 运营的软件工厂。那会发生什么——即便你看 Warp，对吧？

**\[1:23:54\]** Warp，一个现代编码 agent，当然他们也在卖软件工厂产品，但他们就把自己的开源 warp terminal 当软件工厂在跑。这几乎暗示：是的，人类还在参与，但越来越少。所以显然不是每个人都在以我们过去那种同等程度去评审进来的每一个东西。这会让代码库更安全还是更脆弱？

**\[1:24:17\]** 有点难说，对吧？我觉得这里有点微妙，我们还在……即便我认识的做开源的人，也在试图搞清楚那个稳定点到底在哪。对。这里有几个相关论点，然后我很乐意继续。安全是一个不停歇、巨大、巨大、巨大的面积。一个论点是 Vercel 的 Malte 说的：好吧，把每一个高度依赖的 C/C++ 软件都移植到 Rust。

**\[1:24:48\]** 那样会更快、更安全。而且大概不需要 600 万美元，你就能做完。然后还有另一个论点，这也和模型实验室那条“给前沿减速”的线相关：好，我们慢下来，或者我们做 Daybreak、做 Glasswing，确保所有人都打了补丁，然后再放任加速。所以我觉得有一种内在信念：模型会修好一切安全问题。但对我来说这只是未被证明的——因为如果它们引入了新 bug，而那些只是不同的 bug 呢？

**\[1:25:26\]** 对，对。所以，我在找反对意见。我在找那种“不不，你个白痴，显然模型在这上面强多了”。

**\[1:25:37\]** 对。我觉得这几乎是在谈极限：问题是，我们相不相信模型会造出完美的软件？

**\[1:25:46\]** 如果模型能造出完美软件，那就结束了。有这回事吗？那就完了，对吧？那我们都可以回家了，在沙滩上躺一辈子。我觉得还有一个问题是：把它先拿去做安全够不够好？

**\[1:26:00\]** 所以是让人先打补丁，然后把发布推后、之后再发？还是有另一个问题：不，它找漏洞会强得多，你可以全量跑、测更久，即便你已经打了补丁。多长呢，对吧？

**\[1:26:14\]** 你可以给它三个月，别人可以试着利用六个月。问题没解决，对吧？对，对。我全部的疑问是——这又是一整套抱怨，不用展开——你点名了 100 个组织：好，这些是优先的。它们拿到一个你刚造出来的网络模型，而你给我造出了 100 个可以去攻陷的攻击面。而且顺便说，它们相当容易被攻陷。

**\[1:26:40\]** 对。我不知道。总之，超出我们的工资级别了。在安全上聊得 juicy 总是很有趣。安全现在确实很 juicy，对吧？

**\[1:26:52\]** 我觉得安全圈的人其实很喜欢，因为他们通常得不到那么多注意力，现在他们有大量注意力。真的吗？

**\[1:26:58\]** 你什么意思？我是说他们得不到注意力。我发现至少从 VC 角度，VC 很爱投安全公司，而且回报相当好，比如 Wiz 之类做得非常非常好。Wiz 和 Socket——我两天前刚和 VC 聊过这个。据说过去五年里只有 Wiz 和 Socket 这两家安全公司成了。那 Abnormal 呢？

**\[1:27:21\]** 不知道。从 VC 的角度是成了。从经济角度看，有意思。不该我来说。显然那个领域有很多很棒的玩家，但我觉得这是门难做的生意。所以基本上，最好的时机——我觉得这没争议——对任何安全公司来说最好的时机就是刚发生一起高知名度事件之后。对，对吧？

**\[1:27:44\]** 显然。然后你显然能卖出一堆安全产品。完全对。所以我觉得这是公平的。人们应该了解基本的缓解手段。我确实认为代码扫描很重要，但我只想给大家一个观念：模型会引入你作为人类不会犯的 bug。而如果你不检查那些 bug，那就……甚至不是它们会造 bug，而是你对正在写的东西了解得更少，对吧？

**\[1:28:13\]** 就像人类那时——因为你在评审一切。对，对。忘掉 bug 吧。模型平均而言我会说 bug 更少。问题还在于，你甚至不知道自己在发布什么。对。这类事很多。对。所以我们得在缓解手段上用心，而且代码评审里也有安全和 CRD 的组合，对吧？

**\[1:28:35\]** 我觉得做那些检查也很重要。对，所以我想也许我再补一点，或者你检查一下我的直觉：并非代码库的所有部分都是平等的。代码库里安全最重要的部分是数据存储和计费。我们就叫它数据、计费、认证。认证显然和这些都相关。

**\[1:29:03\]** 而这些基本上不要 vibe code，然后其它一切随便玩。对，我觉得完全正确。而且很有意思的是：好吧，如果你不知道 O(n) 和 O(z) 的区别，请去学。然后，如果你没看过 AWS IAM——你显然看过——请去学。这些是基本的概念性东西，你得懂才能去提示。

**\[1:29:28\]** 一旦你有了那套语言，你就能提示。如果你没有那套语言，你就完了。完全同意。某种意义上我会把它延伸到一般的云平台那些东西，对吧？

**\[1:29:38\]** 我是说，有那么一家公司出过一次巨大的事故，就是一个 DNS 问题把东西搞挂了，是哪家来着？

**\[1:29:44\]** 你记得吗？DNS 问题？你得再缩小点范围。对，我知道。有过一个特别著名的。是吗？

**\[1:29:52\]** 也有很多著名的 DNS 问题。我现在想不起来了。我们来把它们列一遍。永远是 DNS。所以 DNS 更多是可靠性和可用性。当然。安全嘛，我觉得人们会问：你丢钱了吗？

**\[1:30:06\]** 你泄漏客户信息了吗？对，对。我大概会把那个排在更上面，肯定。DNS 只是因为——一般可用性。对。后台 agent。现在你有你高通的朋友在这儿。但我是说，你的嘉宾不一定和那一周对应，对吧？

**\[1:30:21\]** 对，不是。第九周那个有点排期问题，我塞了 Ilaad 进去，我大概……不是每周九。Ilaad，我想把他放最后，但时间上没对上。所以那周有点怪，我大概第九周根本不上课，但我们在第十周会回到那些话题。

**\[1:30:39\]** 所以那里有点奇怪的错位。但第八周，Rajesh，他一直在 Cloudflare 带很多基础设施方面的事——云基础设施、开发者体验等等。就像我之前说的，我觉得他们在这里做得很好，而且以他们那个规模、一个上市公司的规模来说，采用程度非常了不起。他们的内容我觉得也很好。

**\[1:31:00\]** 我是说，这根本上关乎你能用异步后台 agent 的哪些方式。我大概也会花不少时间讲 Stripe 的 Minions、Spotify 的那一套——我忘了他们叫什么——Ramp Inspect 之类，我觉得这些都在展示：规模化之后是什么样。Cloud Tag。Instinct。对。Muse？

**\[1:31:23\]** Muse？我觉得少谈消费者，多谈软件团队怎么规模化用它们。它们底下全都是编码 agent。确实。一切都是编码 agent。对，像 GrokBot 就是那种有意思的东西：它被呈现得很消费级。它是 Grok。底下是 Cursor。对对对。是 Cursor 团队。不，肯定。所以我看到 Cursor 在点点点里工作。

**\[1:31:49\]** 但他们没有基于代码的集成，对吧？他们有。好吧，我没用过那个。我一直只用它订餐厅。正是。我觉得那正是他们想做的事。我明白了。他们想做成：你可以拿它做消费级的事，但如果你会用，这里有额外的力量，因为它底下其实是 Cursor。我觉得这适用于所有编码 agent，对吧？

**\[1:32:14\]** 比如 Claude Code、Claude Design，人们用 Codex 却不知道自己在用 Codex，对吧？一个随机的代码解释器窗口弹出来，你只是在问 JetGPT 一个问题。某种程度上，底下就有个编码 agent，对吧？

**\[1:32:29\]** 对，所以我给你另一个实践例子。我的所有 SEO 和 AEO 都跑在 Codex 上，它有一个代码库——尽管传统营销人员大概只会查个地址什么的。因为我写所有这些脚本去做各种疯狂的事，而且我需要存数据，也需要可视化数据。很快你就会发现：只要你在做任何持续的事情、有也许很多步骤或很多数据，你就需要一个代码库。

**\[1:32:58\]** 嗯，这个看法有意思。我觉得模型也喜欢建代码库。不，但那可能是暂时的。我猜我的点更多在界面上，对吧？

**\[1:33:09\]** 就是说，你会不会走到这一步——GrokBot 会有一个地方让重度用户能看到底下的代码？

**\[1:33:16\]** 还是说那会被抽掉？也许他们就干脆跳到 Cursor 去了，你是这个意思吗？正是，因为不然你基本上就在自噬 Cursor。如果极限情况下你说 GrokBot 就是 Cursor，那你连 Cursor 都不需要，如果底下的一切都在变成……是同一个团队。所以现在他们不在乎。对，全都是 GrokBot。

**\[1:33:34\]** 对，对。我买这个。我是说，我确实接受：即便外表看起来完全非技术的用例，底下也是技术的，也可以用代码写、设计和实现。这一点完全成立，对吧？

**\[1:33:47\]** 问题更多是：一个开发者，那是不是他们唯一的入口？对。我觉得甚至不是开发者，对吧？你想想一个做营销的普通人，现在用 Claude Code、或者就在 App 里用 Claude，他在一个他永远不会知道、永远不会碰的代码库里工作，但那里有个代码库管理器。我觉得 Cloud Tag 是后台 agent 的好例子。

**\[1:34:09\]** 这是 Anthropic 工作方式的一大块，他们把它做出来了，你该看看他们怎么工作。对，对。来一发。好，AI 原生团队。我们聊了很多像网关这类话题。我们今天刚发了一期路由的节目，还有 MCP 门户。我会说 MCP 门户是最不成熟的那个。我对 MCP 看多——不是看多也不是看空，它就是现在景观的一部分了，对吧。

**\[1:34:37\]** 那是个陈述——有过一整个“MCP 回来了”“MCP 死了”的循环。

**\[1:34:42\]** MCP 门户是门未被证明的生意。我想过做一个，我其实还提过一个指南和话题，关于有可能做一个，然后我失去兴趣了。我对很多东西都会失去兴趣。那里面有什么？

**\[1:34:55\]** 我在这里想的是：如果这一周更偏向“规模化到发生什么”——把一些原则拿走会怎样。这里面很多是被我和各家 AI 原生团队负责人的对话塑造的。所以在这里，我觉得 MCP 门户这样的东西到了某个规模就真的有意思了：你必须有一个单一入口去做治理、安全、审计、成本优化。

**\[1:35:25\]** 所以我很好奇你怎么看这类东西的未来，或者它的“没有未来”。但对我来说，如果你相信一个开放路由、或者一个单一入口让很多事情发生、连接、并被有效治理，我感觉也有一个世界是这件事可以存在。对。我唯一的修正意见是：这会并进 LLM 网关。

**\[1:35:48\]** 它们是完全同一个平台。这个我给你。这个我给你。我能接受。这个你确实能同意。然后顺便，它也并进另一件事——我刚才说什么？

**\[1:36:00\]** 是 O(z)、权限控制这些东西、还有计费。所以到极限，所有基础设施都收敛到同样的问题：中间有个盒子，两边各有一个盒子。Godbox 会解决一切，对吧？

**\[1:36:14\]** 对企业来说。只有当你理解 Godbox 的工作时它才成立。所以把 MCP 门户和网关分开，意味着你不接受它们是同一层问题。很像地，我也发现人们不理解数据库查询里有很多类似的东西：他们要把过滤和排序分开，或者把通用推荐分开。它们是同一个问题。所以你就——因为当你把这些东西合进同一层，你就可以以有用的方式交叉依赖彼此。

**\[1:36:50\]** 如果它们是不同的层，就做不到。对。我其实不会反对这个。我觉得也许——所以稍微教学一点——我觉得把不同术语分开还是一起，这件事：底层架构是那个 Godbox，这个说法绝对正确：一个东西进去，另一堆东西（有些是第三方的、有些是第一方的）都在 Godbox 的另一侧。

**\[1:37:15\]** 所以是的，其实我同意这个。我有一条辛辣的推。天啊，Godbox 那条推在哪？这是 M×N 变成 M+N 的架构。所以任何做基础设施的人都得懂。恭喜你现在在基础设施里有份工作，或者你想当基础设施工程师，你就得明白：你整个工作就是造 Godbox，然后把它拆开。所以要么你的问题是你的 Godbox 不够好，要么你的问题是别人的 Godbox 你不喜欢。

**\[1:37:50\]** 所以现在你得把它拆开、自己造一个。挺好玩的。非常有意思。我喜欢。非常好玩。直到宇宙热寂。哇。挺好玩的。这基本上是在重述：做软件只有两种方式，你把它们捆起来，或者把它们解绑。对。但你捆的是什么？

**\[1:38:07\]** 希望是那些该在一起的东西。然后随着时间，人们的看法会变——什么该在一起、什么不该。对。所以有那一整套……也许 Monaco 该更像一个点状解决方案，也许 Monaco 什么都得自己拥有，对吧？

**\[1:38:25\]** 而这里有个问题：某种意义上，你在为你服务的那个创业公司细分市场做捆绑；某种意义上，你在从 Salesforce 解绑——因为那就是你从 Salesforce 赢走市场份额的方式，你从 Salesforce 解绑出来。这很有意思。这是个更大的陈述，把它连到整个垂直 AI。现在，捆绑、解绑——我是说，那就是整个 Craigslist 和 Airbnb、Tinder 之类全都分开的故事。

**\[1:38:53\]** Tinder。就是那种个人广告。对，对，对。我确实——从没这么想过。但是的。所以，我们今天刚发了 OpenRouter 那期播客，对吧？

**\[1:39:05\]** OpenRouter 巨大成功。很多人都想做网关，没有一个像 OpenRouter 那样成功。OpenRouter 只做网关。所以这就是一个例子。他们不同意我说的“路由层也该做运维”，因为 Arise 在做运维和可观测性之类。而 MCP 网关，他们没有那些，他们只处理模型路由。

**\[1:39:31\]** 我很喜欢这样被打脸，因为他们说：我们是点状解决方案，我们只把这一件事做得非常非常好，这是我们的工程焦点——这很好，同时也是营销焦点，这更好。我觉得你描述的那种“一站式全做”在意识形态上是有道理的。但我觉得实践中会发生的是——部分大概是营销——尤其是你看企业时，这广义上属于基础设施、属于平台，但然后会有不同的团队拥有同一技术栈的不同部分。

**\[1:40:04\]** 我觉得在企业规模上，这种合并在很大程度上就是：如果我们只是 MCP 门户加网关，总得有人站出来说，现在你打的是同一个端点了。而这根本上是件很难让所有人都同意的事。所以它往往是更政治的、甚至人的问题，而不是纯粹从软件设计角度这件事明显合理。

**\[1:40:25\]** 但这就不是软件了。软件系统有时就是由人的问题带来的，而不是纯软件。我的说法是：你知道你怎么“交付你的组织架构”吗？

**\[1:40:34\]** 我忘了这条原则叫什么。康威定律：你交付你的组织架构，你购买你的组织架构。当你创一家公司或者做一个工具，公司里谁是你最好的朋友？

**\[1:40:47\]** 而如果它是给所有人的，它就是给没人的。这很有意思。真的很有意思。所以 Latent Space 和 AIE 有意做的一部分就是：好，有这么一类软件工程师，他们对 AI 真的、真的、真的非常在意。他们会把它当成主业吗？

**\[1:41:05\]** 那就只为他们做。对，对，对。不是工程的捆绑。永远不会是“给所有开发者”。对，你看，我们聊数据库、聊安全，但那里有个 AI 角度。再看。有道理。

**\[1:41:22\]** 软件工厂。我还想点名一件事，和这个点相关：我觉得未来的一个角色会越来越重要——**平台工程师**。我觉得这个很大。咳，更多 lore。Temporal，在这之前的那份工作……如果我没做 AIE，我会去做平台工程师。因为那是决定所有这些任务的角色的位置，然后应用层的孩子们可以在我们的平台上随便玩。

**\[1:41:51\]** 你知道，大玩家都做平台。对，我觉得在今天，他们拥有云、拥有 DevEx、拥有安全，所以我觉得是全部。一切能真把公司弄丢、或者成败所系的东西都是平台的人。然后产品的人可以调 CSS。

**\[1:42:14\]** 这话说的。你这是在挑起战争。我不是调 CSS 的，但我感谢所有人。我是说，这是好玩的时代。未来呢？

**\[1:42:24\]** 我觉得所有人什么都能调。对，对。所以这里有几个方面。好，这里有一点从上一周溢出过来的东西。就是编码 agent、大团队、一些概念，然后我们会谈到软件工厂。我想让人们真正开始思考“造机器的机器”这个世界：人在那里、如果有人，还在环里吗？

**\[1:42:44\]** 今天我觉得答案是意图，加上某种形式的评审；或者说，意图是你定义规格、定义需要建什么的地方，评审是你自己做一定量检查的地方。当然，这个瓶颈会比意图那一块更早被放宽。但就目前而言，我觉得在一个全自动系统里，那两个是瓶颈。

**\[1:43:07\]** 所以，我想让人们看到这个。其中一家开源合作方其实就做了——Warp。他们作为对开源计划贡献的一部分，会做一件事：他们要做一个跑着工厂的 Warp 版本，学生就是在建工厂、给工厂做贡献、让它一直跑。“来我们工厂上班。”来我们工厂上班，正是。

**\[1:43:26\]** 所以那会是其中一条路。然后他们会发现那里有意思的东西，再把它拉回来。这种事我也不确定——显然工厂本身很热衷。我感觉每个人都想建自己的那一套。对，我觉得这是个好问题。当然他们有权试着卖自己做的产品。

**\[1:43:48\]** 我觉得一个系统很难被完整地拥有。它太大了。“请替我把一切都决定了吧。”对，它确实太大了。我还没深入理解他们在 GTM 上怎么打。但我怀疑你得一块一块来，对吧？

**\[1:44:02\]** 你得先做他们的编码 agent。然后，你基本上就是 land and expand，对吧？我们聊过捆绑和解绑。你不会一上来就说：这是你的整个工厂。你根本不可能让福特接受这个，你懂我意思吧？

**\[1:44:14\]** 直接把整个东西往人家桌上一放。至少我会这么想：你先成为他们的编码 agent 选择，然后给他们做一个后台 agent，接手他们的部分 SRE，然后你说：好，现在只要你在代码里（或者配置里）把一切定义出来，我们就能把它全织在一起。

**\[1:44:32\]** OpenAI 有篇好玩的博客讲这个。我们的朋友 Ryan——我们请 Ryan 上过播客。基本上他们花了五个月做一个内部工具，零行手写代码。他们大概走了一遍。一，它叫 Harness Engineering，所以你可以学 Harness Engineering。那里的学习是：一开始有点卡、有点慢，然后你卸下负担，你有 PR 评审。

**\[1:44:56\]** 这时候是二月的东西，但它是一个软件工厂的愿景，对吧？就是你全力放手，让 agent 全写，以及怎么把它做好。对，绝对。我是说，某种版本的这个会出现。就 swyx 的点，我确实好奇这里的销售那一块，就是这件事真正的生意。那是个有意思的问题。但从原理的角度，我觉得这已经是一种未来形态。

**\[1:45:25\]** 在此之上，我觉得还会有一点涉猎和讨论：好，未来做开发者意味着什么？

**\[1:45:34\]** 人们聊品味。人们聊对系统和架构的理解、软件品味。我想在这里再深入一点，至少给这个问题放上一些答案。对。所以这就是你对 AI 软件工程下一步去哪的回答。对。工厂是战术层，但在此之上，有一个关于角色的问题。角色演变成什么？

**\[1:45:57\]** 如果工厂在跑、全速前进做它的事，传送带在吐出代码，我们在这一切里干什么？

**\[1:46:05\]** 我觉得你和我、我们和 Jerry 在几周前一次晚饭上聊过这个，和 Dex、Jerry 一起，围绕工厂。我觉得那里至少有一点我是基本认同的：抽象层级在提升，然后总还有某个人——即便是公司 CEO——必须有足够的监督和对各个组成部分的理解，才能对方向做判断、才能纠偏、才能设定指标这类事。

**\[1:46:34\]** 我觉得有一个版本的这个类比可以翻译到监管技术的人身上。我们叫它 agent 的经理。我们叫各种词，都是流行词。但某种意义上，是某个理解产品需求、约束、技术约束，把这一切串起来、懂得裁决的人。对。我得说，坐在你这把椅子之前上节目的，是 Anthropic 的产品负责人和平台工程负责人。

**\[1:47:03\]** 我就问，你们的工作什么时候会来？他们说：还没。所以如果 Anthropic 都还没到那一步，你就不该觉得它迫在眉睫。好，好。他们说了还要多久吗，还是只是“还没”？

**\[1:47:18\]** 只是还没，但谁知道呢。而且肯定有很多那种“好吧，我在做她的活、她在做我的活”。对。我觉得对学生来说这也是个有意思的视角，对吧？

**\[1:47:28\]** 你说有很多大二本科生。你还有两三年时间来规划你想做什么。从这个角度有几种看法，对吧？

**\[1:47:37\]** 你还没直接进行业。我在意、我在多想的是：这场讨论里有一部分更让我共鸣，就是循环：好，你最初在写提示词。现在你不写提示词了。你写提示词，它们写提示词。对。然后它们就一直往上走。对我来说，那种递归的、同心圆式的、既向外也向内的性质，是建起工厂的东西。

**\[1:48:05\]** 我觉得是**往上建到工厂**，而不是往下建。但我觉得很多人最终会开始往下建。就像你从顶层开始：我的目标是什么？

**\[1:48:14\]** 然后你倒推系统。那个目前会产生巨量 slop，你现在不该那么做。但有一天你会。

**\[1:48:22\]** 对。所以那会是我要问你的问题。

**\[1:48:31\]** 就是：人们存在要去解决的那个首要问题是什么？那就是你的东西，对吧？比如今天的工程师，你被衡量的是 PR 合并率、PR 贡献率。好吧，两年后这会很荒谬。那你的主要指标是什么？

**\[1:48:54\]** 钱？人们总是太快跳到钱。它是钱和 PR 之间的某个东西。客户满意度，你那些功能带来的 CSAT 分数。即便那也是产品决策，不是真的代码决策，对吧？

**\[1:49:05\]** 我不知道。但如果工程正在演化成更像 PM 工程师、产品工程师、混合体，那我觉得这是那个“角色演变成什么”的一个答案。

**\[1:49:17\]** 不用说，今天我会建议学生花更多时间想整体系统，而不只是你那一块工程拼图，而是它怎么和……这在实践中已经在发生了。比如学生做结课项目，我鼓励他们走出去。事实上，我给他们当最终项目种子想法的，是 YC 的“我们想资助的创业想法”清单。

**\[1:49:39\]** 我几乎是说：去建一家公司，你懂我意思吧？去吧，去建点有意思的东西。去年人们建了什么？各种各样。比如有人来自 E 系、学 EE，他们实际上做的是一个翻译器：解析那些带 C 内存地址的手册，然后转成能解释、甚至可视化的代码。

**\[1:50:05\]** 所以是那种非常具体的、针对自己用例的东西。有人是设计师，现在实际上在 Vercel。她的项目是：拍一张我的设计笔记本的照片，然后基于照片给我生成一个 app。对。所以literally 她演示的时候，我说：来吧。她对着自己随手画的一些涂鸦拍一张，就拿到一个完整成形的 Vercel app。

**\[1:50:23\]** 我觉得正因为那个，她大概拿到了 Vercel 的工作，做类似的事。哇，不错。那其实是个很高的门槛。Vercel，以设计工程师闻名。对。我记得她现在在做 Eve。啊，不，Eve 是你们的？

**\[1:50:37\]** Eve 是个开源项目，或者开源合作方。我是说，我们卖合作的方式之一就是让他们带着学生用 Eve 做东西。对。所以这是元 harness 的概念，对吧？

**\[1:50:49\]** harness 的 harness。你总可以再往下一层。但我确实觉得这有道理，至少对我来说：就像模型路由包住了模型 API，你也需要包住 harness。有道理。我觉得某种意义上学生也该保持脚踩在地上。边上有很多事在发生。也有很多公司还在生产里就是单次调用 ChatGPT、只是玩玩、还没试过。很多这种情况。所以做事的窗口还在。但我觉得你关于品味的点很好：有品味，去试东西。至于每家公司是不是有自己版本的软件工厂，你在造工具帮公司做到这件事，

**\[1:51:34\]** 保持跟进、真的去用工具、去玩，你会一路搞明白的。对，我百分百同意所有。首先你的点：很多公司还在“提示一下 ChatGPT”或者某个版本的 ChatGPT？

**\[1:51:49\]** 也许他们刚买了 Cursor 授权，刚开始让人上手。这比我们相信的要真实得多，至少在硅谷是这样。这我可以百分百肯定。但我觉得对学生来说，接触这些的意义在于：某一天，正因为你知道这些、你在边上，才最终让你在去到那些可能还没到前沿的地方时，成为更有意思、更有价值的贡献者。还有一个关于这种进阶的演讲，大概一年前，仍然非常有影响，Yegge 讲的“精神病级别”，他现在已经到第 10 级了，

**\[1:52:27\]** 他已经放弃，搬到农场去了。但我得说，抱歉，我在开他玩笑。他建了 Gastown。对，我记得。对。所有这些事，搬到 Gas City。现在他把那座城烧了，说我在做我的游戏。我不再是 Gastown 了。我记得今年早些时候在 engineer fair 跟他聊过，他的整个说法不是：Gastown 里唯一建出来的有用的东西就是 Gastown。

**\[1:52:53\]** 对。对吧。那是个可怕的失败。可怕。完全。所以人们应该知道：精神病是真的。如果你不要求自己对交付真产品负责，你就只是在跟 LLM 瞎搞。对。这也许相关。我好奇有多大程度是——我玩过一点 Gastown，非常复杂的系统，也许有点超前，但我也好奇它是不是被营销拖住了：从术语角度它太难懂了。

**\[1:53:24\]** 就是有太多东西在跑。对他来说是有意义的。我觉得 Gastown 的营销也是推动它的事情之一，对吧？

**\[1:53:30\]** 那在 Gastown 之前是什么？Beats。对，Beats。除非你在说别人的东西。不，有整个 open claw，还有别的东西，然后是 Gastown。而整个宣言也真的帮它推进到了概念层面：那些永远不会用 Gastown 的人，因为读了宣言而知道了 Gastown。这里有营销角度。对，所以 Steve 不必然要字面理解，但方向是对的，你知道？

**\[1:54:04\]** 所以我觉得他在这件事上方向是对的。所以如果你还在 IDE 阶段，是时候进到 power user 阶段。如果你在单 agent，是时候进到多 agent 之类的。而且你大概应该试着建自己的编排器，对吧？

**\[1:54:16\]** 就是所有这些。可以论证的是，这在今天已经有点过期了。软件工厂之外还有更多。但这篇文章早于软件工厂。我确实觉得这些里面有一件事我是开放的——作为雇主，我公司里今天就有这个问题：我不想招任何一个没经历过精神病、并且从那头出来的人。因为我现在正在为某个人经历精神病付钱，从他的工资看非常贵，从 token 看非常贵，而我什么都没得到，他自己也没得到。

**\[1:54:48\]** 我的反馈传不进去。所以有点像我会鼓励你的学生去经历精神病，然后出来说：好吧，我哪里有问题？因为 Steve 刚经历的就是这个，一场非常公开的两年旅程。对，学生那侧也很怪：很多行业里你以为你在产出，其实不是——那大概是学生版：你在 Notion 里画图、做所有这些优化，personal ass，然后想：靠，我经历了精神病，但什么都没变。对，所以去经历它，去经历它。对。我没看过这个。

**\[1:55:22\]** 我见过 Boris 的一个版本。显然更偏 Claude 的用例。但我记得他做了一个 Claude artifact，更多是团队层面的，我觉得他有四个阶段而不是八个，但大致的进阶路径差不多：从不采纳到……对，只有四个好。这个层级太多了。我们看看能不能把那个调出来。

**\[1:55:44\]** 除此之外，往外拉一点，我们是不是把所有事都聊了？就是这个。哦就是这个？好，来了。这是一份 RFS。好。所以是 gated、assisted、parallel。最后一个是什么？

**\[1:55:55\]** Supervised autonomy 和 AI native。所以是零索引，所以是五个级别，对吧？好。你从零开始？对。哇。其实这相当不错。我需要更深入地读一遍。还有 AI native。对，对。我想点名 dynamic workflows。它是一种子 agent 模式，OpenAI 的人也在探索，显然很契合。所以基本上你为你想要做的事**按需写一个 harness**。

**\[1:56:26\]** 所以这也许——很多子 agent 的讨论其实是你复制父 agent，但实际应该写更多代码，然后把它当一个子 agent 跑。这就是 Anthropic 的人选择叫 dynamic workflows 的东西。好。但我们……对。我们也建了一个版本。对。这是个好模式。给 Monaco 的？

**\[1:56:49\]** 它做什么？就是即时生成、面向 GTM 的 harness 用例。哦，很棒。对。我要指出，Boris 写这个是为了团队采纳，给在听的各位。而且他说，你知道，Anthropic 在第三阶段，我们还在努力到第四阶段。哇。他就像：我在第四阶段，我是那个人。但你知道，它不像 Steve 那么简单。Steve 是个非常好的个人版：做这个做这个做这个。这个更像：如果你在带一个团队、想给团队做 AI 化，而不只是自己做个用户，你知道，Anthropic 都还在第三阶段。

**\[1:57:28\]** 别，别学，对。好吧。我是说，你该教这个。这很棒。这里面有我们聊过的一切。就在这里。我不敢相信我居然没见过这个。对。非常好，非常好。好。这是一趟狂野的巡游：一学期斯坦福，一小时或者两小时。谢谢你。有什么临别想法、什么号召？

**\[1:57:49\]** 没有，我——谢谢，这特别好玩。这件事筹备了九个月，我很兴奋。现在是第一周结束。有很多事要做、有很多要学。我很兴奋看到会发生什么，尤其是开源合作方那边，还有把学生塞进一些复杂代码库的代码里、让他们建点东西。会很好玩。会跟你们同步。你明年会再做一版？

**\[1:58:10\]** 你需要给学生的额度——如果开源那边的人想参与，他们可以联系你？当然。那些额度很重要。他们想要吗？他们真的想要那些额度吗？

**\[1:58:20\]** 学生们？你确实有信用卡。我不觉得很多学生想花钱。我在做一张 EIU 信用卡。对，不，我觉得。你看，我记得肯定有一定数量额度，但在此之上，他说：看，如果他们想放开搞，告诉我，我们就搞一些一次性的实验，让他们能扩到 1,000 个以上 agent。

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

**\[1:58:48\]** 对。那种有野心、而且真能执行的人，非常值钱。而这基本上就是一次招聘号召。对。这是个好点。对，但我确实觉得学生该懂得怎么有野心。

**\[1:59:04\]** 因为讲礼貌地拍一张照、把它变成一个 app，在今天这个时代并不算有野心。写一个浏览器才是。而且确实还有更多那样的项目。对，我觉得对。全都在于把地板抬高。我是说，去年那事，得给去年那个学生记功。但今年，显然我们会期望更多。那现在算是失败。

**\[1:59:24\]** 我们会期望更多。但那就是全部的意义，对吧？升级。去年是：嘿，你听说过提示工程吗？

**\[1:59:30\]** 就是这样。我花了一些时间讲 K-shot prompting 作为其中一课。而你们现在大概根本不会想那个。我觉得有一种是让你在同学里显眼，另一种是你在早期工程岗位上，而行业里一堆人还在找工作。

**\[1:59:51\]** 这不是——不是要单独点某一个 demo，但你可以做很多事让自己显眼。我给学生一个第 11 周的免费建议：做 benchmark，做 benchmark 和评测。这会给你一个好位置，它能让你敲开每一个前沿实验室、每个顶级 agent 实验室的门。还有带点严谨度的、关于任何有意思事情的优秀工程博客。那方面还有很多低垂的果实，但工程博客效果真的很好，对吧？

**\[2:00:19\]** 你在某件事上钻深了。对，而且大概那里面也有很多钱可赚。所以不只是敲门，如果你把它做成生意，你可以真的真的赚到。对，人们不知道，比如 SWE-bench 曾经是本科项目。对，对，对。普林斯顿的，对吧？

**\[2:00:37\]** 对。太好了。太棒了。就这样。非常感谢。谢谢各位。

---

### 来源

- 节目：[How Stanford Teaches AI-Native Engineering — Mihail Eric, Monaco](https://latent.space/p/cs146s?ref=hubwiz.com)（Latent Space，2026 年 11 月 8 日；AI Engineer 百万订阅特辑）
- 课程：[Stanford CS146S · The Modern Software Developer](https://themodernsoftware.dev/?ref=hubwiz.com)
- 视频：[YouTube 完整版](https://www.youtube.com/watch?v=dpY7YzZo4kE&ref=hubwiz.com)
- 文中提到的材料：[Understanding is the new bottleneck](https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck.html?ref=hubwiz.com)、[Monaco agent 开发者工作区](https://www.monaco.com/blog/agent-developer-workspaces?ref=hubwiz.com)、[Basis 的 Authority Map](https://www.getbasis.ai/blogs/how-we-made-our-monorepo-ergonomic-for-agents?ref=hubwiz.com)、[Stripe Minions](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents?ref=hubwiz.com)、[Faros 的 AI 工程研究](https://www.faros.ai/blog/ai-software-engineering?ref=hubwiz.com)、[Boris Cherny 的 AI 采纳阶段](https://x.com/bcherny/status/2077929379661844559?ref=hubwiz.com)

### 编者补充

原文是一期播客，观点散在 20 多个时间点里。我们的整理把“十周课表”按**依赖顺序**重排成一条线，方便拿去对照自己团队缺哪一环：

| 周  | 教什么                     | 缺了它会发生什么                 |
| -- | ----------------------- | ------------------------ |
| 1  | harness 内部（200 行写出一个循环） | 把 agent 当黑箱，出问题只能重写提示词   |
| 2  | 上下文工程 + 工具设计（MCP）       | 只在“vanilla 提示”水平，碰不了大代码库 |
| 3  | 技能（把过程写成文件）             | 每次都手写提示词，经验留不下来          |
| 4  | 定制机制（配置、hooks、子 agent）  | 有工具但组不成流程                |
| 5  | agent-ready 代码库         | 后台 agent、多 agent 全都建在沙上  |
| 6  | 代码评审（合并队列）              | 生成速度上去了，人成了唯一瓶颈          |
| 7  | 安全（依赖与供应链）              | slop 进主干，没人知道在发布什么       |
| 8  | 后台 agent（触发／事件闭环）       | 只能待在 IDE 里，接不上 CI 与线上    |
| 9  | 团队设施（网关、MCP 门户、角色）      | 每个团队各买一套，治理与成本失控         |
| 10 | 软件工厂 + 剩下的人做什么          | 没有“意图”和“验收”的入口           |

两条边界要放在前面。其一，课表里**不是所有东西都定论了**——Mihail 自己在节目里说了两遍“这不是 settled science”，软件工厂那一周尤其如此，他引用的一线数据是“最前沿的工厂也只有三成左右是全 agent 驱动的”。其二，节目里出现的公司名（Devin、Factory、Resolve、Warp、Monaco）都是**被访谈者自己的使用与赞助关系**，不是评测结论；他说得很明确“我不为任何工具背书”。

对“该学什么”这个问题，节目给出的最短答案是三条：能读懂 diff（不然你无法为合并负责）、能设计可验证的系统（不然自动化就只是加速不确定性）、有一个能判断方向的品味（不然抽象层级越高你越瞎）。第一条可以看我们写过的[《AI 辅助提交怎么标》](https://www.hubwiz.com/blog/ai-commit-attribution-assisted-by-vs-co-authored-by/)，第三条的工程化版本是[《harness 工程指南》](https://www.hubwiz.com/blog/harness-engineering-agent-guide-lunar/)。

本文由 汇智网 · Software 2.0 编译整理，转载请注明出处。

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)