你打开收藏夹，里面躺着三十篇「AI 技巧」文章。下次遇到问题时，你又打开收藏夹，找一篇类似的，点进去，重新读一遍。这个循环的底层问题是：你以为自己在「学习 AI」，实际上只是在「浏览 AI」。真正把 AI 能力沉淀下来的少数人，做法完全不同——他们把一次次有效的 AI 协作经验，封装成了 Skill。
Skill 不是提示词，是能力模块
把 Skill 和提示词混为一谈，是大多数人的第一层误解。提示词是一次性的，它告诉 AI「这次请你这样做」；Skill 是可复用的，它告诉 AI「以后遇到这一类任务，都按这套方法做」。这不是文字游戏。本质区别在于：提示词解决一次问题，Skill 解决一类问题。
一个成熟的 Skill，至少封装了 5 件事：任务边界、操作流程、判断标准、失败处理、可复用资源。Codex 官方把 Skill 定义为由 SKILL.md 加上可选的 scripts/、references/、assets/ 等组成的目录——这不是工程术语，而是人类经验的格式化。说白了，Skill 的本质是一组可复用的能力结构，而不是一段更长的提示词文本。
万物皆可 Skill 的底层逻辑
「万物皆可 Skill」不是说任何东西都要机械地写成 SKILL.md。它真正表达的是：任何可重复、可抽象、可验证的经验，都可以 Skill 化。一篇文章可以变成「文章总结 Skill」，一次报错调试可以变成「报错诊断 Skill」，一份品牌规范可以变成「品牌写作 Skill」，一个专家的判断方式可以变成「领域分析 Skill」。关键不在内容本身，而在内容背后的可迁移方法。
你读了一篇《如何写爆款标题》的文章，低级做法是保存下来等着再读一遍。高级做法是多问一步：这篇背后有没有一套可重复使用的标题生成方法？它适合什么类型的内容？输入需要哪些信息？生成标题要经历哪些步骤？怎样判断标题好不好？当这些问题被回答清楚，文章就不再只是文章，而变成了一个「标题生成 Skill」的雏形。不是抽象，是提炼——抽象是从具体里拿出本质，提炼是把本质装进一个可以调用的容器。
递归视角：Skill 也是制造 Skill 的工具
比「把内容变成 Skill」更深一层的是：Skill 本身也可以继续创建 Skill。第一层，你把内容变成 Skill。第二层，你把「把内容变成 Skill 的方法」也变成 Skill。第三层，你让这个 Skill 读取真实使用反馈，再自动改进自己。第四层，你让多个小 Skill 组合成 Workflow。第五层，你让 Workflow 变成 Agent 的操作系统。这就是递归。元编程听起来高大上，说穿了就是：你不直接让 AI 完成任务，而是设计 AI 完成一类任务的生成规则。
所谓元编程，在这里可以通俗理解为：不是直接解决一个任务，而是写出能生成任务解决方法的规则。普通使用者让 AI 写文章，高级使用者让 AI 总结写文章的方法，真正的专家，会把这个方法封装成 Skill，然后写一个「自动生成 Skill 的 Skill」。这不是科幻场景。这是我自己在 Hermes 里每天都在做的事。
Hermes 的 Skill 目录就是活证据
我跑的是 Hermes Agent，配置了一套 Skill 系统。Skills 目录目前涵盖 productivity、devops、mlops、research、creative 等多个领域，累计规模从 2025 年的十几个增长到 2026 年的数十个 Skill。这套目录不是「规划」出来的，是踩出来的。遇到一个新任务类型，先用提示词跑通；跑通之后，把成功的流程、失败的教训、输入输出的边界条件记录下来，提炼成 SKILL.md；下次遇到同类任务，直接调用 Skill。
Skill 不只执行任务，Skill 还改进 Skill。达利欧在《原则》里写过「拥抱现实、拥抱失败」，套用到 Skill 工程里：好的 Skill 系统不是不犯错，而是每次犯错都能留下一个不再犯第二遍的结构。这不是因为我天赋异禀。是因为我把「怎样用好 AI」这件事本身，当成了一门需要管理的技能。每一次成功的 AI 协作，都不只是「这次用好了」，而是「以后这类问题都有了一个可复用的解法」。
什么不值得 Skill 化
不是所有内容都值得变成 Skill。第一，一次性任务不值得。「帮我写今天这封邮件」，普通提示词就够了，不需要为此专门建一个 Skill。第二，目标还不清楚的任务不值得。如果你还不知道自己想要什么输出，就先不要封装——封装的前提是「我知道这个流程值不值得重复」。第三，高风险判断要谨慎。法律、医疗、金融、安全等领域，Skill 可以做辅助分析，但不能把 Skill 当成最终专业判断的替代品。
Skill 化的真正门槛不是「内容看起来有价值」，而是「它背后有一套可以反复调用、可以检查结果、可以持续改进的方法」。不满足这个条件，塞进 SKILL.md 也只是资料堆积，不是能力沉淀。
好 Skill 的 10 条原则
综合 Codex 文档、Agent Skills 规范和数十个生产级 Skill 的复盘，好 Skill 通常符合以下原则。这些原则不是设计手册，是踩坑记录。
从真实任务中提炼，不要凭空生成。好的 Skill 来自真实专业上下文——运行手册、代码审查记录、真实故障案例、用户反馈，不是靠模型的通用知识想象出来的。
一个 Skill 只做一类事。不要写「万能办公 Skill」——它太宽，容易互相干扰，每个 Skill 最好聚焦一个任务，并优先用明确输入输出的命令式步骤描述。
description 决定是否能被正确调用。description 不是简介，是触发器。差的写法是「这是一个总结 Skill」，好的写法是「当用户发来一篇中文文章链接、需要提取核心论点并写 300 字摘要时调用」，后者清楚说明了范围、触发条件和交付物。
少讲常识，多写 Agent 不知道的东西。不要在 Skill 里解释「什么是 Markdown」，要写那些没有这个 Skill 时 Agent 容易做错的规则。
给默认方案，不要给一堆菜单。好的 Skill 告诉 Agent「大多数情况下这样做，特殊情况才走别的路径」，而不是「这里有五种选项你自己选」。
加 Gotchas。Gotchas 是「坑」——那些没有经验积累就不知道的陷阱，每当 Agent 反复犯同一个错，就把它加入 Gotchas。
输出模板要具体。直接给模板比说「输出清晰一点」有效得多，Agent 对具体结构的模仿能力通常比对抽象描述的执行更稳定。
必须有失败处理。至少写清楚：什么情况下应该报错而不是继续输出，什么情况下应该回退而不是硬撑。
用 evals 测试 Skill，而不是凭感觉。跑通一次不算好用，要找它什么时候会误触发、漏触发、输出不稳定。
复杂逻辑交给脚本。如果某一步必须稳定、可重复、可验证，写进 scripts/ 目录，脚本应自包含、说明依赖并提供有用错误信息。
渐进披露：好 Skill 像好函数
优秀的 Skill 不应该把所有内容都堆进 SKILL.md。Agent 的上下文是有限的，Skill 越多、描述越长，越容易互相干扰。Codex 启动时通常只把可用 Skill 的名称、描述和路径放入初始上下文，当它决定使用某个 Skill 时，才会读取完整 SKILL.md。这就是渐进披露：平时只保留名字和触发条件，真正调用时才加载完整逻辑。
一个好的 Skill 应该像一个好函数：名字精准、参数清晰、返回值可验证。毛泽东在《矛盾论》里写过「抓住主要矛盾」，套用到 Skill 设计里：一个 Skill 聚焦在一个连贯的工作单元上，不要太窄（触发率太低），也不要太宽（触发不准）。过宽会导致触发不准，过窄则容易让多个 Skill 同时加载并互相冲突。
收尾：Skill 库是 AI 能力的「外置硬盘」
2024 到 2026 这两年，AI 能力的核心，正在从「会不会提问」升级为「会不会沉淀能力」。普通人把 AI 当搜索框，用完就走。进阶者把 AI 当助手，一次一议。真正的专家，会为 AI 建立 Skill、Workflow 和 Agent 系统。Skill 是关键中间层：它比提示词稳定，比 Agent 简单，比 Workflow 模块化，比文档可执行。
所谓「万物皆可 Skill」，不是把世界都写成 Markdown，而是当你看到任何有价值的内容时，都能多追问一句：这背后有没有一种可重复使用的能力？如果有，就提炼它，封装它，测试它，迭代它。让自己拥有的，不再是一堆收藏夹里的文章，而是一套可以调用的 AI 能力库。这才是 AI 时代的「学会学习」。
参考资料
- GeekCatX《万物皆可 Skill：如何基于 Codex 把任何内容变成可复用 AI 能力》:
X_Threads/2026-07-06-万物皆可Skill-如何基于Codex把任何内容变成可复用AI能力.md