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个月有效