#447 – Cursor 团队：AI 编程的未来

访谈进行到快两个小时，Lex Fridman 念了一条网上的评论：GitHub Copilot 好像要接入 OpenAI 的 o1 了，那 Cursor 是不是该关门了？

Arvid 先接了一句玩笑："是时候关掉 Cursor 了。"Michael Truell 的回答很直接。他说这个领域跟 2010 年代的软件不一样，天花板高得多。三四年后最好的产品，会比今天最好的产品有用得多。

你可以大谈护城河、品牌、我们的优势，但说到底，只要你停止在产品上创新，你就会输。

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.

他接着说，这对创业公司是好事。它意味着后来者只要做出更好的东西，就有机会赢过已经拥有大量用户的对手。

这句话几乎是整期访谈的底色。Cursor 是基于 VS Code 分叉（fork）出来的代码编辑器，做的事情是把 AI 深度嵌进写代码的每个环节。录这期节目时，它正被程序员圈子热议。四位嘉宾都是联合创始人：Michael Truell 是 Cursor 母公司 Anysphere 的 CEO，Sualeh Asif、Arvid Lunnemark、Aman Sanger 分别负责不同的技术方向。四个人轮流发言，下面按话题而不是按人来组织。

模型每年都在变强，所以领先几个月就是决定性差距

故事要从 Vim 讲起。四个人原来都是纯 Vim 用户。2021 年 Copilot 出来，Aman 想试，而当时只有 VS Code 能用，他就换了过去。Copilot 的体验好到足以让他放弃 Vim。Sualeh 说，Copilot 被低估的一点是：它是第一个真正的大语言模型消费级产品。

Michael 讲了两个让他们下决心的时刻。第一个是 2020 年 OpenAI 发表 scaling lAnthropic 系列论文。这组研究的意思是：模型越大、数据越多，效果就越好，而且好得可以预测。Sualeh 补了一句："不只是更好，是可预测地更好。"这让他们觉得，就算没有新想法，只要堆算力和数据，模型也会持续变强。

第二个是 2022 年底拿到 GPT-4 的早期访问权限。在那之前，他们做过几个很具体的小工具，比如给在 Jupyter Notebook 里工作的金融从业者做的工具，也试过用模型做静态分析。GPT-4 的能力提升让 Michael 意识到，这不会只是某个细分场景的方案。所有编程都会流经这些模型，这需要一种不同的编程环境。

为什么要 fork VS Code，而不是写个插件？Michael 的理由是控制权。如果你只是现有编辑器的插件，你能改的东西非常有限。他们预期模型会彻底改变写软件的方式，不想被插件的边界锁住。

至于怎么跟背靠微软的 Copilot 竞争，Aman 给了一个推理链。以往的技术浪潮，通常是一个大事件解锁一批公司。AI 编程不一样：模型能力每跳一次，就解锁一批新功能。所以哪怕只领先几个月，产品都会有用得多。

我觉得一年后的 Cursor，必须让今天的 Cursor 看起来过时。

I think the Cursor a year from now will need to make the Cursor of today look obsolete.

他认为微软做了很多出色的事，但不在一个能像创业公司那样持续推进、做研究实验去抬高天花板的位置上。Sualeh 讲得更像用户的抱怨：当时你能看到模型在变强，Copilot 的体验却一直没变。"天花板越来越高，他们为什么不做新东西？"他说自己就是那种总想用新东西的人，而很长时间里没有新东西可用。所以他们首先是在给自己做产品。

Arvid 补了组织层面的原因：做交互的人和训练模型的人是同一拨。Sualeh 说两边坐得只隔十几英尺，Aman 补充"经常就是同一个人"。界面怎么设计、prompt 怎么拼、上下文怎么找、Tab 的模型怎么训，放在一起迭代，才做得出分开做不出来的东西。

回到开头那个问题，Aman 的判断是：Cursor 的价值大部分不在于"快速接入 o1 这种新模型"，而在于那些你察觉不到、却在产品每个角落工作的自研模型，以及每个功能上花的交互心思。

好的补全要替你按掉所有"零熵"按键

Michael 把 Cursor 当时擅长的事概括成两件。一是像个手快的同事，在你身后预判你下一步要做什么。二是让你跑到 AI 前面，直接下指令，从描述变成代码。

第一件事的野心比传统补全大。Copilot 预测的是光标后面的几个字符；Cursor Tab 想预测你下一处完整的修改，甚至你下一步要跳到哪里。Sualeh 举了个例子：你刚改完一处，模型应该知道下一个该改的地方在 18 行以下。Vim 用户可以敲 18j 跳过去，但凭什么要人来做？于是团队内部的竞赛变成了："我们能让用户连按多少次 Tab？"

