为什么一夜之间大家都在做 CLI？

飞书、Google、Stripe、ElevenLabs、网易云音乐。

最近几个月，一群看起来毫不相关的公司不约而同做了同一件事：发布 CLI 工具。

Karpathy 最近写了一篇文章记录自己用 AI 做 app 的全过程。

他大部分时间不是在写代码，主要是在浏览器标签之间跳来跳去，配 API Key、改 DNS、填环境变量。

他的原话是：

2026 年了，为什么大家突然回去做"命令行"这种看起来很复古的东西？

CLI 到底是什么

如果你不是程序员，CLI 听起来很技术。其实概念很简单。

GUI（图形界面）是打开 app，看到按钮菜单，鼠标点来点去。

CLI（命令行）是打开一个黑色窗口，敲一行文字，按回车，事情做完了。

打个比方：GUI 是去餐厅看菜单、指给服务员"我要这个"。

CLI 是直接对厨房喊"宫保鸡丁，少油，多辣"。结果一样，但 CLI 更精确，更容易被自动化。

那为什么 CLI 和 AI 特别适配？因为 AI 就是"文字进、文字出"的。GUI 是给眼睛看的，AI 没有眼睛。

AI 想帮你压缩视频，不需要打开 Premiere 找导出按钮。它跑一行 ffmpeg -i input.mp4 -crf 28 output.mp4 就完事了。

人类没有重新爱上命令行。是 AI 原本就生活在命令行里。

AI 的能力边界在哪？

很多人把 AI 想象成全知全能的大脑。

更准确的比喻是：一个非常聪明的新员工，什么都能学，学得快，但需要两样东西，工具和说明书。

装了 ffmpeg，AI 能处理视频。装了飞书 CLI，AI 能帮你查日程、发消息。

装了 Google Workspace CLI，AI 能管你的邮箱和云盘。

没装？"不好意思，这个我做不了。"

工具好理解。"上下文"是什么？简单说就是说明书。

对于 ffmpeg 这种经典工具，AI 在训练时已经见过海量用法，不需要额外说明书。

但飞书 CLI 是 2026 年刚发布的，AI 的训练数据里完全没有，你不给说明书，AI 根本不知道它存在。

所以新一代 CLI 工具都自带一种叫 Skills 的文件，本质就是 Markdown 写的说明书，告诉 AI 这个工具能做什么、怎么用。

这里有个推论值得注意：工具越新，AI 越依赖这种显式说明书。

CLI 正在被重新发明

过去的 CLI 和现在的 CLI，虽然都叫 CLI，已经是两种东西了。

传统 CLI，比如 ffmpeg、jq、curl，是给程序员用的。

输出是给人眼看的彩色文字。遇到需要选择的时候会弹交互式菜单，对人来说很自然，但 AI 遇到这种弹窗直接卡住。

新一代 CLI 从设计之初就假设调用者可能是 AI：

拿飞书 CLI 举例：装完以后 200 多条命令，覆盖日历、消息、文档、任务、邮箱等 11 个领域。

你说"帮我看看明天有什么安排"，AI 调用 lark-cli calendar +agenda；

说"给张三发条消息说会议改到三点"，AI 调用对应的消息命令。整个过程不用打开飞书 app。

Google Workspace CLI 更极端，一条命令启动一个 MCP 服务，让 AI 直接通过标准协议操作 Gmail、Google Drive、Google Calendar。

CLI 正在变成 AI 的万能插件

这里说一个我在做 CodePilot 过程中观察到的现象，目前还很少被讨论到。

先用一句话解释三个概念：

AI 圈一直在讨论这三个东西哪个会成为主流。

但你仔细看新一代 CLI 在做什么，会发现它们把这三样全打包了。

Google Workspace CLI 就是典型：CLI 命令提供执行能力，内置 MCP 服务提供标准通信协议，自带 Skills 文件充当使用说明书。

飞书 CLI、Stripe CLI、ElevenLabs CLI、网易云音乐 CLI，全是这个模式。

但它比 Plugin 多了几个好处。

Claude Code 的 Plugin 只能在 Claude Code 里用。

飞书 CLI 装了以后，Claude Code、Cursor、Gemini CLI 都能用，不锁平台。

这一点在国内尤其重要，因为众所周知的原因，用户可能今天接 Claude，明天换 DeepSeek，后天试 Qwen。

CLI 不关心调用它的是哪个模型，它是模型无关的执行层。

Plugin 商城有审核流程，CLI 工具往 npm 上 publish 就上线了，跟发网站一样自由。

而且人也能用，不装 AI 也能在终端里直接敲命令，开发者有更大的动力去做和维护。

