Skills · 技能层 · 你重复做的事,写成可复用指令

它回答的问题: 你在重复做哪些工作流? 它在哪: .claude/skills/<name>/SKILL.md(Claude Code)/ Cursor Agent Skills / Copilot Custom Agents / Codex Slash Commands 它读取的时机: 按需触发(由用户触发词或 agent 判断), 不是每次都读。

原文金句

★ 「Skills is how you work. A skill is a reusable instruction set for the AI or workflow that you do repeatedly.」 「Skills 是你怎么工作。 一个 Skill 就是一套可复用的、面向 AI 的指令集——是你重复在做的工作流。」 (#202-203,00:13:55,831 → 00:14:05,675)

★ 「I believe that every knowledge worker easily has 20 or 30 of these patterns.」 「我相信每个知识工作者都轻松能列出 20 到 30 种这样的固定模式。」 (#206)

Skill 的标准三段式

按视频 (#207-208):

当我说出 [触发词] 时,
基于 [以下来源] 执行 [某种流程],
以 [这种格式] 产出输出。

例子:

当我说「pre-read for X meeting」时,
基于:
  - 我的日历(找到这次会议的标题、参会人、上次同议题会议)
  - 我的 stakeholders.md(知道每个参会人在乎什么)
  - 我最近 7 天跟参会人的往来邮件
执行:
  1. 提取上次同议题会议的 3 个未决项
  2. 对每个参会人列 1 句话「他们最可能问什么」
  3. 对你识别到的争议点, 标我可以提前给的立场
以一页 markdown 产出, 按以下结构:
  - 会议目标(1 行)
  - 上次未决项(3 行)
  - 每位参会人画像(每人 1 行)
  - 我应该提前定的立场(1-3 行)

这个 Skill 一旦写好, 你以后说 「pre-read for tomorrow’s product review」 就能直接拿到一份 1 页简报。

不写 Skill 时, 你在重复做什么?

按视频 (#209-212):

• 每次重新解释格式
• 每次粘贴一样的来源
• 每次抱怨它的腔调不对, 但你从来没花心思教它你的语气

★ 「You complain that the agent writes in a weird voice and you never bother to teach it your voice.」 「你抱怨 AI 写出来的腔调怪怪的, 但你又从来没花心思教它你的语气。」

MVP-first(再次强调)

「我建议先做一个 MVP 版的 Skill, 而不是一开始就追求完美。 第一版总是不完美、有些地方甚至是错的, 但你用一周, 就会发现它哪里跑偏、哪里需要改。 打补丁, 几周之后, 这个 Skill 写出的初稿,会比你每次重新开始能写的更好。」 (#214-218)

实操节奏:

• 第 1 天: 起草 v1, 长得像 「if-then-else, 大致对了 70%」
• 第 2-7 天: 每天用它跑 1-3 次, 把 「应该这样但它没做到」的项记在文件末尾
• 第 8 天: 把 7 天积累的修正合进 SKILL.md
• 第 30 天: Skill 写出的初稿已经超过你重新写的质量

Chief of Staff 的初始 Skill 套件(按视频 #220-224 整理)

四份的完整可粘贴版本见 08 Chief of Staff 完整模板第 6-9 节。

工具对照(各家 Skill 落点)

⚠️ Skill 标准目前仍在分裂。 Claude Code 用自己的 .claude/skills/<name>/SKILL.md, Hermes 推 agentskills.io 开放标准, 其他工具各自命名。 建议先按你主用工具的格式写, 然后用纯文本(不依赖工具特性)的方式写, 这样换工具时只要改文件位置就能复用。

一个不该被忽略的争议:Skills 真的有用吗?

社区 Stage 1 调研发现一条重要反对声音, 译者诚实展示给你:

⚠️ Hacker News 讨论 AGENTS.md outperforms skills in our agent evals (thread #46809708) — Vercel 团队基于自家 agent 评测数据指出: 在他们的设置下, Skills 在 56% 的时间根本没被 agent 调用, 而把同样的内容直接写进 AGENTS.md 反而获得更稳定的输出。

这条数据点指向一个值得每个人都验证的现实问题:

Skill 的「按需调用」机制依赖 agent 自己判断「这个任务需要哪个 Skill」。 如果 agent 判断不准, Skill 就 silently 没被用上。

我作为译者的看法:

🟢 不要因为 Vercel 的数据放弃 Skills, 但要把它当成一个待优化的设计点。 实操建议:

1. 每个 Skill 在 description: 字段里写极强的触发信号(「ALWAYS use this skill when…」这种 Karpathy 式 caps lock 信号)
2. 周度审计:把过去一周用过的高频任务列出来, 看哪些「应该被某个 Skill 接住但没被接住」, 修正 description
3. 高频核心的 3-5 个 Skill, 在 Identity 文件里直接 reference 它们, 强制召回

🟢 这条争议本身比争议结果更重要 — 它说明 Agent OS 7 层不是完成态, 是一个有缺陷但被持续打磨的工程实践。 跟着用、跟着补, 别盲信、别盲弃。

落地步骤(给你下周的 7 天)

Day 1 · 列你的 Skill 候选清单(20 分钟)

回答 5 个问题:

1. 我每周必做但每次重新解释的工作流是什么?(目标: 列出 ≥ 5 个)
2. 我希望 AI 用我的语气写的内容是什么?(目标: 列 1-2 个写作场景)
3. 我跟 AI 对话时哪些是「拉数据 + 整合 + 输出」型任务?(目标: 列 ≥ 3 个)
4. 哪些任务我做完后 AI 的初稿质量低于 60%?(目标: 找 1-2 个可优化的)
5. 哪些是我只做过一次的任务?(目标: 别给这些写 Skill, 它们不算 pattern)

Day 2 · 起草第一个 Skill(30 分钟)

挑清单里第 1 名(最高频), 用三段式格式起草。 不要追求完美。

Day 3-7 · 每天用一次, 在末尾打补丁

每天用一次, 把它给的初稿和你修改后的版本对比, 把「它没做到的」记在 SKILL.md 末尾的 # notes 段。

Day 8 · 合并补丁, 起草第二个 Skill

把 7 天的 notes 合到正文。 然后起草下一个 Skill。

30 天后 · 你应该有 5-8 个 Skill

每天 30 分钟投入 → 30 天 → 5-8 个 Skill 已经稳定在 80%+ 输出质量。

常见坑

🟢 译者点评

🟢 「20-30 个固定模式」 这个数字很真实。 我做了一个简单测试: 翻自己最近 4 周的 Claude Code 历史, 用「我又一次解释这个东西」 作为标准, 数到的 patterns 是 23 个。 Nufar 的估计很准。

🟢 Skill 这一层的真正价值在于「让你工作的隐性结构变显性」。 写 Skill 的过程本身比 Skill 跑出来的结果更重要 — 你被迫定义 「我要的输出格式是什么」 「我会用哪几个来源」, 这个过程让你对自己的工作流有了之前没有的清晰度。

🟢 承接上一节的争议: 我倾向于「先把 Skill 写当 AGENTS.md / CLAUDE.md 的 import target」, 把核心 3-5 个 Skill 直接 reference, 而不是依赖按需召回。 这把「Skills 56% 没被调用」 的风险降到最低。

🟢 Hermes / agentskills.io 是值得关注的开放标准方向。 如果你想做长期可移植的 Skill 库, 现在就把文件结构按 agentskills.io 的格式写, 比绑死在某个工具的私有 SKILL.md 上更安全。

🔗 立刻去做

→ 列你的 Skill 候选清单(Day 1 的 5 个问题), 然后读 04 Memory · 记忆层 — 让你的 Skill 跨会话记住学到的东西。

🔗 延伸阅读

• HN — AGENTS.md outperforms skills in our agent evals — Vercel 评测数据 + 社区讨论
• Anthropic — Skills 文档 — Claude Code 官方 SKILL.md 规范
• github/awesome-copilot — Copilot 自定义 Agent 集合, 可以借鉴写法
• agentskills.io — Hermes 推动的跨工具 Skills 开放标准
• AIDB Agent Skills Masterclass (YouTube fs_Y3gvj7lk, 9,661 views) — Nufar 自己讲 Skills 的深度版