他把这个想法抽象成"零熵"编辑。熵在这里可以理解成信息量。当你的意图已经表达完，剩下的按键不再携带任何新信息，只是为了让电脑明白你早已想好的事。这类按键应该被一键带过。打个比方：你说了"把这个函数里的 user 全改成 account"，剩下十几处替换就是零熵的。

Aman 给了一个数据层面的支撑。语言模型在不同领域的损失里，代码的 bits per byte（一种按字符归一化的损失）比自然语言低。也就是说，代码里大量字符本来就高度可预测。在"预测用户如何修改已有代码"这个任务里，这种可预测性还会放大。

Cursor Tab 的目标就是：消灭你在编辑器里所有低熵的操作。

The goal of Cursor Tab is let's eliminate all the low entropy actions you take inside of the editor.

这个方向推到底，就是"下一步动作预测"。Sualeh 希望它能跨文件跳转。Arvid 想得更远：它可以建议你在终端里该敲的命令；也可以在你没法判断建议对不对时，先把你带到某个类型的定义处，看完再带回来，让你有足够信息去接受下一个补全。Michael 的说法是：编程有个怪特点，接下来五分钟要做的事，有时可以从你刚做的事里预测出来。理想状态是你一路"好、好、好"地点过去。

要做到这些，速度是前提。Arvid 在访谈一开头就说，他们很多功能做出来试用后又扔掉了，原因是"不好玩"，而好玩很大一部分来自快。"快就是好玩。"

Aman 讲了 Tab 背后的几个关键做法：

• 用小模型。延迟必须极低，大模型扛不住。
• 用稀疏模型（MoE，混合专家模型）。这个任务的特点是输入极长、输出很短，模型要读你大量代码，但只吐出几行。MoE 每次只激活一部分参数，像一家医院里病人只看相关科室的医生，适合这种"读得多写得少"的场景。他说这是一个明显提升长上下文表现的突破。
• 缓存。如果你每敲一个键都要把几千个输入 token 重新算一遍，延迟会崩，GPU 也会被压垮。所以 prompt 要按"缓存友好"的方式设计，并在请求之间复用 KV 缓存。

KV 缓存是这期反复出现的概念。Transformer 处理每个新 token 时，都要回看前面所有 token 的"键"和"值"。如果把前面算过的这些存在 GPU 上，下一个 token 就只需要算自己那一步，不用把整段输入重新过一遍模型。好比做题时把中间结果写在草稿纸上，不用每次从头推。

在此基础上还有两个技巧。一是缓存预热：你还在打字时，系统就猜到你会用到当前文件，提前把它算进缓存，等你按下回车，首个 token 的等待时间就大大缩短。二是推测性预取：假设你会接受当前建议，提前发出下一个请求，等你按 Tab 时，下一个建议已经在那里了。模型本身没变，体感却快了。

Cursor 的智能大半来自自研小模型，不只是前沿大模型

Aman 说，Cursor 实际上是一组自训练的定制模型，加上擅长重推理任务的前沿模型。Tab 是一个例子：专门训练后，它在自己的任务上比前沿模型还强。另一个更出人意料的例子叫 Apply。

Apply 解决的是"把建议真正落到文件里"这一步。前沿模型擅长勾勒修改方案，但要它直接输出精确的 diff，会在很蠢的地方出错，比如数行号，文件越大越严重。Sualeh 强调，这一步和大家的直觉相反，它不是一个确定性算法能做好的事。Aman 说，别处有一些对 Apply 的浅层模仿，用确定性匹配去合并，他在访谈中说这种做法至少 40% 的时候会失败，产品体验很糟。

他们的做法是让大模型只写一个粗略的代码块，再训练一个专门模型把它应用到文件上。这样还有一个好处：最贵的模型少写很多 token，延迟和成本都降下来。Aman 预期这种分工会延续：更聪明的模型做规划，不那么聪明的模型处理实现细节，甚至层层递归，比如 o1 写高层计划，Sonnet 展开，再由 Apply 模型落地。

