跳转至

5.7 常见 skills 类型、来源和评估方法

不要一开始就装一堆 skills。对初学者来说，skills 的价值不在数量，而在它是否把你已经认可的工作方法稳定复用。

先按问题分类

选择 skill 前，先判断它解决哪类问题。

flowchart TD
  A[重复任务] --> B{问题类型}
  B --> C[生成类<br/>从无到有写页面、文档、测试]
  B --> D[审查类<br/>找 bug、找风险、看设计质量]
  B --> E[流程类<br/>计划、PR、发布、工单同步]
  B --> F[工具增强类<br/>把 MCP/CLI 编排成固定动作]
  B --> G[团队规范类<br/>把本项目做法变成默认约束]

如果你说不清一个 skill 属于哪一类，先不要安装。

生成类 skills

适合场景：

  • 需要快速生成前端页面、落地页、组件库示例。
  • 需要生成 README、API 文档、迁移说明。
  • 需要把设计要求转成可运行原型。

使用方式：

先给产品目标、视觉方向、技术栈和约束。
再让 skill 生成第一版。
最后用 review 或 polish 类型 skill 做二次审查。

注意事项：

  • 生成类 skill 很容易把“好看”优先于“可维护”。
  • 前端设计类 skill 要明确响应式、可访问性、主题变量和组件边界。
  • 不要把生成结果直接合并，至少跑 build 并人工看首屏、移动端和关键交互。

审查类 skills

适合场景：

  • PR 前自查。
  • 安全敏感代码。
  • 数据库迁移、批量更新、权限逻辑。
  • UI/UX 质量检查。
  • 性能或可维护性评审。

好的审查类 skill 应该要求 Agent：

  • 先只读，不直接修改。
  • 按严重程度排序。
  • 给出文件位置、风险原因和复现方式。
  • 区分确定问题、可能风险和建议优化。
  • 不把“个人偏好”伪装成 bug。

最值得先做的审查 skill 是 pre-review。它不需要理解所有业务，但能把 diff、测试结果、风险点整理成人类容易 review 的摘要。

流程类 skills

适合场景：

  • 从 issue 生成计划。
  • 从 PRD 拆任务。
  • 修 CI 失败。
  • 发布前检查。
  • 写 PR 描述。
  • 更新工单状态。

流程类 skill 的核心不是写代码，而是减少“每次都要重新提醒 Agent 怎么办”。

一个流程类 skill 通常包含：

  • 输入：issue URL、失败日志、需求描述、PR diff。
  • 步骤：读取、归纳、计划、执行、验证、总结。
  • 输出：计划、变更摘要、测试结果、风险列表、后续事项。
  • 停止条件：缺少权限、高风险文件、无法复现、验收标准不明。

工具增强类 skills

这类 skill 通常和 MCP 或 CLI 结合。

例子：

  • 用 GitHub MCP Server 读取 PR 评论，再逐条处理。
  • 用 Playwright MCP 复现 UI bug，再给出修复方案。
  • 用 Sentry / Datadog Agent MCP 拉错误上下文，再定位代码。
  • 用 Figma MCP 读取设计信息，再生成组件实现计划。

设计原则：

  • MCP 只提供能力，skill 决定调用顺序。
  • 高权限 MCP 必须有人工确认点。
  • 对外部系统写操作要默认禁止，除非明确授权。
  • 每次调用外部系统后，都要把关键事实写入任务记录，避免结果只存在会话里。

团队规范类 skills

当团队反复遇到同一类问题时，应该考虑把经验写成 skill。

常见类型：

  • 后端分层检查。
  • SQL 风险检查。
  • 前端组件规范检查。
  • API 兼容性检查。
  • 文档同步检查。
  • 发布回滚检查。

这类 skill 的关键是不要写成泛泛的“请写高质量代码”。它必须包含团队自己的判断标准，例如：

  • 这个仓库禁止在哪些目录直接写业务逻辑。
  • 哪些接口字段不能轻易改名。
  • 哪些测试命令代表最低验收。
  • 哪些文件属于高风险区域。
  • 哪些历史坑必须在设计阶段检查。

从哪里找 skills

建议按这个顺序找：

  1. 官方或工具作者维护的 skills。
  2. 大型开源项目中持续更新、issue 活跃的 skills。
  3. 和你技术栈、团队流程高度匹配的社区 skills。
  4. 自己从重复工作中提炼的小 skill。

不要只看 star 数。更重要的是：

  • 最近是否维护。
  • 是否有清晰 README。
  • 是否说明权限和风险。
  • 是否有示例任务。
  • 是否能独立卸载。
  • 是否只包含指令，还是还会运行脚本或访问外部服务。

安装前评估

把任何第三方 skill 当成“会影响 Agent 行为的代码”来审查。

安装前至少看：

  • SKILL.md 的 description 是否过宽。过宽会导致误触发。
  • instructions 是否会要求跳过测试、忽略错误、自动提交。
  • 是否包含 scripts、assets、references。
  • 是否要求 API key、网络权限、写入权限。
  • 是否会把外部内容注入到上下文里。
  • 是否和你的 AGENTS/CLAUDE 规则冲突。

一个最小 skill 设计模板

---
name: repo-pre-review
description: Use when preparing a local diff for human review before opening a PR.
---

# Repo Pre Review

## When to use

Use this when the user asks to prepare, review, summarize, or sanity-check a local diff.

## Steps

1. Inspect `git diff --stat` and changed files.
2. Read only the changed areas and nearby context.
3. Identify correctness, security, test, migration, and compatibility risks.
4. Run available lightweight checks if allowed.
5. Produce a review packet with summary, risks, verification, and open questions.

## Stop conditions

- Do not edit files unless explicitly asked.
- Stop if secrets, destructive migrations, or production credentials are detected.
- Mark unrun checks clearly instead of claiming success.

这个模板的重点是边界和停止条件。skill 越像“外包验收单”，结果越稳定。

如何判断 skill 有效

不要凭体感判断。至少跑三次：

  • 一次成功路径。
  • 一次信息不足路径。
  • 一次高风险路径。

观察它是否：

  • 在正确场景触发。
  • 没有在无关场景误触发。
  • 输出结构稳定。
  • 会主动要求证据。
  • 会在高风险时停下。
  • 能减少你重复输入的内容。

如果一个 skill 只是让输出更长，却没有减少返工，它就不值得保留。

推荐的初学者组合

第一阶段只保留四类：

  • bug-fix：定位、复现、修复、验证。
  • pre-review：合并前自查。
  • frontend-design 或 ui-review：前端质量辅助。
  • task-to-plan：把需求变成可执行步骤。

第二阶段再加：

  • ci-fix。
  • security-review。
  • docs-sync。
  • release-check。

第三阶段才考虑团队专用 skills 和 MCP 编排 skills。

不要贪多

skills 过多会带来三个问题：

  • 触发条件互相抢。
  • 上下文膨胀。
  • Agent 行为变得难解释。

更好的策略是：

先手动跑三次 -> 稳定后写成 skill -> 观察误触发 -> 再分享给团队

如果你还不能清楚描述“这个 skill 解决哪个重复问题”，那它现在还不该存在。