Claude Skills 如何把 AI Agent 从聊天工具推向可复用工作流

AI Agent 真正难的地方，不是让模型回答一个问题，而是让它稳定完成一类工作。

比如“帮我生成一份周报”，简单问答模型可以写一段文字；但真实任务通常还包括读取项目数据、统计指标、按团队模板排版、检查缺失字段、导出 PDF、发送给指定对象。只靠一句提示词，很难保证每次都按同样的流程执行。

Claude Skills 解决的正是这个问题：把某类任务的操作规范、注意事项、脚本和参考资料打包成一个“技能包”，让模型在需要时读取并执行。它不是重新训练模型，也不是给模型加一个固定按钮，而是在运行时给模型一套可理解、可调用、可复用的工作方法。

AI 普及的根本原因：使用门槛被压低了

早期谈 AI，重点常常是算法、模型结构、训练数据和算力。只有具备机器学习背景的人，才比较容易把 AI 用到实际系统里。

现在情况完全不同。普通用户打开一个应用，说一句自然语言，就能调用大模型完成搜索、写作、翻译、编程、图片理解等任务。开发者也不一定要自己训练模型，调用 API 就可以把大模型能力接入产品。

这个变化背后有三层门槛下降：

AI Coding 又进一步降低了开发门槛。代码补全、上下文问答、错误解释、单元测试生成、重构建议，这些能力让更多人可以更快把想法变成可运行的软件。

但门槛降低也带来一个新问题：如果所有能力都藏在自然语言对话里，流程就很容易失控。一次能做对，不代表十次都能做对；单人能用，不代表团队能沉淀成规范。Skills 的价值就在这里，它把“经验”从临时提示词里抽出来，变成可维护的文件。

MCP 和 Skills 解决的是两类不同问题

MCP（Model Context Protocol，模型上下文协议）和 Skills 经常一起出现，但它们解决的不是同一个问题。

MCP 更像是“外部世界的标准插座”。它规定 AI Agent 如何连接数据库、文件系统、浏览器、Git 仓库、业务系统等外部资源。只要工具提供方按 MCP 暴露能力，Agent 就可以用统一方式发现工具、读取上下文、发起调用。

Skills 更像是“完成任务的操作手册”。它告诉模型在某个任务里应该遵守什么流程、调用哪些工具、检查哪些异常、输出什么格式。

二者的关系可以这样理解：

flowchart LR
    U[用户需求] --> A[AI Agent]

    A --> S[Skills: 任务流程和操作规范]
    A --> M[MCP: 外部工具和上下文接口]

    S --> A
    M --> T1[(文件系统)]
    M --> T2[(数据库)]
    M --> T3[(Git 仓库)]
    M --> T4[(业务 API)]

    A --> R[交付结果]

MCP 解决“能连什么、怎么连”的问题，Skills 解决“什么时候连、为什么连、连完后怎么处理”的问题。

举个例子：

• MCP 暴露一个 query_database 工具，允许模型查询数据库。
• Skill 规定“生成销售周报时，先查订单表，再按地区聚合，缺失数据要标记为 unknown，最后按固定模板输出”。

没有 MCP，模型很难安全、规范地调用外部系统；没有 Skills，模型即使能调用工具，也可能不知道正确的业务流程。

Claude Skills 的本质：把任务经验文件化

一个 Skill 通常由 Markdown 文档、脚本、模板和参考资料组成。最核心的文件是 SKILL.md，里面描述技能名称、适用场景、执行步骤和注意事项。

一个简化的目录可能长这样：

weekly-report-skill/
├── SKILL.md
├── scripts/
│   └── build_report.py
├── templates/
│   └── weekly_report.md
└── examples/
    └── sample_output.md

SKILL.md 可以写成这样：

---
name: weekly-report
description: 当用户需要生成项目周报、团队周报或研发进度汇总时使用。
---

# 周报生成流程

1. 确认周报时间范围。
2. 读取任务系统中的完成项、延期项和风险项。
3. 按“本周完成 / 进行中 / 风险与阻塞 / 下周计划”组织内容。
4. 如果数据缺失，不要编造；用“未提供”标记。
5. 输出 Markdown 格式，并保持标题层级稳定。

# 可用脚本

- scripts/build_report.py：根据 JSON 数据生成标准周报。