Apply 要快，靠的是他们做的"推测式编辑"（speculative edits）。它是推测解码的变体。普通的推测解码，是用一个小模型先猜一串草稿 token，大模型一次性验证，猜对的直接收下。因为大模型并行处理多个 token 比一个个生成快得多。Cursor 的洞察是：改代码时，最好的草稿就是原来的代码本身。把原代码一块块喂回去，模型大多会同意"照抄"，这些行就能并行通过；直到模型想写出和原文不同的内容，才真正生成；之后再和原文对齐，继续成块推测。用户看到的就是一次快得多的重写流式输出。Sualeh 补充，流式还意味着你可以边出边看，没有长时间的加载。

团队还在模型结构层面压缩 KV 缓存。Aman 和 Sualeh 讲了从多头注意力到分组查询注意力（GQA）、多查询注意力（MQA），再到 DeepSeek 提出的多头潜在注意力（MLA）的演进。共同思路是让每个 token 要存的键值更小，因为生成阶段的瓶颈是从显存读这些缓存的带宽。缓存变小，带来的好处是：能缓存更多东西、命中率更高；批量变大时生成速度不怎么掉；prompt 也可以更长。

还有一条线是强化学习。Sualeh 讲到 pass@k 现象：模型单次采样可能不好，但采 10 个，其中有一个对的概率就高很多。他们训练 Tab 时，会让模型产出上百个候选，奖励人更喜欢的、惩罚人不喜欢的，让模型学会给出人会接受的建议。Aman 补充说，这也是速度问题：用 RL 训过的小模型能达到大模型的效果，就能用小模型。他还提到，因为模型本身的判断大多已经正确，Tab 在两个候选之间挑选时，只需要大约 50 到 100 个人工示例做轻微校准，这跟常规 RLHF 动辄大量标注很不一样。

被问到"哪个模型写代码最好"时，Aman 的回答是没有哪个模型在所有维度上全面占优。维度包括速度、改代码的能力、处理大量代码的能力、长上下文和编程能力本身。综合下来，他认为当时最好的是 Claude 的 Sonnet，并说这是共识。o1 推理很强，做面试题、LeetCode 题表现好，但不如 Sonnet 懂你粗略的意图。他对其他一些前沿模型的保留是：它们在基准测试分布内表现很好，稍微推出分布就掉；Sonnet 是最能保持住能力的那个。

基准测试为什么不靠谱，Sualeh 和 Michael 各给了一层理由。Sualeh 说，面试题是定义清楚的；真实编程里，人说的是半通不通的英语，"照我刚才那样做"，"加个这个再弄个那个 UI"，高度依赖上下文。Michael 的第二层是公开基准的污染问题。以最流行的 agent 基准 SWE-bench 为例，它的数据已经大量混进基础模型的训练集。不给模型代码库，它也能"幻想"出正确的文件路径和函数名。Aman 补充，就算实验室剔除了具体的 issue 和 PR，也不会为了让分数真实而把 SymPy 这类热门 Python 仓库本身从训练数据里拿掉。

所以，Michael 说，做模型和用模型的公司都在依赖一些"拐杖"：让人上手试，给定性反馈。Cursor 内部也大量依赖定性评估，外加私有评测集。Arvid 管这叫"看感觉"。

至于网上常说的"Claude 变笨了"，Aman 转述了一个他听来的猜测：Anthropic 的芯片和英伟达 GPU 数值特性略有不同，降级可能和 Anthropic Bedrock 上跑的量化版本有关。Sualeh 则说，这不是阴谋论，而是人和芯片都会出 bug，算力规模这么大，bug 很难避免。

模型越强，瓶颈越落在人能不能看得过来

Cursor 的 diff 界面经过多次推翻。Sualeh 回忆，最早是 Google Docs 式的删除线加新代码，非常分散注意力。后来试过红色高亮，又试过一个"按住 Mac 的 Option 键才显示建议"的版本：AI 有建议时只把相关区域标蓝，你按住才看到新代码，松开又回到原样。Lex 说，前提是你得知道要按 Option。Sualeh 的结论是："它就是不直观。"最后才变成侧边的方框。他们计划为不同场景做四五种 diff：补全时视线集中在一处，要极快读完；审大块代码和跨多文件修改，又各是一种。

Arvid 把背后的问题称作"验证问题"。diff 对小改动很好用，改动一大、跨多个文件，审阅就变得让人望而却步。他的想法是：diff 里有的部分信息量大，有的部分是重复的低熵内容。可以高亮重要部分、灰掉不重要的；或者让一个模型扫一遍，在可能有 bug 的地方画红色波浪线。现有的 diff 算法是普通算法，没有智能，而这里需要智能。

Sualeh 把它推成一个趋势：模型越聪明，能提的改动越大；改动越大，人要做的验证越多。"我不想把时间都花在审代码上。"

