每个软件都需要一个 CLI + Skill：未来软件架构的终局猜想

_遥远的救世主_2026-04-16 9:53

各大厂都在做自己的 CLI------Claude Code、Gemini CLI、OpenCode、Codex CLI------而且全是 npm install -g 一键安装。装完之后加载 Skill，就能用自然语言操控一切。这让我想到一个问题：未来是不是所有软件都需要一个自己的 CLI？Skill 是不是会变成软件能力的最小交付单元？

但接踵而来的问题是：Skill 一多就成千上万，CLI 怎么精准调用？开发一个 CLI 难不难？怎么用这套逻辑把自己的软件重做一遍？

这篇文章沿着五条思考路径展开，试图回答这些问题。

一、命题：每个软件都需要一个 CLI Agent

1.1 正在发生的事实

2025-2026 年，一场静默的"CLI 复兴运动"正在发生。但这一次的 CLI 不再是 man page + --help 那个时代的产物------它们本质上是 Agent：

timeline title CLI 的三次进化 section 第一代 · 命令行 1970-2010 : Unix 哲学 : 管道组合 : man page : 精确但门槛高 section 第二代 · 交互式 2010-2024 : 自动补全 : 交互式提示 : TUI 界面 : 友好但仍需记命令 section 第三代 · Agent CLI 2025- : 自然语言驱动 : Skill 热加载 : MCP 工具连接 : 说人话就能用

看看这些产品在做什么：

产品 本质 安装方式 Skill 机制
Claude Code 编码 Agent CLI npm i -g @anthropic-ai/claude-code CLAUDE.md + Agent Skills
Gemini CLI 编码 Agent CLI npm i -g @anthropic-ai/gemini-cli GEMINI.md + 插件
Codex CLI 编码 Agent CLI npm i -g @openai/codex 指令文件 + Function Calling
OpenCode 开源编码 Agent go install 配置文件 + MCP
Warp 智能终端 独立安装 AI 命令解释 + Workflow
OpenClaw 全能 Agent CLI npm i -g openclaw ClawHub Skill 市场

模式高度一致：CLI 壳 + LLM 大脑 + Skill 能力包 + MCP 工具连接。

1.2 为什么是 CLI 而不是 GUI

这不是技术审美问题，而是 Agent 的天然形态就是文本流：

flowchart LR subgraph GUI["GUI 应用"] direction TB G1["用户点击按钮"] --> G2["触发事件处理器"] G2 --> G3["调用业务逻辑"] G3 --> G4["更新界面渲染"] end subgraph CLI_AGENT["CLI Agent"] direction TB C1["用户说一句话"] --> C2["LLM 理解意图"] C2 --> C3["匹配 Skill"] C3 --> C4["调用 MCP 工具"] C4 --> C5["流式返回结果"] end GUI -. "需要预定义每个交互路径" .-> LIMIT["路径爆炸"] CLI_AGENT -. "LLM 动态决策" .-> FLEX["无限灵活"] style LIMIT fill:#ef4444,color:#fff style FLEX fill:#10b981,color:#fff

三个核心原因：

  1. LLM 输入输出都是文本------CLI 是零阻抗的连接方式，GUI 反而是额外的翻译层
  2. Agent 的行为不可预测------GUI 需要预定义所有交互路径，但 Agent 的决策链路是动态的
  3. 组合能力------CLI 天然支持管道、脚本、自动化编排，GUI 做不到

这不意味着不需要 GUI。而是说 CLI 是 Agent 的"原生接口"，GUI 是 Agent 的"展示层"。先有 CLI，再套 GUI------就像 Git CLI 先于 GitHub Desktop。

1.3 一个推论：每个 SaaS 都会有自己的 Agent CLI

如果我们接受"CLI 是 Agent 天然形态"这个前提，逻辑链条就很清晰了：

flowchart TD A["每个软件都有 API"] --> B["API 可以被 MCP 封装"] B --> C["MCP 让 Agent 能调用"] C --> D["Skill 教 Agent 怎么调用"] D --> E["CLI 是 Agent 的壳"] E --> F["每个软件都需要一个 CLI Agent"] F --> G["用户不再打开网页操作"] F --> H["用户对 CLI 说一句话，自动完成"] style F fill:#6366f1,color:#fff,stroke-width:3px

想象一下：

bash 复制代码 
# 不再打开 Jira 网页，手动创建 Issue
$ jira-cli "把这个 bug 分给张三，P1 优先级，关联到 sprint 7"

# 不再打开 Figma，手动调布局
$ figma-cli "把首页 banner 改成渐变背景，文字居中"

# 不再打开财务系统，手动报销
$ finance-cli "报销上周北京出差的高铁票和酒店，一共 2380 元"

这不是未来，这是正在发生的事。 Vercel 已经有 vercel CLI，Stripe 有 stripe CLI，AWS 有 aws CLI。只是它们还没有装上 Agent 大脑------但这只是时间问题。

二、Skill 的一键生成：从"专家手写"到"对话生成"

