“最近飞书、网易云音乐都在发 CLI 工具，你怎么看这波热潮？”老王笑嘻嘻地问，“AI 圈每天都在出新东西，有些是风口，有些是泡沫。CLI 这波，你觉得是哪个？”

能感受到，老王对 AI 时代的技术敏感度是真的高。

飞书也不愧是 OpenClaw 大火之后的最大赢家，不仅第一时间降低飞书的配置难度，还在第一时间做出针对 Agent 的 CLI，成为我和 AI 交流最频繁的 IM 工具。

我说：“王哥，这波不是泡沫，是 AI Agent 时代的基础设施升级。”

老王眼睛一亮：“哦？说说看。”

01、CLI 到底是个啥？

“王哥，我先问你一个问题，你觉得 AI 最擅长处理什么？”

老王想了想：“文本？”

“对，AI 就是文本进、文本出。它没有眼睛，看不了图形界面。”

CLI 和 GUI 的区别就在这里。GUI 是给眼睛看的，打开 app，看到按钮菜单，鼠标点来点去。CLI 是纯文本的，打开一个黑色窗口，敲一行文字，按回车，事情做完了。

打个比方，GUI 是去餐厅看菜单、指给服务员“我要这个”。CLI 是直接对厨房喊“油泼面，少油，多辣”。结果一样，但 CLI 更精确，更容易被自动化。

“所以 CLI 和 AI 特别适配？”老王追问。

“对，AI 原本就生活在命令行的世界里。”

AI 想帮你压缩视频，不需要打开 Premiere 找导出按钮，跑一行 ffmpeg -i input.mp4 -crf 28 output.mp4 就完事了。人类没有重新爱上命令行，是 AI 原本就生活在命令行里。

老王点点头：“那为什么以前 CLI 没这么火，偏偏是现在？”

02、AI 的能力边界在哪？

我说：“王哥，这就要说到 AI 的能力边界了。”

很多人把 AI 想象成全知全能的大脑。但更准确的比喻是：一个非常聪明的新员工，什么都能学，学得快，但需要两样东西——工具和说明书。

装了 ffmpeg，AI 能处理视频。装了飞书 CLI，AI 能帮你查日程、发消息。装了网易云音乐 CLI，AI 能管你爱听的歌。

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

AI 的实际能力 = 它能调用的工具 + 它拿到的上下文。

所以如果你感觉 AI 很智障，大概率是他的上下文不够大，给他的工具不够多。

就比如说，如果没有飞书 CLI，让大模型帮我们根据多维表格生成词云图，几乎没办法办到。

“工具好理解，上下文是什么？”老王追问。

“上下文就是说明书。”

就比如说，飞书 CLI 是 2026 年 3 月底刚发布的，AI 的训练数据里完全没有，如果我们不给说明书，AI 根本不知道它存在。

所以新一代 CLI 工具都自带很多种 Skill，我昨天在装飞书 CLI 的时候就安装了 19 个 Skill，Skill 本质就是 Markdown 写的说明书，告诉 AI 这个工具能做什么、怎么用。

老王若有所思：“工具越新，AI 越依赖说明书？”

“对，训练数据永远追不上工具发布速度，说明书会越来越重要。”

03、传统 CLI 和现在的 CLI 有什么区别？

老王话锋一转：“CLI 不是几十年前就有吗？怎么感觉你说的像是新东西？”

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

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

curl -si https://paicoding.com

新一代 CLI 从设计之初就假设调用者是 AI Agent：所有操作通过参数一次性传入，不弹菜单；输出 JSON 格式，AI 直接解析；自带 Skills 说明书；支持 --dry-run 预览，让 AI 执行前先看看会发生什么；AI 还能问工具“你有哪些命令？需要什么参数？”不用读完整文档。

“举个例子？”老王说。

“飞书 CLI。装完以后 200 多条命令，覆盖日历、消息、文档、任务、邮箱等 11 个领域。比如查看今日日程：”

