Skill 可以理解为给 AI 准备的一套可重复使用的工作说明、规则和相关资料。它让 AI 在遇到某类任务时，知道什么时候该采用这套方法、先读什么、按什么步骤做、结果怎样检查。本文适合经常重复写作、研究、表格、设计或开发任务的人；看完后，你能判断一个 Skill 是否适配自己的产品，完成安装并用真实小任务验证。
Skill、普通提示词和插件不是一回事
- 普通提示词：当前对话里的一次要求，适合临时任务。
- Skill：保存下来、可反复调用的一套工作方法，通常包含说明文件，也可以带参考资料、模板和脚本。
- 插件：用于分发一个或多个 Skill，也可能同时连接外部应用、账号或工具，并声明额外权限。
不同 AI 产品对 Skill 的格式、目录、安装入口和触发方式并不完全一致。看到“Skill 包”时，第一件事是确认它为哪个产品和客户端制作，不能把 Codex 的目录规则直接套到所有 AI 工具上。
一个 Skill 里通常有什么
以当前 Codex 的本地 Skill 为例，核心是一个名为 SKILL.md 的说明文件，开头会写名称和适用范围，正文写执行规则。它还可能包含：
references/：任务需要参考的文档；scripts/：可重复运行的小程序；assets/：模板、图片或其他素材；- 额外的界面或依赖说明。
不是每个 Skill 都需要这些目录。只靠一份清楚的说明文件也可以工作。文件越多不代表质量越好，关键是规则是否明确、材料是否可信、脚本是否可审查。
怎样获得一个 Skill
- 优先从目标产品的官方目录、可信仓库或经过审核的资源详情页获取。
- 确认作者、更新时间、许可证、支持的产品和版本。
- 下载后先查看文件清单，不要直接运行脚本。
- 若资源只给了一段提示词，它可能只是提示词模板，不一定是可安装 Skill。
安装前的安全检查
- 范围：它应该在什么任务上触发？什么任务明确不处理？
- 输入：是否会读取文件、浏览器、邮件或团队数据？
- 输出：会只生成草稿，还是还会发送、上传、删除或发布？
- 脚本：是否联网、安装软件或修改项目外文件？
- 凭据：密钥应在产品的安全设置中配置，不应写进 Skill 文件。
怎样安装或放置
先按资源说明选择目标产品：
- 产品内安装：如果产品提供 Skill 或插件目录，就从目录打开详情、检查权限后安装。
- 导入文件：如果产品明确支持压缩包或文件导入，保持原目录结构，使用产品提供的导入入口。
- 本地目录：只有官方文档明确给出目录规则时，才把完整 Skill 文件夹放进去。以当前 Codex 为例，项目级 Skill 常放在项目的
.agents/skills/技能名/中，个人级 Skill 可放在用户目录下的.agents/skills/。其他产品可能完全不同。
不要把压缩包随意复制到系统目录，也不要因为看到 SKILL.md 就断定任何 AI 产品都能识别。
怎样确认它已经被识别
- 打开产品的 Skills 列表或调用选择器，检查名称和简介是否出现。
- 若刚修改本地文件仍未出现，先确认目录层级和说明文件名称，再按官方要求重新加载或重启客户端。
- 检查简介是否准确描述触发场景；简介太宽泛，可能导致该用时不触发、不该用时乱触发。
在当前 Codex CLI 或 IDE 扩展中，可以通过 Skills 选择入口或以 $技能名 明确调用；ChatGPT 和其他客户端的选择方式可能不同，以当时界面为准。
用一个真实小任务验证
假设你安装了“会议纪要整理”Skill，准备一页脱敏记录，明确要求输出决定事项、负责人、截止时间和待确认项。然后检查：
- 它是否只在合适任务上启用；
- 是否真的遵循随附格式和参考资料；
- 缺失负责人或日期时是否标记待确认，而不是编造；
- 若要运行脚本，是否先说明会读取和修改什么；
- 最终结果是否比你每次重写提示词更稳定。
哪些用户适合，什么时候没必要用
高频重复、步骤稳定、多人需要同一标准的任务最适合 Skill，例如周报整理、固定审稿、项目检查和文件交付。一次性问题、两句话就能说清的任务，或流程还在频繁变化时，普通提示词往往更轻便。
常见问题与下一步
装得越多越好吗？不是。重叠 Skill 可能互相冲突，先保留与你高频任务直接相关的少量能力。
Skill 能保证正确吗？不能。它提高流程一致性，事实仍需核对，外部操作仍需确认。
下一步选择一个你每周至少做两次的任务，用可信 Skill 连续测试三次，记录输入、输出和人工修改。只有它确实减少返工，才值得长期保留。
核验来源：OpenAI 官方 Build skills 文档。Skill 的目录、入口和支持范围会随产品更新发生变化；其他 AI 产品请查各自官方说明。