夜雨聆风很多人刚开始接触 Skill，第一反应是：
这不就是把提示词保存成一个文件吗？
这个理解只对了一半。
Skill 的最小形态确实很简单：一个目录，一个 SKILL.md，里面写清什么时候触发、需要哪些输入、按什么步骤执行、怎样判断完成。
但如果你只把它当成“提示词收藏夹”，很快就会撞到新的问题：
谁来更新这些 Skill？
第三方 Skill 能不能直接安装？
一个团队有十几个 Skill 时，怎么避免互相打架？
多个项目都要用同一套 Skill，又该怎么分发？
截至 2026 年 7 月 2 日，我看到一个很明确的信号：OpenAI 官方的 openai/skills 仓库页面已经提示，这个 Skills Catalog 已经弃用，并建议把 Skill 通过插件仓库和插件构建方式分发。
这句话背后，其实是 Skill 从“个人提示词技巧”走向“Agent 工作流基础设施”的转折点。
不要把 Skill 想得太玄。
它不是让模型突然学会一个新行业，也不是给 AI 额外灌一大包知识库。
它真正解决的是动作顺序问题。
比如你让 Codex 修 Bug。
没有 Skill 时，它可能直接看代码、猜原因、打补丁、跑一下测试，然后告诉你修好了。
有一个好的调试 Skill 后，它会被要求先复现问题，再收集证据；先确认根因，再动代码；修完以后必须验证；如果连续失败，要停下来重新检查假设。
模型没变。
工具没变。
变化的是做事的纪律。
所以，一个好 Skill 封装的不是“更多知识”，而是一套已经跑通过的工作方法。
这也是为什么 Skill 比长提示词更适合长期使用。
提示词存在聊天框里，容易丢、容易旧、容易被个人改坏。
Skill 放在文件里，可以审查、可以复用、可以和项目一起演进。
二、为什么插件化是下一步？
单个 Skill 很轻。
轻到什么程度？很多时候，一个 SKILL.md 就够了。
但真正进到团队里，问题马上变多。
一个发布流程可能需要发版检查 Skill、自测报告 Skill、变更日志 Skill、通知 Skill。
一个数据分析流程可能需要读取表格、清洗数据、生成图表、写结论、导出文档。
一个公众号流程可能需要选题、检索、写稿、排版、配图、保存草稿。
这些能力如果只是散落在不同目录里，后期维护会很痛苦。
插件化的意义就在这里：把相关 Skill、工具连接、MCP 服务和配置打成一个可安装的能力包。
Skill 负责“这件事怎么做”。
插件负责“这套能力怎么安装、怎么分发、怎么组合”。
这就像从复制几段脚本，升级到维护一个工具包。
不是为了显得高级，而是为了少出错、好更新、能交接。
三、别急着装满，先把边界写窄
很多人看到 Skill 可以扩展能力，就想一口气做一个“全能开发助手”。
这是最容易失败的写法。
一个 Skill 如果同时负责需求分析、写代码、跑测试、修 Bug、提交代码、发版上线，最后一定会变得又长又虚。
触发条件会变模糊。
步骤会互相冲突。
出问题时也不知道该改哪一段。
更靠谱的做法是：一个 Skill 只解决一个重复动作。
例如：
debug-production-issue 只负责线上问题排查。
write-self-test-report 只负责生成自测报告。
publish-test-build 只负责测试环境打包发布。
review-api-change 只负责接口改动审查。
边界越窄，越容易验证。
能验证，才值得复用。
如果你第一次写 Skill，不要从“完美流程”开始。最省事的方法，是找一次已经成功完成的任务，让 Codex 把那次真实过程提炼成 Skill。
真实任务里有命令、失败、修复、验证和最终结果，比凭空设计出来的流程可靠得多。
四、第三方 Skill 要按依赖来审查
Skill 越容易分发，安全问题就越不能忽略。
因为 Skill 不是一段普通文章。
它会影响 Agent 接下来怎么读文件、怎么运行命令、怎么修改代码、怎么调用工具。
如果一个第三方 Skill 要求自动执行远程脚本、读取环境变量、上传文件、强制切分支、跳过确认，你不能因为它看起来很热门就闭眼安装。
我的建议很简单：把第三方 Skill 当成开源依赖审查。
至少看五件事。
第一，看 SKILL.md。
触发范围是不是过宽？有没有要求 Agent 不经确认就做高风险操作？
第二，看 scripts 目录。
真正危险的动作，往往不在说明文字里，而在脚本里。
第三，搜危险命令。
重点看删除文件、强制 Git、读取密钥、上传数据、执行远程脚本、生产环境发布。
第四，看来源和维护状态。
作者是谁？最近还更不更新？有没有许可证？是否来自官方或可信团队？
第五，先用低风险项目试跑。
不要拿真实业务仓库、生产配置和本地密钥做第一次实验。
五、普通人现在该怎么用？
不要一上来追求 Skill 数量。
真正有价值的不是“我装了 100 个 Skill”，而是“我有 5 个高频流程已经稳定复用”。
可以从三个问题开始：
第一，最近一个月，哪件事你反复让 AI 做过三次以上？
第二，每次做这件事时，你是不是都要重复解释规则、格式、命令或验收标准？
第三，这件事有没有明确的完成标准？
如果三个答案都是“是”，它就适合做成 Skill。
先别做插件。
先写最小 SKILL.md，跑通几次。
等到你发现它需要和其他 Skill、脚本、外部工具一起分发，再考虑插件化。
这才是最省事的路径。
写在最后
Skill 的价值，不在于把提示词写得更长。
它真正改变的是：AI Agent 的能力开始从“临时对话技巧”，变成“可沉淀、可审查、可安装的工作流资产”。
以前，高手和新手的差距是会不会写提示词。
接下来，差距可能会变成：谁把高频工作流程沉淀成了可靠 Skill，谁又把这些 Skill 组织成了可维护的插件。
这不是概念升级。
这是使用 AI 的方式在变重：从一次性提问，变成长期维护自己的工作系统。
如果你只做一件事，就从最小的一步开始：
找一个重复三次以上的任务，把它写成一个只解决单一问题的 SKILL.md。
先让它稳定工作。
再谈分发、组合和插件化。
参考资料：
- • OpenAI Codex：Agent Skills：https://developers.openai.com/codex/skills
- • OpenAI Codex：Build Plugins：https://developers.openai.com/codex/plugins/build
- • OpenAI Skills Catalog：https://github.com/openai/skills
- • Agent Skills Specification：https://agentskills.io/specification