lark-cli calendar +agenda

“查询多维表格数据：”

lark-cli base +query --table appXXX --fields "姓名,学校,专业"

“创建云文档并导入 Markdown：”

lark-cli docs +create --title "面试指南" --file ./interview.md

“这些命令，AI 可以直接调用，不需要打开飞书 app。”

老王点点头：“这确实和传统 CLI 不一样。输出的格式呢？”

“默认是 JSON，AI 可以直接解析。比如查日程的输出：”

{
  "events": [
    {
      "id": "evt_xxx",
      "summary": "谁是逗比大会",
      "start": "2026-03-30T14:00:00",
      "end": "2026-03-30T15:00:00",
      "attendees": ["王二", "陈清扬"]
    }
  ]
}

“AI 拿到这个 JSON，就知道你下午两点有会，参会人是谁，可以直接帮你安排后续工作。”

04、CLI 和 MCP、Skills、Plugin 的区别？

老王追问：“我听说 AI 圈一直在争论 MCP、Skills、Plugin 哪个会成为主流，你怎么看？”

我说：“仔细看新一代 CLI 在做什么，会发现 CLI 把这三样全打包了。”

先解释三个概念。MCP是 AI 和外部服务之间的标准通信协议，理解成 AI 世界的 USB 接口。Skills是告诉 AI“这个工具怎么用”的说明书。Plugin是把工具、协议、说明书打包在一起的可安装扩展，类似手机上的 App。

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

“一个 CLI 工具就是一个事实上的 Plugin。”我说。

“但它比 Plugin 多了几个好处。”老王接话。

“王哥你也注意到这点了？”

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

飞书 CLI 装了以后，Claude Code、Codex、Qoder 都能用。

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

CLI 还有一个很大的优势，就是管道。举个场景：我有一个智能客服系统，每天要生成运营日报。传统做法是：运营人员导出数据、整理 Excel、写分析文字、发邮件。

用 CLI 组合呢？

# 第一步：从客服系统拉取对话数据
cs-cli conversations export \
  --date yesterday \
  --format ndjson

# 第二步：管道传给分析工具，提取关键指标
| jq -c '{total: .total, resolved: .resolved, avg_response_time: .avg_time}'

# 第三步：管道传给AI生成报告
| ai-cli generate \
  --prompt "根据这些数据生成运营日报，包括问题分布、处理效率、改进建议" \
  --output markdown

# 第四步：管道传给飞书，自动发到团队群
| lark-cli message send \
  --chat-id oc_xxx \
  --msg-type post

一条管道，四个工具，从数据拉取到报告发送，全自动完成。人只用在早上看一眼群消息就行。

老王感慨：“大家争 MCP、Skills、Plugin 哪个会赢，答案可能是 CLI 把它们全打包了，而且跨平台。”

05、你觉得以后产品都会 CLI 吗？

老王突然问：“你有没有这种感觉，大部分时间我们不是在写代码，而是在确认 AI 的交付结果。”

“一样，王哥。”

“我觉得，如果以后所有的工具都提供了 CLI 的接入方式，直接指示和赋能 AI Agent 去干活，我们就不再被结果确认占用时间了。”

“AI 时代，服务的接口不应该是图形界面，而应该是命令行。”

如果产品只有网页版，用户想让 AI 帮忙操作，就得让 AI 打开浏览器、点击按钮、填写表单。这一套下来，复杂度极高。

但如果产品有 CLI，AI 只需要跑一行命令就完事了。效率差距是数量级的。

“飞书就做到了这点。这样开发者不需要自己去对接飞书开放平台的 API，装个 CLI 就能用。”

06、做一个 CLI 需要注意什么？

老王追问：“那如果我是开发者，我也想给自己的产品做一个 CLI，应该注意什么？”

我说：“王哥，这个问题我研究过，有五个关键点。”

