AI 时代，为什么说万物皆可 CLI？

猫咪老师
3 阅读8分钟

三十年前，命令行是普通人进入计算机世界的第一道门槛，也是把大多数人挡在门外的那堵墙。图形界面的出现把这堵墙推倒了，鼠标和窗口让计算机变得"人人可用"。但到了 2025 年前后，一件有意思的事情正在发生：CLI 开始重新出现在各种产品的核心位置，而且这次面向的用户范围远比以前更广。

图形界面解决了什么，又带来了什么

GUI（Graphical User Interface）最大的贡献是，你不需要记住命令，只要点开菜单，所有选项就摆在那里。

但 GUI 有一个内在的局限：它的交互单位是"点击"，而点击是原子化的，组合起来非常麻烦。比如，你想把某个会议的纪要文件，用邮件发送给你的同事，再把邮件进行分类——这件事在图形界面里需要在3个页面之间来回切换，手动操作。虽然 Zapier 之类的工具试图解决这个问题，但又引入了新的学习成本和平台依赖。

CLI 从一开始就是为"组合"设计的。管道符 |、重定向 >、脚本化，这些机制让每一个命令都可以成为更大工作流的一个零件。问题是，你得先知道有哪些命令，以及它们怎么组合。 这个前提把很多人挡在了外面。

AI 改变了什么

AI，特别是大语言模型，把"知道怎么写命令"这个门槛几乎消除了。

你现在可以用自然语言描述你想做的事，然后得到一条可以直接运行的命令。这个能力直接重新定义了 CLI 的用户边界。

以前，CLI 的用户是"能写命令的人"。现在，CLI 的用户可以是"能描述意图的人"——而后者几乎是所有人。

更关键的是，AI 和 CLI 在结构上天然契合。语言模型的输出是文本，命令行的输入也是文本。不需要中间件，不需要 API 封装，AI 生成的内容可以直接交给 shell 执行。这种"天然接口"在 GUI 时代根本不存在。

几个正在发生的变化

Claude Code 和 Cursor 的兴起

这两个工具的核心体验都是 CLI 或接近 CLI 的交互。Claude Code 就是一个跑在终端里的 AI，你告诉它"重构这个模块"或者"修掉所有测试"，它直接操作文件系统。Cursor 的 agent 模式也类似——自然语言进去，代码变更出来。

这些工具的流行说明一件事：当 AI 成为中间层，命令行的"高门槛"问题就基本消失了。用户不再需要知道 git rebase -i HEAD~3 怎么写，只要说"合并最近三次提交"就够了。

GitHub CLI 和 gh 的演化

gh （ GitHub CLI ）刚出来的时候定位是"让开发者不用离开终端就能操作 GitHub"，主要用户是重度 CLI 用户。但随着 gh copilot 的集成，它开始往更广泛的方向走：你可以用 gh copilot suggest 描述你要做的事，它帮你生成 shell 命令，你确认后直接运行。

这个模式很有代表性——AI 嵌入 CLI，CLI 的受众随之扩大。

企业工具的 CLI 化

Stripe、Vercel、Supabase、Linear，这些产品的 CLI 都在持续迭代，而且越来越多地把 AI 能力直接放进去。Vercel 的 v0 可以在命令行里生成组件，Supabase 的 CLI 集成了自然语言查询。

更有意思的是一些内部工具的变化。很多公司原本用一套复杂的内部 web 控制台来管理基础设施，现在开始把这些操作迁移到 CLI + AI 的形态，原因很简单：文本接口更容易被 AI 理解和操作，审计日志也更清晰。

万物皆可 CLI 的底层逻辑

说"万物皆可 CLI "，不是说所有产品都要把图形界面扔掉，而是说 CLI 作为一种交互 范式 ，它的适用范围在 AI 时代发生了根本性的扩展。

有几个底层原因值得展开：

  1. 文本是最通用的协议