Aman 在这里说了一句很重的话：

代码审查有点烂。你花大量时间去理解一段往往很陌生的代码，而它其实抓不到多少 bug。

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.

他的推理是这样的：传统代码审查的设计，要同时照顾审阅者和写代码的人。如果写代码的是语言模型，你就不用太在意它的感受，整个流程可以只围绕审阅者来设计，让审阅尽可能轻松、高效、好玩。简单地把 AI 的改动做得"像代码审查"，反而是错的方向。Arvid 补了一个具体点子：审 PR 时文件通常按列表从上到下排，但你真正需要的是按逻辑顺序读，先读逻辑上最先发生的部分。这个顺序应该由模型来排。

那以后是不是都用自然语言写代码？Arvid 认为不会。他拿结对编程打比方：有时他对 Sualeh 说"实现这个函数"就够了；有时解释太费劲，他干脆抢过键盘写一部分示例，对方一看就懂。跟 AI 沟通也一样，有时给个例子最省事，做网页时拖拽和画图可能比描述更直接。他的结论是自然语言会有一席之地，但"绝不会是大多数人在大多数时候编程的方式"。

找 bug 是模型最弱、也最绕不开的能力

Lex 说如果是他，最想要的 agent 是找 bug 的。Aman 的回应是：

很有意思，这些模型在被直接要求找 bug 时表现非常差，校准得一塌糊涂。

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.

Arvid 和 Aman 补了一句：最聪明的模型也一样，o1 也是。

Aman 的解释从预训练分布出发。模型擅长的是代码生成和问答，因为 GitHub 上有数万亿 token 的代码，Stack Overflow 上有海量问答。而"根据已有修改预测下一处修改"、"发现真实 bug 并提出修复"这类数据在网上很少，模型的脆弱就暴露出来了。但他乐观的一面是：代码通用能力能迁移到 Tab 任务上，同样也能迁移到找 bug 上，只需要往那个方向推一把。

Sualeh 的角度不同。他认为模型其实很懂代码，在内部表示里大概"知道"某处有点可疑。难的是校准：可疑之处是无关紧要，还是会把服务器搞挂。这种判断很大程度是文化知识。资深工程师之所以值钱，是因为他知道三年前有人写了段可疑的代码搞挂了线上。同时还要判断用户有多"偏执"：写实验代码时模型挑刺很烦人，写数据库或 Linux 内核时，一个边界情况都不能放过。Aman 随即限定：就算把偏执程度调到最高，模型还是抓不太住。

这里牵出一个有争议的工程实践。Cursor 的内部原则之一，是在可能造成重大破坏的代码里，每一行都标上"危险"之类的注释。Arvid 说，这部分也是写给今天的 AI 模型看的，重复标注会让模型更关注那片区域，更容易在里面找到 bug。他承认这很有争议，有人觉得难看，"Sualeh 就不喜欢"。Sualeh 的回应很诚实：审美上他不喜欢，但这确实对模型有用，而人很健忘，一个小失误就能把服务器拖垮。Aman 补充，普通的 docstring 人会扫一眼就过，觉得"我知道怎么改"，所以需要更显眼的提醒。

怎么训练找 bug 的模型，Arvid 说内部吃饭时争论过很多次。一个流行的想法是利用不对称性：引入一个看似合理的 bug，比发现它容易。所以可以先训练一个"埋 bug"模型，用它造的数据去训练"找 bug"模型。Michael 补了模型之外的路：给最大的模型更多代码之外的信息，比如运行轨迹、调试器的单步执行。人盯着文件找 bug 也很难，通常要跑起来看。他还设想了两种产品形态：一种是后台常驻、速度很快的专用模型，随时扫描；另一种是你明确知道有 bug 时，砸大量算力去解，愿意为一个 bug 付 50 美元甚至更多。

他把这件事和整个方向联系起来：

如果 AI 为你构建越来越多的系统，你需要的不只是生成，还有验证。

If AI is building more and more of the system for you, you need to not just generate but also verify.

没有验证能力，前面谈到的那些问题会变得无法承受。

在验证的尽头，Arvid 提出了最激进的设想：等到形式化验证普及，人可能不再写测试。你写一个函数，模型提议一份规格说明（spec），你审规格，同时一个推理模型去证明实现符合规格。形式化验证可以理解为用数学证明代替抽样测试：测试是试几组输入看结果对不对，证明是确保所有输入都对。他认为大多数函数都会这样。

