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

Mistral 刚刚发布了一种编码模式：你从 Slack 启动一次构建，代理在云端沙箱里干活，而你的笔记本是关着的，最后你拿回一个待审查的 pull request。Cursor 和其他家也在做同样的事。编辑器——那个我们一直当作软件诞生之地的东西——正悄悄沦为众多触发入口中的一个。工作正从窗口里的一次次敲键，转向你下派的任务和你评判的 diff。这件事对这份职业的改变，比听上去要大得多。

- **Author:** Fedor Chishchin
- **Published:** 2026-06-06
- **Tags:** methodology, ai-native, agents
- **Source:** https://fedorthinks.com/zh/blog/your-ide-isnt-where-you-build

---

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

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

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

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

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

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

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

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

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

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

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

## 要带走的一点

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

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