JSON、Markdown、plain text——这些都是文本。AI 的输出是文本，脚本的输入是文本，日志是文本，配置文件是文本。文本作为信息载体有一个 GUI 天然没有的优势：可以被任意程序处理，不依赖特定的渲染环境。

当 AI 成为用户和系统之间的翻译层，文本就成了最合理的通用接口。CLI 是这个接口最自然的载体。

  1. 可组合性在 AI 时代变得更值钱

单个 AI 工具的能力是有边界的，但当你能把多个工具或流程用管道串起来，边界就消失了。

cat meeting_notes.txt | claude "提取所有行动项" | gh issue create --body -

这条命令把会议记录转成 GitHub issue，整个过程是自动的。这种组合在 GUI 里根本做不到，或者要花几倍的时间。

可组合性一直是 Unix 哲学的核心，但以前只有程序员能真正用上它。AI 加入之后，这个能力开始向更广的人群开放。

  1. 自动化和可重复性

CLI 天然可以被脚本化，这意味着任何你用 CLI 做过一次的事，都可以被自动化重复。GUI 操作很难录制成可靠的自动化流程（Selenium 之类的方案维护成本很高）。

在 AI 时代，这一点变得更重要，因为 AI 的操作本身也需要被自动化、被测试、被审计。你不能在生产环境里靠人工一条一条问 AI 然后手动复制结果。而CLI 提供了自然的自动化接口。

  1. 更好的上下文传递

当你在终端里工作，当前目录、环境变量、管道上下文——这些信息很容易传给 AI。GUI 应用通常是孤岛，不同工具之间的上下文传递需要大量手动操作。

Claude Code 之所以在很多开发者里有较好口碑，一个原因就是它能感知完整的项目上下文：文件结构、git 历史、错误日志，这些信息在终端里都是自然可访问的。

感想

有人会说：CLI 的学习曲线还是存在的，即使有 AI 帮助生成命令，用户还是需要知道怎么在终端里运行它，怎么处理错误，怎么理解输出。这个门槛对于非技术用户来说仍然不低。

确实，CLI 的复兴主要发生在开发者和技术用户群体里，对普通消费者来说，图形界面在很长时间内仍然是主要交互方式。

但现在的趋势是，随着 AI 能力的增强，"非技术用户"和"技术用户"之间的边界在模糊。一个以前从不碰终端的产品经理，在 AI 的帮助下可能开始用脚本处理数据；一个设计师可能开始用 CLI 工具操作图像。

这个边界的移动速度比大多数人预期的要快。

我认为当下CLI流行后，有价值的几个思考：

  1. 首先是 CLI first 而不是 CLI only。Stripe 是一个很好的例子，它的 dashboard 很完善，但 stripe CLI 也是一等公民，两者功能基本对等。用户可以自己选择工作方式，不被强迫。
  2. 其次是把 AI 放在 CLI 里，而不是做一个独立的 AI 产品再集成 CLI。这两个顺序的用户体验差距很大。前者让 AI 成为工作流的一部分，后者让 AI 成为一个需要单独打开的工具。
  3. 第三是认真对待 stdin/stdout。如果你的 CLI 能很好地接受管道输入、输出干净的文本或 JSON，它就能很自然地被 AI 调用和处理。反之，如果你的 CLI 输出一堆 ANSI 颜色代码和交互式提示，AI 就很难处理它。

总结

命令行这种交互方式在 GUI 时代从来没有消失，只是退到了某个特定用户群体的工作流里。AI的伟大之处在于，重新扩大这个群体的边界，同时让 CLI 的核心优势——可组合、可自动化、文本友好——在一个 AI 无处不在的世界里变得更有价值。

说"万物皆可 CLI"，或许有些夸张。但说 CLI 正在成为 AI 时代最重要的人机接口之一，这个判断应该不算错。

终端窗口从来都不只是一个黑框。它是一种思维方式——把复杂的事情拆成可以组合的小块，然后让它们自动运转。在 AI 出现之前，这种思维方式需要大量学习才能掌握。现在，门槛正在降低。

avatar
文章
阅读
粉丝