用 AI Skills 武装你的写作流程，从此告别重复劳动

每次让 AI 帮我写技术文章，我都得重新交代一遍：“你是一个有 20 年经验的工程师，语言要接地气，开头要有钩子，结尾要总结，不要废话……”

打完这段话，文章还没开始写，我已经累了。

这就是我开始研究 Agent Skills 的起点。研究完之后，我只想说：早该有这东西了。

一、什么是 Agent Skills？

2025 年 12 月 18 日，Anthropic 把 Agent Skills 作为一个开放标准发布出来，规范地址在 agentskills.io。OpenAI Codex、GitHub Copilot、VS Code 等主流平台随后跟进支持。

官方文档对 Skills 的定义是：

Skills are reusable, filesystem-based resources that provide Claude with domain-specific expertise: workflows, context, and best practices that transform general-purpose agents into specialists.

翻译成人话：Skill 是一个文件夹。里面放着你对 AI 的"专项培训材料"。当 AI 遇到匹配的任务时，它会自动加载这个文件夹里的内容，按照你的规范工作——不用你每次都重新解释。

用一个生活比喻：你雇了一位新助理，第一次你花了两个小时教她公司的排版规范、写作风格、邮件模板。从第二次起，你只需要说"按老规矩来"，她就能做对。Skill 就是那份"老规矩"的电子版。

老墨说： Skill 解决的核心问题是重复交代——把每次对话都要说的上下文、规范、工作流程，封装成一个可复用的模块。

二、为什么需要 Skills？我们之前是怎么活过来的？

在 Skills 出现之前，工程师们靠这几种方式解决"AI 重复交代"的问题：

方式一：超长 System Prompt 把所有规范塞进系统提示词。项目越做越大，提示词从 200 tokens 膨胀到 5000 tokens，AI 变慢、变贵、还容易"跑偏"，因为它在同时消化太多东西。

方式二：反复复制粘贴 在新对话里每次手动粘贴上次的规范。累，而且容易忘。

方式三：代码里写死 Prompt 把 Prompt 藏在 Python 字符串里、YAML 里。非技术同事改不了，版本管理是噩梦，改个措辞要走代码发布流程。

方式四：不同项目各自维护一套 项目 A 的代码审查规范和项目 B 的同步不上，两套规范各自演化，最终谁也不知道哪个是"正确"的。

Skills 一次性解决了上面所有问题。

Skills 的三级加载机制（关键！）

这是 Skills 最精妙的设计，也是大多数人第一次看到会拍桌子的地方。Anthropic 官方文档对此有详细说明：

Level 1：元数据（始终加载，约 100 tokens/个） AI 启动时，只读每个 Skill 的 name 和 description 两个字段。全部 Skill 加起来消耗的上下文极少，AI 知道"我有哪些专项能力"，但不会把所有规范都塞进脑子。

Level 2：指令（触发时加载，< 5k tokens） 当你的请求匹配到某个 Skill 时，AI 才去读 SKILL.md 的完整内容。只在需要的时候出现，不需要时不占位置。

Level 3：脚本和参考文档（按需执行/读取，无限制） Skill 里打包的额外文件、可执行脚本，AI 用到时才加载。脚本执行后只有输出结果进入上下文，脚本代码本身不占 token。

这就像你的硬盘：你不会把所有文档都开着，只在需要时打开对应的文件。

三、Skills vs. 那些长得像它的东西

用了一段时间 Skills 之后，我发现最容易混淆的是这五个概念。这篇对比分析写得相当全面，推荐一读：

维度SkillsMCPPromptsProjectsSubagents
是什么培训手册通信协议当场指令工作台专项员工
持久性永久可复用依赖服务会话内有效项目内有效流程内有效
适合做封装工作流和规范连接外部工具/数据临时单次任务持久背景知识隔离执行任务
类比公司 SOP 手册网线/接口今天开会说的话项目文件夹外包团队

一句话区分：

  • 要教 AI 怎么做某件事 → Skills
  • 要给 AI 接入外部数据 → MCP（Model Context Protocol）
  • 要临时告诉 AI 一次性要求 → Prompt
  • 要给 AI 一个持久的项目上下文 → Project
  • 要让 AI 隔离独立地执行某个任务 → Subagent

有一个组合拳我用得很顺：用 MCP 连 Notion 读数据，用 Skill 告诉 AI 怎么把数据格式化成周报，用 Project 存放这个项目的背景信息。三者互相配合，效果远好于单独使用任何一个。

老墨说： Skills 是"教"，MCP 是"连"，Prompt 是"说"，Project 是"记"，Subagent 是"派"。木工不会用锯子敲钉子，AI 工具也一样，选错了工具，活干得再努力也是白费。