这引发了一轮真正的交锋。Michael 先质疑：前面说过意图本身很难说清楚，如果意图难以表达，证明它和意图一致也一样难。Arvid 问：你是说规格很难生成？Michael 说，就算有了规格，你关心的很多东西也很难用规格语言写清楚，这可能是反对"形式化验证就够了"的一个理由，替代单元测试倒是可以。Arvid 让了一步：规格语言可以演化，去覆盖现在覆盖不了的东西。Lex 问整个代码库行不行，Arvid 承认更难，但他举了从 C 代码一路证明到 GCC 编译器、再到 Verilog 和硬件的工作，认为大型代码库也是多层系统，能分解就能逐层证明。他承认"规格问题是个真问题"。

Aman 继续追问副作用和外部依赖，比如调用 Stripe 的 API。Sualeh 说，也许 Stripe 会为自己的 API 写规格。Aman 再追：不可能每样依赖都有规格；而且以后程序里可能把语言模型当原语来用，这又怎么证明？Arvid 的回答是，也许可以证明一个语言模型是对齐的，或者证明它给出了正确答案。Sualeh 接了一句："那是梦想。"这场讨论没有收敛，停在了 Arvid 的乐观和 Michael、Aman 的保留之间。

最后还有个小插曲。Lex 说 Cursor 帮他写对了三个调用 YouTube API 的函数，他想打赏 5 美元。Arvid 说，在产品里引入钱在公司内部是有争议的。他喜欢的版本是：找不到 bug 不收钱，找到了、你点接受时显示 1 美元。顾虑有两个：用户可能直接复制粘贴不点接受；而且钱一出现，产品就没那么好玩了，也许按月收费、功能全包更合适。Aman 观察到，用户真正想表达认可时，做的是把好例子分享给朋友。Michael 指出另一条路：如果能通过运行代码、语言服务器检查等手段真正验证"bug 已修复"，赏金就不必依赖用户的诚信。

大部分编程需要即时迭代，不适合整体交给 agent

Arvid 说他们觉得 agent 很酷，能让人感觉离 AGI 更近，但目前在很多事上还不够有用。他想要 agent 的场景很具体：Cursor 的聊天输入框有时不能复制粘贴，这种定义清楚的 bug，他只想用两句话交代，"这个不工作，修一下"，然后 agent 自己找文件、复现、修复、验证，一天后他回来审结果。

但他不认同 agent 会接管全部编程。理由是编程的大部分价值在迭代：你事先并不知道自己要什么，要先看到一个初版，再补充信息。对大部分编程，你要的是一个立刻给你初版、让你飞快迭代的系统。Lex 问到 Replit Agent 那种连开发环境、数据库、部署都包办的工具，Arvid 说某些类型的编程很需要，Cursor 当时没在做，但想做。他还设想过后台 agent：一个 PR 同时涉及前后端，你在写前端时，后台 agent 先把后端部分做出初版，等你切过去就有东西可改。

后台计算的思路，Arvid 在一篇博客里写成了"影子工作区"（Shadow Workspace）。他的论点是：在后台做事要有收益，就得给模型反馈信号，否则不如让模型想得更久。程序员最重要的反馈之一是语言服务器。它是每种语言各自的工具，通过一个统一协议（LSP）告诉编辑器"这里类型错了"、"这个定义在哪"。Cursor 的做法是开一个隐藏的 Cursor 窗口，AI 在里面随便改代码、只要不存盘，就能拿到 lint 报错和跳转定义的结果。要真正运行代码就更难：要和用户环境一模一样，在 Linux 上可以镜像文件系统让 AI 以为自己在改文件，实际改在内存里；Mac 和 Windows 上更麻烦。Aman 提了一个他承认"有点 hacky"的点子：让模型持有存盘锁，在内存里的未保存版本上工作，用户要运行代码时再把锁拿回来。他还补了一个限定：几分钟内的小任务适合在本地跑；耗时长、改动大的任务应该放到远程沙箱，而怎么让远程环境和用户环境等效，又是个很难的问题。

意图不足的问题也在这一章出现。Aman 说，系统再完美，用户的请求也常常没给够意图。解法有两种：让模型反问"这几处我不确定，能说清楚吗"；或者干脆把五六种可能的结果都给你挑。Sualeh 讲了刚上线的一个实验功能：你还在写 prompt 时，系统根据你过去的提交猜测你可能需要哪些文件，比如改 API 时，调用它的客户端和服务端也该一起改，并建议你加进来。

