这是我与 Zed 的三位联合创始人 Nathan、Max 和 Antonio 的第五次对话。你可以在此处阅读之前的对话。
这次我不得不谈论房间里的大象：人工智能。我想知道每位创始人是如何开始使用人工智能的，他们今天如何使用它，以及他们希望如何使用它。我们还讨论了 Zed 中人工智能功能当前实现的细节，以及今年 Zed 在人工智能方面将带来什么。我也不得不问：在人工智能时代构建编辑器，难道不是忽视时代的迹象吗？
以下是一小时对话的编辑稿。我尽量保留意图和含义，同时删除了深入对话中常见的“嗯”、“比如”、“你知道”以及停顿和修正。
（你可以在我们的 YouTube 频道观看完整对话。）
Thorsten：你第一次将 AI 用于编程是什么时候？你还记得吗？
Nathan：我用得相当早。我认为我第一次真正大开眼界的经历是 ChatGPT 刚推出时，用它做一些非常基本的事情。我想我用它定义了几何，比如一个几何库，只是为了好玩。我被它能做这些非常基本的事情惊呆了，比如定义一个点、一个圆、一个面积函数，以及它当时所做的一切。从那时起，事情变得复杂多了，但那对我来说是一个令人震惊的时刻。
Thorsten：是令人震惊还是你持怀疑态度？
Nathan：令人震惊。我不明白为什么这么多程序员对人工智能普遍抱有仇恨和怀疑。
我记得在大学时，我学习自然语言处理，毕业后立即为我的教授工作。他是 SRI 负责经典人工智能的负责人，Jerry Hobbs。我记得我曾多么着迷于“意义是什么？语言是什么？它是如何工作的？”这样的想法，并研究这些组合的、范畴语法机制，比如我们将语法定义为这种定向的 lambda 演算形式。你知道，我对所有这些都非常好奇和着迷，但同时也感到沮丧，因为当时……语言模型是有史以来最笨的东西。它基于词元频率之类的东西，你根本无法从中获得任何东西。
所以，我可以坐在那里，用英语要求它做任何事情，并且它能做任何事情，这对我来说简直是惊天动地。就在那时，就在那里。这太棒了。这是一个我从未预料到会变得如此好的奇迹。所以为什么不是每个人都对我们世界上存在的事实感到震惊，这超出了我的理解。我就是不明白。我有点生气，人们对此如此如此狭隘。就像，是的，你把一辆兰博基尼开进了我的车道，但我不喜欢它的颜色。
这只是对消极和错误之处的执着，以及它不能做什么，而不是对它能做什么感到惊讶和震惊。我想这只是我与那些人之间的个性差异。我总是看到事情好的一面，我总是看到令人兴奋的地方。现在，我从未购买过任何 NFT，对吧？明确地说。所以我明白，在技术领域，我们有这些炒作周期，这可能会让人有点筋疲力尽，你会对最新的炒作周期翻白眼，而你 Twitter 时间线上的人们则用大写字母谈论这如何改变一切，如何具有颠覆性。但我认为在这种情况下，我们拥有这项技术真是太棒了。好了，我不抱怨了。
Thorsten：你提到自然语言处理很有趣，因为我来自另一个领域。我学习哲学，研究语言哲学。当 ChatGPT 问世时，每个人都说它不“理解”。我坐在那里想：到底“理解”意味着什么？你是如何理解事物的？意义是什么？所以，我站在另一边，也认为事情没那么简单，这非常引人入胜。
Antonio：我紧随其后就使用了 ChatGPT —— 我不知道，我想是 Nathan 促使我们使用的。我不是 AI 怀疑论者或什么的 —— 我很惊讶，我也将 AI 用于非编码任务 —— 但我从未有过大开眼界的经历，我不知道。
我每天都在做的事情，也就是我每天写好几个小时的代码，而且是用 Rust 编写的，在一个相当复杂的代码库中。所以，我最初的使用场景就是尝试在我们的代码库中使用它。但每次我尝试这样做时，总会遇到一些阻力。
不过，我真正喜欢并且认为它真正出彩的一点是，当涉及到生成复杂的代码片段时。基本上，代码中存在某些模式，对吧？但你无法真正通过正则表达式或使用Cmd-D来设置多光标来表达这些模式，但 AI 却非常擅长。你可以直接说“好的，我想将这个重构应用于这五个函数”，我可以以一种无法通过任何工具（比如正则表达式）解释的方式来解释它。这里有很多有趣的可能性。
Thorsten：听起来有点失望的时刻。
Antonio：是的。我不知道这个东西是不是还没见过足够的 Rust 代码。也许这是一个问题。但可能也存在我们如何与它整合的问题，对吧？我们没有给它足够的上下文。我认为仅仅给它正确的...我最近才开始学习的一件事是，构建上下文至关重要。
你真的需要正确地表达它。机器确实需要理解你想做什么。尤其是在一个复杂的代码库中，你的大脑里有大约 50 个引用，但机器不可能知道这一点。它怎么可能知道呢？所以，是的，我失望的一部分只是与 AI 的集成，而不是工具本身，而是像，
Nathan：我们还没到那一步，是的。
Max：是的，在 Zed 代码库中使用 Copilot —— 我有时仍然这样做，但我不会称之为我的游戏规则改变者 —— 和使用一些 JavaScript 脚本的区别很大，后者是一个单独的文件，所有上下文都在那里，脚本的作用是通过减少步骤来最小化随机测试失败，或者它需要读取一堆文件并调用一些 shell 命令等。在后一种情况下，单个 JavaScript 文件，Copilot 简直是表现出色。
因此，如果能让它在我们日常工作中，当我们处理一个数十万行的代码库时，也能表现得如此出色，那将有巨大的潜力。
Thorsten：那是我在使用聊天助手时在我们的代码库中注意到的。我经常想，“哦，如果你能看到内联提示，如果你能看到类型，你就不会给我这个答案了。”但，是的，集成。
Nathan：那又是我们的失败。我用它最成功的时候，是当我将模型训练数据中已经存在的东西整合在一起的时候。我喜欢那种模式。
GPUI2 的渲染器大部分是我在助手面板中纯粹通过说“哟，我需要一个能与 Metal API 集成的渲染器。它用 Rust 编写”来完成的。它并不完美，但比我配置所有这些图形管道等要快得多。这不是我做过很多的事情。
我喜欢从这些模型的潜在空间中提取我需要的东西，我提供了一些参数，但大部分都在权重中。但我正在引导权重中的内容，以期给我一种“StackOverflow-on-acid”类型的东西，即知识在那里。我只是需要它以某种形状呈现，并且我希望引导它。
所以这个周末我在浴缸里玩 Claude，对吧？我真的写了一个完整的文件索引，它使用了无锁映射来存储文件路径，解释了来自文件系统事件 API 的所有文件系统事件。它异步地做了所有事情。你知道，我为它写了随机测试，有一个伪文件系统实现，而我当时在浴缸里，对，用我的手机。我没有一刻在写大括号。现在，我从未运行过它生成的东西，但我用我的眼睛审阅了它，虽然它可能这里或那里有一些问题，但这东西写出的实现非常合法，而这东西花了 Antonio、Max 和我几天，日日夜夜的持续投入才完成。我以前解决过这个问题的知识帮助我指导它，但我不知道，它几乎以某种方式改变了你能快速完成事情的规模。
然后有时它就会在最简单的事情上完全失败。
Thorsten：ChatGPT 是 2022 年 11 月发布的，对吧？那时我们都应该买英伟达股票了。从那时起，你是否调整了对 AI 的使用方式？例如，使用 Copilot 的人说他们会适应它，并留下一些注释来引导 Copilot。或者你们中有人曾深入研究过提示工程吗？或者在弄清楚它能做什么和不能做什么之后，你们减少了使用它的频率吗？
Nathan：说实话，我不太用 Copilot。我觉得它很烦人，总是在我眼前晃。我以前也从来不喜欢自动运行保存时的测试。我总是只想……我不知道。我更喜欢以聊天模式与 AI 互动。所以我真的很期待我们将投入时间，更深入地研究那个上下文窗口。
我只是觉得 Copilot 有点笨。我不知道。因为他们必须能够在每次按键时调用它，所以他们必须使用一个更笨的模型。所以我想我更喜欢使用一个更聪明的模型，但更审慎地使用它。但我并不执着于这种观点。我想也许 Copilot 上的一些用户体验调整可能会改变我的关系，但我不知道。我想我一直愿意使用它，甚至有时为了投入和学习如何使用它，我的互动会更慢或效率更低。
是的，当时它在某些非常困难的事情上帮了我大忙，比如编写一个过程宏来枚举 GPUI 的所有 Tailwind 类。它教会了我如何编写过程宏，因为我以前不知道怎么写。
Thorsten：就在一年前，我参加了一个会议，遇到了程序员朋友们，我们都在谈论 ChatGPT，其中一些人说：“哦，它什么都不知道。我刚试过，它什么都不知道。”但他们使用的查询或提示，看起来就像人们 20 年前使用 Google 时的提示。那时你仍然使用关键词搜索，人们会输入“我能在哪里买到热狗？”但当时并不是这样工作的。不过，我的一位朋友说：“你知道我用它来做什么吗？我把它当成助手。我把它当成实习生。”所以本质上，当他调试一些东西需要一个小程序来重现 bug 时，他会告诉 AI：“你能给我写一个不设置连接超时的 HTTP 服务器吗？”或者类似的话。因为他知道缺点在哪里。我想我们很多人在过去一年里都有过这种经历，我们开始感受到缺点在哪里，并调整我们的使用方式以适应它。所以我很好奇你们是否有过这些时刻。
Max：我每天都在用。我经常用 ChatGPT 而不是 Google。我已经学会说，“现在，不要用‘这取决于’来推诿。我知道。直接告诉我答案”，这样 ChatGPT 就不会说，“对此有许多可能的回复。”
但我认为在编程世界中我还有很多东西要学。可能有很多知识我还没有融入我的工作流程中，用于提示助手。
Nathan：我想我的优势在于，我不如 Max 或 Antonio 那样擅长纯粹的编程。很多时候，当我与人结对编程时，我更多地扮演导航者的角色。所以我更多地求助于 AI，因为我写代码的速度没那么快。所以我觉得这对我来说挫败感更小。
Thorsten：你们是什么时候决定“我们必须把这个功能添加到 Zed”的？是因为被炒作和所有人的要求所席卷，还是有某个特定的事情或时刻，让你们说“不，我需要在编辑器中加入这个功能”？
Nathan：对我来说，有 Copilot，然后是助手。所以 Copilot，每个人都要求它。我就想，“哦，我想看看用它是什么感觉”。但后来我发现我用得不多。但对于另一个，助手，只是我当时在使用 GPT4，他们对我的请求进行了速率限制。然后我就进入 SDK 或游乐场，在 freaking 网页浏览器里写文本。我就想，这快把我逼疯了。我想在 Zed 里写文本。
我的意思是，这就是助手目前的样子。它有点简陋。它就像一个 API，就像一个 OpenAI API 请求编辑器，一个从文本编辑角度来说不烦人的编辑器。这就是目前的情况，它不会停留在那里。我们还有很多工作要做，但这就是思维过程。
Thorsten：我有点想深入探讨一下，问问你关于 Zed 中的内联辅助。给所有正在观看、收听或阅读的人提供上下文：你可以在 Zed 中选择文本，然后按下 ctrl-enter，你就可以将消息连同选定的文本和更多上下文发送给 AI，你可以要求它“更改此函数的返回类型”或“重新排序”或“使用宏”之类的。然后当 AI 返回请求时，你可以看到它输入文本或更改文本，并且你可以看到它逐字更改。它看起来不像只是将文本塞进缓冲区。所以我很好奇，当 LLM 请求返回并说“这是一个代码片段”时，会发生什么？
Antonio：基本上，我们实现了一个自定义版本的 Needleman-Wunsch 算法。有几种模糊查找算法，它们都源于这种动态规划算法，其本质是找到从 A 点（源头，即两个字符串的起点）到终点（即两个字符串的终点）的最低成本路径。所以我们正在做这种差异化，即流式差异化，因为通常差异化是一个有损函数，你需要完全拥有两个文本，但问题是 AI 是逐块流式传输响应的。但我们不想等到整个响应返回后再进行差异化。所以我们有一种略微修改过的 Needleman 版本，其中我们倾向于插入和删除，我们有点向前看，并有一个不同的成本函数。这使我们能够生成这些流式编辑。这是一个非常有趣的项目。
Thorsten：那么你是专门为内联辅助构建它的吗？我以为它也用于协作功能，不是吗？
Antonio：不。我们最初尝试的是让 AI 使用函数调用来给我们提供编辑，而不是要求一个响应，然后 AI 从头到尾地吐出来。最初的尝试是“好的，只需给我们精确的编辑，你知道，你希望我们应用”。但我们很早就发现它工作不可靠。让它生成精确的位置有点棘手。
它非常善于理解你作为一个整体想做什么，但要让它说“好的，在第三行，第二列，我想插入、删除五个字符并插入其他六个字符”是非常困难的。
所以我们重新审视了方案，我们说它擅长输出文本，所以就让它写你想要的东西，这就是 Nathan 的想法。
Nathan：Antonio 的算法能力也确实让它实现了。是的。
Thorsten：怎么样，它相当可靠，对吧？
Antonio：谢谢。是的。
Nathan：它有时会过度绘制。它……我不知道。对我来说并不总是可靠。我想这可能与我们的提示有关。这里有很多探索要做。我会要求它为函数编写文档，它会重写函数。这让我抓狂。
Thorsten：提示，当然，但实际的文本插入——每次我看到这些词语亮起来，我就会想，这里发生了什么？他们是怎么做到的？实现这个花了多长时间？我很好奇。
Antonio：半天。是的，我记得一天。是的，差不多。
Thorsten：不可能。
Nathan：但公平地说，我们已经做了很多探索，只需要一点点路径匹配的推动。这花了一些时间来理解它。我想更多的是 Antonio 坚持了下来，这么说吧。
Antonio：哈哈哈！
Nathan：因为，是的，遍历那个动态规划矩阵仍然让我有点困惑
Thorsten：半天——你可以说一周，这样我会感觉好一些。
Antonio：一周，是的，一周，不。
Max：哈哈哈。
Thorsten：所以现在在 Zed 中我们有内联辅助，我们有聊天助手，你可以用它来写 Markdown，并且你可以与多个模型对话。接下来是什么？路线图上有什么？
Nathan：一个重要部分是让助手看到更多上下文。将其从 API 客户端过渡到开始拉入更多上下文。Kyle，他一直与我们合作，有一个分支，我们正在拉入当前文件。显然，我们想要更多拉入上下文的机制，不仅是当前文件，还有所有打开的文件，你可以调整上下文，选择加入或退出，等等。
但也要进行工具调用，我可以与助手对话，让它帮助我构建我的上下文，如果这有意义的话。还可以让它与语言服务器交互，但也要使用 tree-sitter 来遍历我们正在拉入的文件的依赖项，以确保我们将所有这些都放入上下文窗口中。当然，上下文大小已经大大增加，这使得所有这些都变得容易得多，因为我们可以更贪婪地拉入内容。
所以这是一个很大的维度，更智能地填充上下文窗口，同时还为助手提供工具调用，它可以用来在终端中编写命令。我不知道我是否想让它能够按 Enter 键，你知道，但至少可以写进去并暂存它，并将我的注意力转移到那里，以便我可以运行一些东西。我可以获得我可能想要运行的任何随机 bash 咒语的帮助。让助手走出那个小盒子，伸出手与编辑器的其他部分交互。
这都是一些非常容易实现的功能。我认为我们需要去实现。这就是我接下来的工作。然后我们也在尝试其他完成提供程序，以实现 Copilot 式的体验。看看会怎么样。目前还处于早期阶段。
Max：我对功能集的另一个维度感到兴奋。现在，我们刚刚谈论的所有东西，那个系统非常本地化。你选择一个代码块，它的输出直接指向那个位置。
但是能够像 Zed 中的代码操作一样，说“将此函数内联到所有调用者中”，然后打开一个多缓冲区，显示“我在这里更改了，我在这里更改了，我在这里更改了。您想保存还是撤消？”然后我就可以查看它做了什么。
我希望能够说，“从这个 crate 中提取一个不在这个 crate 中，而是在一个子 crate 中的结构体，并在所有使用这个 crate 的地方依赖它，这样它们就不必依赖所有其他东西”，然后它就会说，“你看，我更改了你的 Cargo.toml，我创建了一个 crate，我更改了它，我对你的代码库中的各种代码片段进行了这些更复杂的转换。你想保存还是撤消？”
我认为这将是一种非常强大的方式，让它做更多的事情，同时保持控制。我认为多缓冲区是与用户互动并询问“您想应用我刚刚进行的所有这些转换吗？”的好方法。
Nathan：说到多缓冲区，另一个非常容易实现的功能是在多个选择上并行调用模型。当我打开一个满是编译错误的缓冲区，而这些错误基本上都是我需要做的相同的愚蠢操作时，能够并行地对每个错误应用 LLM 提示符将是很棒的。
Thorsten：唾手可得的成果无处不在——你基本上可以为每个文本输入添加 AI，增加自动补全或生成等功能。上周有一个例子，我与某人讨论了如何在项目搜索输入中使用 LLM 来为你生成正则表达式。这很酷，但同时我想，难道更好的步骤不是使用合适的关键词搜索，而不是让 LLM 翻译成正则表达式吗？我想知道，是不是存在一种可能性，为了追求唾手可得的成果，反而会陷入局部最优解？
Max：意思是，我们到底想保留多少当前的编程工具范式，比如正则表达式搜索？或者我们认为我们甚至不再需要那个功能了？
Thorsten：大概是这样，是的。一年前，每个人都在每个领域添加 AI，显然情况发生了变化，人们现在说，“这不是一个好的用例”，而你现在也说你希望它能够访问文件等等。你是怎么看待的？你认为下一个重要的里程碑是什么？
Nathan：嗯，我想我看法不同。我对此想回应几点。一是我们去年夏天尝试了语义搜索，最初的做法是，我们使用 OpenAI 的嵌入 API 生成所有这些嵌入，该 API 专为文本和散文设计。我认为代码方面较少，至少我是这么理解的，也许人们可以在 YouTube 视频上评论并告诉我我错了。所以，我不知道嵌入模型对代码来说总体上有多好，但我确实发现，通过这个初步实验，你可以直接开始输入你的查询，我们会向你展示匹配的文件或者文件和行号。我大量使用它进行导航，因为能够快速输入键真的很实用。
它比模糊查找器和cmd-t（语言服务器上的符号搜索）都好。因为至少对于我们代码库上的rust-analyzer来说，那可能会非常慢。所以我把它当作一个快速方便的导航工具。
但后来我并没有深度参与，我们将那个原型模态体验转变为我们搜索的一个功能。然后我就停止使用它，因为使用它的摩擦力太高了。而且我们当时得到的结果质量，至少那时候，还不够高。我想回到那种使用语义快速跳转到不同区域的模态模糊导航体验。但它不像搜索结果，不太像，它更像是一种快速的东西。所以这是一件事。
但我想说的另一点是，我对……我以前对人工智能总体上是持怀疑态度的，直到我被证明是错的。所以我想谨慎地对可能发生的事情保持谦逊。但总的来说，我现在的情况是，我真的仍然想知道发生了什么。我不希望很多事情在我不知情的情况下在幕后发生，比如它编写了一个正则表达式然后运行它，因为我没有足够的信心它会运行良好。
所以，在我获得那种信心之前，我喜欢这种非常可见的混合体验。AI 正在帮助我使用算法化的传统工具。即使 OpenAI 也有代码解释器，对吧？他们并没有试图让 LLM 进行数字加法。他们只是调用 Python。所以我想让 AI 访问这些更算法化的传统工具是我想去做的方向。
Thorsten：你对上下文窗口有什么想法吗？当你有一个很大的上下文窗口时，你会认为所有问题都解决了，对吧？只需把整个代码库塞进去。但这样你也需要上传大量代码，而且响应回来需要更长的时间。你对上下文大小和延迟之间的权衡有什么想法吗？
Nathan：我仍在努力理解为什么上下文大小增大时会导致额外的延迟。在我的 Transformer 心理模型中，我不明白为什么会花更长时间，但我实际上可以看到它确实如此。所以，是的，我想，我在这里暴露了我的无知。
但在我看来，给它所有东西可能会给它太多，从而让它感到困惑。尽管我的理解是，这也在改善，它们现在对噪音和大海捞针问题不那么困惑了。这就是我从 Gemini 那里看到的，我还在等待获得我的 API 访问权限。但我看到的是，它非常擅长从大量的垃圾中挑选出重要的细节。
我不知道，这不是一个非常连贯的想法，只是在我看来，我们需要再考虑一段时间如何策划上下文。而且我与模型互动最成功的时候，要么是我再次从模型的权重、潜在空间中汲取灵感，因为我正在解决的问题在某种程度上是已知的，所以在上下文窗口中几乎不需要什么。要么是我用它需要成功的特定事物来设置它。
但公平地说，我认为我们在这个领域还有很多要学习的地方。是的。
Thorsten：我问这个是因为你说你曾经在触手可及的情况下使用模糊搜索，但一旦摩擦力稍大一些，你就停止使用了。我注意到，说到大上下文窗口，有时我等 ChatGPT 都会不耐烦。“快点，跳过介绍，给我干货。”有了大上下文窗口，我不知道我是否会宁愿放弃提问，因为我知道答案需要 20 秒，或者 10 秒，或者其他什么时间才能回来。
Nathan：是的，我想延迟越高，我对它的回复期望就越高。我的意思是，我在浴缸里玩得很开心，等着 Claude 回复。我深吸了一口气，感受着身体上的温水，你知道，然后等到它回复的时候，我就只是在看。
Thorsten：我想你应该用一个对照组重新做一次这个实验，他们也在浴缸里写代码，但没有 AI。也许结果是一样的。听起来像一个很棒的浴缸。让我问一些有争议的问题……当我告诉人们我要加入 Zed 时，他们问我：“哦，一个文本编辑器？两年后我们还需要写代码吗？有了 AI？”你对此有什么看法？你认为五年后我们还会把程序语言语法输入到 Zed 中吗？或者你认为我们的编程方式会发生根本性的改变？
Nathan：是的，这是一个好问题。我的意思是，我曾在推特上说过，人工智能能够为我编写代码编辑器，我就不需要代码编辑器了，这有点讽刺。但到目前为止，还不可能坐下来就说，给我用 Rust 编写一个带有 GPU 加速图形的代码编辑器。我不知道。我认为人工智能还没有达到那个水平。
现在也许这是唯一足够复杂的产品。也许人工智能唯一不能构建的就是代码编辑器，但我现在对此持怀疑态度。也许 Ray Kurzweil 是对的，我们都会把我们的大脑上传到云端，我只是不知道。我只知道事情变化很快，但目前看起来真实的是，至少我将需要监督访问，就像那个Devon 演示。
对我来说，一个潜在的结果是，编辑代码在一段时间内会感觉像 Devon 演示那样，但拥有一个出色的用户体验，让程序员参与到循环中，指导这个过程，这样我们就不会只是用暴力尝试来滥发 LLM。相反，LLM 会获取访问权限，人类参与其中并纠正或指导它，形成一个反馈循环。是的，所以它变成了人与 LLM 的协作，但人类仍然参与其中。
如果最终事实并非如此，是的，我想我们就不再需要代码编辑器了。我不知道那离我们有多远，如果它会到来。
他们告诉我很久很久了，我将乘坐这些自动驾驶出租车，我已经乘坐了几次。但我要说，出租车拒绝停在我们旧金山实际所在的位置。所以我们不得不冒着倾盆大雨走到他们接我们的地方。我简直惊呆了，一辆车竟然自动驾驶我，接我并载我到别处，同时，我有点恼火，我正在雨中走到它停下来的地方。感觉就像 LLM 也会发生同样的事情，对吧？
谁知道会发生什么，但目前，我喜欢创造软件。我不需要自己敲出代码，但我确实觉得我希望能更多地参与其中，而不是仅仅坐在一个谷歌搜索框前说，去成为一个代码编辑器。
Max：我仍然看好代码将在相当长一段时间内继续存在。我认为这回到了 Nathan 说的，AI 扩展了你可以在更短时间内构建的事物的集合，它让探索更广阔的创意空间变得更容易，因为它成本更低。
我想有些代码将不再是任何人的工作，但无论如何，那都是无聊的代码。
但我认为它只是让更多的代码成为可能，因为它维护成本更低，创建成本更低，如果我们想要新版本，重写成本也更低。会有各种以前不可能的事情。比如现在，银行无法提供好的网站，我想总有一天银行会拥有好的网站。会有一些软件，无论出于何种原因，目前无法交付。它最终将变得可行。我认为这将是代码，而且我仍然会想偶尔看看它。
Nathan：是的，这真是对人类动机的力量和银行体系腐败的绝佳评论，银行拥有一个好的网站，这就像我们在实现 AGI 之前的那一天。
Max：哈哈哈哈。
Antonio：如果你现在看 Twitter，感觉每条帖子都在说 AGI 下个月就要出来了。我不知道。我真的不知道。对我来说，诚实的答案是我不知道。这是可能的。这就是 AI 让我恼火的一点，就是有些东西是如此不透明。
过去，对于一般的技术，如果遇到难题或复杂事物，我至少可以坐下来尝试理解它们，甚至可能创造它们。而对于人工智能，除非你想用 ChatGPT 或 Claude 做点什么，否则你必须花费数百万美元。那部分，我不太喜欢。
这就是我疑虑的来源，因为这些公司的工程师和研究人员很可能已经达到了 AGI，已经拥有了超人类智能，但其中有多少是炒作？我不知道。
Thorsten：这里有一个问题，我很想听听你们的想法。我经常使用 ChatGPT 来处理编程中的“杂务”，比如一些 CSS 样式或 JavaScript，或者我用它来为我生成一个 Python 脚本来与 Google API 对话，这为我省去了整整一天的头痛和试图找出 OAuth 令牌放在哪里的麻烦。但对于低级编程，比如异步 Rust，你可以看到它开始崩溃。你可以看到这件相对容易的事情对于 AI 来说，而那件事，有些东西发生了。我想知道的是，这是一个规模的问题吗？它只是看到了更多的 JavaScript 吗？它比系统 Rust 代码看到了更多的 HTML 吗，因为它抓取了整个互联网？
Max：我认为解决那些已经被解决很多次，只需要稍微调整一下的问题——我认为这很棒，它就是这样工作的。那些是无聊的事情，因为它们已经被解决很多次了，我认为 LLM 非常擅长解决这些问题。而我们做的一些事情，虽然已经被解决——我不会说我们每天都在做前所未有的事情——但我们日常做的很多事情，在世界上并没有被解决那么多次。这很有趣。这就是我喜欢做它的原因。所以我并不沮丧 LLM 不能完全为我做到。但当我做那些超级标准的事情时，我喜欢 LLM 能够直接完成它，直接解决它。
Nathan：我希望 LLM 尽可能多地为我做事情。但是的，我确实认为它没有看到很多 Rust 代码。我的意思是，我与该领域的人聊过，他们只是这样说了。他们很兴奋，“哦，你要开源 Zed？我很高兴能获得更多 Rust 训练数据。”我就想，“我也是”，除了，你知道，竞争对手只是坐下来，说“给我构建一个快速的代码编辑器”，然后它已经学会了如何做，所有这些工作都付诸东流。我不知道。
但如果那是真的，最终我只是对推动人类进步的状态感到兴奋。所以如果我正在做的事情最终变得无关紧要，也许我应该去做别的事情。我的意思是，那会令人失望，我希望成功……反正，我不知道我是怎么跑题的。
但用它来写 Python，我不想写但又需要写，因为我想查看帧时间直方图并比较它们？谢谢。我根本没兴趣写那个，它做得很好，我很满意。
Antonio：还有一个元观点，我想我们没有真正讨论过。即使在一个人工智能可以生成代码编辑器的世界里，在某个时候你还是要决定这个功能应该如何工作？我想人工智能可以帮助你，但我想会有人指导它，理解需求是什么，以及你到底想做什么，对吧？
也许那也会在某个时候被 AGI 消除，但我不知道。归根结底，代码只是思想的表达，是的，以及公司或一群人内部的知识。
我对 AI 在协作方面的应用感到兴奋。我认为这将是 Zed 作为协作平台的一个非常好的角度。
我们已经讨论过查询 tree-sitter 以获取特定函数或语言服务器以获取引用，这些都是你可以提供给 AI 的上下文。但所有发生的对话呢？就像回到我们之前的采访——如果代码是所有对话的精炼版本是真的，那么这对 AI 帮助你编写代码来说是很好的上下文。
Nathan：我们可以用语音转文本模型捕捉这些上下文，或者进行多模态操作。
我的真正梦想是创建一个 Max 或 Antonio 的 AI 模拟——GPtonio，你知道吗？我喜欢和他们一起编码，因为它让我在很多时候可以停留在更高的抽象层次。我不知道，也许我只是懒惰。我应该多打字，但有时我觉得当我打字时，我碍事了什么的。我就是喜欢结对编程，我喜欢成为那个导航者并参与其中。所以一个可以和我对话并边对话边写代码，听到我说什么的多种模式的模型。我也可以在那里时不时地打字。那会很棒。但这和协作不是一回事。
但它会从观察我们协作中学习。这是我的主要观点。你知道，是的。
Thorsten：你可以根据 Antonio 过去一年所做的所有编辑，以及所有对话来训练 AI。
Antonio：没错，为什么会进行这些编辑？原因是什么？为什么这样做比那样做更好？什么是内部知识，那些没有写下来的隐性知识？我们拥有它只是因为共享的上下文。只是与 AI 共享那个上下文。
Nathan：我们刚开始做 Zed 的时候，一直有个想法，就是如果能把光标放到一个字符上，然后说，给我看看这个字符是如何被写出来的，那该多酷。这个想法是，所有这些代码都与所有这些对话和上下文紧密相连，我们可以存储它并使其易于访问。但即使是那种模式，也需要梳理很多东西，对吧？所以，拥有一种工具，能够很好地提炼这些信息并以智能的方式呈现出来，那将是惊人的。对于协作来说，这是一个非常令人兴奋的发展，以一种新的方式将所有这些我们可能捕捉到但尚未真正捕捉到的数据带到我们指尖。
Thorsten：最后一个问题，展望未来。你知道安迪·沃霍尔对可口可乐的评价吗？他说总统喝的可口可乐和你喝的可口可乐是一样的，没有高级可口可乐和普通可口可乐之分，每个人都得到一样的。对我来说，编程也是如此。我可以在线与世界上最优秀的人一起写代码，它在 GitHub 上看起来一模一样。我的头像在他们的头像旁边。这是一个公平的竞争环境。我可以把我的网站放上去，它也是 thorstenball.com，就在大公司的网站旁边。没有独家俱乐部。我一直在想的是，你曾经只需要一台电脑就可以编程，甚至一台 Raspberry Pi 也足够了。但现在有了 AI 和 LLM，突然事情变得非常昂贵。要参与 AI 游戏，你需要很多钱，或者 GPU。你们考虑过这个问题吗？你们看到了这种转变，还是认为如果你想拥有一个数百万用户可扩展的网络服务，你一直都需要钱？
Antonio：也许只是因为我们技术上还没有达到那个水平，所以今天的硬件成本才这么高，对吧？在 CPU 领域，东西已经便宜了很多，现在有这么多 CPU。所以，我可以看到一个世界，东西因为变得如此便宜而成为商品。
Nathan：想想七十年代末，对吧？肯·汤普森和丹尼斯·里奇，用电传打印机在连接到我房间天花板上的一台 PDP11 上编写 Unix。对吧？谈论计算访问的民主化。那并不是一直都是这样。我们似乎曾处于一个时代，计算在很长一段时间内不再是创新的限制因素。但也许现在又回到了这种状态，谁知道它会走向何方。
Thorsten：太美了。很好。