这篇文章也有英文版本Read in English →
Claude Skills 教学：从零开始打造你的 AI 自动化工作流
每个用 AI 工作的人，几乎都曾撞上同一面墙：你教会了它一件事，隔天开新对话，一切归零。
你花了三天调好一套工作流程，跟 Claude 来回对话搞定了。结果隔天又要从头解释。你把 prompt 存在笔记里每次贴，但一段 500 字的指令，每天贴一次，贴了一个月——你开始怀疑，这真的是 AI 该有的用法吗？
不是。有一个东西专门解决这件事——Agent Skills。
我用 Claude Code，所以这篇以 Claude Skills 为例。但同样的概念在 Cursor 叫 Rules、在 Codex 叫 Instructions——本质一样，格式也正在统一。
我现在每天早上输入两个字「开工」，Claude 自动跑完 8 个步骤——回顾昨天、查周目标、同步四个项目、建好今天的工作清单——然后把每个任务标上颜色：绿色 AI 直接做、黄色 AI 备好选项我来挑、红色我亲自处理、灰色今天不用动。3 分钟后问我：「今天先做哪个？」
因为我把这套流程写成了一个 skill，所以两个字，同样的步骤，同样的格式，每天都是。
这篇从头讲：Skill 是什么、怎么运作、怎么写、以及 Anthropic 自己怎么想这件事。
每次贴 prompt 的问题不只是烦——是浪费。
每贴一次，就占掉 context window 的一块空间。而 context window 是有限的。目前最强的 Claude Opus 也只有 200K tokens（大约 15 万字），听起来很多，但系统指令、MCP 工具描述、对话历史全部共用这个空间。你挂的工具越多、对话越长，能塞进去的指令就越少。我自己实测过，MCP 工具挂多一点，对话还没开始就已经吃掉一半的 context——剩下 50% 才是你真正能工作的空间。
还有一个更隐蔽的问题：做法不一致。 同样一件事，今天你这样解释，明天换个说法，Claude 的做法就不一样。有时候它会多做一步，有时候漏掉一步，有时候格式不对。没有标准化的 SOP，品质靠运气。
Skill 解决的就是这两件事：省 context、稳品质。 在 Anthropic 的开放标准里，这套机制叫 Agent Skills——不只 Claude Code 能用，Cursor、Gemini CLI、Codex 都支持同一套格式。但不管叫什么名字，内核都一样：让 AI 写进程、做任务时，按照你定义的 AI 工作流来运行，把重复性工作变成真正的 AI 自动化。
技术上，一个 Claude Code Skill 就是一个文档夹。内核是一份叫 SKILL.md 的 Markdown 文档——你的 SOP 写在这里。开头是一段 YAML 设置（告诉 Claude 这个 skill 做什么、什么时候该用），后面是具体的步骤和指令。
一个简化的例子：
---name: daily-planningdescription: 每日工作规划流程。当用户说「规划今天」「daily planning」 「早安」「开工」时使用。---
# 每日规划
## 步骤
1. 确认今天日期和星期几2. 读取最近两份 daily note，盘点 carry-over3. 读取周目标，确认进度和剩余天数4. 扫描各项目的进行中任务5. 创建今天的 daily note6. 根据优先级建议今天的工作项目--- 之间的 YAML 就是封面——Claude 靠这段判断要不要启动这个 skill（后面会细讲这件事有多重要）。下面的 Markdown 就是 SOP 本体。就这幺简单。
而完整的 skill 文档夹长这样：
my-daily-planning/├── SKILL.md ← 主要指令（必要）├── scripts/ ← 可运行的脚本（选用）├── references/ ← 参考文档（选用）└── assets/ ← 模板（选用）SKILL.md 是食谱本体——你的工作流程、步骤、判断逻辑都写在这里。Claude 读了就知道该怎么做。
其他三个文档夹是配料：
scripts/：需要跑进程的部分。比如一支 shell script 用来解析 CSV 数据、算统计数字，或是一支 Python 脚本用来调用外部 API。这种事用进程跑比叫 Claude 自己算更准。而且 scripts 可以直接运行，不需要加载 context window——前面说的 context 稀缺问题，这里又省了一块。references/：太长不适合塞在 SKILL.md 里的参考数据。比如一份 API 文档、一份风格指南、或一份决策规则表。Claude 需要时才去翻，不会每次都占用 context。assets/：模板和素材。比如 daily note 的 Markdown 模板，每天建新文档时直接套用，格式不会跑掉。
看出来了吗？这四个东西各自解决的问题不同，但背后都在服务同样两件事：省 context、稳品质。 Scripts 不占 context 又算得准，references 按需加载不浪费空间，assets 让输出格式标准化。整个 skill 文档夹的设计，就是围绕这两个内核在转。
写一次。之后每次对话，Claude 自动套用。不用贴 prompt，不用重复解释。
如果你用过 Claude Code 的 MCP（Model Context Protocol），你已经给了 Claude 一整间厨房——各种工具、食材、设备。
但有厨房不代表会做菜。
| MCP（厨房） | Skills（食谱） |
|---|---|
| 连接工具 | 教怎么用这些工具 |
| 提供即时数据访问 | 封装工作流和最佳实践 |
| 解决「能不能做」 | 解决「怎么做最好」 |
我的 Panopticon（内容监控系统）是一个好例子。MCP 让 Claude 能连到 API 抓取 Reddit、Hacker News、Product Hunt 的热门内容。但「抓到之后怎么处理」——筛选交互分数 4 以上的、分成 5 种内容类型、推荐 2-3 个题材——这些判断逻辑写在 skill 里。
MCP 提供能力。Skills 提供智能。
而且这两层都有了开放标准。MCP 统一了「工具怎么连」，Agent Skills 统一了「工具怎么用」。Agent Skills 是 Anthropic 在 2025 年底推出的开放标准，目前已被 30+ 工具采用——不只是 Claude Code，Cursor、VS Code Copilot、Gemini CLI、OpenAI Codex、JetBrains Junie 都支持。你写的 skill 可以跨平台使用。
我现在同时挂了 17 个 skills。如果每个都全部加载，Claude 会被信息淹没——想像一个厨师同时翻开 17 本食谱的所有页面。
所以 skill 不是一次全部加载的。它的解法是一个三层架构，叫 Progressive Disclosure（渐进式揭露）：
第一层：封面（永远加载，~100 tokens/skill）
就像食谱封面，只有两样东西：
name——这个 skill 叫什么description——做什么、什么时候该用（「番茄意大利面，适合周末午餐」）
Claude 读这个就知道什么时候该启动。
第二层：完整指令（觉得相关才加载，建议 < 500 行）
封面和完整指令都在同一份 SKILL.md 里。差别是：封面永远加载，但 Claude 只有判断「这个任务需要这份食谱」时，才会翻开来读后面的完整内容。
第三层：附加文档（按需查阅，无限制）
references/、scripts/、assets/ 里的东西。Claude 需要时才去翻。Scripts 可以直接运行，不需要加载 context。
这个设计让 17 个 skills 可以和平共存。我说「早安」，只有 /daily 被完整加载，其他 16 个安静待命。说「写 FB 贴文」，/content 被打开。说「SEO 研究」，/seo 被打开。每个 skill 只在被需要的时候才占用 context window。
三层架构里，第一层封面的 description 是最关键的——它决定你的 skill 会不会被触发。
Claude 靠这段文本判断：「用户现在说的话，跟这个 skill 有关吗？」判断方式是 LLM 自己的语义理解——它不是在做关键字比对，而是真的在「读懂」你的意图和 description 的描述，然后决定要不要启动。
听起来很聪明，但有一个问题：Claude 倾向保守。它宁可不触发，也不乱触发。有人做过实测，description 写得模糊的时候，自动触发准确率只有 55%。不是 Claude 读不懂你的意图，而是 description 写得不够明确时，它会选择「不确定就不启动」。
怎么写才对？一个好的 description 要回答两件事：
- 这个 skill 做什么——让 Claude 知道它的用途
- 用户会怎么说——具体的触发词，中英文都列
写得好的 description：
description: 每日工作规划流程。当用户说「规划今天」「daily planning」 「今日规划」「开工」时使用。做什么：每日工作规划。怎么触发：四组中英文关键字。Claude 读到「开工」就知道该启动。
写得烂的 description：
description: 帮助处理日常工作。只有一个模糊的用途，没有触发词。Claude 不知道用户会说什么话来启动它，结果就是永远不触发。
几个要注意的：
- 双语触发：如果你像我一样中英文混着用，description 里要同时写中英文触发词。「规划今天」和「daily planning」都要能触发同一个 skill。
- 宁可多写不要少写：因为 Claude 倾向保守不触发，Anthropic 自己建议 description 写得越明确越好——触发词多列几组，比少列安全。
Description 的角色其实跟产品的 landing page 一样。你怎么描述它，决定了别人（在这里是 Claude）会不会「点进来」。
Skill 不只是「把步骤写下来」。Anthropic 从早期用户中归纳了 5 种设计模式：
| 模式 | 做什么 | 例子 |
|---|---|---|
| 按步骤运行 | 有顺序的流程，步骤间有依赖 | 每日规划：回顾昨天 → 查周目标 → 建 daily note |
| 跨工具协作 | 串接多个工具，数据在系统间流动 | 项目初始化：建 GitHub repo → 生成文档夹 → 设置 CI/CD → 通知 Slack |
| 迭代校稿 | 做一版、检查、改、再检查，直到达标 | 内容校稿：初稿 → 简繁转换 → 品质检查 → 不过关就回去改 |
| 条件分支 | 同一个目标，根据情况走不同路径 | SEO 研究：根据输入决定查关键字、分析竞争对手、还是画产业版图 |
| 嵌入专业知识 | 把领域知识写进去，不只是工具操作 | Code review 标准：命名规则、错误处理原则、测试覆盖率，写一次就好 |
大部分好用的 skill 混用多种模式。你不用刻意套，但知道有哪些可能性，写的时候会更有结构。
Anthropic 的 skill-creator（官方用来写 skill 的 meta-skill）里有一段话，我觉得点出了写 skill 最重要的一件事：
Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs. （与其用一堆死板的 MUST 来压模型，不如跟它解释为什么这件事重要。）
用原因代替命令。
如果你发现自己在 SKILL.md 里写了很多「ALWAYS」和「NEVER」（全大写），那是一个信号——试着改成解释为什么。
举个例子。你在 skill 里可以这样写：
ALWAYS 在运行命令前显示命令内容。NEVER 直接运行。也可以这样写：
运行命令前先显示内容，因为用户需要确认安全性。未经确认就运行可能造成不可逆的损害。第一种写法，Claude 只会照做这两条规则。遇到规则没覆盖的情境（比如一个看起来安全但其实有风险的命令），它不知道该怎么判断。
第二种写法，Claude 理解了「为什么」——保护用户安全。所以即使遇到规则没写到的灰色地带，它也会倾向谨慎处理。原因让模型举一反三，规则只能覆盖你想到的情境。
唯一的例外是格式规范——「输出一定要用这个模板」这种机械性要求，没有「为什么」可以解释，直接写死就对了。
我的 /daily 现在是 v6。第一版很烂——步骤不清楚、路径写错、有些情况没处理到。
第二版加了内容发现系统集成。第三版发现周进度计算常出错，加了明确的计算规则。第四版加了自动触发——周二提醒跑周会、月初提醒归档。第五版加了 iPhone 轻量模式（侦测环境，手机上跳过需要 Python 的步骤）。
每一版都是在使用中发现「这里不够好」，然后改。
Skill 不是写完就丢着的设置档——它是你工作流的活文档。你的工作方式会变，需求会变，skill 跟着变。每改一次，你对自己的工作流就多理解一层。这个过程本身就在逼你思考：「我到底是怎么工作的？哪些步骤真的重要？」
Anthropic 的指南里也说了同样的话：
先在一个具体任务上反复尝试，直到 Claude 做对。然后再把成功的方法抽取成 skill。
不要追求一步到位。今天做一个 v1，用几天发现问题改成 v2。好的工作流是长出来的，不是设计出来的。
我是从一个 /daily 开始的。用了一阵子之后，发现每周一人周会的流程也在重复，做成了 /wam。后来关键字研究每次都要重新解释策略，做成了 /seo。再后来 YouTube 视频分析的 API 串接也固定了，做成了 /youtube。
每一个 skill 都是因为「这件事我重复做了太多次」才诞生的。不是坐下来规划「我需要哪些 skill」，而是日常工作中自然长出来的。
半年后我回头看，已经有 17 个了——不是因为我一开始就计划好，而是因为每天都在用、每次遇到重复的事就多封装一个。
举几个我日常在用的 skill，让你有个感觉：
| Skill | 做什么 | 为什么值得做成 Skill |
|---|---|---|
/daily | 每日工作规划（8 步骤） | 每天都要跑，步骤多且有依赖关系 |
/seo | SEO 关键字研究（8 个子模式） | 查找流程固定，但每次参数不同 |
/content | 内容创作 + 风格校稿 | 写作风格要一致，靠记忆不可靠 |
/wam | 每周一人周会 | 固定流程：算分 → 回顾 → 规划下周 |
/youtube | YouTube 视频转译分析 | API 串接 + 后处理逻辑不想每次重写 |
不用一开始就做很多。从一个你每天都在做的重复性工作开始。
你不需要自己手写 SKILL.md。不管是让 AI 写进程还是写 Skill，Claude 都能帮你搞定。实际上我自己的 skills 没有一个是手写的。
有两条路：
路线 A：让 Claude 帮你写。
最自然的方式。你先在对话中反复尝试某个工作流，直到 Claude 做对。然后跟它说：「把刚才的流程做成一个 skill。」它会自动生成 SKILL.md、建好文档夹结构。你试用几天，发现不对的地方再叫它改。
Anthropic 官方甚至有一个专门做这件事的 skill，叫 skill-creator（2026 年 3 月初刚做了重大升级）。你在 Claude Code 里启动它，Claude 会像访谈一样问你问题——你的工作流长什么样、什么时候该触发、有哪些边界条件——然后根据你的回答自动产出 SKILL.md。
不只是产出。它还能帮你测试和优化：
- Eval：自动生成测试案例（「用户说 X，skill 应该做 Y」），验证 skill 能不能正确触发
- Improve：根据测试结果自动优化 description 和指令，用 60/40 train/test split 防止 overfitting
- Benchmark：追踪成功率、token 用量，甚至能跑 A/B test——两个版本盲测对决
路线 B：从社群找起点再客制。
现成的 skills 到处都有。最大的目录是 SkillsMP，收录了 96,000+ 个从 GitHub 聚合的 skills。Anthropic 官方 repo 数量少但品质有保证。社群也有 Awesome Agent Skills 策展清单，收录了 Anthropic、Vercel、Stripe、Cloudflare 等官方团队发布的 skills。
但要注意：社群 skill 是通用的起点，不是你的终点。一个通用的「每日规划」skill 不知道你用什么项目管理工具、你的周目标格式长什么样、你习惯怎么排优先级。真正好用的 skill 一定是根据你自己的工作流客制过的——这也是为什么我的 /daily 改了六版才到现在的样子。
不管哪条路，关键都一样：先做对一件事，再封装。 不要一开始就想设计一个完美的 skill。v1 能用就好，用了几天发现漏洞再改。我的 /daily 改了五次才变成现在的样子。
每次开新 session，Claude 都是一个什么都不知道的新人。Skill 就是你给它的 onboarding 手册——读完就知道你的流程、你的标准、你的偏好。不用每次重新带，开口就能上手。
/daily 是行政助理，/wam 是周会主持人，/content 是写作教练。每一个都是最懂你的资深员工——知道你的偏好、熟悉你的流程、记得你上次踩过的坑——不是第一天报到的实习生。
Agent Skills 本身不难——就是 Markdown 加上一些结构。但它代表的趋势很重要：AI 从「你每次都要教它」变成「你教一次就好」。
而且这个标准是开放的。你今天在 Claude Code 写的 skill，明天可以搬到 Cursor、Gemini CLI、Codex 上用。你投入的时间不会被绑定在一个平台上。
对我来说，Agent Skills 是 Agentic Coding 从「能用」变成「好用」的那一步。工具接好了（MCP），知识封装好了（Skills），剩下的就是让 AI 按照你的方式做事——不管你用它来写进程、做研究、还是把日常管理变成 AI 自动化流程。
想在一天内把这些串起来？ 10/24（六）杭州班招生中——6 小时实作工作坊，带你用 Claude Code + Obsidian 建好目标追踪、知识库、自动化脚本（FLUX 系统），不用自己摸三个月。看工作坊详情 →
Skills 是零件、不是系统。整套 FLUX 是怎么跑的 →
如果这篇让你有了想法，订阅电子报——我固定写 AI 工作流、和一路上想通的事。
想聊聊怎么把 AI 融入你的工作流？看看我的服务。
常见问题
- Claude Skills 是什么？
- 解决「每次开新对话都要重新教 AI」的问题。一个 skill 是一个文档夹：SKILL.md（主要指令，YAML 封面 + Markdown 步骤）、scripts/（可运行脚本）、references/（参考文档）、assets/（模板）。写一次，之后每次对话自动套用。
- Skills 和 MCP 有什么不同？
- MCP 让 Claude 连到外部工具和 API（解决「能不能做」），Skills 教它拿到数据后怎么处理（解决「怎么做最好」）。以我的 Panopticon 为例：MCP 负责从 Reddit、Hacker News 抓内容，Skill 负责筛选交互分数 4 以上的、分成 5 种内容类型、推荐 2-3 个题材。
- 不会写进程也能用 Skills 吗？
- 可以。SKILL.md 就是 Markdown，不需要写代码。你甚至不用自己手写——Anthropic 官方有一个叫 skill-creator 的 skill，启动后 Claude 会像访谈一样问你问题（工作流长什么样、什么时候触发、有哪些边界条件），然后自动产出 SKILL.md 和文档夹结构。
- Skills 只能在 Claude Code 上用吗？
- 不是。Agent Skills 是 Anthropic 2025 年底推出的开放标准，目前已被 Cursor、VS Code Copilot、Gemini CLI、OpenAI Codex、JetBrains Junie 等 30+ 工具采用。你写的 skill 可以跨平台使用，不会被绑定在单一工具上。
- 一个 Skill 能写多长？
- SKILL.md 建议控制在 500 行以内。超过的话用三层架构处理：封面（name + description，~100 tokens）永远加载，完整指令被触发时才加载，太长的参考数据拆到 references/ 文档夹按需查阅。这样 17 个 skills 同时挂着也不会塞爆 context window。
