你的 IDE 已经不再是你写软件的地方了

这个月发布了一个小功能，我觉得它标志着一个比官方公告所暗示的更大的转折。Mistral 把它的聊天应用改名为 Vibe，并给它加上了一个 "Code Mode"：你连上一个 GitHub 仓库，启动一次在隔离云端沙箱里运行的编码会话，而——重点在这——代理自己干活、开出一个 pull request，然后通知你，「这样你审查的是结果，而不是产出它的每一次敲键」。这些会话 并行运行，在你的机器关机时也照样推进，而且可以 从 Slack 触发， 不再只局限于编辑器。

把最后这句再读一遍。你可以从一条 Slack 消息开始一项真正的软件工作。构建发生的地方， 刚刚不再是 IDE 了。

编辑器从来不神圣——只是感觉如此

在我们整个职业生涯里，「你在哪里写代码」一直有个显而易见的答案：编辑器。它是你敲键的地方， 是工作存放的地方，是驾驶舱。Vibe，还有 Cursor 的 Automations， 以及一波后台代理，正在悄悄把它降级。Cursor 的版本会拉起一台 隔离的云端虚拟机，克隆你的仓库，在自己的分支上干活，然后递给你一个待审查的 PR。一个叫 Tembo 的工具把 Slack 变成了 主界面——在频道里描述一项 任务，就能在同一个线程里收回一个可以直接上生产的 PR。

它们共同的形态是：构建运行在 别的地方，在云端、并行，然后作为一个等你评判的 diff 回到你手里。编辑器变成了你 可能 用来审查那个 diff 的一个地方——而不是工作 发生 的地方。 驾驶舱变成了一条通知。

这是「指挥，而非敲键」走到了它的尽头

我写过自己的工作已经从 敲代码转向指挥写代码的代理。这个月把下一步 变得具体起来：一旦你是在指挥而不是在敲键，你就不需要坐在编辑器里才能做这件事了。如果 真正的工作是把任务说清楚、并评判结果，那么触发点可以在任何地方—— 一条 Slack 消息、一个命令行、一个 issue 跟踪器、一个定时器——而产出永远是同一样东西： 一个等你批准的改动。

这重新定义了整份工作。工作的单位不再是「在编辑器里耗一个下午」，而变成了「我下派出去的 一项任务，和我审过的一个 diff」。这跟 从批准每一步到只看结果 是同一个动作，只不过被一路推到了你身体上如何工作的层面：你启动，代理在云端埋头干， 你回来看一个结果。产出它的那些敲键不再是你要操心的事，就像你不会去读编译器吐出的 汇编一样。

对你来说真正会变的是什么

这件事会带来几个后果，值得你提前应对：

• 规格说明（spec）成了真正的界面。 当你从 Slack 触发、拿回一个 PR 时，你实际亲手写下的，只有那段「你想要什么」的描述。它越清楚，diff 就越好。这就是 spec 才是产物 的字面化—— 你打进频道里的那段文字 就是 工作本身。
• 审查成了主要技能。 如果代理写、你评判，那你的吞吐量就被你读一个 diff 的速度和水平卡住，而不是你打字的速度。瓶颈从生产移到了评估——要把功夫 投在那里。
• 并行成了常态，也成了危险。 会话同时跑，而你的笔记本在睡觉。这是杠杆，但 五个代理在半夜开出五个你随手扫一眼的 PR，正是没审过、微妙有错的代码进入 main 的典型路径。更多的并行构建意味着你需要 更多 的审查纪律，而不是更少。
• 非开发者也拿到了触发权。 当界面是 Slack 时，一个 PM 或支持工程师只要 @ 一下代理就能发起一次改动。这很强大，也是个治理问题——总得有人为 最终进生产的东西负责。

要带走的一点

别过度解读：IDE 没死，仍然有大量工作需要你坐在编辑器里、亲手碰代码。但重心正在 移动。那个默认的心智模型——「写软件就是坐在我的编辑器里敲键」—— 正在变成几个选项之一，而且越来越不是那个主要的选项。

值得内化的转变是：你 在哪里 构建，正在和编辑器解耦；你 做 什么，正从产出代码 滑向说明和评判代码。适应得最快的人，会是那些既能从任何地方轻松发起工作、 更重要的是能把收回来的东西当回事来审查的人——因为唯一没有搬到云端的，是 对最终上线之物的责任。它还待在它一直所在的地方：你这里。