本文介绍了提升 AI Agent 能力的 4 个关键 Skills 资源。内容涵盖 Vercel 官方 Skills 搜索安装工具(skills.sh)、Anthropic 官方的 Skill 创建权威指南、强制设计讨论的 Brainstorming Skill 以及系统化调试的 Debugging Skill 方法论。适合希望扩展或自主开发 AI Agent 技能的中高级开发者,提供了具体的开源地址与实用原则。
Tags:
01
Vercel 官方的 Skills 搜索神器
Skills 这么多,怎么找到适合自己的?
Vercel 官方出了个 find-skills,专门解决这个问题。它本质上是一个 Skills 包管理器,通过 npx skills 命令就能用。
核心功能挺直接的:
• npx skills find [关键词] 搜索 Skills,支持交互式搜索
• npx skills add <包名> 安装 Skill
• npx skills check 检查更新
• npx skills update 一键更新所有已安装的 Skills
比如你想找 React 性能优化相关的 Skill,直接运行 npx skills find react performance,它会列出所有相关的 Skills,还会给你安装命令和文档链接。
官方还做了一个 Skills 搜索网站 skills.sh,可以在线浏览所有的 Skills。
对于经常用 AI Agent 干活的人来说,这个工具能帮你快速发现和安装各种能力扩展,省得到处找。
开源地址:https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md02
Anthropic 官方的 Skill 创建指南
如果你想自己写一个 Skill,这个官方指南是必看的。
Anthropic 作为 Claude 的出品方,他们出的 skill-creator 可以说是权威教程。
它把 Skill 的结构讲得很清楚:
• SKILL.md 是核心文件,包含 YAML 元数据和 Markdown 指令
• scripts/ 放可执行脚本
• references/ 放参考文档
• assets/ 放模板、图片等资源文件
比较有价值的几个设计原则:
渐进式加载:Skill 分三层加载,先是元数据(约100词),再是 SKILL.md 主体(<5k词),最后按需加载引用文件。这样设计是为了省上下文窗口。
自由度匹配:任务越脆弱,指令越具体;任务越灵活,指令越宽松。就像走钢丝需要护栏,在广场上可以随便走。
不要创建多余文件:Skill 不需要 README.md、安装指南、更新日志这些,它只需要 AI 干活要用的信息。
整个指南非常实用,从理解需求、规划内容、初始化、编写到打包发布,每个步骤都有详细说明。想认真做 Skill 的话,这个值得好好读一遍。
开源地址:https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md03
强制设计的 Brainstorming Skill
这个 Skill 有点意思,它强制你在动手写代码之前先做设计。
它的核心理念是:任何项目,不管多简单,都必须先经过设计讨论,获得你认可后才能开始实现。
整个过程分几步:
先了解项目上下文,看看文件、文档、最近的提交。然后一个一个问题问清楚,搞明白目的、约束和成功标准。
接下来提出 2-3 个方案,说明各自的优缺点,给出你的推荐理由。
最后呈现设计,按模块逐步展示,每个模块确认没问题再往下走。设计通过后,写一份设计文档保存到 docs/plans/ 目录,然后才能调用实现相关的 Skill。
有个硬性规定:在用户批准设计之前,禁止调用任何实现类 Skill,禁止写代码,禁止搭建项目。
听起来有点繁琐,但实际上能避免很多返工。很多时候我们觉得简单的项目,做着做着就发现各种问题,还不如一开始就把事情想清楚。
开源地址:https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md04
系统化调试的 Debugging Skill
这个 Skill 是给 AI 用的调试方法论,核心原则就一句话:没有找到根本原因之前,禁止尝试任何修复。
它把调试过程分成四个阶段:
阶段一:根因调查
仔细读错误信息,可靠地复现问题,检查最近的改动。如果是多组件系统,还要在每个组件边界加诊断日志,搞清楚数据在哪儿断的。
阶段二:模式分析
找类似的工作代码,对比差异,理解依赖关系。不要想当然地觉得某些差异不相关。
阶段三:假设和测试
提出单一假设,用最小改动去测试。一次只改一个变量,不要一次性修多个问题。如果不对,回到阶段一重新分析。
阶段四:实现
先写失败的测试用例,然后修复根因,最后验证修复有效。如果连续 3 次修复都失败,停下来质疑架构设计。
这个方法论的好处是避免乱猜乱试,减少改出一个 Bug 引出两个新 Bug 的情况。据统计,系统化调试 15-30 分钟搞定,随机修复可能要折腾 2-3 小时。
开源地址:https://github.com/obra/superpowers/blob/main/skills/systematic-debugging/SKILL.md05
点击下方卡片,关注逛逛 GitHub
这个公众号历史发布过很多有趣的开源项目,如果你懒得翻文章一个个找,你直接关注微信公众号:逛逛 GitHub ,后台对话聊天就行了:
没有评论:
发表评论