Skill、MCP 与 CLI：职能分层与协作关系
一、三者各司其职
Skill（技能）
Skill 是封装了特定领域知识、标准流程和操作规范的能力包。它包含条件分支、校验逻辑和硬性约束，本质上是一个"带规则的决策剧本"。它的职责是告诉 AI：在什么业务场景下该做什么决策，什么条件下允许执行、什么条件下必须终止。
MCP（模型上下文协议）
MCP 是一个标准化的中间层协议，以常驻服务的形式存在。它将底层的 CLI 命令、REST API、数据库连接等复杂实现抽象为统一的工具签名。它的职责是充当 AI 的"翻译官与保镖"------接收 AI 的结构化意图请求，翻译成具体操作并执行，返回标准化结果，同时承担状态维护和安全边界收缩。
CLI（命令行接口）
CLI 是操作系统与应用层最底层的原子指令集（如 git push、npm install）。它的职责是完成最具体的执行动作，不包含任何业务逻辑判断。
二、三者的纵向协作关系
三者构成一条自上而下的逐级委托链：
Skill 位于决策层，它定义了"做什么"以及"什么条件下才能做"。当 Skill 判定某个操作可以执行时，它并不亲自去操作底层系统，而是将执行请求向下委托。
MCP 位于适配层，它接收来自 Skill 的调用请求，将其翻译成具体的底层指令。MCP 负责维护连接状态、处理鉴权、解析返回结果，并将结构化数据回传给 AI。它向下隔离了底层实现的复杂性，向上屏蔽了安全风险。
CLI 位于执行层，它是 MCP 可能调用的底层手段之一（此外还有 API、数据库协议等）。CLI 只负责完成单一原子动作，不参与任何决策和状态管理。
三、为什么是三层而不是两层
如果将 Skill 直接调用 CLI，AI 将获得操作系统的完整权限，且每次执行无状态、返回非结构化文本------这导致安全失控、调试时 Token 飙升、跨轮次任务难以维系。MCP 作为一个中间适配层，用常驻服务的内存开销，换取了安全收缩、状态持久化和结构化交互，本质是用廉价资源置换昂贵的 Token 消耗与潜在的事故风险。
四、选型边界
本地简单任务（固定目录操作、简单 Git 流程）：Skill + 直接 CLI 调用即可，无需额外引入 MCP。
跨系统交互、长时异步任务、生产高敏环境：必须经由 MCP 接管，以保证权限可控与状态可维。
扼要 Q&A
Q：Skill 是自然语言指导，CLI 是具体命令，MCP 是教 AI 用工具？
A：三者皆误。Skill 内含硬性条件分支和 CLI 调用，是"带约束的剧本"而非软指导。MCP 不"教"AI，而是充当翻译代理------AI 发意图 JSON，MCP 转成底层 CLI/API 调用并返回结构化结果。CLI 只是孤立原子动作，离开 Skill 的上下文约束，AI 不知"该不该做"。
Q：MCP 多此一举？CLI+Skill 加个审查不就行了？
A：事后审查有两大死穴：①只能查格式不能查语义（看不出删除的是老板 ID 还是离职员工）；②拦不住组合拳（git commit && rm -rf 绕过开头关键词拦截）。MCP 的安全逻辑是"剥夺自由度"------不提供 Shell 执行环境，只暴露有限白名单函数，从源头杜绝字符串注入。
Q：Skill 自己做白名单，比 MCP 更轻量？
A：理论可行，工程上三座大山：①白名单拦不住命令拼接（git commit ; npm install --unsafe 分号后绕过）；②调试 CLI 报错时，50 行堆栈反复塞上下文，Token 消耗远超 MCP 的 JSON 状态码交互；③CLI 无状态，跨轮次需 AI 记忆 PID，上下文滚动即丢失，要维护状态等于自建 MCP。MCP 是用廉价服务器内存置换昂贵 Token 消耗。
Q：什么时候用 CLI+Skill，什么时候上 MCP？
A：本地固定目录、简单 Git、确定性脚本 → CLI+Skill（零额外开销）。涉及 Jira/Notion/K8s、长时异步任务、需保持登录态高频交互 → MCP（以启动开销换长尾确定性）。衡量指标：AI 调试 CLI 报错超 3 次，其 Token 成本已超过 MCP Server 整月内存费用。
由deepseek用户界面问答，调整说明细节生成的报告