四、Skill 的目录结构长什么样

一个 Skill 的最小形态只是一个文件夹 + 一个文件：

1my-skill/
2└── SKILL.md          # 唯一必须的文件

完整形态可以是这样：

 1my-skill/
 2├── SKILL.md           # 主文件：元数据 + 核心指令（必须）
 3├── REFERENCE.md       # 参考文档：详细规范、API 文档（按需加载）
 4├── EXAMPLES.md        # 示例：输入/输出样例（按需加载）
 5├── scripts/           # 脚本目录：可执行的确定性操作
 6│   ├── validate.py    # AI 执行它，只看输出，代码不入上下文
 7│   └── format.sh      # 格式化脚本
 8├── references/        # 参考资料：文档、Schema、模板
 9│   └── schema.json
10└── assets/            # 静态资源：图片、字体、模板文件
11    └── template.md

SKILL.md 的结构

这是 Skill 的核心文件，由两部分组成。官方 Best Practices 文档对每个字段都有详细说明：

 1---
 2name: your-skill-name        # 必须：小写字母、数字、连字符，需与目录名一致
 3description: 这个 Skill 做什么，什么时候用它。写得越具体，AI 触发得越准确。
 4metadata:
 5  version: "1.0"
 6  author: GeekMo
 7---
 8
 9# Skill 名称
10
11## 主要指令
12...具体的工作流程、规范、步骤...
13
14## 参考
15如需详细规范，见 [REFERENCE.md](REFERENCE.md)

description 字段是触发的关键，写得模糊就没法自动触发。官方有个反例：

1# 坏：太模糊
2description: Helps with documents
3
4# 好：明确说清楚做什么、什么时候用
5description: 从 PDF 提取文本和表格，填写表单，合并文档。当用户提到 PDF、表单提取、文档合并时使用。

Skill 存放位置决定作用范围：

1~/.accio/skills/          # 个人全局（所有 Agent 可用）
2~/.claude/skills/         # Claude Code 个人级别
3.claude/skills/           # 项目级（跟随 Git 仓库）, 每一个IDE的目录可能不同

不同的工具或者IDE，skills的规范不同，但大多数都支持claude的目录规范，详情请查阅官方文档。

五、Skills 的优缺点，老实说

用了一段时间，优点是真的，缺点也不能捂着不说。

优点：

  • 上下文高效：三级懒加载，装了 50 个 Skill 也不会撑爆上下文
  • 可复用、可版本化：放进 Git，协作和历史追踪都有了
  • 跨平台标准：一次编写，Claude / Codex / Copilot 理论上都能用（见 agentskills.io 规范）
  • 非技术人员可维护：SKILL.md 就是 Markdown，产品经理和运营也能改

缺点：

  • 非确定性：AI 解读指令，结果有波动。对精度要求极高的操作，用脚本（scripts/）比用文字描述更可靠
  • 触发 description 要精心设计：写得不好就不触发，需要测试迭代
  • 调试不直观：Skill 没有触发时，很难第一时间知道是 description 问题还是指令问题
  • 跨平台行为差异：标准开放，但各平台实现细节不同，Bibek Poudel 的这篇实测文章记录了不少这方面的细节

六、从零编写一个"技术文章写作 Skill"

说了这么多理论，动手写一个。

场景：每次写技术文章，都要先搜资料、整理内容、再按照自己的风格撰文。这个流程重复且耗时，非常适合封装成 Skill。

第一步：判断这个场景适不适合做 Skill

适合的信号：

  • ✅ 这个流程会重复执行（每次写文章都用）
  • ✅ 包含明确的工作步骤（搜索 → 整理 → 撰写）
  • ✅ 有固定的风格规范（不想每次重新解释）
  • ✅ 输出格式固定（Markdown + frontmatter）

不适合做 Skill 的反例：

  • ❌ 只用一次的临时任务 → 直接 Prompt
  • ❌ 需要实时连接外部数据库 → MCP + Skill 配合
  • ❌ 必须精确到字节级别的操作 → 脚本，不是 Skill

结论：非常适合。

第二步：规划 Skill 的结构

1geekmo-tech-writer/
2├── SKILL.md          # 主文件：人设 + 写作工作流
3└── WRITING-STYLE.md  # 参考：详细的风格指南（按需加载）

设计简单：把风格细节拆到 WRITING-STYLE.md，减少 SKILL.md 的体积，只在 AI 真正需要风格参考时才加载。

第三步：写 SKILL.md

先写 description（最重要，决定触发准确率）：