上下文能不能自动搞定？Michael 的回答是有取舍：上下文越多，请求越慢越贵，后台能做的花活越少；很多模型信息一多还会糊涂。所以自动加入的上下文，准确率和相关性门槛要很高。更长远的方向，他提到两条：一是无限上下文窗口，以及能真正关注它、还能缓存它；二是把知识学进权重里，类似微调，可能会带来质的不同。Aman 举了 VS Code 当证据：VS Code 是开源的，模型预训练时见过它的全部代码，问它 VS Code 的问题，它有时能答得不错。那么能不能专门对某个代码库做继续预训练，再用模型对代码片段自动生成问答、做指令微调？他说这是开放的研究问题，他们很感兴趣。

研究受限于顶尖工程能力，不只受限于算力

关于 o1 这类测试时计算（test-time compute）模型，Aman 的分析是：预训练这条路开始撞上数据墙，而测试时计算提供了另一条路，同样大小的模型跑得更久，就能得到更大模型的效果。他觉得最有意思的是经济账：可能只有 1% 甚至 0.1% 的请求需要一个百万亿参数级别的模型，为这点请求训练一个那么贵的模型很浪费；更合理的是训练一个能处理 99.9% 请求的模型，再在少数需要最高智能的时候让它多想一会儿。

但哪个问题该用哪种模型，这个"模型路由"问题他认为没人真正解决。Cursor 在 Tab 上有初步实现，但在 4o、Sonnet 和 o1 之间切换要难得多。他还提了一个绕的问题：判断"这题对 4o 来说是不是太难"本身需要多少智能？

o1 到底怎么做的，Aman 说大实验室之外，可能 OpenAI 之外，没人真正知道。他推测可能和过程奖励模型加树搜索有关。结果奖励模型只给最终答案打分；过程奖励模型给推理链的每一步打分，这样就能在推理链上分叉探索，挑好的分支走。他说自己没见过把过程奖励模型创造性地用于代码树搜索、并且效果很好的公开工作，同时也承认可能漏看了某些论文。

为什么 OpenAI 隐藏思维链？Michael 明确说是纯推测：可能是为了让别人更难把能力蒸馏出去，因为推理步骤本身就是很重要的训练数据。他类比了一些 API 以前开放 token 的对数概率、后来又收回的情况，也许是同样原因。他也坦白，Cursor 接入 o1 只是因为大家想试，它不在默认体验里，团队还没找到每小时甚至每天都会用到它的方式。Aman 补充了一个很实际的限制：o1 不支持流式输出，你只能干等一大段文字出现，这对需要边看边监督的场景很痛苦。

Aman 把合成数据分成三类：

1. 蒸馏：用强模型的输出训练弱模型。得不到比原模型更强的模型，但能把昂贵大模型的某项能力压进便宜的小模型。
2. 利用反向更容易：比如埋 bug 比找 bug 容易，用一个不太聪明的模型造 bug，训练一个很会找 bug 的模型。
3. 生成后可以轻松验证：数学里形式化证明容易验证，就让一般的模型大量生成，只保留证对了的继续训练；代码里有测试的题也能这样做。他认为这是大实验室做合成数据的主要方式，但对开放式任务和长周期任务，找到完美的验证器非常难。

他认为验证最好是确定性的，用测试或形式系统，而不是让语言模型来判。Michael 补了一个中间形态：让模型像人做质检那样把东西跑起来，并理解输出。Aman 同意这类最可能带来大的提升。

关于 scaling law，Aman 说 OpenAI 最初的论文因为学习率调度的问题有点偏差，后来 DeepMind 的 Chinchilla 给出了更准确的版本，再后来大家又偏离"计算最优"，转向在推理预算下优化。他认为曲线的维度比最初的参数量和数据量多得多，推理计算、上下文长度都是。比如你在乎超长上下文下的推理成本，就可能值得训一个 SSM（状态空间模型）类架构，哪怕训练时要多花 10 倍算力。他特别看好蒸馏，举了 Gemma 的做法：不只在 token 上训练小模型，而是让它去逼近 27B 模型的输出分布。这样每个 token 能榨出更多信号，部分缓解数据墙。

Lex 抛出一个假设：给你 10 万亿美元，怎么花？这一段几个人意见并不一致。Sualeh 先说答案很简单，买尽可能多的 GPU。Aman 问：真的是受限于算力和钱吗？Sualeh 转而说自己更倾向 Arvid 的看法，认为是受限于想法。Arvid 说他确实认为受限于想法，但有了大量算力就能跑大量实验。Aman 给了第三种答案：

