Vibe Coding 以后，我选择了CLI

我一直没有养成 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 个月有效