第一点：不要弹交互式菜单。 传统 CLI 喜欢在遇到选择时弹出菜单，让用户上下键选择。

比如 ? Which environment? 这种。对人来说很自然，但 AI 遇到这种弹窗直接卡死。

正确的做法是：所有选项通过参数一次性传入。如果必须交互，提供 --no-interactive 参数让 AI 跳过。

第二点：输出 JSON 格式。 AI 最擅长处理结构化数据。正确的做法是：默认输出 JSON，或者提供 --output json 参数。这样 AI 可以直接解析，不需要额外处理。

[{"text": {"title": "使用仪表盘的词云图表", "description":
  "一、功能简介\n在多维表格仪表盘中，你可以使用词云图表将文本数据进行视觉化的展示。词云图可以根据
  指定的词频或基于智能分析结果，将高频词汇通过颜色及字体大小突出展示。适用于热点用词分析、用户意
  见统计等需要从大规模文本中提炼关键信息的场景。\n二、操作流程\n添加词云图\n进入目标多维表格，点
  击左侧导航栏中的仪", "url": "https://www.feishu.cn/hc/zh-CN/articles/709166668964", "content":
  "使用仪表盘的词云图表", "meta...

第三点：提供--dry-run 预览。 AI 执行命令前，最好先看看会发生什么。特别是删除、修改这种危险操作。正确的做法是：提供 --dry-run 参数，让 AI 在真正执行前预览结果。这样可以大大降低误操作的风险。

第四点：控制输出大小。 用 field masks 控制返回字段，或者提供 --fields 参数让 AI 指定只返回哪些字段。比如查邮件只要主题和发件人，不要正文。

第五点：写好 Skills 说明书。 Skills 文件要精准，不要太大。建议控制在 1.6KB，这是一个很好的参考。只写 AI 需要知道的，不要写废话。

老王追问：“Skills 文件具体怎么写？能给我看看吗？”

我说：“飞书 CLI 开源了，我们可以直接看它的 Skills 目录。”

飞书 CLI 的 Skills 目录下有 19 个文件，每个对应一个业务领域。比如 lark-base.md 是多维表格操作的说明书，lark-calendar.md 是日历操作的说明书。每个 Skills 文件都包含：工具概述、可用命令、参数说明、使用示例。格式清晰，AI 读完就知道怎么用。

“而且飞书 CLI 还提供了 skill-template 目录。”我说，“如果你想给自己的产品写 Skills，可以直接复制这个模板，改成自己的内容就行。”

老王听完点点头：“这五点都很实用。”

07、怎么管理 CLI？

老王突然问了一个有意思的问题：“如果用户装了很多 CLI 工具，怎么管理？”

“王哥，这个问题我也思考过。有一个很有意思的思路，让 AI 管理自己的工具。”

传统软件思路是：写代码嗅探用户系统装了什么、写 UI 让用户在界面上管理工具、写逻辑检测更新。标准做法，但工作量巨大，而且每个工具的情况都不一样，用代码写死安装逻辑是写不完的。

但 AI 时代有一个更好的思路：既然产品里已经有 AI 了，为什么要绕过它？

安装工具，直接拉起对话让 AI 来。AI 读 --help，判断操作系统，处理权限错误，引导认证配置。安装报错了它能读错误信息自己判断，要不要 sudo？先装个依赖？换个源？

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

“这个思路有意思。”老王眼睛一亮，“等于说 AI 既是工具的使用者，也是工具的管理者。”

“对，这就是 AI 时代的产品设计思路，别用软件帮用户管理 AI 的工具，让 AI 管理自己的工具。”

老王追问：“那更新呢？工具更新了怎么处理？”

“更新更简单。AI 定期检查工具版本，发现新版本就提示用户是否更新。更新过程中遇到问题，AI 自己读错误日志判断怎么解决。整个过程用户只需要点一下确认，剩下的 AI 全包了。”

08、CLI 的未来

老王问：“你觉得 CLI 未来会怎么发展？”

我说：“有几个趋势比较确定。”

趋势一：CLI 会成为产品的标准配置。 以后每个 SaaS 产品，除了网页版、app 版，还会有 CLI 版。不是可选的附加功能，而是标配。

因为 CLI 是 AI 调用你产品的最佳接口，没有 CLI 就等于放弃了 AI 这个用户群体。飞书开了个头，接下来会有更多产品跟进。

趋势二：会出现 AI 工具的 App Store。 未来一定会出现专门索引 AI 工具的平台，可能是由 npm、GitHub 来做，也可能是由新的创业公司来做。

谁能做成这个，谁就是 AI 时代的 npm。这个机会很大，现在还是空白。

老王听完感慨：“这两个趋势，每一个都是机会。那你觉得普通开发者能做什么？”

“两件事。第一，学会用好现有的 CLI 工具，提升自己的生产力。第二，如果有机会，给自己的产品做一个 CLI，这是进入 AI 生态最直接的方式。”

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

老王问出最后一个问题：“总结一下，为什么一夜之间大家都在做 CLI？”

我说：“王哥，大家意识到 CLI 可能是当下效率最高的 AI 能力分发方式。”

一个 CLI 工具同时包含执行能力、通信协议和使用说明，就是一个完整的 AI 插件。跨平台，免审核，人和 AI 都能用。每多装一个好用的 CLI 工具，你的 AI 就多一项技能。每少一分多余的上下文噪音，你的 AI 就聪明一点。

“具体说说？”老王追问。

“王哥，你看飞书 CLI 出来之后，我做了什么。”

我用飞书 CLI 让 AI 帮我分析了 600 多条简历数据，生成了词云图，还把 18 篇面渣逆袭文章全部上传到了飞书云文档。整个过程我没写一行代码，没打开飞书网页，全是 AI 通过 CLI 自动完成的。

https://my.feishu.cn/wiki/CScqwBVyliWpRYkJEAWc9ouxnZf?from=from_copylink

如果没有 CLI 呢？我得先去飞书开放平台创建应用、配置权限、写代码调 API、处理分页、处理图片上传、处理格式转换。一套下来，一天就没了。

有了 CLI 呢？装一次，扫个码，AI 就能直接干活。效率差距是数量级的。

“而且 CLI 有个好处，一次安装，处处可用。”我说，“我在 Qoder 里装了飞书 CLI，换到 Codex、Claude Code 里都能用，不需要重复配置。这是 Plugin 做不到的。”

老王点点头：“这确实解决了跨平台的问题。”

我们正处在一个混乱的新旧交替时代。旧的格式、旧的数据壁垒、旧的包管理器，和新的 AI 原生工具链交织在一起。

老王沉默了两秒，然后说：“你什么时候能来上班？”

10、CLI 如何写到简历上？

项目名称：AI Agent CLI 工具集成项目

项目简介：基于飞书 CLI 等 AI 原生命令行工具，实现业务数据的自动化分析和文档管理，提升数据处理效率 10 倍以上。

核心职责：

• 集成飞书 CLI 等 AI 原生工具，实现业务数据自动采集与分析，覆盖 11 大领域 200+命令，日均处理数据 500+条
• 利用 AI Agent + CLI 管道组合，完成批量文档转换与上传，18 篇万字文档一键同步飞书云空间
• 编写自定义 Skills 文件，指导 AI 正确调用工具，准确率达 95%以上，减少 AI 幻觉导致的误操作
• 设计并实现 CLI 工具管理方案，支持跨 Agent 平台复用，工具配置时间从 30 分钟缩短至 2 分钟

Karpathy 说得对：每一个产品都应该有一个 CLI 工具。不要让开发者去访问、查看或点击。直接指示和赋能他们的 AI。

【CLI 不是复古，是 AI 时代被重新发明的基础设施。】

CLI 这波浪潮，才刚刚开始，机会巨大。

我们下期见！