脚本负责确定性更强的部分：

import json
from pathlib import Path

def build_report(data_path: str) -> str:
    data = json.loads(Path(data_path).read_text(encoding="utf-8"))

    done = data.get("done", [])
    doing = data.get("doing", [])
    risks = data.get("risks", [])
    plans = data.get("plans", [])

    def section(title, items):
        if not items:
            return f"## {title}\n\n- 未提供\n"
        return f"## {title}\n\n" + "\n".join(f"- {item}" for item in items) + "\n"

    return "\n".join([
        "# 项目周报",
        section("本周完成", done),
        section("进行中", doing),
        section("风险与阻塞", risks),
        section("下周计划", plans),
    ])

Markdown 负责让模型理解业务语义，脚本负责处理格式化、计算、校验等确定性任务。二者结合后，Agent 不只是“知道怎么说”，还可以“按规矩做”。

Skills 的运行机制：按需加载，而不是把所有知识塞进提示词

如果把所有规范都写进系统提示词，提示词会越来越长，模型上下文会被大量无关内容占用。Skills 更适合按需加载：模型先根据用户需求判断是否需要某个技能，再读取对应技能文件。

典型流程如下：

flowchart TD
    A[用户提出任务] --> B[模型理解意图]
    B --> C{是否匹配某个 Skill}
    C -- 否 --> D[按普通对话或已有工具处理]
    C -- 是 --> E[读取 Skill 描述]
    E --> F[理解执行步骤和限制条件]
    F --> G{是否需要外部工具}
    G -- 否 --> H[直接生成结果]
    G -- 是 --> I[调用脚本 / MCP 工具 / 文件资源]
    I --> J[检查输出是否符合 Skill 约束]
    J --> K[返回结果]

这个机制有两个重要效果。

一是节省上下文。模型只在需要时读取相关技能，不必每次都携带全部业务规范。

二是便于团队维护。流程变化时，不需要重新训练模型，也不需要修改复杂代码，只要更新 Skill 文件和配套脚本即可。

需要注意，Skills 不会改变模型权重。它更接近“运行时知识注入”和“任务流程装配”。模型能力仍然来自底层大模型，Skill 负责把能力引导到稳定路径上。

Skills 和传统工作流平台的差别

很多自动化平台也能配置流程，比如可视化编排、RPA（机器人流程自动化）、CI/CD 流水线。Skills 的差异在于，它把“自然语言理解”放进了流程选择和流程执行中。

传统工作流擅长确定性流程，Skills 擅长半结构化任务。比如“把这份合同按公司审查清单检查一遍”，里面既有固定规则，也有大量语义判断，用纯流程节点表达会很复杂，用 Skill 描述反而更自然。

“用 AI 赋能 AI”：从临时提示到可迭代技能库

Skills 让 Agent 有了更清晰的自我迭代入口。

当某个任务频繁出现时，可以把临时对话中的经验沉淀为 Skill；当 Skill 执行效果不稳定时，可以让模型分析失败案例，补充约束、测试样例和校验脚本；当团队流程变化时，可以更新对应 Skill，而不是到处复制新提示词。

这个过程可以形成一个闭环：

flowchart LR
    A[真实任务] --> B[Agent 执行]
    B --> C[结果评测]
    C --> D{是否稳定达标}
    D -- 是 --> E[保留当前 Skill]
    D -- 否 --> F[分析失败原因]
    F --> G[修改说明 / 增加脚本 / 补充样例]
    G --> B

这里的“自举”不是让模型凭空变聪明，也不是自动完成训练，而是把 AI 用在技能维护、流程改写、测试生成和结果评估上。真正上线前仍然需要人类审查，尤其是涉及安全、财务、代码发布、生产数据的场景。

AI Coding 的变化：不是立刻消灭代码，而是改变代码出现的位置

AI 辅助开发已经从“补全几行代码”变成“理解仓库、规划修改、生成测试、解释错误、执行命令”。但这不意味着代码会很快消失。

更现实的变化是：应用层开发会越来越多地用“约束描述”驱动，底层系统仍然需要工程化代码支撑。

过去写一个功能，开发者可能直接进入代码文件：

需求 → 设计接口 → 写代码 → 写测试 → 部署

Agent 参与后，流程会变成：

