AI Agent Skills 是什么？以及几类适合编程和前端开发的 Skills

如果你最近在用 Codex、Claude Code，或者其他 coding agent，大概率已经见过 skill 这个词。

它听起来像一个新概念，其实没有那么玄。简单说，skill 不是给 Agent 增加一个全新的能力，而是告诉它：遇到某一类任务时，应该按什么方式工作。

Skill 到底是什么

AI Agent Skill 通常就是一个目录，里面至少有一个 SKILL.md。这个文件会写清楚几件事：这个 skill 解决什么问题、什么时候触发、执行时遵守哪些规则、可以参考哪些材料、是否要调用额外脚本。

复杂一点的 skill，还会带上 rules/、references/、scripts/ 这些目录，用来放规范、示例、资料或可执行脚本。

my-skill/
  SKILL.md
  rules/
  references/
  scripts/

我更愿意把它理解成“给 Agent 的工作说明书”。它和 tool 不是一回事。

• tool 解决的是“能不能做”
• skill 解决的是“该怎么做”

比如 Agent 有读文件、执行命令、联网搜索这些工具，只能说明它具备操作能力。至于它要不要先看项目结构、改完要不要跑 lint、遇到失败要不要回退一步、最后应该输出结论还是 checklist，这些都更接近 skill 的范围。

什么任务值得写成 skill

不是所有 prompt 都需要沉淀成 skill。一次性的、很具体的问题，直接对话就够了。

真正适合写成 skill 的，是那些你会反复交给 Agent 做、而且容易因为临场发挥导致质量不稳定的任务。比如：

• 每次改完代码都要格式化、跑检查、整理结果
• 每次 review 都希望按同一套标准找 bug 和风险
• 每次写 React 组件都要检查可访问性、状态边界和性能
• 每次生成文档都要遵守同一套结构和语气

这些任务如果每次都重新写 prompt，很容易漏细节。写成 skill 之后，相当于把经验固定下来，让 Agent 下次别从零开始猜。

编程里适合复用的 Skills

下面这些是我觉得比较容易复用的类型。它们不一定要原封不动照搬，但很适合作为你自己项目里的起点。

1. fix

fix 适合放在改完代码后的收尾阶段。它通常会做几件事：格式化、跑 lint、处理能自动修掉的问题，再把剩下的问题整理出来。

很多项目里，真正消耗时间的不是改业务逻辑，而是反复处理格式、静态检查和一些小的工程规范。把这类动作做成 skill，Agent 的收尾会稳定很多。

GitHub：fix

2. karpathy-guidelines

这类 skill 不是为了“多写代码”，而是为了约束 Agent 少犯工程上的老毛病。比如先说明假设，不做没必要的抽象，不随手扩大改动范围，改完必须给出可验证结果。

如果你不想让 Agent 一上来就写一大套看起来完整、实际用不上的东西，这种写法约束很有价值。

GitHub：karpathy-guidelines

3. find-skills

不是每个 skill 都要自己写。find-skills 这类 skill 的作用，是先帮你找现成的 skill，再判断它是否适合当前项目。

对于经常换项目、换技术栈的人来说，这类发现型 skill 很省时间。它更像一个入口：先找到可参考的做法，再决定要不要安装、改写或拆分。

GitHub：find-skills

4. andrej-karpathy-skills

如果你想直接看一组整理好的 skills，可以翻一下这个仓库。它里面收了一批偏代码写作、工程习惯和任务约束的 skill，适合拿来参考目录结构和规则写法。

GitHub：andrej-karpathy-skills

前端开发里适合复用的 Skills

前端尤其适合用 skill。因为很多前端任务天然就不是“写完能跑”这么简单，还要同时考虑交互、状态、可访问性、性能、响应式和可维护性。

1. frontend-code-review

这个 skill 适合做提交前检查，也适合 review 单个组件文件。它的价值在于按固定检查项看问题，而不是泛泛说一句“代码还行”。

如果你经常 review tsx、ts、js 文件，这类 skill 基本值得准备一份。

GitHub：frontend-code-review

2. frontend-accessibility-best-practices

无障碍最适合沉淀成 skill。因为它本来就有很多稳定规则：语义化标签、键盘可访问性、焦点管理、aria-live、reduced-motion 等。

这些事情靠临时提醒很容易漏。做成 skill 以后，Agent 在生成组件或 review 组件时，会更容易把这些检查变成默认动作。

GitHub：frontend-accessibility-best-practices

3. vercel-react-best-practices

这个 skill 更偏 React / Next.js 实战，重点通常在性能和架构边界上。比如怎么减少 waterfall、怎么拆客户端边界、怎么控制 bundle 体积、怎么减少重复渲染。

如果你的项目本来就是 React 或 Next.js，这类 skill 的收益会比较直接。

GitHub：vercel-react-best-practices

GitHub：Vercel Labs agent-skills

4. optimized-nextjs-typescript

这个 skill 更像一套 Next.js + TypeScript 项目的工程基线，重点在目录组织、类型边界、性能、错误处理和基本 UI 规范。

如果你经常让 Agent 直接写页面、模块或完整功能，这类“默认约束型 skill”会很有用。它能减少很多看起来能跑、但后续很难维护的代码。

GitHub：optimized-nextjs-typescript

如何自己写一个最小可用的 skill

最小可用版本其实不难。先写一个 SKILL.md，把下面几件事说清楚就可以了：

• 这个 skill 叫什么
• 它解决什么问题
• 什么场景下应该触发
• 执行流程是什么
• 有哪些硬性约束
• 是否依赖脚本或参考资料

比如，一个用来 review 接口代码的 skill，可以先写成这样：

---
name: api-review
description: 在 review 接口代码时使用，重点检查入参校验、错误处理和返回结构。
---
 
# API Review
 
### 什么时候用
 
- 用户让 Agent review 后端接口代码
- 用户要求检查接口设计是否合理
 
### 要做什么
 
1. 先看接口的输入参数和校验逻辑
2. 再看错误处理和状态码是否一致
3. 最后看返回结构是否稳定，字段命名是否清楚
 
### 约束
 
- 优先指出真实 bug 和风险，不要泛泛而谈
- 如果没有明显问题，也要说明剩余风险
- 输出里要带文件路径和行号

这个版本很小，但已经够用了。后面如果发现某些检查经常重复，就把它继续补进流程里；如果需要固定参考资料，就加 references/；如果有自动化动作，就放进 scripts/。

一些可以继续翻的仓库

如果你想继续找现成的 skill，可以先看这两个仓库：

GitHub：openai/skills

GitHub：vercel-labs/skills

写到这里，其实也能看出来，skill 不是一个很重的东西。它更像是把一类重复任务收拢起来，让 Agent 下次别再从头猜一遍。