一：简介

Anthropic公司于2025年10月推出的Claude Skills，提供了一种全新的范式，通过模块化的方式将隐性知识和专业能力封装成可复用的“技能包"，使得Al能够像人类学习技能一样，获取和掌握特定领域的专业能力。

Skills是对MCP的升级，Skills内部也可能会使用到MCP来支持，相对MCP又有很大的优势：

• 范式创新：从"协议"到”能力”。Claude Skills实现了从MCP(模型上下文协议)到能力封装的范式转变，通过模块化设计大幅降低了token消耗(相比MCP节省60%-80%)，提供了更高效的能力扩展方式。
• 增强输出一致性和可重复性：在数据处理、报告生成等需要标准化输出的场景中，Skills确保了95%+的输出致性，解决了传统提示工程结果不稳定的痛点。
• 显著降低开发门槛：非技术人员也能通过简单的Markdown文件和YAML 配置创建Skis,开发效率提升3-5倍，团队协作中工程师反馈"产品设计师也能进行前端微调和状态管理"。

维度	Claude Skills	MCP（模型上下文协议）	传统提示工程	Function Calling
技术理念	能力封装	协议扩展	指令引导	函数调用
Token 消耗	⭐⭐⭐⭐⭐（低）	⭐（高）	⭐⭐⭐	⭐⭐⭐⭐
开发门槛	⭐⭐⭐⭐⭐（低）	⭐⭐（高）	⭐⭐⭐	⭐⭐
可重复性	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐
灵活性	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
知识沉淀	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐	⭐⭐
生态成熟度	⭐⭐（早期）	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
部署复杂度	⭐⭐⭐⭐⭐（简单）	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
性能效率	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐

工作原理：用户请求 ->Claude解析请求 -> 匹配合适的Skill -> 加载Skill配置 -> 执行Skil逻辑-> 返回结构化结果。

二：常用Skills

• https://skillsmp.com/
• Claude Skills 官网

技能名称	开发者	功能描述
playwright-skill	lackeyjb	基于Playwright的浏览器自动化（端到端测试、爬虫、脚本生成）
cypress-skill	devguru	使用Cypress进行Web应用测试和UI自动化
selenium-helper	webqa	Selenium浏览器驱动辅助（兼容性测试、跨浏览器验证）
chrome-devtools	mrgoonie	Chrome开发者工具集成（DOM检查、网络分析、性能调试）
react-devtools	fb-tools	React组件树调试与状态监控
vue-inspector	vue-master	Vue.js应用调试和组件分析
claude-code	mrgoonie	前端代码生成（HTML/CSS/JS片段、组件模板）
figma-to-code	design-dev	Figma设计稿转前端代码（支持多框架）

• commit-commands 用于提交代码、生成 commit message、辅助 push / PR。
• pr-review-toolkit 用于 Pull Request 评审、风险扫描、审查摘要。
• figma 用于设计稿读取、设计到代码辅助。

1. 全栈开发：claude-code + react-assistant + webpack-config
2. 测试保障：playwright-skill + cypress-skill + lighthouse-ai
3. 企业级应用：redux-helper + better-auth + accessibility-check
4. UI开发：figma-to-code + tailwind-gen + responsive-css

建议通过 plugin marketplace add [技能ID] 命令直接安装所需技能。

三：安装插件

输入/plugin，默认进入到Discover，可以选择也可以进行搜索，后面都有安装量，例如

• fronted-design安装277.5k，作为前端开发人员肯定是必装的。
• code-review、github也是每个开发人员必装的。
• skill-creator：用于辅助生成SKILL.md
  

然后搜索名字，然后回车安装。

查看已经安装的所有插件 /plugin ，然后选择Installed，按esc即退出。
如果插件没有enabled，可以通过/reload-plugins来重新加载。

安装插件也可以从插件市场上直接通过skill命令安装：/plugin marketplace add xxx

1. 手动触发，输入/插件提供的工具名，如 /debug，需要输入具体的工具名，上面安装的figma插件不能使用使用/figma而是使用figma具体提供的工具，如：/figma:implement-design
2. 自动触发

四：自定义Skills

自定义一个最小可用的 SKILL.md 示例。

1. ~/.claude/skills/code-review-helper/SKILL.md

• code-review-helper 为skill名称。
• 最小版本YAML 头部只包含了name和description，正文指令告诉 Claude 这个 skill 在什么场景触发、该怎么做。
• 在自定义Skill时也可以通过Claude提供的Skill来辅助生成SKILL.md。anthropics/skill-creator：要自己做skill记得安装这个，就不需要记开发标准了，直接在CC里说“用skill-creator开发一个将PDF信息转成可视化网页的skill”。

---
name: code-review-helper
description: 在需要代码评审时，检查潜在 bug、风险点和测试缺口。
---

# Code Review Helper

当用户要求“review / 代码评审 / 检查风险”时，执行以下步骤：

1. 优先查找功能性 bug、边界条件问题、潜在回归。
2. 检查是否缺少必要的测试。
3. 检查是否有明显的性能或安全风险。
4. 输出时先给出 findings，再给简短总结。

打开一个新的终端，进入Claude，输入/skills查看所有skills。

2. 使用