2.1 当前 Skill 的创建方式

今天创建一个 Skill，你需要：

  1. 理解业务流程
  2. 手写 SKILL.md
  3. 编写辅助脚本
  4. 测试调试
  5. 发布到 Skill 市场

这其实跟"写代码"差不多------只是语言从 Python/TypeScript 变成了 Markdown + 自然语言。

但问题来了：如果 Skill 的本质是"教 AI 怎么做事"，那 AI 自己能不能生成 Skill？

2.2 Skill 应该可以一键生成

答案是肯定的。来看一个具体场景：

sequenceDiagram actor User as 用户 participant CLI as CLI Agent participant LLM as LLM participant SkillGen as Skill 生成器 participant Registry as Skill 注册表 User->>CLI: 我想创建一个客户投诉处理的 Skill CLI->>LLM: 分析需求 生成 Skill 草案 LLM->>CLI: 返回 SKILL.md 初稿 CLI->>User: 展示草案 确认修改 User->>CLI: 加一步 投诉升级到主管 CLI->>LLM: 修改 Skill LLM->>CLI: 更新后的 SKILL.md CLI->>SkillGen: 生成 Skill 文件夹结构 SkillGen->>Registry: 注册到本地 Skill 库 Registry-->>CLI: 注册成功 CLI->>User: Skill 已创建并加载 User->>CLI: 收到一条客户投诉 订单延迟三天 CLI->>LLM: 匹配到 complaint-handling Skill LLM->>CLI: 按 Skill 流程自动处理

关键洞察：Skill 生成本身就是一个 Skill。我们可以有一个 "meta-skill"------一个专门用来生成其他 Skill 的 Skill。

2.3 Skill 的生成管线

一个实用的 Skill 自动生成管线长这样：

flowchart TD subgraph INPUT_BOX["输入源 · 任选其一"] I1["自然语言描述"] I2["现有 API 文档"] I3["录屏操作记录"] I4["已有 SOP 文档"] end INPUT_BOX --> ANALYZE["意图分析"] ANALYZE --> EXTRACT_BOX subgraph EXTRACT_BOX["结构化提取"] E1["触发条件"] E2["操作步骤"] E3["依赖工具 MCP"] E4["异常处理"] E5["输出格式"] end EXTRACT_BOX --> GENERATE["生成 SKILL.md"] GENERATE --> VALIDATE_BOX subgraph VALIDATE_BOX["自动验证"] V1["语法检查"] V2["MCP 可达性测试"] V3["模拟执行 dry-run"] end VALIDATE_BOX --> PUBLISH_BOX subgraph PUBLISH_BOX["发布注册"] P1["本地 Skill 库"] P2["团队 Skill Hub"] P3["公开 Skill 市场"] end style INPUT_BOX fill:#e0e7ff,stroke:#6366f1 style EXTRACT_BOX fill:#fef3c7,stroke:#f59e0b style VALIDATE_BOX fill:#d1fae5,stroke:#10b981 style PUBLISH_BOX fill:#fce7f3,stroke:#ec4899

2.4 表单 Skill 的例子

你提到的"创建某个表单的 Skill"，来看具体实现：

bash 复制代码 
$ my-app-cli "生成一个客户登记表单的 Skill"

AI 自动生成：

markdown 复制代码 
---
name: customer-registration-form
description: >
  创建和管理客户登记信息。当用户要求"登记客户""添加新客户"
  "录入客户信息"时激活。
triggers:
  - 登记客户
  - 添加客户
  - 新客户录入
---

## 必填字段

| 字段 | 类型 | 校验规则 |
|------|------|---------|
| 姓名 | string | 非空，2-50字符 |
| 手机号 | string | 11位手机号格式 |
| 公司名称 | string | 非空 |
| 来源渠道 | enum | [线上推广/转介绍/自然流量/BD拓展] |

## 操作流程

1. 收集用户提供的客户信息
2. 校验字段完整性和格式
3. 若信息不完整，逐个询问缺失字段
4. 调用 CRM 接口创建客户 → [MCP: crm-server]
5. 返回创建结果（客户ID + 摘要）

## 对话示例

用户："帮我登记个客户，张三，电话 13800138000，XX科技公司，BD介绍来的"
→ 提取：姓名=张三，手机=13800138000，公司=XX科技，来源=BD拓展
→ 调用 CRM API 创建
→ 返回："已创建客户 张三（ID: C-20260415），来源：BD拓展"

从此你只需说一句话就能创建一条客户记录。表单不再是一个页面，而是一段对话。

三、Skill 精准调用的秘诀：当 Skill 成千上万时

3.1 问题的本质

这是整篇文章最核心的技术问题。当一个 CLI Agent 加载了上千个 Skill，用户说"帮我请个假"------Agent 怎么知道该调用 leave-application 而不是 time-off-query 或 attendance-report？

这本质上是一个 信息检索 + 语义匹配 + 上下文决策 的复合问题。

3.2 三层漏斗架构

