# 造了20年编辑器的人说：AI写得越快，你越需要看得见代码的地方

> Training Data No. 73 中文精读

- 原标题：Why IDEs Won't Die in the Age of AI Coding: Zed Founder Nathan Sobo
- 发布日期：2025-12-02
- 主持：Sonya Huang · Pat Grady · Konstantine Buhler 等
- 网页版：https://trainingdata.qiaomu.ai/ep/073-why-ides-won-t-die-in-the-age-of-ai-coding-zed-founder-natha-nQP4Wt.html
- 精读字数：约 5454 字（阅读约 12 分钟）

> 本文为 trainingdata.qiaomu.ai 基于原始访谈的 AI 改写中文精读，非官方翻译；引用请注明出处并链接网页版。

2006年，Nathan Sobo 大学刚毕业，给自己定了一个目标：做一款心目中理想的代码编辑器。

这一做就是将近20年。中途他在 GitHub 做出了 Atom，顺手造出了 Electron，后来微软用同样的思路做出 VS Code，统治了整个行业。他自己则在2017年推倒重来，用 Rust 从零写 Zed，一个如今有17万左右活跃开发者的 IDE。

然后 AI 来了。所有人都在问同一个问题：终端里敲两句英文，agent 就能把活干了，IDE 是不是要死了？

在红杉资本播客 Training Data 的这期节目里，Sobo 给出了他的答案：**只要人还需要读代码，IDE 就死不了。而人需要读代码的时间，会比大多数人以为的长得多。**

## 代码是写给人看的

Sobo 不否认终端加 LLM 的威力。他自己也用 Claude Code，也知道外面有几百万人这么干活。让他受不了的是另一个环节：agent 干完活想给你看成果时，你只能隔着终端里十几行的摘要看它的改动。

想看更多？没门。想看这次改动牵扯到的上下游？自己开编辑器去。

所以他的推理很简单：如果 IDE 会死，前提是人不再需要看源代码。这件事在他看来根本不成立。**源代码和自然语言一样，是一门语言，是写给人看的。**他引用了 MIT 教授、《计算机程序的构造和解释》合著者 Harold Abelson 的话，这句他记了很多年：

> 「程序应当写给人读，只是顺便让机器执行。」

这话听着极端，程序写出来总归要跑。但 Sobo 认真对待了它背后的含义：程序的本质，是人用一种极其精确的方式表达某个抽象过程。而表达这类图灵完备的概念，没有比源代码更好的语言。

那最好的界面一定是图形界面吗？他的答案很务实。Vim 算不上 GUI，但 Vim 就是一个围绕源代码优化的界面：展示它、导航它、偶尔亲手改它。因为有时候，表达一个想法最清楚的方式，就是直接把代码写出来。你可以对 LLM 描述「我要一个带这四个字段的结构体」，但如果你已经清楚要表达什么，直接写代码往往更快。他没兴趣手搓重复劳动，能交给模型的他乐意交，可表达权还在自己手里。

他顺口补了一句观察：**那些在终端里重度 vibe coding（基本全靠 AI 生成代码）的人，多半旁边也开着一个编辑器，用来看 agent 到底干了什么。**

## Atom的教训：性能没法事后补

Sobo 对编辑器的执念有来历。2006年他毕业时，TextMate 正火，Rails 之父 DHH 演示框架用的就是它：轻、快、好上手。他试过 Emacs、Eclipse、JetBrains 全家桶，每家都有绝活，有的扩展性强，有的响应快，有的功能全，但没有一家把这些捏进同一个包。

他想要的东西很具体：最强 IDE 的能力，TextMate 的手感，外加不用像养宠物一样，每个周末喂养一份随时会坏的 Vim 配置。他说，Atom 就是在 Vim 里写出来的。

第一站是 Atom。他作为头两名工程师之一加入 GitHub 做这个项目，为了极致扩展性选了 Web 技术。做 Atom 时顺手造的那层外壳，就是后来的 Electron：把 Node.js 和 Chrome 拼在一起，让你能用网页技术做桌面应用。这个主意来自 GitHub 联合创始人 Chris Wanstrath。

结局大家都知道了。微软拿走这套思路，把自己现成的网页版代码搬上来，VS Code 统治了行业。

Atom 给他留下两条硬教训。一条是通用的：怎么设计数据结构，才能高效表示并编辑大段文本。另一条是血泪：**别让扩展代码跑在主线程上。**Atom 靠极度开放迅速走红，然后被自己过早许下的承诺淹没。

> 「我们被自己过早许下的承诺淹没了。」

还有一层是私人恩怨：他受够了 Web 技术。打开 Electron 的性能分析器，盯着火焰图里那些线条，他知道自己钻不进去，速度到顶了。

2017年，他决定推倒重来，理由听起来朴素：**性能这东西事后补不上，选了什么架构，就等于接受了什么性能上限。**Web 不是他要的地基。

## Zed的两个赌注：快，和把人拉回代码里

Zed 从第一天起就押了两件事。

