深度解读 CLI 与 Skill 的协同之道：从操作实践到设计哲学

在 AI Agent 领域，CLI 和 Skill 是两个高频出现的概念。然而，许多开发者对它们的关系存在误解——认为它们是上下级的包含关系。事实上，它们更像是厨房里的菜谱与菜刀：菜谱告诉你怎么做，菜刀帮你实际执行。二者相互配合，却不存在绝对的层级高低。

CLI 调用 Skill 的实战场景

让我们通过一个真实案例来理解这种协同关系。在撰写技术文档时，作者需要为每个章节生成配套的信息图。具体流程是：通过 CLI 环境调用一个封装好的生图 Skill，该 Skill 能读取文档结构并自动生成对应图片。执行时只需输入一句提示词，系统便会自动完成从读取文档到生成图片再到插入对应位置的完整流程。这个案例展示了 CLI 作为「执行者」如何调用 Skill 作为「能力包」的过程。

Skill 封装 CLI 的自动化实现

上述操作如果每天都要重复，直接调用 CLI 就会显得繁琐。这时可以将整个流程封装成一个 Skill。封装后的效果是：原本需要长段提示词的操作，现在只需一句话即可触发。这体现了 Skill 的核心价值——将重复性的操作流程转化为可复用的能力模块。封装完成后，CLI 调用 Skill、Skill 再调用 CLI 的双向协同便形成了闭环。

重新理解二者的工作边界

这种协同并非「野路子」用法。实际上，Anthropic 从官方设计层面就支持这种深度融合：首先，Skill 目录可以包含 scripts/ 文件夹，脚本本质上就是 CLI 操作；其次，Skill 支持 `!`command`` 语法，Shell 命令的执行结果可以直接注入 Skill 内容；最后，Skill 的 frontmatter 可以配置 allowed-tools 来授权 CLI 执行。这些设计都表明官方认可并鼓励二者深度协同。

官方设计已内置双向融合

面对具体场景，如何选择直接使用 CLI 还是封装成 Skill？这里有一个实用的判断口诀：「手动三次，就该写成说明书」。具体而言：当操作是一次性或探索性的、流程还在调试阶段、仅供自己使用时，直接用 CLI；当操作需要重复三次以上、流程已稳定、需要分享给他人或 AI 使用时，就应封装成 Skill。这就像点外卖——连点三次同一家店，第三次时就该存入收藏夹了。

如有侵权，请联系删除。