精准调用的秘诀在于不要让模型一次看到所有 Skill ，而是用三层漏斗逐步缩小范围：

flowchart TD USER["用户输入 帮我请个假"] --> L1 subgraph L1["第一层 · 关键词分类过滤"] direction LR L1A["全部 Skill 索引
5000 个"] --> L1B["按类别关键词
快速过滤"] L1B --> L1C["候选 Skill
~50 个"] end L1 --> L2 subgraph L2["第二层 · 语义排序"] direction LR L2A["候选 50 个"] --> L2B["Embedding 相似度
+ 使用频率加权"] L2B --> L2C["Top-K Skill
~5 个"] end L2 --> L3 subgraph L3["第三层 · LLM 精选"] direction LR L3A["Top 5 个 Skill
的 name + description"] --> L3B["LLM 理解上下文
精确匹配"] L3B --> L3C["最终选定
1 个 Skill"] end L3 --> LOAD["加载完整 SKILL.md
执行"] style L1 fill:#fee2e2,stroke:#ef4444 style L2 fill:#fef3c7,stroke:#f59e0b style L3 fill:#d1fae5,stroke:#10b981 style LOAD fill:#6366f1,color:#fff

每一层的设计意图：

层级 方法 输入规模 输出规模 延迟 作用
L1: 过滤 关键词 + 分类标签 + 倒排索引 5000 ~50 <5ms 排除明显不相关的
L2: 排序 Embedding 余弦相似度 + 频率 ~50 ~5 <20ms 语义级粗排
L3: 精选 LLM 读 description 决策 ~5 1 ~200ms 上下文级精排

总延迟 < 250ms，比你打开一个网页还快。

3.3 Skill 的元数据设计：精准调用的基础

精准调用的前提是 Skill 有足够好的元数据。一个高质量的 Skill 索引条目应该包含：

yaml 复制代码 
┌──────────────────────────┐
│      SkillMetadata       │
├──────────────────────────┤
│ + name: string           │
│ + description: string    │
│ + triggers: string[]     │
│ + categories: string[]   │
│ + keywords: string[]     │
│ + embedding: float[]     │
│ + usageCount: int        │
│ + successRate: float     │
│ + requiredMCPs: string[] │
│ + conflictsWith: string[]│
│ + lastUsed: datetime     │
└──────────┬───────────────┘
           │ 被索引
           ▼
┌──────────────────────────────────────┐
│            SkillIndex                │
├──────────────────────────────────────┤
│ + skills: Map<string, SkillMetadata> │
│ + keywordIndex: InvertedIndex        │
│ + embeddingIndex: VectorIndex        │
│ + categoryTree: CategoryTree         │
├──────────────────────────────────────┤
│ + add(skill)                         │
│ + search(query): SkillMetadata[]     │
│ + rank(candidates, ctx): Metadata[]  │
└──────────┬───────────────────────────┘
           │ 被路由器使用
           ▼
┌──────────────────────────────────────┐
│            SkillRouter               │
├──────────────────────────────────────┤
│ + index: SkillIndex                  │
│ + llm: LLM                          │
├──────────────────────────────────────┤
│ + resolve(input, ctx): Skill         │
│ - filterByKeyword(input): Metadata[] │
│ - rankBySemantic(cands): Metadata[]  │
│ - selectByLLM(topK, ctx): Metadata   │
└──────────────────────────────────────┘

3.4 六个精准调用的工程技巧

技巧一：Trigger 短语比 Description 更重要

yaml 复制代码 
# ❌ 只有 description
description: "处理员工请假申请流程"

# ✅ 加上 trigger 短语
description: "处理员工请假申请流程"
triggers:
  - "请假"
  - "休假"
  - "请个假"
  - "想休息几天"
  - "年假"
  - "病假"
  - "事假"

Trigger 是用户最可能说出的那些话。它不需要完美------只需要覆盖高频表达。

技巧二：层级分类 + 命名空间

r 复制代码 
skills/
├── hr/                    # 人力资源类
│   ├── leave-apply        # 请假
│   ├── leave-query        # 查假
│   └── attendance-report  # 考勤
├── finance/               # 财务类
│   ├── expense-submit     # 报销
│   └── budget-query       # 预算
├── crm/                   # 客户管理类
│   ├── customer-create    # 创建客户
│   └── order-track        # 订单追踪
└── devops/                # 运维类
    ├── deploy-prod        # 生产部署
    └── rollback           # 回滚

分类让第一层过滤效率大幅提升------如果上下文已经在"HR"话题里，直接把其他类别的 Skill 全部跳过。

技巧三：上下文感知------记住用户在"聊什么"

stateDiagram-v2 [*] --> Idle: 初始状态 Idle --> HR_Context: 请假 or 考勤 Idle --> Finance_Context: 报销 or 预算 Idle --> CRM_Context: 客户 or 订单 HR_Context --> HR_Context: 后续请求优先匹配 HR Skill Finance_Context --> Finance_Context: 后续请求优先匹配 Finance Skill CRM_Context --> CRM_Context: 后续请求优先匹配 CRM Skill HR_Context --> Idle: 话题切换 超时或明确切换 Finance_Context --> Idle: 话题切换 CRM_Context --> Idle: 话题切换

当用户刚说了"帮我请个假"，紧接着又说"顺便帮我看看剩几天"------第二句不包含任何明确关键词，但上下文暗示了它是"查询剩余年假"，而不是"查看剩余预算"。

技巧四：使用频率加权------越常用的排越前

ini 复制代码 
score = semantic_similarity * 0.6 + usage_frequency * 0.2 + recency * 0.1 + success_rate * 0.1

一个每天被调用 50 次的 Skill 和一个半年没人用的 Skill，在语义相似度接近时，前者应该优先。

技巧五：冲突检测------避免歧义

当多个 Skill 得分非常接近时（差距 < 阈值），不要猜，要问：

markdown 复制代码 
用户：帮我看一下张三的情况

CLI：我找到了两个可能匹配的操作：
  1. 📋 查看员工档案（HR 系统）
  2. 🤝 查看客户详情（CRM 系统）
请问你指的是哪一个？

技巧六：学习与反馈------越用越准

flowchart LR A["用户选择 Skill"] --> B["执行"] B --> C{"执行成功"} C -- "是" --> D["正向反馈
+1 权重"] C -- "否" --> E["用户纠正
选错了"] E -- "选错了" --> F["负向反馈
调整关联"] E -- "Skill 有 bug" --> G["标记问题
通知维护者"] D & F --> H["更新 Skill 索引权重"]

3.5 类比：Skill 调度就是"大脑的注意力机制"

如果把 CLI Agent 想象成一个大脑：

flowchart TD subgraph BRAIN["CLI Agent 的大脑"] direction TB subgraph LONG["长期记忆 = Skill 索引"] S1["5000 个 Skill"] end subgraph ATTENTION["注意力机制 = 三层漏斗"] A1["关键词触发"] A2["语义匹配"] A3["LLM 精选"] end subgraph WORKING["工作记忆 = 当前加载的 Skill"] W1["1-3 个活跃 Skill"] end LONG --> ATTENTION ATTENTION --> WORKING end INPUT["用户输入"] --> ATTENTION WORKING --> OUTPUT["执行输出"]

人脑也不会同时想着自己会的所有事情------你说"做饭"，大脑不会同时激活"开车""写代码""游泳"的记忆。它会先按类别过滤，再按语境匹配，最后精确激活。

Skill 精准调用的本质，就是为 CLI Agent 实现一套人工的"注意力机制"。

四、CLI Agent 的开发：难度、架构与设计

4.1 开发难度：没你想象的那么大

先说结论：一个基础的 CLI Agent，一个全栈工程师一周可以做出来。 但要做到生产级，需要 2-4 周。

难度分级：

markdown 复制代码 
                        CLI Agent 开发难度 vs 价值矩阵

    业务价值高 ▲
              │  ┌─────────────────────┬──────────────────────┐
              │  │    优先实现          │     重点投入          │
              │  │                     │                      │
              │  │  • Skill 加载机制    │  • Skill 精准路由     │
              │  │  • MCP 工具连接      │  • Skill 自动生成     │
              │  │                     │  • 权限与安全         │
              │  ├─────────────────────┼──────────────────────┤
              │  │    按需开发          │     谨慎评估          │
              │  │                     │                      │
              │  │  • 基础对话循环      │  • 多 Agent 编排      │
              │  │  • 流式输出          │  • 离线能力           │
              │  │  • GUI 壳            │                      │
              │  └─────────────────────┴──────────────────────┘
    业务价值低 └───────────────────────────────────────────────▶
              开发难度低                              开发难度高

4.2 核心架构设计

一个生产级 CLI Agent 的架构分 5 层：

css 复制代码 
┌──────────────────────────────────────────────────────────────┐
│                   Layer 1 · CLI 输入层                         │
│           终端交互  /  流式 I/O  /  管道  /  REPL              │
├──────────────────────────────────────────────────────────────┤
│                   Layer 2 · Agent 循环核心                     │
│       消息收发 → LLM 调用 → 工具执行 → 结果反馈 → 循环         │
├──────────────┬──────────────────┬────────────────────────────┤
│  Layer 3a    │   Layer 3b       │   Layer 3c                 │
│  Skill 路由器 │   Skill 加载器    │   Skill 注册表              │
│  三层漏斗匹配 │   渐进式披露      │   索引 + 元数据             │
├──────────┬───┴──────┬───────────┴───┬────────────────────────┤
│ Layer 4  │          │               │                        │
│ MCP      │ MCP      │  内置工具      │  Function Calling      │
│ Server A │ Server B │  (文件/HTTP)   │  (原子调用)             │
├──────────┴──────────┴───────────────┴────────────────────────┤
│                   Layer 5 · 基础设施                           │
│       认证鉴权   ·   日志审计   ·   配置管理   ·   插件系统     │
└──────────────────────────────────────────────────────────────┘

4.3 从零开始的技术选型

flowchart TD START["选择技术栈"] --> LANG{"开发语言"} LANG --> TS["TypeScript Node.js"] LANG --> GO["Go"] LANG --> RUST["Rust"] LANG --> PYTHON["Python"] TS --> TS_PRO["npm 生态完善
MCP SDK 官方支持
用户安装方便
启动速度一般"] GO --> GO_PRO["单二进制分发
启动极快
AI LLM 生态弱"] RUST --> RUST_PRO["性能极致
单二进制
开发速度慢"] PYTHON --> PY_PRO["AI ML 生态最强
分发困难
依赖管理复杂"] TS_PRO --> REC["推荐 TypeScript"] GO_PRO --> REC RUST_PRO -.-> REC PY_PRO -.-> REC REC --> WHY["npm 一键安装 + MCP 官方 SDK
Agent 生态都在 TS 上"] style REC fill:#10b981,color:#fff style WHY fill:#6366f1,color:#fff

4.4 核心模块实现

模块一：Agent Loop（核心循环）

这是整个 CLI 的心脏。Claude Code 的 512K 泄露源码告诉我们，生产级 Agent Loop 其实惊人的简单：

typescript 复制代码 
async function agentLoop(userMessage: string, context: ConversationContext) {
  context.addMessage({ role: "user", content: userMessage });

  while (true) {
    // 1. 组装消息 + 系统提示 + 已加载的 Skill
    const messages = context.buildMessages();
    const tools = skillRouter.getActiveTools(context);

    // 2. 调用 LLM
    const response = await llm.chat({ messages, tools, stream: true });

    // 3. 处理响应
    for await (const chunk of response) {
      if (chunk.type === "text") {
        process.stdout.write(chunk.text);
      }
      if (chunk.type === "tool_call") {
        const result = await toolExecutor.execute(chunk.toolCall);
        context.addToolResult(chunk.toolCall.id, result);
      }
    }

    // 4. 判断是否继续循环
    if (!response.hasToolCalls) break;
    if (context.budgetExceeded()) break;
  }
}

模块二：Skill Router（路由器）

typescript 复制代码 
class SkillRouter {
  private index: SkillIndex;
  private llm: LLMClient;

  async resolve(input: string, context: ConversationContext): Promise<Skill> {
    // L1: 关键词 + 分类过滤
    const candidates = this.index.filterByKeywordsAndCategory(
      input,
      context.currentCategory
    );

    // L2: 语义排序
    const topK = await this.index.rankBySemantic(input, candidates, 5);

    // L3: LLM 精选（仅当候选 > 1 时）
    if (topK.length === 1) return topK[0];

    const selected = await this.llm.selectSkill(input, topK, context);
    return selected;
  }
}

模块三：Skill Loader（渐进式加载器）

typescript 复制代码 
class SkillLoader {
  // 三层渐进加载
  async loadForDiscovery(skillId: string): Promise<SkillSummary> {
    // ~100 tokens: name + description + triggers
    return this.registry.getSummary(skillId);
  }

  async loadForActivation(skillId: string): Promise<SkillFull> {
    // <5000 tokens: 完整 SKILL.md 内容
    return this.registry.getFullContent(skillId);
  }

  async loadForExecution(skillId: string): Promise<SkillRuntime> {
    // 加载关联脚本和工具定义
    return this.registry.getRuntime(skillId);
  }
}

4.5 开发路线图

flowchart LR subgraph W1["Week 1 · 最小可用"] direction TB W1A["Agent Loop 核心循环"] W1B["基础 Skill 加载"] W1C["1-2 个内置工具"] W1D["终端 IO + 流式输出"] end subgraph W2["Week 2 · 能力扩展"] direction TB W2A["MCP 客户端"] W2B["Skill 路由器"] W2C["配置系统"] W2D["错误处理与重试"] end subgraph W3["Week 3 · 生产加固"] direction TB W3A["权限控制"] W3B["日志审计"] W3C["Skill 自动生成"] W3D["使用反馈系统"] end subgraph W4["Week 4 · 生态建设"] direction TB W4A["Skill 市场 Hub"] W4B["插件机制"] W4C["npm 发布"] W4D["文档 + 示例"] end W1 --> W2 --> W3 --> W4

4.6 一个极简 CLI Agent 的目录结构

bash 复制代码 
my-agent-cli/
├── package.json
├── tsconfig.json
├── src/
│   ├── index.ts                 # CLI 入口
│   ├── agent/
│   │   ├── loop.ts              # Agent 核心循环
│   │   ├── context.ts           # 对话上下文管理
│   │   └── budget.ts            # 预算/限流控制
│   ├── skill/
│   │   ├── router.ts            # Skill 三层路由
│   │   ├── loader.ts            # 渐进式加载器
│   │   ├── registry.ts          # Skill 注册表
│   │   ├── generator.ts         # Skill 自动生成
│   │   └── index.ts             # Skill 索引与检索
│   ├── tool/
│   │   ├── executor.ts          # 工具执行引擎
│   │   ├── mcp-client.ts        # MCP 协议客户端
│   │   └── builtin/             # 内置工具
│   │       ├── file.ts
│   │       ├── http.ts
│   │       └── shell.ts
│   ├── llm/
│   │   ├── client.ts            # LLM API 封装
│   │   ├── stream.ts            # 流式处理
│   │   └── providers/           # 多模型支持
│   │       ├── openai.ts
│   │       ├── anthropic.ts
│   │       └── ollama.ts
│   └── config/
│       ├── settings.ts          # 配置加载
│       └── auth.ts              # 认证管理
├── skills/                      # 内置 Skill
│   ├── help/
│   │   └── SKILL.md
│   └── skill-generator/
│       └── SKILL.md
└── README.md

五、用 CLI + Skill 重做你的软件

5.1 心智模型转换

传统软件和 CLI + Skill 软件的根本区别不在于技术实现，而在于交互范式的转换：

flowchart LR subgraph OLD["传统软件思维 · 设计驱动"] direction TB O1["页面"] --> O2["表单"] O2 --> O3["按钮"] O3 --> O4["API 调用"] O4 --> O5["结果展示"] end subgraph NEW["CLI + Skill 思维 · 意图驱动"] direction TB N1["意图"] --> N2["Skill 匹配"] N2 --> N3["信息补全"] N3 --> N4["MCP 执行"] N4 --> N5["结果返回"] end OLD -- "范式迁移" --> NEW style OLD fill:#fee2e2,stroke:#ef4444 style NEW fill:#d1fae5,stroke:#10b981

5.2 重做的六步法

flowchart TD S1["Step 1
功能盘点"] --> S2["Step 2
API 标准化"] S2 --> S3["Step 3
MCP 封装"] S3 --> S4["Step 4
Skill 编写"] S4 --> S5["Step 5
CLI 搭建"] S5 --> S6["Step 6
渐进替换"] S1 --- D1["列出所有功能点
标记使用频率"] S2 --- D2["确保每个功能
都有 REST API"] S3 --- D3["把 API 包装成
MCP Server"] S4 --- D4["为每个高频操作
编写 SKILL.md"] S5 --- D5["搭建 CLI Agent
注册所有 Skill"] S6 --- D6["CLI 与 GUI 并行
逐步迁移用户"] style S1 fill:#6366f1,color:#fff style S2 fill:#8b5cf6,color:#fff style S3 fill:#a855f7,color:#fff style S4 fill:#c084fc,color:#fff style S5 fill:#d8b4fe,color:#000 style S6 fill:#e9d5ff,color:#000

5.3 以一个 CRM 系统为例：完整重做过程

假设你有一个中型 CRM 系统，包含：客户管理、商机跟进、合同管理、报表分析。

Step 1：功能盘点

功能模块 高频操作 当前入口 Skill 化优先级
客户管理 创建客户 填 10 个字段的表单 P0
客户管理 查询客户 搜索框 + 筛选器 P0
商机跟进 更新商机阶段 拖拽看板 P1
商机跟进 添加跟进记录 弹窗表单 P0
合同管理 创建合同 复杂多步表单 P1
报表分析 查看销售漏斗 图表页面 P2

Step 2-3：API + MCP 封装

flowchart LR subgraph CRM["现有 CRM 系统"] API1["api customers"] API2["api opportunities"] API3["api contracts"] API4["api reports"] end subgraph MCP_LAYER["MCP Server 层"] M1["crm-customer-mcp"] M2["crm-opportunity-mcp"] M3["crm-contract-mcp"] M4["crm-report-mcp"] end API1 --> M1 API2 --> M2 API3 --> M3 API4 --> M4 subgraph AGENT["CLI Agent"] SK["Skill 路由器"] end M1 & M2 & M3 & M4 --> SK

Step 4：Skill 编写（以"添加跟进记录"为例）

markdown 复制代码 
---
name: add-follow-up
description: 为商机添加跟进记录。当用户提到"跟进""回访""联系客户"时激活。
triggers: [跟进, 回访, 联系客户, 拜访记录, 沟通记录]
requiredMCPs: [crm-opportunity-mcp]
---

## 流程

1. 确认客户/商机（从上下文推断或询问）
2. 收集跟进内容（方式、结果、下一步）
3. 调用 MCP 创建跟进记录
4. 返回确认 + 该商机当前状态摘要

## 必要信息

| 字段 | 必填 | 默认值 |
|------|------|-------|
| 商机名称/客户 | 是 | 从上下文推断 |
| 跟进方式 | 否 | "电话" |
| 跟进内容 | 是 | - |
| 下一步计划 | 否 | - |

## 对话示例

用户："今天跟张三聊了下，他对方案很感兴趣，下周安排上门演示"
→ 提取：客户=张三，方式=电话，内容=对方案感兴趣，下一步=下周上门演示
→ 创建跟进记录，返回确认

Step 5-6：效果对比

sequenceDiagram actor User as 销售 participant GUI as CRM 网页 participant Agent as CLI Agent rect rgb(254, 226, 226) Note over User,GUI: 传统方式 约 3 分钟 User->>GUI: 打开 CRM 网页 User->>GUI: 搜索客户 张三 User->>GUI: 点击进入商机详情 User->>GUI: 点击 添加跟进 User->>GUI: 填写表单 方式 内容 日期 下一步 User->>GUI: 点击保存 GUI-->>User: 保存成功 end rect rgb(209, 250, 229) Note over User,Agent: CLI Skill 方式 约 10 秒 User->>Agent: 今天跟张三聊了 他对方案很感兴趣 下周安排上门演示 Agent-->>User: 已为商机 张三XX项目 添加跟进记录 下一步提醒已设置 end

5.4 并行世界：CLI 不是替代 GUI，而是共存

一个常见误解是"做了 CLI 就不要 GUI 了"。不是这样的------CLI 和 GUI 应该共享同一层 API/MCP，各自服务不同场景：

flowchart TD subgraph USERS["用户入口"] WEB["Web GUI
可视化操作 报表"] CLI["CLI Agent
快速操作 批量处理"] API_DIRECT["直接 API 调用
系统集成"] CHATBOT["IM 机器人
钉钉 企微 飞书"] end subgraph MIDDLE["统一能力层"] SKILL_HUB["Skill Hub"] MCP_HUB["MCP Gateway"] end subgraph BACKEND["业务系统"] DB["数据库"] SERVICE["业务服务"] QUEUE["消息队列"] end WEB & CLI & API_DIRECT & CHATBOT --> SKILL_HUB SKILL_HUB --> MCP_HUB MCP_HUB --> DB & SERVICE & QUEUE

Skill 和 MCP 是能力层，CLI/GUI/IM Bot 是交付渠道。 一次编写 Skill，多渠道复用。

六、终局猜想：软件架构的范式迁移

6.1 从"页面驱动"到"意图驱动"

我们正在经历软件交互范式的第三次大迁移：

timeline title 软件交互范式的三次迁移 section 命令驱动 1970-1995 : CLI + 命令 : 用户需要记住命令 : 效率高但门槛高 : 面向专家 section 页面驱动 1995-2025 : GUI + 表单 + 按钮 : 所见即所得 : 门槛低但效率受限 : 面向大众 section 意图驱动 2025- : 自然语言 + Agent : 说什么就做什么 : 门槛最低 + 效率最高 : 面向所有人

6.2 未来软件的标准架构

如果这个趋势成立，未来每个软件的架构会趋同于以下模式：

flowchart TD subgraph INTERFACE["交互层 · 多渠道"] direction LR I1["CLI Agent"] I2["Web GUI"] I3["Mobile App"] I4["IM Bot"] I5["Voice Assistant"] end subgraph INTELLIGENCE["智能层 · Skill + LLM"] direction TB ROUTER["Skill 路由器
三层漏斗 + 上下文感知"] SKILLS["Skill 库
所有业务操作的标准化指令"] LLM_ENGINE["LLM 引擎
理解 + 推理 + 决策"] end subgraph CAPABILITY["能力层 · MCP + API"] direction LR MCP_GW["MCP Gateway"] A2A_HUB["A2A Hub
Agent 间协作"] end subgraph BUSINESS["业务层 · 存量系统"] direction LR B1["ERP"] B2["CRM"] B3["OA"] B4["数据库"] B5["文件系统"] B6["第三方 SaaS"] end INTERFACE --> INTELLIGENCE INTELLIGENCE --> CAPABILITY CAPABILITY --> BUSINESS style INTERFACE fill:#e0e7ff,stroke:#6366f1 style INTELLIGENCE fill:#fef3c7,stroke:#f59e0b style CAPABILITY fill:#d1fae5,stroke:#10b981 style BUSINESS fill:#fee2e2,stroke:#ef4444

6.3 五条思考路径的终极答案

回到开头的五个问题：

mindmap root((CLI + Skill 五大问题)) Q1 每个软件都需要 CLI 吗 CLI 是 Agent 的天然形态 CLI 不替代 GUI 而是共存 先 CLI 后 GUI 就像 Git 先于 GitHub Q2 Skill 能一键生成吗 可以 Skill 生成本身就是一个 Skill 输入 自然语言 API 文档 SOP 输出 完整的 SKILL.md 和脚本 Q3 Skill 太多怎么精准调用 三层漏斗 关键词过滤 语义排序 LLM 精选 上下文感知 加 使用频率加权 本质是给 Agent 实现注意力机制 Q4 CLI 开发难度大吗 不大 核心是一个 while 循环 推荐 TypeScript 加 npm 分发 4 周可达生产级 Q5 怎么用这套逻辑重做软件 六步法 盘点 API MCP Skill CLI 渐进替换 Skill 是能力层 CLI GUI 是渠道层 一次编写 多渠道复用

6.4 这不是预测，这是正在发生的事

2026 年 Q2 的此刻：

  • Anthropic 的 Agent Skills 已被 27+ 工具采纳
  • MCP 协议月下载量 9700 万+
  • OpenClaw 的 ClawHub 已有 5700+ Skill
  • Vercel、Stripe、Cloudflare 都在给自己的 CLI 加 Agent 能力
  • 企业内部的 MCP Server 建设正在加速

不是"要不要做"的问题，而是"什么时候开始做"的问题。

七、给不同角色的行动建议

7.1 如果你是开发者

行动 时间 产出
学习 SKILL.md 规范 2 小时 能手写 Skill
用现有 CLI（Claude Code / Codex）体会 Skill 机制 1 天 理解 Agent 如何使用 Skill
为自己的项目写 3 个 Skill 1 天 实际感受效率提升
搭建一个最小 CLI Agent Demo 1 周 掌握核心架构

7.2 如果你是技术负责人

行动 优先级 产出
盘点现有系统 API 资产 P0 API 可 MCP 化清单
试点 1 个业务流程的 Skill 化 P0 效果验证数据
评估 CLI Agent 方案（自建 vs 集成） P1 技术选型报告
建立内部 Skill 编写规范 P1 团队统一标准
规划 MCP Server 建设路线 P2 中长期路线图

7.3 如果你是产品经理

重新思考"功能"的定义。 过去你设计的是"页面 + 表单 + 按钮"；未来你设计的是"意图 + Skill + 对话流"。

objectivec 复制代码 
过去：用户故事 → 原型图 → UI 设计 → 前端开发 → 联调 → 上线
未来：用户意图 → SKILL.md → MCP 对接 → 测试 → 上线

Skill 就是新时代的 PRD。

八、结语：软件的终极形态是对话

回到最初的思考------

各大厂的 CLI Agent 不是技术团队的玩具，它们指向一个清晰的未来：软件不再是你"打开然后操作"的东西，而是你"说一句话然后它自己完成"的东西。

实现这个未来需要三样东西：

  • CLI（Agent 的壳）------ 接收意图，返回结果
  • Skill（Agent 的脑）------ 知道怎么做，什么时候做
  • MCP（Agent 的手）------ 连接系统，执行操作

Skill 精准调用的秘诀不是什么高深算法，而是一个朴素的工程实践：三层漏斗 + 好的元数据 + 上下文感知 + 用户反馈。 本质上就是给 Agent 装一套"注意力机制"。

CLI 的开发难度也没有想象中那么大------核心是一个 while 循环，生态已经足够成熟，TypeScript + npm 两周可以交付一个可用版本。

真正难的不是技术，而是思维的转换：从"设计页面"到"设计意图"，从"做表单"到"写 Skill"，从"用户操作系统"到"用户跟系统对话"。

这场范式迁移才刚刚开始。现在入场，还来得及。

本文系技术探索性文章，欢迎探讨交流。

最后更新：2026 年 4 月

相关推荐
梦醒江南2 小时前
从调参到调水：OpenClaw深度技术指南——如何科学“饲养”你的AI小龙虾
人工智能
穿条秋裤到处跑82 小时前
java2AI系列：SpringAI 通过 Function Calling 接入外部系统
java·人工智能
qq_381338502 小时前
2026 年 AI 编程助手全面对比评测：Cursor vs Copilot vs Claude Code vs GitHub Copilot Free
人工智能·github·copilot
W_Pan2 小时前
我给 miniONNXRuntime 做了 mac + CUDA 的 EP，这里是实现思路
人工智能
东离与糖宝2 小时前
医疗辅助 Agent：病历解读、文献检索、指南对照
人工智能
天一生水water2 小时前
机器学习中的小提琴图有什么作用
人工智能·机器学习
古城小栈2 小时前
Rust在当下AI领域的用武之地：从底层加速到上层应用全解析
开发语言·人工智能·rust
一次旅行2 小时前
2026最新AI编程模式总结
人工智能
东离与糖宝2 小时前
泛化能力基础：AI 适应新数据的关键
人工智能
热门推荐
012026年4月技术前沿：AI大模型爆发、智能体革命与量子安全新纪元02GitHub 镜像站点03一周AI热点速览（2026.03.31-04.06）：GPT-6曝光、谷歌开源Gemma 4、资本狂飙与模型军备竞赛04GPT-6核心能力解析及与现有主流大模型对比05基于 Docker 部署 Hermes Agent 并接入飞书机器人的完整指南06GPT-6发布日深度解析-Symphony架构200万Token实战07零成本！Ollama本地部署国产大模型全指南（支持Kimi-K2.5/GLM-5/Qwen，新手秒上手）08AI Weekly | 2026年4月第二周 · GitHub热门项目与AI发展趋势深度解析09从限购到畅通：GLM-5.1 Coding Plan接入攻略10免费！不限量！用opencode接入英伟达（NVIDIA）大模型，轻松打造你的 AI 编程助手