背景
2026 年一条重大变化：SKILL.md 已成为跨平台的开放标准。从 Anthropic 的 Claude Code 到 OpenAI 的 Codex CLI，从 Google 的 Antigravity 到 AWS 的 Agent，一套 Skill 文件可在多个 Agent 间通用。
本卡分四块：一、Skill 是什么；二、用 → 装 → 改 → 造四阶演示；三、使用中的 3 个常见配置问题；四、储存与分发两条通路。不给整段脚本，给出思路与指向。
Skill 是什么
Skill 不是模型、不是工具、也不是提示词。它是一份可版本管理的"可执行操作说明书"：告诉 LLM"在某个条件下，按这套步骤和脚本执行"。由三部分构成：
- SKILL.md —— 元数据（触发条件、工具依赖、阶段流转、示例）
- scripts/ —— 可直接调用的辅助脚本（Python / Bash，只读引用）
- resources/ —— 说明文档 / 示例 / 模板
为什么说是"能力"而不是"提示词"？因为 Skill 是阶段化的：LLM 先看元数据判断是否该启用，需要时把 scripts / resources 读入，就相当于给 LLM 安装了一个可调用的"操作手册"。
用 → 装 → 改 → 造（4 阶演示）
| 阶段 | 做什么 | 类比 |
|---|
| ① 用（约 20 分钟） |
从 Skill 库 / GitHub 选一个与场景一致的，放到你 Agent 的 skills 目录（Claude Code 的 user 目录、OpenCode 配置目录等） |
选一张现成的"操作卡" |
| ② 装（5–15 分钟） |
找一个带 SKILL.md 的 Git 仓库，克隆目录到 skills 配置目录，完成 —— 不需要编译 |
装一个组件：目录摆好，Agent 就看得见 |
| ③ 改（约半小时） |
读懂 SKILL.md，把触发条件、参数接口改成符合自己场景的版本 |
重写一份 SOP：流程改动，工具不动 |
| ④ 造（约半天） |
把行业 / 团队内常用的步骤整理为 SKILL.md，配上调好的辅助脚本，公共给同团队 |
给 Agent 加上"操作手册"，模型自动按你的习惯处理这类事 |
使用中的 3 个常见配置问题
- 触发条件写得太宽：SKILL.md 里的触发条件太模糊（比如"处理文件"）→ Agent 在其他场景下也会触发。对策：触发条件用 3–5 个具体动宾短语，如"当用户提到'整理 PDF 并生成摘要'时"。
- 脚本带越权或高危操作：内嵌 scripts 含删库 / 转账 / 数据上传 → 装好后 Agent 就持有了这些权限。对策：先 review 一遍 SKILL.md 与 scripts/，不熟悉的代码段一律删掉；涉及付费或删除的操作必须加人工确认点。
- 步骤被 LLM 跳过：SKILL.md 要求"接着做下一步"，但 LLM 在某分支下跳步了 → 输出与预期不一致。对策：在 SKILL.md 中写明阶段化验证 —— 每阶段末尾要求 LLM 输出确认码，未通过不进入下一阶段。
储存与分发
团队内部（私有）：
- 企业自建 Git 仓库（GitHub / Gitee / GitLab），每个 Skill 一个子目录，走 PR 审核入库
- 统一的 Skill 索引表（markdown），列：Skill 名 / 版本 / 适用场景 / 风险等级
社区分发（公开）：
- 官方 Skill Marketplace / Agent Skills 目录（各家陆续推出）
- 社区 awesome 系列聚合，自行 clone 并修改，最稳定
- 跨平台标准下，自己写的 Skill 不局限在某一家 Agent —— SKILL.md 标准一套多用
Skill 与 MCP 的分工
Skill 解决"怎么做" —— 流程、方法、验证。
MCP 解决"能调什么" —— 数据库、API、工具。
常见组合：Skill 第 3 步调 MCP Server 查询数据 → 第 4 步本地脚本处理 → 第 5 步调 MCP Server 写回。两者是"方法"和"工具"的关系，互不冲突。
合规与交付红线
- Skill 脚本只装官方或可信来源，不装来路不明的第三方代码
- 装 Skill 前审查 metadata，有高危操作（删除 / 付费 / 上传到云端）的自行移除
- 闭源服务商的 Skill 商城"一键安装" ≠ 安全，同样要 review scripts