第一件是快。按下一个键，像素要在显示器的下一次刷新里响应，零可感知延迟。他说还没做到百分之百，但已经比浏览器里能达成的近得多。技术上最核心的一招：**整个 Zed 的界面像游戏渲染3D世界那样，由 GPU 上的着色器画出来。**为此他甚至重写过整个图形后端。

第二件是协作方式。他在 GitHub 亲历了如今这套协作流程的流行：异步，各自在角落里干活，拍个快照传上去，别人在网页上留言，一小时或一天后你回复。他说这套邮件式的流程，适合 Linux 那种全球分工、各做各事的场景；大多数坐在同一页上的团队，最好的协作是实时待在代码里，能随时打断彼此，也把彼此当人看。

Zed 团队自己就很少做代码评审，有事直接在代码里实时聊。屏幕共享不行，因为总有一个人坐在副驾驶，按键要绕一圈才能生效。他想要的是 Figma 给设计师的那种东西：你待在创作工具里，看着正在造的东西，队友就在旁边。

这套旧执念，撞上了 AI 时代的新需求。现在所有人都开始「在代码里对话」，只是对话对象换成了 agent。问题来了：agent 改完代码，你给了反馈，这些反馈存在哪？

> 「这种东西，还没有一个对应的 Git。」

你不可能给 agent 吐出的每个 token 都做一次 commit，再走一遍 pull request 评审。所以 Zed 在做一套细粒度追踪机制，大致相当于每按一次键、agent 每写入一段编辑，就自动记一次「提交」，然后把对话直接锚在这些记录上。Sobo 承认 Zed 离完整愿景还很远，但这是他认定的方向。

这套执念也解释了 Zed 的用户画像。主持人按10万活跃用户估算，他纠正说大概17万，开源软件统计口径天然偏低。用户偏硬核，多是写了多年代码的老手。按他们的统计，**约一半用户在用 Zed 的编辑预测功能，约四分之一在用某种形式的 agent 编辑。**拥抱 AI 时有人跑到评论区骂街，他不在乎：「这事正在发生，我们不会掉头装看不见。」

为什么硬核用户爱 Zed？他的解释：开发者越老练，越在意工具在手上的反馈。一个天天十几个小时摸着的工具，掉帧、跟不上手，是会让人烦的。至于他女儿同学的妈妈，一位牙医，最近正在 vibe coding 自己诊所的管理软件，她知不知道自己需要一个手感好的编辑器？不知道。「让她知道，是我的工作。」

## 给所有agent当接口

今年早些时候，Zed 也做了自家 agent。他的体会是：真正难的部分居然是 AI。调 prompt、跟模型较劲，和做 IDE 完全是两种难法；图灵完备的软件部分反而容易。

与此同时，每家都在造 agent。Anthropic 有 Claude Code，Google 有 Gemini CLI，是 Zed 接入的第一家。这些 agent 渲染出来的终端体验，在他眼里都相当贫瘠，都需要一个编辑器来补。

Zed 的选择是给所有人当接口。参照物是微软做对的一件事：语言服务器协议（LSP）。VS Code 把原本捆在 JetBrains 式 IDE 里的智能抽出来交给社区，PHP 有语言服务器，TypeScript 有语言服务器，谁都能接。

**Zed 想对 agent 做同一件事，这就是他们发起的 ACP（Agent Client Protocol，agent 客户端协议）。**逻辑是：agent 会分化，有的擅长某类问题，有的今天领先明天被反超，与其押注某一家，不如让任何 agent 都能在 Zed 里获得好界面。

效果比他预期的好。JetBrains 理论上是竞争对手，也加入了。他说这样挺好的，与其跟所有人的努力对着干，不如站在同一边。

## LLM擅长什么，卡在哪

这期节目里最有信息量的部分，是 Sobo 拆解 LLM 的能力边界。起因是 Zed 工程师 Conrad Irwin 那篇冲上 Hacker News 第一的文章《为什么 LLM 造不出软件》。Sobo 说他把文章转给主持人时都有点心虚，他自己比 Conrad 乐观，不太愿意断言 LLM 永远做不了什么，但他能说清哪些好用、哪些糟心。

先说好用的。一个成功案例：Zed 有一批老旧的服务端设施要迁移到 Cloudflare，他花了一个下午，vibe coding 出一个 Cloudflare API 的模拟器。做法是先喂 API 文档，再描述需求：写 Rust 绑定，再抽象出一层，方便插入模拟器。他脑子里有完整的图景，只是没时间亲手写。换作以前，要么自己挤时间写，要么写一份含糊的文档向团队解释。这次他直接把生成的一堆代码交给负责云的同事，附了一句「别嫌弃，里面可能有奇怪的东西」。结果团队顺利跑了下去。

他给自己划了一条线：**可以当 vibe coding 的老板，但得当个明白的老板。**最怕那种甩手掌柜，以为自己解决了95%的问题，其实只解决了5%，再把一坨半成品扔给团队。

更早的例子，还在 agent 出现之前，用 GPT-4。Zed 的界面全部由 GPU 渲染，他重写图形后端时，配置渲染管线、设置 GPU 各个阶段这些知识他并不掌握，以前得翻 Stack Overflow 和冷门文档，这次直接生成，一次到位。

