Cursor 团队的创始成员 Michael、Swalette、Arvid 和 Aman 在一次访谈中透露，他们的用户中已经有人实现了「100% 的代码都是 AI 写的」。
如果你还在逐行敲代码，你可能正在用打字机时代的方式工作。
这不是危言耸听。2021 年 GitHub Copilot 发布时，自动补全功能让一两行代码瞬间出现在光标后，那种「它懂我」的感觉让无数程序员兴奋。但三年后的今天，Copilot 开始显得迟缓——不是它变慢了，而是 Cursor 将「预测」这件事做到了极致。
Michael 回忆他们最初决定做 Cursor 时的场景：「我们看到模型在变好，但煤矿工人的体验没有改变。」他说的「煤矿工人」指的是程序员。那是 2022 年，他们拿到了 GPT-4 的早期访问权限，模型能力的飞跃让他们意识到——编程环境本身需要被重新设计。
但这群人最初并不打算做编辑器。
Arvid 是纯 Vim 用户出身。终端，黑色背景，绿色字符，手指不离键盘。他对 VS Code 这种「现代编辑器」不屑一顾，直到 Copilot 出现。「那种体验超过了我对 Vim 的热爱，」他说，语气里带着一点妥协的味道。
这是 2021 年。那一年，OpenAI 发布了 Scaling Law 论文。Aman 读完后激动地找到 Michael，问了一个问题：「为什么 Scaling 不是我们需要的全部？」Michael 当时觉得这个想法「太疯狂了」，甚至有点「妄想」。但现在他承认：「我可能是小组里最错的人。」
团队里有人下了个赌：2024 年 6 月，AI 能不能在国际数学奥林匹克竞赛（IMO）中拿金牌？当时 Aman 站在「能」的一边，穿着印有 Scaling Law 公式和图表的 T 恤四处走动。结果呢？DeepMind 的模型差一分就拿到金牌。技术上没错，但还差一分。
这个细节很重要。它说明了两件事：第一，这些人对 Scaling Law 的信仰有多深；第二，他们愿意为「也许不可能的事」下注。
Cursor 不是 VS Code 的插件。它是 VS Code 的 Fork。
这个决定在当时看起来有点疯狂。VS Code 已经是最流行的代码编辑器，有庞大的插件生态，GitHub Copilot 也跑在上面。为什么不直接做个扩展？
Swalette 的回答很简单：「如果你是插件，你对代码编辑器的控制力非常有限。」他们想做的不是「给现有编辑器加点 AI 功能」，而是「让 AI 成为编辑器的一部分」。这意味着他们需要控制整个用户体验——从提示如何渲染，到模型如何训练，再到界面如何响应。
这种控制在技术上体现为一个叫「preemptive」的内部系统。它类似于响应式网页设计：你用 JSX 声明性地描述「我想要什么」，然后由渲染引擎（preemptive）决定「如何塞进有限的上下文窗口」。
举个例子：假设你的光标停在某一行。这一行显然是最重要的，所以它的优先级最高。往上或往下的每一行，优先级递减。当模型只能容纳 8000 个 token 时，preemptive 会自动裁剪掉优先级最低的部分，同时保留所有必要的上下文结构。
这听起来简单，但实际操作时需要大量工程细节。比如：如何处理文件夹层级？如何处理多文件编辑？如何确保本地代码库状态和服务器同步？Aman 提到，他们用了类似 Merkle Tree 的方式：每个文件有个哈希值，每个文件夹保存所有子节点的哈希值，递归到顶层。这样只需要对比根节点的哈希，就能知道哪里不一致。
但用户不会在意这些。他们只会觉得：「这个编辑器很快。」
Cursor Tab：消灭所有低熵操作
Cursor 的核心功能有两个。第一个是「监视你的肩膀」，像一个非常快的同事，能预测你接下来要做什么。第二个是让你「领先一步」，告诉 AI 做什么。
Cursor Tab 属于第一种。
它的目标是「消灭所有低熵操作」。什么是低熵操作？就是那些「你已经知道要做什么，但还得敲几下键盘」的事情。比如：写完一个函数，下一步显然是要跳到测试文件里加个测试。Cursor Tab 会预测到这一点，直接跳过去，并且建议下一个编辑。
Arvid 说：「有时候你只需要一直按 Tab。」
这听起来像是玩笑，但实际上是一种产品哲学。他们认为，一旦你表达了意图，剩下的编辑就应该是「零熵」的——不需要新信息，只需要让计算机理解你的想法。所以他们内部有个竞赛：能让 Cursor Tab 预测多少步？
技术上，这需要训练小模型。这些模型有两个特点：第一，极其「贪婪」，需要大量输入 token；第二，生成的 token 很少。为了让它快，他们用了 MoE（混合专家模型）+ 推测性编辑（Speculative Editing）。
推测性编辑是什么？它是推测解码的变体。简单说：假设你要编辑一个文件，模型会先把原始代码「喂回去」，大部分情况下它会同意原始代码，直接输出。这样可以并行处理很多行。直到某个地方出现分歧——模型预测的内容和原始代码不一样——这时候才开始生成新 token。
最终效果：用户看到的是「代码在流式地往下滚」，速度非常快。
另一个关键技术是缓存。因为输入 token 太多，如果每次击键都重新跑一遍模型，延迟会爆炸。所以他们设计了「缓存预热」：当你开始输入时，系统就假设你会用到当前文件内容，提前把 KV Cache 算好。等你按下回车时,大部分 token 已经预填充完了，首字延迟大幅降低。
但这还不够。
Apply：当「应用」变成一个模型
在 Cursor 里有个功能叫「Apply」。当 AI 给出建议时,你可以点「应用」,它会自动把修改合并到你的代码里。
听起来很简单？其实不然。
大多数人以为这是一个「确定性算法」——就像 Git 的 merge 那样，按照某种规则把两段代码拼在一起。但 Swalette 说:「如果你尝试做确定性匹配，至少 40% 的时间会失败。」
所以 Apply 也是一个模型。
这个模型的任务是:看着你的原始代码和 AI 的建议,生成一个「完美融合」的版本。它需要理解哪些部分该保留,哪些部分该替换,哪些部分需要微调。更重要的是,它需要处理「行号计算」这种琐碎但容易出错的细节。
Arvid 提到,他们试过让 Sonnet 和 O1 这样的前沿模型直接做 Apply,结果「它们会搞砸一些愚蠢的事情,比如算错行号」。所以他们训练了专门的小模型来处理这个任务。
这种设计哲学贯穿整个 Cursor:用前沿模型做高层规划,用专门训练的小模型做具体实施。就像 Aman 说的:「你可以给模型一个非常粗糙的草图,然后让小模型去实现它。因为实现这个任务非常简单,但勾勒出草图需要真正的智能。」
Shadow Workspace:在后台跑代码
Arvid 写过一篇博客,标题是「Shadow Workspace:在后台迭代代码」。
这个想法很疯狂:在你写代码的时候,系统在后台开一个隐藏的 Cursor 窗口,AI 在那里修改代码、获取 linting 错误、跳转到定义、甚至运行测试。所有这些都发生在你看不见的地方。
为什么要这么做？因为如果你想让 AI 真正理解你的代码库,它需要「反馈信号」。语言服务器可以告诉你「这里有个类型错误」,可以让你「跳转到定义」。这些信息对人类程序员很重要,对 AI 也一样。
技术上,这需要在用户机器上「镜像」整个开发环境。Linux 可以用 lockless save——让 AI 修改文件,但不真正写入磁盘,所有改动都存在内存里。Mac 和 Windows 更麻烦,需要一些内核扩展才能实现。
但这值得吗？Swalette 的回答是:「如果你可以在后台花费计算,你可以预测接下来 10 分钟用户要做什么。」
想象一下:你在写前端代码,AI 在后台已经把后端的 API 改好了。当你切到后端时,初始版本已经在那里等着你了。你只需要迭代和调整。
这不是科幻。这是他们正在实验的东西。
理论升华:编程正在变成「写书法」
有个有趣的观察:语言模型在代码上的损失(bits per byte)比自然语言更低。这意味着代码比自然语言「更可预测」。
换句话说:很多代码是机械的、重复的、低熵的。真正需要人类决策的部分,只有那些「高熵」的时刻——选择用什么架构、如何处理边界情况、在速度和成本之间做权衡。
Cursor 团队认为,编程正在分裂成两种活动:
- 传达意图(高熵,需要人类)
- 实现细节(低熵,可以交给 AI)
这听起来像是在说「程序员要失业了」。但他们的观点恰恰相反。
Michael 说:「我们不想要一个由 AI 运营的公司。我们想要人类在驾驶席上,做真正的软件设计决策。」Aman 补充:「很多编程的价值在于迭代。你不知道你想要什么,直到你看到初始版本。然后你迭代,提供更多信息。这个过程无法被预先指定。」
所以他们的愿景不是「用 AI 替代程序员」,而是「用 AI 增强程序员」。就像 Swalette 说的:「写代码正在变成书法艺术。」你关心的不再是「怎么敲键盘」,而是「如何设计这个系统」。
但这里有个悖论。
局限性:当模型不知道哪里有 Bug
AI 在编程中的最大问题不是「写不出代码」,而是「找不到 bug」。
Aman 说:「这些模型在发现 bug 方面非常糟糕。即使是最聪明的模型,即使是 O1,它们的校准非常差。」
为什么？因为 bug 检测在预训练数据里不常见。GitHub 上有大量代码生成的例子,Stack Overflow 有大量问答,但「检测真正的 bug 并提出修复方案」的例子很少。
这不只是数据问题。还有一个更深层的问题:人类在判断「哪些 bug 重要」时,依赖的是「文化知识」。比如:一个高级工程师知道,三年前有人写了一段「粗略的代码」,在服务器快关闭时会出问题。这种知识不在代码里,在人的脑子里。
所以 Cursor 团队在研究几个方向:
- 训练「逆向 bug 模型」——先让 AI 引入 bug,再训练另一个模型去发现它们
- 让模型访问更多信息——不只是代码,还有 trace、调试器、运行结果
- 专门的「bug 检测模型」——在后台运行,速度快,专门盯着你的代码找问题
但即使这些都实现了,仍然有个问题:当 AI 生成越来越多代码时,人类需要做越来越多「验证工作」。这会不会让程序员变成「代码审查员」？
Arvid 的回答是:「我不想花所有时间审查代码。」所以他们在研究「智能 diff」——用模型来高亮 diff 中的重要部分,灰化不重要的部分,甚至用小红点标记「这里可能有错误」。
余韵:一个没有回答的问题
访谈快结束时,主持人问了个问题:「如果给你 1 万亿美元,你会怎么花？」
Aman 的回答很诚实:「你只需要买 GPU,然后研究人员会找到所有技巧。」但 Arvid 不同意:「我认为我们受限于想法,而不是计算。」
这个分歧很有趣。它暴露了一个更深层的问题:当我们谈论「AI 的未来」时,瓶颈在哪里？是计算？是数据？是算法？还是人类的想象力？
Cursor 团队没有给出答案。但他们给了一个线索:「今天最好的产品,三四年后会被新产品远远甩开。如果你停止创新,你会输。」
这意味着什么？也许是说:最终获胜的,不是那些拥有最多 GPU 的人,也不是那些拥有最多数据的人,而是那些「跑得最快」的人。
所以,也许真正的问题不是「AI 什么时候会取代程序员」,而是「哪些程序员会率先学会和 AI 共舞」。