我一直没有养成 IDE 的习惯。
从 Cursor、VS Code，到后来各种带 Agent 的编辑器，我都能用，但很少觉得舒服。窗口太多：文件树、代码区、终端、调试器、插件栏、聊天栏。它们当然很强，只是我的注意力总会被切得很碎。
开始 Vibe Coding 后，我几乎直接上了 CLI。
先解释两个词。
CLI，Command Line Interface，命令行界面。面对的是终端，通过输入文字命令让电脑做事。今天的 CLI 已经不只是过去那个“黑色控制台”，它也可以是和 Coding Agent 对话、让它读代码、改文件、跑测试的入口。
IDE，Integrated Development Environment，集成开发环境。Cursor、VS Code 都属于这一类。它把写代码会用到的文件、终端、调试、版本管理和插件，放进同一个图形界面里。
一个像工作台：工具都摊在眼前。一个像对讲机：把事情说清楚，再等对方回报进展。
我更习惯后者。
I. 我想要的，是少一点界面
一个终端窗口，一段任务描述，Agent 自己读代码、改文件、跑命令、报结果。需要时我打开浏览器看页面，或者打开编辑器看一眼 diff。大部分时间，这种信息密度让我更放松。
过去，IDE 是程序员的驾驶舱。人要自己在文件、代码、终端、Git、调试器之间来回切换；IDE 的价值，是把一整套仪表盘铺在眼前。
现在，Agent 也坐进了驾驶舱。
当它能读仓库、搜索代码、修改文件、运行测试、看浏览器结果时，人不必盯着每一个仪表盘。人更像是在给目的地、判断路线，并在关键岔路口接管方向盘。
这也解释了为什么 CLI 在 Vibe Coding 里突然变得顺手。它保留了任务、过程和结果。
“把这个页面改成移动端优先，别动数据模型。”
它去干。卡住了，补一条信息。完成了，看结果。
中间少了许多“我该点哪个面板”的动作。
II. 真正决定上限的，是 harness
有意思的问题在后面：CLI 里的 Agent，和 ChatGPT、Claude 这类 App 里的 Agent，谁的 harness 更强？
我的判断是：App 不天然更强，CLI 也不天然更原生。真正决定能力的，是 harness。
可以把 harness 理解成：模型之外，围绕模型搭出来的整套手脚和工作环境。
模型负责生成和推理；harness 决定它看得见什么、做得了什么、怎么拿到反馈。
它能不能看到当前仓库、历史对话、项目规则和打开的网页？它能不能读写文件、跑终端、查 Git、调用浏览器、部署服务？它改完后，能不能知道测试是否通过、页面是否真的渲染出来？它记得住的是一次对话，还是一个项目长期积累下来的约束？
这些问题，比它运行在终端、IDE 还是桌面 App 里重要得多。
一个做得好的 CLI harness，离真实执行环境很近：本地代码、Shell、Git、测试、日志，都是它能直接碰到的东西。对真实开发而言，这已经非常强。
一个做得好的 App harness，也有另一种优势。它更容易接住代码之外的上下文：正在看的网页、一张截图、一段语音、一份业务文档，甚至跨应用的工作流。它未必因此更会写代码，但可能更会理解此刻正在处理什么。
所以，“终端里的 Agent”与“App 里的 Agent”并不是两种智力。它们可能接着同一类模型，差别在于，谁给它配了更合适的上下文、工具、权限和反馈回路。
III. CLI 也没有解决一切
CLI 的简洁有一个前提：事情已经被说清楚。
任务本身模糊，Agent 只会把模糊放大。什么不能动、什么结果算完成、什么时候该停下来检查，仍然需要人来判断。终端不会替人补上判断力。
它也不会自动让 Agent 变可靠。没有测试、没有清晰的约束、没有可验证的反馈，再漂亮的对话都只是一次听起来流畅的猜测。
这也是我越来越在意 harness 的原因。大家很容易比较哪个模型更聪明，真正让一个 Agent 从“偶尔惊艳”变成“能连续干活”的，往往是它周围那套环境。
我现在喜欢 CLI。它刚好落在一个舒服的位置：信息足够少，离执行足够近，又能让 Agent 真正把活干出来。
以后我当然可能切到别的界面。
只要那个产品能让我少解释一次上下文，少接管一次中断，少花十分钟确认它到底做了什么，我不会在乎它长得像终端、编辑器，还是聊天窗口。
工具会不断换壳。真正稀缺的，是一个能和人一起把事情做完的 harness。
2026 年 7 月 · 以上判断约 6 个月有效
