AI 编程工具有一个很隐蔽的浪费：每换一个项目，你都要重新告诉它怎么写测试、怎么查日志、怎么发版、哪些目录不能碰。提示词写得越长，越像在反复培训一个永远不入职的同事。Agent Skills 的价值就在这里：把重复的工作方法沉淀成可复用技能。

GitHub CLI 已经推出 gh skill，用来发现、安装、管理和发布 agent skills。Claude Code 也支持通过 skills 扩展能力。我的判断是：个人开发者现在不需要追逐所有 skill 生态，但应该开始为自己的高频工作流沉淀技能库。

什么值得做成 Skill

不是所有提示词都值得变成 skill。适合沉淀的东西通常有三个特点：重复出现、步骤固定、需要项目规则。比如“为 FastAPI 接口补测试”“检查 Next.js 页面性能问题”“根据错误日志生成排查步骤”“把数据库迁移改成幂等版本”。

一个实用 skill 应该包含任务目标、输入要求、禁止事项、检查命令和输出格式。比如补测试的 skill 不应该只写“请补测试”，而要写清楚：优先覆盖边界条件，不允许改业务逻辑，完成后运行指定测试命令，最后列出新增用例覆盖了哪些风险。

如果你维护多个小项目，skill 的收益会更明显。个人开发者常常在 SaaS、脚本、插件、内部工具之间切换，脑子里装着一堆隐性规则。把这些规则变成 skill，本质上是在给自己的工作流做版本管理。

踩坑：Skill 不是万能模板

第一个坑是把 skill 写成空泛口号。比如“你是资深工程师，请写高质量代码”。这类话几乎没有约束力。真正有用的是具体规则：不要引入新依赖、优先修改 service 层、失败时先复现、输出 diff 摘要。

第二个坑是 skill 太长。长到像一份制度文件，模型未必能稳定遵守，人也不愿意维护。我的经验是一个 skill 只解决一类任务，宁可拆成多个小技能，也不要做一个“全栈开发大师”。名字越朴素，越容易复用。

第三个坑是没有版本意识。skill 一旦在多个项目复用，就会出现“这个项目适合，那个项目不适合”的情况。最好把公共 skill 和项目覆盖规则分开。公共 skill 管方法，项目规则管边界。

结论

Agent Skills 不会让 AI 突然变成高级工程师，但能减少重复解释，让 AI 更稳定地进入你的工作流。对个人开发者来说，最值得优先做的不是公开发布一堆技能，而是给自己沉淀三五个高频技能：补测试、查错误、做重构、写发布说明、检查安全边界。真正的效率提升，往往来自这些不酷但重复的地方。

参考：GitHub gh skill 公告：https://github.blog/changelog/2026-04-16-manage-agent-skills-with-github-cli/