• AI 编程“落地”，其实缺 SOP/上下文/可治理复用。用 Agent Skills（SKILL.md） 把“交接文档+脚本+资料”打包，3 步做出可复用的垂直 Agent。照着文末模板写一个你的第一个 Skill，当天就能跑。

• 阅读信息：预计 10 分钟｜适用人群：小白/进阶

为什么现在必须解决这个问题

• 痛点：

  1. 你不是不会用 AI，你是被迫重复解释同一套规则（格式、流程、边界、工具）。

  2. 你不是缺模型，你是缺可版本化、可迁移、可审计的“做事方法”。

• Agent Skills 在 2025-10-16 由 Anthropic 系统化提出，并在 2025-12-18 更新为跨平台开放标准。 同期，GitHub Copilot / VS Code / Cursor / OpenAI Codex 已出现对 SKILL.md 的原生支持入口。

• 本文价值承诺：今天你能把一个“反复口头交接的任务”做成 Skill 能力包：30–60 分钟写完 SKILL.md + 1 个脚本（可选），立刻在 Copilot / Claude Code / Codex / Cursor 里复用。

核心问题清单

• Q1：Skills 到底是什么？为什么不是“又一套提示词花活”？

• Q2：Skills 和 MCP / Workflow 的分工边界在哪？什么时候该用哪一个？

• Q3：怎么用最小闭环，把 Skill 变成“能跑、能复用、能迁移”的能力包？先把概念钉死，才能谈工程化复用。

工具卡（用途/适合）

• GitHub Copilot Agent Skills

  • 用途：让 Copilot 在需要时把 SKILL.md 注入上下文，并可联动目录内脚本/资源，执行专用任务。

  • 适合：团队开发规范、PR 审查清单、测试生成、提交信息、脚手架等“重复且可标准化”的编码任务。

• OpenAI Codex Skills

  • 用途：同样基于“文件夹 + SKILL.md（name/description）”选择与加载技能。

  • 适合：你已经在用 Codex 做 CLI/Agent 编码，希望把个人/团队 SOP 固化成可复用资产。

• Cursor Agent Skills

  • 用途：把可复用知识与脚本打包成 Skills，让 Agent 按需加载执行。

  • 适合：重度 IDE 流工作流、项目内“上下文工程”长期沉淀。

别纠结“选谁家模型”，先选一个你每天在用的载体，把 Skill 跑起来。

底层逻辑：

• 判断：Skills 的本质不是“更长的提示词”，而是可渐进加载（progressive disclosure）的 SOP 包装：先加载元信息，再按需读正文与资源，避免把上下文塞爆。

• 证据：Anthropic 明确把 Skills 定义为“指令、脚本与资源的文件夹”，并强调按需加载让可打包的上下文“近似无上限”。

• 为什么很多人觉得 AI 编程不落地？

  1. 缺“组织化的上下文”：你脑子里的流程、边界、规范没法稳定传给模型——所以它表现像“聪明但健忘的实习生”。

  2. 缺“可治理的交付物”：Prompt 不好版本化、难评审；Skill 是文件夹，可 Git 管、可 Review、可复用、可迁移。

  3. 缺“工具与方法的绑定”：Workflow 解决“流程固定”，MCP 解决“外部工具统一接入”，而 Skills 解决“把怎么做写清楚，并在需要时加载”。

• 想要落地就两步——把重复任务写成 SKILL.md，再把高风险环节用脚本固化成“可执行证据”。AI 编程落不了地，通常不是模型不够强，而是你的“交接包”还没成型。

一张表说清：Skills / MCP / Workflow 怎么选

MCP 管“怎么连”，Workflow 管“怎么走”，Skills 管“怎么做”。

两步/三步落地（最短闭环）

1. 第一步：挑一个“你每周至少做 2 次”的任务（检查点｜产出｜预计时长）

   • 检查点：任务是否具备稳定输入/稳定输出/稳定标准（例如“技术文档按公司模板生成”“PR 审查按清单”）。

   • 产出：写下 10 行“你现在是怎么做的”，这就是 Skill 的骨架。

   • 预计时长：10 分钟。别从宏大愿景开始，从你最烦的重复劳动开始。

2. 第二步：写一个“最小可用 SKILL.md”（检查点｜产出｜预计时长）

   • 检查点：必须包含 name + description，并把流程写成可执行步骤（像交接给同事）。

   • 产出：一个可被 Copilot/Codex/Cursor 等识别的 skill 文件夹。

   • 预计时长：20–30 分钟。Skill 不是作文比赛，步骤清晰比文采重要。

3. [可选] 第三步：把“高风险步骤”改成脚本（检查点｜产出｜预计时长）

   • 检查点：凡是“容易写错/算错/漏项”的步骤（比如批量改名、生成报表、格式转换），都值得脚本化。

   • 产出：scripts/ 下 1 个可执行脚本 + 在 SKILL.md 里写清楚何时运行它。

   • 预计时长：30–90 分钟（看复杂度）。能用脚本证明正确的，就别让模型靠“感觉”输出。

可复制：最小可用 SKILL.md 模板

---
name: doc-reviewer
description: 用固定清单审查技术文档/PRD，输出问题列表与改写建议（含风险分级）。
metadata:
  owner: your-name
  version: 0.1.0
---

# 目标
把用户提供的文档按“结构/事实/一致性/可执行性”四类审查，并输出可直接修改的建议。

# 输入
- 文档正文（Markdown/纯文本/粘贴内容）
- 可选：公司术语表、模板、历史示例（放在 references/）

# 输出
1) 结论摘要（≤5条）
2) 问题清单（按 P0/P1/P2 分级）
3) 改写稿（仅改必要部分，不重写全部）

# 工作流程（必须按顺序）
1. 先复述任务与边界：哪些内容不猜、不编。
2. 结构检查：标题层级、缺失段落、是否可执行。
3. 事实检查：对不确定的点标记【需确认】并列出要问的问题。
4. 一致性检查：术语、口径、指标定义是否冲突。
5. 输出按模板排版，最后给“下一步建议”。

# 资源使用
- 需要公司模板时：读取 references/template.md
- 需要术语表时：读取 references/glossary.md
- 需要自动化格式化时：运行 scripts/format.sh（如存在）

你写下的每一条“必须按顺序”，都是在把不稳定的生成变成稳定的交付。

预测：Skills 会把“AI 产品形态”往哪推

• 判断 1：Skills 会把大量“轻量 AI 产品”打回文件系统：一个 Skill + 一个通用 Agent，就够做 MVP。证据是开放标准与多工具原生入口已形成合围。

• 判断 2：下一阶段竞争点不再是“谁更会写 Prompt”，而是谁的 Skill 包更可复用、更可治理、更可评估（像代码仓库一样迭代）。

未来最值钱的不是一次性的提示词，而是可迁移的“组织能力包”。 你赞同吗？