CLI、TUI、GUI是什么？大厂为什么突然都在做CLI工具？

2026年3月，飞书、钉钉、企业微信在不到两周的时间内相继开源了自己的CLI工具。飞书CLI上线首日GitHub星数破千，三个月后涨到将近15000。钉钉CLI一口气发布了209条命令，覆盖19个产品线。企业微信CLI用Rust编写，走轻量路线。

与此同时，群里和学员那边也开始问同一个问题：CLI到底是什么？为什么大厂突然都在搞这个？

说实话，网上搜出来的解释要么太技术化，一堆术语堆在一起，非技术背景的朋友看完更懵。要么就是那种“命令行就是xxx”的概念定义，看完也不知道跟自己有什么关系。

这篇文章就是把CLI、TUI、GUI这三个词讲清楚，然后说说大厂为什么突然集体做CLI，CLI背后到底是什么逻辑，以及这对产品经理来说意味着什么。

三个名词一次讲清楚

先说最熟悉的。GUI（Graphical User Interface，图形用户界面）就是你我每天都在用的东西。打开浏览器上网，打开飞书发消息，打开微信聊天——所有带窗口、按钮、菜单、图标的界面，都是GUI。你用鼠标点，用手指滑，所见即所得。

CLI（Command Line Interface，命令行界面）是另一种操作方式。打开Mac的“终端”或者Windows的“命令提示符”，你会看到一个黑底白字的窗口，光标在那里一闪一闪。你在里面输入一行命令，按回车，程序就执行。

比如你想从GitHub上下载一个项目的代码，CLI方式是这样的：

git clone https://github.com/larksuite/cli.git

一行命令搞定。如果用GUI方式做同样的事，得打开浏览器，访问GitHub页面，点“Code”按钮，选“Download ZIP”，等下载完再解压。CLI更快，但前提是你得记住命令怎么写。

再举几个CLI的例子，都是开发者在终端里天天用的：

# 查看当前目录下有哪些文件
ls -la

# 搜索一段文字在哪些文件里出现
grep -r "飞书CLI" ./docs

# 压缩一个视频，把文件体积缩小
ffmpeg -i input.mp4 -crf 28 output.mp4

# 用飞书CLI查看今天的日程
lark-cli calendar +agenda

CLI的交互方式就是这样：一行命令、一组参数、按回车、出结果。没有按钮、没有弹窗、没有拖拽。看起来原始，但它有一个GUI做不到的事——可以写进脚本里批量跑，也可以被AI直接调用。

TUI（Text-based User Interface，文本用户界面）介于两者之间。它也运行在终端里，但不是一行行命令，而是用字符“画”出一个界面。你在终端里能看到列表、菜单、状态栏，可以用方向键选择，用快捷键操作。

举几个你可能在用的例子。Vim和Neovim是TUI的文本编辑器，在终端里打开就是一个完整的编辑界面，有状态栏、行号、分屏。htop是TUI的系统监控工具，打开就是一个实时刷新的进程列表，CPU、内存占一目了然，方向键选中进程按F9就能杀掉它。lazygit是TUI的Git操作工具，不用记git rebase -i那一长串命令，在界面里选一下就搞定。

还有更多TUI工具值得认识：

TUI工具	用途	替代的GUI操作
Vim / Neovim	文本编辑	VS Code、Sublime Text
htop / btop	系统监控	活动监视器、任务管理器
lazygit	Git操作	SourceTree、GitHub Desktop
ranger	文件管理	Finder、文件资源管理器
ncdu	磁盘分析	WinDirStat、DaisyDisk
Midnight Commander	文件管理	Total Commander

为什么TUI会存在？因为在服务器、远程运维这些场景里，你只有SSH连接，没有图形桌面。纯CLI记不住所有命令，GUI又跑不起来。TUI就是个折中——在终端里给你一个“看起来像应用”的界面，用方向键和快捷键操作，比一行行敲命令容易上手，但又不占什么资源。

维度	CLI	TUI	GUI
交互方式	输入命令+回车	终端内界面+快捷键	窗口+按钮+鼠标
你见过的例子	终端里敲git命令	Vim、htop、lazygit	浏览器、飞书App、微信
上手成本	高（要记命令）	中等（要记快捷键）	低（点就行）
自动化能力	很强（可写脚本）	一般	弱
AI适配性	天然适配	有限	需要额外转换层

TUI有时也被归入CLI的大范畴，因为它们都运行在终端里。但严格来说，CLI是“命令驱动”——你输一条命令它执行一条；TUI是“界面驱动”——它接管整个终端屏幕，你在一个界面上操作。理解这个区别就行，不用太纠结分类。

CLI背后到底是什么

