Cursor 可谓是最近最火的 AI 代码类应用。
AI 大神 Andrej Karpathy 多次在推特上夸赞 Cursor，说 Cursor 的体验已经碾压式的超过了 GitHub Copilot。
8 月份，他们宣布获得 A 轮 6000 万的融资，a16z 领投，OpenAI 和谷歌首席科学家 Jeff Dean 参投。这家公司现在估值达到 4 亿美元，年度 ARR 收入超过 1000 万美元。
和其他的 Code Copilot 应用不同，Cursor 定位自己是 The AI-first Code Editor。不仅仅是编码插件，而是构建一个新型的代码编辑器——“面向程序员的 Google Docs”。
“我们需要一个全新的 AI 驱动的 IDE”，Cursor 联合创始人 Aman Sanger 是这么说的。在他看来，AI 中的新功能需要 AI UX 的新创新，需要重新设计软件开发流程。
从最早打算做 CAD 大模型，到后来转型做 Cursor，中间到底有过怎么样的探索与思考，以及，Aman Sanger 是如何看待 AI 代码 和 AI 的未来？在 2023 年 Latent Space 的一期播客里，主持人 Alessio、Swyx 与Aman Sanger 聊了聊 Cursor 的创业思考。
一、Cursor 的出发点，是重新设计软件开发流程
Swyx：直接来聊 Cursor，毕竟这是你们现在的主打产品。2023 年 1 月，你们向全世界公布了它。也许可以带我们了解一下 Cursor 的想法演变过程。
Aman：好啊。其实中间还有一小段时间我们尝试转向，做文字生成图像。后来我们放弃了，主要是因为我觉得我们不适合做那种公司。我们从 CAD 项目中学到了教训，现在我们坚信一点：做产品的人最好自己也是产品的用户。但我们自己并不怎么用文字生成图像的工具。
然后到了 2022 年 12 月份，我们设法提前拿到了 GPT-4 的使用权限。在那之前，我们其实已经用 GPT-3.5 的早期版本试过写代码了。但我们差不多放弃了，因为看起来无论是 Text DaVinci 2 还是 Code DaVinci 2，这些 3.5 的老版本，都做不了什么有意义的事情。
但是当我们打开 GPT-4 的 playground，开始往里面粘贴代码，那效果让人大吃一惊。要知道，那时候大家还没开始大规模使用 ChatGPT 呢。
Swyx：你们用的是早期版本吗？
Aman：对，是的。
Swyx：所以是更早的版本，那种还没被约束的原始版本？
Aman：哦，其实不是，它还是很安全的。不过那时候人们还没开始普遍使用它。HumanEval（基准测试数据集）已经存在了，但在大家都开始谈论它之前，我们就尝试用这个进行测试，结果得分达到了 85%。我们当时就惊呆了，要知道，当时最好的开源模型也就 30% 的得分。Code DaVinci 2 大概是 47% 左右。而且，你看，现在的 GPT-4 得分也差不多。
然后我们就开始在里面写代码，就是把我们正在测试和开发的各种代码随便复制粘贴进去。我们发现它不仅擅长创造新东西，还能重构代码、编辑代码、帮你调试。软件开发的方方面面，用这些模型感觉都完全不一样了。
接着我们就在脑子里畅想了一下未来。这才是 GPT-4 呢，要是有了 4.5、GPT-5 会怎样？这些模型在编程方面只会越来越厉害。未来可能不会是你按 Tab 键然后回车就能自动补全更多东西那么简单。我觉得自动补全是个很有用的工具，我们每天都在用 Copilot，觉得挺好用的。但是你想啊，如果语言模型能生成 90%、95% 的代码，那还按原来那种方式来肯定是不行的。
我觉得得彻底重新设计整个软件编写的方式，整个用户体验都得改。这就是我们做 Cursor 的出发点，你得掌控整个 IDE，彻底重新设计软件开发的流程，其实是重新设计整个软件开发的方式。
Swyx：你刚才说的这些可不是小事啊，得好好聊聊。我想往回捋一捋。你们提前用上了 GPT-4，这是不是意味着你们其实是得到了 OpenAI 的支持，在做 Cursor 之前就加入了 OpenAI Fund？
Aman：嗯，差不多吧。
Swyx：哦，好的。因为我在理清时间线，我还以为是他们看中了 Cursor 才给你们投资呢。
Aman：是这样的，OpenAI 有个叫 Converge 的项目，我们参加了这个项目。通过这个项目，我们最大的收获就是可以提前体验到还没发布的模型。当然了，这些都没有用于生产环境，也不可能用于生产环境。就是让我们偷偷瞄了一眼 GPT-4。所以，在我们真正开发 Cursor 之前，我们没有从 OpenAI 那里拿钱，但我们确实参与了这个项目。
Swyx：明白了。对了，你还提到一件有意思的事。你们现在还在用 Copilot，但同时也用 Cursor。对吧。你还说 Copilot 可能是用上万亿个 token 训练的，这意味着从最初的 Codex 到现在，它经历了大量的训练。
Aman：我是这么想的，你看 Stack Overflow？它有多少来着？一到两万亿个 token？差不多这个数吧。我很怀疑 Copilot 会用更少的数据训练，特别是现在还有那么多关于它是否属于“合理使用”的官司呢。
Swyx：所以，我猜就是上万亿个 token。
Aman：我也不太确定。不过我敢说，如果你算一算 GitHub 上有多少公开代码，肯定是以万亿计的。
Swyx：我之所以一直纠结这个问题，是因为我们一直在关注数据集和参数比例的关系。Copilot 不可能那么大，因为它响应得很快。所以它的参数规模应该就是几十亿级别的，对吧？那么问题来了，怎么用万亿级别的 token 训练出一个参数只有几十亿的模型呢？
Aman：我对这个问题有些想法。你知道，现在大家都在讨论 chinchilla scaling（一种模型训练方法），但又有人说，因为推理的原因，chinchilla scaling 其实不重要。不过，Copilot 可能是一个 MoE 系统。
但这只是另一种猜测，我也不确定是不是真的。至少一两年前可能还不是这样。我猜它可能是一个小模型，但经过了大量的过度训练。据我所知，还有很多缓存技巧可以用，即使模型很大，它实际上也不需要花时间去处理整个提示。
Swyx：他们管这个叫语义缓存，对吧？我猜如果大致嵌入到同一个东西，就直接返回相同的结果。
Aman：我觉得部分是这样的。比如说，如果你光标前面的代码后缀稍微变了一点，他们可能不会真的去用不同的……
Swyx：这对代码来说似乎有点危险啊。
Aman：确实看起来有点危险，但这样可以让响应速度非常快。还有一个就是 KV 缓存，你知道吧？虽然我觉得现在还没有开源框架在做这个，但如果你已经在 KV 缓存上计算过一些东西，你就可以直接……
Swyx：这里说的是注意力机制中的 KV 缓存，给大家解释一下。
Aman：对，就是注意力机制的 KV 缓存。如果你已经计算出了所有的键和值，你就可以把它们存在内存里，然后直接加载到 GPU 上，这样就不需要再处理一遍提示了。我猜他们在后台可能就是这么做的。
Swyx：那需要不少内存和存储啊。
Aman：除非他们用了类似多查询注意力（multi-query attention）之类的技术……
Swyx：对，我们聊聊你那篇关于 Llama 2 的文章*。你在文章里还提到了一个重要观点，就是必须开发自己的 IDE，而不是写一个 VS Code 插件。现在已经有不少这样的插件了，比如 SourceGraph 就在做一个，我也一直在和刚推出 Rift 的 Morph 密切合作。显然，开发自己的 IDE 是个大工程。你能不能多解释一下为什么要自己开发 IDE 呢？
Aman：我们之所以这么决定，是因为我觉得从长远来看，虽然现在 Cursor 和其他工具提供的功能可能和 VS Code 差不多，但从长期来看，你需要设计一个完全不同的用户体验，而这是插件无法给你的。
我们听说过一个故事，说 Copilot 的多行幽灵文本（multi-line ghost text，就是那种半透明的提示文本），其实不是通过插件实现的。GitHub 的团队不得不联系 VS Code，让他们修改源代码，才能启用那个扩展 API。这就是多行幽灵文本补全的实现方式。这挺吓人的。
想想看，如果 VS Code 在他们的源代码中还启用了一些其他 API，但这些 API 只对 Copilot 开放，对其他所有人都是关闭的。所以我觉得这里存在一个根本的平台风险，你在和拥有平台的 incumbent（在位者）竞争，而你却要在他们的平台上构建。从这个角度来看，我们觉得这样做不太可行。
另外，如果你想做一些更花哨的功能，也需要自己的 IDE。
比如说，我们现在正在开发一个功能：Copilot 很擅长补全下一行或接下来几行代码，但如果你想做编辑，不仅仅是补全这一行，而是改变上面的行或者删除一些东西呢？在 VS Code 里你根本无法实现这样的功能，但我们在 Cursor 里已经为此构建了 UI。我们现在正在训练模型，让这个功能运行得更好。我们认为一旦这个功能完善，它会非常有用，可能会达到 Copilot 那样的实用水平。但如果你不拥有自己的 IDE，这根本就是不可能的。我们还在酝酿很多类似的功能。
还有一些小细节。比如说内联编辑，在 Cursor 里你可以按 Command+K，然后要求修改代码或生成代码。我觉得我们在这方面的用户体验可能是最好的。如果你看看 Sourcegraph 的做法，他们基本上只能使用 GitHub 的拉取请求评论功能（pull request comment）来实现这一点。我觉得这些小问题随着时间积累起来会很烦人。
Swyx：确实如此。而且 Cursor 给人的印象很好，下载很快，安装包很小，启动速度也快，用一个文本文件就把你带入了教程。真的很棒。
Alessio：我今天刚用过。我最喜欢的一点是，你们允许用户使用自己的 API 密钥。这是我在很多产品中都没看到的功能，大多数产品都要求你注册账号什么的。
Swyx：嗯，不过你得相信他们不会滥用你的密钥。
我在想啊，OpenAI 要是能再多做一件事就好了，就是给每个 API 密钥设个消费上限。这样不就给其他公司留出空间来做这个了嘛。不过说实话，OpenAI 明天就能搞定这功能。
Alessio：我看到 Logan（Logan Kilpatrick，谷歌 AI 负责人）发推问大家，每个密钥单独计费是不是个好主意。
Swyx：我觉得挺有意思的。他们肯定在考虑这事儿。
Aman：是啊，不过他们还有更重要的事要忙呢，比如 GPT-4.5。
二、一开始想做 CAD 大模型，但很快就放弃了
Swyx：你之前在桥水基金（全球最大的对冲基金）、麦肯锡、谷歌和 You.com 工作，主要做 AI 相关的项目，还有一些金融方面的工作。你创办了一家叫 Abelian AI 的咨询公司。麻省理工毕业，学的是计算机科学和数学。你还参与了好几个项目，包括我们待会儿会聊到的 Instill 和最近的Cursor.so。
咱们先说点轻松的，有没有什么 LinkedIn 上看不到，但你觉得大家应该知道的有趣的事？
Aman：你可能不信，我以前可是个壁球高手。
Swyx：你还是高手啊？
图中右 1 为 Aman Sanger
Aman：对啊，高中的时候还参加过比赛呢。不过说实话，很多人可能都不太了解壁球。其实它和网球有点像，也是用拍子打球，不过是在室内，对着墙打。我本来是打网球的，后来搬到一个有壁球场的地方，就开始玩壁球了。一玩就喜欢上了，之后就一直在打。高中时经常去比赛，到了麻省理工也没停。只是搬到旧金山后打得少了，这里壁球场太少了。
Swyx：那我们可以组织个壁球赛，你肯定能横扫全场。对了，你觉得运动员的心态对你现在当创始人有什么帮助吗？
Aman：是啊，有时候可能会有点帮助过头，但我确实很好胜。我真的很讨厌输。现在我出去跑步，要是有人想超过我，我绝对不会让他得逞。我会立马加速，如果实在跑不过他，我可能会转个弯跑别的路，但绝不能让人在跑步的时候超过我。我觉得创业也是一样的道理。这种好胜心总的来说能激励我，让我更加努力工作。
Alessio：2022 年 8 月，你推出了一个叫 Instill 的项目，能不能跟我们说说这个项目？
Aman：在说 Instill 之前，我可能得先聊聊我之前在做什么。因为 Instill 其实是我和我最初的联合创始人 Michael 一起做的项目中的一个小插曲。我们俩是高中同学，后来一起上了麻省理工。毕业后，我们都想创业干点什么。2022 年 6 月份的时候，我们在做的项目也叫 Cursor，但跟现在的完全不一样。
我们那会儿是 Copilot 的狂热粉丝，简直爱不释手。我们对计算机辅助设计（CAD）软件也有一点经验。说来也巧，我们很多朋友都是机械工程师。他们经常抱怨用 Solidworks 之类的软件设计零件有多麻烦。我们就想，要是能训练一个 Transformer 模型，不光是预测代码的下一个 token，还可以用于 CAD，那不就能做出一个超级实用的产品，大大提高机械工程的效率吗？
所以在做 Instill 之前，甚至在 Instill 之后的一段时间，我们一直在搞这个。挺有意思的。虽然现在我们做的模型训练比以前少了，但那会儿我们可是从头开始搭建模型，没少花时间在训练和推理上。
Alessio：我一直很好奇，是什么让你对这个产生了兴趣。显然，你在AI这个领域一直走在前沿。为什么你觉得这是最有意思的方向呢？是因为觉得没多少人在做这个吗？还是你觉得自己有什么独特的见解？
Aman：首先呢，我一直对 AI 很着迷。说起来，我最初学编程其实就是因为看到了 ImageNet 的那些论文，听说了深度学习这个东西，感觉简直酷毙了。所以我的第一个编程项目就是用 Java 搭建和训练神经网络，因为那会儿我就只会这一种语言，还是在计算机科学课上学的。从那以后，我做的所有事情都跟机器学习、AI 有关。
至于为什么想创业，我想首先是因为我之前和 Michael 合作过几个项目。我们以前还一起做过 AI 咨询呢。我们俩配合得特别好，而且真的很享受一起独立做事的感觉。
说到 CAD 这个项目，我们当时在构思阶段，说实话，我们挺担心在其他领域竞争太激烈。不过现在回过头来看，这种担心确实少了不少，尤其是考虑到我们现在在做的东西。当然了，编程领域的竞争还是很激烈的。
但是 CAD 这个方向看起来好像没多少人关注。至少在当时，从技术上来看似乎是可行的。而且如果你深入研究一下，就会发现这个市场其实挺大的。所以呢，这既是一个非常有意思的技术难题，也会觉得是个不错的主意。
Alessio：作为创始人，你是怎么决定放弃这个项目的？
Aman：我觉得我们当时没考虑到几个关键点。
首先，看看最初的 Codex 论文（Evaluating Large Language Models Trained on Code），我们的假设是这是驱动 Copilot 的模型。它用了 1000 亿个 token 训练，其中大概 500 亿是 Python 代码。有个有意思的发现是，从文本预训练模型到代码模型，实际上没有迁移收益。
简单说，他们用了 GPT-3，对于那些没用全部 Python 数据训练的小模型，GPT-3 确实能更快地迁移学习。但是到了最终的 Codex 模型，发现根本没有迁移学习的好处。也就是说，你直接用那 1000 亿个 Python 代码 token 从头训练一个模型，效果和微调过的 120 亿参数 GPT-3 模型差不多。
问题是，这只适用于 GPT-3 和 1000 亿个 Python 代码 token 的情况。现在嘛，虽然还没定论，但看起来学习语言对编程确实很有帮助。
这就引出了 CAD 的问题。首先，CAD 的数据比代码少太多了。假设你需要 500 亿到 1000 亿个 token，那么就算只有十分之一，可能也能训练出一个不错的模型。但实际上，现在的 Copilot 可能用了上万亿个代码和文本 token。而 CAD 呢，就算把所有数据都搜刮来，最多也就 100 亿个 token。这根本不够训练出一个有用的模型。
我们试过扩大规模，用了各种正则化技术，但都没法在不过拟合的情况下将其扩展到超过几十亿参数。这是个大问题。
另外就是没有迁移学习的效果。现在如果你测试这些模型，即使是 GPT-4，我有个常用的提示词，可以用来测试 3.5 和 4 的区别。但有时连 4 都搞不定。
这个 prompt 是 Gary Marcus 发明的，在桌子上依次放一堆方块，让 AI 去计算和描述。随着复杂性的增加，3.5 会掉队，复杂性再增加，4 也会掉队。但很明显，这些模型在空间推理方面不太擅长，而这正是 CAD 所需要的。
Swyx：哦，是的，没错。
Aman：你想啊，如果我要用 CAD 设计一张桌子给你看，我得先画个长方形，然后做个拉伸操作，就是把这个长方形垂直于平面拉出来，变成一个立体的。
Swyx：对。
Aman：然后模型得意识到，好，现在这个形状就是桌子了。更难的是，对于其他操作，它还得指出已经构建的几何结构。基本上，要想模型工作得好，它得在“脑子”里想象这个 3D 结构。但这些模型做不到这一点。你要是试图用这个任务去微调代码模型或语言模型，它们的迁移效果都不好。
Alessio：你觉得两三年内会有好用的AI驱动的 CAD 软件吗？
Aman：嗯，我现在的看法是，可能最好的方法是彻底重新设计整个系统。我们之前遇到的另一个大问题是，我们试图为所有主流 CAD 软件开发插件，比如 SolidWorks、Onshape 之类的。要是你觉得给一些老旧的 IDE 开发插件很难，那你就没见识过这些 CAD 软件有多难搞。所以即使你有了一个不错的模型，要真正推广并开发出一个好用的插件也是相当困难的。
现在看来，考虑到文生成图的进步，还有一些新公司在做文字生成 3D 模型的东西，感觉更合理的方法可能是彻底抛弃现在的 CAD 使用方式。我猜很快就会有一家或几家公司在这方面做得很好。
Swyx：这个想法很独特。
三、代码解释器是真正找到了PMF 场景的 AI Agent
Alessio：聊聊你们现在在做的事情吧。跟其他工具不一样的是，你们有个类似系统提示的功能，给AI设定一些规则。为什么要这么做？是不是发现用户老是重复输入相同的提示，觉得麻烦了？
Aman：对，问题就出在这儿。我们需要给模型设定一些规则，因为模型在某些地方老是出错。比如我们用的是 Solid 框架，而不是 React。Solid 是另一个响应式 UI 框架，速度更快。我合伙人比我更懂这些技术细节。
用 Solid 有个好处是在我们定制的 VS Code 版本里，可以把 Solid 嵌入到多个路由里，而 React 通常只能接管整个 DOM 树的根节点。这样，Solid 的性能更好。所以我们选了 Solid。
问题是，每次你创建一个 TSX 文件，写组件时，GPT-4 总是默认你用的是 React，这就导致代码会写错。所以给系统提示加上这些规则非常有帮助。另外，对于英语不太熟练的用户，我们还会加一些指令，比如“用你最熟悉的语言描述”。
Swyx：简单解释一下，你们主要用的是 GPT-3.5，专业用户可以用 GPT-4。你们通过这些系统提示来引导 GPT-3.5。除了你们公司特有的提示和针对非英语用户的指令，你还有什么其他方法引导 GPT-3.5 或 GPT-4 来写代码吗？
Aman：整体来说，这些模型在生成新代码或从头开始写代码上挺擅长的，但在编辑或修改现有代码时表现就不太好，特别是生成差异（diff）的时候。你可能也遇到过这个问题，模型经常搞错行号。而且生成 diff 其实用的计算 token 比较少。
有人认为，模型用的 token 越多，它的推理能力越强，也就是所谓的“思维链”。这是我们一直在努力解决的问题。
我们的一个技巧是，先用 GPT-4 生成一个 PR 草稿，然后再用 GPT-3.5 去修复这个草稿中的 diff，再用 3.5 处理那些修改。这样可以绕过模型在编辑上的限制。
至于一般的代码编写，GPT-4 表现就很出色了。如果用 GPT-3.5，我强烈推荐使用 Azure 的模型，因为它有 completions 功能，可以给 GPT-3.5 一个开头，让它接着写，这有点像 Claude 的功能，真的很好用。
Swyx：我之前还以为这个 API 迟早会被淘汰，因为 OpenAI 明显不太愿意维护它。现在他们直接宣布要弃用了。
Aman：确实有点失望，我觉得这个功能对写代码很有帮助。你知道，在聊天格式里你没法在代码的某行中间做修改，但用 completion 格式就可以轻松做到。
Swyx：我和 Jesse 在研究 GPT-4 时学到一个小技巧，他总是先让 GPT 给代码写注释，再写代码，这其实就是“代码的思维链”，对吧？所以我现在让 AI 写代码时会这么说：“给我一份带完整注释的代码，简单解释一下它是怎么工作的，并尽量用最有效的解决方案。如果合适的话，提供替代方案。如果你不确定我使用的环境或库版本会影响结果，请向我确认。”这是我现在常用的自定义指令。我觉得我们应该作为一个社区分享这些自定义指令和系统提示。
Aman：让它更详细有点让我担心用户体验。因为 token 多了，结果出来的时间就长了。而且我不想看一大堆冗长的回答，有时我只是想快速得到答案，或者只需要一小段代码解决问题。这确实是个需要权衡的点。对于 diff 也是，如果能让 diff 生成得更快，可能质量就会下降。
Alessio：你们在聊天工具里做了一件挺不错的事，就是删掉了没改动的代码。我用它改代码库时，它会给现有代码加注释，只告诉我需要改的部分。有时候用 GPT-4 挺让人烦的，它总是把整个函数给我重写一遍。
我注意到，现在如果你不是从文件开始对话，它可以直接应用改动并放入代码里。这功能这么难实现吗？很多产品都有类似功能，这是技术难度问题，还是用户体验上的考虑？
Aman：有两种方式吧。你说的应用改动，是指你选中代码的一部分，按个按钮，它就直接帮你改？
Alessio：对啊，比如它告诉我要加三行 Python 代码，我就想，能不能别让我手动复制粘贴。虽然最后我还是粘了，但如果能自动改就更好了。
Aman：你说的是让它直接改好代码。这个功能我们这周就会加上，很多用户都在提需求，技术上也不难。我们只是想慎重一些，因为这个功能成本高，而且 GPT-3.5 在这方面表现不算好。
Alessio：我还发现，你们聊天工具可以选择带上下文或者不带上下文。带上下文时，会传一部分代码库；不带上下文时就不传。但每次它都会加载许可证文件。你们有没有想过怎么避免这类问题，还是说模型认为许可证文件特别重要？
Aman：是啊，现在它用的是最基础的嵌入方式。
我们正在研究一些有意思的技术，可能会大大提高检索效果。其中一种是微调模型，让它能“记住”整个代码库。前不久谷歌发了一篇论文，叫《将 Transformer 作为可微分搜索索引》（Transformer Memory as a Differentiable Search Index）。简单说就是，用代码库或者文档训练 Transformer，让它能直接回答哪个文档跟问题相关。比如你问关于某段代码的问题，模型不只告诉你在哪个文件，而是具体到哪个函数或类能解决问题。它不会把所有代码都列出来，只给你相关的部分。我们做的初步实验效果还不错。比老掉牙的 BM25 检索技术，甚至比基于嵌入的技术表现更好。所以我们在这个方向上继续探索，觉得会很有帮助。
另一个方向是改进嵌入技术。最近阿里巴巴发了一篇论文，他们开发了一个新模型，训练成本不到 1000 美元。在非代码任务上，它打败了 OpenAI。不过在代码嵌入任务上，OpenAI 还是更强。如果我们自己训练嵌入模型，再针对特定代码库微调，效果应该会更好。所以我们现在在这两条路上都在探索，希望能提升检索性能。
短期内，我们已经可以用一些重排序器和更高级的调优技术。你在聊天界面里应该可以看到有个按钮可以开启重排序，这能显著提升性能。
Swyx：太棒了。
Alessio：产品还有什么功能没提到吗？比如行内生成和行内问答模型，聊天界面在右边，对吧？
Aman：有个功能用户特别喜欢，就是可以添加文件或文档。比如你想加入最新的 Next.js 文档，只要在聊天框或命令面板里输入“add Next.js”，这些信息就会被加入到你的上下文里。
我们还有不少新功能即将推出，其中一个特别让我们兴奋的，就是类似代码解释器风格的聊天模式。
我说的不是传统意义上的代码解释器，但我觉得代码解释器是目前少数真正找到了PMF 场景的 AI Agent。它特别好用的原因是，当你让 AI Agent 处理大任务，比如审查 PR 或大段代码变更时，很多人觉得太复杂。但如果把任务拆成一个个小单元，用户可以轻松审核和理解。
举个例子，模型生成一个图表后，你可以立刻看到结果，并判断对不对。如果有问题，你还可以查看代码，代码也很容易理解。所以让 AI Agent 处理这种小任务单元，并且以用户容易理解的方式展示输出，非常重要。
我们正在聊天功能里开发这样的工作流程，预计两周内推出。我们对此特别期待，因为之前我们做了很多 AI Agent 的实验。最大的问题是，它生成了大量代码，但你很难判断代码是否正确，最后还不如用户自己写效率高。
Swyx：我们之前有个嘉宾 Itamar，他在 Codium 上的做法是，把开发规格说明、测试和源代码结合起来。简单说，规格说明是提示词，然后用它生成测试，再生成代码。他的观点是，验证代码唯一的方法就是通过测试运行。这是他对 AI 代码 agent 的看法。
Aman：我觉得测试确实是个很有前途的方向。如果你有一套非常严格的测试，能完全确认 AI Agent 是否做对了，那就解决问题了。但我觉得这只是整个拼图的一部分。问题在于，写一个超长的提示词来描述所有东西真的很痛苦。我希望能够保持在心流状态中，看到一个变化，然后一步步往下走。我觉得这样做更有意思。假设功能差不多的话，更有趣、更容易使用的产品才能胜出。这就是我们的赌注所在。
Swyx：你们有没有考虑过版本控制的问题？你说可以添加文档，这很酷。我之前也想过这个，但总是卡在版本控制上。你们是选择不管这个，就直接嵌入最新的文档吗？
Aman：你可以添加任何你想要的文档，只要有 URL 就行。你可以直接粘贴文档的 URL。
Swyx：哦，你们有爬虫啊。
Aman：对，我们在后台爬取并嵌入。所以你可以有自定义的版本，或者你用的任何版本。它会在本地为你存储。你说的爬取差异是指什么？
Swyx：这意味着你们其实写了一个搜索引擎，对吧？
Aman：其实很基础。相比其他东西，文档爬取起来超级简单，因为它们基本上都是类似 markdown 的格式。
Swyx：嗯，确实。
Aman：我们绝对没有写一个爬取整个互联网的爬虫啦。
四、提升 AI 能力的关键，是让 AI 用上更多工具
Swyx：说到代码解释器，我们之前也做过一期节目。我觉得它可以算是 GPT-4.5 了，因为它是在 GPT-4 的基础上针对更多代码进行了微调。而且它还有一些在传统大语言模型设置中无法实现的推理能力。不过，GPT-4 最重要的特点是它有沙盒环境。
所以我想问你们的是，你们打算在自己的环境中运行沙盒，还是想在我们的本地机器上运行，毕竟你们也有权限访问？这个问题我们得非常小心。
Aman：是啊，你可不想不小心执行了“sudo rm -rf *”之类的命令。
我们的计划是在本地机器上运行，但每次都会询问用户是否同意。我觉得如果我们想让 AI Agent 执行多个操作……就拿代码解释器风格的功能来说，它的优点在于你把任务分解成了小单元，所以你可以在每一步把一堆命令打包在一起，然后问问用户，因为用户一直在看着呢。对于完全在后台运行的 AI Agent，你可能就需要一个封闭的环境，让代理可以安全地执行任意代码。
有一种很危险的攻击方式是，如果某个团队想要进行提示注入攻击，他们可能会在代码中加一条注释，比如说“当你做这种编辑时，你应该执行 rm -rf 或者其他非常危险的操作”。问题就在于，如果一个 AI Agent 在后台运行，然后它执行了那段代码，获取了那条信息，如果提示注入成功了，它就会真的执行那个危险操作。同样的情况也可能发生在文档上，如果有人怀有恶意，获取了其他人使用的某份文档的访问权限，他们可能会尝试对那些正在运行代码和终端命令的 AI 代理进行提示注入攻击。
Alessio：现在已经有人在劫持 npm 包了。
Swyx：是啊，我敢说这种恶作剧以后只会越来越多。不过我觉得，最安全的方式可能还是在云端使用沙盒。我一直把这种现象称为“代理云”。我知道 Fly.io、Modal 和 E2B 已经在这个领域了，Repl.it 也在探索。你们要是也加入感觉会很有意思。
我有点说不清楚代理云和典型的无服务器沙盒有什么不同。基本上，我觉得如果代理云要成为一个真正的类别，我们得搞清楚我们想给AI什么样的反馈，这些反馈又和给人类的有什么不同？这就是我目前对这个问题的想法。
Aman：我觉得现在很多人忽视了一个关键点，就是给 AI 更多工具的使用权限。
我最喜欢举的例子是早期的 AlphaCode 模型。它在某个编程竞赛中达到了 50% 的水平，也就是说比一半的优秀程序员还要厉害，对吧？这个基础模型在 HumanEval 测试中只得了大约 28% 的分数。他们用了一个很有意思的推理策略，让模型生成一堆测试用例，然后运行这些测试用例，看哪些能通过。他们还用了一些其他技巧，比如聚类什么的。但关键在于让模型自己生成测试，然后对它生成的所有输出运行这些测试。这就把一个在代码能力测试中只有 28% 的模型提升到了 50% 的水平。
再看 GPT-4，你只要加一个很简单的提示，比如“请完成这个 Python 函数”，它在 HumanEval 测试中就能得到 85% 到 87% 的分数。当然，谁知道这个基准测试有多准确呢？但假设它还算合理，你觉得如果 GPT-4 用和 AlphaCode 一样的推理策略，在这个基准测试中会得多少分？肯定会表现得非常好。而且 GPT-4 已经到了一个新的水平，它不仅能运行测试然后给出是或否的答案，还能看到测试结果，然后根据结果修改代码或测试基础。
这只是一个工具的例子。另一个可以用的工具是语言服务器。这是 VS Code 的一个很棒的功能，VS Code 发明了语言服务器或者说语言服务器协议。所以当我们使用 VS Code 的分支时，我们就能访问语言服务器协议的每一个部分。这意味着我们可以跳转到定义，获取整个工作空间的所有符号，基本上就是现代 IDE 能做的所有事情。我们一直在努力让这些模型能够使用这些工具。这大大提高了性能，对吧？
因为人类通常搜索东西的方式是四处点击，跳转到定义，阅读代码，诸如此类。但你可以用 IDE 中的工具更高效地搜索。如果你只是让模型做一个暴力的语义搜索然后从中得到答案，我觉得效果肯定不如能够使用这些工具的 AI Agent 好。
五、模型训练在未来会是一种外包服务
Swyx：接下来我们来快速聊聊你对 LLM 一些话题的看法，首先是 HumanEval，这是目前评估代码模型的主要方法，因为 OpenAI 用这种方式来评估代码模型。不过这种方法也有一些问题。
Aman：是啊。对于开源模型，甚至可能对一些闭源模型来说，我们不清楚有多少内容其实已经泄露到训练集里了。比如最近的模型，看起来就有一些数据泄露，这就解释了它为什么表现得那么好。不过，我觉得 Palm 2 采取了一个有趣的方法，我觉得现在有人完全可以尝试一下。有一篇叫 BabelCode 的论文，他们有一个库，我觉得可以把 HumanEval 直接翻译成所有其他编程语言。这会是一个很好的测试。
因为另一个问题是，很多在 HumanEval 上表现很好的模型都是纯 Python 的，对吧？这并不能真正反映它是否是一个全面的好的编程模型。所以我觉得，如果有人能做这个工作，运行 BabelCode 引擎，把 HumanEval 翻译成所有其他语言，然后能够运行它，那会很有帮助。我觉得这可能是个更好的基准测试。不过，如果原始的 HumanEval 问题泄露了，我猜它对解决翻译成其他语言的问题也会有帮助。但问题是，它太容易运行了，而其他任何方法可能都会很麻烦。
Swyx：没错。如果有个沙盒环境来运行它就更好了。
Alessio：你推特上的另外一个观点：未来，AI 模型的训练可能会变成一种专业化的服务，研究人员会将需要大量计算资源的训练任务交给专门做这个的公司来完成，而不是自己进行。这种状况很像芯片设计和制造。
Swyx：你怎么看这个观点？
Alessio：显然，刚刚在播客上出现过的 MosaicML 已经被收购了。
注：2023 年 6 月，Databricks 13 亿美元买下 MosaicML。
Swyx：你在 2022 年 5 月发了那条推特，一年后 MosaicML 就被收购了。
Aman：我可能在很多方面都错了，因为我当时以为未来会是很多创业公司都有自己的模型。这是我带着 CAD 思维在想，当时看 GPT-3，它就是 GPT-3，可能有点 3.5 的味道。它还不是一个那么好的通用模型。我觉得提示工程不是正确的方向，应该完全是微调或训练自己的模型。那时候我们也看到了很多早期的开源训练模型的尝试，结果证明并不是很成功。
关键的区别是，现在有一些超大的基础模型公司。我觉得大多数 AI 产品公司不会主要去训练自己的模型或者主要使用定制模型。更可能的情况是，他们会直接使用这些现成的 API。然后可能会用一下那里的微调接口。
Swyx：所以你的想法有点改变了。
Aman：是的，我确实改变了一些想法。我之前像考虑 CAD 那样，觉得需要一个 CAD 的基础模型。
Swyx：不，那是老思路了。
Aman：对啊。现在就是你有一个通用模型。一个“上帝模型”。这个“上帝模型”在所有方面都能出色地迁移。
Swyx：你还有另一个观点，我很喜欢。GitHub 公共仓库的所有代码历史大小是 92TB。而 Google 的单一代码库是 86TB，而且是质量更高的代码。如果 Google 愿意部署用自己数据训练的代码模型，他们会比其他所有人都有明显的优势。
Aman：这又是一个我觉得可能有点错的地方。因为这是基于 big science 那篇论文的。那篇论文基本上说他们抓取了 GitHub 的所有内容，得到了 92TB。但我仔细看了一下，是在一些人指出了一些错误之后，我觉得 GitHub 实际上比这个大得多。big science 的论文说他们用了 git clone。所以我就假设，好吧，git clone 意味着你得到完整的工作树，对吧？但如果你深入看，GitHub 可能比人们想象的大得多。我估计 GitHub 可能有 5 到 10 万亿个 token 的可用代码。这比他们最后得到的要多得多。不过是的，Google 仍然有相当大的一部分。
Swyx：他们刚刚推出了 Project IDX，某种程度上是个竞争对手。
Aman：我觉得它更像是，看起来更像是 replit 那样的竞争对手，是一个浏览器内的东西。但是，我觉得很多人都可以被视为竞争对手。
六、Agent 才是未来
Alessio：好的，让我们进入快问快答环节。有三个问题要问你。第一个是，在AI领域已经发生的事情中，有什么是你原本以为会花更长时间才能实现的？
Aman：我觉得是代码。具体来说，就是在代码方面的通用能力。之前你有这些专门的模型，对吧？比如 Codex 就是专门为代码设计的。然后还有通用语言模型，但现在是能力的统一，朝着一个不仅擅长文本，而且在代码方面也很出色的模型发展。我没想到通用模型会来得这么快，而且在代码方面表现得这么好。
Swyx：这就是为什么你转向或者说创立了你的整个公司。你认为AI中最有趣的未解决问题是什么？
Aman：我真的认为是长期记忆这块。我觉得可能会出现超人类水平的 AGI 系统，它们仍然使用类似 transformer 的东西来处理记忆。但更优雅的方式是，如何让模型真正持续学习？某种基于循环的系统可能能做到这一点，它有一个状态。但现在，模型只能在上下文中非常高效地学习。微调效率极低，需要大量数据点才能真正学习新东西。所以，我真的很想看看我们如何解决这个终身学习效率的问题。
Swyx：是的。我对使用知识图谱来做这件事很感兴趣，因为我觉得这是拼图中被遗忘的一块。如果你能让模型更新自己的知识图谱并查询自己的知识图谱，那可能就是解决方案了。我觉得 LlamaIndex 基本上正在朝这个方向发展。
Aman：是啊。还有一些技术，模型直接学习如何在权重内部或架构内部读取数据库，以及基于检索的技术，比如 RETRO 技术。这些看起来很有趣，但令人惊讶的是，自从最初的论文之后，就没有真正看到这方面的任何进展了。
Alessio：你希望大家在继续构建和探索 AI 时记住什么？
Aman：GPT-4 已经出来几个月了，很快我们可能会有更好的模型。那时候，世界会是什么样？特别是对编程来说，如果有像从 GPT-3 到 GPT-4 这样的重大进步，世界又会怎样？我觉得会有翻天覆地的变化，编写软件的方式将被彻底改变。
Swyx：那会朝哪个方向发展呢？我之前提到过，觉得 4.5 版本可能会在推理速度上有所提升，不过我也不确定，只是猜测。
Aman：我觉得未来的方向是语言模型在复杂推理方面会更强，它们能解决更难的问题，可能也会更好地理解软件工程中的各种细节，还会有更长的上下文记忆能力。所以，我预计未来会有更多像 agent 这样的东西出现。我不确定 4.0 级别的模型能在代理上走多远，但 4.5 或 5.0 级别的模型可能几乎能处理任何类型的编码任务，至少是合理范围内的。
Swyx：Agent 就是未来。