• 自动触发：当你的请求和 description正文场景匹配时，Claude Code 可能自动使用
• 手动触发：一般可以用 /skill-name 方式调用，比如 /code-review-helper 对xxx方法进行代码评审
  

3. 模板
   好的 SKILL.md 不是“写一段提示词”那么简单，而是要把这 3 件事写清楚：

• 什么时候触发
• 按什么流程执行
• 输出要长什么样

---
name: your-skill-name
description: 说明这个 skill 做什么、什么时候用、用户可能怎么提。
user-invocable: true
---
# Skill Title
一句话说明目标。

## The Job
1. 第一步做什么
2. 第二步做什么
3. 第三步输出什么
## Rules
- 必须遵守什么
- 不要做什么
- 输出时注意什么

## Output
- 格式
- 路径
- 命名规则

使用模板写一个code view 示例。

---
name: code-review
description: "对代码变更进行结构化评审，优先识别 bug、风险、行为回归、边界条件问题和测试缺口。适用于用户提出 review、代码评审、审查变更、检查风险、检查问题、看下这段代码是否有问题 等场景。"
user-invocable: true
---

# Code Review

对代码变更进行高信号、可执行的评审，优先发现真正会影响功能、稳定性、可维护性和上线质量的问题。

---

## The Job

1. 理解用户要评审的范围
2. 阅读相关代码、diff 或上下文
3. 优先识别真实问题，而不是风格偏好
4. 输出按严重程度排序的 findings
5. 如果没有明确问题，说明未发现 findings，并补充剩余风险或测试盲区

**Important:** 评审的目标是发现问题和风险，不是重写代码，也不是默认进行修改。

---

## Review Scope

当用户提出以下类型请求时，使用本技能：

- review 这段代码
- 帮我做代码评审
- 看下这次改动有没有问题
- 检查是否有 bug / 风险 / 回归
- 帮我审一下 PR
- 看下测试是否充分

如果用户没有明确范围，先确认以下信息之一：

- 需要评审的文件
- 需要评审的 diff
- 需要评审的 PR / 提交
- 需要重点关注的模块或风险点

---

## Review Principles

始终遵循以下原则：

- 优先关注功能正确性，而不是代码风格
- 优先关注用户可感知的问题，而不是理论上的小概率问题
- 优先关注新增改动引入的风险
- 结论必须尽量基于代码证据，不要空泛猜测
- 如果问题成立需要依赖某个假设，要明确写出假设
- 不要为了凑数量输出低价值意见
- 不要把“可以更优雅”当成“必须修改”

---

## What To Look For

重点检查以下方面：

### 1. 功能正确性
- 是否存在明显逻辑错误
- 条件分支是否遗漏
- 状态流转是否完整
- 返回值、异常、空值处理是否正确
- 新逻辑是否破坏已有行为

### 2. 边界条件
- 空数据、null、undefined、空字符串、空集合
- 极端输入、重复提交、并发场景
- 分页边界、时间边界、金额边界、状态边界
- 权限不足、参数缺失、接口失败时的处理

### 3. 回归风险
- 改动是否影响已有调用方
- 接口字段、函数签名、返回结构是否变化
- 默认值是否改变
- 初始化逻辑是否改变
- 是否影响兼容性

### 4. 错误处理与稳定性
- 异常是否被吞掉
- 是否缺少日志或上下文
- 是否把失败误当成功
- 重试、回滚、兜底逻辑是否合理
- 是否会导致静默失败

### 5. 数据与状态一致性
- 状态更新是否原子
- 多处数据是否可能不一致
- 是否存在重复写入、漏写、脏数据风险
- 缓存、数据库、前端状态是否同步

### 6. 性能与资源消耗
- 是否引入不必要的循环、重复请求、重复计算
- 是否存在明显 N+1、全量扫描、阻塞操作
- 是否可能导致大对象常驻内存或资源泄漏

### 7. 安全与权限
- 输入是否缺少校验
- 是否存在越权访问风险
- 敏感信息是否泄露
- 是否存在注入、拼接、反序列化等常见风险

### 8. 测试充分性
- 是否缺少核心路径测试
- 是否缺少异常路径测试
- 是否缺少边界条件测试
- 测试是否真的覆盖关键逻辑，而不只是跑通流程

---

## Severity Rules

对发现的问题按严重程度排序：

### Critical
会导致严重故障、安全问题、数据错误、核心功能不可用的问题。

### High
很可能导致功能错误、线上回归、明显异常行为的问题。

### Medium
不会立即阻塞主流程，但会造成隐藏风险、稳定性下降、维护成本增加的问题。

### Low
影响较小的问题，或需要在后续迭代中处理的改进项。

如果一个问题不确定是否成立，不要强行拔高严重级别。

---

## Output Format

输出时使用以下结构：

### 有 findings 时

```md
## Findings

1. [High] 这里写问题标题
说明问题是什么、为什么成立、会带来什么影响。
如有必要，补充触发条件或复现路径。

2. [Medium] 这里写问题标题
说明问题是什么、为什么成立、会带来什么影响。

## Open Questions / Assumptions

- 如果某个判断依赖假设，在这里说明
- 如果缺少上下文，在这里说明

## Summary

- 用 1-3 句话总结整体评审结论