Cursor 团队：AI 时代的编程未来
Cursor Team: Future of Programming with AI
AI 编程工具 Cursor 的团队谈代码模型的训练思路、开发者工作流的变化与编程的未来。
Cursor 内部有个说法，来自联合创始人 Sualeh 后来的一次复盘：2022 年 6 月，团队里有人打了个赌，赌 2024 年 6 月或 7 月，大模型能不能在 IMO（国际数学奥林匹克）上拿到金牌。Sualeh 本人是竞赛选手，清楚这道题的分量，他当时的第一反应是「Aman 疯了」。两年后 DeepMind 的系统离金牌线只差一分。
这个赌局被当成了饭后谈资，它几乎定义了 Cursor 存在的前提。如果模型能力能这样陡峭地爬升，那所有围绕「程序员怎么工作」的产品设计，都得在一个更激进的时间尺度上重做。
这期播客是 Cursor 四位创始人 Michael Truell、Aman Sanger、Sualeh Asif、Arvid Lunnemark 第一次集体出镜，聊了将近两个半小时。表面上是聊一个代码编辑器，往下挖，聊的是编程这件事本身会长成什么形状。
代码编辑器到底是什么
Lex 开场问了一个看起来很傻的问题：代码编辑器的意义是什么？
Michael 的回答是，传统上编辑器是程序员「用正式编程语言做文本编辑」的地方。对不写代码的人，可以理解成一个为程序员做的、超级强化版的 Word。强化的理由很单纯：代码有结构。正因为有结构，编辑器能替人做的事远比普通文字处理器多。
从关键词的语法高亮让你能快速扫读，到像浏览网页超链接一样在代码库里跳转定义，再到错误检查抓一些低级 bug，这些都是编辑器在「结构」上做文章。Michael 补了一句关键的话：未来十年，代码编辑器是什么，会发生很大变化，因为「造软件」这件事本身会变得不太一样。
Arvid 补了一个常被低估的维度：编辑器得好玩。
很多我们做出来的东西，试完就扔了，因为它不好玩。而好玩很大一部分来自快。快就是好玩。（Arvid Lunnemark）
这句「Fast is fun」后来几乎成了 Cursor 所有工程决策的隐形指挥棒。后面聊到的 KV cache、投机解码、影子工作区，本质上都在服务这一条。
从 Vim 到 VS Code，再到一个疯狂的念头
Cursor 四个人早期全是 Vim 用户，纯 Vim 加终端，连 Neovim 都不碰。转折发生在 2021 年 Copilot 出来的时候。Aman 说他想试试 Copilot，而当时唯一能用的编辑器是 VS Code，结果一进去就再没出来。
Lex 给 Copilot 的体验做了个精妙类比：像一段亲密友谊里，朋友能替你把话说完。说得准的时候，那种「他懂我」的感觉会上瘾；说得不准的时候，你就得手动删掉重打。Arvid 补充了一个被忽略的细节：Copilot 即使错了也不致命，因为你只要再敲一个字符，提示就会重新生成，错一次的代价几乎为零。
Sualeh 说，Copilot 真正的历史意义在于，它是第一个真正意义上的 AI 消费级产品。在它之前，语言模型一直待在论文和 demo 里。
但团队的野心不止于自动补全。2020 年 OpenAI 的 scaling law 论文出来后，Michael 说那是一个「即使没有新想法，只要加算力和数据就能变好」的时刻。真正让所有事情闭合的，是 2022 年底拿到 GPT-4 的早期权限。之前他们做过一些很具体的工具，比如给金融从业者在 Jupyter Notebook 里用的小工具，也试过用模型做静态分析。
GPT-4 的能力跃升让他们看清了两件事。第一，之前理论上预测的收益变成了现实。第二，整个编程流程都要穿过这些模型，给某一步加个 AI 助手不够用。他们的判断是要重做一个编程环境，给老环境打补丁这条路走不通。
为什么非要 fork VS Code
这个问题很多人问过。市面上已经有 Copilot 这样的插件，为什么 Cursor 要重做一个编辑器？
Michael 的回答很直接：如果你只是现有编辑器的一个插件，你能控制的就非常有限。而 Cursor 团队的判断是，模型会持续变强，编程方式会被彻底改写，这时候被插件的框架限制住，等于自断手脚。他们想要的是「能做出最有用的东西」的自由度。
Aman 补了一个更深的行业观察，这也能解释为什么 Cursor 敢和微软正面竞争：
过去的技术浪潮，往往是一个大东西出现，解锁一批公司。但 AI 编程不一样，每一年、每一次模型能力的跃迁，都会解锁一批新特性。在 AI 编程里，领先几个月，甚至领先一年，产品就会好用得多。（Aman Sanger）
他把这个讲得更狠：一年后的 Cursor，必须让今天的 Cursor 显得过时。一家创业公司如果不能自我作废，就会被别人作废。他评价微软做了很多了不起的事，但不认为他们处在一个能持续做研究和实验、把天花板往上顶的位置。
Sualeh 从另一个角度解释了这个决策：「我们其实是做给自己用的。」当年用 Copilot 时，他能看到模型在变强，但 Copilot 的体验几个月都没什么变化。他当时的感受是：天花板在往上抬，你们为什么不做新东西？alpha 功能在哪里？一个卖得很好、却没有新东西的产品，对想要探索的人来说很难受。
Arvid 补了一个组织层面的关键点：Cursor 把「做 UI 的人」和「训模型的人」放在同一间屋子里，有时候干脆是同一个人。「这样你能做出一些，如果大家不交流、不做实验就根本做不出来的东西。」
Tab：把「下一步」整个预测出来
Cursor 目前最被称道的能力，圈内人叫它 Tab。Michael 把 Cursor 现在做得好归纳成两件事：
第一，像同事一样从你肩膀后面探头，比你更快一步地猜出你下一步要做什么。字符级别的补全只是这个想法的低配版，Cursor 预测的粒度是整个下一次改动，是你下一处要跳过去的地方。
第二，反过来，让你跳到 AI 前面去，用指令驱动代码生成。
Sualeh 讲了 Tab 这个想法怎么来的。他们最初只是想让模型能替人改代码，试了很多次才等到一个真正会改代码的模型。后来发现，一旦接受了一处改动，下一步该去哪儿其实是「明摆着的」。如果你是个 Vim 用户，按 18JJ 就能往下走 18 行，但为什么要人自己数？
所以想法是：你按一下 Tab，它跳到 18 行下面，给你看下一处改动，你再按 Tab。内部当时有个竞赛，看我们能让人按多少次 Tab。（Sualeh Asif）
他接着把这套想法抽象成一个更漂亮的概念：「零熵编辑」。当你已经表达了意图，剩下的操作里其实没有新信息了，但你还是得敲一堆字符让电脑「理解」你在想什么。那模型就应该直接读懂你的心思，把所有零熵的操作都 tab 掉。
Aman 从模型角度补了数据依据：代码的 bits per byte（按字节归一化的损失）比自然语言更低，意思是代码里大量 token 是高度可预测的。而当你预测的对象从「补全代码」换成「人在编辑已有代码时下一步做什么」，可预测性还会再被放大一个量级。Cursor Tab 的目标，就是消灭编辑器里所有低熵的动作，在意图已经确定的地方，把你直接推到未来。
这套东西技术上怎么做？Aman 讲了两个关键点。
第一，这类任务需要极低延迟，所以得用专门训练的小模型。它的特征是「prefill token 消耗巨大，生成长度极小」，也就是要吃进大量上下文却没几个输出。这种负载形态跟稀疏模型天然契合，所以他们用了 MoE（Mixture of Experts）架构，在长上下文下性能提升明显。
第二，他们做了一个叫 speculative edits（投机编辑）的东西，是投机解码（speculative decoding）的变体。区别在于，投机解码通常用小模型去起草、大模型来验证；而代码编辑有一个天然的先验：你正在编辑的那段代码，本身就是最准的「草稿」。
做法很朴素也很聪明：把原始代码块直接喂回模型，模型绝大部分时候会同意「这段我照抄回去」。于是这些行可以并行处理。一直走到某一行模型开始不同意，真的生成新 token，再等匹配了足够多之后重新投机。
Sualeh 提了一个 UI 上的额外好处：因为是流式输出，人可以边看边审，不用盯着一个加载动画干等。
那个被所有人低估的验证问题
聊到一半，Lex 提到 Cursor 体验里的 diff 界面：红绿对比，接受改动。他感叹这背后的 UX 设计工程问题相当大。
Sualeh 讲了他们为了这个界面推翻了多少版。最早是类似 Google Docs 的删除线加上新代码并排显示，太乱。后来试过「按住 Option 键才展示 AI 建议」的交互，蓝色高亮提示这里有建议，你按住 Option 才看到新代码，松开回到原文。这个设计思路本身是合理的，但 Lex 一针见血：你首先得知道要按 Option。
Arvid 把这背后的本质挑了出来，叫它「验证问题」：
这些 diff 对小改动很好用。但一旦改动很大，或者涉及多个文件，逐行审 diff 就变得很不人道了。（Arvid Lunnemark）
他提了两个方向。一是把 diff 拆成「高信息」和「低熵」两类，重要的高亮出来，重复的灰掉。二是让模型先看 diff，预判哪里有 bug，用红色波浪线标出来，告诉你「这段重点看」。他补了一句关键判断：当前的 diff 算法只是普通算法，设计里有人类智慧，但运行时没有智能。
Aman 从产品层面说得更狠：代码审查这个交互，本来就是为「人给人 review」设计的。当代码的生产者是模型，你不需要照顾「作者」的体验，可以完全围绕审阅者重新设计。而现在这种「把 AI 产出硬套成 PR」的做法，恰恰是想象力不足。
Arvid 还提了一个被忽略的细节：顺序。真实的代码审查里，你从上往下翻文件列表，但逻辑上的正确阅读顺序其实不一样。让模型来告诉你该先读哪块、再读哪块，这才是模型应该做的事。
Sualeh 把这个问题推到了更远处：
模型会变强，能提出的改动会越来越大。改动越大，人要做验证的工作就越多，你就越得帮人减负。我不想把时间全花在审代码上。（Sualeh Asif）
一堆自研模型叠起来的东西
Lex 聊到这儿说了一句很准的话：这个编辑器里跑着一堆机器学习。
Aman 讲了其中的结构。Cursor 的工作方式是一套自研模型和前沿模型的「合奏」。前沿模型负责推理密集的部分，自研模型补它做不好的部分。有两个典型例子。
第一是 Cursor Tab，前面讲过，在特定任务上，专门的模型可以打赢前沿模型。
第二是 Apply。这个功能很少被外行注意，但它撑起了 Cursor 体验的关键一环。前沿模型很擅长勾画代码改动的草图，但一到「生成精确的 diff」就开始翻车。Aman 说得很直白：
你拿 Sonnet、o1，任何前沿模型去干这事，它都会在特别蠢的地方搞砸，比如在大文件里数错行号。（Aman Sanger）
Sualeh 补刀：「跟很多人想的不一样，靠确定性算法根本解不了这个问题。」
听到这里能感到那个反差：把「建议」和「原文」合成一份精确的 diff，对人来说是几乎不费吹灰之力的动作，对模型却是硬骨头。Cursor 的解法是让模型先画一个很粗的草图，再训练专门模型去把草图落到文件里。Aman 说外面有些粗糙的模仿品，想用确定性匹配硬解，结果至少 40% 的时候会崩，产品体验直接毁掉。
更妙的是，Apply 还带来了省钱和提速的副产品。因为它让最贵的推理模型只需要输出极小规模的草图，后面的实现交给更轻的模型去落地。Aman 判断这个趋势会继续：越来越聪明的模型做规划，实现细节交给次要的模型去做。o1 这种级别的模型只出一个高层计划，被下级模型递归应用。
到底哪个模型写代码最好
Lex 问出了那个所有人都在争的问题：GPT 还是 Claude？
Aman 的回答很干：没有一个模型在所有维度上 Pareto 最优。维度包括速度、改代码能力、处理超长上下文的能力、代码能力。就当下综合最优而言，他认为答案是 Sonnet，并说这是社区共识。
o1 很有意思，推理能力确实强，做编程面试题、LeetCode 难题表现很好。但它对你「粗糙意图」的理解，明显不如 Sonnet。Aman 还提了一个更含蓄的批评：一些前沿模型在基准上的表现，跟它们在中间地带的真实能力，是有落差的。在训练分布附近跑基准，分数很好看；一旦稍微出界，Sonnet 是那种「能力能保持住」的模型。
这引出了另一个问题：基准和真实编程到底差在哪里？
Sualeh 说得最直接：真实编程里，人是半句半句说话的，有时候是「照我刚才那样做」，有时候是「加这个，再做那个，顺便把那个 UI 改一下」。所有这些都高度依赖上下文。面试题的规格极其明确，而人的诉求极其不明确。
Michael 补了第二层难度：公开基准本身就被污染了。他举了 SWE-Bench 的例子，这是最流行的 agent 基准之一，但在基础模型的训练数据里污染严重。一个证据是，如果你让模型做 SWE-Bench 的题，但不给它任何代码库上下文，它能直接幻觉出正确的文件路径和函数名。
Aman 接了句更狠的话：这些题目涉及的代码库，大多是最流行的 Python 仓库之一，比如 sympy。基础模型公司不会为了保护这些基准的干净度，而把这些主流代码库从训练集里剔除。
那怎么办？Michael 说，很多做系统或做模型的团队用了一种土办法：找人来玩，做定性反馈。有些基础模型公司，专门有人干这个。Cursor 内部也做大量定性评估，再加上一些私有评测集。
Arvid 给这件事起了个名字：「vibe」测评。Lex 马上接话说，他自己也是这么做的，读论坛、读 Reddit、读 X，但用户经常说「我觉得 Claude 变蠢了」，他自己有时候也这么觉得，只是不确定是模型的问题还是他自己的问题。
Aman 提了一个有意思的猜测：AWS 用的是自家芯片，数值精度和 Nvidia 的 GPU 可能不一样，有人猜 Claude 在 AWS 上表现变差，可能跟 Bedrock 上跑的是量化版本有关。Sualeh 补了一句：芯片是脏的，bug 是极难避免的，这个难度怎么高估都不为过。
把 prompt 当成 React 组件来写
Arvid 写过一篇博客，讲 Cursor 内部的 prompt 系统，叫 Preempt。
他的思路起点是：早期模型（2023 年那批 GPT-4）上下文窗口只有 8K，而编辑器里可用的上下文信息一大堆：文档、加进来的文件、对话历史。你怎么决定哪些塞进 prompt、哪些不塞？空间有限，怎么排？
他借了一个看似完全不相关的领域的思路：网页设计。
做杂志印刷，你确切知道内容放在哪。但做网页的时候，输入是动态的，你得让它永远能工作，输入太大就得裁掉点东西。（Arvid Lunnemark）
于是他借鉴了 React 的声明式写法。Cursor 内部确实是用 JSX 来写 prompt 的。有组件，有一个组件叫 File，输入是光标位置。光标所在的那一行优先级最高，往外每远一行减一，渲染引擎（Preempt renderer）自动算能装多少行，以光标为中心适配。
更妙的是，这个抽象让 prompt 变得「可调试」。因为原始输入和渲染是分离的，你可以改渲染逻辑，然后在老 prompt 上回放，看这个改动在整套 eval 上到底有没有提升。Arvid 说这个能力现在比当初更重要：早期 Preempt 是为了适配小窗口，现在更多是为了把数据切分和渲染解耦，让调试变得可能。
Lex 顺着问：那用户是不是也应该写 JSX 来提问？Arvid 的回答很干净：
我们的目标是你做你觉得最自然的事，我们的工作是想办法把相关内容找出来，让你的表达能被理解。（Arvid Lunnemark）
这跟 Lex 之前采访 Perplexity 的 Aravind 聊过的观点相通：让用户尽可能懒。但 Lex 也抛出了一个张力：对程序员，你是可以要求更多的。那到底是让用户懒，还是让系统去「启发」用户思考得更深？
Aman 的回答是另一种思路：当意图传达不够时，可以有几种解法。最朴素的是让模型直接问，「这部分我不确定，你能说清楚吗？」另一种是，如果搜索空间不大，那干脆生成五六个选项让你挑。
Sualeh 提了一个 Cursor 最近做的功能：在你打字时，系统会猜你在做什么，主动建议你该加哪些文件。比如你在改 API，系统能根据你在同一文件里的历史提交猜出 client 和 server 都很重要，主动建议你加进来。这个能力还在很早期，但方向是把「提示词的构建」这件事从用户手里接过去一部分。
Agent 能干什么，这四个人怎么判断
Lex 问 agent 的实用程度。Arvid 先说了一句很坦诚的话：
Agent 很像人，看 demo 的时候会觉得自己离 AGI 更近了，非常酷。但对很多事情，agent 现在还不够有用。我们正在接近它们真正有用的那个点。（Arvid Lunnemark）
他举了一个具体的例子：Cursor 的聊天输入框里，有一个 bug 是 Command+C、Command+V 有时候不管用。这种任务规格极其明确：「这里坏了，帮我修」，两句话就能说清楚。他很想要一个 agent，自动找到相关文件、复现 bug、修掉、验证一遍，一天后他回来看结果。
接下来他讲了 Cursor 团队对 agent 最不主流的判断：
很多人相信 agent 会接管所有编程。我们不这么看。因为编程里很大一部分价值在迭代，你没法事先把需求说清楚，因为你看到第一版之前根本不知道自己想要什么。（Arvid Lunnemark）
大部分编程场景里，人真正想要的是那种即时的东西：一秒钟给一版初稿，立刻能改，改完再看下一版。派一个 agent 出门办差，那是另一类需求，适合规格清楚、步骤固定的活儿。
他还补充了一个「背景 agent」的产品形态：在一个前后端都改的 PR 里，你在前端工作时，后台可以跑一个 agent 先摸后端，等你切到后端时，已经有一份初稿可以迭代。这个想法后来变成了 Cursor 的 Shadow Workspace。
速度是产品的一部分，拆开讲都是硬核工程
Lex 提了一个很妙的观察：在 Cursor 里，Apply 是唯一让他觉得慢的功能，一两秒而已。这个「一两秒都觉得慢」本身，说明其他部分快到什么程度。Arvid 听到这句时脸上的痛苦，Lex 专门描述了。
Aman 系统讲了几个加速设计。
一是 cache warming（缓存预热）。用户在打字时，系统能预测他大概会用到哪些上下文，提前把当前文件内容预热进 KV cache。等用户按下回车，真正需要 prefill 的 token 已经很少，TTFT（time to first token）明显下降。
二是 KV cache 本身的机制。Aman 解释得很清楚：Transformer 能做上下文依赖，靠的是 attention 里的 key 和 value。默认情况下，模型每生成一个 token，都要把所有历史 token 的 key/value 重新算一遍。但如果把它们存在 GPU 上，生成第 N+1 个 token 时只需要跑最后一个 token 的前向，attention 时复用之前的 KV。这是 Transformer 里唯一的串行依赖部分，复用 KV 等于把这块串行的代价砍掉大半。
三是投机加缓存的组合。Cursor Tab 会在用户按下 Tab 前，先假设他已经接受了当前建议，提前发起下一个请求。如果用户真的按了，下一个建议已经在缓存里等着他了。Aman 说这是个混合了投机与缓存的 trick，能达到「看起来很快」的体感，哪怕模型本身没变过。
Sualeh 接了一句更理论的话：如果把 KV cache 做小，你就能更激进地投机。比如预测接下来 10 个可能动作，用户只要命中其中一个就赚了。他管这个叫 power K 曲线现象，单次采样可能不好，但采样多次，命中好答案的概率会高得多。而 RL 本质上就是在利用这条曲线。
Aman 从模型架构上补了另一条线：老一代主要用 multi-head attention，现在往 group-query、multi-query 迁移，本质是压缩 KV cache 的大小。这么做的直接好处是生成 token 阶段（memory bound）更快，而且 batch size 能做得更大。更小的 KV cache 意味着你能同时处理更多请求，或者让 prompt 更长，而不牺牲生成延迟。
Sualeh 还讲了一个非常有意思的算法：DeepSeek 的 MLA（multi-latent attention）。思路是把所有 head 的 KV 压成一个共享的低秩向量（latent vector），再在需要时展开回去。省下的是内存带宽，用算力换带宽。他顺带给了一个判断：多 query 注意力这类压缩方案，本质都在牺牲 KV 的表达丰富度换效率，MLA 想把损失补回来一部分。
影子工作区：让 AI 在另一个宇宙里跑代码
Arvid 写过另一篇博客，讲 Shadow Workspace。
他先讲了动机：如果你能在后台烧算力，就能帮用户做到超出「预测下面几行」的事情，比如「未来 10 分钟你会做什么」，这需要更多算力和更长的思考窗口。但要让后台计算真的有用，你必须给模型一个反馈信号。纯靠模型多想一会儿这条路，o1 已经证明有效；另一种同样成立的方式是让模型迭代、拿到反馈。
对程序员来说，最重要的反馈信号就是语言服务器（language server）。每种语言各有一个，能做类型检查、判断你写错了什么类型、能不能跳到定义、能不能找到引用。它们在 VS Code 里通过 LSP（language server protocol）接入，好处是 VS Code 本身不用内置所有语言的编译器，直接复用现成的编译器基础设施。
Shadow Workspace 的想法是：开一个隐藏的 Cursor 窗口，把 flag 一挂，它就隐形了。AI agent 可以随便改这个窗口里的代码，只要不保存，就不会污染源文件（因为文件夹是同一个）。在隐藏窗口里，agent 可以拿到 lint 反馈、跳定义、反复迭代自己的代码。
Arvid 提到一个技术坑：Linux 上可以做文件系统的内存镜像，把 AI 的改动挡在内存层，它以为自己在改文件，其实全在内存里。Mac 和 Windows 上更难，但这也是他觉得有意思的原因。
Aman 提了一个「hack 但有趣」的替代方案：让语言模型直接对保存加个锁。于是你编辑的其实是「未保存的、只存在于内存里的影子版本」，但仍然能收到 linter 报错。你要跑代码时，会收到一个小警告说锁被占着，然后可以把控制权协商过来。
Lex 说，这个未来既激动人心又有点吓人。让模型直接改文件，让 agent 跑一整夜，第二天回来像看同事的作品一样看结果。Aman 补了一个更细的判断：几分钟级别的、嵌在用户工作流里的任务，本地跑合适；时间更长、改动更大的任务，应该放到远程沙箱，但怎么让沙箱复现用户环境到「等价」的程度，本身就是极难的问题。
为什么这些模型这么不会找 bug
Lex 说他设想的 agent 不止在编程里，还在视频剪辑里。他做播客的很多后期工作通过代码驱动 Premiere，包括上传、翻译、配音，他希望这些都能被 agent 自动化。回到编程，他最想要的 agent 能力是 bug 发现，尤其是逻辑层面的大方向。
Aman 接得很直接：
这些模型在找 bug 上出奇地差。就算是最聪明的模型，甚至 o1，只要朴素地提示它们去找 bug，校准差得可怕。（Aman Sanger）
为什么？Aman 的解释有信息量。这类模型是预训练分布的强烈反映，而预训练里最多的代码相关数据是「代码生成」和「问答」：GitHub 上的代码是万亿 token 量级，Stack Overflow、GitHub issues 上的问答也海量。但「在现有代码里检测真实 bug」，这件事在网上几乎不存在。所以当你让模型去做 Cursor Tab 那种「预测下一处改动」的任务，或者去做 bug 检测，脆弱性就露出来了。
Sualeh 补了一层更微妙的观察：模型其实在内部「知道」某段代码有点可疑，但难点是校准「有多可疑」。同一段代码，你在做实验时几个 bug 无所谓，你在写数据库时一个边界情况都不能错。这中间的判断需要「用户有多偏执」的上下文，而这恰恰是模型最不擅长的。他还提了一个词：资深工程师的价值一部分来自文化记忆，知道三年前有人写过一段很可疑的代码把服务器搞挂了，这种知识模型没有。
他讲了 Arvid 一个极端的实践：如果一段代码能造成巨大破坏，就在函数里每一行都写上全大写的「DANGEROUS」，重复十遍。这套做法在今天的 AI 模型上确实有效，模型会对这种区域更警觉，更容易发现 bug。Sualeh 自己承认，从美学上他很难接受，但从实用上，人太容易遗忘，一个小失误就能搞挂服务器。
Arvid 顺着这条线想到更远的地方：在形式化验证（formal verification）普及之前，你永远需要担心「这里会不会悄悄引入 bug」。他设想的未来是，人不再写测试，模型根据你的函数生成一份 spec，你审 spec，然后一个强力推理模型去证明实现符合 spec。Michael 追问：如果意图本身很难被精确表达呢？Arvid 承认这确实是个真问题，spec 语言也需要演进。
但 Arvid 觉得整库级别的形式化验证也可行。他举了一个很硬的例子：现在已经有工作做到把 C 代码形式化验证到 GCC 编译器、再到 Verilog、再到硬件。如果这么大的系统都能拆解验证，大型代码库原则上也可以。Aman 追问了更难的问题：外部依赖怎么办？调用 Stripe API 怎么证明？如果模型本身成了程序里的原语，怎么证明它？Arvid 说，他甚至觉得「证明一个语言模型对齐」在原则上也是可能的。Lex 说这就是他的「I have a dream」演说。
基础设施：Merkle 树、分支数据库、为什么 AWS 还赢
聊到基础设施，Lex 提了一个怪问题：为什么 AWS 依旧赢，尽管它的界面那么糟？Arvid 说，AWS 就是好，任何时候你用 AWS 产品，你就知道它能跑通，虽然走通配置流程的过程可能是地狱。Sualeh 一句「这就是赢家该有的样子」把大家逗笑了。
Michael 讲了一个更有价值的细节：每加一个数量级的 QPS，都会撞上新的坑。现在到了「表开始溢出」的规模。Cursor 自研的检索系统（对代码库做语义索引、回答问题）是其中最难扩的。
Sualeh 展开讲了这套系统，这是整期播客里信息密度最高的一段。
Cursor 把用户的代码分块（chunk）上传做 embedding，然后只在数据库里存向量，不存代码本身，所有细节加密在服务端，客户端 bug 是他们的心腹大患。技术上最难的是保证「本地索引」和「服务端状态」一致。每改一个文件、删一个文件、切一个分支，都得同步。
朴素做法是每分钟拉一次全量哈希，但这样会「砸爆用户的 WiFi」，也会让接近 20TB 的数据库每秒被读一遍。Cursor 的解法是分层哈希：每个文件一个哈希，每个文件夹存它所有子节点哈希的哈希，一层层往上，直到项目根节点一个哈希。绝大多数情况下根哈希对上就结束。一旦不对，才逐层下钻，去找不一致的地方。这套结构有个大名鼎鼎的名字：Merkle 树。
Aman 补了一个很妙的经济学细节：索引系统的成本瓶颈不在向量数据库，而在embedding 本身。一个公司里 N 个程序员用同一份代码，你没理由给每个人都重新 embed 一遍。他们的做法是，对某个 chunk 算出的向量做缓存，缓存的 key 是这个 chunk 内容的哈希。这样公司里第 N 个人做 embedding 时几乎瞬间完成，切分支时也不用重算，还不用在服务端存原始代码。
Sualeh 提到一个未来的方向：Turbopuffer 这类数据库正在给 write-ahead log 加分支（branch）能力，让 AI agent 直接在数据库分支上测试，而不用污染主库。他很喜欢这个隐喻：「所有东西都需要分支。」Aman 顺着开脑洞：如果文件系统也能分支呢？Sualeh 回了一句关于多重宇宙的玩笑收尾，说已经有极其聪明的算法能保证不会真的占掉太多空间和 CPU。
为什么不做本地模型
Lex 问一个反复被提及的问题：为什么 Cursor 不把 embedding 之类的计算放到本地？
Arvid 的回答很现实：Cursor 的用户 80% 以上用 Windows 机器，很多性能一般。本地模型基本只在最新款 MacBook Pro 上可行，光是维护这些分支就要吃掉大量工程资源。更关键的是，当模型越来越大，本地能做的事越来越少。
Sualeh 补了一个常被忽略的角度：这跟「用户电脑弱」关系没那么大。哪怕你是大公司里最强的程序员，在一台顶级 MacBook Pro 上处理公司那种二十年积累的庞大代码库，做近似最近邻搜索也会把内存和 CPU 榨干。就算能勉强跑通，也不「好玩」了。
Aman 从模型侧补了另一重困难：趋势是 MOE 化，这对本地推理其实有利，因为 MOE 更受内存带宽约束，而消费级硬件在内存带宽上的劣势比在算力上小。但坏消息是，总参数量越来越大，经常单台机器放不下，得上多节点，更别提塞进 MacBook。
接下来 Arvid 讲了一段可能是整期里最哲学也最动人的话。他说他有一个替代方案，还在研究阶段，但特别令人期待：用同态加密做语言模型推理。你在本地加密输入，传到服务器，服务器在密文上跑你本地根本跑不动的模型，但服务器看不到数据是什么。结果传回来，你解密，只有你能看到答案。他说这个技术现在还处在研究阶段，瓶颈全在开销，如果能把这个开销压下去，意义会非常大。
他接着讲了为什么这件事重要：
当这些模型越来越好，它们会越来越有经济价值，世界上越来越多的信息和数据会流向一两个中心化的玩家。如果全世界的明文数据都流经一个节点，那就有可能被以很坏的方式监控。一开始往往是好的理由，防止坏人恶意使用 AI，于是加上一些监控代码。然后换一个人进来，你就滑下去了，然后开始用全世界的海量数据做坏事。（Arvid Lunnemark）
他还顺手做了一个和云计算的对比。今天你用云服务，大多数时候可以自己管密钥，云厂商其实看不到多少东西。但模型推理这一层不一样，服务商看到的就是完整的明文。
Sualeh 补了一个他真正担心的画面：随着模型能力到 ASL-3、ASL-4，出于合理的安全考虑，你会想监控所有 prompt。这个出发点能理解，但如果全世界的信息都要在这种监控下流动，那太集权了。他描述这种状态是一条极细的线：一边是不想让模型失控，一边是不放心让所有人的所有信息流经三家模型公司。
上下文这件事，为什么自动算不干净
Lex 说这是他自己的痛点：写 Python 时导入了一堆库，Cursor 大概能猜出你想放进上下文的东西，但猜得不够好。
Michael 的回答里有一个容易被忽略的取舍：自动塞上下文不是免费的。塞得越多，请求越慢越贵，你能做的模型调用次数就越少，后台能跑的漂亮功能也就越少。更麻烦的是，很多模型在 prompt 塞满时会犯糊涂。所以「自动上下文」的门槛其实很高，相关性不够的宁可不放。
他提了几条可能的路。一条是更工程化的：更好的检索、更好的 embedding、更好的 reranker。另一条更学术：能不能让模型自己理解一个新语料库。这条路上有几个层层递进的问题。先问能不能让上下文窗口无限长；如果能，再问模型是否真的会注意无限长的上下文；如果会，再问能不能对这种无限上下文做缓存，不用每次都重算。还有一类思路更像微调，把信息学进权重，而非靠 in-context learning 临时装进来。Michael 说，在权重层面学到的理解，可能和在上下文里「临时读懂」的理解有质的不同，但这个问题目前还没有定论。
Aman 给了一个现成的验证案例：VS Code 的代码全公开，这些模型在预训练时都见过，可能也见过围绕着它的问答，然后再经过指令微调和 RLHF，所以你问它 VS Code 的问题，它有时候能答得挺好，当然也会幻觉。他追问：那如果你专门去 post-train 一个模型，让它真的「懂」某个代码库呢？
他讲了具体做法，很朴素。做持续的预训练，把通用代码数据和某个特定仓库的数据混在一起喂进去。然后做指令微调，标准代码数据集之外，加上大量「关于这个仓库」的问答。这些问答可以是真的人工标注，也可以用合成的方式造：拿最近改动过的代码片段，让模型自己针对它提问，然后把问题和代码配对，做成训练样本。
这里还有一个更深的分岔，Aman 说这仍是个开放问题：你希望模型端到端地把检索也做进内部，还是希望把检索和前沿模型分开？后一种情况下，几个月后会出现一批远超最好的开源模型的前沿模型，同时你可以专门训一个很强的开源模型来当检索器，负责给大模型喂上下文。
o1 出来了，然后呢
Aman 把训练分成三段：预训练、后训练、测试时计算。他说测试时计算这条路有意思的地方在于，预训练那边大家开始撞到数据墙，靠加数据加参数继续变好会越来越难，而在推理时多花算力、换来对应幅度的性能提升，是一条新的增长曲线。
他讲了一个很实在的经济学视角：有些问题可能需要万亿参数级、万亿 token 训练的模型才能解，但这类请求可能只占全部请求的 1% 甚至 0.1%。为了这种罕见需求去训练一个超大模型，然后极低频地调用，纯属浪费。更合理的做法是训练一个能覆盖 99.9% 请求的模型，然后在遇到真正硬的问题时，让它多跑一会儿。
o1 到底在内部怎么工作，这事连圈内人都只能猜。Aman 说得很坦率：出了 OpenAI，甚至可能只有 OpenAI 内部少数人知道。他提了几个公开研究里露出的线索，比如用过程奖励模型配合树搜索，或者大规模人工标注的思维链数据集。但这些都是推测。
他顺带把奖励模型分了两类。结果奖励模型（outcome reward model）只看最后答案，给那个最终输出打分。过程奖励模型（process reward model）试图给思维链的每一步打分。他提到一个关键判断：现在公开文献里，过程奖励模型最主流的用法是采样一批候选答案，然后用它来排序挑最好的那个。真正让人兴奋、但还没有被验证成功的方向，是用过程奖励模型去做树搜索，就是说如果每一步能被准确打分，你就可以在思维链里分叉、探索多条路径、再判断哪条分支值得走下去。
Lex 追问这个过程里有个隐含前提：分支的短期质量和最终结果的长期质量要高度相关。Aman 认可，这也正是难点所在。
关于 OpenAI 隐藏 o1 的思维链这件事，Michael 给了一个很有信息量的猜测。他说一个可能的动机是防止能力被蒸馏：如果能看到模型走到答案的每一步，那么复现这套技术的难度会显著下降。他还联系了一个历史细节，某些大模型 API 曾经开放 log probability 的访问，后来又收回去了，理由可能类似，那些概率分布同样能给出大量蒸馏用得上的信息。
Michael 也澄清了 Cursor 集成 o1 的实际状态：o1 不参与任何默认体验，团队至今没找到一种让人每小时、甚至每天都想用的集成方式。原因之一是 o1 不流式输出，对需要边看边监督的任务来说，盯着空白等一大段文字掉下来，体验很糟。Sualeh 补了一句：想法是有的，只是要先做出真正有用的东西才放出去。
Aman 补了另一层难度：模型路由。什么任务该用 4o、什么该用 Sonnet、什么才值得上 o1，这件事没人真正解好。Cursor Tab 那边有初步实现，但要在 4o、Sonnet、o1 之间切换就麻烦得多。他抛了一个很尖锐的自问：判断「这题对 4o 来说太难了」需要什么级别的智能？不确定。
Lex 顺势问了一个互联网上流传的说法：GitHub Copilot 开始集成 o1 了，有人评论「Cursor 是不是完了」。Michael 的回答里有这期最重要的一个判断：
这个领域的天花板高得离谱。三四年后最好的产品，会比今天最好的产品有用得多。你可以把护城河、品牌讲得天花乱坠，但如果你停止在产品上创新，你就会输。（Michael Truell）
他把这当成对创业公司利好的消息：这意味着你永远有机会靠做出更好的东西，去打败那些已经有很多用户的对手。Aman 补充，Cursor 相对其他工具的价值，大部分不来自「最快接上新模型」，而来自那些你意识不到自己在用的自研模型，以及每一个功能背后被反复推敲过的交互。
合成数据的三个种类
聊到这里 Lex 让 Aman 展开了他在内部讲过的一套合成数据分类。这段对做模型的人最有用。
先定义清楚：非合成的自然数据，是人类在真实过程里产生的数据。合成数据分三类。
第一类是蒸馏。让一个语言模型输出 token 或者 token 上的概率分布，然后拿它去训一个能力更弱的模型。这条路不会让你得到比原模型更强的模型，但它能把一个昂贵、高延迟的模型能力，压到一个小的专用模型里。对产品来说，这就是延迟和成本的解药。
第二类靠的是「一个方向比反方向容易」。最典型的例子是 bug 检测：制造一个看起来合理的 bug，比找出 bug 容易得多。所以你可以让一个不太聪明、没训多少数据的模型去制造 bug，用这些合成数据去训一个擅长抓 bug 的模型。Aman 说这对人大概也成立。
第三类是用语言模型生成「可以被轻易验证」的文本。他打了个极端的比方：如果有一个验证器能判断一段文字是不是莎士比亚水平，那你让一群猴子在打字机上乱敲，敲足够久也能凑出足以训练出莎士比亚级模型的数据。数学是这一类最好的场景，因为形式化语言的验证极其便宜。代码里的 LeetCode 型题目也一样，只要有测试集，跑通了就说明解对了。
Aman 的判断是，第三类最有可能带来巨大收益，但它也最难推广。对开放式任务、长周期任务，「完美的验证器」这个前提就很难满足。Michael 补了一种中间状态：让模型去「运行」代码并真的理解输出，相当于把人类的手工验证交给模型做。Aman 认可这一点，说那大概是最有希望的一条路。
顺带聊到 RLHF 和 RLAIF。Aman 的解释是：RLHF 的奖励模型来自人类反馈标注，前提是你能拿到海量的人类反馈。RLAIF 的价值建立在一个前提上，即验证确实比生成容易得多。他说 Cursor 的实际做法是两者混合：模型本身往往已经相当正确，只需要 50 到 100 个样本量级的人类偏好，把它原本的先验校准到你想要的分布上。这和传统上花海量样本训奖励模型的做法很不一样。
Lex 顺着「P 是否等于 NP」这个比喻往下问。Aman 说，如果你相信 P 不等于 NP，那有一大类问题，验证比生成容易太多，这个直觉应该成立。Lex 打趣问：那 AI 会不会顺手证明 P≠NP，然后顺手拿个菲尔兹奖？谁来领这个奖？Michael 说，谁写的那条 prompt 谁领。Sualeh 认真猜了个年份：2028 到 2030。
Arvid 认为菲尔兹奖会比诺贝尔奖更早被 AI 攻下，理由是数学可以被验证，是一个封闭系统，容易设计奖励。Aman 说他自己的直觉是：我们可能会在 AGI 之前先拿到菲尔兹奖。他还补了一句自我修正：当年他赌 IMO 金牌，是因为那时看得清路径，已经能解几道题，文献里也有一堆现成的 tactic 可以捡。但对真正开放的数学难题，他现在的直觉要弱得多，「我们连一条通往解法的路都看不清」。他专门提了 BSD 猜想（Birch and Swinnerton-Dyer conjecture）这类题目做例子，说明难点不在验证，而在于连探索的方向都没有。
Scaling law 比最初那篇论文复杂得多
Aman 讲了一段对 scaling law 的修正史。OpenAI 最初那篇论文有点偏差，主要是学习率调度的问题。Chinchilla 给了一个更准确的版本，核心是在参数量和 token 数之间找到算力最优比例。但后来大家又开始偏离「算力最优」，转而按推理预算做优化，宁可训练时多花算力，换取部署时更便宜更快。
他说今天的曲线维度远比当年多。推理时的算力是一个维度，上下文长度是另一个。他举了一个漂亮的推论：如果你的核心诉求是「推理时延低 + 上下文超长」，那你可能该训一个 SSM 架构，因为它在超长上下文的推理上便宜得多、快得多。哪怕训练时要多花 10 倍算力才能达到同样的能力水平，也值，因为你最在乎的是推理那一端。
对「更大是不是一定更好」这个问题，Aman 的回答很直接：对原始能力而言，更大确实更好。Sualeh 补了「原始智力」这个词。Aman 接着说，他自己特别看好蒸馏：花极其昂贵的算力，训练一个最强的教师模型，然后把它的能力压进一个便宜的学生模型。他举了 Gemma 的做法，训练目标本来就是去最小化学生和 27B 教师之间的 KL 散度。这就是「用训练教师的全部算力，换一个更小的模型」。这也部分缓解了数据墙：同样的 token，你能从中榨出更多信号。
Lex 抛出一个假设性的问题：给你 10 万亿美元，投在接下来五年，怎么分？
Sualeh 说答案可能很简单，全买 GPU，研究人员自己去调。Aman 追问：那你到底是被算力和钱限制，还是被别的东西限制？Sualeh 说他更认同 Arvid 的判断：这个领域是被想法限制的。Arvid 补了一句：但如果你有大量算力，你就能跑大量实验。
Aman 想得更细。他说就算有全世界的资本，你也凑不齐人。全世界真正能在这件事上做出差别的人本来就不多，而且研究里有大量工作是纯粹极其艰苦的工程。他拿 Transformer 论文举例：把文献里那些有趣概念拼起来是一回事，写出能真正把 GPU 性能打满的代码、可能包括 CUDA kernel，是另一回事。再往前一步，让模型并行在几千甚至几万张 V100 上跑通，本身就是一个巨大的工程壮举。他说如果能把这种工程成本降低 10 倍，让一个有好想法的人立刻拿到他设想的架构、且能跑到 40% 到 50% 的 GPU 利用率，那研究的整体速度会快一大截。
Sualeh 最后给了一个很务实的次序判断：如果你看见一条清晰的改进路径，就应该先捡低垂的果实。当一路加规模就能变好时，没有理由停下来做实验。直到你必须靠新想法才能继续，那时才回头重新审视。Aman 说，他们四个人大概都相信，要走到 AGI 一定需要新想法，也都相信这些想法可以在小规模上先验证出来。难的是，对现在的大实验室来说，一边有一个「再加规模大概率还能涨」的核心路径，一边要分出极稀缺的研究和工程人力去探别的路，这个取舍非常难做。
人坐在驾驶座上
Lex 把话题拉到最远处：编程这件事，未来几个月、一年、两年、五年、十年会怎么变。
Michael 讲得最完整。他说 Cursor 押注的是一个「程序员长期坐在驾驶座上」的未来，关键词是三个：速度、主动权、控制权。能改任何你想改的东西，能以极快的速度迭代你在做的东西。
他明确地和另一种流行想象划了界：有一种画面很吸引人，你对着电脑说话，它像一个工程师或者一个工程部门一样替你把软件造出来，一个孤零零的输入框就搞定一切。他们不兴奋于这个画面，一部分原因是延迟，但更重要的是那意味着放弃大量控制权。
如果你只能像对一个工程部门说话那样跟一个东西沟通，你就会把大量极其重要的决策让给这个机器人。但工程里最好的那部分，恰恰是无数个关于「到底要造什么」的微小决定，以及速度、成本和其他一切之间的艰难取舍。（Michael Truell）
他还顺带纠正了一个关于工程的误解。不在工程里的人容易以为，规格已经写得清清楚楚，工程师只负责把它落到代码里。但真正好的工程，恰恰是那些关于系统该怎么权衡的微小判断，速度、成本、复杂度、可维护性，这些东西事先根本写不进规格。
他提了一个有点怪但很有意思的想法：让你能控制自己看代码库的抽象层级。你可以用伪代码的形式消化一整个代码库，甚至可以编辑那段伪代码，然后让改动落到真正的编程语言层面。你在任何一层抽象上都能对逻辑做手势，同时保留文本编辑、保留钻进代码里的能力。他说这个想法目前还很模糊，细节要一项项填，成不成得看时间。
Lex 把这个问题落到最现实的地方：现在有很多年轻人害怕，他们喜欢编程，但怕这条路没有未来。编程这门手艺会不会被根本性地改写？
Michael 的回答很乐观，理由具体：编程今天比 2012、2013 年那会儿好玩太多了，那时候的杂事、样板代码、查各种刁钻问题的比重高得多。今天的编程「越来越接近纯粹的愉悦」。那些把人吸引到编程里的东西，快速造东西的能力、个人的掌控感，都正在被放大。技能会变，人的品味和创意会被放大，样板代码的文本编辑会变少，现在很重要的「小心翼翼」也会变得没那么重要。
Arvid 举了一个他自己的经历：他们决定把代码库里用的 AsyncLocalStorage 迁移到 context object，因为前者性能不好。这是影响整个代码库的大迁移，他和搭档花了五天，用着今天最强的 AI 工具。他很期待未来只需要展示两三个例子，AI 就能把改动铺到所有位置，遇到新情况就高亮出来问他，他示范一次，整件事十分钟搞定。这样你就不用事先站在黑板前反复推演「成本太高了，必须一次做对」，可以先试一个方向，发现不对立刻改。
Aman 把这种心态讲成两种编程方式的对比：一种是先想清楚最优解，再用有限的工程时间去实现；另一种是先动手写，看它长成什么样，然后快速迭代。他说后一种更好玩。
至于该怎么学，Aman 说不同的人因为不同理由写代码，但真正最好的程序员，是那种纯粹热爱编程本身的人。他讲团队里有人下班回家，打开 Cursor 写自己的项目写到凌晨三点，难过的时候说「我就是需要写代码」。这种痴迷会让人钻进细节里，去搞清楚事情到底是怎么跑的。
Lex 追问：那这个人，当超级 Tab 成功、他只需要一直按 Tab 的时候，会变成什么样？
Sualeh 和 Arvid 几乎同时回答：这个人会是团队里最爱 Cursor Tab 的人。Arvid 补了一层更细的理解：按 Tab 是被动接受。你一直在往里注入意图。有时候你拒绝，有时候你多敲几个字符，这就是你在塑造正在被造出来的东西。Sualeh 用一个词概括：带宽。人对电脑的沟通带宽，从「一个字一个字敲」变成「持续注入意图」，这是好几个数量级的提升。
这期节目最后，Lex 读了 Cursor 团队那份叫 Engineering Genius 的内部宣言。宣言里写，他们要造的是「未来的工程师」，一个比任何单个工程师有效十倍的「人机混合程序员」，这个混合体会对代码库有毫不费力的掌控，没有一次低熵按键，即使在最复杂的系统里，也能以判断力的速度迭代。宣言的最后一句是：在这条路上，至少我们会让编程变得更有趣。
把整期听完，最有意思的地方在于这四个人的判断和行业主流叙事之间持续的张力。别人在说「agent 会接管一切」，他们说大部分编程的价值在迭代，而迭代需要人坐在驾驶座上。别人在比谁的模型参数更大，他们在比谁的 KV cache 更小、谁能在用户按下回车前就把 cache 预热好。别人在谈护城河，Michael 说的是「停止创新你就会输」。
Cursor 的差异不在某个单点。让一家公司站住的是整套东西：一堆自研模型、一层被反复推翻重做的 diff 界面、一套用 JSX 写的 prompt 渲染引擎、一棵可以逐层下钻的 Merkle 树，以及一个敢把「快就是好玩」当产品原则的团队。这些东西单拎出来都不性感，叠在一起才有那种「用过就回不去」的体感。
如果你现在就想用起来
把这一期的信息翻译成能立刻动手做的事，大概是下面这些：
- 把 Tab 当成主要输入方式，而非补全按钮。多按几次，看它能不能把你接下来几步都带过去。被拒绝了不要紧，那正是你在注入意图的地方，顺手多敲两个字符往往就校准了。
- 给危险代码加显式标记。如果某段逻辑出错能搞挂服务，就在函数里写清楚，必要时用全大写的警告重复几遍。这不是给同事看的，是给模型看的，今天的模型确实会对这类区域更警觉。
- 不要指望模型替你找 bug。它对「这段代码有多可疑」的校准很差。让它找 bug 时必须给它足够的上下文：运行日志、调用链、类型定义，以及这段代码有多关键。
- 写 prompt 时把「意图」和「上下文」分开想。先把你要什么说清楚，再想它需要看到哪些文件。如果它答非所问，先怀疑上下文没给够，别急着换措辞。
- 大改动别一次做完。展示两三个例子让 AI 铺开，遇到它不确定的地方你示范一次。这比事先在黑板上推演三天更划算，因为迭代成本已经被压下来了。
- 把重复性、规格明确的活儿攒起来交给 agent。比如「这个快捷键在某些情况下失效了，帮我修」，这类任务说清楚就能派出去。设计层面的取舍，留在自己手里。
- 审 AI 产出时先要一份导读。多文件大改动的话，与其从头翻 diff，不如先让模型告诉你该按什么顺序读、哪几块最值得细看。
- 如果模型突然「变笨」，先怀疑部署。同一家厂商不同云上的芯片、量化版本、数值精度都可能不一样，这类问题有真实的工程根源，不必先怀疑自己的判断。
- 给自己留一个「跑实验」的习惯。这次访谈里反复出现的一个判断是，这个领域仍然被想法限制。想到一个可能性就小规模跑一下，比在心里推演三小时更值。
最后留一句 Lex 在节目末尾念的、来自 Reddit 的段子：世界上没有比一个能用的临时方案更永恒的东西。这句话放在 AI 编程这个领域，意外的贴切。
The following is a conversation with the founding members of the Cursor team, Michael Truell, Sualeh Asif, Arvid Lunnemark, and Aman Sanger.
以下是与 Cursor 团队创始成员 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger 的对话。
00:00 Cursor is a code editor based on VS Code that adds a lot of powerful features for AI-assisted coding.
Cursor 是一个基于 VS Code 的代码编辑器，为 AI 辅助编码添加了很多强大的功能。
It has captivated the attention and excitement of the programming and AI communities.
它引起了编程和人工智能社区的关注和兴奋。
So I thought this is an excellent opportunity to dive deep into the role of AI in programming.
所以我认为这是一个深入研究人工智能在编程中的作用的绝佳机会。
This is a super technical conversation that is bigger than just about one code editor.
这是一场超级技术对话，其规模不仅仅是一个代码编辑器。
It’s about the future of programming and in general, the future of human AI collaboration in designing and engineering complicated and powerful systems.
它关系到编程的未来，以及人类人工智能在设计和工程复杂而强大的系统方面协作的未来。
This is the Lex Fridman podcast.
这是莱克斯·弗里德曼播客。
To support it, please check out our sponsors in the description.
为了支持它，请在说明中查看我们的赞助商。
And now, dear friends, here’s Michael, Sualeh, Arvid and Aman.
现在，亲爱的朋友们，这是迈克尔、苏阿莱、阿维德和阿曼。
00:59 All right, this is awesome.
好吧，这太棒了。
We have Michael, Aman, Sualeh, Arvid here from the Cursor team.
我们有来自 Cursor 团队的 Michael、Aman、Sualeh、Arvid。
First up, big ridiculous question.
首先，一个非常荒谬的问题。
What’s the point of a code editor?
代码编辑器有什么意义？
So the code editor is largely the place where you build software and today or for a long time, that’s meant the place where you text edit a formal programming language.
因此，代码编辑器主要是您构建软件的地方，而在今天或很长一段时间内，这意味着您对正式编程语言进行文本编辑的地方。
01:10 And for people who aren’t programmers, the way to think of a code editor is a really souped up word processor for programmers, where the reason it’s souped up is code has a lot of structure.
对于不是程序员的人来说，可以将代码编辑器视为程序员的一个真正增强的文字处理器，其增强的原因是代码具有很多结构。
And so the “word processor,” the code editor can actually do a lot for you that word processors sort of in the writing space haven’t been able to do for people editing texts there.
因此，“文字处理器”、代码编辑器实际上可以为您做很多事情，而在写作空间中的文字处理器却无法为在那里编辑文本的人做很多事情。
01:42 And so that’s everything from giving you visual differentiation of the actual tokens in the code so you can scan it quickly to letting you navigate around the code base, sort of like you’re navigating around the internet with hyperlinks, you’re going to definitions of things you’re using to error checking to catch rudimentary bugs.
因此，这就是一切，从为您提供代码中实际标记的视觉区分，以便您可以快速扫描它，到让您在代码库中导航，有点像您使用超链接在互联网上导航，您将使用错误检查来捕获基本错误的事物的定义。
And so traditionally that’s what a code editor has meant.
传统上这就是代码编辑器的含义。
And I think that what a code editor is is going to change a lot over the next 10 years as what it means to build software maybe starts to look a bit different.
我认为代码编辑器的含义将在未来 10 年发生很大变化，因为构建软件的含义可能开始看起来有点不同。
I think also a code editor should just be fun.
我认为代码编辑器也应该很有趣。
Yes, that is very important.
是的，这非常重要。
02:19 That is very important.
这非常重要。
And it’s actually sort of an underrated aspect of how we decide what to build.
这实际上是我们决定构建什么的一个被低估的方面。
A lot of the things that we build and then we try them out, we do an experiment and then we actually throw them out because they’re not fun.
我们构建了很多东西，然后我们尝试它们，我们做了实验，然后我们实际上把它们扔掉了，因为它们不好玩。
And so a big part of being fun is being fast a lot of the time.
因此，乐趣的一个重要部分就是很多时候速度快。
Fast is fun.
快就是有趣。
Yeah, fast is…
是的，快就是……
02:42 That should be a T-shirt.
那应该是一件T恤。
Fundamentally, I think one of the things that draws a lot of people to building stuff on computers is this insane iteration speed, where in other disciplines you might be sort of gate capped by resources or the ability…
从根本上说，我认为吸引很多人在计算机上构建东西的原因之一就是这种疯狂的迭代速度，而在其他学科中，你可能会受到资源或能力的限制......
02:48 Even the ability to get a large group together and coding is this amazing thing where it’s you and the computer and that alone, you can build really cool stuff really quickly.
即使是让一大群人聚集在一起进行编码的能力也是一件令人惊奇的事情，只要你和计算机，你就可以很快地构建出非常酷的东西。
So for people who don’t know, Cursor is this super cool new editor that’s a fork of VS Code.
对于那些不知道的人来说，Cursor 是一个超级酷的新编辑器，它是 VS Code 的一个分支。
03:09 It would be interesting to get your explanation of your own journey of editors.
得到你对你自己的编辑之旅的解释会很有趣。
I think all of you were big fans of VS Code with Copilot.
我想你们都是 VS Code with Copilot 的忠实粉丝。
How did you arrive to VS Code and how did that lead to your journey with Cursor?
您是如何接触 VS Code 的？这又是如何开启您的 Cursor 之旅的？
Yeah, so I think a lot of us…
是的，所以我认为我们很多人......
03:33 Well, all of us were originally [inaudible 00:03:39] users.
好吧，我们所有人最初都是 [听不清 00:03:39] 用户。
Pure Vim.
纯粹的维姆。
Pure Vim.
纯粹的维姆。
03:40 Yeah.
是的。
No Neovim, just Pure Vim and a terminal.
没有 Neovim，只有 Pure Vim 和一个终端。
And at least for myself, it was around the time that Copilot came out, so 2021 that I really wanted to try it.
至少对我自己来说，那是 Copilot 出来的时候，所以 2021 年我真的很想尝试一下。
So I went into VS Code, the only code editor in which it was available, and even though I really enjoyed using Vim, just the experience of Copilot with VS Code was more than good enough to convince me to switch.
所以我进入了 VS Code，这是唯一可用的代码编辑器，尽管我真的很喜欢使用 Vim，但 Copilot 使用 VS Code 的体验就足以说服我切换。
And so that kind of was the default until we started working on Cursor.
因此，在我们开始研究 Cursor 之前，这种情况是默认的。
And maybe we should explain what Copilot does.
也许我们应该解释一下 Copilot 的作用。
04:14 It’s a really nice auto complete.
这是一个非常好的自动完成功能。
As you start writing a thing, it suggests one or two or three lines how to complete the thing.
当你开始写一篇文章时，它会建议一两行或三行如何完成这篇文章。
And there’s a fun experience in that.
这其中有一个有趣的经历。
You know like when you have a close friendship and your friend completes your sentences?
你知道当你有亲密的友谊并且你的朋友完成你的句子时吗？
When it’s done well, there’s an intimate feeling.
做得好的时候，会有一种亲密的感觉。
There’s probably a better word than intimate, but there’s a cool feeling of holy shit, it gets me.
也许有比“亲密”更好的词了，但有一种很酷的感觉，这让我着迷。
And then there’s an unpleasant feeling when it doesn’t get you.
然后，当它无法吸引你时，你就会有一种不愉快的感觉。
And so there’s that kind of friction.
所以就存在这种摩擦。
But I would say for a lot of people, the feeling that it gets me overpowers that it doesn’t.
但我想说，对于很多人来说，它让我感动的感觉压倒了它不让我感动的感觉。
And I think actually one of the underrated aspects of Github Copilot is that even when it’s wrong, it’s a little bit annoying, but it’s not that bad because you just type another character and then maybe then it gets you, or you type another character and then it gets you.
我认为实际上 Github Copilot 被低估的一个方面是，即使它是错误的，它也有点烦人，但它并没有那么糟糕，因为你只需输入另一个字符，然后它可能会抓住你，或者你键入另一个字符，然后它会抓住你。
04:55 So even when it’s wrong, it’s not that bad.
所以即使是错的，也没有那么糟糕。
You can sort of iterate and fix it.
您可以进行迭代并修复它。
05:09 I mean, the other underrated part of Copilot for me was just the first real AI product.
我的意思是，对我来说，Copilot 的另一个被低估的部分只是第一个真正的人工智能产品。
So the first language model consumer product.
所以第一个语言模型是消费产品。
So Copilot was kind of like the first killer app for LMs.
所以 Copilot 有点像 LM 的第一个杀手级应用程序。
Yeah.
是的。
05:25 And the beta was out in 2021.
测试版已于 2021 年推出。
Right.
对。
05:29 Okay.
好的。
So what’s the origin story of Cursor?
那么 Cursor 的起源故事是什么呢？
So around 2020, the scaling loss papers came out from OpenAI and that was a moment where this looked like clear predictable progress for the field where even if we didn’t have any more ideas, it looked like you could make these models a lot better if you had more compute and more data.
因此，在 2020 年左右，OpenAI 发表了缩放损失论文，在那一刻，这看起来像是该领域明显可预测的进展，即使我们没有更多的想法，如果你有更多的计算和更多的数据，看起来你可以使这些模型变得更好。
By the way, we’ll probably talk for three to four hours on the topic of scaling loss.
顺便说一句，我们可能会就缩放损失这个话题讨论三到四个小时。
05:49 But just to summarize, it’s a paper in a set of papers in a set of ideas that say bigger might be better for model size and data size in the realm of machine learning.
但总而言之，这是一系列论文中的一篇论文，其中的一系列想法表明，机器学习领域的模型大小和数据大小可能越大越好。
It’s bigger and better, but predictably better.
它更大更好，但可以预见的是更好。
Okay, that’s another topic of conversation.
好吧，这是另一个话题了。
Yes.
是的。
06:10 Yeah.
是的。
So around that time for some of us, there were a lot of conceptual conversations about what’s this going to look like?
所以在那段时间，对于我们中的一些人来说，有很多关于这会是什么样子的概念性对话？
06:11 What’s the story going to be for all these different knowledge worker fields about how they’re going to be made better by this technology getting better?
对于所有这些不同的知识工作者领域来说，关于如何通过这项技术变得更好来使他们变得更好，故事将会是什么？
And then I think there were a couple of moments where the theoretical gains predicted in that paper started to feel really concrete and it started to feel like a moment where you could actually go and not do a PhD if you wanted to do useful work in AI.
然后我认为，有几个时刻，该论文中预测的理论成果开始变得非常具体，并且开始感觉如果你想在人工智能领域做有用的工作，你实际上可以直接去读博士，而不是攻读博士学位。
It actually felt like now there was this whole set of systems one could build that were really useful.
实际上感觉现在有一整套可以构建的非常有用的系统。
And I think that the first moment we already talked about a little bit, which was playing with the early beta of Copilot, that was awesome and magical.
我认为我们在第一时间就已经讨论过一点，那就是玩 Copilot 的早期测试版，这真是太棒了，太神奇了。
06:51 I think that the next big moment where everything kind of clicked together was actually getting early access to GPT-IV.
我认为，所有事情齐头并进的下一个重要时刻实际上是尽早访问 GPT-IV。
So it was sort of end of 2022 was when we were tinkering with that model and the step-upping capabilities felt enormous.
因此，大约在 2022 年底，我们正在修改该模型，感觉提升的能力是巨大的。
And previous to that, we had been working on a couple of different projects.
在此之前，我们一直在研究几个不同的项目。
Because of Copilot, because of scaling odds, because of our prior interest in the technology, we had been tinkering around with tools for programmers, but things that are very specific.
由于 Copilot，由于扩展可能性，由于我们之前对技术的兴趣，我们一直在为程序员修补工具，但事情非常具体。
So we were building tools for financial professionals who have to work within a Jupyter Notebook or playing around with can you do static analysis with these models?
因此，我们正在为必须在 Jupyter Notebook 中工作或尝试使用这些模型进行静态分析的金融专业人士构建工具。
07:29 And then the step-up in GPT- IV felt like, look, that really made concrete the theoretical gains that we had predicted before.
然后，GPT-IV 的进步让人感觉，看，这确实使我们之前预测的理论成果具体化了。
It felt like you could build a lot more just immediately at that point in time.
感觉就像你可以在那个时间点立即建造更多东西。
And also if we were being consistent, it really felt like this wasn’t just going to be a point solution thing.
而且，如果我们保持一致，就会感觉这不仅仅是一个点解决方案。
This was going to be all of programming was going to flow through these models and it felt like that demanded a different type of programming environment, a different type of programming.
这将是所有编程都将流经这些模型，感觉这需要不同类型的编程环境、不同类型的编程。
And so we set off to build that sort of larger vision around then.
因此，我们开始围绕那时建立更大的愿景。
There’s one that I distinctly remember.
有一个我记得很清楚。
07:59 So my roommate is an IMO Gold winner and there’s a competition in the US called the PUTNAM, which is sort of the IMO for college people and it’s this math competition.
我的室友是 IMO 金牌得主，美国有一个名为 PUTNAM 的竞赛，这有点像 IMO 面向大学生的数学竞赛。
It’s exceptionally good.
非常好。
So Shengtong and Aman I remember, sort of June of 2022, had this bet on whether the 2024 June or July you were going to win a gold medal in the IMO with models.
我记得盛通和安缦大概是在 2022 年 6 月的时候，打赌在 2024 年 6 月或 7 月你是否会赢得 IMO 模型金牌。
IMO is the International Math Olympiad.
IMO是国际数学奥林匹克竞赛。
Yeah, IMO is International Math Olympiad.
是的，IMO 是国际数学奥林匹克竞赛。
08:33 And so Arvid and I are both also competing in it.
所以我和阿维德也都参与其中。
So it was sort of personal and I remember thinking, Matt, this is not going to happen.
所以这有点个人化，我记得我当时想，马特，这不会发生。
Even though I sort of believed in progress, I thought IMO Gold, Aman is delusional.
尽管我有点相信进步，但我认为安缦黄金是一种妄想。
And to be honest, I mean, I was, to be clear, very wrong.
说实话，我的意思是，明确地说，我是非常错误的。
But that was maybe the most prescient bet in the group.
但这可能是该团队中最有先见之明的赌注。
So the new results from DeepMind, it turned out that you were correct.
所以 DeepMind 的新结果，证明你是正确的。
Technically not.
从技术上讲不是。
Technically incorrect but one point away.
技术上不正确，但还差一分。
Aman was very enthusiastic about this stuff back then and before, Aman had this scaling loss T-shirt that he would wear around where it had the charts and the formulas on it.
阿曼当时对这些东西非常热衷，在此之前，阿曼有一件缩放损失 T 恤，他会穿在上面有图表和公式的地方。
So you felt the AGI or you felt the scaling loss.
所以你感受到了 AGI 或者你感受到了缩放损失。
Yeah, I distinctly remember there was this one conversation I had with Michael before I hadn’t thought super deeply and critically about scaling laws and he kind of posed the question, why isn’t scaling all you need or why isn’t scaling going to result in massive gains in progress?
是的，我清楚地记得在我没有对缩放法则进行非常深入和批判性的思考之前，我与迈克尔进行了一次对话，他提出了一个问题，为什么缩放不能满足你的需要，或者为什么缩放不会带来巨大的进步？
09:28 And I think I went through the stages of grief.
我想我经历了悲伤的阶段。
There is anger, denial, and then finally at the end just thinking about it, acceptance.
有愤怒，有否认，最后只要想一想，就接受了。
And I think I’ve been quite hopeful and optimistic about progress since.
我想从那时起我就对进展充满希望和乐观。
I think one thing I’ll caveat is I think it also depends on which domains you’re going to see progress.
我想我要注意的一件事是，我认为这还取决于您将在哪些领域看到进展。
Math is a great domain especially formal theorem proving because you get this fantastic signal of actually verifying if the thing was correct.
数学是一个伟大的领域，尤其是形式定理证明，因为你会得到这个奇妙的信号，实际验证事情是否正确。
And so this means something like RL can work really, really well and I think you could have systems that are perhaps very superhuman in math and still not technically have AGI.
所以这意味着像强化学习这样的东西可以工作得非常非常好，我认为你可能拥有在数学上可能非常超人的系统，但在技术上仍然不具备通用人工智能。
Okay, so can we take it all the way to Cursor.
好的，我们可以把它一直带到 Cursor 吗？
10:27 And what is Cursor?
什么是游标？
It’s a fork of VS Code and VS Code is one of the most popular editors for a long time.
它是 VS Code 的一个分支，VS Code 是长期以来最受欢迎的编辑器之一。
Everybody fell in love with it.
每个人都爱上了它。
Everybody left Vim, I left DMAX for it.
每个人都离开了 Vim，我也为此离开了 DMAX。
Sorry.
对不起。
So unified in some fundamental way the developer community.
因此以某种基本方式统一了开发者社区。
And then you look at the space of things, you look at the scaling laws, AI is becoming amazing and you decided okay, it’s not enough to just write an extension via VS Code because there’s a lot of limitations to that.
然后你看看事物的空间，你看看缩放法则，人工智能正在变得令人惊奇，你决定好吧，仅仅通过 VS Code 编写扩展是不够的，因为这有很多限制。
If AI is going to keep getting better and better and better, we need to really rethink how the AI is going to be part of the editing process.
如果人工智能要不断变得越来越好，我们需要真正重新思考人工智能将如何成为编辑过程的一部分。
And so you decided to fork VS Code and start to build a lot of the amazing features we’ll be able to talk about.
因此，您决定分叉 VS Code 并开始构建许多我们将能够讨论的令人惊叹的功能。
But what was that decision like?
但这个决定是什么样的呢？
Because there’s a lot of extensions, including Copilot, of VS Code that are doing sort of AI type stuff.
因为 VS Code 的很多扩展（包括 Copilot）都在做人工智能类型的事情。
What was the decision like to just fork VS Code?
只分叉 VS Code 的决定是什么样的？
So the decision to do an editor seemed kind of self-evident to us for at least what we wanted to do and achieve because when we started working on the editor, the idea was these models are going to get much better, their capabilities are going to improve and it’s going to entirely change how you build software, both in a you will have big productivity gains but also radical and now the active building software is going to change a lot.
因此，做一个编辑器的决定对我们来说似乎是不言而喻的，至少对于我们想要做和实现的目标来说，因为当我们开始开发编辑器时，我们的想法是这些模型将会变得更好，它们的功能将会提高，并且它将完全改变你构建软件的方式，你将获得巨大的生产力提升，而且也是激进的，现在活跃的构建软件将会发生很大的变化。
11:33 And so you’re very limited in the control you have over a code editor if you’re a plugin to an existing coding environment and we didn’t want to get locked in by those limitations.
因此，如果您是现有编码环境的插件，那么您对代码编辑器的控制就非常有限，并且我们不想受到这些限制的限制。
We wanted to be able to just build the most useful stuff.
我们希望能够构建最有用的东西。
Okay.
好的。
12:08 Well then the natural question is, VS Code is kind of with Copilot a competitor, so how do you win?
那么自然的问题是，VS Code 与 Copilot 是竞争对手，那么如何获胜呢？
Is it basically just the speed and the quality of the features?
基本上只是功能的速度和质量吗？
Yeah, I mean I think this is a space that is quite interesting, perhaps quite unique where if you look at previous tech waves, maybe there’s kind of one major thing that happened and it unlocked a new wave of companies, but every single year, every single model capability or jump you get in model capabilities, you now unlock this new wave of features, things that are possible, especially in programming.
是的，我的意思是，我认为这是一个非常有趣的空间，也许非常独特，如果你看看以前的技术浪潮，也许发生了一件重大事情，它开启了新一波公司，但每一年，每一个模型功能或你在模型功能中获得的每一个跳跃，你现在都解锁了这一新的功能浪潮，这些都是可能的，尤其是在编程方面。
12:20 And so I think in AI programming, being even just a few months ahead, let alone a year ahead makes your product much, much, much more useful.
因此，我认为在人工智能编程中，即使提前几个月，更不用说提前一年，也会让你的产品变得更加有用。
I think the Cursor a year from now will need to make the Cursor of today look obsolete.
我认为一年后的 Cursor 将需要让今天的 Cursor 看起来过时。
And I think Microsoft has done a number of fantastic things, but I don’t think they’re in a great place to really keep innovating and pushing on this in the way that a startup can.
我认为微软已经做了很多了不起的事情，但我不认为他们处于一个像初创公司那样真正持续创新和推动这一点的好地方。
Just rapidly implementing features.
只是快速实现功能。
Yeah.
是的。
13:16 And kind of doing the research experimentation necessary to really push the ceiling.
并进行必要的研究实验来真正突破天花板。
I don’t know if I think of it in terms of features as I think of it in terms of capabilities for programmers.
我不知道我是否从功能的角度来看待它，就像我从程序员的能力的角度来看待它一样。
13:24 As the new O1 model came out, and I’m sure there are going to be more models of different types, like longer context and maybe faster, there’s all these crazy ideas that you can try and hopefully 10% of the crazy ideas will make it into something kind of cool and useful and we want people to have that sooner.
随着新的 O1 模型的出现，我确信将会有更多不同类型的模型，比如更长的上下文，甚至更快，你可以尝试所有这些疯狂的想法，希望 10% 的疯狂想法能够使其成为某种酷而有用的东西，我们希望人们尽快拥有它。
To rephrase, an underrated fact is we’re making it for ourself.
换句话说，一个被低估的事实是我们正在为自己制造它。
13:59 When we started Cursor, you really felt this frustration that models…
当我们启动 Cursor 时，您确实感受到了建模的挫败感……
You could see models getting better, but the Copilot experience had not changed.
你可以看到模型变得更好，但副驾驶体验并没有改变。
It was like, man, these guys, the ceiling is getting higher, why are they not making new things?
就像，伙计，这些家伙，天花板越来越高，为什么他们不创造新东西？
They should be making new things.
他们应该创造新事物。
Where’s all the alpha features?
所有 alpha 功能在哪里？
There were no alpha features.
没有阿尔法功能。
I’m sure it was selling well.
我确信它卖得很好。
I’m sure it was a great business, but it didn’t feel…
我确信这是一项伟大的事业，但感觉并不……
I’m one of these people that really want to try and use new things and there was no new thing for a very long while.
我是那些真正想尝试和使用新事物的人之一，但很长一段时间以来都没有新事物。
Yeah, it’s interesting.
是的，这很有趣。
14:35 I don’t know how you put that into words, but when you compare a Cursor with Copilot, Copilot pretty quickly started to feel stale for some reason.
我不知道你是如何用语言表达的，但是当你将 Cursor 与 Copilot 进行比较时，Copilot 很快就因为某种原因开始感到陈旧。
Yeah, I think one thing that I think helps us is that we’re sort of doing it all in one where we’re developing the UX and the way you interact with the model at the same time as we’re developing how we actually make the model give better answers.
是的，我认为对我们有帮助的一件事是，我们在开发用户体验以及与模型交互的方式的同时，同时也在开发如何让模型给出更好的答案。
14:45 So how you build up the prompt or how do you find the context and for a Cursor Tab, how do you train the model?
那么，如何构建提示或如何找到上下文，对于光标选项卡，如何训练模型？
So I think that helps us to have all of it the same people working on the entire experience [inaudible 00:15:17] .
因此，我认为这有助于我们让同一个人致力于整个体验 [听不清 00:15:17]。
Yeah, it’s like the person making the UI and the person training the model sit like 18 feet away-
是的，就像制作 UI 的人和训练模型的人坐在 18 英尺远的地方一样 -
Often the same person even.
甚至经常是同一个人。
Yeah, often even the same person.
是的，甚至经常是同一个人。
15:25 You can create things that are sort of not possible if you’re not talking, you’re not experimenting.
如果你不说话，不做实验，你可以创造出一些不可能的东西。
And you’re using, like you said, Cursor to write Cursor?
正如你所说，你正在使用 Cursor 来编写 Cursor？
Of course.
当然。
Oh yeah.
哦，是的。
Well let’s talk about some of these features.
好吧，让我们来谈谈其中的一些功能。
15:38 Let’s talk about the all-knowing the all-powerful praise be to the Tab, auto complete on steroids basically.
让我们谈谈对选项卡的无所不知的全能赞扬，基本上是类固醇的自动完成。
So how does Tab work?
那么 Tab 是如何工作的呢？
What is Tab?
什么是选项卡？
To highlight and summarize at a high level, I’d say that there are two things that Cursor is pretty good at right now.
为了在高层次上强调和总结，我想说 Cursor 目前非常擅长两件事。
15:53 There are other things that it does, but two things that it helps programmers with.
它还可以做其他事情，但有两件事它可以帮助程序员。
One is this idea of looking over your shoulder and being a really fast colleague who can kind of jump ahead of you and type and figure out what you’re going to do next.
其中一个想法是，你要时刻关注自己，成为一名速度非常快的同事，他可以跳到你前面，打字并弄清楚你下一步要做什么。
And that was the original idea behind…
这就是背后的最初想法……
That was kind of the kernel of the idea behind a good auto complete was predicting what you’re going to do next, but you can make that concept even more ambitious by not just predicting the characters after your Cursor but actually predicting the next entire change you’re going to make, the next diff, next place you’re going to jump to.
良好的自动完成背后的想法的核心是预测你下一步要做什么，但是你可以使这个概念更加雄心勃勃，不仅是预测光标之后的字符，而且实际上预测你将要进行的下一个整体更改，下一个差异，你要跳转到的下一个地方。
16:35 And the second thing Cursor is pretty good at right now too is helping you sometimes jump ahead of the AI and tell it what to do and go from instructions to code.
Cursor 现在也非常擅长的第二件事是帮助你有时超越人工智能并告诉它要做什么并从指令到代码。
And on both of those we’ve done a lot of work on making the editing experience for those things ergonomic and also making those things smart and fast.
在这两个方面，我们做了很多工作，使这些内容的编辑体验符合人体工程学，并使这些内容变得智能和快速。
One of the things we really wanted was we wanted the model to be able to edit code for us.
我们真正想要的事情之一是我们希望模型能够为我们编辑代码。
16:54 That was kind of a wish and we had multiple attempts at it before we had a good model that could edit code for you.
这是一种愿望，在我们拥有一个可以为您编辑代码的良好模型之前，我们进行了多次尝试。
Then after we had a good model, I think there’ve been a lot of effort to make the inference fast for having a good experience, and we’ve been starting to incorporate…
然后，在我们有了一个好的模型之后，我认为我们已经付出了很多努力来加快推理速度，以获得良好的体验，并且我们已经开始整合……
I mean, Michael sort of mentioned this ability to jump to different places and that jump to different places I think came from a feeling of once you accept an edit, it’s like man, it should be just really obvious where to go next.
我的意思是，迈克尔提到了这种跳转到不同地方的能力，我认为这种跳转到不同地方的感觉来自于一旦你接受编辑，就像男人一样，下一步该去哪里应该是非常明显的。
It’s like I’d made this change, the model should just know that the next place to go to is 18 lines down.
就像我做了这个改变一样，模型应该知道下一个要去的地方是 18 行以下。
If you’re a WIM user, you could press 18JJ or whatever, but why am I doing this?
如果你是 WIM 用户，你可以按 18JJ 或其他什么，但我为什么要这样做呢？
The model should just know it.
模型应该知道这一点。
17:54 So the idea was you just press Tab, it would go 18 lines down and then show you the next edit and you would press Tab, so as long as you could keep pressing Tab.
所以我们的想法是你只要按 Tab 键，它就会向下移动 18 行，然后向你显示下一个编辑，你会按 Tab 键，所以只要你可以一直按 Tab 键。
And so the internal competition was, how many Tabs can we make someone press?
因此内部竞争是，我们可以让某人按多少个 Tab？
Once you have the idea, more abstractly, the thing to think about is how are the edits zero entropy?
一旦你有了想法，更抽象地说，要考虑的是编辑如何为零熵？
So once you’ve expressed your intent and the edit is…
因此，一旦您表达了您的意图并且编辑就是......
There’s no new bits of information to finish your thought, but you still have to type some characters to make the computer understand what you’re actually thinking, then maybe the model should just sort of read your mind and all the zero entropy bits should just be like tabbed away.
没有新的信息来完成你的想法，但你仍然需要输入一些字符来让计算机理解你实际上在想什么，那么也许模型应该只是读懂你的想法，所有的零熵位应该就像被标签掉一样。
That was sort of the abstract version.
这是一种抽象版本。
There’s this interesting thing where if you look at language model loss on different domains, I believe the bits per byte, which is a kind of character normalize loss for code is lower than language, which means in general there are a lot of tokens in code that are super predictable, a lot of characters that are super predictable.
有一件有趣的事情是，如果你看看不同领域的语言模型损失，我相信每字节的位数（代码的一种字符标准化损失）低于语言，这意味着通常代码中有很多标记是超级可预测的，很多字符是超级可预测的。
18:42 And this is I think even magnified when you’re not just trying to auto complete code, but predicting what the user’s going to do next in their editing of existing code.
我认为，当您不仅仅是尝试自动完成代码，而是预测用户在编辑现有代码时下一步要做什么时，这一点甚至会被放大。
And so the goal of Cursor Tab is let’s eliminate all the low entropy actions you take inside of the editor.
因此，光标选项卡的目标是消除您在编辑器内执行的所有低熵操作。
When the intent is effectively determined, let’s just jump you forward in time, skip you forward.
当意图被有效确定后，我们就让你及时前进，跳过你前进。
Well, what’s the intuition and what’s the technical details of how to do next Cursor prediction?
那么，下一步如何进行游标预测的直觉和技术细节是什么？
19:22 That jump, that’s not so intuitive I think to people.
我认为对于人们来说，这种跳跃并不那么直观。
Yeah.
是的。
19:31 I think I can speak to a few of the details on how to make these things work.
我想我可以谈谈如何使这些事情发挥作用的一些细节。
They’re incredibly low latency, so you need to train small models on this task.
它们的延迟非常低，因此您需要针对此任务训练小型模型。
In particular, they’re incredibly pre-fill token hungry.
特别是，他们非常渴望预填充代币。
What that means is they have these really, really long prompts where they see a lot of your code and they’re not actually generating that many tokens.
这意味着他们有这些非常非常长的提示，他们看到了很多代码，但实际上并没有生成那么多令牌。
And so the perfect fit for that is using a sparse model, meaning an MOE model.
因此，最适合的方法是使用稀疏模型，即 MOE 模型。
So that was one breakthrough we made that substantially improved its performance at longer context.
因此，这是我们取得的一项突破，大大提高了其在更长期背景下的性能。
The other being a variant of speculative decoding that we built out called speculative edits.
另一个是我们构建的推测性解码的变体，称为推测性编辑。
These are two, I think, important pieces of what make it quite high quality and very fast.
我认为，这是使其质量非常高且速度非常快的两个重要因素。
Okay, so MOE [inaudible 00:20:22], the input is huge, the output is small.
好的，所以 MOE [听不清 00:20:22]，输入很大，输出很小。
Yeah.
是的。
Okay.
好的。
20:25 So what else can you say about how to make…
那么关于如何制作……你还能说些什么吗？
Does caching play a role-
缓存是否发挥作用 -
Oh, caching plays a huge role.
哦，缓存起着巨大的作用。
20:30 Because you’re dealing with this many input tokens, if every single keystroke that you’re typing in a given line you had to rerun the model on all of those tokens passed in, you’re just going to one, significantly degrade latency, two, you’re going to kill your GPUs with load.
因为您要处理如此多的输入令牌，所以如果您在给定行中键入的每一次击键都必须对传入的所有这些令牌重新运行模型，那么您只会出现一，显着降低延迟，二，您将因负载而杀死 GPU。
So you need to design the actual prompts you use for the model such that they’re caching aware.
因此，您需要设计用于模型的实际提示，以便它们能够感知缓存。
And then yeah, you need to reuse the KV cache across requests just so that you’re spending less work, less compute.
然后，是的，您需要跨请求重用 KV 缓存，这样您就可以减少工作量和计算量。
Again, what are the things that Tab is supposed to be able to do in the near term, just to linger on that?
再说一遍，Tab 在短期内应该能够做哪些事情，只是停留在这个问题上？
21:04 Generate code, fill empty space, also edit code across multiple lines and then jump to different locations inside the same file and then-
生成代码，填充空白区域，还可以跨多行编辑代码，然后跳转到同一文件内的不同位置，然后-
Hopefully jump to different files also.
希望也跳转到不同的文件。
21:25 So if you make an edit in one file and maybe you have to go to another file to finish your thought, it should go to the second file also.
因此，如果您在一个文件中进行编辑，并且可能必须转到另一个文件才能完成您的想法，那么它也应该转到第二个文件。
The full generalization is next action prediction.
完整的概括是下一个动作预测。
21:36 Sometimes you need to run a command in the terminal and it should be able to suggest the command based on the code that you wrote too, or sometimes you actually need to…
有时您需要在终端中运行命令，它应该能够根据您编写的代码建议该命令，或者有时您实际上需要......
It suggests something, but it’s hard for you to know if it’s correct because you actually need some more information to learn.
它暗示了一些东西，但你很难知道它是否正确，因为你实际上需要更多信息来学习。
You need to know the type to be able to verify that it’s correct.
您需要知道类型才能验证它是否正确。
And so maybe it should actually take you to a place that’s the definition of something and then take you back so that you have all the requisite knowledge to be able to accept the next completion.
因此，也许它实际上应该带你到一个定义某事物的地方，然后带你回去，以便你拥有能够接受下一个完成所需的所有必要知识。
So providing the human the knowledge.
因此为人类提供知识。
Yes.
是的。
Right.
正确的。
Yeah.
是的。
I just gotten to know a guy named Primeagen who I believe has an…
我刚刚认识了一个叫 Primeagen 的人，我相信他有……
22:19 You can order coffee via SSH.
您可以通过 SSH 订购咖啡。
Oh yeah.
哦，是的。
We did that.
我们做到了。
We did that.
我们做到了。
So can also the model do that and provide you with caffeine?
那么模型也能做到这一点并为你提供咖啡因吗？
22:31 Okay.
好的。
So that’s the general framework.
这就是总体框架。
Yeah.
是的。
22:39 And the magic moment would be if…
而神奇的时刻将是如果……
Programming is this weird discipline where sometimes the next five minutes, not always, but sometimes the next five minutes of what you’re going to do is actually predictable from the stuff you’ve done recently.
编程是一门奇怪的学科，有时（并非总是如此）接下来的五分钟，但有时你将要做的接下来五分钟的事情实际上可以从你最近所做的事情中预测出来。
And so can you get to a world where that next five minutes either happens by you disengaging and it taking you through?
那么，你能否进入一个这样的世界：接下来的五分钟要么是你脱离接触，然后它就会带你过去？
Or maybe a little bit more of just you seeing next step what it’s going to do and you’re like, okay, that’s good, that’s good, that’s good, that’s good, and you can just sort of tap, tap through these big changes.
或者也许更多的是你看到下一步要做什么，然后你会想，好吧，那很好，那很好，那很好，那很好，然后你就可以点击，点击这些重大变化。
As we’re talking about this, I should mention one of the really cool and noticeable things about Cursor is that there’s this whole diff interface situation going on.
当我们谈论这个时，我应该提到 Cursor 真正酷且引人注目的事情之一是，整个 diff 接口的情况正在发生。
23:09 So the model suggests with the red and the green of here’s how we’re going to modify the code, and in the chat window you can apply and it shows you the diff and you can accept the diff.
因此，模型用红色和绿色建议我们如何修改代码，在聊天窗口中您可以应用它，它会向您显示差异，您可以接受差异。
So maybe can you speak to whatever direction of that?
那么也许您可以谈谈这方面的任何方向吗？
We’ll probably have four or five different kinds of diffs.
我们可能会有四到五种不同类型的差异。
23:32 So we have optimized the diff for the auto complete, so that has a different diff interface than when you’re reviewing larger blocks of code.
因此，我们针对自动完成优化了 diff，因此与您查看较大代码块时相比，它具有不同的 diff 界面。
And then we’re trying to optimize another diff thing for when you’re doing multiple different files.
然后，当您处理多个不同的文件时，我们尝试优化另一个差异事物。
And at a high level, the difference is for when you’re doing auto- complete, it should be really, really fast to read.
从高层次来看，区别在于当你进行自动完成时，它的阅读速度应该非常非常快。
Actually it should be really fast to read in all situations, but in auto-complete your eyes are focused in one area, you can’t be in too many…
实际上，在所有情况下阅读都应该很快，但是在自动完成中，你的眼睛集中在一个区域，你不能集中在太多......
The humans can’t look in too many different places.
人类无法观察太多不同的地方。
So you’re talking about on the interface side?
那么你是在谈论界面方面吗？
On the interface side.
在接口方面。
24:17 So it currently has this box on this side.
所以目前它的这一侧有这个盒子。
So we have the current box, and it you tries to delete code in some place and tries to add other code, it tries to show you a box on the side.
因此，我们有当前的框，如果您尝试删除某个位置的代码并尝试添加其他代码，它会尝试在侧面显示一个框。
You can maybe show it if we pull it up in Cursor.com.
如果我们在 Cursor.com 中将其拉出，您也许可以显示它。
24:28 This is what we’re talking.
这就是我们正在谈论的。
So that box-
所以那个盒子——
Exactly here.
就在这里。
It was like three or four different attempts at trying to make this thing work where first the attempt was this blue crossed out line.
这就像三到四次不同的尝试，试图让这件事发挥作用，第一个尝试是这条蓝色划掉的线。
24:35 So before it was a box on the side, it used to show you the code to delete by showing you Google Docs style, you would see a line through it and then you would see the new code.
因此，在它成为侧面的一个框之前，它通常通过向您显示 Google 文档样式来向您显示要删除的代码，您会看到一条穿过它的线，然后您会看到新代码。
That was super distracting.
那真是太让人分心了。
And then we tried many different…
然后我们尝试了很多不同的……
There was deletions, there was trying the red highlight.
有删除，有尝试红色突出显示。
25:05 Then the next iteration of it, which is sort of funny, you would hold the, on Mac, the option button.
然后，在下一次迭代中，这有点有趣，您将在 Mac 上按住选项按钮。
So it would sort of highlight a region of code to show you that there might be something coming.
因此，它会突出显示某个代码区域，以向您表明可能会发生一些事情。
So maybe in this example, the input and the value would all get blue.
所以也许在这个例子中，输入和值都会变成蓝色。
And the blue was to highlight that the AI had a suggestion for you.
蓝色是为了强调人工智能为你提供了建议。
So instead of directly showing you the thing, it would just hint that the AI had a suggestion and if you really wanted to see it, you would hold the option button and then you would see the new suggestion.
因此，它不会直接向您展示该内容，而是只会暗示人工智能有一个建议，如果您确实想看到它，您可以按住选项按钮，然后您就会看到新的建议。
And if you release the option button, you would then see your original code.
如果松开选项按钮，您就会看到原始代码。
So by the way, that’s pretty nice, but you have to know to hold the option button.
顺便说一句，这很好，但你必须知道按住选项按钮。
Yeah.
是的。
And by the way, I’m not a Mac user, but I got it.
顺便说一句，我不是 Mac 用户，但我明白了。
25:51 Option.
选项。
It’s a button I guess you people have.
我想你们都有这个按钮。
Again, it’s just not intuitive.
再说一遍，这并不直观。
26:00 I think that’s the key thing.
我认为这是关键。
And there’s a chance this is also not the final version of it.
而且这也有可能不是它的最终版本。
I am personally very excited for making a lot of improvements in this area.
我个人对在这个领域做出很多改进感到非常兴奋。
26:07 We often talk about it as the verification problem where these diffs are great for small edits.
我们经常将其视为验证问题，其中这些差异非常适合小型编辑。
For large edits or when it’s multiple files or something, it’s actually a little bit prohibitive to review these diffs.
对于大型编辑或多个文件或其他内容时，检查这些差异实际上有点令人望而却步。
So there are a couple of different ideas here.
所以这里有一些不同的想法。
One idea that we have is, okay, parts of the diffs are important.
我们的一个想法是，部分差异很重要。
They have a lot of information.
他们有很多信息。
And then parts of the diff are just very low entropy.
然后部分差异的熵非常低。
They’re the same thing over and over again.
它们一遍又一遍地重复同样的事情。
And so maybe you can highlight the important pieces and then gray out the not so important pieces.
因此，也许您可以突出显示重要的部分，然后将不那么重要的部分灰显。
Or maybe you can have a model that looks at the diff and sees, oh, there’s a likely bug here.
或者也许你可以有一个模型来查看差异并发现，哦，这里可能存在错误。
I will mark this with a little red squiggly and say, you should probably review this part of the diff.
我会用一个红色的波浪线来标记它，并说，你应该检查一下差异的这一部分。
Ideas in that vein I think are exciting.
我认为这种想法令人兴奋。
Yeah, that’s a really fascinating space of UX design engineering.
是的，这确实是用户体验设计工程的一个令人着迷的领域。
27:11 So you’re basically trying to guide the human programmer through all the things they need to read and nothing more, optimally.
所以你基本上是在试图引导人类程序员以最佳方式完成他们需要阅读的所有内容，仅此而已。
And you want an intelligent model to do it.
你需要一个智能模型来做到这一点。
27:25 Currently, diff algorithms, they’re just like normal algorithms.
目前，diff 算法与普通算法一样。
There’s no intelligence.
没有智力。
There’s intelligence that went into designing the algorithm, but then you don’t care if it’s about this thing or this thing as you want the model to do this.
设计算法需要智慧，但你并不关心它是关于这个东西还是这个东西，因为你希望模型做到这一点。
So I think the general question is like, man, these models are going to get much smarter.
所以我认为普遍的问题是，这些模型将会变得更加智能。
27:47 As the models get much smarter, changes they will be able to propose are much bigger.
随着模型变得更加智能，他们能够提出的改变也会更大。
So as the changes gets bigger and bigger and bigger, the humans have to do more and more and more verification work.
因此，随着变化越来越大，人类必须做越来越多的验证工作。
It gets more and more and more…
它变得越来越多、越来越多……
You need to help them out.
你需要帮助他们。
I don’t want to spend all my time reviewing code.
我不想把所有时间都花在审查代码上。
Can you say a little more across multiple files [inaudible 00:28:19]?
您能对多个文件多说一点吗 [听不清 00:28:19]？
Yeah.
是的。
28:20 I mean, so GitHub tries to solve this with code review.
我的意思是，GitHub 尝试通过代码审查来解决这个问题。
When you’re doing code review, you’re reviewing multiple diffs across multiple files.
当您进行代码审查时，您正在审查多个文件中的多个差异。
But like Arvid said earlier, I think you can do much better than code review.
但正如 Arvid 之前所说，我认为你可以做得比代码审查更好。
Code review kind of sucks.
代码审查有点糟糕。
You spend a lot of time trying to grok this code that’s often quite unfamiliar to you and it often doesn’t even actually catch that many bugs.
您花费大量时间尝试理解这些对您来说通常很陌生的代码，而且它通常甚至没有真正捕获那么多错误。
And I think you can significantly improve that review experience using language models, for example, using the kinds of tricks that Arvid had described of maybe pointing you towards the regions that actually matter.
我认为你可以使用语言模型显着改善评论体验，例如，使用 Arvid 描述的各种技巧，这些技巧可能会引导你走向真正重要的区域。
I think also if the code is produced by these language models and it’s not produced by someone else…
我还认为，如果代码是由这些语言模型生成的，而不是由其他人生成的……
The code review experience is design for both the reviewer and the person that produced the code.
代码审查体验是为审查者和代码生成者设计的。
In the case where the person that produced the code is a language model, you don’t have to care that much about their experience and you can design the entire thing around the reviewer such that the reviewer’s job is as fun, as easy, as productive as possible.
如果生成代码的人是语言模型，则您不必太关心他们的体验，您可以围绕审阅者设计整个事物，以便审阅者的工作尽可能有趣、简单、高效。
I think that feels like the issue with just naively trying to make these things look like code review.
我认为这感觉像是天真地试图让这些事情看起来像代码审查的问题。
I think you can be a lot more creative and push the boundary on what’s possible.
我认为你可以更有创造力并突破可能的界限。
And just one idea there is, I think ordering matters.
只有一个想法，我认为顺序很重要。
29:43 Generally, when you review a PR, you have this list of files and you’re reviewing them from top to bottom, but actually, you actually want to understand this part first because that came logically first, and then you want to understand the next part and you don’t want to have to figure out that yourself, you want a model to.
一般来说，当你审查 PR 时，你会得到这个文件列表，并且你会从上到下审查它们，但实际上，你实际上想首先理解这一部分，因为这在逻辑上是第一位的，然后你想要理解下一部分，而你不想自己弄清楚，你想要一个模型。
30:00 And you don’t want to have to figure out that yourself.
而且你不想自己弄清楚这一点。
You want a model to guide you through the thing.
你需要一个模型来指导你完成这件事。
And is the step of creation going to be more and more natural language, is the goal versus with actual writing the book?
创作的步骤是否会越来越自然的语言，目标是否与实际写书相反？
I think sometimes.
我有时想。
30:12 I don’t think it’s going to be the case that all of programming will be natural language, and the reason for that is if I’m pair programming with Sualeh and Sualeh is at the computer and the keyboard, and sometimes if I’m driving, I want to say to Sualeh, “Hey, implement this function,” and that works.
我不认为所有的编程都将是自然语言，原因是如果我与 Sualeh 结对编程，而 Sualeh 是在计算机和键盘上，有时如果我在开车，我想对 Sualeh 说，“嘿，实现这个功能”，这样就可以了。
And then sometimes it’s just so annoying to explain to Sualeh what I want him to do, and so I actually take over the keyboard and I show him.
有时向 Sualeh 解释我想让他做什么真是太烦人了，所以我实际上接管了键盘并向他展示。
I write part of the example and then it makes sense and that’s the easiest way to communicate.
我写了部分示例，然后它就有意义了，这是最简单的沟通方式。
And so I think that’s also the case for AI.
所以我认为人工智能也是如此。
Sometimes the easiest way to communicate with the AI will be to show an example and then it goes and does the thing everywhere else.
有时，与人工智能交流的最简单方法是展示一个示例，然后它就会在其他地方执行该操作。
30:54 Or sometimes if you’re making a website for example, the easiest way to show to the AI what you want is not to tell it what to do but drag things around or draw things, and maybe eventually we will get to brain machine interfaces or whatever and you can understand what you’re thinking.
或者有时，如果你正在制作一个网站，向人工智能展示你想要什么的最简单方法不是告诉它做什么，而是拖动东西或画东西，也许最终我们会进入脑机接口或其他什么，你可以理解你在想什么。
And so I think natural language will have a place.
所以我认为自然语言将会占有一席之地。
I think it will definitely not be the way most people program most of the time.
我想这绝对不会是大多数人大多数时候的编程方式。
I’m really feeling the AGI with this editor.
我真的感受到了这个编辑器的 AGI。
31:20 It feels like there’s a lot of machine learning going on underneath.
感觉下面有很多机器学习在进行。
Tell me about some of the ML stuff that makes it all work?
请告诉我一些使这一切发挥作用的 ML 内容吗？
Where Cursor really works via this ensemble of custom models that we’ve trained alongside the frontier models that are fantastic at the reasoning intense things.
Cursor 真正发挥作用的地方是通过我们与前沿模型一起训练的自定义模型集合，这些模型在推理密集事物方面表现出色。
31:31 And so Cursor Tab for example, is a great example of where you can specialize this model to be, even better than even frontier models if you look at evals on the task we set it at.
例如，光标选项卡是一个很好的例子，说明您可以将这个模型专门化，如果您查看我们设置的任务的评估，甚至比前沿模型更好。
The other domain, which it’s surprising that it requires custom models but it’s necessary and works quite well, is in Apply.
另一个领域是Apply，它需要自定义模型，但它是必要的并且工作得很好，这令人惊讶。
So I think these models are…
所以我认为这些模型是……
The frontier models are quite good at sketching out plans for code and generating rough sketches of the change, but actually, creating diffs is quite hard for frontier models, for your training models.
前沿模型非常擅长绘制代码计划并生成更改的粗略草图，但实际上，对于前沿模型和训练模型来说，创建差异非常困难。
You try to do this with Sonnet, with o1, any frontier model and it really messes up stupid things like counting line numbers, especially in super, super large files.
你尝试用 Sonnet、o1、任何前沿模型来做到这一点，它确实会搞乱一些愚蠢的事情，比如计算行数，尤其是在超级、超级大的文件中。
And so what we’ve done to alleviate this is we let the model sketch out this rough code block that indicates what the change will be and we train a model to then Apply that change to the file.
因此，为了缓解这种情况，我们所做的就是让模型勾画出这个粗略的代码块，指示将要进行的更改，然后训练模型以将该更改应用到文件。
And we should say that Apply is the model looks at your code, it gives you a really damn good suggestion of what new things to do.
我们应该说，Apply 是查看您的代码的模型，它为您提供了关于要做哪些新事情的非常好的建议。
32:42 And the seemingly for humans trivial step of combining the two, you’re saying is not so trivial.
对于人类来说，将两者结合起来看似微不足道，但你却说这一步并不那么微不足道。
Contrary to popular perception, it is not a deterministic algorithm.
与流行的看法相反，它不是确定性算法。
Yeah, I think you see shallow copies of apply elsewhere and it just breaks most of the time because you think you can try to do some deterministic matching and then it fails at least 40% of the time and that just results in a terrible product experience.
是的，我认为您在其他地方看到了 apply 的浅拷贝，并且大多数时候它都会失败，因为您认为您可以尝试进行一些确定性匹配，然后它至少在 40% 的情况下失败，这只会导致糟糕的产品体验。
33:03 I think in general, this regime of you are going to get smarter and smarter models.
我认为总的来说，你们的这个政权将会得到越来越聪明的模型。
So one other thing that Apply lets you do is it lets you use fewer tokens with the most intelligent models.
因此，Apply 让您做的另一件事是，它可以让您在最智能的模型中使用更少的令牌。
This is both expensive in terms of latency for generating all these tokens and cost.
就生成所有这些令牌的延迟和成本而言，这都是昂贵的。
So you can give this very, very rough sketch and then have your model models go and implement it because it’s a much easier task to implement this very, very sketched out code.
因此，您可以给出这个非常非常粗略的草图，然后让您的模型模型去实现它，因为实现这个非常非常粗略的代码是一项容易得多的任务。
And I think that this regime will continue where you can use smarter and smarter models to do the planning and then maybe the implementation details can be handled by the less intelligent ones.
我认为这种制度将继续下去，你可以使用越来越聪明的模型来进行规划，然后也许实施细节可以由不太聪明的模型来处理。
Perhaps you’ll have maybe o1, maybe it’ll be even more capable models given an even higher level plan that is recursively applied by sauna and then the apply model.
也许你会有 o1，也许它会是更强大的模型，给出一个更高级别的计划，该计划由桑拿递归应用，然后应用模型。
Maybe we should talk about how to make it fast if you like.
如果你愿意的话，也许我们应该讨论一下如何让它变得更快。
34:16 Fast is always an interesting detail.
快速始终是一个有趣的细节。
Fast is good.
快就是好。
Yeah, how do you make it fast?
是啊，怎么才能快点呢？
Yeah, so one big component of making it fast is speculative edits.
是的，所以加快速度的一个重要组成部分是推测性编辑。
34:25 So speculative edits are a variant of speculative decoding, and maybe it’d be helpful to briefly describe speculative decoding.
因此，推测性编辑是推测性解码的一种变体，也许简要描述一下推测性解码会有所帮助。
With speculative decoding, what you do is you can take advantage of the fact that most of the time, and I’ll add the caveat that it would be when you’re memory bound in language model generation, if you process multiple tokens at once, it is faster than generating one token at a time.
通过推测性解码，您所做的是，您可以利用这样一个事实：大多数时候，我将添加一个警告，即当您在语言模型生成中受到内存限制时，如果一次处理多个标记，它比一次生成一个标记更快。
So this is the same reason why if you look at tokens per second with prompt tokens versus generated tokens, it’s much much faster for prompt tokens.
因此，这就是为什么如果您查看带有提示令牌和生成令牌的每秒令牌数，会发现提示令牌要快得多。
35:09 So what we do is instead of using what speculative decoding normally does, which is using a really small model to predict these draft tokens that your larger model will then go in and verify, with code edits, we have a very strong prior of what the existing code will look like and that prior is literally the same exact code.
因此，我们所做的不是使用推测性解码通常所做的事情，即使用一个非常小的模型来预测这些草稿标记，然后您的较大模型将进入并验证这些草稿标记，通过代码编辑，我们对现有代码的外观有一个非常强的先验，并且该先验实际上是相同的代码。
So you can do is you can just feed chunks of the original code back into the model, and then the model will just pretty much agree most of the time that, “Okay, I’m just going to spit this code back out.” And so you can process all of those lines in parallel and you just do this with sufficiently many chunks.
所以你可以做的是，你可以将原始代码块反馈回模型，然后模型在大多数情况下都会同意，“好吧，我只是要把这段代码吐出来。”因此，您可以并行处理所有这些行，并且只需使用足够多的块即可完成此操作。
And then eventually you’ll reach a point of disagreement where the model will now predict text that is different from the ground truth original code.
然后最终你会达到一个分歧点，模型现在将预测与真实原始代码不同的文本。
It’ll generate those tokens and then we will decide after enough tokens match the original code to re- start speculating in chunks of code.
它将生成这些令牌，然后我们将在足够的令牌与原始代码匹配后决定重新开始推测代码块。
36:02 What this actually ends up looking like is just a much faster version of normal editing code.
这实际上最终看起来只是普通编辑代码的更快版本。
So it looks like a much faster version of the model rewriting all the code.
所以它看起来像是一个更快的模型版本，重写了所有代码。
So we can use the same exact interface that we use for diffs, but it will just stream down a lot faster.
因此，我们可以使用与差异相同的接口，但它的传输速度会更快。
And then the advantage is that while it’s streaming, you can just also start reviewing the code before it’s done so there’s no big loading screen.
优点是，在流式传输时，您还可以在完成之前开始检查代码，这样就没有大的加载屏幕。
36:21 Maybe that is part of the advantage.
也许这就是优势的一部分。
So the human can start reading before the thing is done.
因此人们可以在事情完成之前开始阅读。
I think the interesting riff here is something like…
我认为这里有趣的即兴重复是这样的……
36:39 I feel like speculation is a fairly common idea nowadays.
我觉得现在投机是一个相当普遍的想法。
It’s not only in language models.
这不仅存在于语言模型中。
There’s obviously speculation in CPUs and there’s speculation for databases and there’s speculation all over the place.
显然，人们对 CPU 和数据库都有猜测，到处都有猜测。
Well, let me ask the ridiculous question of which LLM is better at coding?
好吧，让我问一个可笑的问题：哪个 LLM 更擅长编码？
36:54 GPT, Claude, who wins in the context of programming?
GPT、Claude，在编程方面谁胜出？
And I’m sure the answer is much more nuanced because it sounds like every single part of this involves a different model.
我确信答案更加微妙，因为听起来每个部分都涉及不同的模型。
I think there’s no model that Pareto dominates others, meaning it is better in all categories that we think matter, the categories being speed, ability to edit code, ability to process lots of code, long context, a couple of other things and coding capabilities.
我认为帕累托模型不存在优于其他模型的模型，这意味着它在我们认为重要的所有类别中都更好，这些类别包括速度、编辑代码的能力、处理大量代码的能力、长上下文、其他一些东西和编码能力。
37:12 The one that I’d say right now is just net best is Sonnet.
我现在想说的是，Sonnet 是最好的。
I think this is a consensus opinion.
我认为这是一个共识。
o1’s really interesting and it’s really good at reasoning.
o1真的很有趣，而且很擅长推理。
So if you give it really hard programming interview style problems or lead code problems, it can do quite well on them, but it doesn’t feel like it understands your rough intent as well as Sonnet does.
因此，如果你给它提供非常困难的编程面试风格问题或引导代码问题，它可以很好地解决它们，但感觉它不像 Sonnet 那样理解你的粗略意图。
If you look at a lot of the other frontier models, one qualm I have is it feels like they’re not necessarily over…
如果你看过很多其他前沿模型，我的一个疑虑是感觉它们不一定已经结束......
I’m not saying they train on benchmarks, but they perform really well in benchmarks relative to everything that’s in the middle.
我并不是说他们在基准测试上进行训练，但相对于中间的所有内容，他们在基准测试中表现得非常好。
So if you tried on all these benchmarks and things that are in the distribution of the benchmarks they’re evaluated on, they’ll do really well.
因此，如果您尝试了所有这些基准测试以及评估基准测试分布中的内容，它们会表现得非常好。
But when you push them a little bit outside of that, Sonnet is I think the one that does best at maintaining that same capability.
但当你把它们推向更远的地方时，我认为 Sonnet 是最能保持同样能力的。
You have the same capability in the benchmark as when you try to instruct it to do anything with coding.
当您尝试指示它执行任何编码操作时，您在基准测试中具有相同的功能。
Another ridiculous question is the difference between the normal programming experience versus what benchmarks represent?
另一个可笑的问题是正常编程体验与基准测试之间的差异？
38:38 Where do benchmarks fall short, do you think, when we’re evaluating these models?
您认为，当我们评估这些模型时，基准测试的不足之处在哪里？
By the way, that’s a really, really hard, critically important detail of how different benchmarks are versus real coding, where real coding, it’s not interview style coding.
顺便说一句，这是一个非常非常困难且至关重要的细节，说明不同的基准与真实编码有何不同，真正的编码不是面试风格的编码。
38:49 Humans are saying half-broken English sometimes and sometimes you’re saying, “Oh, do what I did before.” Sometimes you’re saying, “Go add this thing and then do this other thing for me and then make this UI element.” And then it’s just a lot of things are context dependent.
人类有时会说半蹩脚的英语，有时你会说，“哦，做我以前做过的事。”有时你会说，“去添加这个东西，然后为我做其他事情，然后制作这个 UI 元素。”而且很多事情都是依赖于上下文的。
You really want to understand the human and then do what the human wants, as opposed to this…
你真的想了解人类，然后做人类想要的事情，而不是这样……
Maybe the way to put it abstractly is the interview problems are very well specified.
也许抽象地说，面试问题是非常明确的。
They lean a lot on specification while the human stuff is less specified.
他们非常依赖规范，而人类的东西则较少指定。
I think that this benchmark question is both complicated by what Sualeh just mentioned, and then also what Aman was getting into is that even if you…
我认为这个基准问题因 Sualeh 刚才提到的内容而变得复杂，而且 Aman 所面临的问题是，即使你……
39:50 There’s this problem of the skew between what can you actually model in a benchmark versus real programming, and that can be sometimes hard to encapsulate because it’s real programming’s very messy and sometimes things aren’t super well specified what’s correct or what isn’t.
在基准测试中实际建模的内容与真实编程之间存在偏差的问题，有时很难封装，因为真实的编程非常混乱，有时事情并没有很好地指定什么是正确的或什么是错误的。
But then it’s also doubly hard because of this public benchmark problem.
但由于这个公共基准问题，这也变得加倍困难。
And that’s both because public benchmarks are sometimes hill climbed on, then it’s really, really hard to also get the data from the public benchmarks out of the models.
这都是因为公共基准有时是爬山的，那么从模型中获取公共基准的数据真的非常非常困难。
40:28 And so for instance, one of the most popular agent benchmarks, SWE-Bench, is really, really contaminated in the training data of these foundation models.
例如，最流行的代理基准测试之一 SWE-Bench 确实受到了这些基础模型的训练数据的污染。
And so if you ask these foundation models to do a SWE-Bench problem, but you actually don’t give them the context of a code base, they can hallucinate the right file pass, they can hallucinate the right function names.
因此，如果你要求这些基础模型做一个 SWE-Bench 问题，但实际上你没有给他们代码库的上下文，他们可以幻觉出正确的文件传递，他们可以幻觉出正确的函数名称。
And so it’s also just the public aspect of these things is tricky.
因此，这些事情的公共方面也很棘手。
In that case, it could be trained on the literal issues or pull requests themselves, and maybe the labs will start to do a better job or they’ve already done a good job at decontaminating those things, but they’re not going to omit the actual training data of the repository itself.
在这种情况下，它可以针对字面问题或拉取请求本身进行训练，也许实验室会开始做得更好，或者他们已经在净化这些东西方面做得很好，但他们不会忽略存储库本身的实际训练数据。
40:53 These are all some of the most popular Python repositories.
这些都是一些最流行的 Python 存储库。
SimPy is one example.
SimPy 就是一个例子。
I don’t think they’re going to handicap their models on SimPy and all these popular Python repositories in order to get true evaluation scores in these benchmarks.
我认为他们不会为了在这些基准测试中获得真实的评估分数而在 SimPy 和所有这些流行的 Python 存储库上限制他们的模型。
I think that given the dirts in benchmarks, there have been a few interesting crutches that places that build systems with these models or build these models actually use to get a sense of are they going the right direction or not.
我认为，考虑到基准测试中的污垢，已经有一些有趣的拐杖放置在使用这些模型构建系统或构建这些模型的实际用途中，以了解它们是否朝着正确的方向前进。
41:24 And in a lot of places, people will actually just have humans play with the things and give qualitative feedback on these.
在很多地方，人们实际上只是让人类玩这些东西并给出定性反馈。
One or two of the foundation model companies, they have people who that’s a big part of their role.
一两家基础模型公司，他们的员工是他们角色的重要组成部分。
And internally, we also qualitatively assess these models and actually lean on that a lot in addition to private emails that we have.
在内部，我们还对这些模型进行定性评估，并且除了我们拥有的私人电子邮件之外，实际上还非常依赖这些模型。
It’s like the vibe.
这就像氛围。
The vibe, yeah, the vibe.
氛围，是的，氛围。
It’s like the vibe.
这就像氛围。
The vibe benchmark, human benchmark, the humans.
氛围基准、人类基准、人类。
42:00 You pull in the humans to do a vibe check.
你拉人来进行氛围检查。
Yeah.
是的。
Okay.
好的。
42:06 That’s what I do.
这就是我所做的。
Just reading online forums and Reddit and X.
只是阅读在线论坛、Reddit 和 X。
Well, I don’t know how to properly load in people’s opinions because they’ll say things like, “I feel like Claude or GPT has gotten dumber,” or something.
好吧，我不知道如何正确地表达人们的意见，因为他们会说“我觉得克劳德或 GPT 变得更愚蠢了”之类的话。
They’ll say, “I feel like…” And then I sometimes feel like that too, but I wonder if it’s the model’s problem or mine.
他们会说，“我觉得……”有时我也会有这样的感觉，但我想知道这是模型的问题还是我的问题。
With Claude, there’s an interesting take I heard where I think AWS has different chips and I suspect they have slightly different numerics than Nvidia GPUs, and someone speculated that Claude’s degraded performance had to do with maybe using the quantized version that existed on AWS Bedrock versus whatever was running on Anthropics GPUs.
对于 Claude，我听到了一个有趣的看法，我认为 AWS 有不同的芯片，我怀疑它们的数字与 Nvidia GPU 略有不同，有人推测 Claude 性能下降可能与使用 AWS Bedrock 上存在的量化版本和 Anthropics GPU 上运行的任何版本有关。
I interview a bunch of people that have conspiracy theories.
我采访了一群有阴谋论的人。
43:00 I’m glad you spoke to this conspiracy.
我很高兴你谈到了这个阴谋。
Well, it’s not like conspiracy theory as much as humans.
嗯，这不像人类那样像阴谋论。
43:06 Humans are humans and there’s these details-
人类就是人类，有这些细节——
Yes.
是的。
And you’re doing this queasy amount of flops and chips are messy and man, you can just have bugs.
你正在做这么多令人作呕的失败，筹码很混乱，伙计，你可能会遇到错误。
43:14 It’s hard to overstate how hard bugs are to avoid.
很难夸大错误是多么难以避免。
What’s the role of a good prompt in all of this?
良好的提示在这一切中起什么作用？
43:28 We mentioned that benchmarks have really structured, well-formulated prompts.
我们提到基准测试有真正结构化、精心设计的提示。
What should a human be doing to maximize success and what’s the importance of what the humans…
人类应该做什么才能最大程度地取得成功以及人类所做的事情的重要性是什么……
You wrote a blog post on…
您写了一篇博文……
You called it Prompt Design.
你称之为“即时设计”。
Yeah, I think it depends on which model you’re using, and all of them are slightly different and they respond differently to different prompts, but I think the original GPT-4 and the original [inaudible 00:44:07] models last year, they were quite sensitive to the prompts, and they also had a very small context window.
是的，我认为这取决于您使用的模型，所有模型都略有不同，对不同提示的响应也不同，但我认为原始的 GPT-4 和去年原始的 [听不清 00:44:07] 模型，它们对提示非常敏感，而且它们也有一个非常小的上下文窗口。
43:50 And so we have all of these pieces of information around the code base that would maybe be relevant in the prompt.
因此，我们拥有围绕代码库的所有这些信息，这些信息可能与提示相关。
You have the docs, you have the files that you add, you have the conversation history, and then there’s a problem like how do you decide what you actually put in the prompt and when you have a limited space?
你有文档，你有你添加的文件，你有对话历史记录，然后就出现了一个问题，比如你如何决定在提示中实际放置什么以及当你的空间有限时？
And even for today’s models, even when you have long context, filling out the entire context window means that it’s slower.
即使对于今天的模型，即使你有很长的上下文，填充整个上下文窗口也意味着它会更慢。
It means that sometimes the model actually gets confused and some models get more confused than others.
这意味着有时模型实际上会变得混乱，并且某些模型比其他模型更混乱。
44:43 And we have this one system internally that we call Preempt, which helps us with that a little bit.
我们内部有一个称为 Preempt 的系统，这对我们有一点帮助。
And I think it was built for the era before where we had 8,000 token contact windows.
我认为它是为我们拥有 8,000 个令牌联系窗口之前的时代而构建的。
And it’s a little bit similar to when you’re making a website.
这与制作网站时有点相似。
You want it to work on mobile, you want it to work on a desktop screen, and you have this dynamic information which you don’t have.
您希望它在移动设备上运行，您希望它在桌面屏幕上运行，并且您拥有这些您没有的动态信息。
For example, if you’re designing a print magazine, you know exactly where you can put stuff.
例如，如果您正在设计一本印刷杂志，您就确切地知道可以把东西放在哪里。
But when you have a website or when you have a prompt, you have these inputs and then you need to format them to always work, even if the input is really big, then you might have to cut something down.
但是，当您有一个网站或有提示时，您有这些输入，然后您需要将它们格式化以使其始终有效，即使输入真的很大，那么您可能必须削减一些内容。
And so the idea was, okay, let’s take some inspiration.
所以我们的想法是，好吧，让我们吸取一些灵感。
What’s the best way to design websites?
设计网站的最佳方法是什么？
Well, the thing that we really like is React and the declarative approach where you use JSX in JavaScript, and then you declare, “This is what I want and I think this has higher priority or this has higher Z index than something else.”
好吧，我们真正喜欢的是 React 和声明式方法，在 JavaScript 中使用 JSX，然后声明，“这就是我想要的，我认为它比其他东西具有更高的优先级或者具有更高的 Z 索引。”
45:56 And then you have this rendering engine in web design.
然后你就可以在网页设计中使用这个渲染引擎了。
It’s like Chrome, and in our case it’s a preempt renderer, which then fits everything onto the page.
它就像 Chrome，在我们的例子中，它是一个抢占渲染器，然后将所有内容放入页面上。
And as you declare, decide what you want and then it figures out what you want.
当你声明时，决定你想要什么，然后它就会弄清楚你想要什么。
And so we have found that to be quite helpful and I think the role of it has shifted over time where initially it was to fit to these small context windows.
所以我们发现这非常有帮助，我认为它的作用随着时间的推移而发生了变化，最初它是为了适应这些小的上下文窗口。
Now it’s really useful because it helps us with splitting up the data that goes into the prompt and the actual rendering of it.
现在它非常有用，因为它可以帮助我们分割进入提示的数据和实际渲染的数据。
And so it’s easier to debug because you can change the rendering of the prompt and then try it on old prompts because you have the raw data that went into the prompt, and then you can see, “Did my change actually improve it for this entire eval set?”
因此调试起来更容易，因为您可以更改提示的呈现，然后在旧提示上尝试它，因为您拥有进入提示的原始数据，然后您可以看到，“我的更改实际上改善了整个评估集吗？”
So do you literally prompt with JSX?
那么你真的用 JSX 进行提示吗？
Yes.
是的。
46:48 Yes.
是的。
Yeah.
是的。
So it looks like react.
所以看起来像是有反应。
There are components.
有组件。
We have one component that’s a file component and it takes in the cursor.
我们有一个组件是文件组件，它接收光标。
Usually there’s one line where the cursor is in your file and that’s probably the most important line because that’s the one you’re looking at.
通常，文件中的光标位于一行，这可能是最重要的一行，因为这就是您正在查看的行。
And so then you can give priorities.
这样你就可以确定优先级。
So that line has the highest priority, and then you subtract one for every line that is farther away.
因此该行具有最高优先级，然后为距离较远的每行减去 1。
And then eventually when it’s rendered, it figures out how many lines can actually fit and it centers around that thing.
然后最终当它被渲染时，它会计算出实际上可以容纳多少条线，并以该东西为中心。
That’s amazing.
太棒了。
And you can do other fancy things where if you have lots of code blocks from the entire code base, you could use retrieval and things like embedding and re-ranking scores to add priorities for you through these components.
您还可以做其他奇特的事情，如果您有来自整个代码库的大量代码块，您可以使用检索以及嵌入和重新排名分数等功能来通过这些组件为您添加优先级。
So should humans when they ask questions, also try to use something like that?
那么人类在提出问题时是否也应该尝试使用类似的东西呢？
47:30 Would it be beneficial to write JSX in the problem or the whole idea is this should be loose and messy?
在问题中编写 JSX 是否有益，或者整个想法应该是松散和混乱的？
I think our goal is that you should just do whatever is the most natural thing for you, and then our job is to figure out how do we actually retrieve the relative event things so that your thinking actually makes sense?
我认为我们的目标是，你应该做对你来说最自然的事情，然后我们的工作是弄清楚我们如何真正检索相关事件，以便你的想法真正有意义？
Well, this is the discussion I had with Aravind of Perplexity is his whole idea is you should let the person be as lazy as he wants.
嗯，这是我与 Perplexity 的 Aravind 进行的讨论，他的整个想法是你应该让这个人像他想要的那样懒惰。
47:56 That’s a beautiful thing, but I feel like you’re allowed to ask more of programmers, right?
这是一件很美好的事情，但我觉得你可以向程序员提出更多的要求，对吧？
Yes.
是的。
So if you say, “Just do what you want,” humans are lazy.
因此，如果你说，“做你想做的事”，人类就是懒惰的。
48:14 There’s a tension between just being lazy versus provide more as be prompted…
懒惰与按提示提供更多之间存在着紧张关系……
Almost like the system pressuring you or inspiring you to be articulate.
几乎就像系统给你施加压力或激励你要善于表达。
Not in terms of the grammar of the sentences, but in terms of the depth of thoughts that you convey inside the prompts.
不是根据句子的语法，而是根据您在提示中传达的思想的深度。
I think even as a system gets closer to some level of perfection, often when you ask the model for something, not enough intent is conveyed to know what to do.
我认为，即使系统接近某种程度的完美，当您向模型询问某些内容时，通常也没有传达足够的意图来知道要做什么。
48:39 And there are a few ways to resolve that intent.
有几种方法可以解决这个意图。
One is the simple thing of having the model just ask you, “I’m not sure how to do these parts based on your query.
一是简单的事情，让模型问你，“我不知道如何根据你的查询来完成这些部分。
Could you clarify that?” I think the other could be maybe if there are five or six possible generations, “Given the uncertainty present in your query so far, why don’t we just actually show you all of those and let you pick them?”
你能澄清一下吗？”我认为另一个可能是，如果有五到六代可能的话，“鉴于到目前为止您的查询中存在的不确定性，为什么我们不直接向您展示所有这些并让您选择它们呢？”
How hard is it for the model to choose to talk back versus generally…
与一般情况相比，模型选择顶嘴有多难……
49:19 It’s hard, how deal with the uncertainty.
很难，如何应对不确定性。
Do I choose to ask for more information to reduce the ambiguity?
我是否选择询问更多信息以减少歧义？
So one of the things we do, it’s like a recent addition, is try to suggest files that you can add.
因此，我们所做的一件事（就像最近添加的内容一样）就是尝试建议您可以添加的文件。
49:36 And while you’re typing, one can guess what the uncertainty is and maybe suggest that maybe you’re writing your API and we can guess using the commits that you’ve made previously in the same file that the client and the server is super useful and there’s a hard technical problem of how do you resolve it across all commits?
当你打字时，人们可以猜测不确定性是什么，也许表明你可能正在编写 API，我们可以使用你之前在同一个文件中所做的提交来猜测客户端和服务器非常有用，并且存在一个困难的技术问题，即如何在所有提交中解决它？
Which files are the most important given your current prompt?
根据您当前的提示，哪些文件最重要？
And we’re still initial version is ruled out and I’m sure we can make it much more accurate.
我们仍然排除了初始版本，我相信我们可以使其更加准确。
It’s very experimental, but then the idea is we show you, do you just want to add this file, this file, this file also to tell the model to edit those files for you?
这是非常实验性的，但我们的想法是我们向您展示，您是否只想添加这个文件，这个文件，这个文件来告诉模型为您编辑这些文件？
50:37 Because if maybe you’re making the API, you should also edit the client and the server that is using the API and the other one resolving the API.
因为如果您正在制作 API，您还应该编辑使用该 API 的客户端和服务器以及解析该 API 的另一个客户端和服务器。
So that would be cool as both there’s the phase where you’re writing a prompt and there’s…
所以这会很酷，因为既有你写提示的阶段，又有……
Before you even click, “Enter,” maybe we can help resolve some of the uncertainty.
在您点击“输入”之前，也许我们可以帮助解决一些不确定性。
To what degree do you use agentic approaches?
您在多大程度上使用代理方法？
50:54 How useful are agents?
代理有多大用处？
We think agents are really, really cool.
我们认为代理真的非常非常酷。
Okay.
好的。
I think agents, it’s like resembles like a human…
我认为特工，就像人类一样……
51:03 You can feel that you’re getting closer to AGI because you see a demo where it acts as a human would and it’s really, really cool.
你会感觉到你离 AGI 越来越近了，因为你看到了一个演示，它的行为就像人类一样，而且真的非常非常酷。
I think agents are not yet super useful for many things.
我认为代理对于很多事情来说还不是非常有用。
I think we’re getting close to where they will actually be useful.
我认为我们已经接近它们真正有用的地方了。
And so I think there are certain types of tasks where having an agent would be really nice.
所以我认为在某些类型的任务中，有一个代理会非常好。
I would love to have an agent.
我很想有一个代理。
For example, if we have a bug where you sometimes can’t Command+C and Command+V inside our chat input box, and that’s a task that’s super well specified.
例如，如果我们有一个错误，您有时无法在聊天输入框中使用 Command+C 和 Command+V，那么这就是一个非常明确的任务。
I just want to say in two sentences, “This does not work, please fix it.” And then I would love to have an agent that just goes off, does it, and then a day later, I come back and I review the thing.
我只想用两句话说：“这不起作用，请修复它。”然后我希望有一个代理人能够立即行动，然后一天后，我回来并审查这件事。
You mean it goes, finds the right file?
你的意思是它可以找到正确的文件？
Yeah, it finds the right files, it tries to reproduce the bug, it fixes the bug and then it verifies that it’s correct.
是的，它找到正确的文件，尝试重现错误，修复错误，然后验证它是否正确。
52:05 And this could be a process that takes a long time.
这可能是一个需要很长时间的过程。
And so I think I would love to have that.
所以我想我很乐意拥有它。
And then I think a lot of programming, there is often this belief that agents will take over all of programming.
然后我想到很多编程，人们常常相信代理将接管所有编程。
I don’t think we think that that’s the case because a lot of programming, a lot of the value is in iterating, or you don’t actually want to specify something upfront because you don’t really know what you want until you have seen an initial version and then you want to iterate on that and then you provide more information.
我不认为我们认为是这种情况，因为很多编程，很多价值都在迭代中，或者你实际上不想预先指定一些东西，因为你并不真正知道你想要什么，直到你看到一个初始版本，然后你想要迭代它，然后你提供更多信息。
52:43 And so for a lot of programming, I think you actually want a system that’s instant, that gives you an initial version instantly back and then you can iterate super, super quickly.
因此，对于很多编程，我认为您实际上想要一个即时的系统，它可以立即返回初始版本，然后您可以超级、超级快速地进行迭代。
What about something like that recently came out, replica agent, that does also setting up the development environment and solving software packages, configuring everything, configuring the databases and actually deploying the app.
最近出现的类似副本代理怎么样，它还可以设置开发环境和解决软件包，配置所有内容，配置数据库并实际部署应用程序。
52:52 Is that also in the set of things you dream about?
这也是你梦想的事情吗？
I think so.
我想是的。
53:09 I think that would be really cool.
我认为那真的很酷。
For certain types of programming, it would be really cool.
对于某些类型的编程来说，这真的很酷。
Is that within scope of Cursor?
是否在 Cursor 范围内？
Yeah, we aren’t actively working on it right now, but it’s definitely…
是的，我们现在还没有积极开展工作，但这绝对是……
53:17 We want to make the programmer’s life easier and more fun and some things are just really tedious and you need to go through a bunch of steps and you want to delegate that to an agent.
我们希望让程序员的生活变得更轻松、更有趣，但有些事情确实很乏味，你需要执行一系列步骤，然后你想将其委托给代理。
And then some things you can actually have an agent in the background while you’re working.
然后有些事情你实际上可以在工作时在后台有一个代理。
Let’s say you have a PR that’s both backend and frontend, and you’re working in the frontend and then you can have a background agent that doesn’t work and figure out what you’re doing.
假设你有一个既是后端又是前端的 PR，并且你在前端工作，然后你可能有一个不起作用的后台代理并弄清楚你在做什么。
And then when you get to the backend part of your PR, then you have some initial piece of code that you can iterate on.
然后，当您到达 PR 的后端部分时，您将获得一些可以迭代的初始代码。
And so that would also be really cool.
所以这也非常酷。
One of the things we already talked about is speed, but I wonder if we can just linger on that some more in the various places that the technical details involved in making this thing really fast.
我们已经讨论过的事情之一是速度，但我想知道我们是否可以在各个地方多停留一些时间，让这件事变得非常快所涉及的技术细节。
53:58 So every single aspect of Cursor, most aspects of Cursor feel really fast.
因此 Cursor 的每个方面，Cursor 的大多数方面都感觉非常快。
Like I mentioned, the Apply is probably the slowest thing.
就像我提到的，Apply 可能是最慢的事情。
And for me from…
而对于我来说，从...
I’m sorry, the pain on Arvid’s face as I say that.
对不起，当我这么说的时候，阿维德脸上的痛苦。
I know.
我知道。
54:22 It’s a pain.
这是一种痛苦。
It’s a pain that we’re feeling and we’re working on fixing it.
我们感受到了这种痛苦，并且正在努力解决它。
Yeah, it says something that feels…
是的，它说了一些感觉……
54:27 I don’t know what it is, like one second or two seconds, that feels slow.
我不知道那是什么，比如一秒或两秒，感觉很慢。
That means that actually shows that everything else is just really, really fast.
这意味着这实际上表明其他一切都非常非常快。
So is there some technical details about how to make some of these models, how to make the chat fast, how to make the diffs fast?
那么是否有一些关于如何制作其中一些模型、如何使聊天快速、如何使差异快速的技术细节？
Is there something that just jumps to mind?
有什么事情突然浮现在脑海中吗？
Yeah.
是的。
54:49 So we can go over a lot of the strategies that we use.
所以我们可以回顾一下我们使用的很多策略。
One interesting thing is cache warming.
一件有趣的事情是缓存预热。
And so what you can do is if as the user’s typing, you can have…
因此，您可以做的是，当用户输入时，您可以……
You’re probably going to use some piece of context and you can know that before the user’s done typing.
您可能会使用某些上下文，并且您可以在用户完成输入之前知道它。
So as we discussed before, reusing the KV cache results in lower latency, lower costs, cross requests.
正如我们之前讨论的，重用 KV 缓存可以降低延迟、降低成本、降低交叉请求。
So as the user starts typing, you can immediately warm the cache with let’s say the current file contents, and then when they press enter, there’s very few tokens it actually has to pre-fill and compute before starting the generation.
因此，当用户开始输入时，您可以立即使用当前文件内容来预热缓存，然后当他们按 Enter 键时，在开始生成之前实际上需要预先填充和计算的令牌非常少。
This will significantly lower TTFT.
这将显着降低 TTFT。
Can you explain how KV cache works?
你能解释一下 KV 缓存是如何工作的吗？
Yeah, so the way transformers work.
是的，变压器的工作方式就是这样。
I like it.
我喜欢它。
One of the mechanisms that allow transformers to not just independently…
允许变压器不仅独立地……的机制之一
55:41 The mechanism that allows transformers to not just independently look at each token, but see previous tokens are the keys and values to attention.
该机制允许转换器不仅独立地查看每个令牌，而且还可以看到以前的令牌是需要注意的键和值。
And generally, the way attention works is you have at your current token some query, and then you’ve all the keys and values of all your previous tokens, which are some kind of representation that the model stores internally of all the previous tokens in the prompt.
一般来说，注意力的工作方式是对当前标记进行一些查询，然后获得所有先前标记的所有键和值，这些是模型在提示中内部存储的所有先前标记的某种表示形式。
And by default, when you’re doing a chat, the model has to, for every single token, do this forward pass through the entire model.
默认情况下，当您进行聊天时，模型必须针对每个标记，对整个模型进行前向传递。
That’s a lot of matrix multiplies that happen, and that is really, really slow.
发生了很多矩阵乘法，而且速度非常非常慢。
56:23 Instead, if you have already done that and you stored the keys and values and you keep that in the GPU, then when I…
相反，如果您已经完成了该操作并且存储了键和值并将其保留在 GPU 中，那么当我...
Let’s say I have to sort it for the last N tokens.
假设我必须对最后 N 个标记进行排序。
If I now want to compute the output token for the N+1nth token, I don’t need to pass those first N tokens through the entire model because I already have all those keys and values.
如果我现在想要计算第 N+1n 个标记的输出标记，我不需要将前 N 个标记传递到整个模型，因为我已经拥有所有这些键和值。
And so you just need to do the forward pass through that last token.
所以你只需要通过最后一个令牌进行前向传递。
And then when you’re doing attention, you’re reusing those keys and values that have been computed, which is the only kind of sequential part or sequentially dependent part of the transformer.
然后，当您进行注意时，您将重用那些已计算的键和值，这是变压器的唯一一种顺序部分或顺序依赖部分。
Is there higher level caching of caching of the prompts or that kind of stuff that could help?
是否有更高级别的提示缓存或类似的东西可以提供帮助？
I see.
我懂了。
57:05 Yeah.
是的。
There’s other types of caching you can do.
您还可以执行其他类型的缓存。
One interesting thing that you can do for Cursor Tab is you can basically predict ahead as if the user would’ve accepted the suggestion and then trigger another request.
您可以为“光标选项卡”做的一件有趣的事情是，您基本上可以提前预测，就好像用户会接受建议，然后触发另一个请求一样。
And so then you’ve cached, you’ve done the speculative.
所以你已经缓存了，你已经完成了推测。
It’s a mix of speculation and caching, right?
这是猜测和缓存的混合体，对吧？
Because speculating what would happen if they accepted it.
因为猜测如果他们接受的话会发生什么。
And then you have this value that is cached this suggestion.
然后你就有了缓存这个建议的值。
And then when they press tab, the next one would be waiting for them immediately.
然后当他们按下 Tab 时，下一个就会立即等待他们。
It’s a clever heuristic/trick that uses a higher level caching and can give the…
这是一个聪明的启发式/技巧，它使用更高级别的缓存，并且可以提供......
It feels fast despite there not actually being any changes in the model.
尽管模型实际上没有任何变化，但感觉很快。
And if you can make the KV cache smaller, one of the advantages you get is like maybe you can speculate even more.
如果您可以使 KV 缓存更小，那么您获得的优势之一就是也许您可以推测得更多。
57:54 Maybe you can guess, “Here’s the 10 things that could be useful, predict the next 10,” and then it’s possible the user hits the one of the 10.
也许你可以猜测，“这是可能有用的 10 件事，预测接下来的 10 件事”，然后用户可能会点击这 10 件事中的一件。
It’s much higher chance than the user hits the exact one that you showed them.
这比用户点击您向他们展示的那个的机会要高得多。
Maybe they type in other character and hit something else in the cache.
也许他们输入其他字符并命中缓存中的其他内容。
So there’s all these tricks where…
所以所有这些技巧都在……
The general phenomena here is, I think it’s also super useful for RL is maybe a single sample from the model isn’t very good, but if you predict 10 different things, turns out that one of the 10 that’s right is the probability is much higher.
这里的一般现象是，我认为它对于 RL 也非常有用，也许模型中的单个样本不是很好，但如果你预测 10 个不同的事物，结果证明 10 个正确的事物之一的概率要高得多。
There’s these passive K curves and part of RL, what RL does is you can exploit this passive K phenomena to make many different predictions.
这些被动 K 曲线和 RL 的一部分，RL 所做的就是你可以利用这种被动 K 现象做出许多不同的预测。
58:53 And one way to think about this, the model knows internally has some uncertainty over which of the key things is correct or which of the key things does the human wants?
思考这个问题的一种方式是，模型内部知道哪些关键事物是正确的或者人类想要哪些关键事物存在一些不确定性？
When we RL our Cursor Tab model, one of the things we’re doing is we’re predicting which of the 100 different suggestions the model produces is more amenable for humans?
当我们强化光标选项卡模型时，我们正在做的一件事是预测模型产生的 100 种不同建议中哪一种更适合人类？
Which of them do humans more like than other things?
与其他事物相比，人类更喜欢其中哪一个？
Maybe there’s something where the model can predict very far ahead versus a little bit, maybe somewhere in the middle.
也许模型可以预测很远的时间，而不是一点点，也许在中间的某个地方。
And then you can give a reward to the things that humans would like more and punish the things that it would like, and then train the model to output the suggestions that humans would like more.
然后你可以对人类更喜欢的东西给予奖励，对人类更喜欢的东西进行惩罚，然后训练模型输出人类更喜欢的建议。
You have these RL loops that are very useful that exploit these passive K curves.
这些 RL 循环对于利用这些被动 K 曲线非常有用。
Aman, maybe can go into even more detail.
阿曼，也许可以说得更详细。
Yeah, it is a little different than speed, but technically, you tie it back in because you can get away with the smaller model if you RL your smaller model and it gets the same performance as the bigger one.
是的，它与速度有点不同，但从技术上讲，你可以将其重新绑定起来，因为如果你对较小的模型进行强化学习，并且它获得与较大模型相同的性能，你就可以使用较小的模型。
1:00:00 …
……
as the bigger one.
作为较大的一个。
So while I was mentioning stuff about KV, about reducing the size of your KV cache, there are other techniques there as well that are really helpful for speed.
因此，当我提到关于 KV 的内容、关于减少 KV 缓存大小的内容时，还有其他技术对速度确实有帮助。
So kind of back in the day, all the way two years ago, people mainly use multi-head attention, and I think there’s been a migration towards more efficient attention schemes like group query or multi-query attention, and this is really helpful for then with larger batch sizes being able to generate the tokens much faster.
回到过去，两年前，人们主要使用多头注意力，我认为已经向更有效的注意力方案（如组查询或多查询注意力）迁移，这对于当时更大的批量大小能够更快地生成令牌非常有帮助。
The interesting thing here is this now has no effect on that time to first token pre-fill speed.
有趣的是，这现在对首次令牌预填充速度没有影响。
The thing this matters for is now generating tokens.
现在重要的是生成代币。
And why is that?
这是为什么呢？
Because when you’re generating tokens, instead of being bottlenecked by doing these super parallelizable matrix multiplies across all your tokens, you’re bottlenecked by how quickly…
因为当你生成令牌时，你不会因为在所有令牌上进行这些超级可并行矩阵乘法而受到瓶颈，而是因为速度有多快而受到瓶颈......
For a long context with large batch sizes, by how quickly you can read those cache, keys, and values.
对于具有大批量大小的长上下文，取决于读取这些缓存、键和值的速度。
1:01:07 And so then that’s memory bandwidth, and how can we make this faster?
这就是内存带宽，我们怎样才能让它更快呢？
We can try to compress the size of these keys and values.
我们可以尝试压缩这些键和值的大小。
So multi-query attention is the most aggressive of these.
因此，多查询注意力是其中最积极的。
Where normally with multi-head attention, you have some number of, quote, unquote, “attention heads” and some number of query heads.
通常在多头注意力的情况下，你有一定数量的引用、取消引用、“注意力头”和一定数量的查询头。
Multi-query just preserves the query heads, gets rid of all the key value heads.
多查询只是保留查询头，去掉所有键值头。
So there’s only one kind of key value head, and there’s all the remaining query heads.
所以只有一种键值头，还有所有剩余的查询头。
With group query, you instead preserve all the query heads and then your keys and values are…
使用组查询，您可以保留所有查询头，然后您的键和值是......
There are fewer heads for the keys and values, but you’re not reducing it to just one.
键和值的头较少，但您并没有将其减少到只有一个。
But anyways, the whole point here is you’re just reducing the size of your KV cache.
但无论如何，这里的重点是你只是减少了 KV 缓存的大小。
And then there is MLA.
然后是司法协助。
Yeah, multi-latent.
是的，多重潜伏。
1:02:02 That’s a little more complicated.
这有点复杂。
And the way that this works is it kind of turns the entirety of your keys and values across all your heads into this one latent vector that has then kind of expanded in for its time.
它的工作方式是将你所有头脑中的全部键和值转变为一个潜在向量，然后在其时间范围内进行扩展。
But MLA is from this company called DeepSeek.
但MLA来自这家叫DeepSeek的公司。
1:02:19 It’s quite an interesting algorithm.
这是一个非常有趣的算法。
Maybe the key idea is in both MQA and in other places, what you’re doing is you’re reducing the number of KV heads.
也许关键的想法是在 MQA 和其他地方，你正在做的是减少 KV 头的数量。
And the advantage you get from that is there’s less of them, but maybe the theory is that you actually want a lot of different…
你从中获得的优势是它们的数量更少，但也许理论上你实际上想要很多不同的......
You want each of the keys and values to actually be different.
您希望每个键和值实际上都不同。
So one way to reduce the size is you keep one big shared vector for all the keys and values and then you have smaller vectors for every single token.
因此，减少大小的一种方法是为所有键和值保留一个大的共享向量，然后为每个标记保留更小的向量。
So that you can store the only the smaller thing as some sort of low-rank reduction, and the low-rank reduction, well, that…
这样你就可以将较小的东西存储为某种低阶归约，而低阶归约，那么……
At the end of the time, when you eventually want to compute the final thing, remember that your memory band, which means that you still have some compute left that you can use for these things.
最后，当您最终想要计算最终的事情时，请记住您的内存带，这意味着您仍然有一些剩余的计算可用于这些事情。
And if you can expand the latent vector back out and somehow this is far more efficient because you’re reducing…
如果你可以将潜在向量扩展回来，并且不知何故，这会更有效，因为你正在减少......
For example, maybe you’re reducing vec 32 or something like the size of the vector that you’re keeping.
例如，也许您正在减少 vec 32 或类似您保留的向量的大小。
Yeah, there’s perhaps some richness in having a separate set of keys and values and query that kind of pairwise match up versus compressing that all into one in that interaction at least.
是的，拥有一组单独的键和值并查询这种成对匹配与至少在该交互中将其全部压缩为一个可能会更丰富。
Okay, and all of that is dealing with being memory bound.
好吧，所有这些都是关于内存限制的。
1:03:51 I mean, ultimately, how does that map to the user experience?
我的意思是，最终，这如何映射到用户体验？
Trying to get the-
试图得到-
Yeah.
是的。
1:04:02 The two things that it maps to is you can now make your cache a lot larger because you’ve less space allocated for the KV cache.
它映射到的两件事是你现在可以使你的缓存更大，因为你为 KV 缓存分配的空间更少。
You can maybe cache a lot more aggressively in a lot more things, so you get more cache hits, which are helpful for reducing the time to first token for the reasons that were kind of described earlier.
您可以更积极地缓存更多的东西，这样您就可以获得更多的缓存命中，这有助于减少第一个令牌的时间，原因如前所述。
And then the second being, when you start doing inference with more and more requests and larger and larger batch sizes, you don’t see much of a slowdown as it’s generating the tokens at the speed of that.
第二个是，当您开始对越来越多的请求和越来越大的批量大小进行推理时，您不会看到太大的减速，因为它以这样的速度生成令牌。
Well, it also allows you to make your prompt bigger for certain-
好吧，它还可以让你让你的提示更大一些——
Yeah.
是的。
1:04:34 Yeah, so the size of your KV cache is both the size of all your prompts multiplied by the number of prompts being processed in parallel.
是的，所以 KV 缓存的大小就是所有提示的大小乘以并行处理的提示的数量。
So you could increase either those dimensions, right?
所以你可以增加这些尺寸，对吧？
The batch size or the size of your prompts without degrading the latency of generating tokens.
批量大小或提示的大小不会降低生成令牌的延迟。
Arvid, you wrote a blog post Shadow Workspace: Iterating on Code in the Background.
Arvid，您写了一篇博文 Shadow Workspace：在后台迭代代码。
1:04:51 So what’s going on [inaudible 01:04:59]?
那么发生了什么事 [听不清 01:04:59]？
So to be clear, we want there to be a lot of stuff happening in the background, and we’re experimenting with a lot of things.
所以需要明确的是，我们希望在后台发生很多事情，并且我们正在尝试很多事情。
1:04:58 Right now, we don’t have much stuff happening other than the cache warming or figuring out the right context that goes into your command key prompts for example.
目前，除了缓存预热或找出命令键提示中的正确上下文之外，我们没有发生太多事情。
But the idea is if you can actually spend computation in the background, then you can help the user maybe at a slightly longer time horizon than just predicting the next few lines that you’re going to make.
但我们的想法是，如果您实际上可以在后台进行计算，那么您可以在稍长的时间范围内帮助用户，而不仅仅是预测您将要做的接下来的几行。
But actually in the next 10 minutes, what are you going to make?
但实际上，在接下来的 10 分钟内，你会做什么？
And by doing it in background, you can spend more computation doing that.
通过在后台执行此操作，您可以花费更多的计算量来执行此操作。
And so the idea of the Shadow Workspace that we implemented, and we use it internally for experiments is that to actually get advantage of doing stuff in the background, you want some kind of feedback signal to give back to the model because otherwise you can get higher performance by just letting the model think for longer, and so o1 is a good example of that.
因此，我们实现的影子工作区的想法，以及我们在内部使用它进行实验的想法是，为了真正利用在后台做事情的优势，你需要某种反馈信号来反馈给模型，否则你可以通过让模型思考更长时间来获得更高的性能，所以 o1 就是一个很好的例子。
1:06:03 But another way you can improve performance is by letting the model iterate and get feedback.
但提高性能的另一种方法是让模型迭代并获取反馈。
And so one very important piece of feedback when you’re a programmer is the language server, which is this thing, it exists for most different languages, and there’s a separate language server per language.
因此，当你是一名程序员时，一个非常重要的反馈是语言服务器，就是这个东西，它适用于大多数不同的语言，并且每种语言都有一个单独的语言服务器。
And it can tell you, “You’re using the wrong type here,” and then gives you an error, or it can allow you to go to definition and sort of understands the structure of your code.
它可以告诉你，“你在这里使用了错误的类型”，然后给你一个错误，或者它可以允许你去定义并理解代码的结构。
So language servers are extensions developed by…
所以语言服务器是由……开发的扩展。
There is a TypeScript language server developed by the TypeScript people, a Rust language server developed by the Rust people, and then they all interface over the language server protocol to VS Code.
有一个由 TypeScript 人员开发的 TypeScript 语言服务器，一个由 Rust 人员开发的 Rust 语言服务器，然后它们都通过语言服务器协议连接到 VS Code。
So that VS Code doesn’t need to have all of the different languages built into VS Code but rather you can use the existing compiler infrastructure.
因此，VS Code 不需要将所有不同的语言内置到 VS Code 中，而是可以使用现有的编译器基础设施。
For linting purposes, what-
为了清理目的，什么-
It’s for linting.
这是为了绒毛。
1:06:52 It’s for going to definition and for seeing the right types that you’re using.
这是为了进行定义并查看您正在使用的正确类型。
So it’s doing type checking also.
所以它也在进行类型检查。
Yes, type checking and going to references.
是的，类型检查和参考文献。
1:07:01 And that’s like when you’re working in a big project, you kind of need that.
这就像当你在一个大项目中工作时，你有点需要它。
If you don’t have that, it’s really hard to code in a big project.
如果你没有这个，那么在一个大项目中编码真的很困难。
Can you say, again, how that’s being used inside Cursor, the language server protocol communication thing?
你能再说一遍，它是如何在 Cursor（语言服务器协议通信）内部使用的吗？
So it’s being used in Cursor to show to the programmer just like in VS Code, but then the idea is you want to show that same information to the models, the IM models, and you want to do that in a way that doesn’t affect the user because you want to do it in background.
因此，它在 Cursor 中用于向程序员显示，就像在 VS Code 中一样，但想法是您希望向模型、IM 模型显示相同的信息，并且您希望以不影响用户的方式执行此操作，因为您希望在后台执行此操作。
1:07:20 And so the idea behind the Shadow Workspace was, okay, one way we can do this is we spawn a separate window of Cursor that’s hidden, and so you can set this flag in it and like turn it’s hidden.
因此，影子工作区背后的想法是，好吧，我们可以做到这一点的一种方法是我们生成一个隐藏的单独的光标窗口，因此您可以在其中设置此标志，然后将其隐藏。
There is a window but you don’t actually see it.
有一个窗口，但你实际上看不到它。
And inside of this window, the AI agents can modify code however they want as long as they don’t save it because it’s still the same folder and then can get feedback from the linters and go to definition and iterate on their code.
在此窗口内，人工智能代理可以根据需要修改代码，只要不保存代码即可，因为它仍然是同一个文件夹，然后可以从 linter 获取反馈并进行定义并迭代其代码。
So literally run everything in the background as if…
因此，实际上在后台运行所有内容，就好像......
1:08:04 Right, maybe even run the code.
是的，甚至可以运行代码。
So that’s the eventual version and that’s what you want.
这就是最终的版本，这就是您想要的。
1:08:10 And a lot of the blog post is actually about how do you make that happen because it’s a little bit tricky.
博客文章的很多内容实际上都是关于如何实现这一点，因为这有点棘手。
You want it to be on the user’s machine so that it exactly mirrors the user’s environment.
您希望它位于用户的计算机上，以便它准确地反映用户的环境。
And then on Linux, you can do this cool thing where you can actually mirror the file system and have the AI make changes to the files, and it thinks that it’s operating on the file level, but actually, that’s stored in memory and you can create this kernel-like extension to make it work.
然后在 Linux 上，你可以做一件很酷的事情，你可以实际镜像文件系统并让 AI 对文件进行更改，它认为它是在文件级别上操作的，但实际上，它存储在内存中，你可以创建这个类似内核的扩展以使其工作。
Whereas on Mac and Windows, it’s a little bit more difficult, but it’s a fun technical problem, so that’s why.
而在 Mac 和 Windows 上，这有点困难，但这是一个有趣的技术问题，所以这就是原因。
One may be hacky but interesting idea that I like is holding a lock on saving.
我喜欢的一个可能是老套但有趣的想法是锁定储蓄。
1:08:57 And so basically, you can then have the language model kind of hold the lock on saving to disk and then instead of you operating in the ground truth version of the files that are saved to disk, you actually are operating what was the Shadow Workspace before and these unsaved things that only exist in memory that you still get linter errors for, and you can code in.
基本上，您可以让语言模型在保存到磁盘时保持锁定，然后您实际上正在操作之前的影子工作区以及这些仅存在于内存中的未保存的内容，而不是在保存到磁盘的文件的真实版本中进行操作，您仍然会收到 linter 错误，并且可以在其中进行编码。
And then when you try to maybe run code, it’s just like there’s a small warning that there’s a lock, and then you kind of will take back the lock from the language server if you’re trying to do things concurrently or from the Shadow Workspace if you’re trying to do things concurrently.
然后，当您尝试运行代码时，就像有一个小警告，表明有锁，然后如果您尝试同时执行操作，您将从语言服务器或影子工作空间中收回锁（如果您尝试同时执行操作）。
That’s such an exciting future by the way.
顺便说一句，这是一个令人兴奋的未来。
1:09:31 It’s a bit of a tangent, but to allow a model to change files, it’s scary for people but it’s really cool, to be able to just let the agent do a set of tasks and you come back the next day and kind of observe like it’s a colleague or something like that.
这有点离题，但允许模型更改文件，这对人们来说很可怕，但它真的很酷，能够让代理完成一组任务，然后你第二天回来并像同事或类似的人一样进行观察。
And I think there may be different versions of runability where, for the simple things where you’re doing things in the span of a few minutes on behalf of the user as they’re programming, it makes sense to make something work locally in their machine.
我认为可能存在不同版本的可运行性，对于简单的事情，您在编程时代表用户在几分钟内做一些事情，让某些东西在他们的机器上本地工作是有意义的。
1:09:52 I think for the more aggressive things where you’re making larger changes that take longer periods of time, you’ll probably want to do this in some sandbox remote environment and that’s another incredibly tricky problem of how do you exactly reproduce or mostly reproduce to the point of it being effectively equivalent for running code the user’s environment with this remote sandbox.
我认为，对于更激进的事情，您要进行更大的更改，需要更长的时间，您可能希望在某个沙箱远程环境中执行此操作，这是另一个非常棘手的问题，即如何准确地重现或大部分重现到它与使用此远程沙箱在用户环境中运行代码有效等效的程度。
I’m curious what kind of agents you want for coding?
我很好奇你想要什么样的代理来编码？
1:10:27 Do you want them to find bugs?
您希望他们发现错误吗？
Do you want them to implement new features?
您希望他们实现新功能吗？
What agents do you want?
你想要什么代理？
So by the way, when I think about agents, I don’t think just about coding.
顺便说一句，当我想到代理时，我不仅仅想到编码。
1:10:36 I think so for this particular podcast, there’s video editing and a lot of…
我认为对于这个特定的播客来说，有视频编辑和很多……
If you look in Adobe, a lot…
如果你查看 Adobe，会发现很多……
There’s code behind.
后面有代码。
It’s very poorly documented code, but you can interact with Premiere, for example, using code, and basically all the uploading, everything I do on YouTube, everything as you could probably imagine, I do all of that through code and including translation and overdubbing, all of this.
这是非常缺乏记录的代码，但你可以与 Premiere 进行交互，例如，使用代码，基本上所有的上传，我在 YouTube 上所做的一切，你可能想象到的一切，我通过代码完成所有这些，包括翻译和配音，所有这一切。
So I envision all of those kinds of tasks.
所以我设想了所有这些类型的任务。
So automating many of the tasks that don’t have to do directly with the editing, so that.
因此，自动化许多不必直接与编辑相关的任务，所以。
Okay, that’s what I was thinking about.
好吧，这就是我在想的。
But in terms of coding, I would be fundamentally thinking about bug finding, many levels of kind of bug finding and also bug finding like logical bugs, not logical like spiritual bugs or something.
但就编码而言，我将从根本上考虑错误查找，多种级别的错误查找以及逻辑错误之类的错误查找，而不是像精神错误之类的逻辑错误。
Ones like big directions of implementation, that kind of stuff.
比如大的实施方向之类的。
Magical [inaudible 01:11:39] and bug finding.
神奇的 [听不清 01:11:39] 和 bug 发现。
Yeah.
是的。
1:11:40 I mean, it’s really interesting that these models are so bad at bug finding when just naively prompted to find a bug.
我的意思是，真正有趣的是，当这些模型只是天真地提示寻找错误时，它们在发现错误方面却如此糟糕。
They’re incredibly poorly calibrated.
它们的校准非常糟糕。
Even the smartest models.
即使是最聪明的模型。
Exactly, even o1.
没错，甚至是o1。
How do you explain that?
你怎么解释？
1:11:53 Is there a good intuition?
有没有好的直觉？
I think these models are really strong reflection of the pre-training distribution, and I do think they generalize as the loss gets lower and lower, but I don’t think the loss and the scale is quite…
我认为这些模型确实强烈地反映了预训练分布，并且我确实认为它们随着损失越来越低而泛化，但我不认为损失和规模相当......
1:11:58 The loss is low enough such that they’re really fully generalizing on code.
损失足够低，以至于它们真正完全概括了代码。
The things that we use these things for, the frontier models that they’re quite good at, are really code generation and question answering.
我们使用这些东西的目的，他们非常擅长的前沿模型，实际上是代码生成和问题回答。
And these things exist in massive quantities in pre-training with all of the code in GitHub on the scale of many, many trillions of tokens and questions and answers on things like stack overflow and maybe GitHub issues.
这些东西在预训练中大量存在，所有代码都在 GitHub 上，规模达到了数万亿个代币以及有关堆栈溢出和 GitHub 问题等问题和答案。
1:12:39 And so when you try to push one of these things that really don’t exist very much online, like for example, the Cursor Tab objective of predicting the next edit given the edits done so far, the brittleness kind of shows.
因此，当您尝试将这些实际上并不存在的东西之一推到网上时，例如，根据迄今为止所做的编辑来预测下一次编辑的光标选项卡目标，就会显示出脆弱性。
And then bug detection is another great example, where there aren’t really that many examples of actually detecting real bugs and then proposing fixes and the models just kind of really struggle at it.
然后错误检测是另一个很好的例子，实际上并没有那么多实际检测真正的错误然后提出修复方案的例子，而且模型在这方面确实很困难。
But I think it’s a question of transferring the model in the same way that you get this fantastic transfer from pre-trained models just on code in general to the Cursor Tab objective.
但我认为这是一个以同样的方式转移模型的问题，就像您从一般代码上的预训练模型到光标选项卡目标的奇妙转移一样。
You’ll see a very, very similar thing with generalized models that are really good at code to bug detection.
您会看到与非常擅长代码错误检测的通用模型非常非常相似的事情。
It just takes a little bit of kind nudging in that direction.
只需要朝这个方向一点点善意的推动即可。
Look to be clear, I think they sort of understand code really well.
看起来很清楚，我认为他们对代码的理解非常好。
1:13:25 While they’re being pre-trained, the representation that’s being built up almost certainly like somewhere in the stream, the model knows that maybe there’s something sketchy going on.
当它们正在接受预训练时，几乎可以肯定正在建立的表示就像流中的某个地方一样，模型知道也许正在发生一些粗略的事情。
It sort of has some sketchiness but actually eliciting the sketchiness to actually…
它有点粗略，但实际上引发了粗略……
Part of it is that humans are really calibrated on which bugs are really important.
部分原因是人类确实已经校准了哪些错误是真正重要的。
It’s not just actually saying there’s something sketchy.
这不仅仅是说有一些粗略的东西。
It’s like it’s this sketchy trivial, it’s this sketchy like you’re going to take the server down.
就好像这是一件粗略的琐事，就像你要关闭服务器一样。
1:14:04 Part of it is maybe the cultural knowledge of why is a staff engineer is good because they know that three years ago someone wrote a really sketchy piece of code that took the server down and as opposed to maybe you just…
部分原因可能是文化知识，为什么高级工程师是优秀的，因为他们知道三年前有人编写了一段非常粗略的代码，导致服务器瘫痪，而不是你只是……
This thing is an experiment.
这件事是一个实验。
So a few bugs are fine, you’re just trying to experiment and get the feel of the thing.
所以有一些错误是可以的，你只是想尝试一下并感受一下。
And so if the model gets really annoying when you’re writing an experiment, that’s really bad, but if you’re writing something for super production, you’re writing a database.
因此，如果您在编写实验时模型变得非常烦人，那真的很糟糕，但如果您正在为超级生产编写一些东西，那么您正在编写数据库。
You’re writing code in Postgres or Linux or whatever.
你正在 Postgres 或 Linux 等中编写代码。
You’re Linus Torvalds.
你是莱纳斯·托沃兹。
It’s sort of unacceptable to have even an edge case and just having the calibration of how paranoid is the user and like-
即使是有一个边缘情况，并且只是对用户的偏执程度进行校准，也是有点不可接受的——
But even then if you’re putting in a maximum paranoia, it still just doesn’t quite get it.
但即便如此，如果你投入最大的偏执，它仍然无法完全理解。
Yeah, yeah.
是啊是啊。
1:14:57 Yeah.
是的。
I mean, but this is hard for humans too to understand which line of code is important, which is not.
我的意思是，但这对人类来说也很难理解哪一行代码重要，哪一行不重要。
1:14:58 I think one of your principles on a website says if a code can do a lot of damage, one should add a comment that say, “This line of code is dangerous.”
我认为您在网站上的原则之一是，如果代码会造成很大的损害，则应该添加一条评论，说“这行代码很危险”。
And all caps, repeated 10 times.
并且全部大写，重复10次。
No, you say for every single line of code inside the function you have to…
不，你说对于函数内的每一行代码，你必须......
1:15:20 And that’s quite profound, that says something about human beings because the engineers move on, even the same person might just forget how it can sink the Titanic a single function.
这是非常深刻的，这说明了人类的一些事情，因为工程师继续前进，即使是同一个人也可能忘记它如何能够沉没泰坦尼克号的一个功能。
You might not intuit that quite clearly by looking at the single piece of code.
通过查看单段代码，您可能无法清楚地直觉到这一点。
Yeah.
是的。
1:15:42 And I think that one is partially also for today’s AI models where if you actually write dangerous, dangerous, dangerous in every single line, the models will pay more attention to that and will be more likely to find bugs in that region.
我认为这在一定程度上也适用于当今的人工智能模型，如果你真的在每一行中都写下危险、危险、危险，模型就会更加关注这一点，并且更有可能在该区域发现错误。
That’s actually just straight up a really good practice of labeling code of how much damages can do.
这实际上是标记代码可以造成多大损害的一个非常好的做法。
Yeah.
是的。
1:16:08 I mean, it’s controversial.
我的意思是，这是有争议的。
Some people think it’s ugly.
有些人认为它很丑。
Sualeh does not like it.
苏阿莱不喜欢这样。
Well, I think it’s…
嗯，我认为这是……
1:16:14 In fact, I actually think this is one of the things I learned from Arvid is sort of aesthetically I don’t like it, but I think there’s certainly something where it’s useful for the models and humans just forget a lot, and it’s really easy to make a small mistake and cause…
事实上，我实际上认为这是我从 Arvid 学到的东西之一，在美学上我不喜欢它，但我认为它肯定对模型有用，而人类只是忘记了很多，而且很容易犯一个小错误并导致……
Just bring down the server.
只需关闭服务器即可。
Of course, we test a lot and whatever, but there’s always these things that you have to be very careful.
当然，我们进行了很多测试，但总有一些事情你必须非常小心。
Yeah, like with just normal docstrings, I think people will often just skim it when making a change and think, “Oh, I know how to do this,” and you really need to point it out to them so that doesn’t slip through.
是的，就像普通的文档字符串一样，我认为人们在进行更改时通常会浏览一下，然后想，“哦，我知道该怎么做”，你真的需要向他们指出，这样就不会漏掉。
Yeah.
是的。
1:16:55 You have to be reminded that you could do a lot of damage that’s like we don’t really think about that.
必须提醒您，您可能会造成很大的损害，就像我们没有真正考虑到这一点一样。
You think about, “Okay, how do I figure out how this works so I can improve it?” You don’t think about the other direction that it could-
你会想，“好吧，我如何弄清楚它是如何工作的，以便我可以改进它？”你不会考虑它可能的另一个方向-
Until we have formal verification for everything, then you can do whatever you want and you know for certain that you have not introduced a bug if the proof pass.
在我们对所有内容进行正式验证之前，您可以做任何您想做的事情，并且如果证明通过，您可以确定您没有引入错误。
Well, concretely, what do you think that future would look like?
嗯，具体来说，你认为未来会是什么样子？
I think people will just not write to tests anymore, and the model will suggest…
我认为人们将不再编写测试，模型会建议......
1:17:22 You write a function, the model will suggest a spec, and you review the spec.
您编写一个函数，模型会建议一个规范，然后您查看该规范。
And in the meantime, smart reasoning model computes a proof that the implementation follows the spec, and I think that happens for most functions.
与此同时，智能推理模型会计算出实现遵循规范的证明，我认为大多数功能都会发生这种情况。
Do you think this gets at a little bit some of the stuff you were talking about earlier with the difficulty of specifying intent for what you want with software, where sometimes it might be because the intent is really hard to specify, it’s also then going to be really hard to prove that it’s actually matching whatever your intent is?
您是否认为这有点像您之前讨论的一些内容，即很难指定您想要的软件的意图，有时可能是因为意图确实很难指定，然后也很难证明它实际上符合您的意图？
You think that spec is hard to generate?
您认为该规范很难生成吗？
Yeah, or just for a given spec, maybe you can…
是的，或者只是对于给定的规格，也许你可以......
1:18:01 I think there is a question of, can you actually do the formal verification?
我觉得有一个问题，你真的能做形式化验证吗？
Is that possible?
这可能吗？
I think that there’s more to dig into there, but then also-
我认为还有更多值得深入研究的地方，但同时——
Even if you have the spec?
即使你有规格？
If you have the spec-
如果您有规格
Even if you have the spec, is the spec written in natural language?
即使您有规范，规范是否是用自然语言编写的？
1:18:19 Or is it-
或者是——
No, [inaudible 01:18:21] the spec would be formal.
不，[听不清 01:18:21] 规范将是正式的。
But how easier would that be [inaudible 01:18:26]?
但这有多容易[听不清 01:18:26]？
Okay.
好的。
1:18:27 So then I think that you care about things that are not going to be easily well specified in the spec language.
所以我认为你关心的是那些在规范语言中不容易很好地指定的事情。
I see, I see.
我明白了，我明白了。
Would be maybe an argument against formal verification is all you need.
也许您所需要的只是反对形式验证的论点。
The worry is there’s this massive document-
担心的是有这么一份庞大的文件——
[inaudible 01:18:39] replacing something like unit tests, sure.
[听不清 01:18:39] 当然，要替换单元测试之类的东西。
Yeah, yeah.
是啊是啊。
1:18:41 I think you can probably also evolve the spec languages to capture some of the things that they don’t really capture right now.
我认为你也可以发展规范语言来捕获一些它们现在没有真正捕获的东西。
I don’t know.
我不知道。
I think it’s very exciting.
我认为这非常令人兴奋。
And you’re speaking not just about single functions, you’re speaking about entire code bases.
而且您谈论的不仅仅是单个函数，而是整个代码库。
I think entire code bases is harder, but that is what I would love to have and I think it should be possible.
我认为整个代码库更难，但这就是我想要的，并且我认为它应该是可能的。
1:19:00 And because you can even…
因为你甚至可以……
There’s a lot of work recently where you can prove formally verified down to the hardware, so through the…
最近有很多工作可以证明对硬件的正式验证，因此通过......
You formally verify the C code and then you formally verify through the GCC compiler and then through the Verilog down to the hardware.
您正式验证 C 代码，然后通过 GCC 编译器进行正式验证，然后通过 Verilog 深入到硬件。
And that’s incredibly big system, but it actually works.
这是一个非常大的系统，但它确实有效。
And I think big code bases are sort of similar in that and they’re like multi-layered system.
我认为大型代码库在这方面有点相似，它们就像多层系统。
And if you can decompose it and formally verify each part, then I think it should be possible.
而如果你能分解它并形式化地验证每个部分，那么我认为这应该是可能的。
I think this specification problem is a real problem, but…
我认为这个规范问题是一个真正的问题，但是......
How do you handle side effects or how do you handle, I guess, external dependencies like calling the Stripe API?
你如何处理副作用，或者我猜你如何处理外部依赖项，例如调用 Stripe API？
Maybe Stripe would write a spec for their API.
也许 Stripe 会为他们的 API 编写一个规范。
But you can’t do this for everything.
但你不能对所有事情都这样做。
1:19:49 Can you do this for everything you use?
你能对你使用的所有东西都这样做吗？
How do you do it for…
你如何做到这一点...
If there’s a language…
如果有一种语言……
Maybe people will use language models as primitives in the programs they write, and there’s a dependence on it and how do you now include that?
也许人们会在他们编写的程序中使用语言模型作为原语，并且对它有依赖性，现在如何包含它？
I think you might be able to prove that still.
我想你也许还能证明这一点。
Prove what about language models?
证明语言模型怎么样？
I think it feels possible that you could actually prove that a language model is aligned for example, or you can prove that it actually gives the right answer.
例如，我认为您实际上可以证明语言模型是对齐的，或者您可以证明它实际上给出了正确的答案。
That’s the dream.
这就是梦想。
Yeah, that is…
是的，那就是……
1:20:21 I mean, if it’s possible.
我的意思是，如果可能的话。
That’s your I have a dream speech.
这就是你的《我有一个梦想》演讲。
If it’s possible, that will certainly help with making sure your code doesn’t have bugs and making sure AI doesn’t destroy all human civilization.
如果可能的话，这肯定有助于确保你的代码没有错误，并确保人工智能不会摧毁所有人类文明。
So the full spectrum of AI safety to just bug finding.
因此，人工智能安全的全方位范围仅限于发现错误。
So you said the models struggle with bug finding.
所以你说模型很难发现错误。
What’s the hope?
希望是什么？
My hope initially is, and I can let Michael chime in too, but it was like it should first help with the stupid bugs.
我最初的希望是，我也可以让迈克尔插话，但这就像它应该首先帮助解决那些愚蠢的错误。
1:20:44 It should query quickly, catch the stupid bugs off by one error is like…
它应该快速查询，通过一个错误捕获愚蠢的错误，就像……
Sometimes you write something in a comment and do the other way.
有时，您在评论中写了一些内容，然后以其他方式执行。
It’s very common.
这很常见。
I do this.
我做这个。
I write less than in a comment and I maybe write the greater than or something like that.
我在评论中写的小于，我可能会写大于或类似的东西。
And the model is like, “Yeah, you looks sketchy.
模特就像是，“是的，你看起来很粗略。
You sure you want to do that?” But eventually, it should be able to catch harder bugs too.
你确定要这么做吗？”但最终，它也应该能够捕获更难的错误。
Yeah.
是的。
1:21:16 And I think that it’s also important to note that this is…
我认为同样重要的是要注意这是……
Having good bug, finding models feels necessary to get to the highest reaches of having AI do more and more programming for you, where you’re going to…
有了好的 bug，找到模型对于达到让 AI 为你做越来越多的编程的最高境界是必要的，你将......
If AI is building more and more of the system for you, you need to not just generate but also verify.
如果人工智能正在为你构建越来越多的系统，你不仅需要生成，还需要验证。
And without that, some of the problems that we’ve talked about before with programming, with these models will just become untenable.
如果没有这个，我们之前讨论过的一些关于编程和这些模型的问题将变得站不住脚。
So it’s not just for humans like you write a bug, I write a bug, find the bug for me, but it’s also being able to verify the AI’s code and check it is really important.
因此，这不仅对于像你写一个错误、我写一个错误、为我找到错误这样的人来说，而且能够验证人工智能的代码并检查它也非常重要。
Yeah.
是的。
1:21:52 And then how do you actually do this?
那么你实际上是如何做到这一点的呢？
We have had a lot of contentious dinner discussions of how do you actually train a bug model, but one very popular idea is it’s kind of potentially easy to introduce a bug than actually finding the bug.
我们就如何实际训练错误模型进行了很多有争议的晚餐讨论，但一个非常流行的想法是，引入错误可能比实际发现错误更容易。
And so you can train a model to introduce bugs in existing code and then you can train a reverse bug model then that can find bugs using this synthetic data.
因此，您可以训练一个模型以在现有代码中引入错误，然后您可以训练一个反向错误模型，然后使用该合成数据来查找错误。
So that’s one example, but there are lots of ideas for how to [inaudible 01:22:22].
这只是一个例子，但关于如何做到这一点有很多想法 [听不清 01:22:22]。
You can also do a bunch of work not even at the model level of taking the biggest models and then maybe giving them access to a lot of information that’s not just the code.
您还可以做很多工作，甚至不是在模型级别，采用最大的模型，然后可能让他们访问大量信息，而不仅仅是代码。
1:22:23 It’s kind of a hard problem to stare at a file and be like, “Where’s the bug?” And that’s hard for humans often, right?
盯着一个文件并问“错误在哪里？”是一个难题。这对人类来说通常很难，对吧？
And so often you have to run the code and being able to see things like traces and step through a debugger, there’s another whole other direction where it tends toward that.
通常，您必须运行代码并能够查看跟踪之类的内容并单步执行调试器，还有另一个完全不同的方向。
1:22:46 It could also be that there are two different product form factors here.
也可能有两种不同的产品形状因素。
It could be that you have a really specialty model that’s quite fast that’s running in the background and trying to spot bugs.
可能您有一个非常专业的模型，速度相当快，在后台运行并尝试发现错误。
And it might be that sometimes sort of to Arvid’s earlier example about some nefarious input box bug.
有时，这可能有点像 Arvid 之前关于一些邪恶的输入框错误的例子。
It might be that sometimes you want to like…
有时您可能想喜欢……
You know there’s a bug, you’re not just checking hypothesis free, you’re like, “This is a problem, I really want to solve it,” and you zap that with tons and tons and tons of compute, and you’re willing to put in $50 to solve that bug or something even more.
你知道存在一个错误，你不仅仅是检查假设，你会想，“这是一个问题，我真的想解决它，”然后你用大量的计算来解决这个问题，并且你愿意投入 50 美元来解决这个错误或更多。
Have you thought about integrating money into this whole thing?
你有没有想过把钱融入到这整件事中？
1:23:12 I would pay probably a large amount of money if you found a bug or even generated code that I really appreciated.
如果您发现错误，甚至生成我真正欣赏的代码，我可能会支付一大笔钱。
I had a moment a few days ago when I started using Cursor where it generated perfect three functions for interacting with the YouTube API to update captions for localization in different languages.
几天前，当我开始使用 Cursor 时，它生成了三个完美的函数，用于与 YouTube API 交互，以更新不同语言本地化的字幕。
The API documentation is not very good and the code across, if I…
API 文档不是很好，代码也很混乱，如果我……
I googled it for a while.
我用谷歌搜索了一段时间。
I couldn’t find exactly, there’s a lot of confusing information, and Cursor generated perfectly.
我找不到确切的信息，有很多令人困惑的信息，而 Cursor 生成得很完美。
1:23:53 I just sit back, I read the code, I was like, “This is correct.
我只是坐下来，阅读代码，我想，“这是正确的。
I tested it, it’s correct.” I was like, “I want to tip.” I want a button that goes, “Here’s $5.” One that’s really good just to support the company and support what the interface is.
我测试了一下，是正确的。”我当时想，“我想给小费。”我想要一个按钮，上面写着“这是 5 美元”。一个非常好的只是支持公司和支持界面。
And the other is that probably sends a strong signal like good job.
另一个是这可能会发出一个强烈的信号，比如干得好。
So there’s this much stronger signal than just accepting the code.
因此，这个信号比仅仅接受代码要强得多。
You just actually send a strong good job.
你实际上只是发送了一份很好的工作。
That and for bug finding, obviously, there’s a lot of people that would pay a huge amount of money for a bug bounty thing, right?
对于错误发现，显然有很多人愿意为错误赏金支付巨额资金，对吗？
You guys think about that?
你们想一想吗？
Yeah, it’s a controversial idea inside the company.
是的，这是公司内部有争议的想法。
1:24:33 I think it sort of depends on how much you believe in humanity almost.
我认为这在某种程度上取决于你对人性的信任程度。
I think it would be really cool if you spend nothing to try to find a bug.
我认为如果你不花任何钱来尝试找到错误，那就太酷了。
And if it doesn’t find a bug, you spend $0.
如果没有发现错误，您将花费 0 美元。
And then if it does find a bug and you click accept, then it also shows in parentheses like $1.
然后，如果它确实发现了错误并且您单击“接受”，那么它也会显示在括号中，例如 $1。
And so you spend $1 to accept the bug.
所以你花了 1 美元来接受这个 bug。
And then of course, there’s a worry like okay, “We spent a lot of computation, maybe people will just copy paste.” I think that’s a worry.
当然，还有一种担心，“我们花了很多计算，也许人们只会复制粘贴。”我认为这是一个担忧。
Then there is also the worry that introducing money into the product makes it…
还有就是担心把钱投入到产品中会导致……
It doesn’t feel as fun anymore.
感觉不再那么有趣了。
You have to think about money.
你必须考虑钱的问题。
And all you want to think about is the code, and so maybe it actually makes more sense to separate it out, and you pay some fee every month, and then you get all of these things for free.
你想要考虑的只是代码，所以也许将其分开实际上更有意义，你每个月支付一些费用，然后你免费获得所有这些东西。
But there could be a tipping component which is not like it cost this-
但可能会有一个小费组件，其成本并不像这样——
Yes, but it still has that dollar symbol.
是的，但它仍然有美元符号。
1:25:32 I think it’s fine, but I also see the point where maybe you don’t want to introduce it.
我认为这很好，但我也看到了你可能不想介绍它的一点。
Yeah, I was going to say the moment that feels like people do this is when they share it.
是的，我想说的是，当人们分享它的时候，就会感觉到他们这样做了。
1:25:40 When they have this fantastic example, they just share it with their friends.
当他们有了这个很棒的例子时，他们就会与朋友分享。
There is also a potential world where there’s a technical solution to this like honor system problem too, where if we can get to a place where we understand the output of the system more, I mean, to the stuff we were talking about with error checking with the LSP and then also running the code.
还有一个潜在的世界，其中也有一个技术解决方案，例如荣誉系统问题，如果我们能够到达一个我们可以更多地了解系统输出的地方，我的意思是，我们正在谈论的东西，通过 LSP 进行错误检查，然后运行代码。
1:25:46 But if you could get to a place where you could actually somehow verify, “Oh, I have fixed the bug,” maybe then the bounty system doesn’t need to rely on the honor system too.
但如果你能到达一个地方，你实际上可以以某种方式验证，“哦，我已经修复了错误，”也许赏金系统也不需要依赖荣誉系统。
How much interaction is there between the terminal and the code?
终端和代码之间有多少交互？
1:26:09 How much information is gained from if you run the code in the terminal?
如果在终端中运行代码，可以获得多少信息？
Can you do a loop where it runs the code and suggests how to change the code?
您可以做一个循环来运行代码并建议如何更改代码吗？
If the code and runtime gets an error?
如果代码和运行时出现错误？
Is right now there’s separate worlds completely?
现在是完全不同的世界了吗？
I know you can do control K inside the terminal to help you write the code.
我知道你可以在终端内执行 control K 来帮助你编写代码。
You can use terminal context as well inside of check command K kind of everything.
您也可以在检查命令 K 之类的所有内容中使用终端上下文。
1:26:35 We don’t have the looping part yet, so we suspect something like this could make a lot of sense.
我们还没有循环部分，所以我们怀疑这样的事情可能很有意义。
There’s a question of whether it happens in the foreground too or if it happens in the background like what we’ve been discussing.
存在一个问题，它是否也发生在前台，或者是否像我们一直在讨论的那样发生在后台。
Sure.
当然。
1:26:52 The background’s pretty cool.
背景相当炫酷。
I could be running the code in different ways.
我可以用不同的方式运行代码。
Plus there’s a database side to this, which how do you protect it from not modifying the database, but okay.
另外，还有数据库方面的问题，如何保护它不修改数据库，但是没关系。
I mean, there’s certainly cool solutions there.
我的意思是，那里肯定有很酷的解决方案。
1:27:03 There’s this new API that is being developed for…
这个新的 API 正在开发中......
It’s not in AWS, but it certainly…
它不在 AWS 中，但它肯定......
I think it’s in PlanetScale.
我认为是在 PlanetScale 中。
I don’t know if PlanetScale was the first one to you add it.
我不知道 PlanetScale 是不是你第一个添加的。
It’s this ability sort of add branches to a database, which is like if you’re working on a feature and you want to test against the broad database, but you don’t actually want to test against the broad database, you could sort of add a branch to the database.
正是这种向数据库添加分支的能力，就像如果您正在开发一个功能并且想要针对广泛的数据库进行测试，但您实际上不想针对广泛的数据库进行测试，您可以向数据库添加一个分支。
And the way they do that is they add a branch to the write-ahead log.
他们这样做的方式是向预写日志添加一个分支。
And there’s obviously a lot of technical complexity in doing it correctly.
正确地做到这一点显然有很多技术复杂性。
I guess database companies need new things to do.
我想数据库公司需要做新的事情。
They have good databases now.
他们现在拥有良好的数据库。
And I think turbopuffer, which is one of the databases we use, is going to add maybe branching to the write-ahead log.
我认为turbopuffer（我们使用的数据库之一）可能会向预写日志添加分支。
So maybe the AI agents will use branching, they’ll test against some branch, and it’s sort of going to be a requirement for the database to support branching or something.
因此，也许人工智能代理会使用分支，他们会针对某个分支进行测试，这将成为数据库支持分支或其他东西的要求。
It would be really interesting if you could branch a file system, right?
如果您可以对文件系统进行分支，那会非常有趣，对吗？
Yeah.
是的。
1:28:13 I feel like everything needs branching.
我觉得一切都需要分支。
It’s like-
就像-
Yeah.
是的。
Yeah.
是的。
1:28:17 The problem with the multiverse, right?
多元宇宙的问题，对吧？
If you branch on everything that’s like a lot.
如果你在所有事情上都分支，那就很多了。
There’s obviously these super clever algorithms to make sure that you don’t actually use a lot of space or CPU or whatever.
显然，这些超级聪明的算法可以确保您实际上不会使用大量空间或 CPU 或其他任何东西。
Okay.
好的。
1:28:32 This is a good place to ask about infrastructure.
这是询问基础设施的好地方。
So you guys mostly use AWS, what are some interesting details?
你们大多使用AWS，有哪些有趣的细节？
What are some interesting challenges?
有哪些有趣的挑战？
Why’d you choose AWS?
您为什么选择 AWS？
Why is AWS still winning?
为什么AWS仍然获胜？
Hashtag.
井号。
AWS is just really, really good.
AWS 真的非常非常好。
1:28:45 It is really good.
这真的很好。
Whenever you use an AWS product, you just know that it’s going to work.
每当您使用 AWS 产品时，您就知道它会起作用。
It might be absolute hell to go through the steps to set it up.
完成设置步骤可能绝对是地狱。
Why is the interface so horrible?
为什么界面这么糟糕？
Because it’s-
因为它是——
It’s just so good.
真是太好了。
1:29:05 It doesn’t need to-
它不需要-
It’s the nature of winning.
这就是胜利的本质。
I think it’s exactly.
我认为确实如此。
1:29:09 It’s just nature they’re winning.
他们获胜只是自然现象。
Yeah, yeah.
是啊是啊。
1:29:11 But AWS we can always trust, it will always work.
但我们始终可以信任 AWS，它永远有效。
And if there is a problem, it’s probably your problem.
如果有问题，很可能是你的问题。
Yeah.
是的。
Okay.
好的。
1:29:20 Is there some interesting challenges to…
有没有一些有趣的挑战……
You guys are pretty new startup to scaling, to so many people and-
对于很多人来说，你们都是刚刚起步的初创公司，而且——
Yeah, I think that it has been an interesting journey adding each extra zero to the request per second.
是的，我认为这是一个有趣的旅程，向每秒的请求添加每个额外的零。
1:29:29 You run into all of these with the general components you’re using for caching and databases, run into issues as you make things bigger and bigger, and now we’re at the scale where we get into overflows on our tables and things like that.
您使用用于缓存和数据库的通用组件会遇到所有这些问题，当您使事情变得越来越大时，会遇到问题，现在我们的规模已经达到了表和类似问题的溢出程度。
And then also there have been some custom systems that we’ve built.
我们还构建了一些定制系统。
For instance, our retrieval system for computing, a semantic index of your code base and answering questions about a code base that have, continually, I feel like been one of the trickier things to scale.
例如，我们的计算检索系统、代码库的语义索引以及回答有关代码库的问题，我一直觉得这是扩展过程中比较棘手的事情之一。
1:30:00 …
……
that have continually, I feel like, been one of the trickier things to scale.
我觉得这一直是最棘手的事情之一。
I have a few friends who are super senior engineers and one of their lines is, it’s very hard to predict where systems will break when you scale them.
我有几个朋友是超级高级工程师，他们的一句话是，当你扩展系统时，很难预测系统会在哪里崩溃。
1:30:04 You can try to predict in advance, but there’s always something weird that’s going to happen when you add these extras here.
您可以尝试提前预测，但是当您在此处添加这些额外内容时，总会发生一些奇怪的事情。
You thought through everything, which you didn’t actually think through everything.
你想通了一切，但实际上你并没有想通一切。
But I think for that particular system, we’ve…
但我认为对于那个特定的系统，我们......
So for concrete details, the thing we do is obviously we upload when…
因此，对于具体细节，我们所做的显然是在……时上传。
We chunk up all of your code, and then we send up the code for embedding and we embed the code.
我们将您的所有代码分块，然后发送用于嵌入的代码，然后嵌入该代码。
And then we store the embeddings in a database, but we don’t actually store any of the code.
然后我们将嵌入存储在数据库中，但我们实际上并不存储任何代码。
And then there’s reasons around making sure that we don’t introduce client bugs because we’re very, very paranoid about client bugs.
然后，我们有理由确保我们不会引入客户端错误，因为我们对客户端错误非常非常偏执。
We store much of the details on the server.
我们将许多详细信息存储在服务器上。
Everything is encrypted.
一切都已加密。
1:31:08 So one of the technical challenges is always making sure that the local index, the local code base state is the same as the state that is on the server.
因此，技术挑战之一始终是确保本地索引、本地代码库状态与服务器上的状态相同。
The way, technically, we ended up doing that is, for every single file you can keep this hash, and then for every folder you can keep a hash, which is the hash of all of its children.
从技术上讲，我们最终这样做的方式是，对于每个文件，您都可以保留此哈希值，然后对于每个文件夹，您可以保留一个哈希值，这是其所有子级的哈希值。
You can recursively do that until the top.
您可以递归地执行此操作，直到到达顶部。
Why do something complicated?
为什么要做一些复杂的事情？
One thing you could do is you could keep a hash for every file and every minute, you could try to download the hashes that are on the server, figure out what are the files that don’t exist on the server.
你可以做的一件事是你可以为每个文件和每分钟保留一个哈希值，你可以尝试下载服务器上的哈希值，找出服务器上不存在的文件是什么。
Maybe you just created a new file, maybe you just deleted a file, maybe you checked out a new branch, and try to reconcile the state between the client and the server.
也许您刚刚创建了一个新文件，也许您刚刚删除了一个文件，也许您签出了一个新分支，并尝试协调客户端和服务器之间的状态。
1:31:57 But that introduces absolutely ginormous network overhead both on the client side.
但这在客户端引入了绝对巨大的网络开销。
Nobody really wants us to hammer their WiFi all the time if you’re using Cursor.
如果你使用 Cursor，没有人真的希望我们一直攻击他们的 WiFi。
But also, it would introduce ginormous overhead on the database.
而且，它也会给数据库带来巨大的开销。
It would be reading these tens of terabytes database, approaching 20 terabytes or something data base every second.
它将每秒读取数十 TB 的数据库，接近 20 TB 或类似的数据库。
That’s just crazy.
这太疯狂了。
You definitely don’t want to do that.
你绝对不想这样做。
So what you do, you just try to reconcile the single hash, which is at the root of the project.
因此，您所做的只是尝试协调位于项目根部的单个哈希。
And then if something mismatches, then you go, you find where all the things disagree.
然后，如果有什么不匹配，那么你就会去发现所有事情不一致的地方。
Maybe you look at the children and see if the hashes match.
也许你看看孩子们，看看哈希值是否匹配。
If the hashes don’t match, go look at their children and so on.
如果哈希值不匹配，请查看他们的孩子等等。
But you only do that in the scenario where things don’t match.
但只有在事情不匹配的情况下才这样做。
For most people, most of the time, the hashes match.
对于大多数人来说，大多数时候，哈希值都是匹配的。
So it’s like a hierarchical reconciliation-
所以这就像一个层级协调——
Yeah.
是的。
…
……
1:32:53 of hashes-
哈希值-
Something like that.
类似的事情。
Yeah, it’s called a Merkle tree.
是的，它被称为默克尔树。
Yeah, Merkle.
是的，默克尔。
1:32:56 Yeah.
是的。
Yeah, this is cool to see that you have to think through all these problems.
是的，看到你必须思考所有这些问题真是太酷了。
The reason it’s gotten hard is just because the number of people using it and some of your customers have really, really large code bases to the point where…
它变得困难的原因只是因为使用它的人数和你的一些客户拥有非常非常大的代码库，以至于......
1:33:03 We originally reordered dark code base, which is big, but it’s just not the size of some company that’s been there for 20 years and has a ginormous number of files and you want to scale that across programmers.
我们最初对暗代码库进行了重新排序，该代码库很大，但它的规模还达不到某些已经存在了 20 年、拥有大量文件的公司的规模，并且您希望将其扩展到程序员之间。
There’s all these details where building the simple thing is easy, but scaling it to a lot of people, a lot of companies is obviously a difficult problem, which is independent of, actually…
在所有这些细节中，构建简单的东西很容易，但将其扩展到很多人、很多公司显然是一个困难的问题，这实际上是独立的……
so that there’s part of this scaling.
这样就有了这种缩放的一部分。
Our current solution is also coming up with new ideas that, obviously, we’re working on, but then scaling all of that in the last few weeks, months.
我们当前的解决方案也提出了新的想法，显然，我们正在研究这些想法，但随后在过去几周、几个月内扩展了所有这些想法。
Yeah.
是的。
1:33:48 There are a lot of clever things, additional things that go into this indexing system.
这个索引系统中有很多聪明的东西和附加的东西。
For example, the bottleneck in terms of costs is not soaring things in the vector database or the database.
比如成本方面的瓶颈并不是矢量数据库或者数据库里飞涨的东西。
It’s actually embedding the code.
它实际上是嵌入代码。
You don’t want to re-embed the code base for every single person in a company that is using the same exact code except for maybe they’re a different branch with a few different files or they’ve made a few local changes.
您不想为公司中使用相同代码的每个人重新嵌入代码库，除非他们是具有一些不同文件的不同分支，或者他们进行了一些本地更改。
Because again, embeddings are the bottleneck, you can do this one clever trick and not have to worry about the complexity of dealing with branches and the other databases where you just have some cash on the actual vectors computed from the hash of a given chunk.
因为嵌入是瓶颈，所以您可以使用这一聪明的技巧，而不必担心处理分支和其他数据库的复杂性，在这些数据库中，您只需在根据给定块的哈希计算出的实际向量上有一些现金即可。
So this means that when the nth person at a company goes and embed their code base, it’s really, really fast.
所以这意味着当公司的第 n 个人去嵌入他们的代码库时，速度真的非常快。
You do all this without actually storing any code on our servers at all.
您完成这一切时根本不需要在我们的服务器上实际存储任何代码。
No code data is stored.
不存储代码数据。
We just store the vectors in the vector database and the vector cache.
我们只是将向量存储在向量数据库和向量缓存中。
What’s the biggest gains at this time you get from indexing the code base?
目前，您通过索引代码库获得的最大收获是什么？
1:34:45 Just out of curiosity, what benefit do users have?
只是出于好奇，用户有什么好处？
It seems like longer term, there’ll be more and more benefit, but in the short term, just asking questions of the code base, what’s the usefulness of that?
看起来从长远来看，好处会越来越多，但从短期来看，只是问代码库的问题，这有什么用处呢？
I think the most obvious one is just, you want to find out where something is happening in your large code base, and you have a fuzzy memory of, “Okay, I want to find the place where we do X,” but you don’t exactly know what to search for in a normal text search.
我认为最明显的一个就是，你想找出大型代码库中发生了什么事情，并且你有一个模糊的记忆，“好吧，我想找到我们做 X 的地方”，但你并不确切知道在正常的文本搜索中要搜索什么。
1:35:06 So you ask a chat, you hit command enter to ask with the code base chat.
因此，您询问聊天时，您按下命令 Enter 来询问代码库聊天。
And then very often, it finds the right place that you were thinking of.
然后很多时候，它会找到你想要的正确位置。
Like you mentioned, in the future, I think there’s only going to get more and more powerful, where we’re working a lot on improving the quality of our retrieval.
就像你提到的，在未来，我认为它只会变得越来越强大，我们正在努力提高检索质量。
1:35:33 I think the ceiling for that is really, really much higher than people give the credit for.
我认为这个上限确实比人们想象的要高得多。
One question that’s good to ask here, have you considered and why haven’t you much done local stuff to where you can do the…
在这里问一个很好的问题，你有没有考虑过，为什么你没有做太多当地的事情，以便你可以做……
1:35:46 It seems like everything was just discussed as exceptionally difficult to do.
一切似乎都被讨论为异常困难。
To go to the cloud, you have to think about all these things with the caching and the large code base where a large number of programmers are using the same code base.
要转向云，您必须考虑所有这些问题，包括缓存和大量程序员使用相同代码库的大型代码库。
You have to figure out the puzzle of that.
你必须弄清楚其中的谜团。
A lot of it, most software just does this heavy computational stuff locally.
很多，大多数软件只是在本地完成这些繁重的计算工作。
So have you considered doing embeddings locally?
那么您是否考虑过在本地进行嵌入？
Yeah, we thought about it, and I think it would be cool to do it locally.
是的，我们考虑过这个问题，我认为在本地做会很酷。
1:36:18 I think it’s just really hard.
我认为这真的很难。
One thing to keep in mind is that some of our users use the latest MacBook Pro, but most of our users, more than 80% of our users are in Windows machines, which many of them are not very powerful.
要记住的一件事是，我们的一些用户使用最新的 MacBook Pro，但我们的大多数用户，超过 80% 的用户使用的是 Windows 机器，其中许多功能不是很强大。
So local models really only works on the latest computers, and it’s also a big overhead to build that in.
因此，本地模型实际上只能在最新的计算机上运行，而且构建它也是一个很大的开销。
So even if we would like to do that, it’s currently not something that we are able to focus on.
因此，即使我们想这样做，目前也不是我们能够关注的事情。
I think there are some people that do that, and I think that’s great, but especially as models get bigger and bigger and you want to do fancier things with bigger models, it becomes even harder to do it locally.
我认为有些人这样做，我认为这很棒，但特别是当模型变得越来越大并且你想用更大的模型做更奇特的事情时，在本地做就变得更加困难。
Yeah.
是的。
1:37:07 It’s not a problem of weaker computers.
这不是计算机较弱的问题。
It’s just that for example, if you’re some big company, you have big company code base.
举例来说，如果你是一家大公司，你就有大公司的代码库。
It’s just really hard to process big company code base even on the beefiest MacBook Pros.
即使在最强大的 MacBook Pro 上处理大公司的代码库也非常困难。
It’s not even a matter of if you’re just a student or something.
这甚至与你是否只是一名学生或其他什么无关。
I think if you’re the best programmer at a big company, you’re still going to have a horrible experience.
我认为如果你是一家大公司最好的程序员，你仍然会经历可怕的经历。
If you do everything locally where you could do it and scrape by, but again, it wouldn’t be fun anymore.
如果你在本地做所有事情，你可以勉强度日，但同样，它不会再有趣了。
Yeah.
是的。
1:37:40 Like at approximate nearest neighbors and this massive code base is going to just eat up your memory and your CPU, and it’s based off of that.
就像近似最近的邻居一样，这个庞大的代码库只会耗尽你的内存和 CPU，而它正是基于此。
That’s just that.
就是这样。
Let’s talk about also the modeling side where, as Arvid said, there are these massive headwinds against local models where one, things that seem to move towards MOEs, which one benefit is maybe their more memory bandwidth bound, which plays in favor of local versus using GPUs or using Nvidia GPUs.
让我们也谈谈建模方面，正如 Arvid 所说，本地模型存在巨大的阻力，其中之一似乎是向 MOE 发展，其中一个好处可能是它们的内存带宽限制更大，这有利于本地模型而不是使用 GPU 或使用 Nvidia GPU。
But the downside is, these models are just bigger in total, and they’re going to need to fit, often not even on a single node but multiple nodes.
但缺点是，这些模型总体上更大，并且它们需要适应，通常甚至不是在单个节点上而是在多个节点上。
There’s no way that’s going to fit inside of even really good MacBooks.
即使是非常好的 MacBook 也无法容纳它。
I think especially for coding, it’s not a question as much of, does it clear some bar of the model’s good enough to do these things and then we’re satisfied?
我认为特别是对于编码来说，这并不是一个问题，它是否清除了模型的某些标准，足以完成这些事情，然后我们就满意了？
Which may be the case for other problems and maybe where local models shine, but people are always going to want the best, the most intelligent, the most capable things, and that’s going to be really, really hard to run for almost all people, locally.
其他问题可能也是如此，也许本地模式大放异彩，但人们总是想要最好的、最聪明的、最有能力的东西，而这对于本地的几乎所有人来说都非常非常困难。
Don’t you want the most capable model?
您不想要最有能力的模型吗？
1:38:51 You want [inaudible 01:38:55] too?
您也想要 [听不清 01:38:55]？
And also o1-
还有o1-
I like how you’re pitching me.
我喜欢你向我推销的方式。
o1 is another-
o1 是另一个-
Would you be satisfied with an inferior model?
您会对劣质型号感到满意吗？
1:39:00 Listen, yes, I’m one of those, but there’s some people that like to do stuff locally, especially like…
听着，是的，我是其中之一，但有些人喜欢在本地做事，尤其是……
Really, there’s a whole obviously open source movement that resists.
确实，有一个明显的开源运动在抵制。
It’s good that they exist actually because you want to resist the power centers that are growing our-
它们确实存在是件好事，因为你想抵制那些正在发展我们的——
There’s actually an alternative to local models that I am particularly fond of.
实际上，我特别喜欢本地模型的替代方案。
1:39:20 I think it’s still very much in the research stage, but you could imagine to do homomorphic encryption for language model inference.
我认为它仍然处于研究阶段，但你可以想象为语言模型推理进行同态加密。
So you encrypt your input on your local machine, then you send that up, and then the server can use loss of computation.
因此，您可以在本地计算机上对输入进行加密，然后将其发送出去，然后服务器就可以使用计算损失。
They can run models that you cannot run locally on this encrypted data, but they cannot see what the data is, and then they send back the answer and you decrypt the answer and only you can see the answer.
他们可以运行你无法在这些加密数据上本地运行的模型，但他们看不到数据是什么，然后他们发回答案，你解密答案，只有你可以看到答案。
So I think that’s still very much research and all of it is about trying to make the overhead lower because right now, the overhead is really big, but if you can make that happen, I think that would be really, really cool, and I think it would be really, really impactful because I think one thing that’s actually worrisome is that, as these models get better and better, they’re going to become more and more economically useful.
所以我认为这仍然是大量的研究，所有这些都是为了试图降低开销，因为现在，开销真的很大，但如果你能做到这一点，我认为那将非常非常酷，而且我认为这将非常非常有影响力，因为我认为真正令人担忧的一件事是，随着这些模型变得越来越好，它们将变得越来越在经济上有用。
1:40:18 So more and more of the world’s information and data will flow through one or two centralized actors.
因此，世界上越来越多的信息和数据将通过一两个集中的参与者流动。
And then there are worries about, there can be traditional hacker attempts, but it also creates this scary part where if all of the world’s information is flowing through one node in plaintext, you can have surveillance in very bad ways.
然后人们担心，可能会有传统的黑客尝试，但它也造成了这个可怕的部分，如果世界上所有的信息都以明文形式流过一个节点，你就可以以非常糟糕的方式进行监视。
Sometimes that will happen for…
有时，这种情况会发生在……
Initially, will be good reasons.
最初，这将是很好的理由。
People will want to try to protect against bad actors using AI models in bad ways, and then you will add in some surveillance code.
人们会想要尝试防止不良行为者以不良方式使用人工智能模型，然后你将添加一些监视代码。
And then someone else will come in and you’re on a slippery slope, and then you start doing bad things with a lot of the world’s data.
然后其他人就会介入，你就陷入了滑坡，然后你开始用大量的世界数据做坏事。
So I am very hopeful that we can solve homomorphic encryption for-
所以我非常希望我们能够解决同态加密问题——
Yeah, and-
是的，还有-
…
……
1:41:12 language model inference.
语言模型推理。
…
……
doing privacy, preserving machine learning.
保护隐私，保护机器学习。
But I would say, that’s the challenge we have with all software these days.
但我想说，这就是当今所有软件面临的挑战。
It’s like there’s so many features that can be provided from the cloud and all us increasingly rely on it and make our life awesome.
就好像云可以提供如此多的功能，我们所有人都越来越依赖它，让我们的生活变得更加美好。
But there’s downsides, and that’s why you rely on really good security to protect from basic attacks.
但它也有缺点，这就是为什么您需要依靠真正良好的安全性来防御基本攻击。
But there’s also only a small set of companies that are controlling that data, and they obviously have leverage and they could be infiltrated in all kinds of ways.
但也只有一小部分公司控制着这些数据，而且他们显然拥有影响力，并且可以通过各种方式进行渗透。
That’s the world we live in.
这就是我们生活的世界。
So it’s-
所以这是——
Yeah, the thing I’m just actually quite worried about is the world where…
是的，我实际上非常担心的是这个世界......
1:41:43 Anthropic has this responsible scaling policy where we’re the low ASLs, which is the Anthropic security level or whatever of the models.
Anthropic 有这种负责任的扩展策略，其中我们是低 ASL，即 Anthropic 安全级别或任何模型。
But as we get to ASL-3, ASL-4, whatever models which are very powerful…
但当我们谈到 ASL-3、ASL-4 时，无论什么型号都非常强大......
But for mostly reasonable security reasons, you would want to monitor all the prompts.
但出于大多数合理的安全原因，您可能希望监视所有提示。
But I think that’s reasonable and understandable where everyone is coming from.
但我认为这是合理且可以理解的，每个人都来自于此。
But man, it’d be really horrible if all the world’s information is monitored that heavily, it’s way too centralized.
但是，如果世界上所有的信息都受到如此严格的监控，那就太可怕了，这太集中了。
It’s like this really fine line you’re walking where on the one side, you don’t want the models to go rogue.
就像你正在走的这条非常细的线，一方面，你不希望模型失控。
On the other side, humans like…
另一方面，人类喜欢……
I don’t know if I trust all the world’s information to pass through three model providers.
我不知道我是否相信世界上所有的信息都通过三个模型提供商传递。
Why do you think it’s different than cloud providers?
为什么您认为它与云提供商不同？
Because I think a lot of this data would never have gone to the cloud providers in the first place where this is often…
因为我认为很多数据一开始就不会流向云提供商，而这通常是……
1:42:47 You want to give more data to the AI models, you want to give personal data that you would never have put online in the first place to these companies or to these models.
你想向人工智能模型提供更多数据，你想向这些公司或这些模型提供你本来不会放在网上的个人数据。
It also centralizes control where right now, for cloud, you can often use your own encryption keys, and AWS can’t really do much.
它还集中控制，目前，对于云，您通常可以使用自己的加密密钥，而 AWS 确实无能为力。
But here, it’s just centralized actors that see the exact plain text of everything.
但在这里，只有中心化的参与者才能看到所有内容的确切明文。
Yeah.
是的。
1:43:31 On the topic of a context, that’s actually been a friction for me.
关于背景这个话题，这对我来说实际上是一个摩擦。
When I’m writing code in Python, there’s a bunch of stuff imported.
当我用 Python 编写代码时，会导入很多东西。
You could probably intuit the kind of stuff I would like to include in the context.
您可能会凭直觉知道我想在上下文中包含哪些内容。
How hard is it to auto figure out the context?
自动找出上下文有多难？
It’s tricky.
这很棘手。
1:43:51 I think we can do a lot better at computing the context automatically in the future.
我认为我们将来可以在自动计算上下文方面做得更好。
One thing that’s important to note is, there are trade-offs with including automatic context.
需要注意的一件事是，包含自动上下文需要权衡。
So the more context you include for these models, first of all, the slower they are and the more expensive those requests are, which means you can then do less model calls and do less fancy stuff in the background.
因此，您为这些模型包含的上下文越多，首先，它们的速度就越慢，这些请求的成本就越高，这意味着您可以执行更少的模型调用并在后台执行更少的花哨的事情。
Also, for a lot of these models, they get confused if you have a lot of information in the prompt.
此外，对于许多这样的模型，如果提示中包含大量信息，它们会感到困惑。
So the bar for accuracy and for relevance of the context you include should be quite high.
因此，您所包含的上下文的准确性和相关性的标准应该相当高。
Already, we do some automatic context in some places within the product.
我们已经在产品的某些地方做了一些自动上下文。
It’s definitely something we want to get a lot better at.
这绝对是我们想要做得更好的事情。
I think that there are a lot of cool ideas to try there, both on the learning better retrieval systems, like better embedding models, better rerankers.
我认为有很多很酷的想法可以尝试，包括学习更好的检索系统，比如更好的嵌入模型、更好的重新排序器。
1:44:48 I think that there are also cool academic ideas, stuff we’ve tried out internally, but also the field is grappling with writ large about, can you get language models to a place where you can actually just have the model itself understand a new corpus of information?
我认为还有一些很酷的学术想法，我们在内部尝试过的东西，但这个领域也正在努力解决这个问题，你能否将语言模型发展到一个可以让模型本身理解新信息语料库的地方？
The most popular talked about version of this is can you make the context windows infinite?
最流行的讨论版本是你能让上下文窗口无限吗？
Then if you make the context windows infinite, can you make the model actually pay attention to the infinite context?
那么如果你让上下文窗口无限，你能让模型真正关注无限的上下文吗？
And then after you can make it pay attention to the infinite context to make it somewhat feasible to actually do it, can you then do caching for that infinite context?
然后，当您可以让它关注无限上下文以使其实际执行起来有些可行之后，您可以为该无限上下文进行缓存吗？
You don’t have to recompute that all the time.
您不必一直重新计算。
But there are other cool ideas that are being tried, that are a little bit more analogous to fine-tuning of actually learning this information in the weights of the model.
但还有其他很酷的想法正在尝试，这些想法更类似于在模型权重中实际学习这些信息的微调。
It might be that you actually get a qualitative lead different type of understanding if you do it more at the weight level than if you do it at the in-context learning level.
如果你在权重级别上做得比在上下文学习级别上做得更多，你实际上可能会获得不同类型的定性领先理解。
1:45:37 I think the jury’s still a little bit out on how this is all going to work in the end?
我认为，对于这一切最终将如何进行，陪审团仍然有点不明白？
But in the interim, us as a company, we are really excited about better retrieval systems and picking the parts of the code base that are most relevant to what you’re doing, and we could do that a lot better.
但在此期间，作为一家公司，我们对更好的检索系统和挑选与您正在做的事情最相关的代码库部分感到非常兴奋，我们可以做得更好。
One interesting proof of concept for the learning this knowledge directly in the weights is with VS Code.
直接在权重中学习这些知识的一个有趣的概念证明是使用 VS Code。
1:45:52 So we’re in a VS Code fork and VS Code.
所以我们处于 VS Code 分支和 VS Code 中。
The code is all public.
代码全部公开。
So these models in pre-training have seen all the code.
所以这些模型在预训练中已经看到了所有的代码。
They’ve probably also seen questions and answers about it.
他们可能也看过相关的问题和答案。
And then they’ve been fine-tuned and RLHFed to be able to answer questions about code in general.
然后，它们经过微调和 RLHFed，能够回答有关代码的一般问题。
So when you ask it a question about VS Code, sometimes it’ll hallucinate, but sometimes it actually does a pretty good job at answering the question.
因此，当你向它询问有关 VS Code 的问题时，有时它会产生幻觉，但有时它实际上可以很好地回答问题。
I think this is just by…
我认为这只是通过...
It happens to be okay, but what if you could actually specifically train or post-train a model such that it really was built to understand this code base?
碰巧没问题，但是如果您实际上可以专门训练或后训练一个模型，使其真正能够理解此代码库，该怎么办？
1:46:38 It’s an open research question, one that we’re quite interested in.
这是一个开放的研究问题，我们对此非常感兴趣。
And then there’s also uncertainty of, do you want the model to be the thing that end-to-end is doing everything, i.e. it’s doing the retrieval in its internals and then answering a question, creating the code, or do you want to separate the retrieval from the frontier model, where maybe you’ll get some really capable models that are much better than the best open source ones in a handful of months?
然后还存在不确定性，您是否希望模型成为端到端执行所有操作的模型，即它在内部进行检索，然后回答问题，创建代码，或者您是否希望将检索与前沿模型分开，也许您会在几个月内得到一些真正有能力的模型，比最好的开源模型要好得多？
And then you’ll want to separately train a really good open source model to be the retriever, to be the thing that feeds in the context to these larger models.
然后，您需要单独训练一个非常好的开源模型作为检索器，作为在上下文中为这些更大的模型提供数据的东西。
Can you speak a little more to post-training a model to understand the code base?
您能多谈谈对模型进行后训练以理解代码库吗？
1:47:14 What do you mean by that?
你这是什么意思？
Is this a synthetic data direction?
这是综合数据方向吗？
Is this-
这是——
Yeah, there are many possible ways you could try doing it.
是的，有很多可能的方法你可以尝试这样做。
1:47:23 There’s certainly no shortage of ideas.
当然不乏想法。
It’s just a question of going in and trying all of them and being empirical about which one works best.
这只是一个深入尝试所有方法并根据经验确定哪一个最有效的问题。
One very naive thing is to try to replicate what’s done with VS Code and these frontier models.
一件非常天真的事情是尝试复制 VS Code 和这些前沿模型所做的事情。
So let’s continue pre-training.
那么我们继续进行预训练。
Some kind of continued pre-training that includes general code data but also throws in of the data of some particular repository that you care about.
某种持续的预训练，包括一般代码数据，但也加入您关心的某些特定存储库的数据。
And then in post-training, meaning in…
然后在训练后，这意味着……
Let’s just start with instruction fine-tuning.
让我们从指令微调开始。
You have a normal instruction fine-tuning data set about code.
您有一个关于代码的正常指令微调数据集。
Then you throw in a lot of questions about code in that repository.
然后你提出了很多关于该存储库中的代码的问题。
1:48:07 So you could either get ground truth ones, which might be difficult or you could do what you hinted at or suggested using synthetic data, i.e. having the model ask questions about various recent pieces of the code.
因此，您可以获取真实的数据，这可能很困难，或者您可以使用合成数据执行您暗示或建议的操作，即让模型询问有关最近的各种代码片段的问题。
So you take the pieces of the code, then prompt the model or have a model propose a question for that piece of code, and then add those as instruction fine-tuning data points.
因此，您获取代码片段，然后提示模型或让模型针对该代码片段提出问题，然后将它们添加为指令微调数据点。
And then in theory, this might unlock the model’s ability to answer questions about that code base.
从理论上讲，这可能会释放模型回答有关该代码库的问题的能力。
Let me ask you about OpenAI o1.
我想问一下有关 OpenAI o1 的问题。
1:48:39 What do you think is the role of that kind of test time compute system in programming?
您认为这种测试时间计算系统在编程中的作用是什么？
I think test time compute is really, really interesting.
我认为测试时间计算真的非常非常有趣。
1:48:47 So there’s been the pre-training regime which will, as you scale up the amount of data and the size of your model, get you better and better performance both on loss and then on downstream benchmarks and just general performance.
因此，当您扩大数据量和模型大小时，预训练机制将使您在损失、下游基准测试以及一般性能方面获得越来越好的性能。
So we use it for coding or other tasks.
所以我们用它来编码或其他任务。
We’re starting to hit a bit of a data wall.
我们开始遇到一些数据墙。
Meaning, it’s going to be hard to continue scaling up this regime.
这意味着，继续扩大这一制度将很困难。
So scaling up test time compute is an interesting way, if now increasing the number of inference time flops that we use but still getting…
因此，扩大测试时间计算是一种有趣的方法，如果现在增加我们使用的推理时间触发器的数量，但仍然得到......
Yeah, as you increase the number of flops you use inference time getting corresponding improvements in the performance of these models.
是的，当你增加失败次数时，你使用的推理时间就会使这些模型的性能得到相应的改进。
Traditionally, we just had to literally train a bigger model that always used that many more flops, but now, we could perhaps use the same size model and run it for longer to be able to get an answer at the quality of a much larger model.
传统上，我们只需要训练一个更大的模型，该模型总是使用更多的失败次数，但现在，我们也许可以使用相同大小的模型并运行更长时间，以便能够获得更大模型质量的答案。
1:49:46 So the really interesting thing I like about this is there are some problems that perhaps require 100 trillion parameter model intelligence trained on 100 trillion tokens.
因此，我真正喜欢的一点是，有些问题可能需要在 100 万亿个代币上训练 100 万亿个参数模型智能。
But that’s maybe 1%, maybe 0.1% of all queries.
但这可能只占所有查询的 1%，也可能是 0.1%。
So are you going to spend all of this effort, all of this compute training a model that costs that much and then run it so infrequently?
那么，您是否会花费所有这些精力、所有这些计算来训练一个成本如此之高的模型，然后很少运行它？
It feels completely wasteful when instead you get the model that can…
当你得到可以……的模型时，感觉完全浪费了。
You train the model that is capable of doing the 99.9% of queries, then you have a way of inference time running it longer for those few people that really, really want max intelligence.
你训练的模型能够完成 99.9% 的查询，然后你就有了一种推理时间的方法，可以为那些真正想要最大智能的少数人运行更长的时间。
How do you figure out which problem requires what level of intelligence?
你如何确定哪个问题需要什么水平的智力？
1:50:28 Is that possible to dynamically figure out when to use GPT-4, when to use a small model and when you need the o1?
是否可以动态地确定何时使用 GPT-4、何时使用小模型以及何时需要 o1？
Yeah, that’s an open research problem, certainly.
是的，这当然是一个开放的研究问题。
1:50:44 I don’t think anyone’s actually cracked this model routing problem quite well.
我认为没有人真正很好地解决了这个模型路由问题。
We have initial implementations of this for something like Cursor Tab, but at the level of going between 4o sonnet to o1, it’s a bit trickier.
我们已经针对 Cursor Tab 之类的东西进行了初步实现，但在 4o sonnet 到 o1 之间的级别上，它有点棘手。
There’s also a question like, what level of intelligence do you need to determine if the thing is too hard for the four level model?
还有一个问题，比如，你需要什么水平的智力来确定这件事对于四级模型来说是否太难？
Maybe you need the o1 level model.
也许您需要 o1 级别模型。
It’s really unclear.
实在是不清楚。
But you mentioned this.
但你提到了这一点。
1:51:19 So there’s a pre-training process then there’s post-training, and then there’s test time compute.
因此，有一个预训练过程，然后是训练后过程，然后是测试时间计算。
Is that fair to separate?
分开公平吗？
Where’s the biggest gains?
最大的收获在哪里？
Well, it’s weird because test time compute, there’s a whole training strategy needed to get test time compute to work.
嗯，这很奇怪，因为测试时间计算，需要一个完整的训练策略才能让测试时间计算发挥作用。
1:51:31 The other really weird thing about this is outside of the big labs and maybe even just OpenAI, no one really knows how it works.
另一个非常奇怪的事情是在大型实验室之外，甚至可能只是 OpenAI，没有人真正知道它是如何工作的。
There’ve been some really interesting papers that show hints of what they might be doing.
有一些非常有趣的论文暗示了他们可能正在做的事情。
So perhaps they’re doing something with tree search using process reward models.
所以也许他们正在使用过程奖励模型进行树搜索。
But yeah, I think the issue is we don’t quite know exactly what it looks like, so it would be hard to comment on where it fits in.
但是，是的，我认为问题是我们不太清楚它到底是什么样子，所以很难评论它适合什么地方。
I would put it in post-training, but maybe the compute spent for this kind of…
我会把它放在训练后，但也许这种计算所花费的......
forgetting test time compute to work for a model is going to dwarf pre-training eventually.
忘记为模型工作的测试时间计算最终会使预训练相形见绌。
So we don’t even know if o1 is using just chain of thought or we don’t know how they’re using any of these?
所以我们甚至不知道 o1 是否只使用了思想链，或者我们不知道他们如何使用其中任何一个？
1:52:18 We don’t know anything?
我们什么都不知道？
It’s fun to speculate.
推测很有趣。
If you were to build a competing model, what would you do?
如果你要建立一个竞争模型，你会做什么？
Yeah.
是的。
1:52:35 So one thing to do would be, I think you probably need to train a process reward model, which is…
所以要做的一件事是，我认为你可能需要训练一个过程奖励模型，这是......
So maybe we can get into reward models and outcome reward models versus process reward models.
因此，也许我们可以讨论奖励模型、结果奖励模型与过程奖励模型。
Outcome reward models are the traditional reward models that people are trained for language modeling, and it’s just looking at the final thing.
结果奖励模型是人们接受语言建模训练的传统奖励模型，它只关注最终的事情。
So if you’re doing some math problem, let’s look at that final thing.
所以，如果你正在做一些数学问题，让我们看看最后一件事。
You’ve done everything and let’s assign a grade to it, how likely we think…
你已经完成了所有事情，让我们给它打个分，我们认为……的可能性有多大……
What’s the reward for this outcome?
这个结果的奖励是什么？
Process reward models instead try to grade the chain of thought.
相反，过程奖励模型尝试对思想链进行评分。
So OpenAI had preliminary paper on this, I think, last summer where they use human labelers to get this pretty large several hundred thousand data set of creating chains of thought.
我想，去年夏天，OpenAI 就此发表了初步论文，他们使用人工标记器来获取这个相当大的数十万数据集，以创建思想链。
Ultimately, it feels like I haven’t seen anything interesting in the ways that people use process reward models outside of just using it as a means of affecting how we choose between a bunch of samples.
最终，我感觉除了将过程奖励模型用作影响我们如何在一堆样本之间进行选择的一种手段之外，我还没有看到人们使用过程奖励模型的任何有趣的方式。
1:53:36 So what people do in all these papers is they sample a bunch of outputs from the language model, and then use the process reward models to grade all those generations alongside maybe some other heuristics and then use that to choose the best answer.
因此，人们在所有这些论文中所做的就是从语言模型中采样一堆输出，然后使用过程奖励模型对所有这些代进行评分，也许还有一些其他启发式方法，然后使用它来选择最佳答案。
The really interesting thing that people think might work and people want to work is tree search with these process reward models.
人们认为可能有效并且人们想要工作的真正有趣的事情是使用这些过程奖励模型进行树搜索。
Because if you really can grade every single step of the chain of thought, then you can branch out and explore multiple paths of this chain of thought and then use these process reward models to evaluate how good is this branch that you’re taking.
因为如果你真的可以对思想链的每一步进行评分，那么你就可以分支并探索这个思想链的多个路径，然后使用这些过程奖励模型来评估你正在采取的这个分支有多好。
Yeah.
是的。
1:54:14 When the quality of the branch is somehow strongly correlated with the quality of the outcome at the very end, so you have a good model of knowing which branch to take.
当分支的质量在某种程度上与最终结果的质量密切相关时，您就有了一个很好的模型来知道要采用哪个分支。
So not just in the short term, in the long term?
那么不仅仅是短期，长期来看呢？
Yeah.
是的。
1:54:26 The interesting work that I think has been done is figuring out how to properly train the process…
我认为已经完成的有趣的工作是弄清楚如何正确地训练这个过程......
Or the interesting work that has been open sourced and people I think talk about is how to train the process reward models, maybe in a more automated way.
或者我认为已经开源的有趣工作是如何训练过程奖励模型，也许以更自动化的方式。
I could be wrong here, could not be mentioning some papers.
我在这里可能是错的，不能提及某些论文。
I haven’t seen anything super that seems to work really well for using the process reward models creatively to do tree search and code.
我还没有看到任何超级的东西似乎可以非常有效地创造性地使用过程奖励模型来进行树搜索和编码。
This is an AI safety, maybe a bit of a philosophy question.
这是一个人工智能安全问题，也许有点哲学问题。
1:54:52 So OpenAI says that they’re hiding the chain of thought from the user, and they’ve said that that was a difficult decision to make.
因此 OpenAI 表示他们向用户隐藏了思想链，并且他们表示这是一个很难做出的决定。
Instead of showing the chain of thought, they’re asking the model to summarize the chain of thought.
他们没有显示思想链，而是要求模型总结思想链。
They’re also in the background saying they’re going to monitor the chain of thought to make sure the model is not trying to manipulate the user, which is a fascinating possibility.
他们还在后台表示，他们将监控思想链，以确保模型不会试图操纵用户，这是一个令人着迷的可能性。
But anyway, what do you think about hiding the chain of thought?
但无论如何，你觉得隐藏思想链怎么样？
One consideration for OpenAI, and this is completely speculative, could be that they want to make it hard for people to distill these capabilities out of their model.
OpenAI 的一个考虑因素（这完全是推测性的）可能是他们想让人们很难从他们的模型中提取这些功能。
1:55:21 It might actually be easier if you had access to that hidden chain of thought to replicate the technology, because pretty important data, like seeing the steps that the model took to get to the final results.
如果您能够访问隐藏的思想链来复制该技术，实际上可能会更容易，因为非常重要的数据，例如查看模型为获得最终结果而采取的步骤。
So you could probably train on that also?
那么你也可以进行这方面的训练吗？
And there was a mirror situation with this, with some of the large language model providers, and also this is speculation, but some of these APIs used to offer easy access to log probabilities for all the tokens that they’re generating and also log probabilities over the prompt tokens.
一些大型语言模型提供商也存在类似的情况，这也是猜测，但其中一些 API 用于提供轻松访问它们生成的所有标记的日志概率以及提示标记的日志概率。
1:55:42 And then some of these APIs took those away.
然后其中一些 API 拿走了这些。
Again, complete speculation, but one of the thoughts is that the reason those were taken away is if you have access to log probabilities similar to this hidden chain of thought, that can give you even more information to try and distill these capabilities out of the APIs, out of these biggest models and to models you control.
再次强调，完全是猜测，但其中一个想法是，这些被取消的原因是，如果您能够访问类似于此隐藏思想链的日志概率，这可以为您提供更多信息，以尝试从 API、这些最大的模型和您控制的模型中提取这些功能。
As an asterisk on also the previous discussion about us integrating o1, I think that we’re still learning how to use this model.
作为之前关于我们集成 o1 的讨论的星号，我认为我们仍在学习如何使用这个模型。
So we made o1 available in Cursor because when we got the model, we were really interested in trying it out.
因此，我们在 Cursor 中提供了 o1，因为当我们获得模型时，我们真的很想尝试一下。
I think a lot of programmers are going to be interested in trying it out.
我认为很多程序员都会有兴趣尝试一下。
1:56:40 o1 is not part of the default Cursor experience in any way up, and we still haven’t found a way to yet integrate it into the editor in a way that we reach for every hour, maybe even every day.
o1 无论如何都不是默认光标体验的一部分，我们仍然没有找到一种方法将其集成到编辑器中，以我们每小时甚至每天都能达到的方式。
So I think that the jury’s still out on how to use the model, and we haven’t seen examples yet of people releasing things where it seems really clear like, oh, that’s now the use case.
因此，我认为对于如何使用该模型，目前还没有定论，而且我们还没有看到人们发布看起来非常明确的东西的例子，比如，哦，这就是现在的用例。
The obvious one to turn to is maybe this can make it easier for you to have these background things running, to have these models and loops, to have these models be agentic.
最明显的一个问题是，这也许可以让你更容易地运行这些后台事物，让这些模型和循环，让这些模型成为代理。
But we’re still discovering,
但我们仍在发现，
To be clear, we have ideas.
需要明确的是，我们有想法。
1:57:22 We just need to try and get something incredibly useful before we put it out there.
我们只需要在发布之前尝试获得一些非常有用的东西即可。
But it has these significant limitations.
但它有这些重大的局限性。
1:57:29 Even barring capabilities, it does not stream.
即使限制功能，它也不会流式传输。
That means it’s really, really painful to use for things where you want to supervise the output.
这意味着用它来监控输出是非常非常痛苦的。
Instead, you’re just waiting for the wall text to show up.
相反，您只需等待墙上的文字出现即可。
Also, it does feel like the early innings of test time, compute and search where it’s just a very, very much a v0, and there’s so many things that don’t feel quite right.
而且，它确实感觉像是测试时间、计算和搜索的早期阶段，它只是一个非常非常 v0 的版本，而且有很多事情感觉不太对劲。
I suspect in parallel to people increasing the amount of pre-training data and the size of the models and pre-training and finding tricks there, you’ll now have this other thread of getting search to work better and better.
我怀疑，在人们增加预训练数据量和模型大小以及预训练和寻找技巧的同时，你现在还会有另一个让搜索工作得越来越好的线索。
So let me ask you about strawberry tomorrow eyes.
那么让我问你关于明天草莓眼睛的事情。
1:58:13 So it looks like GitHub Copilot might be integrating o1 in some kind of way, and I think some of the comments are saying, does this mean Cursor is done?
所以看起来 GitHub Copilot 可能会以某种方式集成 o1，我认为一些评论是在说，这是否意味着 Cursor 已经完成了？
I think I saw one comment saying that.
我想我看到一条评论是这么说的。
It’s a time to shut down Cursor.
现在是关闭 Cursor 的时候了。
1:58:35 Yeah.
是的。
Time to shut down Cursor.
是时候关闭光标了。
[inaudible 01:58:38].
[听不清 01:58:38]。
Thank you.
谢谢。
1:58:39 So is it time to shut down Cursor?
那么是时候关闭 Cursor 了吗？
I think this space is a little bit different from past software spaces over the 2010s, where I think that the ceiling here is really, really, really incredibly high.
我认为这个领域与 2010 年代过去的软件领域有点不同，我认为这里的上限真的非常非常高。
1:58:41 So I think that the best product in three to four years will just be soon much more useful than the best product today.
所以我认为三到四年内最好的产品很快就会比今天最好的产品有用得多。
You can wax poetic about moats this and brand that and this is our advantage, but I think in the end, just if you stop innovating on the product, you will lose.
你可以对这个护城河和品牌进行诗意的描述，这是我们的优势，但我认为最终，如果你停止产品创新，你就会失败。
That’s also great for startups, that’s great for people trying to enter this market because it means you have an opportunity to win against people who have lots of users already by just building something better.
这对于初创公司来说也很棒，对于试图进入这个市场的人来说也很棒，因为这意味着你有机会通过构建更好的东西来击败那些已经拥有大量用户的人。
So I think over the next few years, it’s just about building the best product, building the best system.
所以我认为在接下来的几年里，我们要做的就是打造最好的产品，打造最好的系统。
That both comes down to the modeling engine side of things, and it also comes down to the editing experience.
这既取决于建模引擎方面，也取决于编辑体验。
Yeah, I think most of the additional value from Cursor versus everything else out there is not just integrating the new model fast like o1.
是的，我认为与其他所有产品相比，Cursor 的大部分附加价值不仅仅是像 o1 那样快速集成新模型。
1:59:37 It comes from all of the depth that goes into these custom models that you don’t realize are working for you in every facet of the product, as well as the really thoughtful UX with every single feature.
它来自于这些定制模型的所有深度，您没有意识到这些模型在产品的各个方面都为您工作，以及每个功能都经过深思熟虑的用户体验。
All right.
好的。
2:00:01 From that profound answer-
从那个深刻的答案——
All right, from that profound answer, let’s descend back down to the technical.
好吧，从这个深刻的答案开始，让我们回到技术层面。
You mentioned you have a taxonomy of synthetic data.
您提到您有合成数据的分类法。
Oh yeah.
哦，是的。
Can you please explain?
你能解释一下吗？
Yeah, I think there are three main kinds of synthetic data.
是的，我认为合成数据主要分为三种。
2:00:10 So what is synthetic data, first?
那么，首先什么是合成数据？
So there’s normal data, like non-synthetic data, which is just data that’s naturally created, i.e. usually it’ll be from humans having done things.
因此，存在正常数据，例如非合成数据，它们只是自然创建的数据，即通常来自人类所做的事情。
So from some human process you get this data.
因此，您可以从某些人工过程中获得这些数据。
Synthetic data, the first one would be distillation.
综合数据，第一个是蒸馏。
So having a language model, output tokens or probability distributions over tokens, and then you can train some less capable model on this.
因此，拥有一个语言模型，输出标记或标记上的概率分布，然后您可以在此训练一些能力较差的模型。
2:00:45 This approach is not going to get you a more capable model than the original one that has produced the tokens, but it’s really useful for if there’s some capability you want to elicit from some really expensive high-latency model.
这种方法不会为您提供比生成代币的原始模型更强大的模型，但如果您想从一些非常昂贵的高延迟模型中获得某些功能，那么它确实非常有用。
You can then distill that down into some smaller task-specific model.
然后，您可以将其提炼为一些较小的特定于任务的模型。
2:01:04 The second kind is when one direction of the problem is easier than the reverse.
第二种是问题的一个方向比相反方向更容易。
So a great example of this is bug detection, like we mentioned earlier, where it’s a lot easier to introduce reasonable-looking bugs than it is to actually detect them.
因此，一个很好的例子就是错误检测，就像我们之前提到的那样，引入看起来合理的错误比实际检测它们要容易得多。
And this is probably the case for humans too.
人类可能也是如此。
And so what you can do, is you can get a model that’s not trained in that much data, that’s not that smart, to introduce a bunch of bugs and code.
所以你能做的是，你可以获得一个没有接受过那么多数据训练的模型，这不是那么聪明，会引入一堆错误和代码。
And then you can use that to then train…
然后你可以用它来训练......
Use the synthetic data to train a model that can be really good at detecting bugs.
使用合成数据来训练一个能够真正擅长检测错误的模型。
2:01:42 The last category I think is, I guess the main one that it feels like the big labs are doing for synthetic data, which is producing text with language models that can then be verified easily.
我认为的最后一类是，我认为大型实验室正在为合成数据所做的主要一类，即使用语言模型生成文本，然后可以轻松验证。
So extreme example of this is if you have a verification system that can detect if language is Shakespeare level, and then you have a bunch of monkeys typing and typewriters.
极端的例子是，如果你有一个验证系统，可以检测语言是否达到莎士比亚的水平，然后你有一群猴子打字和打字机。
You can eventually get enough training data to train a Shakespeare-level language model.
您最终可以获得足够的训练数据来训练莎士比亚级别的语言模型。
2:02:12 And I mean this is very much the case for math where verification is actually really, really easy for formal languages.
我的意思是数学的情况非常如此，对于形式语言来说验证实际上非常非常容易。
And then what you can do, is you can have an okay model, generate a ton of rollouts, and then choose the ones that you know have actually proved the ground truth theorems, and train that further.
然后你可以做的是，你可以拥有一个好的模型，生成大量的展示，然后选择你知道的那些实际上已经证明了基本事实定理的模型，并进一步训练它。
2:02:34 There’s similar things you can do for code with lead code like problems, where if you have some set of tests that you know correspond to if something passes these tests, it actually solved problem.
您可以对具有引导代码之类的问题的代码执行类似的操作，如果您有一组测试，您知道如果某些内容通过了这些测试，则它实际上可以解决问题。
You could do the same thing where you verify that it’s passed the test and then train the model in the outputs that have passed the tests.
您可以执行相同的操作，验证它是否通过了测试，然后在通过测试的输出中训练模型。
2:02:51 I think it’s going to be a little tricky getting this to work in all domains, or just in general.
我认为要让它在所有领域或一般情况下发挥作用会有点棘手。
Having the perfect verifier feels really, really hard to do with just open-ended miscellaneous tasks.
对于开放式的杂项任务来说，拥有完美的验证者感觉真的非常困难。
You give the model or more long horizon tasks, even in coding.
您可以给出模型或更长期的任务，甚至在编码中也是如此。
That’s because you’re not as optimistic as Arvid.
那是因为你不像阿维德那么乐观。
2:03:09 But yeah, so yeah, that third category requires having a verifier.
但是，是的，是的，第三类需要有一个验证者。
Verification, it feels like it’s best when you know for a fact that it’s correct.
验证，当你知道它是正确的事实时，感觉最好。
2:03:17 And then it wouldn’t be like using a language model to verify.
然后就不会像使用语言模型来验证了。
It would be using tests or formal systems.
它将使用测试或正式系统。
Or running the thing too.
或者也运行这个东西。
2:03:28 Doing the human form of verification, where you just do manual quality control.
进行人工形式的验证，您只需进行手动质量控制。
Yeah.
是的。
But the language model version of that, where it’s running the thing and it actually understands the output.
但是它的语言模型版本，它运行这个东西并且它实际上理解输出。
Yeah.
是的。
2:03:39 No, that’s-
不，那是——
I’m sure it’s somewhere in between.
我确信它介于两者之间。
Yeah.
是的。
2:03:41 I think that’s the category that is most likely to result in massive gains.
我认为这是最有可能带来巨大收益的类别。
What about RL with feedback side RLHF versus RLAIF?
带有反馈端 RLHF 和 RLAIF 的 RL 怎么样？
2:03:48 What’s the role of that in getting better performance on the models?
这对于获得更好的模型性能有何作用？
Yeah.
是的。
2:04:00 So RLHF is when the reward model you use is trained from some labels you’ve collected from humans giving feedback.
因此，RLHF 是指您使用的奖励模型是根据您从提供反馈的人类那里收集的一些标签进行训练的。
I think this works if you have the ability to get a ton of human feedback for this kind of task that you care about.
我认为，如果您有能力针对您关心的此类任务获得大量人类反馈，那么这就是有效的。
2:04:21 RLAIF is interesting because you’re depending on…
RLAIF 很有趣，因为您依赖于……
This is actually, it’s depending on the constraint that verification is actually a decent bit easier than generation.
这实际上取决于验证实际上比生成容易一点的约束。
Because it feels like, okay, what are you doing?
因为感觉就像，好吧，你在做什么？
Are you using this language model to look at the language model outputs and then prove the language model?
您是否使用该语言模型来查看语言模型输出，然后证明该语言模型？
But no, it actually may work if the language model has a much easier time verifying some solution than it does generating it.
但不，如果语言模型验证某些解决方案比生成它更容易，那么它实际上可能会起作用。
Then you actually could perhaps get this kind of recursive loop.
那么你实际上也许可以得到这种递归循环。
But I don’t think it’s going to look exactly like that.
但我认为它看起来不会完全像那样。
2:04:56 The other thing you could do, that we kind of do, is a little bit of a mix of RLAIF and RLHF, where usually the model is actually quite correct and this is the case of precursor tap picking between two possible generations of what is the better one.
您可以做的另一件事，也就是我们所做的，是 RLAIF 和 RLHF 的一点混合，通常模型实际上是相当正确的，这是在两个可能的更好代之间进行前体抽头采摘的情况。
And then it just needs a little bit of human nudging with only on the order 50, 100 examples to align that prior the model has with exactly with what you want.
然后它只需要一点点人工推动，只需 50、100 个示例即可将模型的先验结果与您想要的完全一致。
2:05:29 It looks different than I think normal RLHF where you’re usually training these reward models in tons of examples.
它看起来与我认为的正常 RLHF 不同，在正常 RLHF 中，你通常会在大量示例中训练这些奖励模型。
What’s your intuition when you compare generation and verification or generation and ranking?
当您比较生成和验证或生成和排名时，您的直觉是什么？
2:05:35 Is ranking way easier than generation?
排名比生成容易吗？
My intuition would just say, yeah, it should be.
我的直觉只会说，是的，应该如此。
2:05:45 This is going back to…
这又要回到……
Like, if you believe P does not equal NP, then there’s this massive class of problems that are much, much easier to verify given proof, than actually proving it.
就像，如果你相信 P 不等于 NP，那么有一类大量的问题，验证给定的证据比实际证明它要容易得多。
I wonder if the same thing will prove P not equal to NP or P equal to NP.
我想知道同样的事情是否可以证明P不等于NP或P等于NP。
That would be really cool.
那真是太酷了。
That’d be a whatever Field’s Medal by AI.
那将是人工智能颁发的菲尔兹奖章。
2:06:11 Who gets the credit?
谁获得功劳？
Another the open philosophical question.
另一个开放的哲学问题。
Whoever prompted it.
无论是谁促使的。
I’m actually surprisingly curious what a good bet for one AI will get the Field’s Medal will be.
事实上，我很好奇一个人工智能将获得菲尔德奖章的好赌注是什么。
2:06:24 I actually don’t have-
我其实没有——
Isn’t this Aman’s specialty?
这不是阿曼的特色吗？
I don’t know what Aman’s bet here is.
我不知道阿曼在这里的赌注是什么。
Oh, sorry, Nobel Prize or Field’s Medal first?
哦，抱歉，先是诺贝尔奖还是菲尔德奖？
Field’s Medal-
菲尔德奖章——
Oh, Field’s Medal level?
哦，菲尔德勋章级别？
Field’s Medal comes first, I think.
我认为菲尔德奖是第一位的。
[inaudible 02:06:41].
[听不清 02:06:41]。
Field’s Medal comes first.
菲尔德奖章是第一位的。
2:06:41 Well, you would say that, of course.
嗯，你当然会这么说。
But it’s also this isolated system you verify and…
但这也是您验证的这个孤立的系统......
Sure.
当然。
I don’t even know if I-
我什至不知道我是否——
You don’t need to do [inaudible 02:06:50].
您不需要这样做 [听不清 02:06:50]。
I feel like I have much more to do there.
我觉得我在那里还有很多事情要做。
2:06:50 It felt like the path to get to IMO was a little bit more clear.
感觉通往 IMO 的道路更加清晰了。
Because it already could get a few IMO problems and there was a bunch of low-hanging fruit, given the literature at the time, of what tactics people could take.
因为它已经可能遇到一些 IMO 问题，而且根据当时的文献，人们可以采取哪些策略，有很多容易实现的成果。
I think I’m, one, much less versed in the space of theorem proving now.
我想我现在对定理证明领域不太熟悉。
And two, less intuition about how close we are to solving these really, really hard open problems.
第二，对于我们距离解决这些真正非常困难的问题还有多远缺乏直觉。
So you think you’ll be Field’s Medal first?
所以你认为你会第一个获得菲尔德奖？
2:07:15 It won’t be in physics or in-
它不会在物理学或-
Oh, 100%.
哦，100%。
2:07:20 I think that’s probably more likely.
我认为这可能更有可能。
It is probably much more likely that it’ll get in.
它进入的可能性可能要大得多。
Yeah, yeah, yeah.
是啊，是啊，是啊。
Well I think it both to…
好吧，我认为两者都……
I don’t know, BSD, which is a Birch and Swinnerton-Dyer conjecture, or [inaudible 02:07:33] iPods, or any one of these hard math problems are just actually really hard.
我不知道，BSD，这是 Birch 和 Swinnerton-Dyer 的猜想，或者 [听不清 02:07:33] iPod，或者这些困难的数学问题中的任何一个实际上都非常难。
It’s sort of unclear what the path to get even a solution looks like.
甚至连找到解决方案的途径是什么也不清楚。
We don’t even know what a path looks like, let alone [inaudible 02:07:47].
我们甚至不知道路径是什么样子，更不用说 [听不清 02:07:47]。
And you don’t buy the idea this is just like an isolated system and you can actually have a good reward system, and it feels like it’s easier to train for that.
你不相信这就像一个孤立的系统，你实际上可以拥有一个良好的奖励系统，而且感觉训练起来更容易。
I think we might get Field’s Medal before AGI.
我认为我们可能会在 AGI 之前获得菲尔德奖。
I mean, I’d be very happy.
我的意思是，我会很高兴。
2:07:59 I’d be very happy.
我会很高兴。
But I don’t know if I…
但我不知道我是否……
I think 2028, 2030.
我认为是2028年、2030年。
For Field’s Medal?
为了菲尔德奖章？
Field’s Medal.
菲尔德奖章。
All right.
好的。
2:08:11 It feels like forever from now, given how fast things have been going.
考虑到事情进展得有多快，感觉就像从现在开始就永远了。
2:08:17 Speaking of how fast things have been going, let’s talk about scaling laws.
说到事情进展得有多快，我们来谈谈缩放定律。
So for people who don’t know, maybe it’s good to talk about this whole idea of scaling laws.
因此，对于那些不知道的人来说，也许最好谈谈缩放定律的整个概念。
What are they, where’d you think stand, and where do you think things are going?
它们是什么？您认为情况如何？您认为事情将走向何方？
I think it was interesting.
我认为这很有趣。
2:08:34 The original scaling laws paper by open AI was slightly wrong.
开放人工智能最初的缩放定律论文略有错误。
Because I think of some issues they did with learning right schedules.
因为我想到了他们在学习正确的时间表方面遇到的一些问题。
And then Chinchilla showed a more correct version.
然后 Chinchilla 展示了一个更正确的版本。
And then from then people have again deviated from doing the compute optimal thing.
从那时起，人们再次偏离了计算最优的做法。
Because people start now optimizing more so for making the thing work really well given an inference budget.
因为人们现在开始进行更多优化，以便在给定推理预算的情况下使事情真正正常运行。
2:08:59 And I think there are a lot more dimensions to these curves than what we originally used, of just compute number of parameters and data.
我认为这些曲线的维度比我们最初使用的要多得多，仅计算参数和数据的数量。
Like inference compute is the obvious one.
推理计算是显而易见的。
I think context length is another obvious one.
我认为上下文长度是另一个明显的问题。
So let’s say you care about the two things of inference compute and then context window, maybe the thing you want to train, is some kind of SSM.
假设您关心推理计算和上下文窗口这两件事，也许您想要训练的东西是某种 SSM。
Because they’re much, much cheaper and faster at super, super long context.
因为它们在超超长的上下文中更便宜、更快。
And even if, maybe it was 10 X more scaling properties during training, meaning you spend 10 X more compute to train the thing to get the same level of capabilities, it’s worth it.
即使在训练过程中缩放属性可能增加了 10 倍，这意味着您需要花费 10 倍的计算来训练该物体以获得相同水平的功能，但这也是值得的。
Because you care most about that inference budget for really long context windows.
因为您最关心的是非常长的上下文窗口的推理预算。
So it’ll be interesting to see how people play with all these dimensions.
因此，看看人们如何处理所有这些维度将会很有趣。
So yeah, I mean you speak to the multiple dimensions, obviously.
是的，我的意思是，显然你谈到的是多个维度。
2:09:47 The original conception was just looking at the variables of the size of the model as measured by parameters, and the size of the data as measured by the number of tokens, and looking at the ratio of the two.
最初的构想只是查看以参数衡量的模型大小和以令牌数量衡量的数据大小变量，并查看两者的比率。
Yeah.
是的。
And it’s kind of a compelling notion that there is a number, or at least a minimum.
这是一个令人信服的概念，即存在一个数字，或者至少是一个最小值。
2:10:00 And it seems like one was emerging.
似乎有一个正在出现。
Do you still believe that there is a kind of bigger is better?
您还相信有一种越大越好吗？
I mean I think bigger is certainly better for just raw performance.
我的意思是，我认为对于原始性能而言，越大越好。
And raw intelligence.
和原始智力。
And raw intelligence.
和原始智力。
2:10:22 I think the path that people might take, is…
我认为人们可能采取的道路是……
I’m particularly bullish on distillation.
我特别看好蒸馏。
And how many knobs can you turn to, if we spend a ton, ton of money on training, get the most capable cheap model.
如果我们花大量的钱进行培训，你可以转向多少个旋钮，以获得最有能力的廉价模型。
Really, really caring as much as you can.
真的，真的尽可能地关心。
Because the naive version of caring as much as you can about inference time compute, is what people have already done with the Llama models.
因为人们已经用 Llama 模型完成了尽可能多地关心推理时间计算的简单版本。
Or just over-training the shit out of 7B models on way, way, way more tokens than is essential optimal.
或者只是对 7B 模型进行过度训练，使用的标记远远多于基本的最佳值。
2:10:54 But if you really care about it, maybe the thing to do is what Gamma did, which is let’s not just train on tokens, let’s literally train on minimizing the KL divergence with the distribution of gemma 27B, right?
但如果你真的关心它，也许要做的事情就是 Gamma 所做的，这就是让我们不仅仅是在代币上进行训练，让我们从字面上训练如何最小化 KL 散度与 gemma 27B 的分布，对吧？
So knowledge distillation there.
所以知识蒸馏就在那里。
And you’re spending the compute of literally training this 27 billion parameter model on all these tokens, just to get out this, I don’t know, smaller model.
你花费了在所有这些标记上训练这个 270 亿个参数模型的计算量，只是为了得到这个，我不知道，更小的模型。
And the distillation gives you just a faster model, smaller means faster.
蒸馏给你一个更快的模型，更小的意味着更快。
Yeah.
是的。
2:11:23 Distillation in theory is, I think, getting out more signal from the data that you’re training on.
我认为，理论上的蒸馏是从您正在训练的数据中获取更多信号。
And it’s perhaps another way of getting over, not completely over, but partially helping with the data wall.
这也许是另一种克服数据墙的方法，不是完全克服，而是部分帮助。
Where you only have so much data to train on, let’s train this really, really big model on all these tokens and we’ll distill it into this smaller one.
如果您只有这么多数据可供训练，那么让我们在所有这些标记上训练这个非常非常大的模型，然后我们将其提炼成这个较小的模型。
And maybe we can get more signal per token for this much smaller model than we would’ve originally if we trained it.
也许对于这个小得多的模型，我们可以从每个标记中获得比我们最初训练它更多的信号。
So if I gave you $10 trillion, how would you spend it?
那么如果我给你10万亿美元，你会怎么花呢？
2:11:51 I mean you can’t buy an island or whatever.
我的意思是你不能购买岛屿或其他东西。
How would you allocate it in terms of improving the big model versus maybe paying for HF in the RLHF?
你会如何分配它来改进大模型，而不是在 RLHF 中支付 HF 费用？
Or-
或者-
Yeah, yeah.
是啊，是啊。
2:12:09 I think there’s a lot of these secrets and details about training these large models that I just don’t know, and are only privy to the large labs.
我认为有很多关于训练这些大型模型的秘密和细节我只是不知道，而且只有大型实验室才知道。
And the issue is, I would waste a lot of that money if I even attempted this, because I wouldn’t know those things.
问题是，如果我尝试这样做，我会浪费很多钱，因为我不知道这些事情。
Suspending a lot of disbelief and assuming you had the know- how, or if you’re saying you have to operate with the limited information you have now-
搁置大量怀疑并假设您拥有专业知识，或者如果您说您必须使用现在拥有的有限信息进行操作-
No, no, no.
不，不，不。
2:12:37 Actually, I would say you swoop in and you get all the information, all the little heuristics, all the little parameters, all the parameters that define how the thing is trained.
实际上，我会说你猛扑进去，你会得到所有的信息，所有的小启发，所有的小参数，所有定义事物如何训练的参数。
Mm-hmm.
嗯嗯。
If we look in how to invest money for the next five years in terms of maximizing what you called raw intelligence-
如果我们研究如何在未来五年内投资资金，以最大限度地发挥你所说的原始智力——
I mean, isn’t the answer really simple?
我的意思是，答案不是很简单吗？
2:12:57 You just try to get as much compute as possible.
您只需尝试获得尽可能多的计算即可。
At the end of the day all you need to buy, is the GPUs.
归根结底，您需要购买的只是 GPU。
And then the researchers can find all…
然后研究人员可以找到所有......
You can tune whether you want to pre-train a big model or a small model.
您可以调整是要预训练大模型还是小模型。
Well this gets into the question of are you really limited by compute and money, or are you limited by these other things?
那么这就涉及到一个问题：你真的受到计算和金钱的限制，还是受到其他因素的限制？
I’m more privy to Arvid’s belief that we’re sort of idea-limited, but there’s always that like-
我更了解阿维德的信念，即我们的想法有限，但总有这样的——
But if you have a lot of compute, you can run a lot of experiments.
但如果您有大量计算能力，则可以进行大量实验。
So you would run a lot of experiments versus use that compute to trend a gigantic model?
因此，您会进行大量实验，而不是使用该计算来预测巨大模型的趋势？
I would, but I do believe that we are limited in terms of ideas that we have.
我愿意，但我确实相信我们的想法是有限的。
I think yeah, because even with all this compute and all the data you could collect in the world, I think you really are ultimately limited by not even ideas, but just really good engineering.
我想是的，因为即使有了所有这些计算和你可以在世界上收集的所有数据，我认为你最终实际上甚至不是受到想法的限制，而是受到真正优秀的工程的限制。
2:13:44 Even with all the capital in the world, would you really be able to assemble…
就算拥有全世界的资本，你真的能够聚集起来吗……
There aren’t that many people in the world who really can make the difference here.
世界上真正能够改变现状的人并不多。
And there’s so much work that goes into research that is just pure, really, really hard engineering work.
研究中有很多工作都是纯粹的、非常非常艰苦的工程工作。
As a very hand-wavy example, if you look at the original Transformer paper, how much work was joining together a lot of these really interesting concepts embedded in the literature, versus then going in and writing all the codes, maybe the CUDA kernels, maybe whatever else.
举一个非常令人费解的例子，如果你看一下最初的 Transformer 论文，你会发现，将文献中嵌入的许多非常有趣的概念结合在一起需要花费多少工作，而不是编写所有代码，也许是 CUDA 内核，也许是其他任何代码。
I don’t know if it ran them GPUs or TPUs.
我不知道它运行的是 GPU 还是 TPU。
Originally such that it actually saturated the GPU performance.
原本这样，它实际上已经使 GPU 性能饱和了。
Getting GNOME Azure to go in and do all this code.
让 GNOME Azure 进入并执行所有这些代码。
And GNOME is probably one of the best engineers in the world.
GNOME 可能是世界上最好的工程师之一。
2:14:43 Or maybe going a step further, like the next generation of models, having these things…
或者也许更进一步，就像下一代模型，拥有这些东西......
Like getting model parallelism to work, and scaling it on thousands of, or maybe tens of thousands of V100s, which I think GBDE-III may have been.
比如让模型并行性发挥作用，并将其扩展到数千甚至数万个 V100，我认为 GBDE-III 可能就是这样。
There’s just so much engineering effort that has to go into all of these things to make it work.
所有这些事情都需要付出大量的工程努力才能使其发挥作用。
If you really brought that cost down to maybe not zero, but just made it 10 X easier, made it super easy for someone with really fantastic ideas, to immediately get to the version of the new architecture they dreamed up, that is getting 50, 40% utilization on their GPUs, I think that would just speed up research by a ton.
如果你真的把成本降低到可能不是零，但只是让它变得更容易 10 倍，让那些有真正奇妙想法的人变得超级容易，立即获得他们梦想的新架构版本，即 GPU 利用率达到 50%、40%，我认为这只会大大加快研究速度。
I mean I think if you see a clear path to improvement, you should always take the low-hanging fruit first, right?
我的意思是，我认为如果你看到了一条清晰的改进之路，你应该总是先采取容易实现的目标，对吗？
2:15:27 I think probably OpenAI and all the other labs that did the right thing to pick off the low-hanging fruit.
我认为 OpenAI 和所有其他实验室可能做了正确的事情来摘取唾手可得的果实。
Where the low-hanging fruit is like, you could scale up to a GPT-4.25 scale and you just keep scaling, and things keep getting better.
在那些容易实现的目标方面，您可以扩展到 GPT-4.25 规模，并且您只需不断扩展，事情就会不断变得更好。
And as long as…
并且只要...
There’s no point of experimenting with new ideas when everything is working.
当一切正常时，尝试新想法是没有意义的。
And you should sort of bang on and to try to get as much as much juice out of the possible.
你应该继续努力，并尝试从可能的情况中获得尽可能多的成果。
And then maybe when you really need new ideas for…
然后也许当你真的需要新想法时......
I think if you’re spending $10 trillion, you probably want to spend some…
我认为如果你要花费 10 万亿美元，你可能想花一些......
Then actually reevaluate probably your idea a little bit at that point.
然后实际上重新评估一下你的想法。
I think all of us believe new ideas are probably needed to get all the way there to AGI.
我想我们所有人都相信可能需要新的想法才能实现通用人工智能。
2:16:15 And all of us also probably believe there exist ways of testing out those ideas at smaller scales, and being fairly confident that they’ll play out.
我们所有人也可能相信存在一些方法可以在较小的范围内测试这些想法，并且对它们会发挥作用相当有信心。
It’s just quite difficult for the labs in their current position to dedicate their very limited research and engineering talent to exploring all these other ideas, when there’s this core thing that will probably improve performance for some decent amount of time.
对于目前所处位置的实验室来说，将其非常有限的研究和工程人才用于探索所有这些其他想法是相当困难的，因为这个核心东西可能会在相当长的时间内提高性能。
But also, these big labs like winning.
而且，这些大型实验室也喜欢获胜。
2:16:56 So they’re just going wild.
所以他们只是发疯了。
Okay, so big question, looking out into the future: You’re now at the center of the programming world.
好吧，这么大的问题，展望未来：你现在处于编程世界的中心。
How do you think programming, the nature of programming changes in the next few months, in the next year, in the next two years and the next five years, 10 years?
你如何看待编程，编程的本质在未来几个月、未来一年、未来两年、未来五年、十年会发生什么变化？
I think we’re really excited about a future where the programmer is in the driver’s seat for a long time.
我认为我们对程序员长期占据主导地位的未来感到非常兴奋。
2:17:20 And you’ve heard us talk about this a little bit, but one that emphasizes speed and agency for the programmer and control.
您已经听我们谈论过这一点，但强调程序员和控制的速度和代理。
The ability to modify anything you want to modify, the ability to iterate really fast on what you’re building.
能够修改您想要修改的任何内容，能够快速迭代您正在构建的内容。
And this is a little different, I think, than where some people are jumping to in the space, where I think one idea that’s captivated people, is can you talk to your computer?
我认为，这与一些人在这个领域跳到的地方有点不同，我认为一个吸引人们的想法是，你能和你的电脑说话吗？
Can you have it build software for you?
你可以让它为你构建软件吗？
As if you’re talking to an engineering department or an engineer over Slack.
就好像您正在通过 Slack 与工程部门或工程师交谈一样。
And can it just be this sort of isolated text box?
它可以只是这种孤立的文本框吗？
And part of the reason we’re not excited about that, is some of the stuff we’ve talked about with latency, but then a big piece, a reason we’re not excited about that, is because that comes with giving up a lot of control.
我们对此不感兴趣的部分原因是我们已经讨论过延迟的一些问题，但更重要的是，我们对此不感兴趣的原因是因为这会带来很多控制权的放弃。
2:18:19 It’s much harder to be really specific when you’re talking in the text box.
当你在文本框中说话时，要真正具体化要困难得多。
And if you’re necessarily just going to communicate with a thing like you would be communicating with an engineering department, you’re actually advocating tons of really important decisions to this bot.
如果您一定要与某个事物进行交流，就像与工程部门进行交流一样，那么您实际上是在向该机器人提倡大量非常重要的决策。
And this kind of gets at, fundamentally, what engineering is.
从根本上讲，这说明了工程是什么。
I think that some people who are a little bit more removed from engineering might think of it as the spec is completely written out and then the engineers just come and they just implement.
我认为一些远离工程的人可能会认为规范已经完全写出来，然后工程师就来了，他们就实施了。
And it’s just about making the thing happen in code and making the thing exist.
这只是让事情在代码中发生并让事情存在。
But I think a lot of the best engineering, the engineering we enjoy, involves tons of tiny micro decisions about what exactly you’re building, and about really hard trade-offs between speed and cost and just all the other things involved in a system.
但我认为很多最好的工程，我们喜欢的工程，都涉及到大量关于你正在构建的东西的微小决策，以及速度和成本之间真正艰难的权衡，以及系统中涉及的所有其他事情。
As long as humans are actually the ones designing the software and the ones specifying what they want to be built, and it’s not just like company run by all AIs, we think you’ll really want the human in a driver’s seat dictating these decisions.
只要人类实际上是设计软件并指定他们想要构建什么的人，并且这不仅仅是像所有人工智能运营的公司一样，我们认为您真的会希望人类坐在驾驶座上来决定这些决策。
2:19:26 And so the jury’s still out on what that looks like.
因此，目前尚无定论。
I think that one weird idea for what that could look like, is it could look like you can control the level of abstraction you view a code base at.
我认为一个奇怪的想法是，你可以控制查看代码库的抽象级别。
And you can point at specific parts of a code base that…
您可以指出代码库的特定部分......
Like, maybe you digest a code base by looking at it in the form of pseudocode.
就像，也许您可以通过以伪代码的形式查看代码库来消化它。
And you can actually edit that pseudocode too, and then have changes get made down at the sort of formal programming level.
实际上，您也可以编辑该伪代码，然后在正式编程级别进行更改。
And you can gesture at any piece of logic in your software component of programming.
您可以对软件编程组件中的任何逻辑部分进行手势操作。
You keep the inflow text editing component of programming, you keep the control of, you can even go down into the code, you can go at higher levels of abstraction, while also giving you these big productivity gains.
您保留了编程的流入文本编辑组件，您可以保持控制，甚至可以深入到代码中，您可以进入更高的抽象级别，同时还可以为您带来巨大的生产力提升。
It’d be nice if you can go up and down the abstraction stack.
如果您可以在抽象堆栈中上下移动，那就太好了。
Yeah.
是的。
2:20:18 And there are a lot of details to figure out there that’s sort of like a fuzzy idea.
还有很多细节需要弄清楚，这有点像一个模糊的想法。
Time will tell if it actually works.
时间会证明它是否真的有效。
But these principles of control and speed in the human in the driver’s seat, we think are really important.
但我们认为，驾驶座上的人类控制和速度的这些原则非常重要。
We think for some things like Arvid mentioned before, for some styles of programming, you can hand it off chatbot-style.
我们认为对于像 Arvid 之前提到的一些事情，对于某些编程风格，你可以将其交给聊天机器人风格。
If you have a bug that’s really well specified.
如果你有一个非常明确的错误。
But that’s not most of programming, and that’s also not most of the programming we think a lot of people value.
但这不是大部分编程，也不是我们认为很多人重视的大部分编程。
What about the fundamental skill of programming?
那么编程的基本功呢？
2:20:43 There’s a lot of people, like young people right now kind of scared, because they love programming, but they’re scared about, “Will I be able to have a future if I pursue this career path?” Do you think the very skill of programming will change fundamentally?
有很多人，比如现在的年轻人，有点害怕，因为他们喜欢编程，但他们害怕，“如果我追求这条职业道路，我能有未来吗？”您认为编程技能会发生根本性的改变吗？
I actually think this is a really, really exciting time to be building software.
事实上，我认为对于构建软件来说，这是一个非常非常令人兴奋的时刻。
2:21:04 We remember what programming was like in 2013, 2012, whatever it was.
我们还记得 2013 年、2012 年的编程情况，不管是什么。
And there was just so much more cruft and boilerplate and looking up something really gnarly.
而且还有太多的粗俗和样板，并且查找一些非常粗糙的东西。
And that stuff still exists.
而且那些东西仍然存在。
It’s definitely not at zero.
绝对不是零。
But programming today is way more fun than back then.
但今天的编程比以前有趣得多。
It’s like we’re really getting down to the delight concentration.
就好像我们真的在专注于快乐。
And all the things that really draw people to programming, for instance, this element of being able to build things really fast and speed and also individual control, all those are just being turned up a ton.
所有真正吸引人们进行编程的东西，例如，能够非常快速地构建东西以及单独控制的元素，所有这些都被大量使用。
2:21:49 And so I think it’s going to be a really, really fun time for people who build software.
所以我认为对于构建软件的人来说这将是一个非常非常有趣的时光。
I think that the skills will probably change too.
我认为技能也可能会改变。
I think that people’s taste and creative ideas will be magnified.
我认为人们的品味和创意会被放大。
And it will be maybe less, a little bit, about boilerplate text editing.
关于样板文本编辑的内容可能会少一些。
Maybe even a little bit less about carefulness, which I think is really important today if you’re a programmer.
甚至可能少一点谨慎，我认为如果你是一名程序员，这一点在今天非常重要。
I think it’ll be a lot more fun.
我想这会更有趣。
What do you guys think?
你们觉得怎么样？
I agree.
我同意。
2:22:15 I’m very excited to be able to change…
我很高兴能够改变……
One thing that happened recently, was we wanted to do a relatively big migration to our code base.
最近发生的一件事是我们想要对我们的代码库进行相对较大的迁移。
We were using AsyncLocalStorage in Node.js, which is known to be not very performant, and we wanted to migrate to a context object.
我们在 Node.js 中使用 AsyncLocalStorage，众所周知，它的性能不是很好，并且我们希望迁移到上下文对象。
And this is a big migration and affects the entire code base.
这是一次大迁移，会影响整个代码库。
[inaudible 02:22:38] and I spent, I don’t know, five days working through this, even with today’s AI tools.
[听不清 02:22:38] 我不知道，即使使用当今的人工智能工具，我也花了五天的时间来解决这个问题。
And I am really excited for a future where I can just show a couple of examples and then the AI applies that to all of the locations.
我对未来感到非常兴奋，我可以只展示几个例子，然后人工智能将其应用到所有位置。
And then it highlights, “Oh, this is a new example, what should I do?” And then I show exactly what to do there.
然后它突出显示，“哦，这是一个新示例，我应该做什么？”然后我会具体展示在那里做什么。
And then that can be done in 10 minutes.
然后这可以在 10 分钟内完成。
And then you can iterate much, much faster.
然后你就可以更快地进行迭代。
Then you don’t have to think as much upfront and stand at the blackboard and think, “Exactly how are we going to do this, because the cost is so high?” But you can just try something first and you realize, “Oh, this is not actually exactly what I want.” And then you can change it instantly again after.
然后你就不必预先思考太多，站在黑板前思考：“我们到底要怎么做，因为成本太高了？”但你可以先尝试一些东西，然后你就会意识到，“哦，这实际上并不完全是我想要的。”然后您可以立即再次更改它。
And so yeah, I think being a programmer in the future is going to be a lot of fun.
所以，是的，我认为未来成为一名程序员将会很有趣。
Yeah, I really like that point about…
是的，我真的很喜欢这一点……
2:23:26 It feels like a lot of the time with programming, there are two ways you can go about it.
感觉很多时候在编程时，有两种方法可以实现。
One is you think really hard, carefully upfront about the best possible way to do it and then you spend your limited time of engineering to actually implement it.
一是你认真认真地、仔细地预先考虑最好的可能方法，然后你花有限的工程时间来实际实施它。
But I must refer just getting in the code and taking a crack at seeing how it lays out and then iterating really quickly on that.
但我必须提到，只是进入代码并尝试看看它是如何布局的，然后快速迭代。
That feels more fun.
这样感觉更好玩。
Yeah, just speaking to generate the boilerplate, is great.
是的，只是说生成样板，非常棒。
2:23:55 So you just focus on the nuanced, difficult design decisions.
因此，您只需专注于细致入微、困难的设计决策。
Migration, I feel like this is a cool one.
迁移，我觉得这是一件很酷的事情。
It seems like a larger language models is able to basically translate for one program language to another.
看起来更大的语言模型基本上能够将一种程序语言翻译成另一种程序语言。
Or translate, migrate in the general sense of what migrate is.
或者翻译一下，一般意义上的迁移是什么。
But that’s in the current moment.
但这是在当前时刻。
So mean the fear has to do with, okay, as these models get better and better, then you’re doing less and less creative decisions.
所以意味着恐惧与，好吧，随着这些模型变得越来越好，那么你所做的创造性决策就会越来越少。
And is it going to kind of move to a place where you’re operating in the design space of natural language where natural language is the main programming language?
它是否会转移到你在自然语言设计空间中操作的地方，其中自然语言是主要编程语言？
And I guess I could ask that by way of advice.
我想我可以通过建议的方式问这个问题。
If somebody’s interested in programming now, what do you think they should learn?
如果有人现在对编程感兴趣，你认为他们应该学习什么？
You guys started in some Java and I forget the…
你们是从 Java 开始的，我忘了……
Oh, some PHP.
哦，一些 PHP。
PHP.
PHP。
PHP.
PHP。
Objective-C.
Objective-C。
Objective-C.
Objective-C。
2:24:54 There you go.
就这样吧。
I mean in the end, we all know JavaScript was going to win and not TypeScript.
我的意思是，最终，我们都知道 JavaScript 将获胜，而不是 TypeScript。
It’s going to be like vanilla JavaScript.
它会像普通的 JavaScript 一样。
It’s just going to eat the world and maybe live with PHP.
它将会吞噬整个世界，并且可能会与 PHP 共存。
And I mean it also brings up the question of, I think Don Knuth has this idea that some percent of the population is geeks, and there’s a particular kind of psychology in mind required for programming.
我的意思是，这也提出了一个问题，我认为 Don Knuth 有这样的想法，即人口中有一定比例是极客，并且编程需要一种特殊的心理学。
And it feels like more and more that expands the kind of person that should be able to, can do great programming, might expand.
感觉越来越多的人应该能够扩展，能够进行出色的编程，可能会扩展。
I think different people do programming for different reasons.
我认为不同的人出于不同的原因进行编程。
2:25:32 But I think the true, maybe the best programmers, are the ones that really love, just absolutely love programming.
但我认为真正的、也许是最好的程序员是那些真正热爱、绝对热爱编程的人。
For example, there are folks on our team who literally when they get back from work, they go and then they boot up cursor and then they start coding on their side projects for the entire night.
例如，我们团队中有一些人，当他们下班回来时，他们会启动光标，然后开始整个晚上的业余项目编码。
And they stay up until 3:00 a.m.
他们熬夜到凌晨 3:00。
doing that.
这样做。
And when they’re sad, they said, “I just really need to code.” And I think there’s that level of programmer where this obsession and love of programming, I think makes, really, the best programmers.
当他们悲伤时，他们会说：“我真的需要编码。”我认为，这种对编程的痴迷和热爱确实造就了最好的程序员。
And I think these types of people will really get into the details of how things work.
我认为这些类型的人会真正了解事物运作的细节。
I guess the question I’m asking, that exact programmer, let’s think about that person.
我想我问的问题就是那个程序员，让我们想想那个人。
2:26:29 When the super tab, the super awesome praise be the tab succeeds, and you keep pressing tab-
当超级tab的时候，超级赞的就是tab成功了，一直按tab——
That person in the team loves cursor tab more than anybody else, right?
团队中的那个人比其他任何人都更喜欢光标选项卡，对吗？
Yeah.
是的。
2:26:45 And it’s also not just…
而且它还不仅仅是……
Pressing tab is just pressing tab.
按 Tab 键只是按 Tab 键。
That’s the easy way to say it in the catchphrase.
这是用口号表达的最简单的方法。
But what you’re actually doing when you’re pressing tab, is that you’re injecting intent all the time while you’re doing it.
但当你按下 Tab 键时，你实际上在做的是，你在执行此操作时一直在注入意图。
Sometimes you’re rejecting it, sometimes you’re typing a few more characters.
有时你会拒绝它，有时你会多输入几个字符。
And that’s the way that you’re sort of shaping the things that’s being created.
这就是你塑造正在创造的事物的方式。
And I think programming will change a lot to just, “What is it that you want to make?”
我认为编程将会发生很大的变化，变成“你想做什么？”
It’s sort of higher bandwidth.
这是更高的带宽。
2:27:17 The communication to the computer just becomes higher and higher bandwidth as opposed to just typing as much lower bandwidth than communicating intent.
与计算机的通信的带宽变得越来越高，而不是仅仅键入比通信意图低得多的带宽。
I mean, this goes to your manifesto titled Engineering Genius.
我的意思是，这属于你的标题为“工程天才”的宣言。
2:27:27 “We are an applied research lab building extraordinary productive human AI systems.” So speaking to this hybrid element.
“我们是一个应用研究实验室，致力于打造非凡高效的人类人工智能系统。”所以谈到这个混合元素。
2:27:41 “To start, we’re building the engineer of the future, a human AI programmer that’s an order of magnitude more effective than any one engineer.
“首先，我们正在培养未来的工程师，一名人类人工智能程序员，其效率比任何一位工程师都要高一个数量级。
This hybrid engineer will have effortless control over their code base and no low entropy keystrokes.
这位混合工程师将轻松控制他们的代码库，并且无需低熵击键。
They will iterate at the speed of their judgment, even in the most complex systems.
即使在最复杂的系统中，他们也会以自己判断的速度进行迭代。
Using a combination of AI and human ingenuity they will outsmart and out engineer the best pure AI systems.
通过将人工智能与人类的聪明才智相结合，他们将比人类更聪明地设计出最好的纯人工智能系统。
We are a group of researchers and engineers.
我们是一群研究人员和工程师。
2:28:12 We build software and models to invent at the edge of what’s useful and what’s possible.
我们构建软件和模型，以在有用和可能的边缘进行发明。
Our work has already improved the lives of hundreds of thousands of programmers.”
我们的工作已经改善了数十万程序员的生活。”
2:28:21 And on the way to that, we’ll at least make programming more fun.
在此过程中，我们至少会让编程变得更加有趣。
So thank you for talking today.
谢谢你今天的发言。
Thank you.
谢谢。
Thanks for having us.
感谢您拥有我们。
Thank you.
谢谢。
Thank you.
谢谢。
Thanks for listening to this conversation with Michael, Sualeh, Arvid and Aman.
感谢您收听 Michael、Sualeh、Arvid 和 Aman 的对话。
2:28:29 To support this podcast.
为了支持这个播客。
Please check out our sponsors in the description.
请在说明中查看我们的赞助商。
And now let me leave you with a random, funny and perhaps profound programming code I saw on Reddit.
现在让我给你们留下一段我在 Reddit 上看到的随机的、有趣的、也许是深刻的编程代码。
Nothing is as permanent as a temporary solution that works.
没有什么比有效的临时解决方案更永久的了。
Thank you for listening and hope to see you next time.
感谢您的聆听，并希望下次再见。
本集资源与出处
- 视频在 YouTube 收看
- 音频官方 MP3 直链来自 lexfridman.com 官方播客 RSS
- 官网Lex Fridman 官网本集页面
- 文稿官方 Transcript（lexfridman.com）
