继MCP之后的Skills到底能干什么?
Skills正在重塑AI模型的职业培训方式,这套为模型设计的知识库系统将人类专业经验转化为标准化操作指南。从设计师的配色方案到工程师的代码审查规范,Skills通过渐进式加载机制,让AI像实习生一样快速掌握岗位核心技能。本文深度解析这套系统的构建逻辑与应用场景,揭示如何将高频、复杂、易错的工作转化为组织级的自动化能力。

什么是Skills?
其实在2025年的年轻我在撰写提示词时,是有关于skill的概念的,当时我所接手时现在模型大厂的一个PPT项目,需要构建System Prompt,由于我是设计专业出身所以就需要设计一套流程化的提示词来对模型的审美和构图能力进行规范,当时我就意识到如果将所有的设计师经验回忆到一个SP中那么模型不就成了设计大神。
我当时的核心工作就是把自己之前的设计经验融合整理成文字形式让模型去学习去根据我的经验来进行ppt生成,甚至我还会给他配色、排版、字体等网站让他自己学习,其实这就是skill的概念将人类专业中宝贵的经验累积分享下来。
Skills 是一套专门为模型设计的知识库系统,包含了各类任务的最佳实践、操作规范和质量标准。这些都是通过大量实验和迭代积累下来的宝贵经验。
Skills的构成
核心设计理念:按需加载+渐进式加载(Progressive Loading)
这种设计解决了一个关键问题:如何在有限的上下文窗口中高效管理大量知识?
把 AI 想象成一个刚毕业的聪明但没经验的实习生:
- 普通Prompt= 你每次都要从头教他怎么做事(今天教一遍,明天还得重新教)
- Rule / 记忆= 你给他贴一张”公司行为守则”在工位上(一直生效,但只能管态度和格式)
- MCP/ Tools= 你给他电脑装了一堆软件和API(他能调用外部工具,但不知道什么时候该用、怎么组合用)
- Skills= 你直接给他一整套“岗位培训大礼包”(PDF+流程图+SOP+话术模板+常用脚本),告诉他:”当老板让你做这类事情时,就按这个文件夹里的方法来做”
如何为项目构建 SKILL.md 配置文件?
SKILL.md 文件是一份专门为 AI 编写的”工作手册”,它能引导 Claude 按照既定流程自动化处理特定任务,从而实现能力扩展。
步骤一:建立技能存储结构
技能文件需要按规范存放。针对项目级别的技能,应在项目根目录创建以下路径:
mkdir -p .claude/skills/<技能名称>
关键要点:
- 作用域区分:放置在.claude/skills/<skill-name>/SKILL.md的技能仅在当前项目内生效
- 命名约定:建议采用 kebab-case 格式(小写字母+连字符),长度不超过 64 字符
步骤二:构建文件内容框架
SKILL.md 采用双层结构设计:
层级 1:元数据配置(YAML Frontmatter)
位于文件开头,用—分隔符包裹,定义技能的触发逻辑:
- name:技能标识符,同时作为斜杠命令使用(如/code-review)
- description:触发判断依据,需包含用户可能使用的自然语言关键词(这是最关键的配置项)
- disable-model-invocation:设为true时禁止自动触发,仅支持手动调用
- allowed-tools:限定可用工具范围(如Read、Grep等)
层级 2:执行指令(Markdown 正文)
紧接元数据部分,编写 AI 需遵循的标准操作流程:
- 撰写原则:指令应具体、明确且可执行
- 动态参数:通过$ARGUMENTS或$0、$1接收用户输入
步骤三:实战配置案例
创建代码审查技能.claude/skills/code-review/SKILL.md:
name: code-reviewdescription: 执行代码审查,识别潜在缺陷和性能瓶颈。适用于代码质量检查、漏洞扫描等场景。
disable-model-invocation: false
—
# 代码审查执行规范
收到审查请求后,按以下顺序操作:
1.**安全漏洞扫描**:检测 SQL 注入风险、明文密钥等安全隐患
2.**性能分析**:定位冗余循环、内存泄漏等性能问题
3.**目标文件处理**:若用户指定文件($ARGUMENTS),优先处理该文件
4.**结果呈现**:以结构化列表输出问题点及改进方案
步骤四:扩展资源管理(高级功能)
当指令内容超过 500 行时,建议采用模块化管理:
目录组织方案:
.claude/skills/code-review/
├── SKILL.md # 核心指令文件
├── templates/ # 代码/文档模板库
├── examples/ # 正反面案例集
└── scripts/ # 可执行脚本(如 validate.sh)
引用机制:在 SKILL.md 中通过相对路径声明,例如:”格式规范参见examples/best-practice.md”。Claude 会按需加载这些资源,有效控制 Token 消耗。
步骤五:功能验证
完成配置后可通过以下方式测试:
- 手动触发:在终端执行/技能名称 参数(例:/code-review src/main.js)
- 智能识别:输入符合 description 描述的自然语言请求(如”帮我检查这段代码”),系统将自动匹配并加载技能
排查提示:若技能未按预期激活,请检查:
description字段是否包含常用触发词
运行/context命令查看技能是否因超出字符限制而被过滤
Skills 应用场景(精炼业务版)
应用场景总览:Skills 解决什么问题
从业务视角看,Skills 的核心价值不是“更会写提示词”,而是把高频、可复制、可标准化的工作沉淀为组织级能力。在实际工作中,其应用场景可以收敛为三大类:
- 高频标准化流程(SOP 类)
- 强组织语境与内部知识依赖类
- 多资源协同的复杂生产任务
这三类场景,覆盖了个人效率、团队一致性与技术自动化三个层级。
高频标准化流程(SOP类场景)
场景特征:同类任务周期性重复(周 / 月 / 项目节点)|输出结构高度固定|人工操作成本主要浪费在“重新组织表达”而非思考本身
判断标准一句话版:这件事如果不靠记忆、而是靠流程完成,就该做成 Skill。
周报 / 月报 / 项目汇报生成
痛点:汇报频率高但信息密度低|结构固定却每次重写|多数据源拼装成本高(项目系统 / 代码仓库 / 会议纪要)|不同人输出风格差异大,管理者阅读成本高
Skill 的好处:将“经验型检查”结构化|固化检查顺序与判断标准|降低人为疏漏概率
固定结构写作与文档模板
痛点:文档结构不统一|新成员无从下笔|评审时间被格式问题消耗|文档难以规模化复用
常见文档类型:产品需求文档(PRD)|技术方案 / RFC|事故复盘与复盘报告|内部技术分享材料
Skill 的好处:统一结构与逻辑顺序|明确“每一部分该回答什么问题”|提升文档的决策支持能力
强组织语境与内部知识依赖类场景
场景特征:强依赖公司内部定义、规则与共识|脱离组织语境,通用模型输出失真|一致性比创造性更重要
一句话总结:这类 Skill 的目标不是“更聪明”,而是“不出错”。
品牌调性与内容规范
痛点:对外表达风格割裂|术语口径不统一|禁用表达靠口口相传|新人学习成本高
Skill 的好处:语气与风格基准|统一术语表|禁用词与风险表达|标准示例库
团队工程与协作规范
痛点:提交信息不可读|PR 评审成本高|代码风格不统一|项目结构随人而变
Skill 覆盖范围:Commit 信息规范|PRD 描述模板|工程目录与命名规范|代码风格与最佳实践
业务口径与指标定义
痛点:同一指标多种解释|报表对不上结论|新人理解成本高|数据决策缺乏可信基础
Skill 的优势:固化指标定义|明确计算逻辑与边界条件|统一数据解释方式
多资源协同的复杂生产任务
场景特征:仅靠提示词不稳定|需要脚本、模板、示例协同|输出质量要求高且可复用
这一类 Skill 更接近“轻量自动化系统”。
数据分析与报告自动化
痛点:分析流程重复|手工清洗易出错、图表风格不统一|结论表达质量不稳定
Skill 组合能力:数据解析与清洗脚本|标准图表配置|结论生成模板
文档批量生成与维护
痛点:文档数量大|手工维护成本高|更新不及时|一致性差
典型应用:API 文档、组件与配置文档、批量格式转换
测试与项目脚手架生成
痛点:测试模板重复劳动|风格不一致|Mock 数据构造成本高|覆盖率难保障
Skill 的角色:固化测试结构|统一断言规范|提供可复用基础设施
如何判断是否值得做成 Skill
三个业务判断维度
- 频率:是否持续、高频发生
- 稳定性:是否存在固定结构与规则
- 复杂度:是否难以用一句话描述清楚
满足其中两项,通常就具备投入价值。
Skills 的本质不是“工具升级”,而是:
把个人经验转化为组织可复用的生产力资产。从最浪费时间、最容易出错、最依赖个人记忆的工作开始,优先落地 Skill,往往能获得最高的投入产出比。
本文由 @LULAOSHI 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
- 目前还没评论,等你发挥!

起点课堂会员权益