很多人到这一步会有个疑问：CLI说到底是个本地程序，它怎么就能操作飞书、钉钉这些云端服务？

答案很简单：CLI背后调的还是API。

飞书CLI的每一条命令，底层都是在调用飞书的OpenAPI。lark-cli calendar +agenda这条命令，本质上做了这几件事：

flowchart TD
    A["你在终端输入命令"] --> B["CLI程序接收参数"]
    B --> C["加载本地认证Token"]
    C --> D["向飞书服务器发API请求"]
    D --> E["飞书服务器返回日程数据"]
    E --> F["CLI把数据格式化输出"]
    F --> G["你看到今天的日程"]

你看，CLI做的事情其实就是帮你把“认证→请求→解析→输出”这一整套流程封装成了一条命令。你在终端敲一行命令，CLI在后台帮你完成了所有的API调用。

那问题来了：既然CLI底层也是调API，为什么不直接让AI调API，非要做一层CLI封装？

因为直接调API对AI来说太麻烦了。调一个API你需要：构造HTTP请求、处理OAuth认证token、管理token刷新、解析JSON响应、处理各种错误码。这些事情，AI要么需要你提前在代码里写好，要么每次调用都要在上下文里消耗大量token去理解API文档。

CLI把这些复杂度全部吃掉了。AI只需要做一件事——生成一行命令文本。认证、请求、解析全由CLI在本地处理完，返回一个干净的结构化结果。AI不需要理解API文档，不需要管token刷新，不需要处理HTTP状态码。

对比	直接调API	通过CLI
AI需要做什么	构造HTTP请求、管理认证、解析响应	生成一行命令文本
认证处理	AI需要理解OAuth流程	CLI在本地自动处理
文档依赖	AI需要读API文档才知道参数	CLI自带--help，AI按需查
Token消耗	高（API文档+错误处理全在上下文里）	低（命令+结果，干净利落）
错误恢复	需要分析HTTP状态码	CLI输出明确的错误信息

一句话总结：CLI是API的“翻译层”——把复杂的API调用翻译成一行命令，让人和AI都能直接用。 大厂做CLI不是替代API，而是在API之上加了一层让AI更容易调用的壳。

大厂为什么突然都在做CLI

2025年之前，想让程序自动操作飞书或者钉钉，只有两条路：要么用浏览器手动点，要么调OpenAPI。前者没法自动化，后者门槛太高——要注册应用、配权限、管token、处理回调，光认证流程就能卡住一大片人。

CLI工具做的事情很简单：把API调用封装成一条命令。但真正让大厂集体行动的原因，是AI Agent的爆发。

AI大模型的输入输出是纯文本——token序列进，token序列出。CLI也是纯文本的。两者天然适配，不需要任何额外转换。GUI就不行，GUI是为人类眼睛和手指设计的，AI要用GUI得靠图像识别去“看”界面元素，成本高还不稳定。

用一句话说：不是人类重新爱上了命令行，是AI本来就住在命令行里。大厂只是顺应了这个事实。

Andrej Karpathy（前特斯拉AI总监）在用AI构建应用时写下一句话：“你的服务应该有一个CLI工具。不要让开发者去访问、查看或点击。直接指示和赋能他们的AI。”

Vercel CEO rauchg在X上说得更直接：“CLIs are the de-facto MCPs for agents”——CLI就是事实上的Agent工具协议。

看看三家做了什么：

飞书CLI（@larksuite/cli）：Go语言开发，覆盖17个业务域——消息、文档、日历、表格、邮箱、任务、知识库、通讯录、审批、OKR等。GitHub星数截至6月底约14889。一条命令安装：npx @larksuite/cli@latest install。装完之后，Claude Code、Cursor、Codex这些AI工具就能直接操作飞书了。

钉钉CLI（dws）：Go语言开发，209条命令，19个产品线。命令数最多，工程化程度最高——支持自升级、输入纠错、--dry-run预览、--jq精确过滤。还有一个dws schema命令，让AI动态发现可用能力，不需要预置知识。GitHub星数约2302。

企业微信CLI（wecom-cli）：Rust开发，7大品类。走“少而精”路线，二进制体积小、执行速度快。GitHub星数约2391。

维度	飞书CLI	钉钉CLI（dws）	企业微信CLI
语言	Go	Go	Rust
命令数	200+	209	40+
覆盖范围	17个业务域	19个产品线	7大品类
GitHub星数	~14889	~2302	~2391
安装方式	npx一键安装	curl脚本/npm	npm
特色能力	Wake Word语音触发	Schema发现+输入纠错	按企业规模分场景

三家做CLI的共同点很明确：全部开源，全部内置AI Agent Skills支持，全部支持OAuth认证，全部以JSON作为输出格式。这不是巧合，是同一个趋势下的必然选择。