1---
2name: geekmo-tech-writer
3description: 极客老墨技术文章写作助手。当用户要求"用极客老墨风格写文章"、"帮我写一篇技术文章"、"写篇博客"时触发。先联网搜索最新资料，整理内容，再以极客老墨的独特风格撰写技术文章，支持配图生成建议。
4---

然后写工作流程（核心是分步骤，不要一锅炖）：

 1## 工作流程（按顺序执行，不可跳步）
 2
 3### Step 1：联网搜索，建立知识底座
 41. 优先访问官方文档（权重最高）
 52. 搜索：{主题} + "best practices" / "internals" / "2025"
 63. 搜索中文社区获取工程师实战视角
 74. 整理：核心概念、常见坑、真实案例
 8
 9### Step 2：规划文章结构
10根据文章类型选对应模板：
11- 概念科普型：故事引入 → 定义 → 原理 → 对比 → 场景 → 总结
12- 实战教程型：痛点 → 方案 → 步骤 → 踩坑 → 总结
13- 深度解析型：现象引入 → 表层 → 深入原理 → 启示 → 总结
14
15### Step 3：配图规划与封面生成
16每篇公众号文章必须生成封面图（比例 2.55:1，科幻风）
17正文配图文件名统一使用中文
18
19### Step 4：撰写文章（严格按风格规范 + 引用必有超链接出处）

第四步：写风格人设（这是让 AI 真正"活"起来的部分）

在人设里要说清楚三件事：是谁、怎么说话、什么不能做。

 1## 人设：极客老墨
 2
 3你是一位拥有 20 年技术经验的全能工程师与写作专家。
 4
 5**说话方式：**
 6- 开篇必须有钩子，前三句话决定读者走不走
 7- 技术概念先用生活比喻热身，再进入正题
 8- 每个重要知识点后有"老墨说"小结，锁定核心
 9- 结尾"老墨总结"给出真正的判断，不是罗列
10
11**引用规则（铁律）：**
12- 所有引用必须有超链接：[来源名称](URL)
13- 包括：官方文档、名人语录、数据报告、外部博客
14
15**禁止行为：**
16- 禁止"在本文中，我们将..."这类废话开头
17- 禁止没有灵魂的 Markdown 列表堆砌
18- emoji 全篇不超过 3 个
19- 禁止裸引用——所有引用必须可点击

第五步：测试和迭代

写完不等于完成。测试流程：

1. 用"帮我写一篇关于 Docker 网络的文章"触发 Skill，看是否自动激活
2. 检查 description 是否准确描述了触发场景
3. 看输出是否真的"联网搜索了"、"按步骤执行了"、"引用有超链接了"
4. 根据实际输出调整指令的颗粒度

一个实用技巧：如果 Skill 不触发，90% 是 description 的问题，不是指令的问题。先改 description，再考虑改指令。这个经验来自 Anthropic 官方 Best Practices 的建议，实测完全准确。

七、配图这件事，Skill 能帮多少忙

文章里需要配图，有三种处理方式：

1. 截图类：Skill 在对应位置插入占位符提醒你后期补充。

2. 流程图/架构图：Skill 生成 Mermaid 代码，渲染工具直接出图：

graph LR
    A[用户请求] --> B{描述匹配?}
    B -->|匹配| C[加载 SKILL.md]
    B -->|不匹配| D[跳过]
    C --> E[执行工作流]
    E --> F[输出结果]

3. AI 生成概念图：在 Skill 里约定 prompt 规范，调用 image_generate 工具直接生成，自动存入 assets/，文件名使用中文，自动插入文章。

这就是本文配图的生成方式——那几张架构图和流程图，都是在写文章时顺手生成的，没有单独找设计师，也没有手绘，AI 一步完成。

老墨总结

Skills 这个东西，对我来说不是"探索新技术"，而是"终于有人把这件事做对了"。

把它放到实际场景里：

适合用 Skills 的人：

  • 经常重复某类任务（写文章、写周报、审代码、生成报告）
  • 有明确的风格规范想让 AI 遵守
  • 多个项目共享一套工作方式

不需要折腾 Skills 的情况：

  • 只是偶尔用一次 AI 的临时用户
  • 任务每次差异很大，难以模板化

对于我自己的写作流程，这个 Skill 写完之后，从"想写一篇文章"到"有一篇可以审查的草稿"，时间从 3 小时压缩到 30 分钟。剩下的时间我用来改内容、加自己的判断，而不是从零搭架子。

这才是 AI 工具应该有的用法：把重复的脚手架工作交给它，把真正需要人类判断的部分留给自己。

文章有帮助？转发给同样在重复劳动的技术同学。有想法或不同意见？评论区见。

关注公众号：极客老墨

更多 AI 应用开发、工程实践和效率工具分享，欢迎扫码关注。

极客老墨微信公众号二维码

相关阅读