给 AI 装技能的四个工具

最近在研究一个问题。

为什么同样用 AI 写代码，有些人效率很高，有些人总觉得差点意思。

想了想。差别不在模型。在技能。

2026年行业有一个共识。不再追求一个全能的 AI。而是给 AI 装上一个个专业的小技能。Anthropic 和 Vercel 都在推这个方向。叫 Skills。原子化的、可组合的技能单元。

但实际用起来有两个问题。一是找不到合适的 Skills。二是自己开发的 Skills 踩坑多。

今天聊四个工具。分别解决查找、开发、设计、调试四个环节。

四个工具不是独立的。是一个闭环。

第一个：find-skills

Vercel 做的。本质是一个 Skills 包管理器。

你想给 AI 加一个能力，先别自己造。搜一下有没有现成的。

核心就四个命令。

npx skills find [关键词]    搜索技能
npx skills add <包名>       安装技能
npx skills check            检查更新
npx skills update           一键更新

比如你想让 AI 帮你做 React 性能优化。跑一下 npx skills find react performance。它会列出相关的技能，显示功能说明、安装命令、文档链接。

不习惯命令行的话，还有一个在线网站 skills.sh。可以按领域、功能分类浏览。

从 GitHub 上看了一下项目细节。find-skills 的搜索逻辑是先查 skills.sh 的排行榜（按安装量排序），再做关键词匹配。优先推荐经过大量用户验证的技能。

想了想。这个工具解决的是「不要重复造轮子」的问题。生态里已经有成千上万个 Skills 了。先搜再造。

第二个：skill-creator

Anthropic 官方出的。113K Star。

当现有 Skills 满足不了你的需求，就得自己造。skill-creator 是官方的开发指南。也是一个「元技能」——教你怎么造技能的技能。

从 GitHub 上看了项目源码。它定义了一个标准化的 Skill 目录结构。

my-skill/
├── SKILL.md       ← 核心文件，元数据 + 执行指令
├── scripts/       ← 可选，Python/Bash 脚本
├── references/    ← 可选，API 规范、业务规则
└── assets/        ← 可选，模板、图片等

SKILL.md 是核心。由两部分组成。YAML 元数据（名称、描述，约100词）和 Markdown 正文（具体指令，5000词以内）。AI 靠元数据判断什么时候触发这个技能。靠正文知道具体怎么做。

GitHub 上还看到四个设计原则。

渐进式加载。不是一次性把所有内容塞给 AI。先读元数据，触发了再读正文，需要时再读引用资源。最大化利用上下文窗口。

自由度匹配。任务越精细，指令越具体。任务越灵活，指令越宽松。像走钢丝就要每一步都写清楚。像在广场散步就给个大方向就行。

最小化冗余。不加 README、安装指南这些 AI 不需要的东西。打包工具会自动剔除冗余文件。

可验证性。自带结构校验。检查元数据完整性、脚本可执行性、资源路径引用。

还配了两个脚本。init_skill.py 初始化目录生成模板。package_skill.py 验证结构并打包成 .skill 文件。

想了想。skill-creator 的核心价值不是教你写代码。是教你写「给 AI 看的说明书」。说明书写得好，AI 就能稳定地按你的意图工作。写得不好，输出就忽高忽低。

而且它的开发流程很有意思。不是写完就发布。是写完 → 跑测试 → 看结果 → 改 → 再跑 → 再改。循环迭代直到满意。和写代码的 TDD 思路一样。

第三个：brainstorming

Superpowers 里的一个 Skill。142K Star 的项目里最核心的技能之一。

这个工具解决的问题很简单。不要上来就动手。

从 GitHub 源码看到一条硬规则。

任何项目，无论多简单，必须先完成设计讨论并获得用户认可，才能开始写代码。

没有例外。哪怕是一个待办事项列表。哪怕是一个配置变更。

源码里有一段话让我印象很深。叫「Anti-Pattern: This Is Too Simple To Need A Design」。越是觉得简单的项目，越容易因为跳过设计而踩坑。因为「简单」意味着你没有仔细审视过自己的假设。

标准流程是四步。

第一步不是问你要做什么。是先看项目现有的文件、文档、最近的提交记录。了解上下文。

第二步才开始提问。一次问一个问题。明确目的、约束条件、成功标准。

第三步给出2-3个方案。每个方案的优缺点写清楚。附上推荐理由。

第四步按模块逐步确认。每个模块确认无问题后再推进下一个。全部确认后，设计文档存入 docs/plans/ 目录。

然后才能开始写代码。

想了想。这个流程看似繁琐。但它解决的是 AI 编程中最贵的成本——返工。

AI 执行力很强。你说什么它就做什么。但如果你说的东西本身就没想清楚，它会非常高效地做出一个错误的东西。然后你花更多时间返工。

先想清楚再动手。这个道理人人都懂。但 brainstorming 把它变成了一条不可跳过的硬规则。

第四个：systematic-debugging

也是 Superpowers 里的。

AI 写代码会出 Bug。这很正常。问题是怎么修。

大多数人的做法是凭经验猜。改一下试试。不行再改。越改越乱。

systematic-debugging 的核心原则只有一句话。

没有找到根本原因之前，禁止尝试任何修复。

从 GitHub 源码看到它叫这条规则为 The Iron Law。铁律。不可违反。

四个阶段。必须按顺序走。

源码里有一个细节让我觉得很实在。在多组件系统里，它要求在每个组件边界加诊断日志。不是猜哪里出了问题。是先收集证据，看数据在哪一层断掉了，再去查那一层。

还有一条规则。如果连续3次修复失败，立即停止。不是继续试。是退一步，重新审视架构设计是否有问题。

想了想。这套方法的核心是把调试从「凭感觉的试错」变成「有逻辑的推理」。

15到30分钟解决问题。而盲目修复平均需要2到3小时。差距很大。

四个工具怎么组合

它们不是各自独立的。是一个闭环。

三种场景。

日常使用。先搜有没有现成的。有就直接装。省时间。

个性化需求。搜不到合适的。先用 brainstorming 想清楚要做什么。再用 skill-creator 开发。

项目落地。不管用现成的还是自研的。先 brainstorming 定设计。执行中出问题用 systematic-debugging 排查。

从行业趋势看，AI Agent 的未来不是一个超级智能体解决所有问题。是成千上万个原子化 Skills 的组合协作。

这四个工具抓住了四个核心环节。find-skills 解决资源查找。skill-creator 解决个性化开发。brainstorming 解决流程规范。systematic-debugging 解决问题排查。

想了想。其实道理很简单。

不是让 AI 更聪明。是给 AI 装上对的技能。

开源地址：
find-skills ·
skill-creator
brainstorming
systematic-debugging