不只是办公平台在做CLI。Google发布了Google Workspace CLI，Stripe发布了Stripe CLI，ElevenLabs发布了ElevenLabs CLI。2026年第一季度，几乎每周都有新的CLI工具发布。这说明“让AI能操作你的产品”正在从一个可选项变成一个必选项。

CLI+AI Agent：让AI真正“动手干活”

没有CLI的AI是什么状态？

你问AI“帮我看看明天有什么安排”，它会告诉你“你可以打开飞书日历查看”。你想让它帮你发条消息，它给你一段文字让你复制粘贴。AI能理解你的需求，能帮你写方案、分析数据，但它没有“手”——不能直接操作你的工作软件。

装了CLI之后就不一样了。同样是“帮我看看明天有什么安排”，AI会调用lark-cli calendar +agenda，直接把你的日程读出来。你说“给张三发条消息说会议改到三点”，AI调用消息命令，直接帮你发。整个过程不用打开飞书App，不用任何界面操作。

再举一个更完整的场景。你周一早上打开电脑，跟AI说“帮我整理一下上周的项目进度，发给老板”。AI会怎么做？它先调用飞书CLI搜索上周的项目文档，拉出关键节点的进展信息，调用多维表格命令读取各项目的状态数据，把所有信息整理成一份摘要，最后调用文档命令创建一份新文档，再调用消息命令把文档链接发给你的老板。整个过程你可能只花了一分钟说话，AI在后台跑了几十条命令全部搞定。

这就是CLI给AI装上了“手”之后的效果。

AI的实际能力 = 它能调用的工具 + 它拿到的说明书。

这个公式很关键。AI本身不“自带”任何操作能力。装了飞书CLI，AI能查日程发消息；装了ffmpeg，AI能处理视频；没装，“这个我做不了”。工具决定了AI能做什么，说明书（Skills文件）告诉AI怎么用这个工具。

新一代CLI和传统CLI有一个根本区别：设计之初就假设调用者可能是AI。

设计维度	传统CLI（git、curl、ffmpeg）	AI原生CLI（飞书CLI、钉钉CLI）
目标用户	人类开发者	AI + 人类开发者
输出格式	人类可读的彩色文字	JSON格式，AI可直接解析
交互方式	可能弹出交互式菜单	所有参数一次传完，不弹菜单
使用说明	靠--help和man page	自带Skills文件，AI直接读取
预览执行	无	支持--dry-run
自我描述	静态文档	AI可动态查询命令列表

传统CLI是给懂命令行的人用的，输出格式是人看的彩色文字。AI原生CLI从一开始就为AI考虑——输出JSON让AI直接解析，不弹交互式菜单（AI处理不了选项菜单会卡住），自带Skills说明书（因为新工具发布时间晚于AI训练数据，AI不认识它），支持--dry-run让AI在执行前预览会发生什么。

一个CLI工具装下去，实际上打包了三样东西：执行能力（CLI命令本身）、通信协议（MCP）、使用说明（Skills文件）。以前这三样是分开的，现在一个工具全带上。

大厂抢着做CLI，这件事跟你有什么关系

过去十几年，SaaS产品的默认链路是：人→打开软件→找页面→点按钮→填表单→完成操作。AI Agent出现后，链路变成了：人→说出目标→Agent理解任务→调用工具→完成操作。

这意味着什么？用户可能不再每次都打开你的GUI了。

用“银行柜台”来理解这个变化：过去办银行业务，你必须去柜台，你和银行的关系发生在柜台窗口。后来有了ATM、网银、移动支付，你不再去柜台了，但你的账户能力还在。你面对的界面变了，银行的核心能力没变。

SaaS产品也一样：产品能力还在，但用户不一定每次都打开你的GUI。Agent可能成为新的入口。

这对产品经理的冲击是什么？过去你主要思考“按钮放哪、表单怎么设计、菜单怎么分组”。未来你还要思考“Agent怎么发现我的能力、怎么调用、怎么确认、怎么报错、怎么留痕”。如果你不懂CLI，你和用户之间多了一个你不懂的入口，而技术可能不带你参与设计。

你能占到什么先机

第一：设计“Agent-Ready”的产品能力。

当你设计一个新功能时，多问自己一个问题：“这个功能未来会不会被Agent调用？”如果会，你的需求文档里就要考虑：输出格式是不是结构化的？Agent能不能读懂？错误信息是不是明确的？Agent知道下一步该干嘛吗？操作有没有清晰的边界？哪些能自动执行，哪些需要确认？

第二：成为团队里“懂Agent设计”的人。