CLI 还有一个 Plugin 做不到的事：

组合。gws gmail +triage | jq '.messages[]'，两个工具用管道串起来，前一个的输出变成后一个的输入。

Shell 管道这个几十年前的设计，在 AI 时代突然又变得值钱了。Plugin 之间是隔离的，没有标准的组合方式。

但事情没那么美好

说了这么多好处，该说问题了。

CLI 最大的结构性缺陷是安全。

Plugin 在平台沙箱里跑，有声明式权限控制。

CLI 是直接执行 shell 命令，AI 一旦能跑 gws，就能用这个身份做任何事。

没有"只读不写"的细粒度控制。目前靠 --dry-run 和弹窗确认来补救，但跟平台级权限框架比，差距很大。

具体到实际使用，我在 CodePilot 里接入各种 CLI 工具的过程中也踩了不少坑。

第一个：说明书太大，AI 脑子撑爆了。

有些工具有非常大的 Skills 文件。AI 的上下文窗口有容量限制，这一个文件就占掉一大块，加载完推理质量明显下降。

对比之下，Google Workspace CLI 的 Skills 文件平均 1.6KB，精准给 AI 需要的信息，不多不少。

第二个：交互式提示卡死 AI。

Stripe CLI 早期版本弹 ? Which environment? 选择菜单，人觉得挺自然，AI 直接卡住不动了。后来加了 --no-interactive 才解决。

第三个：输出太长，淹没有用信息。

一个查询返回几万字符 JSON，全灌进上下文，真正需要的信息反而找不到了。

Google Workspace CLI 用 field masks 控制返回大小，这个设计目前很少有工具跟进。

这几个问题有一个共同根源：

"为 AI 设计"和"在 AI 中验证"是两件事。就像移动端适配，设计稿上看着响应式没问题，真机上按钮根本点不到。

我的实验：让 AI 管理自己的工具

做 CodePilot 的 CLI 管理功能时，我经历了一次思路转变。

一开始是传统软件思路：

写代码嗅探用户系统装了什么、写 UI 让用户在界面上管理工具、写逻辑检测更新。标准做法。

后来想明白了一个问题：我产品里已经有 AI 了，为什么要绕过它？

安装工具，直接拉起对话让 AI 来。

AI 读 --help，判断操作系统，处理权限错误，引导认证配置。

安装报错了它能读错误信息自己判断，要不要 sudo？先装个依赖？

注册工具也一样，给 AI 一个提示词模板，读完 --help 自动生成结构化描述，工具能做什么、怎么用、典型场景。

每个工具的情况都不一样，用代码写死安装逻辑是写不完的。

但 AI 能处理这种开放式问题。把工具安装变成 AI 任务，比写一个覆盖所有边界情况的安装器靠谱得多。

我还做了一个 5 维 Agent 兼容度评分，从是否为 AI 设计、是否支持结构化输出、是否支持自查、是否支持预览、是否注意上下文大小五个方面去打分。

说实话这个评分更多是一个呼吁：希望工具开发者开始想"我的 CLI 对 AI 友好吗？"

还缺什么？

CLI 正在成为 AI 能力扩展的基础设施，但有几个明显缺口。

你怎么知道"有个飞书 CLI 能让 AI 操作飞书"？

目前基本靠口口相传。npm 和 GitHub 最有条件做 AI 工具的 App Store，但它们没这个动力。发现机制是空白的。

认证也是问题。

飞书一套登录，Google 一套，Stripe 一套，装五个工具登录五次。对普通用户来说摩擦太大了。

安装体验也不靠谱。

npm、brew 是十几年前设计的，假设使用者是懂命令行的开发者。

当操作者变成 AI，权限问题、依赖缺失、路径冲突这些"查 Stack Overflow 就能解决"的问题，变成了真正的障碍。

行业不缺工具，不缺协议，不缺说明书。

缺的是让这三样东西被发现、被安装、被信任的那一层基础设施。

谁做出来这个，谁就是 AI 时代的 npm。

所以，为什么大家都在做 CLI？

大家意识到 CLI 可能是当下效率最高的 AI 能力分发方式。

一个 CLI 工具同时包含执行能力、通信协议和使用说明，就是一个完整的 AI 插件。

跨平台，免审核，人和 AI 都能用。

每多装一个好用的 CLI 工具，你的 AI 就多一项技能。每少一分多余的上下文噪音，你的 AI 就聪明一点。

我们正处在一个混乱的新旧交替时代。

旧的格式、旧的数据壁垒、旧的包管理器，和新的 AI 原生工具链交织在一起。

CLI 不是唯一的答案，但它是目前最务实的那一个。