AI时代万物皆可CLI的深层原因

三十年前，命令行曾是普通人踏入计算机世界的首要门槛，也是将大多数人拒之于门外的无形高墙。图形用户界面（GUI）推倒了这面墙，借助鼠标和窗口，计算机变得“人人可及”。然而，到2025年前后，一个有趣的现象正在浮现：命令行界面（CLI）开始重新回归到各类产品的核心位置，并且这一次，它所面向的用户群体远比以往更为广泛。

图形界面解决了哪些问题，又带来了什么新挑战

图形界面的最大贡献在于——你无需记忆任何命令，打开菜单后所有选项一目了然。这种直观交互让计算机从专业工具转变为大众消费品。

但GUI也存在着内在局限：其交互单位是“点击”。点击是原子化的操作，难以高效组合。举个例子，你想把某次会议纪要文件通过邮件发送给同事，再对邮件进行分类归档——在图形界面中，你需要在三四个页面之间来回切换，手动完成每一个步骤。虽然Zapier这类工具试图解决这个问题，但同时也引入了新的学习成本和平台依赖。

CLI从诞生之初就专为“组合”而生。管道符 |、重定向 >、脚本化——这些机制让每一条命令都能成为更大工作流中的一个组件。问题在于，你必须先知道有哪些命令以及如何组合它们，这个前提将许多人拒之门外。

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、纯文本——这些都是文本。AI的输出是文本，脚本的输入是文本，日志是文本，配置文件也是文本。文本作为信息载体有一个GUI天然不具备的优势：可以被任意程序处理，不依赖特定的渲染环境。
   当AI成为用户与系统之间的翻译层，文本便成为最合理的通用接口，而CLI是该接口最自然的载体。
2. 可组合性在AI时代变得更加重要
   单个AI工具的能力存在边界，但当你能够用管道将多个工具或流程串联起来时，边界便消失了。
   cat meeting_notes.txt | claude "提取所有行动项" | gh issue create --body -
   这条命令将会议记录转化为GitHub issue，整个过程自动化完成。这种组合在GUI里根本无法实现，或者需要耗费数倍时间。
   可组合性一直是Unix哲学的核心，但过去只有程序员能真正利用它。AI加入后，这一能力开始向更广泛的用户群体开放。
3. 自动化与可重复性
   CLI天然支持脚本化，这意味着任何你用CLI做过一次的操作，都可以被自动化重复执行。GUI操作很难录制为可靠的自动化流程（Selenium等方案维护成本较高）。
   在AI时代，这一点变得更为关键，因为AI的操作本身也需要被自动化、测试和审计。你不能在生产环境中依靠人工逐条询问AI然后手动复制结果。CLI提供了天然的自动化接口。
4. 更优的上下文传递
   当你在终端中工作时，当前目录、环境变量、管道上下文等信息可以轻松传递给AI。GUI应用通常是孤立的，不同工具之间传递上下文需要大量手动操作。
   Claude Code之所以在开发者中口碑较好，原因之一就是它能感知完整的项目上下文：文件结构、git历史、错误日志，这些信息在终端中都可以自然访问。

感想

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

确实，CLI的复兴目前主要发生在开发者和技术用户群体中，对于普通消费者而言，图形界面在很长一段时间内仍将是主要的交互方式。

但目前趋势表明，随着AI能力的增强，“非技术用户”与“技术用户”之间的界限正在模糊。一个以前从不碰终端的产品经理，在AI的帮助下可能开始使用脚本处理数据；一位设计师可能开始使用CLI工具操作图像。这个边界的移动速度比大多数人预想的要快。

以下几个值得关注的思考方向：

1. 首先是CLI first，而非CLI only。Stripe是一个很好的例子：它的仪表板非常完善，但 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出现之前，这种思维方式需要大量学习才能掌握。如今，门槛正在逐步降低。