需求 → 规格说明 → Skill / 工具 / 测试约束 → Agent 生成或修改代码 → 自动验证 → 人工审查

代码没有消失，只是从“人手工逐行编写”更多转向“人定义目标、边界和验收标准，AI 生成实现”。开发者的重点会向几类能力移动：

因此，未来不是“所有人都不需要编程”，而是“更多应用逻辑会通过自然语言、配置和技能描述表达”。越靠近底层的部分，越需要 C/C++、Rust、Go 这类系统级语言能力；越靠近业务应用的部分，越可能被 Agent 和 Skills 抽象掉。

从自动驾驶看 Agent 的另一种演进方向

自动驾驶的发展也能提供一个类比。

早期系统更强调模块拆分：感知模块识别车道线和障碍物，预测模块判断其他车辆轨迹，规划模块计算路径，控制模块执行转向和制动。每个模块都有较强的可解释性，但模块之间误差会累积。

端到端路线试图让模型直接从多模态输入中学习动作决策。VLA（Vision-Language-Action，视觉-语言-动作）模型进一步把视觉、语言理解和动作生成放到同一个框架里，让系统基于世界模型进行推演，再输出行动。

对应到通用 AI Agent，也有类似趋势：

这类系统不再只追求每一步都由人工规则解释，而是更关注闭环结果是否正确、安全、可验证。可解释性仍然重要，但复杂任务中只靠人工规则会越来越难覆盖所有情况。更可行的方式是：让模型负责推演和行动，让评测系统、权限系统、日志系统负责约束和验收。

使用 Skills 时最容易踩的坑

Skills 看起来只是几个 Markdown 文件和脚本，但要稳定用于生产任务，需要处理不少工程细节。

1. Skill 描述不能太泛

如果描述写成“用于处理所有文档任务”，模型很容易误触发。更好的写法是明确场景：

description: 当用户需要把会议记录整理成包含决议、负责人、截止时间的行动项清单时使用。

触发条件越具体，模型越容易判断是否该加载该 Skill。

2. 关键步骤要交给脚本或测试

模型适合理解语义和处理变化，脚本适合做确定性计算。金额计算、字段校验、格式转换、文件命名、重复数据检查，这些部分不要只写在自然语言说明里。

3. 不要让 Skill 拿到过大的权限

如果一个 Skill 可以读写所有文件、访问所有数据库、执行任意命令，风险会被放大。更安全的做法是按任务拆权限：

4. Skill 需要版本管理

技能文件本质上是代码资产，应该放进 Git。每次修改都要能追踪差异，最好配合测试样例：

skills/
├── contract-review/
│   ├── SKILL.md
│   ├── tests/
│   │   ├── case_001.md
│   │   └── expected_001.md
│   └── scripts/
└── weekly-report/

没有版本管理的 Skill 很快会变成另一种“祖传提示词”。

5. 评测比演示更重要

演示只证明某一次成功，评测才能证明一类任务稳定。一个 Skill 至少应该准备几类样例：

• 正常输入
• 缺字段输入
• 格式混乱输入
• 恶意提示注入输入
• 超长上下文输入

尤其是提示注入场景，Skill 必须明确要求模型忽略文档中试图修改系统规则、窃取密钥、越权调用工具的内容。

Claude Skills 代表的方向

Skills 的意义不在于 Markdown 文件本身，而在于它给 AI Agent 提供了一种简单的能力封装方式：

• 用自然语言描述任务经验；
• 用脚本处理确定性步骤；
• 用资源文件提供模板和示例；
• 用 MCP 或其他工具协议连接外部系统；
• 用评测和权限控制保证结果可靠。

这套模式让 AI Agent 不再只是一次性回答问题，而是可以逐步沉淀成团队可维护的技能库。短期看，它会改变 AI Coding、办公自动化、知识管理和数据分析的工作方式；长期看，越来越多应用层逻辑会从“手写代码”转向“标准化约束 + 工具调用 + 自动验证”。

真正关键的不是某个具体协议或产品形态，而是一个更底层的变化：当大模型能够阅读规范、理解流程、调用工具并根据反馈修正行为，软件系统就多了一种新的构建方式。代码仍然存在，但一部分代码会被更高层的技能描述包起来，交给 Agent 在受控环境中执行。