就算有全世界的算力和数据，我觉得最终的限制甚至不是想法，而是真正优秀的工程。

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.

他的论据是 Transformer 论文：把文献里的想法拼起来是一回事，写出能把 GPU 跑满的代码、CUDA 内核是另一回事，这需要 Noam Shazeer 这种世界顶级工程师。再往后，把模型并行扩展到上万张 V100 上也是大量工程。如果能把这类工程成本降到十分之一，让有好想法的人能立刻得到一个 GPU 利用率四五成的新架构实现，研究会快很多。

Sualeh 的补充是：有清晰改进路径时，先摘低垂的果子是对的，各大实验室一直在放大规模、效果一直在变好，那时实验新想法没有意义。但如果要花 10 万亿美元，大概就该重新审视想法了。Aman 最后给了一个四人似乎都认同的判断：通往 AGI 很可能需要新想法；这些想法可以在小规模上测试并相当有把握地推断；只是大实验室把有限的研究和工程人才都押在了当前主线上，很难分出精力探索。

程序员应该一直坐在驾驶座上

访谈最后，Lex 问编程在未来几个月到十年会怎么变。Michael 的回答是整期最清晰的立场表达。他说他们期待的未来，是程序员长期坐在驾驶座上：强调速度、能动性和控制，想改哪里就改哪里，飞快迭代。

这和当时很多人追的方向不同：像在 Slack 上跟一个工程部门对话那样，对着一个文本框让电脑替你造软件。他说不喜欢这个方向，一部分是延迟问题，更大的原因是控制权。在文本框里很难精确表达，而把自己当成跟工程部门沟通，就意味着把大量重要决策让渡给了机器人。

很多最好的工程，我们享受的那种工程，包含大量关于你到底在造什么的微小决策，以及速度、成本和系统里其他一切之间的艰难取舍。

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.

他认为，离工程较远的人会以为工程就是规格写好、工程师照着实现。只要软件还是人在设计、人在定义要什么，而不是一家全由 AI 运营的公司，人就该在驾驶座上做这些决定。

具体形态他也没定论，只给了一个他自己称为"模糊"的设想：让你能控制看代码库的抽象层级。比如以伪代码的形式阅读整个代码库，直接改伪代码，改动自动落到真正的代码上；需要时也能一路下钻到具体代码。他重申，像定义清楚的 bug 这种任务可以聊天式地交出去，但那不是大多数编程，也不是很多人看重的那部分。

对担心前途的年轻程序员，Michael 的回答出人意料地乐观。他说现在编程比 2012、2013 年好玩得多，那时有大量的样板代码和查各种刁钻资料的苦活。今天这些没消失，但人们被吸引来编程的那些东西，快速构建、个人掌控，都被放大了。他预期技能也会变：品味和创意会被放大，样板式的文本编辑会少一些，甚至"细心"这项今天非常重要的能力也会变得没那么重要。

Arvid 给了一个亲身例子。他们把代码库从 Node.js 的 AsyncLocalStorage（性能不太好）迁移到 context 对象，影响整个代码库，即使用着当时的 AI 工具，两个人也花了大约五天。他期待的是：给几个示例，AI 应用到所有地方，遇到新情况再问你，十分钟搞定。更重要的是，成本一低，你就不用站在黑板前把一切想清楚再动手，可以先试，发现不对立刻改。Aman 接着说，他自己更喜欢直接动手、看代码怎么展开再迭代，而不是先想清楚再把有限的工程时间花在实现上。

Lex 追问：如果 Tab 足够强，那个爱编程的人只剩下按 Tab 了吗？Aman 先说，最好的程序员是真正热爱编程的人，团队里有人下班回家还打开 Cursor 写自己的项目到凌晨三点，心情不好时说"我就是需要写代码"。Arvid 则重新定义了按 Tab：

按 Tab 只是个好记的说法。你按 Tab 时真正在做的，是不断注入你的意图。

Pressing tab is just pressing 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.

有时你拒绝，有时你多敲几个字符，这就是你在塑造正在生成的东西。Sualeh 的说法是：人和电脑之间的沟通带宽越来越高，打字只是一种很低带宽的意图表达。

这三种说法放在一起，构成了 Cursor 对"人在回路中"的完整辩护。它不是为了保住程序员饭碗的口号，而是从前面几章推出来的结论：意图很难一次说清楚，所以需要即时迭代；模型生成越多，验证越成为瓶颈，所以审阅体验要重做；模型找 bug 还很弱，所以人要留在关键决策点上。

