编辑器插件的天花板
把编码助手做成编辑器插件是最自然的做法：光标在哪里，补全就在哪里，交互距离最短。
但它有一个结构性的限制：插件能可靠拿到的信息，通常只有当前打开的文件和相邻的几个文件。而实际工作中最耗时的那类改动，恰恰不发生在单个文件里——改一个接口签名要牵动所有调用点，换一种错误处理方式要扫过整个模块，加一条构建约束要同时动配置和脚本。
命令也是上下文的一部分
还有一类信息编辑器插件看不到：命令的输出。
类型检查报了什么错、测试在哪一条挂了、构建为什么失败，这些是判断下一步做什么的主要依据。插件最多把命令结果贴回来给你看，但没法把“跑命令、读结果、再决定”变成一个连续的循环。
终端里这两件事天然在一起。代理可以执行命令、读输出、根据结果继续操作，整个过程和开发者平时的工作方式一致。
终端是所有人都有的环境
另一个现实考虑是接入成本。编辑器生态分散，每种编辑器一套扩展机制，还要跟随它们的接口变更。终端是每个开发者都已经在用的东西，不需要安装宿主软件，也不需要为了用代理而更换工作环境。
远程场景下这一点更明显：通过 SSH 连到服务器上时，能不能在终端里工作，决定了这件事能不能做。
代价
终端界面能做的东西比图形界面少：没有内联的改动预览，没有点击跳转，长输出的浏览体验也更差。
我们的取舍是把交互做扎实——逐步输出、把每一步做了什么清楚地列出来、状态一直可见——而不是追求图形界面才有的效果。