[
  {
    "i": 0,
    "speaker": "Lauren Tan",
    "text": "对于 GrokBot，我们真的希望从一个全新的视角来探讨：如果你的智能体更像是一位同事，那会是什么样子？嗯。呃，于是我开始思考，怎样才能让我的智能体在我睡觉时自动为我修复 bug？"
  },
  {
    "i": 1,
    "speaker": "Lauren Tan",
    "text": "所以，这就是我们早期一些实验的灵感来源，比如构建一个更持久的机器人。"
  },
  {
    "i": 2,
    "speaker": "Lauren Tan",
    "text": "如果你在早期大量投入，我看待工程师角色在智能体世界中的演变方式是，你知道的，就像我之前提到的，你基本上是你那些智能体的工程经理。但我认为，我们现在的一大责任是"
  },
  {
    "i": 3,
    "speaker": "Lauren Tan",
    "text": "工程师的职责之一也是，你知道的，保持代码库处于一种状态，让产品经理和设计师能够贡献高质量的代码。呃，好的，所以我假设你能看到我的屏幕。"
  },
  {
    "i": 4,
    "speaker": "Speaker 1",
    "text": "是的。"
  },
  {
    "i": 5,
    "speaker": "Lauren Tan",
    "text": "是的，我们很好。所以是的，今天，我认为对我来说，在我使用智能体编写代码的过程中，我相信你们中的许多人也有过同样的经历，最大的主题就是：你如何信任它？"
  },
  {
    "i": 6,
    "speaker": "Lauren Tan",
    "text": "你知道，尤其是如果你是一名写了很代码的工程师，你对如何做好工程有着很多见解和经验教训。"
  },
  {
    "i": 7,
    "speaker": "Lauren Tan",
    "text": "当你看到智能体只是即兴发挥、猜测、产生幻觉，并且第一百次自信地声称找到了确凿证据时，但事实却是……实际上不是真正的问题，你会失去很多信任。"
  },
  {
    "i": 8,
    "speaker": "Lauren Tan",
    "text": "而且当你输掉的时候，如果你对你的智能体没有太多信任，我觉得你真的无法让它们发挥最大的作用。对我来说，这与管理有相似之处。"
  },
  {
    "i": 9,
    "speaker": "Lauren Tan",
    "text": "呃，所以如果我是一个团队的工程经理，我手下有一群工程师，而我不信任他们，那么我的管理方式就会变成微观管理，对吧？"
  },
  {
    "i": 10,
    "speaker": "Lauren Tan",
    "text": "我得花大量时间盯着下属的屏幕，检查他们的工作是否到位，确保他们没有把 bug 发布到生产环境。"
  },
  {
    "i": 11,
    "speaker": "Lauren Tan",
    "text": "所以我画了这张图，因为呃它并不是什么很科学的图表，但这代表了我对自己以及在使用智能体过程中的心路历程的想象。"
  },
  {
    "i": 12,
    "speaker": "Lauren Tan",
    "text": "所以，你知道的，快进或快退，或者说快退，快退大约一年左右，当时几乎没有人或者没多少人使用智能体来写代码。我认为你会进入一种状态，即你与一个或几个——比如一小撮——智能体深度交互（in the loop），发现自己不断地在琢磨、试图理解你的智能体正在做什么，而且你非常、非常地深度参与其中。"
  },
  {
    "i": 13,
    "speaker": "Lauren Tan",
    "text": "你在盯着每一个输出结果。你就坐在那里写提示词，你真的无法在此基础上实现并行化，因为你不信任，对吧？你不可能"
  },
  {
    "i": 14,
    "speaker": "Lauren Tan",
    "text": "一下子扩展到 100 个智能体，比如生成 100 个智能体，当你连一个智能体的输出都不信任的时候。"
  },
  {
    "i": 15,
    "speaker": "Lauren Tan",
    "text": "所以，在过去的 5 个月里，我觉得我确实已经爬升了这条信任曲线，现在我已经到了这样一个阶段：呃，说实话这听起来有点吓人，而且让我听起来像个摇滚明星，但我保证我不是。"
  },
  {
    "i": 16,
    "speaker": "Lauren Tan",
    "text": "但现在我的智能体确实会自动为我合并 PR（拉取请求），呃，说这话挺疯狂的，但嗯，比如我今天早上醒来，发现已经有大约 20 个 PR 合入了，我只是在主干分支上审查了一下，它们已经合入完毕。"
  },
  {
    "i": 17,
    "speaker": "Lauren Tan",
    "text": "而且质量很好。呃，那么，我是怎么达到这个阶段的呢？这基本上就是我今天想聊的原因。再次强调，Colin，如果你有问题，随时可以插话。呃，哦，对，我当然得展示这张图表。"
  },
  {
    "i": 18,
    "speaker": "Lauren Tan",
    "text": "呃，从“不信任某人请求控制我的电脑”到……可能不会那么做。呃，对，所以我认为我分享这张图表不是为了炫耀，而是为了展示这段历程。"
  },
  {
    "i": 19,
    "speaker": "Lauren Tan",
    "text": "你可以看到这条曲线，它大致与我能够在 Cursor 上合入的贡献量呈反向匹配关系。所以，我是 5 个月前加入的。5 个月前，你知道，第一个月我效率不高，因为我在熟悉代码库。"
  },
  {
    "i": 20,
    "speaker": "Lauren Tan",
    "text": "完全不知道发生了什么。随着我对智能体越来越有信心，我的生产力确实大幅提升。呃，再说一次，上个月我发布了 1,000 个 PR，这简直离谱。"
  },
  {
    "i": 21,
    "speaker": "Lauren Tan",
    "text": "呃，然后这个月才到 12 号，我已经差不多合并了 800 个 PR。呃，所以速度确实很高。而且你会分享很多，你肯定会质疑这些代码中有多少实际上是好的。"
  },
  {
    "i": 22,
    "speaker": "Lauren Tan",
    "text": "而且我认为，是的，对此提出质疑绝对是合理的。嗯，不过是的，我认为如果你把智能体搭建得好，绝对能达到非常相似的水平。嗯，所以我将谈谈我们是如何做到这一点的。"
  },
  {
    "i": 23,
    "speaker": "Lauren Tan",
    "text": "嗯，对我来说，我觉得我很好奇，我想 Colin，你的经验也是，但对我来说，我认为当你与智能体合作时，你应该在工具箱中拥有的最重要的技能是验证。"
  },
  {
    "i": 24,
    "speaker": "Lauren Tan",
    "text": "呃，我所说的验证是指智能体能够实际运行代码、获取 CPU 轨迹或堆快照，或者你知道的，打开 iOS 模拟器等等。无论你的应用如何向用户暴露接口，它都能做同样的事情，真正运行并测试和验证其是否有效。"
  },
  {
    "i": 25,
    "speaker": "Lauren Tan",
    "text": "因为这才是真正能闭环的关键。呃，它并不能保证你的智能体写出优秀的代码，但它至少能让它们写出正确的代码，这其实意义重大。迈出一步，以便能够信任你的智能体。"
  },
  {
    "i": 26,
    "speaker": "Lauren Tan",
    "text": "嗯，我可以分享一个我们在 Cursor 里的例子，哎呀，让我打开这个。让我把它放大一点。呃，让我切换到全屏。"
  },
  {
    "i": 27,
    "speaker": "Speaker 1",
    "text": "搞定。"
  },
  {
    "i": 28,
    "speaker": "Lauren Tan",
    "text": "呃，所以关于 Cursor 的智能体窗口，这其实是个有趣的故事。但嗯，当我五个月前加入 Cursor 时，他们实际上……嗯，我本该加入另一个团队。"
  },
  {
    "i": 29,
    "speaker": "Lauren Tan",
    "text": "我原本应该加入云智能体团队。呃，但因为我有很多使用 React 和智能体开发 Agent Window（一个 React 应用）的经验，所以我被要求基本上协助……"
  },
  {
    "i": 30,
    "speaker": "Lauren Tan",
    "text": "呃，智能体窗口的工作。呃，但是嗯，并没有太多像技能这样的东西来帮助我。所以，我突然意识到，好吧，Agent Swarm 大概一周后就要上线了。"
  },
  {
    "i": 31,
    "speaker": "Lauren Tan",
    "text": "好吧，我们的截止日期非常紧。然后嗯，你知道的，我就坐在那里想，好吧，我要打开 Chrome DevTools 的性能面板，抓取一个追踪记录，自己看看，试着理解这个火焰图。"
  },
  {
    "i": 32,
    "speaker": "Lauren Tan",
    "text": "请记住，我当时才入职第一周。所以，我完全不知道自己在看什么，也不知道……呃，我的意思是，我有点概念，但你知道，这个代码库对我来说完全是陌生的。"
  },
  {
    "i": 33,
    "speaker": "Lauren Tan",
    "text": "呃，我意识到我的智能体也一无所知，你知道的，比如我会截个图，试图下载追踪记录或发给它，然后说，“嗯，它看起来大概是这样。”呃，然后它会自信满满地断定这就是那个问题。"
  },
  {
    "i": 34,
    "speaker": "Lauren Tan",
    "text": "然后我试着去修复它。结果发现那根本不是真正的问题所在。所以，这是一个非常非常缓慢的过程。"
  },
  {
    "i": 35,
    "speaker": "Lauren Tan",
    "text": "如果你曾经自己做过任何性能优化工作，或者你知道，只是用智能体进行开发，而你缺乏验证能力，那么你就是验证者。好吧，你才是瓶颈。你告诉你的智能体去做某事，然后它就去写一些代码。"
  },
  {
    "i": 36,
    "speaker": "Lauren Tan",
    "text": "然后你打开你的……你知道的，本地开发构建，然后你开始说，“哦，你知道，它不起作用。”然后你得复制粘贴屏幕……你知道，截图或控制台错误之类的。"
  },
  {
    "i": 37,
    "speaker": "Lauren Tan",
    "text": "呃，然后你的智能体会慢慢地……你知道的，处理这些信息，然后试图理解并修复问题。但你始终处于循环中，成为瓶颈。所以，根本无法并行处理。"
  },
  {
    "i": 38,
    "speaker": "Lauren Tan",
    "text": "所以，glass 是我为 Cursor 构建的最早的技能之一。呃，顺便说一下，Glass 是我们内部对 Agent Window 使用的代号，但它其实就是 Cursor，我想。"
  },
  {
    "i": 39,
    "speaker": "Lauren Tan",
    "text": "嗯，所以这个技能……我想代码本身是……非常有趣。你的智能体可以非常轻松地为你创建一个。呃，如果你正在构建一个 Electron 应用或 Web 应用，或者"
  },
  {
    "i": 40,
    "speaker": "Lauren Tan",
    "text": "甚至是 iOS 应用程序，你可以教你的智能体如何使用 Chrome DevTools 协议，或者通过 Apple 的一些实用工具来运行模拟器、捕获追踪数据并进行程序化控制。"
  },
  {
    "i": 41,
    "speaker": "Lauren Tan",
    "text": "呃，这真的很有用。呃，但有一件事我实际上想谈谈，就是那个东西。呃，readme 在哪里？"
  },
  {
    "i": 42,
    "speaker": "Lauren Tan",
    "text": "呃，所以这个技能带有一个非常独特的文件，叫做 feature map（功能地图），或者说还不是一个功能，而是一个独特的文件。"
  },
  {
    "i": 43,
    "speaker": "Lauren Tan",
    "text": "所以故事是这样的：我构建了这项技能，因此智能体能够实际运行 Agent Window 并捕获追踪数据等等。呃，但它完全不知道 Agent Window 是什么。"
  },
  {
    "i": 44,
    "speaker": "Lauren Tan",
    "text": "所以，你知道，就像有人说哦，左侧边栏有点卡顿之类的。或者你知道，右侧的 PR 标签页不工作。而智能体就会手忙脚乱地瞎忙活。它会花大量时间试图查找代码，你知道，这个功能在哪里？"
  },
  {
    "i": 45,
    "speaker": "Lauren Tan",
    "text": "我实际上如何在 UI 上找到它？这使得它基本上完全没用。呃，你知道，我会本地运行这个技能，它会生成一个开发构建版本，但然后它就会空转，就像我只是尝试"
  },
  {
    "i": 46,
    "speaker": "Lauren Tan",
    "text": "点击这里。它不知道如何找到这些东西。嗯，那简直是一次糟糕透顶的体验。呃，所以是谁在我的屏幕上画箭头的？"
  },
  {
    "i": 47,
    "speaker": "Lauren Tan",
    "text": "嗯，所以呃，是的，这个功能地图真的很有用，因为它教会智能体如何访问你拥有的所有功能。"
  },
  {
    "i": 48,
    "speaker": "Lauren Tan",
    "text": "嗯，在 P Stack 中，我制作的那个插件，如果你在 Google 上搜索“P Stack cursor”，就能找到它。"
  },
  {
    "i": 49,
    "speaker": "Lauren Tan",
    "text": "嗯，但该插件中有一个创建验证技能的功能，它实际上能帮你为自己设置类似这样的东西。"
  },
  {
    "i": 50,
    "speaker": "Lauren Tan",
    "text": "嗯，包括功能地图，所以它实际上会探索代码并构建这个初始功能地图，告诉你的智能体如何访问你拥有的所有不同功能。"
  },
  {
    "i": 51,
    "speaker": "Lauren Tan",
    "text": "呃，这非常强大，因为现在有了这些用户报告进来，你甚至可以映射像模糊的报告甚至截图这样的内容。"
  },
  {
    "i": 52,
    "speaker": "Lauren Tan",
    "text": "所以我们在 Cursor 内部有一个 Slack 频道，你知道，很多人在那里给我们反馈关于智能体窗口、侧边栏等等的问题。"
  },
  {
    "i": 53,
    "speaker": "Lauren Tan",
    "text": "呃，而且很多时候报告质量很差，像非常低的质量，比如有人只是发了一张截图，然后说这是什么？这是什么？什么，就像这是什么？你知道，如果没有这个，你的智能体会说，“我完全没头绪。”"
  },
  {
    "i": 54,
    "speaker": "Lauren Tan",
    "text": "对吧？但有了像这样的功能地图，它就有更多的上下文和理解力，知道如何实际导航，如何访问所有不同的功能。呃，所以比如，你知道，举个例子，比如侧边栏，侧边栏是什么？"
  },
  {
    "i": 55,
    "speaker": "Lauren Tan",
    "text": "呃，你知道，里面存在的所有不同子功能。嗯，从用户的角度来看，这是访问它的方法，所有不同的键盘快捷键。"
  },
  {
    "i": 56,
    "speaker": "Lauren Tan",
    "text": "呃，甚至像……你叫什么来着？DOM 元素，或者对，像通过 CDP 选择事物时使用的属性，全都包含在内。所以呃，再说一次，是的，这对智能体来说真的、真的很强大。"
  },
  {
    "i": 57,
    "speaker": "Lauren Tan",
    "text": "而呃，以及创建验证技能的能力，还有维护验证技能的能力。呃，这样你就可以保持它实时更新。"
  },
  {
    "i": 58,
    "speaker": "Speaker 1",
    "text": "酷。是的，我正要问你是怎么创建那个的。那么，你介意在 P stack 的背景下多分享一点这个过程吗？"
  },
  {
    "i": 59,
    "speaker": "Lauren Tan",
    "text": "也许还可以给那些不熟悉的人简单介绍一下 P stack 是什么。是的，所以 P stack 挺有意思的，因为呃首先，这个名字有点滑稽。"
  },
  {
    "i": 60,
    "speaker": "Lauren Tan",
    "text": "就像 P stack 里的 P 指的是土豆袋（potato sack）。嗯，因为呃有一个相当出名的人，Garry Tan，他是 Y Combinator 的 CEO。"
  },
  {
    "i": 61,
    "speaker": "Lauren Tan",
    "text": "他搞出了一个叫 G stack 的插件。呃，Garry stack。而有趣的是，我们同姓。但我们没有任何亲属关系。"
  },
  {
    "i": 62,
    "speaker": "Lauren Tan",
    "text": "呃，但我觉得开个玩笑挺好玩的，你知道，调侃一下 Gary，把 P stack 做成我版本的他的插件。呃，但主要是为了适应我自己的一套实用工程实践。"
  },
  {
    "i": 63,
    "speaker": "Lauren Tan",
    "text": "呃，但我老实说，最初根本没打算去构建 P stack。呃，它只是从一堆技能开始的。明白吗？比如我从那个控制类技能开始。"
  },
  {
    "i": 64,
    "speaker": "Lauren Tan",
    "text": "然后我又开始了另一个叫 how 的技能，这也是我通过观察智能体注意到的。嗯，就像你知道的，在我早期试图在这条职业阶梯上攀爬的时候，我完全沉浸其中。"
  },
  {
    "i": 65,
    "speaker": "Lauren Tan",
    "text": "我当时基本上对我的智能体进行了极其严苛的挑剔。我会告诉它，你知道，这个功能停止工作了。这是一个错误报告。就像，为什么它不工作？"
  },
  {
    "i": 66,
    "speaker": "Lauren Tan",
    "text": "而很多时候，智能体会非常自信地断言说：“哦，肯定是这个原因，对吧？一定是这个东西。”我注意到，当我查看实际的工具调用时，我发现它并没有真正读取它们应该使用的代码。"
  },
  {
    "i": 67,
    "speaker": "Lauren Tan",
    "text": "这让我变得极度怀疑。到了那个阶段，我就想，我再也不会信任任何智能体了，因为它们完全是在幻觉。"
  },
  {
    "i": 68,
    "speaker": "Lauren Tan",
    "text": "我认为，很容易建立起这种不信任感，并且感到无助，就像你知道的，你不知道如何帮助你的智能体取得成功。"
  },
  {
    "i": 69,
    "speaker": "Lauren Tan",
    "text": "但再次强调，我认为管理的类比非常有用，因为想象一下，如果你是工程团队的管理者，而你团队里有一位工程师，他编码能力很强，但完全没有业务背景，你知道，你刚刚雇佣了他，他才刚入职，就在五秒钟前。"
  },
  {
    "i": 70,
    "speaker": "Lauren Tan",
    "text": "那么，你实际上如何教导这个人变得高效呢？你通过技能来实现这一点。嗯，技能就是，你知道，它只是 Markdown，对吧？但你知道，它编码了大量的信息、指令，你可以从中引出大量的……"
  },
  {
    "i": 71,
    "speaker": "Lauren Tan",
    "text": "通过良好的方式，你可以从智能体中激发出很多智能，有些人会在 Twitter 上称之为，你知道，将智能体拉入不同的潜在空间。"
  },
  {
    "i": 72,
    "speaker": "Lauren Tan",
    "text": "这其实是一种花哨的说法，意思是既然你知道，LLM 某种程度上是在预测下一个 token。"
  },
  {
    "i": 73,
    "speaker": "Lauren Tan",
    "text": "嗯，当你一开始给它一些高质量的 token 时，那么，你知道，它可以在一个更高、更聪明的空间中进行模式匹配。嗯，所以这是一个非常有趣的模型。"
  },
  {
    "i": 74,
    "speaker": "Lauren Tan",
    "text": "但是的，我非常渐进地构建了 P stack。呃，所以起初我只是在观察智能体，你知道的，观察这些智能体出现的各种失败模式。每次看到这种情况，我就想，好吧，那我就把它做成一个技能。"
  },
  {
    "i": 75,
    "speaker": "Lauren Tan",
    "text": "比如，停止幻觉，实际去搜索一下查一下代码。大量使用子智能体。呃，还有，停止瞎猜。是的，这很有道理。"
  },
  {
    "i": 76,
    "speaker": "Speaker 1",
    "text": "这里有一个跟进问题，既来自我自己，也来自聊天室里的一群人。所以我猜它包含两个部分。第一部分是，你如何维护这些技能？因为产品会随时间变化。显然有很多人在针对代码库进行开发并发布功能。"
  },
  {
    "i": 77,
    "speaker": "Speaker 1",
    "text": "那么这些技能是如何得到维护的？其次，你如何知道你的验证已经足够好了？比如，你知道你可以信任你构建的验证循环，我猜你是相信当它们完成时，任务就结束了。"
  },
  {
    "i": 78,
    "speaker": "Lauren Tan",
    "text": "是的，也许我会谈谈我认为相关的内容。也许我先从这个问题开始。那么，我如何维护这些技能？"
  },
  {
    "i": 79,
    "speaker": "Lauren Tan",
    "text": "如果你不熟悉这个概念，eval（评估） 本质上是一种方式，我认为我的心理模型是，它就像智能体的单元测试。而且你实际上可以自己制作评估。你不需要像那种特殊的框架来做它们。"
  },
  {
    "i": 80,
    "speaker": "Lauren Tan",
    "text": "你可以构建，你可以，你可以根据你想要多么科学和严谨来构建一个。"
  },
  {
    "i": 81,
    "speaker": "Speaker 1",
    "text": "我的屏幕是红色的。是的，有个小按钮。"
  },
  {
    "i": 82,
    "speaker": "Lauren Tan",
    "text": "抱歉。你是禁用了绘图功能还是什么？"
  },
  {
    "i": 83,
    "speaker": "Speaker 1",
    "text": "我看不到我的屏幕。是的，抱歉。如果你们能不在屏幕上绘图那就太好了，但有个小按钮在……是的，那个小下拉菜单里。我喜欢清除。是的。好的，是的。明白了。"
  },
  {
    "i": 84,
    "speaker": "Speaker 1",
    "text": "完美。"
  },
  {
    "i": 85,
    "speaker": "Lauren Tan",
    "text": "嗯，是的，所以评估基本上是一种对技能进行单元测试的方式。"
  },
  {
    "i": 86,
    "speaker": "Lauren Tan",
    "text": "实际上在 Pystack 中，我们在 pilot 模式下发布了一个 playbook，如果你搜索的话，叫做 eval playbook。它是呃，它其实做得相当相当严谨。"
  },
  {
    "i": 87,
    "speaker": "Lauren Tan",
    "text": "但是嗯，本质上我所做的是生成许多不同的子智能体。我让我的主要协调智能体制定一个关于我希望技能做什么的评分标准。"
  },
  {
    "i": 88,
    "speaker": "Lauren Tan",
    "text": "嗯，然后它会生成所有这些子智能体，并为它们创建单独的目录，这些目录的命名很巧妙，不会让子智能体知道它正在被评估，因为智能体确实能察觉出来，一旦察觉到，它们就会改变行为。"
  },
  {
    "i": 89,
    "speaker": "Lauren Tan",
    "text": "呃，但它会做很多类似的事情，基本上是的，就像测试我创建或修改的技能是否真的在做我认为它在做的事情。嗯，Cursor 的一个真正棒的地方是，我们支持非常多的不同模型。"
  },
  {
    "i": 90,
    "speaker": "Lauren Tan",
    "text": "所以你可以实际上在各种不同的模型上评估你的技能。嗯，你知道的，了解一下它在不同矩阵中的表现如何。嗯，特别是对于你使用的那些模型。呃，所以我经常这样做。"
  },
  {
    "i": 91,
    "speaker": "Lauren Tan",
    "text": "每次我修改一个技能时，我都会运行其中一个。呃，比如评估 playbook，并确保你知道，它确实能产生我想要的结果。呃，但我要说，维护技能实际上相当困难。"
  },
  {
    "i": 92,
    "speaker": "Lauren Tan",
    "text": "呃，我认为这需要很多品味和观察力。所以你某种程度上需要非常擅长当个副驾指挥（backseat driver）。你懂我意思吗？"
  },
  {
    "i": 93,
    "speaker": "Lauren Tan",
    "text": "就像如果你做过结对编程，比如你看着同事写代码，你就会觉得，你可能能做得更好。你知道的，你会想，你为什么没这么做呢，对吧？你会问你的同事很多问题。"
  },
  {
    "i": 94,
    "speaker": "Lauren Tan",
    "text": "这里的情况有点类似。你不希望只是被动地观察智能体。在初期构建你自己的技能集时，你希望非常掌控局面，坐在驾驶座上。"
  },
  {
    "i": 95,
    "speaker": "Lauren Tan",
    "text": "呃，你知道，显然你可以使用像 Pystack 这样的东西，但如果你正在构建自己的技能集，我认为打开所有的工具调用，阅读代码，阅读所有智能体行为及其思考块，是查看它们在哪里失败的一个非常好的方法，对吧？"
  },
  {
    "i": 96,
    "speaker": "Lauren Tan",
    "text": "比如，你知道的，它们在哪些方面表现不佳？然后你可以去为那个方面构建一个技能。"
  },
  {
    "i": 97,
    "speaker": "Lauren Tan",
    "text": "接着是关于验证的部分，你的测试方式——我认为这同样是一个类似的迭代循环，你知道的，就像我实际上对验证技能本身进行验证时，采用了完全相同的过程，我当时……"
  },
  {
    "i": 98,
    "speaker": "Lauren Tan",
    "text": "所以，评估（evals）有一件有趣的事情，就是你可以对它进行某种程度的爬山优化（hill climb），意思是你的评估可以产生一个分数，对吧？"
  },
  {
    "i": 99,
    "speaker": "Lauren Tan",
    "text": "呃，一个让你的协调者产生的分数，但此外，你也可以使用另一个不同模型的裁判智能体来交叉参考，确保第一个模型没有偏见，对吧？这个模型负责评判所有正在运行任务的子智能体。"
  },
  {
    "i": 100,
    "speaker": "Lauren Tan",
    "text": "呃，但你也同样可以进行爬山优化。"
  },
  {
    "i": 101,
    "speaker": "Lauren Tan",
    "text": "所以，这意味着你可以使用 Cursor 中的 /loop 功能，然后说：‘好的，继续在这个评估上循环迭代，对吧？’直到所有项目都达到满分 10 分。’作为一个例子。"
  },
  {
    "i": 102,
    "speaker": "Lauren Tan",
    "text": "呃，我在控制技能上也基本采用了同样的方法。所以，整个过程其实非常……实际上是非常放手的。呃，所以，你知道的，我呃我就是那样构建了那个技能，比如其中的命令行界面（CLI）。"
  },
  {
    "i": 103,
    "speaker": "Lauren Tan",
    "text": "嗯，随着时间的推移，它的表现变得非常好。呃，但是的，一开始肯定不是很顺利。它需要大量的迭代。我觉得这里有一个类比，就是……嗯，我在后面另一张幻灯片上的手绘图中也做了这个类比。"
  },
  {
    "i": 104,
    "speaker": "Lauren Tan",
    "text": "呃，但我把它想象成……你知道的，作为一名工程师，你现在更像是一个管理者，或者我喜欢的类比是，你就像餐厅里的主厨。呃，你知道，你是主厨。你不再亲自烹饪所有的食物了。"
  },
  {
    "i": 105,
    "speaker": "Lauren Tan",
    "text": "你有一支厨师团队，对吧？你有线厨（line cooks），有副主厨（sous chef），还有你知道的，所有这些不同的岗位。嗯，你的工作就是设置环境。"
  },
  {
    "i": 106,
    "speaker": "Lauren Tan",
    "text": "你知道的，你负责搭建厨房。你负责给不同的人分配任务。所以嗯，是的，这是一种非常有趣的工作方式。呃，但没错，这就是我基本上构建这些验证技能的方式。"
  },
  {
    "i": 107,
    "speaker": "Speaker 1",
    "text": "是的，我只有一个想法，我想再深入一层。所以，假设我们想为某件事构建一个评估或技能，并且希望它能自我改进，这正是我认为你建议的方向。"
  },
  {
    "i": 108,
    "speaker": "Speaker 1",
    "text": "呃，你是像在隔离的工作树中那样做的吗？比如使用子智能体和评审智能体等？这是在某种云托管环境中进行的吗？更实际的步骤是什么？如果我想去做这件事，并为某事设置一个验证系统，"
  },
  {
    "i": 109,
    "speaker": "Speaker 1",
    "text": "我该怎么做，或者从哪里开始？"
  },
  {
    "i": 110,
    "speaker": "Lauren Tan",
    "text": "嗯，我认为最好的开始方式是本地运行，因为你可以观察。你绝对可以观察到你的智能体在做什么。"
  },
  {
    "i": 111,
    "speaker": "Lauren Tan",
    "text": "所以，如果你是在为自己构建一个验证技能，我肯定会从本地开始，让你的智能体启动应用程序，无论是命令行界面、桌面应用还是其他什么。这样你就可以实际观察，对吧？"
  },
  {
    "i": 112,
    "speaker": "Lauren Tan",
    "text": "你可以看到智能体是如何与应用程序交互的。你可以看到它如何调用不同的 API 来与应用程序交互。嗯，但就我个人而言，我基本上已经全面转向云智能体，因为它们非常强大。"
  },
  {
    "i": 113,
    "speaker": "Lauren Tan",
    "text": "呃，Cursor 真正强大的地方在于"
  },
  {
    "i": 114,
    "speaker": "Lauren Tan",
    "text": "实际上是云智能体，如果你花一点时间设置环境，这些控制技能、验证技能会带来巨大的回报。因为这不仅仅是让你作为单个工程师变得更好，它实际上提升了你整个团队，甚至整个公司的水平，因为你可以开始思考云智能体，并开始思考自动化流程，让它们自动执行诸如……我会深入讲解……比如我经常提到的那个叫 Benny 的智能体，对吧？"
  },
  {
    "i": 115,
    "speaker": "Lauren Tan",
    "text": "就是那个……你知道的，接收我们收到的所有 bug 报告，然后自动在云端运行，打开一个云桌面……"
  },
  {
    "i": 116,
    "speaker": "Lauren Tan",
    "text": "桌面环境，它在自己的计算机上运行 Cursor，并使用相同的控制技能与应用交互，尝试复现 bug 或用户报告的问题，对吧？这非常强大，因为我可以立即从中自动获取大量信息。"
  },
  {
    "i": 117,
    "speaker": "Lauren Tan",
    "text": "比如在这个例子中，你可以看到 Benny 确实复现了 bug，但它在 main 分支上已经被修复了。"
  },
  {
    "i": 118,
    "speaker": "Lauren Tan",
    "text": "所以，它实际上确认了我们已经修复了这个问题，我只需要再发布一个 Cursor 版本即可。"
  },
  {
    "i": 119,
    "speaker": "Lauren Tan",
    "text": "嗯，这提供了巨大的信息价值，我不必亲自去盯着智能体，花一个小时去搞清楚这个问题是修好了还是没修好。所以，你可以节省大量时间，而且我团队里的每个人都能从中受益。"
  },
  {
    "i": 120,
    "speaker": "Lauren Tan",
    "text": "公司里的每个人都能从中受益。嗯，所以绝对认为使用云智能体是非常强大的。嗯，但这就像一段旅程。你必须先信任它，对吧？"
  },
  {
    "i": 121,
    "speaker": "Lauren Tan",
    "text": "在达到这个阶段之前，这回到了我之前说的观点：非常困难，几乎不可能，我强烈建议不要试图从……比如如果你还在这个阶段，不要一下子跳到‘我现在要生成一百或一千个云智能体’……"
  },
  {
    "i": 122,
    "speaker": "Lauren Tan",
    "text": "因为你只会浪费大量 token，而且成本会极其高昂。"
  },
  {
    "i": 123,
    "speaker": "Speaker 1",
    "text": "好的，所以到目前为止简单总结一下，基本上如果我们想走你走过的这段旅程，那就是从验证开始，构建一些技能和确定智能体是否至少产出了正确代码的方法，或者如你所言，代码质量好坏可能是另一个问题，但从技术角度看，它是通过查看堆栈跟踪、观察应用中的实际行为等方式来解决问题的。"
  },
  {
    "i": 124,
    "speaker": "Speaker 1",
    "text": "一旦我们在本地信任了它，就可以开始考虑扩展到云端，运行更多能够自主捕捉信号的智能体，对吧？所以，无论是……"
  },
  {
    "i": 125,
    "speaker": "Speaker 1",
    "text": "进来的 bug 报告或其他事项，它们可以去处理并解决问题，然后给我们返回一个 PR。那么最后一步可能是自动合并 PR，这就是你目前的阶段。也许不是每个人的阶段。"
  },
  {
    "i": 126,
    "speaker": "Speaker 1",
    "text": "是的，是的。然后在主分支上审查它们，这大概对吗？"
  },
  {
    "i": 127,
    "speaker": "Lauren Tan",
    "text": "是的，完全正确。我想是的，这就是为什么我画了这条曲线，对吧？因为这基本上描述了我的历程：你知道，刚开始时我只能勉强使用几个智能体，并且我在观察每一件事。"
  },
  {
    "i": 128,
    "speaker": "Lauren Tan",
    "text": "我认为从这一步到那一步真的没有捷径，因为这实际上关乎你对智能体的个人信任程度。对吧？嗯，显然，你知道，作为一名工程师，你不想把粗糙的代码直接部署到生产环境。"
  },
  {
    "i": 129,
    "speaker": "Lauren Tan",
    "text": "那么，你实际上如何建立这种信任呢？这需要……嗯，很多……我想是品味和判断力。嗯，但是……你知道，像 Pstack 这样的插件确实能帮助你更快地上手。"
  },
  {
    "i": 130,
    "speaker": "Lauren Tan",
    "text": "呃，所以，我想这就像是如果你信任我，并且信任 Pstack，那么通过这种延伸，你可能也能信任你的智能体。但如果你不信任我，而且我绝对不鼓励人们盲目信任我。"
  },
  {
    "i": 131,
    "speaker": "Lauren Tan",
    "text": "呃……你知道，如果你建立了一套自己的技能集，你显然可以查看 Pstack 并对其进行分叉，使其成为你自己的东西，改进这些技能，我绝对鼓励这样做。"
  },
  {
    "i": 132,
    "speaker": "Lauren Tan",
    "text": "呃，但对我来说，这真的全都归结为信任。你知道，我们在这个聊天中的每个人对工程都有不同的标准。呃，在我们的代码库中，对我们来说重要的事情也各不相同。"
  },
  {
    "i": 133,
    "speaker": "Lauren Tan",
    "text": "而当你能够把所有这些都编码成技能，并且可以验证你的智能体确实在执行它们时，这就能让你真正沿着这条曲线上升。然后……嗯……你知道，开始自动化这些事情。"
  },
  {
    "i": 134,
    "speaker": "Lauren Tan",
    "text": "嗯，还有另一部分我想谈谈，如果有的话 好的，请说。我会随着进行提出更多问题，但 是的，我认为这其中还有第三部分我还没谈到，这是一个有点有趣的部分，就是关于重构和重写。"
  },
  {
    "i": 135,
    "speaker": "Lauren Tan",
    "text": "比如，我想行业内最具争议的话题之一，可能就是你是否应该重写你的应用？"
  },
  {
    "i": 136,
    "speaker": "Lauren Tan",
    "text": "嗯，因为我觉得工程师很容易陷入这种思维，特别是当你加入一家公司时，你进来看到代码库，心里想：\"天哪，这代码是谁写的？\"你知道的，太糟糕了。我想把整个东西重写一遍。"
  },
  {
    "i": 137,
    "speaker": "Lauren Tan",
    "text": "这是一种非常普遍的倾向，我认为很多人知道，在智能体出现之前，甚至可以说现在也是，人们肯定会劝你不要重写这些东西。但我其实是来论证为什么你可能需要考虑重写的。"
  },
  {
    "i": 138,
    "speaker": "Lauren Tan",
    "text": "嗯，因为我觉得这真的要看情况。"
  },
  {
    "i": 139,
    "speaker": "Lauren Tan",
    "text": "呃，你知道，对于已有系统（brownfield applications）来说，我认为它们其实处于一个相当不错的位置，特别是如果它们已经搭建得很好的话。"
  },
  {
    "i": 140,
    "speaker": "Lauren Tan",
    "text": "呃，最近我和一些人聊过，我只是在观察。我刚刚注意到这个平行现象，就是很多大型科技公司的难题现在变成了所有人的难题。"
  },
  {
    "i": 141,
    "speaker": "Lauren Tan",
    "text": "嗯，而大型科技公司的难题，你知道，比如我在 Meta 工作的时候，我们有一个巨大的单体仓库（monorepo）。我们有，我不知道，成千上万的工程师，只是你知道的，不停地敲"
  },
  {
    "i": 142,
    "speaker": "Lauren Tan",
    "text": "键盘并发布代码。Meta 有很多非常优秀的工程师，但我会说，你可能会惊讶地发现代码质量其实并没有那么好。"
  },
  {
    "i": 143,
    "speaker": "Lauren Tan",
    "text": "嗯，所以我经常开玩笑说，你知道，在 AI 制造的烂代码之前，我们有的是人类制造的烂代码。"
  },
  {
    "i": 144,
    "speaker": "Lauren Tan",
    "text": "嗯，所以呃，我认为很多大型科技的基础设施，比如 Meta 或 Google 的，你知道，真正的大型科技公司，实际上是为此设计的，也就是说你是在迎合……这听起来很糟糕，但就是你们团队中能力最弱的工程师，对吧？"
  },
  {
    "i": 145,
    "speaker": "Lauren Tan",
    "text": "你构建框架，你建立规范，你设置护栏，你知道的，限制权限，这样你的实习生就不会把生产数据库删掉。嗯，如果你已经有那样的基础设施，我认为你的智能体其实已经能做得非常扎实了。"
  },
  {
    "i": 146,
    "speaker": "Lauren Tan",
    "text": "对吧？因为护栏已经就位，防止智能体在你的代码库中造成混乱或不至于造成太大混乱。嗯，而且你总是可以添加更多的护栏。"
  },
  {
    "i": 147,
    "speaker": "Lauren Tan",
    "text": "呃，但我觉得，从零开始的应用（greenfield applications），尤其是全新的应用，在我看来风险最大。呃，同时也是最大的机会。"
  },
  {
    "i": 148,
    "speaker": "Lauren Tan",
    "text": "因为，你知道的，如果你为一个项目写代码、做一个原型，就像我们为 Grokbot 做的那样，Grokbot 启动得非常非常快。"
  },
  {
    "i": 149,
    "speaker": "Lauren Tan",
    "text": "嗯，如果你没听说过 Grokbot，这是我们昨天刚发布的新应用。呃，它真的很酷。呃，它让你可以编排智能体，比如那些拥有独立身份的智能体，你可以对它们进行编排。"
  },
  {
    "i": 150,
    "speaker": "Lauren Tan",
    "text": "超级酷，一定要去看看。嗯，但没错，那是一个典型的从零开始的应用，就像大多数原型一样。所以它是通过 vibe coding 非常快速地写出来的。"
  },
  {
    "i": 151,
    "speaker": "Lauren Tan",
    "text": "人类根本没有阅读代码。呃，我最近发了一条推文，提到了关于有机架构（organic architecture）的一些想法。嗯，也许我能找到它。"
  },
  {
    "i": 152,
    "speaker": "Lauren Tan",
    "text": "呃，但核心思想是，当你有一个完全通过 vibe coding 构建的应用时，你基本上没有任何护栏。所以，当你给智能体分配任务时，它们只会用最方便的方法来解决它。"
  },
  {
    "i": 153,
    "speaker": "Lauren Tan",
    "text": "随着时间的推移，你会陷入这样一种境地：由于你不理解代码库，它开始失控。嗯，你的智能体在某种程度上理解它，但它们构建的东西是为了走捷径而优化的。"
  },
  {
    "i": 154,
    "speaker": "Lauren Tan",
    "text": "嗯，你知道，你会受苦，那个应用会有很多问题的。所以，我认为从一开始就为代码库设置非常强的护栏是非常必要的。因为当你拥有一个值得信赖的代码库时，对吧？"
  },
  {
    "i": 155,
    "speaker": "Lauren Tan",
    "text": "当你的护栏实际上能帮助你的智能体时，对吧？好代码。你可以进入曲线的这一部分，就像我之前说的，我今天醒来时发现我的智能体已经合并了20个PR。"
  },
  {
    "i": 156,
    "speaker": "Lauren Tan",
    "text": "这是因为我在将GrokBot重构为我一直在构建的新架构时投入了大量时间，我昨天计算过，超过600个PR。嗯，是的，我已经到了一个不再需要查看代码的地步。"
  },
  {
    "i": 157,
    "speaker": "Lauren Tan",
    "text": "我说这个不仅仅是为了卖token给你，而是因为确实花了很多token才让代码库达到这种我不再需要查看它的状态。但我非常兴奋，因为你知道，这不仅仅对我有利。"
  },
  {
    "i": 158,
    "speaker": "Lauren Tan",
    "text": "它对所有为GrokBot做出贡献的人都有利。它还赋能设计师、产品经理，甚至GTM人员为GrokBot添加功能。我不必担心，不必半夜醒来担心有人刚刚合并了一个性能回归的问题。"
  },
  {
    "i": 159,
    "speaker": "Lauren Tan",
    "text": "对吧？我有很多约束，CI实际上让在GrokBot中写代码变得非常烦人，但智能体吸收了所有这些烦恼。嗯，是的，我很乐意谈谈具体是什么情况。嗯 是的，我想问一个问题是的。"
  },
  {
    "i": 160,
    "speaker": "Speaker 1",
    "text": "在深入这部分之前，我想先了解一下你们的 CI（持续集成）流程是什么样的，或者有哪些限制条件，以及平均 PR（Pull Request）的大小。"
  },
  {
    "i": 161,
    "speaker": "Speaker 1",
    "text": "我之前看到过关于这个问题。只是想给大家一个大概的了解。不需要是数学意义上的平均值，只是想知道通常 PR 的大小是怎样的，比如只有几行代码，或者你知道的，对。"
  },
  {
    "i": 162,
    "speaker": "Lauren Tan",
    "text": "嗯，我觉得这要看情况。"
  },
  {
    "i": 163,
    "speaker": "Speaker 1",
    "text": "嗯，也许我试着换种方式问，我不需要 是的，你不必分享具体的数字，如果愿意的话，大概的平均值就行 这样也可以。"
  },
  {
    "i": 164,
    "speaker": "Lauren Tan",
    "text": "基准参考。但是我们有……好吧。这其实没那么有趣，不过有个有趣的事实是，GrokBot 和 Cursor 中的虚拟化功能实际上是由 Pretext 驱动的，这是一个由某人构建的新库。"
  },
  {
    "i": 165,
    "speaker": "Lauren Tan",
    "text": "嗯，这真的很有趣。你应该去看看。但这其实没那么重要。呃，关于平均 PR 大小，我实际上不知道，我可能……我不确定是否想点击这些链接去查。"
  },
  {
    "i": 166,
    "speaker": "Lauren Tan",
    "text": "呃，我大概可以查，但我会说它们的大小范围可以从几十行、50 行到一千行不等，取决于具体在做什么。呃，所以比如这里，我实际上是在删除一堆文件，所以我预计这主要是删除操作。"
  },
  {
    "i": 167,
    "speaker": "Lauren Tan",
    "text": "呃，但总的来说，它确实会有所变化。没有像……是的。"
  },
  {
    "i": 168,
    "speaker": "Speaker 1",
    "text": "对于 50 行左右的 PR，有没有一个硬性上限？"
  },
  {
    "i": 169,
    "speaker": "Lauren Tan",
    "text": "上限。虽然绝对没有硬性上限，但我确实鼓励我的智能体将工作拆分成多个 PR（拉取请求）。"
  },
  {
    "i": 170,
    "speaker": "Lauren Tan",
    "text": "呃，我这么做主要是因为……嗯，我喜欢这个想法。我想也许这在现在更难做到了，因为在智能体的世界里，你会有非常多的提交记录。"
  },
  {
    "i": 171,
    "speaker": "Lauren Tan",
    "text": "但我喜欢这样的理念：你知道的，Git 历史是一个非常丰富的上下文来源。呃，我喜欢每个 PR 都能以原子化的方式描述那一小块内容具体在做什么。"
  },
  {
    "i": 172,
    "speaker": "Lauren Tan",
    "text": "这也让我更容易回滚更改，并且弄清楚，哦，我发布了一个 bug，它就在这里，对吧？而不是埋在一个四万行的 PR 里，谁知道里面到底混进了什么。"
  },
  {
    "i": 173,
    "speaker": "Lauren Tan",
    "text": "呃，不过是的，我对 PR 的大小没有硬性限制。酷。"
  },
  {
    "i": 174,
    "speaker": "Speaker 1",
    "text": "然后，是的，还有一个关于 CI（持续集成）的快速问题。所以，再次说明，你不需要像屏幕共享那样展示你的 CI 具体长什么样，但一般来说，你会如何描述"
  },
  {
    "i": 175,
    "speaker": "Speaker 1",
    "text": "CI 的大致样子，或者它的严格程度？"
  },
  {
    "i": 176,
    "speaker": "Lauren Tan",
    "text": "呃，是的，所以……嗯，具体来说对于 Grokbot，Dune 是我们为 Grokbot 构建的架构的一个有点俏皮的内幕代号。嗯，CI 看起来相当烦人，因为到处都是检查项。"
  },
  {
    "i": 177,
    "speaker": "Lauren Tan",
    "text": "所以，比如字面意义上，我有……嗯，好吧，如果你读过任何 React 相关的资料，你就知道 React 中最大的陷阱之一就是 useEffect。"
  },
  {
    "i": 178,
    "speaker": "Lauren Tan",
    "text": "呃，所以在 Dune 和 Grokbot 中，我们禁用了 useEffect。"
  },
  {
    "i": 179,
    "speaker": "Lauren Tan",
    "text": "所以，Dune……你可以这样理解 Dune 的心智模型：把它想象成是专为 Electron 应用设计的 Next.js，并且它是为智能体编写代码而设计的。"
  },
  {
    "i": 180,
    "speaker": "Lauren Tan",
    "text": "呃，以及它专门为我们由智能体驱动的应用程序定制。嗯，所以 CI 检查项非常针对这些特定规则。比如，你知道的，不要使用 useEffect。它是被禁止的。"
  },
  {
    "i": 181,
    "speaker": "Lauren Tan",
    "text": "比如，CI 会失败呃，然后对你大吼大叫。我们有一些比较有趣的规则，人们可能会对此皱眉，比如我实际上也禁止了代码注释。呃，这非常有趣。"
  },
  {
    "i": 182,
    "speaker": "Lauren Tan",
    "text": "嗯，但我注意到 99% 的情况下，智能体只是写出描述某些历史事件的代码注释，而这些事件实际上与代码完全无关。嗯，比如它经常会说，你知道，“哦，Lauren 说你永远不应该这样做。”"
  },
  {
    "i": 183,
    "speaker": "Lauren Tan",
    "text": "然后这就出现在了代码注释里。我就想，“什么？为什么？我并没有那样说过”作为一个持久的、你知道的，全局规则。我只是想说你的 PR 很烂，你应该修改那部分。"
  },
  {
    "i": 184,
    "speaker": "Lauren Tan",
    "text": "令人惊讶的是，智能体其实并不太理解这一点。呃，或者它们假设得太多，并以非常愚蠢的方式做事。所以，是的，我们只是禁止所有你能想到的智能体做得不好的东西。"
  },
  {
    "i": 185,
    "speaker": "Lauren Tan",
    "text": "呃，所以在智能体窗口中，我们实际上遭受很多的一个例子是，我们有呃，你知道，如果你用过智能体窗口，你肯定见过性能问题，而且你知道，我们一直在努力修复它们。"
  },
  {
    "i": 186,
    "speaker": "Lauren Tan",
    "text": "呃，但这就像是一场无休止的斗争，因为有太多的拉取请求被合并。每一个都可能回退性能、稳定性或可靠性。呃，你知道，智能体窗口还没有这种架构。我计划将这种学习带回去，并在那里重构一切。"
  },
  {
    "i": 187,
    "speaker": "Lauren Tan",
    "text": "呃，但它回退得非常频繁，因为有一个例子是，我们进程之间的隔离非常差。所以，比如在 Electron 上，你有一个渲染线程来渲染你的用户界面。"
  },
  {
    "i": 188,
    "speaker": "Lauren Tan",
    "text": "但你还有一个主线程，可以在上面运行其他代码，你知道的，那些不需要阻塞渲染器的代码。嗯，但我们在区分这些方面做得很差。因此，很多时候你会不小心让代码在渲染线程上运行。"
  },
  {
    "i": 189,
    "speaker": "Lauren Tan",
    "text": "呃，然后突然间你正在与渲染器竞争，你知道，如果你想要 60 FPS，那么每一帧的绘制都必须在 16 毫秒内完成。所以，非常非常小，你知道，每帧的截止时间。"
  },
  {
    "i": 190,
    "speaker": "Lauren Tan",
    "text": "呃，如果你想要一个非常流畅的产品。呃，当你开始构建并引入——不小心引入——你知道的，那些计算量非常大或者 I/O 非常多的东西时，你就会遇到很多卡顿和糟糕的体验。"
  },
  {
    "i": 191,
    "speaker": "Lauren Tan",
    "text": "而且你的帧率真的会大幅下降，你会开始，你知道的，丢帧，出现耗时超过 16 毫秒的长任务，整体体验变得非常卡顿。"
  },
  {
    "i": 192,
    "speaker": "Lauren Tan",
    "text": "所以，我们在构建 Electron 应用过程中学到的所有模式，都已经编码进了这个框架中。这就变成了一种硬性失败。"
  },
  {
    "i": 193,
    "speaker": "Lauren Tan",
    "text": "所以，在 Grokbot 中，我们确实有一个目录结构，包括 electron main、electron renderer，还有，导入检查，我想应该是 CI（持续集成）的一部分，我们会在那里实际检查依赖图，以确保你不会意外地从一个目录向另一个目录导入代码。"
  },
  {
    "i": 194,
    "speaker": "Lauren Tan",
    "text": "嗯，所以这是由 CI 强制执行的，还有 Bobby，也就是我们的 Cursor 代码审查工具，它运行在 CI 上。你知道，在我们的 agents.md 里，到处都是。"
  },
  {
    "i": 195,
    "speaker": "Lauren Tan",
    "text": "嗯，我有个想法，我觉得构建一个好的东西需要多个层次。代码库。嗯，显然代码库是这样的，如果你有这样的架构，非常严格，你知道的，构建功能的方式非常传统。"
  },
  {
    "i": 196,
    "speaker": "Lauren Tan",
    "text": "这可以说是最强、最严格的执行力度，因为智能体非常喜欢复制现有的模式。所以，嗯，Grokbot 中这方面的一个例子是，我们有诸如“功能”这样的概念，还有入口点和转录卡片。"
  },
  {
    "i": 197,
    "speaker": "Lauren Tan",
    "text": "比如，你知道的，聊天窗口里看到的那些卡片。这些大概算是框架里的名词吧。所以创建它们的方式非常传统。比如，一个功能的所有内容都放在单个目录下，作为例子，所有"
  },
  {
    "i": 198,
    "speaker": "Lauren Tan",
    "text": "与该功能相关的代码都存放在同一个目录中。所以，它们全部集中在一个地方。这让事情变得超级简单，你知道的，智能体不需要到处用 grep 搜索并试图搞清楚所有东西都在哪里。"
  },
  {
    "i": 199,
    "speaker": "Lauren Tan",
    "text": "它只需查看该功能，然后想：\"哦，好的，我正在处理 GrokBot 中的引导功能。\"\"我就在这个目录下工作。\"对于 80% 的工作来说，内容大多都封装得很好。"
  },
  {
    "i": 200,
    "speaker": "Lauren Tan",
    "text": "但就像它是专门为，你知道的，最笨的智能体设计的。就像，你根本不需要思考。好的，我在这个框架上的一个关键原则是最短路径就是最佳路径。所以，因为这完全契合智能体喜欢编写代码的方式。"
  },
  {
    "i": 201,
    "speaker": "Lauren Tan",
    "text": "就像，它们真的喜欢走捷径。你知道，它们会找到解决问题的最快方法。所以，为什么不把这种方法变成解决问题的最佳方式呢？所以，我可能不会深入所有具体细节。"
  },
  {
    "i": 202,
    "speaker": "Lauren Tan",
    "text": "而这个框架实际上更像是一系列理念和原则的集合，而不是一个会开源的东西。你可以，你知道的，截个图，如果你愿意的话，然后告诉你的智能体也为你构建类似这样的东西。"
  },
  {
    "i": 203,
    "speaker": "Lauren Tan",
    "text": "嗯，是的，但这真的全都是关于分层的问题。你知道，比如代码库是一个部分，包含功能和目录，还有你知道的，导入那些不应该被导入的阻塞性依赖。但是所有这些都会强制执行，并进行静态分析。"
  },
  {
    "i": 204,
    "speaker": "Lauren Tan",
    "text": "所以，比如有 CI 检查。我们有很多针对我们观察到的不良模式的 lint 规则。编译器诊断。在 bug bot 中还有一些规则，我认为像三、四、五条是比较软的，对吧？"
  },
  {
    "i": 205,
    "speaker": "Lauren Tan",
    "text": "这两条实际上会让 CI 变红，对吧？所以，你知道，有一个硬性约束，智能体不能只写糟糕的代码。对于规则、技能和 bug bot，你的智能体仍然可能会忘记，好吗？"
  },
  {
    "i": 206,
    "speaker": "Lauren Tan",
    "text": "它们可能不会始终一致地应用这些规则。所以，我喜欢将它们分层，但我不喜欢仅依赖它们作为唯一的执行手段，因为这非常非常软性，对吧？"
  },
  {
    "i": 207,
    "speaker": "Lauren Tan",
    "text": "如果你只有规则、bug bot、技能以及代码风格指南，那么你的代码库迟早会变成一团糟。很抱歉这么说，但我确实建议，你知道的，投资于那些可以硬性强制执行的东西，对吧？"
  },
  {
    "i": 208,
    "speaker": "Lauren Tan",
    "text": "这就是为什么，你知道，也许你使用的技术栈的选择也非常重要。嗯，比如我认为 Rust 正在重新变得非常流行，因为它的编译器非常严格，对吧？"
  },
  {
    "i": 209,
    "speaker": "Lauren Tan",
    "text": "编译器强制执行了很多不同的事情，你知道，有一个你必须满足的借用检查器。只要确保你的智能体不写不安全代码块，你就可以大致放心，如果代码能编译通过，它很可能就能工作并且是好的。"
  },
  {
    "i": 210,
    "speaker": "Lauren Tan",
    "text": "呃，但你看，它给你那种级别的信任和信心，让你作为人类工程师不再需要亲自去检查。你知道，你依靠代码和静态分析来实际让这个过程，顺畅得多。"
  },
  {
    "i": 211,
    "speaker": "Lauren Tan",
    "text": "嗯，我想最糟糕的情况、最糟糕的处境是，如果你被困在代码审查的世界里，实际上是通过真人逐字阅读代码并说“好吧，你不应该这样做”来强制实施代码库中的所有约束和不变量。"
  },
  {
    "i": 212,
    "speaker": "Lauren Tan",
    "text": "对吧？每次你不得不这样做时，都应该将其视为一种代码异味，就像一种反模式。你应该说：“好吧，与其我在 PR 上评论，我该如何将其转化为一条硬性规则？”"
  },
  {
    "i": 213,
    "speaker": "Lauren Tan",
    "text": "对吧？我如何将其转化为一条 lint 规则？我如何将其转化为 CI 失败？或者我甚至如何从根本上彻底消除这个问题？呃，我可以谈谈我做的另一次迁移，但我可能就在这里暂停一下。"
  },
  {
    "i": 214,
    "speaker": "Speaker 1",
    "text": "好的。"
  },
  {
    "i": 215,
    "speaker": "Lauren Tan",
    "text": "是的，老实说，我觉得我现在所处的状态就是你正在描述的那种，也就是我没有所有这些规则。呃，所以在这次会话之后，我有些事情要做，以便能够扩展我的智能体。"
  },
  {
    "i": 216,
    "speaker": "Lauren Tan",
    "text": "我肯定是在，你知道，也许本地并行运行几个，比如本地两到三个。我相信这里的大多数人情况也一样，所以呃，是的，我知道我们只剩几分钟了。呃，Lauren，你还有什么想强调的吗？"
  },
  {
    "i": 217,
    "speaker": "Speaker 1",
    "text": "显然有很多问题，所以我可以收集更多，但我想给你几分钟时间，如果你还有其他想谈的内容。好的，太好了。呃，我有一个问题，出现了好几次，就是关于 token 使用量的。"
  },
  {
    "i": 218,
    "speaker": "Speaker 1",
    "text": "所以问题是，你描述的情况对于那些拥有正常 token 使用量的人来说是否现实？他们并没有基本上无限的 token 来使用。嗯，我认为这是一个很好的观点。"
  },
  {
    "i": 219,
    "speaker": "Speaker 1",
    "text": "我的意思是，显然，我在一个 AI 实验室工作，那里我们有无限的 token，所以我肯定不能说每个人都应该以和我完全相同的方式来做这件事。"
  },
  {
    "i": 220,
    "speaker": "Speaker 1",
    "text": "我认为在不花大价钱的情况下达到这个状态是可能的。"
  },
  {
    "i": 221,
    "speaker": "Lauren Tan",
    "text": "但是，如果你是工程负责人，或者你领导着一家初创公司，我认为主要的问题在于投资回报率（ROI）。"
  },
  {
    "i": 222,
    "speaker": "Speaker 1",
    "text": "嗯，是的，你在前期阶段会在 token 上花费很多钱。你知道，重构代码库会消耗大量的 token。添加所有这些功能也会消耗大量 token。"
  },
  {
    "i": 223,
    "speaker": "Speaker 1",
    "text": "好的，酷。呃，我有一个问题，出现了好几次，就是关于 token 使用量的。所以问题是，你描述的情况对于那些拥有正常 token 使用量的人来说是否现实？他们并没有基本上无限的"
  },
  {
    "i": 224,
    "speaker": "Speaker 1",
    "text": "token 来使用。"
  },
  {
    "i": 225,
    "speaker": "Lauren Tan",
    "text": "嗯，我认为这是一个很好的观点。我的意思是，显然，我在一个 AI 实验室工作，那里我们有无限的 token，所以我肯定不能说每个人都应该以和我完全相同的方式来做这件事。"
  },
  {
    "i": 226,
    "speaker": "Lauren Tan",
    "text": "我认为在不花大价钱的情况下达到这个状态是可能的。但是，如果你是工程负责人，或者你领导着一家初创公司，我认为主要的问题在于投资回报率（ROI）。"
  },
  {
    "i": 227,
    "speaker": "Lauren Tan",
    "text": "嗯，是的，你在前期阶段会在 token 上花费很多钱。你知道，重构代码库会消耗大量的 token。添加所有这些功能也会消耗大量令牌。"
  },
  {
    "i": 228,
    "speaker": "Lauren Tan",
    "text": "但是，如果我们正走向一个由智能体编写所有代码的世界，而且你知道，你想要保持非常精简，对吧？你不想去招聘，你不想成为，你不想变得像 Meta 那样，对吧？"
  },
  {
    "i": 229,
    "speaker": "Lauren Tan",
    "text": "我的意思是，在规模上你不想变成一个拥有万名工程师的组织，因为我的意思是，那确实是个令人羡慕的问题，但同时也意味着你有巨大的管理开销。"
  },
  {
    "i": 230,
    "speaker": "Lauren Tan",
    "text": "那里充斥着各种规划工作，你知道的，就我个人而言，我觉得这并不太有趣。但是，我认为你希望保持非常敏捷，对吧？而且智能体的核心在于让你能够做以前无法做到的事情。"
  },
  {
    "i": 231,
    "speaker": "Lauren Tan",
    "text": "对我来说，这真正体现了智能体的价值。你知道，这并不是说在每个小细节上都堆砌 token，但是对我来说，以前我无法独自做到的事情，是在代码库中强制执行这种级别的约束。"
  },
  {
    "i": 232,
    "speaker": "Lauren Tan",
    "text": "对吧？我只是一个人，你知道的，如果只有我一个人，构建这个框架、完成所有重构、亲自测试并验证一切，想象一下那得花多少年，对吧？"
  },
  {
    "i": 233,
    "speaker": "Lauren Tan",
    "text": "不，在智能体出现之前的时代，就像我自己跑完整个流程，那会花我很长时间，对吧？而且我的薪水相当高，对吧？"
  },
  {
    "i": 234,
    "speaker": "Lauren Tan",
    "text": "所以，你知道，我认为工程领导者可能会问的问题是，这里存在一个权衡：你是雇佣某人来做这件事，还是花费 token 来搭建代码库，以便即使是最天真、最笨拙的"
  },
  {
    "i": 235,
    "speaker": "Lauren Tan",
    "text": "智能体也能出色地完成工作。当你真正达到这一点时，即使是那些规模不大的智能体，也能非常出色地编写代码。"
  },
  {
    "i": 236,
    "speaker": "Lauren Tan",
    "text": "这对我个人来说也带来了巨大的回报，因为我不仅赋能了自己，还再次赋能了产品经理、设计师以及不熟悉 Grok 的工程师，让他们能够以可持续的方式做出贡献。"
  },
  {
    "i": 237,
    "speaker": "Lauren Tan",
    "text": "所以，我认为，是的，这绝对是一个权衡，你知道，天下没有免费的午餐。呃，而且 token 相当昂贵。"
  },
  {
    "i": 238,
    "speaker": "Lauren Tan",
    "text": "呃，不过哦，实际上，我不知道你们中有多少人看到了这个，但我们今天确实发布了 Grok 4.6。所以，非常令人兴奋，终于上线了。嗯，是的，Grok 4.6 会"
  },
  {
    "i": 239,
    "speaker": "Lauren Tan",
    "text": "变得很棒，它非常、非常聪明。呃，它在基准测试上的表现真的很好。呃，关于 token 也是同样的情况，希望我没有说错，但我相信每个 token 的成本与 4.5 版本相同。"
  },
  {
    "i": 240,
    "speaker": "Lauren Tan",
    "text": "所以，你实际上是以相同的成本获得了更高的智能水平。呃，我认为这是 Cursor 和 SpaceX AI 努力优化的领域，也就是在成本与智能之间找到那个帕累托前沿。"
  },
  {
    "i": 241,
    "speaker": "Lauren Tan",
    "text": "你知道，我们并不一定想要构建有史以来最大的模型，因为运行它的成本极其高昂。这真的是关于如何找到那个最佳平衡点，对吧？"
  },
  {
    "i": 242,
    "speaker": "Lauren Tan",
    "text": "你不需要一个巨大的模型，但它必须超级聪明，对吧，而且推理成本不高。呃，不过嗯，是的，我想总结一下，我认为如果你自己做分析，感觉前景相当积极。"
  },
  {
    "i": 243,
    "speaker": "Lauren Tan",
    "text": "投资这类事物所带来的投资回报率（ROI）会相当可观，这不仅赋能你自己，还能让你的整个团队生产力大幅提升。对吧？"
  },
  {
    "i": 244,
    "speaker": "Lauren Tan",
    "text": "想象一下，如果你有一支像我这样的工程师大军，每天都在发布大量的改进和 bug 修复。好吧，这确实相当令人兴奋。"
  },
  {
    "i": 245,
    "speaker": "Speaker 1",
    "text": "酷。呃，在我们结束之前最后一个问题。呃，这个问题是给电话会议中负责产品的人员的。所以，假设我们确实有一支像 Lauren 说的那样不断发布更新的工程师大军。"
  },
  {
    "i": 246,
    "speaker": "Speaker 1",
    "text": "我只是好奇，鉴于你们发布产品的速度如此之快，贵公司的产品团队或其他职能部门是如何跟上进度的？他们是否更多地使用 AI 来完成工作？请尽可能详细地谈谈这一点。"
  },
  {
    "i": 247,
    "speaker": "Lauren Tan",
    "text": "显然你并不在那个岗位上，但我只是好奇这具体是如何运作的。嗯，我认为这正是 Grok Bot 实际上展现出极强力量的地方。"
  },
  {
    "i": 248,
    "speaker": "Lauren Tan",
    "text": "呃，所以在 Grok Bot 出现之前，你知道的，显然 Cursor 只有 Cursor 本身。我们只有智能体窗口、命令行界面和集成开发环境。"
  },
  {
    "i": 249,
    "speaker": "Lauren Tan",
    "text": "这些真的是面向高级用户的工具，对吧？它们是为开发者设计的，所以非常以开发者为中心。你可以在其中进行知识型工作，但用户界面并没有真正为此优化。"
  },
  {
    "i": 250,
    "speaker": "Lauren Tan",
    "text": "所以，我们实际上并没有……嗯，我认为很多从事 GTM（市场拓展）、产品等工作的人可能使用过 Cursor 来完成工作，但这绝对不是一种令人愉悦的体验。"
  },
  {
    "i": 251,
    "speaker": "Lauren Tan",
    "text": "嗯，我认为现在有了 Grok Bot，Grok Bot 基本上就像是非科技领域人士的 Cursor 时刻，在我看来。"
  },
  {
    "i": 252,
    "speaker": "Lauren Tan",
    "text": "它提供了一种非常易于使用的方式，在一个非常舒适、非常熟悉的界面中使用智能体。它看起来像 iMessage。嗯，而且它也非常有趣。你知道，你可以给你的智能体起个名字。"
  },
  {
    "i": 253,
    "speaker": "Lauren Tan",
    "text": "呃，你可以进行某种编排以一种非常自然的方式，每个智能体就像一个人，现在你拥有一个由智能体组成的团队在为你工作，例如你管理着每个账户对应的一个智能体。"
  },
  {
    "i": 254,
    "speaker": "Lauren Tan",
    "text": "或者如果你是产品经理，你可以有一个智能体来总结 Lauren 昨晚完成的所有工作，然后你就知道我要做什么了，对吧？所以我认为我们的产品经理们大量利用了这一点。"
  },
  {
    "i": 255,
    "speaker": "Lauren Tan",
    "text": "而且他们也在发布代码。所以你知道，很多时候他们会说，哦，这里有个 bug，我修好了。你能看看吗？然后我去审查，结果发现确实完美无缺。我就想，好吧，批准。"
  },
  {
    "i": 256,
    "speaker": "Lauren Tan",
    "text": "所以我认为这表明你知道，Dune 架构是经得起考验的，对吧？所有那些非常严格的约束条件，让非工程专家也能以高水平做出贡献。"
  },
  {
    "i": 257,
    "speaker": "Lauren Tan",
    "text": "所以我觉得我已经看到很多回报了，你知道，设计师和产品经理现在可以直接发布功能。这让 Grok Bot 团队变得超级快，对吧？我们可以如此迅速地发布产品。"
  },
  {
    "i": 258,
    "speaker": "Lauren Tan",
    "text": "嗯，我们还有很多计划，所以我很兴奋能发布更多内容。"
  }
]