如果这些前提中有一条被打破，比如形式化验证真的像 Arvid 设想的那样普及，或者 agent 的验证能力追上了生成能力，那么"驾驶座"的位置可能会往后挪。访谈里没有人回答这个问题：当模型能可靠地验证自己时，人还需要在多大程度上掌握微决策？这正是这期访谈留下的最大悬念。

其他值得记下的观点

• Arvid 介绍了他们内部的 prompt 系统，借鉴 React 的声明式写法：用类似 JSX 的组件描述 prompt，每块内容标注优先级（比如光标所在行最高，越远越低），由一个渲染器决定放得下什么。最初是为了应付 8000 token 的小窗口，后来的主要价值是把原始数据和渲染逻辑分开，改了渲染方式可以在旧数据上回放，看整个评测集有没有变好。Arvid 认为用户不需要学这些，自然地写就行，检索相关内容是 Cursor 的事。
• Sualeh 和 Aman 讲了代码库索引的扩展难题。为了让本地和服务器的状态一致又不频繁扫描，他们用 Merkle 树：每个文件一个哈希，每个目录的哈希由子项组成，只比对根哈希，不一致才逐层往下找。Aman 说成本瓶颈在计算 embedding，所以按代码块的哈希缓存向量，同公司的第 N 个人索引同一份代码时会非常快；服务器上不存储代码，只存向量。Sualeh 在访谈中提到这个数据库接近 20TB。
• Arvid 说他们考虑过本地跑模型，但超过 80% 的用户用 Windows，很多机器并不强。Sualeh 补充，问题不只是电脑弱，大公司的代码库在最强的 MacBook Pro 上也处理不了。Aman 认为编程场景里用户永远想要最强的模型，而最强的模型（包括越来越大的 MoE）根本装不进笔记本。
• Arvid 更看好同态加密的推理：本地加密输入，服务器在密文上计算，看不到内容。他担心的是，模型越有用，世界上越多数据会以明文流经一两家中心化公司，以安全为名的监控可能滑向滥用。Sualeh 担心 Anthropic 负责任扩展政策中的高等级（ASL-3、ASL-4）模型会要求监控所有 prompt。Aman 反问这和云服务商有何不同；Arvid 的回答是很多人会把从不放上云的私人数据交给 AI，而云上你还能用自己的密钥，AI 提供商却能看到全部明文。
• Sualeh 提到数据库分支：PlanetScale 等可以在预写日志上开分支，他们用的向量数据库 turbopuffer 也可能加入这类能力，AI agent 可以在分支上测试而不碰生产库。Aman 希望文件系统也能分支。
• 关于基础设施，Arvid 说 Anthropic 设置起来很痛苦，但用起来永远可靠，"出了问题多半是你自己的问题"。Michael 说规模每多一个零都会遇到新问题，包括数据表溢出。
• Sualeh 讲了 2022 年 6 月 Aman 和朋友打的赌：2024 年模型能否拿到 IMO 金牌。他当时觉得 Aman"疯了"，后来承认自己错得很离谱。DeepMind 的结果距金牌只差一分。Aman 当时补充，数学尤其是形式化证明有明确的验证信号，强化学习很适合，所以可能出现数学上远超人类、但仍不算 AGI 的系统。被问到 AI 何时拿菲尔兹奖级别成果时，Sualeh 猜 2028 到 2030 年，Aman 认为可能在 AGI 之前，但也承认自己对定理证明前沿的直觉不如当年对 IMO 那么清楚。

对 builder 有什么用

• 给你的 AI 功能做一次"熵审计"。列出用户在产品里必须做、但不带新信息的操作（重复修改、可预测的跳转、照抄式的确认），挑一个让模型一键完成，并像 Cursor 一样定一个指标：用户能连续接受多少次。
• 别让前沿模型直接输出精确的修改结果。让它写粗略方案，再用一个专门训练或更便宜的模型把方案落地，同时测一下你现有的确定性合并逻辑实际失败率是多少。
• 建一套不公开的评测集，并安排固定的内部人工试用。选型时不要只看公开基准，尤其是 SWE-bench 这类可能已经进了训练数据的榜单。
• 把 prompt 的原始输入数据和拼装逻辑分开存储。下次改 prompt 时，在旧数据上整体回放，用评测集比较新旧版本，而不是凭几个例子判断。
• 想做 AI 找 bug 或代码审查，先试"埋 bug 再找 bug"的合成数据思路；同时在高风险代码处加醒目的危险注释，看模型在这些区域的检出率有没有提升。