还有 Rust 的过程宏。他想把 Tailwind CSS 的思路搬进 Zed 的 Rust 图形框架，给每个 Tailwind 类生成对应方法，这需要写他从来没学过的过程宏。LLM 会。他把这些体验总结成一台「知识榨汁机」：知识都在模型的分布里，他不想去读书再慢慢消化，**他想让知识被直接挤成他需要的形状**。像复制粘贴，但远远超出复制粘贴。

再说糟心的。Zed 正在做一个叫 DeltaDB 的系统，在 Git 之上对每一次编辑做细粒度追踪和实时同步。这是他很久没有体验过的、需要把一堆约束同时装进脑子里硬扛的难题。LLM 帮不上什么忙，至少帮不上写代码的忙。这个系统总共没多少行代码，他引以为傲的恰恰是行数少，每一行都在该在的地方。难的是把所有约束同时想清楚，代码只是把想清楚的东西记下来。

LLM 他照用，只是换了用法：拿它探索想法，甚至让它生成一些他根本不会运行的代码，快速感受一下方向。主持人 Sonya Huang 替他把边界总结得很干净：任务在训练数据分布之内、你脑子里已有清晰的抽象模型，模型实现起来又快又好；一旦出了分布，或者任务的核心是思考而非打字，模型就跟不上了。Sobo 认可这个总结。

另一个痛点是等。agent 跑任务时，你可以盯着看，可以去做别的，可以跟它赛跑，哪种都别扭。盯着看有时必要，比如及时喊停：「住手，我要的那个测试还没跑通，你倒好，跑去写我没让你写的测试，还把它跑通了。」他这个做编辑器的人，连按键反馈都要卡在下一帧，最受不了的就是干等。所以他盼着模型变快，比如 Claude Haiku 这类小模型，工具开发者的职责是搞清楚什么时候切快模型、什么时候切聪明模型。**如果十分之一的时间能拿到一个八九成正确的结果，整个工作方式可能又要变一次。**至于终局会怎样，他自己的说法是，陪审团还没退庭。

## 对话不该只是聊天记录

聊到 IDE 的最终形态，Sobo 先吐槽了一个事实：IDE 长得一模一样已经不知道多少年了。左边文件树，中间标签页，右边 Git 面板或者 agent 面板。这套布局是为一个场景设计的：一个人，一份工作副本，一个问题，手动解决。

如果 agent 成为主要工作方式，这个布局就得重想。他在 Zed 的原型里推几件事：

- **对话即文档。**现在 agent 对话被渲染成聊天记录，但它同时是一份随时间演化的文档：里面不断注入代码引用，不断发生编辑，随日志展开。他想让这份文档从只读变成可编辑，光标往上移，进入之前的对话，直接干活。
- **渲染出来的代码可以直接改。**对话里展示的代码窗口，只要内容是新鲜的，就应该能就地编辑，并且和真实文件同步，还能像 GitHub 的 pull request 那样展开上下文。
- **multi buffer（多缓冲区）。**Zed 已有的概念：把散落在代码库各处的代码片段拼进同一个界面，像编辑一个文件那样编辑它们。他想把对话也变成这种东西：对话把代码拉到你面前，你直接伸手改。
- **时间轴回放。**在对话里选两个点，能不能直接看这段时间里发生了哪些改动？

再往深一层，是他对代码库本身的想象。今天的代码库几乎是裸的：代码里可以有注释，GitHub 的快照上可以挂讨论，但代码本身不带元数据。他想把代码库变成一根主干，让所有相关数据都挂在上面：对话、编辑、上下文，全部稳定地锚在代码的具体位置上，形成对代码演化的连续记录，而非一张张快照。

到那时，LLM 可以对着某段代码问：这底下发生过哪些对话？然后把上下文全部捞出来。人拉同事进对话时，agent 的交流记录就是现成的背景材料，帮对方把该看的代码快速装进脑子。

他管这套东西叫「根本性的抽象」，认为它是围绕 LLM 构建一切交互的地基。

## 明天就能用上的几件事

节目听完，有几件事不用等 Zed 更新，明天就能照做：

- **开双窗口。**用终端 agent 干活时，旁边开一个编辑器同步看改动。Sobo 断言重度用户都在这么干，终端里那十几行摘要，不够你判断一次改动的好坏。
- **先分类，再派活。**任务在模型的能力分布之内、你脑子里已有清晰结构，就放手让它生成，像 Cloudflare 模拟器那样；任务的核心是权衡和思考，就把它当讨论对象和草稿机，别让它碰正式代码。
- **给 agent 的反馈留痕。**别让修改意见散在终端历史里，尽量留在代码旁边，能锚定到具体位置就锚定。你未来的自己和你的队友，都会感谢这些记录。
- **选型时盯住开放协议。**团队挑 coding agent 时，优先考虑支持 ACP 这类开放协议的。今天领先的产品未必明年还领先，接口比产品耐用。

主持人最后把 Sobo 总结为「为手艺寻找完美工具的人」。从2006年到现在，工具换了两代，问题没换过：人和代码之间，该有一个更好的界面。AI 只是让这个界面上多了一个对话者，问题本身还在。