BuilderIO/skills

你是一个前端开发者，正在用 Cursor 或 Copilot 写一个 React 组件。你输入“帮我写一个带搜索和分页的用户列表”，AI 生成了代码，但样式不对，分页逻辑有 bug，而且它不知道你用的是 Tailwind 还是 Ant Design。你花十分钟改 prompt：“用 Tailwind，分页用 usePagination hook，列表数据从 /api/users 拿”。AI 这次对了，但下次你让它写一个“带拖拽排序的表格”，它又忘了你的技术栈偏好。你开始怀疑：这 AI 是不是每次都在“重新学习”怎么干活？

Skills 就是来解决这个问题的。它是一个给编码代理用的“技能库”，由 BuilderIO 开源，发布 12 天就拿到了 2451 颗星。它的思路很简单：把 AI 能做的事拆成一个个独立的“技能”，每个技能是一个 JavaScript 模块，定义了输入、输出、上下文和调用方式。你不需要写复杂的 prompt，只需要告诉 AI“用这个技能”，它就知道怎么处理。

具体怎么用？假设你是一个团队的技术负责人，你们用 Cursor 写代码，但每次让 AI 生成 API 接口文档，它都格式不对。你可以创建一个“生成 API 文档”的技能：输入是路由文件路径和注释，输出是 Markdown 格式的文档，上下文里绑定了你们团队的文档模板和字段规范。然后把这个技能注册到 Skills 库里。下次你的队友在 Cursor 里输入“给 /users 路由生成文档”，AI 会自动加载这个技能，按你的模板输出，不用再反复调教。Skills 本身不跑代码，它只是一个“技能描述”的仓库，真正的执行靠 Cursor、Copilot 这类编码代理去调用。上下游接的是你的编辑器、你的代码仓库、你的文档系统。

你可以把 Skills 想象成给 AI 助手装上的“外挂插件”。就像游戏里的角色，基础能力是走路、攻击、跳跃，但装上“火焰剑”插件就能放火，装上“飞行背包”就能上天。Skills 就是这些插件，每个插件教会 AI 一个特定领域的“绝活”。没有 Skills，AI 就像一个只会基础动作的裸装角色，每次遇到新任务都要从零学起。

对比一下 OpenAI 的 Function Calling。OpenAI 的路径是“让 AI 学会调用你定义的函数”，你需要写函数签名、参数、返回值，然后 AI 在对话里决定要不要调用。这条路的问题是：函数是死的，AI 只能按你写好的逻辑执行，不能自己“学会”新函数。Skills 的路径是“让 AI 学会使用你定义的技能”，技能本身可以包含上下文、示例、甚至子技能，AI 可以组合多个技能完成复杂任务。差异在哪？Function Calling 适合“执行一个确定操作”，比如“调用 sendEmail 函数发邮件”；Skills 适合“完成一个不确定流程”，比如“根据用户反馈和代码历史，自动生成修复方案”。如果你的场景是固定的、重复的，Function Calling 够用；如果你的场景是变化的、需要 AI 自己判断的，Skills 更灵活。

但 Skills 不是万能药。它的代价是：你需要花时间写技能定义，而且技能的质量直接决定 AI 的表现。如果你写的技能描述模糊、示例太少，AI 可能用错或不用。另外，Skills 目前依赖编码代理去加载，如果你的编辑器不支持 Skills 协议，它就是个空架子。目前 Skills 的生态还在早期，只有 BuilderIO 自家的 Agent Native 平台原生支持，其他工具需要手动集成。还有一个风险：技能是公开的，你写的技能可能被别人看到或修改，虽然 MIT 许可证允许，但如果你有商业机密，得自己托管私有版本。

想象一下这个场景：你的团队新来了一个实习生，他第一次用 Cursor 写代码。他输入“帮我修复这个 CSS 布局问题”，AI 自动加载了“CSS 修复技能”，这个技能包含了你们项目里所有常见的布局模式、浏览器兼容性处理、以及你们团队偏好的 Flexbox 写法。AI 不仅修复了问题，还加上了注释说明为什么这么改。实习生看了一眼，说：“这 AI 怎么这么懂我们？”他不知道，是你们团队的技术负责人提前写好了那个技能，放在 Skills 库里。