Skill 和 CLI：经验指导能力，能力丰富经验

想了三天，我想明白了

上篇《神级CLI写作大法》发了后，有个群友问我：黄叔，CLI 和 Skill 到底谁调谁？是不是 CLI 是底层基础设施，Skill 是上层应用？

这问题让我愣了好几秒。

因为我自己每天的工作流里，CLI 调 Skill、Skill 封装 CLI，来来回回已经好多次了。但你要问我它们是什么关系，我还真没认真想过。想了一阵，我觉得大多数人搞错了一件事。

它们不是上下级，不是谁包含谁。它们更像菜谱和菜刀。

菜谱告诉你怎么切，菜刀帮你切。你可以照着菜谱拿刀，也可以切完之后总结出一份新菜谱。没有人会问"菜谱和菜刀谁是上级"。

先看两个我自己的真实操作，然后你就明白我在说什么了。

我最近在写 Skill 蓝皮书。写的过程中用到了飞书 CLI 和 YouMind CLI。写完之后有个重复动作——对每一篇飞书云文档，我都要调 YouMind 的一个生图 Skill，为每个章节生成配套的信息图。效果是这样的：

这个生图的 Skill 是我之前在 YouMind 里调好的，它能读取整篇文档的结构，针对每个章节自动生成对应图片：

那我怎么在 Claude Code 里调用它呢？就写这样一句话：

帮我为这篇文档https://superhuang.feishu.cn/wiki/xxx 调用YouMind Skill：个性化信息图批量生成器 生成信息图并插回文档的对应位置。

它背后跑的流程大致是这样的：

最后的结果——飞书文档里，对应位置已经自动插好了图片：

这个流程里发生了什么？核心是 Claude Code（CLI 环境）调用了 YouMind 的 CLI，YouMind CLI 又调用了里面的生图 Skill。

能做到这一步，是因为 YouMind 开放了这些能力：

https://github.com/youmind-openlab/skills

好，这是第一个操作——CLI 调用了 Skill。还没完。

上面这个操作我几乎每天都要做。每次都要打那么长一段提示词，说实话挺烦的。我就想：能不能一句话搞定？比如：

为文档生成信息图:https://superhuang.feishu.cn/wiki/xxx

于是我让 Claude Code 帮我把整个流程封装成一个 Skill：

把刚才这个为飞书云文档调用YouMind Skill生成信息图并插入回原文档内的整个过程封装成Skill,你先出个Skill开发方案

很快给了详细方案：

微调一下，3 分钟 Skill 就开发完成了：

之后我的提示词就变成了这样：

你看，整个流程就是对前面操作一的一次完整封装：

做完这两个操作，我突然愣住了。

Skill 把 CLI 装进去了。但前面 CLI 不也把 Skill 调出来了吗？到底谁套谁？

说实话这个问题我想了好一阵，直到：

就这一句话，全想通了。

Skill 是什么？一份存在文件系统里的 Markdown。Agent 需要的时候把它加载进自己的工作记忆，获得"知道怎么做"的知识——加载之后，它会持续影响 Agent 的判断和决策。

CLI 是什么？通过 Bash 工具执行的命令。Agent 需要的时候调它一次，获得"能做什么"的能力——调完就完，结果拿回来继续干活。

它们工作方式不同，但不分高低。一个影响 Agent 怎么想，一个帮 Agent 去执行。

Skill 管"知道怎么做"——经验、知识、SOP。

CLI 管"能做什么"——执行、调用、连接。

就像厨师的经验和厨师的刀。经验在脑子里持续运转——切多厚、火多大、什么时候翻面；刀在手里一次一次切。经验不比刀高级，刀也不比经验底层。你需要经验告诉你怎么切，也需要刀帮你切。切完了总结出一道新经验，下次再用。

飞鸟白菜在分析 Skill 和 MCP 关系的时候也说过类似的话：

Skill 管知识传递，CLI 和 MCP 管能力扩展。两条腿走路，不是一条腿踩另一条。

你可能觉得我这种用法有点野路子。坦白说我一开始也这么想。直到我翻了 Anthropic 的官方文档，发现人家从第一天就把"互相包容"设计进去了。

第一个证据：Skill 天然可以包含脚本。

官方的 Skill 目录结构里有个 scripts/ 文件夹。脚本是什么？就是 CLI 操作。这意味着一个 Skill 从设计上就不只是说明书——它同时可以是工具箱。

my-skill/ ├── SKILL.md           # 知识：怎么做 ├── reference.md       # 补充资料 └── scripts/     └── helper.py      # 执行：CLI 操作

第一次注意到这个的时候我有点意外。

第二个证据：Skill 可以注入 CLI 的执行结果。

官方有一种 !`command` 语法。Shell 命令先跑，输出直接灌进 Skill 内容里。比如你写个 PR 审查 Skill：

- 变更文件列表: !`gh pr diff --name-only` - PR 评论: !`gh pr view --comments`

Agent 拿到的时候，这些已经是 gh CLI 跑完的真实数据了。CLI 的结果，直接变成了 Skill 的上下文。什么意思？CLI 喂 Skill，Skill 消化 CLI。

第三个证据：Skill 可以给 CLI 开绿灯。

在 Skill 的 frontmatter 里写一行 allowed-tools: Bash(git *)，Agent 跑这个 Skill 时就能自由调 git，不用每次弹窗确认。相当于 Skill 跟 AI 说：这几把刀我替你磨好了，放心用。

三个设计放在一起看，方向很清楚：

1Skill 可以包含 CLI 操作（scripts/）

2Skill 可以消化 CLI 输出（!`command`）

3Skill 可以授权 CLI 执行（allowed-tools）

每一个设计都在让 Skill 和 CLI 更深度地咬合。如果官方认为它们是上下级，不会做这种双向嵌套的设计。

理解了关系之后，实际的问题就来了：什么时候 CLI 直接敲，什么时候该封装成 Skill？

简单判断口诀：手动三次，就该写成说明书。

就像你连点三次同一家外卖，第三次就该把它存进收藏夹了。我做那个信息图 Skill 就是这个逻辑。前两次手动调 CLI 跑通流程，第三次直接封装。

从此以后，一句话搞定。

掌握了这个思路之后，你会发现一个更强的玩法——把多个 Skill 和 CLI 串起来，形成 Skill 链。

每个 Skill 调用特定的 CLI 完成一步，把结果传给下一个 Skill。我自己现在的内容生产线就是这样跑的：

全网内容雷达（CLI 抓数据）     → 信息差评估（Skill 做判断）         → 角度锤炼（Skill 切角度）             → 脚本生成（Skill 写稿）                 → 演示规划（Skill + CLI 做 demo）

每一步里面，Skill 和 CLI 交替出现。

Skill 做判断，CLI 做执行，左右手交替传接：

所以我现在对这件事的理解是——不要纠结 CLI 和 Skill 谁在上面。它们自己会找到最舒服的位置。

CLI 是你的手，Skill 是你的经验。手做过的事，写成经验。经验指导手，做更多的事。

下一篇，我讲一个更刺激的事：当你的 Skill 库积累到一定数量之后，会发生什么？