现在大多数产品经理还在学怎么写PRD、怎么做原型。而懂“Agent怎么调用产品能力”的产品经理，在团队里属于稀缺物种。技术评审会上，当技术说“我们打算用CLI暴露这个能力”时，你能问出这些问题：

• 权限怎么控制？Agent和普通用户的权限一样吗？
• 操作失败时返回什么格式？Agent能解析吗？
• 需不需要审计日志？Agent的操作记录怎么查？

这些问题，不懂CLI的人问不出来。

第三：更准确地评估技术方案。

当技术说“接Agent需要两个月”，你能判断：是真的需要两个月，还是技术想从头造轮子？有没有现成的CLI工具或MCP协议可以用？成本和收益是否匹配？

如果不懂，会踩什么坑

坑一：设计的需求，Agent接不进去。

你设计的“创建订单”功能，输出提示是“创建成功”。Agent看到这个提示，不知道订单号是多少，不知道接下来能不能查询这个订单，不知道失败时怎么重试。如果你懂CLI的思维方式，你会在需求里要求：返回结构化结果，包含订单ID、状态、时间戳、下一步可用操作。

坑二：被技术牵着走，没法参与决策。

技术说“我们用API接Agent”，你不知道API和CLI的区别，不知道CLI的Token消耗更低，不知道CLI的调试更方便。你只能说“好，你定”。

坑三：错过产品设计的下一代范式。

GUI时代的产品设计，核心是怎么让人点得爽。Agent时代的产品设计，核心是怎么让Agent调得稳、让人放心。这个转变不是理论，是正在发生的行业现实。飞书、钉钉、企微已经行动了，你设计的产品呢？

哪些能力适合给Agent调用

不是所有功能都适合让Agent自动执行。

更适合Agent调用	不适合完全交给Agent
查订单、查库存、查日程	判断品牌审美、设计方向
生成草稿、生成报表	拍板重大业务决策
创建待办、发起审批	高风险资金操作
批量整理文档	需要强人情判断的沟通

判断标准：规则越清楚、输入输出越明确、风险边界越可控，越适合让Agent调用。

还有一个维度要考虑——动作分层。Agent能执行，不代表应该直接执行：

动作类型	建议处理方式
查询信息	可以直接执行
生成草稿	先生成，等用户确认后再生效
发消息、发邮件	建议二次确认
删除数据、修改金额、批量操作	必须确认，并保留操作记录

Agent越像“能干活的人”，越需要边界。这也是企业级产品强调权限、审计、沙箱、操作日志的原因——不是为了显得复杂，而是为了防止Agent把“能做”变成“乱做”。

几个要说的实话

CLI不是万能的，现在还有一些实际问题。

安全权限控制还不够成熟。 CLI直接执行Shell命令，AI一旦能运行某个CLI工具，就能以该工具的系统身份执行操作，没有“只读不写”的细粒度控制。钉钉CLI在这方面做得最完备——加密存储token、域名白名单、管理员审计——但整个生态还处于早期阶段。

对非技术用户门槛仍然高。 npm安装、认证配置、路径设置，这些对没有终端使用经验的人来说是真实的摩擦。虽然AI引导安装在进步，但现阶段主要还是面向有命令行基础的人。

工具发现是个空白。 你怎么知道某个CLI工具的存在？目前基本靠口口相传——关注了特定技术账号或博客才知道。还没有一个“AI工具的App Store”来帮你发现和安装CLI工具。npm和GitHub最有条件做这件事，但目前都不在它们的产品优先级里。

认证流程碎片化。 装五个CLI工具，就要完成五次不同的登录配置。飞书用OAuth，钉钉用OAuth device-flow，企业微信用自己的认证体系——每家都不一样。对熟悉命令行的开发者是麻烦，对普通用户是真实摩擦。

说实话，我自己对这些东西也还在摸索阶段。文章里写的数据和对比都是基于公开信息和GitHub上的实际数据，但CLI生态变化很快，飞书CLI从3月到现在三个月涨了将近14000颗星，谁知道下半年又会变成什么样。

结尾

CLI、TUI、GUI不是“谁更先进”的关系，是三种不同场景下的交互方式。但在AI时代，CLI因为天然适配AI的纯文本交互方式，突然成了最炙手可热的东西。大厂集体做CLI并接入Agent，本质上是把“让AI能操作我的产品”当成了新的开放策略。

对产品经理来说，不需要学会写命令，但需要理解这背后的逻辑：CLI封装的是API，AI调用的是CLI，最终的产品决策——哪些能力开放给AI、怎么开放、开放到什么程度——这些是你的工作。谁能把产品能力以AI友好的方式开放出来，谁就能在AI Agent生态里占一席之地。

有问题可以留言，评论区聊。