CLI、GUI、TUI到底是什么？为什么大厂都在卷CLI？
2026年3月最后一周，钉钉、飞书、企业微信三天之内接连开源了自己的CLI工具。飞书lark-cli冲到9800多颗星（三个月增长了一倍多），钉钉dws 1300+，企微wecom-cli也到了2000星。OpenClaw同月登上GitHub星标总榜，到3月底收割了34万颗星，超过React成为GitHub历史上星标最多的仓库。
CLI复兴这件事不是偶然。
过去40年人类花大力气，在命令行地基上给计算机穿上图形界面这件漂亮外衣。现在AI来了，突然发现脱了外衣光着身子干活反而更利索。这篇文章不讲高深的技术原理，就用产品经理能看懂的方式，拆解三件事：
一、CLI、GUI、TUI到底是什么，什么关系？
二、为什么飞书钉钉都在卷CLI，它跟API/MCP有什么区别？
三、Claude Code、Codex这些AI编程Agent，为什么从CLI起家，跟IDE有何本质区别？
一、CLI、GUI、TUI，三个概念一张图
先给PM同事扫个盲。这三个词跟技术壁垒没关系，就是交互界面演化的三个分支。
GUI（Graphical User Interface），图形用户界面。这是你们日常接触最多的——Windows桌面、Mac的Finder、手机上的App。按钮、图标、弹窗、拖拽，一切都是可视化的。GUI的设计目标很明确：降低人的记忆成本。你看到齿轮知道是设置，看到放大镜知道是搜索，不需要背任何指令。
CLI（Command Line Interface），命令行界面。黑屏白字（或者绿字），没有按钮没有图标，全靠敲命令。ls是列出文件，cd是切换目录，rm是删除。CLI的设计目标是精确和可编程。一次敲对了，下次还能敲，脚本化、批量、自动化全部建立在CLI之上。
TUI（Terminal User Interface），终端用户界面。说白了就是终端里的简化版GUI。htop（进程管理器）、vim（文本编辑器）、lazygit（Git可视化），这些本质上跑在终端里，有窗格有颜色有快捷键，但不是传统意义上那种窗口图形界面。TUI是CLI向GUI方向妥协了一小步的产物。
| 维度 | GUI | TUI | CLI |
|---|---|---|---|
| 学习曲线 | 低，所见即所得 | 中等，需要记快捷键 | 高，需要记命令 |
| 操作效率 | 低，点来点去 | 中，键盘为主 | 高，脚本可批量 |
| 机器可读性 | 极差（像素） | 较差 | 极好（结构化文本） |
| 远程操作 | 需RDP/VNC | 可通过SSH | 原生支持SSH |
| AI友好度 | 极差（需视觉识别） | 差 | 极好（纯文本+参数） |
| 资源占用 | 高（整个图形栈） | 低 | 极低 |
核心矛盾在这里：GUI是人类的最优解，但它是AI的阅读理解题。AI要操作一个GUI界面，需要截图、做视觉识别、算坐标、模拟鼠标移动——每一步都在消耗算力。就像一个精通文字指令的会计师，被要求去翻一本全是图标的儿童绘本找数字。
而CLI，纯文本、结构化、参数和输出格式都有明确规范——这是AI的母语。LLM在海量训练数据中见过无数命令行会话，它天生就懂。
坦白说，CLI本身也是人类设计的产物。只是AI恰好长在了CLI这套语法体系上。
二、为什么大厂都在卷CLI
2026年3月27日到29日，三天之内钉钉、飞书、企业微信先后开源各自的CLI工具。时间窗口密集到这种程度，没人相信这是巧合。
三家CLI分别做什么
飞书 lark-cli
官方定位是Agentic Workspace（智能体工作空间）的核心枢纽。三层命令架构：
- Shortcuts层：以
+号为前缀，内置智能默认值。比如lark-cli calendar +agenda直接看今日日程 - Commands层：标准CLI命令，覆盖文档、表格、消息、日历等飞书核心能力
- Raw API层：直接调飞书全部2500+个API，为边缘场景留后路
lark-cli基于Go 1.23编写，支持npm全局安装，前端开发者不用学Go就能用。它的核心能力是Markdown↔飞书文档双向无损转换——你本地写的Markdown，一行命令直接变成飞书文档，Mermaid和PlantUML还能自动转成可编辑的飞书画板。
钉钉 dws（dingtalk-workspace-cli）
采用Apache-2.0协议，基于Go 1.25，编译成单二进制文件，无额外依赖。设计完全围绕AI Agent优先展开：
将钉钉2000多个开放API封装为204个标准化命令，覆盖AI多维表格、聊天消息、日历、待办、通讯录、考勤、汇报等16个产品线。一个关键设计是Schema动态发现——AI Agent不需要预先硬编码接口信息，通过dws schema命令就能查询所有工具的参数规范。内置智能输入纠错，非标准参数格式自动转换Unix规范，连拼写错误都能修正。
内置13个预构建的AI Agent Skill脚本，覆盖会议预约、日报汇总、销售线索跟进等高频场景。
企业微信 wecom-cli
Rust编写，npm分发，MIT协议。开放了7大高频能力品类：消息、通讯录、文档、智能表格、日程、会议、待办。提供了12个开箱即用的AI Agent Skill。
三家共同点：全是面向AI Agent设计的，不是面向人类设计师设计的。
我以前也不太理解这个转变。直到我自己试了Claude Code和Codex CLI，才意识到一个关键差异：
CLI is the new API
你可能会问：大厂不是已经有API了吗？为什么还要做CLI？叫AI调API不行吗？
答案很简单。
API调用需要写代码——构造HTTP请求、处理鉴权、解析响应。这对开发者来说没问题，但对AI Agent来说，不是一个命令就能解决的事。而CLI命令是一行文本，LLM天生就懂怎么生成命令行指令。
还有两个更关键的理由：
1. CLI自带自我说明
每个像样的CLI工具都有--help或者help子命令。AI遇到不会用的命令，先跑一遍--help看参数说明，按需加载。而API文档是死的数据，要么提前全部注入上下文（Token消耗大），要么靠外部检索（复杂度高）。
2. Token消耗比MCP低很多
你可能听过MCP（Model Context Protocol），它也是连接AI和工具的协议。但MCP要求把所有工具的名称和参数格式全部注入AI上下文。工具越多Token消耗越猛。ScaleKit做过一组基准测试：同样任务，MCP的Token消耗是CLI的几十倍。
当然这不是说MCP过时了。在需要统一权限管控的企业场景下，MCP的标准化鉴权规范依然很有价值。Cursor也已经上线了按需加载MCP的功能，等AI需要用到某个工具时再加载，不再一股脑全塞进去。
三、AI编程Agent：为什么CLI出身，跟IDE有什么本质区别
这块是很多PM同事最想问的。Claude Code、Codex CLI、Cursor这些AI编程工具，宣传上都说"AI帮你写代码"，但你会困惑：它们之间到底有什么不同？一个IDE插件和一个CLI工具有什么本质差别？
IDE AI插件、AI原生IDE、纯CLI Agent——三者的能力分层
先说清楚容易混淆的点。Cursor是一个AI原生IDE（基于VS Code深度改造），它里面既有传统的编辑功能，也有Agent模式。Claude Code和Codex CLI是纯CLI工具，没有图形界面。而GitHub Copilot的侧边栏聊天是传统IDE插件。这三者不是同一类东西，但能力边界正在快速模糊。
为了不误导，我直接拿三种形态做个对比：
| 维度 | 传统IDE插件<br/>（Copilot聊天） | AI原生IDE<br/>（Cursor Agent模式） | 纯CLI Agent<br/>（Claude Code/Codex） |
|---|---|---|---|
| 能力边界 | 补全代码、聊天解释 | 读写文件、跑命令、操作Git、调MCP工具 | 同左，再加管道/重定向/CI集成 |
| 执行模式 | 被动响应你的提问 | Agent主动执行，但你仍在IDE里操作 | Agent主动执行，终端里交互 |
| 上下文管理 | 编辑器当前文件 | 全代码库+编辑器状态 | 全代码库+系统状态 |
| 工具调用 | 无（只输出文本） | 有（终端/MCP/文件系统） | 有（同左，无限制） |
| 多文件操作 | 有限 | 全代码库 | 全代码库 |
| 与系统的关系 | 寄生在编辑器 | 嵌套在IDE里 | 独立进程 |
| 自动化集成 | 不可（需手动） | 有限（可调终端） | 天生可（CI/CD、脚本链） |
| 调试难度 | 高（日志+DevTools） | 中 | 低（重跑命令就行） |
看到差距了吗？真正划分边界的不是"有没有界面"，而是"执行模式"。
Cursor Agent模式和Claude Code在能力边界上已经非常接近了——都能读文件、写代码、跑终端命令、操作Git。两者的核心差异在于集成场景：Cursor的Agent跑在IDE里面，你从编辑到审查到修改都在同一个窗口完成；Claude Code跑在终端里，可以塞进GitHub Actions，可以在服务器上无人值守运行，可以和Linux管道符组合成更复杂的自动化链。
说白了，Cursor是给你用的AI助手，Claude Code是可以独立干活的AI员工。前者提升你的工作效率，后者能嵌入到系统自动化流程里。
所以你应该根据你的场景选择：每天在IDE里写代码选Cursor，需要自动化流程（CI/CD、定时任务、批量重构）选CLI Agent。
Claude Code和Codex CLI是怎么工作的
它们不是你的编辑器插件，而是一个独立进程 + 远程模型服务器的组合。
拿Claude Code举例。你在终端敲claude "帮我重构这个模块"，背后发生的事情是：
flowchart LR
A[终端敲命令] --> B[CLI启动Agent Loop]
B --> C[组装上下文<br/>代码库+历史+指令]
C --> D[HTTPS请求<br/>发送到Anthropic服务器]
D --> E[模型返回回复<br/>含工具调用指令]
E --> F{有工具调用?}
F -->|是| G[本地执行工具<br/>读文件/写文件/跑命令/git操作]
G --> B
F -->|否| H[输出结果给用户]
这套循环叫Agent Loop。它不是一次问答就结束的——它可能循环几十、上百次，直到任务完成。每次循环里，Agent可能读取一个文件、分析代码、修改另一个文件、跑测试、看到测试失败、继续修改……整个过程不需要你敲一个字。
Codex CLI的架构类似，但通信协议不同。它用JSON-RPC over stdio（标准输入输出）。OpenAI还发布了Codex App Server协议，统一了CLI、VS Code、Web、桌面端等所有接入方式。
这里有个产品设计上的洞察：CLI Agent做的是「执行」，IDE插件做的是「辅助」。辅助可以寄生在编辑器里，执行必须独立出去——因为它要在文件系统上动手、在终端里跑命令、操作Git仓库。如果你把它做成IDE插件，性能和权限都会受限。
为什么它们从CLI起家，而不是先做IDE
这是个有意思的产品起步策略。Claude Code和Codex CLI都是CLI为先，然后才做VS Code插件、桌面端。理由很实际：
CLI版本的开发成本最低。 不需要处理编辑器插件的生命周期、不需要兼容不同IDE的API（VS Code、JetBrains、Xcode各有各的插件SDK）、不需要渲染复杂的UI。CLI就是标准输入输出加HTTP请求，核心逻辑写好了，跑起来就能用。
CLI版本的调试体验最好。 IDE插件出了bug，你需要看DevTools控制台、搞日志、甚至复现特定的编辑器配置。CLI出问题了？复制命令重新跑一次，输出一看就知道哪里不对。这对开发者来说就是降维打击——调试效率和IDE插件不在一个量级。
CLI版本天生适合自动化。 可以集成到CI/CD流水线里（比如每次PR自动让Agent做代码审查），可以定时跑（比如每天凌晨自动重构），可以跟其他CLI工具链组合（管道符、重定向、JQ过滤）。IDE插件只能在桌面端一个人用。
更关键的还在于产品定位：CLI Agent不只是IDE的一个功能，它本身就是下一代编程工具的原型。 从CLI出发做产品，意味着你可以先验证"Agent Loop"这个核心模式是否跑得通，再考虑界面包装的事。如果一开始就花大力气做IDE集成，一半精力都消耗在与编辑器交互的复杂度上，而不是核心Agent能力本身。
Claude Code从2025年的研究预览到2026年2月的数据：每天约13.5万个GitHub commits由它生成，占了GitHub总commit数的4%。Anthropic自家90%的代码也是AI写的。这个渗透速度，单纯靠IDE插件版本是不可能实现的——因为CLI版本可以跑在CI里、跑在服务器上、跑在任何人开的终端里。
四、CLI怎么跟服务端通信？跟API到底有什么区别？
这块可能是PM视角最关心的。CLI说到底也是个本地程序，它怎么跟云端的模型通信？这跟API调用有什么区别？我拿实际用过的场景给你讲清楚。
CLI的通信方式
不管是Claude Code还是Codex CLI，它们的通信链路都一样简单：
本地终端 → CLI进程（Agent Loop） → HTTPS/SSE → 模型服务器CLI本身就是一个本地进程。你在终端敲了claude "帮我重构这个模块"，它在本地启动Agent Loop，扫描当前目录结构、读取关键文件（自动发现代码库）、组装好上下文，然后通过HTTPS向模型服务器发请求。
服务器返回的回复中可能包含工具调用指令——比如read_file("src/main.ts")、run_command("npm test")。CLI在本地执行这些操作，把执行结果拼接回上下文，再发下一个请求。就这样循环，直到任务完成。
注意一个关键点：Agent的逻辑在本地跑，模型推理在云端跑。 中间走的是标准的HTTP协议加SSE（Server-Sent Events）做流式传输。所以你的代码和数据在本地，模型的计算在云端，中间通信的是指令和结果。
如果你在本地部署了模型（比如用Ollama跑Llama），那Agent Loop和推理都在本地，连网络通信都省了。但大多数场景下，云端模型的质量明显更高，所以CLI走远端是最常见的部署模式。
CLI ≠ API：一个产品经理应该理解的差异
很多文章把CLI和API混着说，实际上它们是两个完全不同的抽象层级：
| 维度 | API | CLI |
|---|---|---|
| 本质 | 程序接口定义 | 终端操作工具 |
| 调用方式 | 写代码发HTTP请求 | 敲命令+参数 |
| 是否需要编程 | 是 | 否（但需要记命令） |
| 状态管理 | 无状态（每次请求独立） | 有状态（会话、上下文窗口） |
| 交互逻辑 | 无（请求→响应） | 有（多轮、容错、进度反馈） |
| AI友好度 | 低（需构造请求代码） | 高（一行文本搞定） |
你甚至可以理解为：API是积木，CLI是搭积木的人。 CLI的底层实现本身也在调API——Claude Code调Anthropic的API，Codex调OpenAI的API。但CLI在这个基础上多了交互逻辑、上下文管理、工具执行、错误处理。
这让CLI比API多了一层"智能"：它不只是拿到数据，而是去理解任务、分解步骤、执行操作、验证结果。
回到产品经理的视角，这篇文章想传递的核心信息很简单：
CLI这个东西，以前被认为是程序员才用的工具。但在AI时代，它是"给AI用的界面"。你在设计一个系统的时候，有没有给AI留一个入口——这不仅决定了你的系统能不能被Agent调用，也决定了当Agent大军到来时，你的产品是被接入还是被绕开。
未来的产品可能有两套前端。一套GUI给人类，一套CLI给AI。 殊途同归。
这篇不是让你去学敲命令行。但你起码看到"CLI复兴"这个信号之后，知道它不是技术人的自嗨，而是AI时代交互范式的结构性转变。理解这个变化，比记几条命令值钱得多。