2024年AI Skill编写教程：手把手教你复刻工作流

AI Skill 的实际定义与运作机制

多数AI使用者都听过“Skill”这个词，但对其准确定义和实际用途往往模糊。本质上，Skill 相当于 AI 的“专项能力组件”——一个为特定任务类型预封装的操作单元。

与临时提示词不同，Skill 不依赖实时联网或外部插件。它将特定任务领域的经验沉淀、规则约束、执行流程和边界条件统一封装，实现复用。

每次要求AI撰写周报时反复强调的约束——避免空泛表述、严禁编造数据、聚焦成果与问题——这些重复性指令完全可以固化为可执行的规则体系。这正是 Skill 的核心价值。

下面以“工作总结写作”为实战案例，逐步演示如何创建一个名为 work-summary-writing 的 Skill，完整覆盖从设计到落地的全流程。

最小可用 Skill 的文件结构

一个最简 Skill 只需一个 SKILL.md 文件即可启动：

work-summary-writing/
└── SKILL.md

当功能复杂度提升后，可按需扩展目录层次：

work-summary-writing/
├── SKILL.md
├── scripts/
├── references/
└── assets/

各目录承担明确的职能边界：

初期不必追求目录结构的完整性。先把核心文件打磨到能稳定触发并输出合格结果，第一版即算达成。

第 1 步：锁定 Skill 要解决的具体问题

切忌一开始就试图构建“万能写作Skill”。Skill 的职责边界越精确，执行稳定性越强。

举例来说，如果描述写成“辅助用户完成各类写作”，这个范围过于宽泛——邮件正文、代码注释、广告文案、产品文档都被包含在内。模型反而无法确定该遵循哪套规则。

本次只聚焦一个明确场景：用户需要撰写工作总结、周报、月报、季度总结等文本时触发。边界清晰，Skill 的执行才有据可循。

第 2 步：创建 Skill 专属目录

不同AI工具对 Skill 目录的存放路径要求各异。以 Codex 为例，全局 Skill 通常放置在用户目录下的指定路径中。

执行创建命令：

mkdir -p ~/.codex/skills/work-summary-writing

若使用 Claude Code，路径通常为 ~/.claude/skills/。核心原则是确保目录位于对应 Agent 能够自动识别的扫描路径内。

第 3 步：编写 FrontMatter 配置

SKILL.md 头部 YAML FrontMatter 是整个 Skill 的配置中枢：

---
name: work-summary-writing
description: 撰写、润色或整理中文工作总结类文档时使用，包括周报、双周报、月报、季度总结、半年/年度总结、项目复盘、阶段性汇报、述职报告、工作小结等。当用户说"帮我写个周报"、"整理一份月度工作"、"年终总结"、"项目复盘"、"做汇报材料"、"述职"，或扔过来一堆零散工作记录要求"总结一下"、"整理成报告"时，都要主动启用。该技能用于帮助用户把零散工作内容整理成结构清晰、重点明确、表达正式自然的总结文本。
---

description 字段的价值常被低估——它不是给人类阅读的简介，而是 AI 判断“何时加载该 Skill”的决策依据。因此至少需要明确三层信息：

• 该 Skill 具备什么能力。
• 适配哪些典型场景。
• 用户发出哪些指令时应被触发。

避免写成“辅助撰写总结类文档”，过于简短且语义模糊。

第 4 步：将流程拆解为可执行步骤

Skill 本质上是一份操作手册，而非理念宣言。与其描述“写出专业、自然、有逻辑的内容”，不如将任务拆解为具体的操作动作。

以下是一份完整的 SKILL.md 示例，注意观察它如何将“撰写总结”分解为一系列可执行的步骤节点：

---
name: work-summary-writing
description: 撰写、润色或整理中文工作总结类文档时使用，包括周报、双周报、月报、季度总结、半年/年度总结、项目复盘、阶段性汇报、述职报告、工作小结等。当用户说"帮我写个周报"、"整理一份月度工作"、"年终总结"、"项目复盘"、"做汇报材料"、"述职"，或扔过来一堆零散工作记录要求"总结一下"、"整理成报告"时，都要主动启用。该技能用于帮助用户把零散工作内容整理成结构清晰、重点明确、表达正式自然的总结文本。
---

# 工作总结写作

## 写作步骤

### 1. 明确总结范围
先判断总结的时间范围、使用场景和目标字数，例如：
- 周报
- 月报
- 季度总结
- 年度总结
- 项目阶段总结
- 个人工作复盘
如果用户没有说明时间范围，可使用“本阶段”作为默认表述。字数默认800-1200字。

### 2. 提炼核心工作
从用户提供的信息中提取主要工作内容，优先识别：
- 负责了什么任务
- 推进了哪些项目
- 解决了哪些问题
- 参与了哪些协作
- 完成了哪些交付

### 3. 整理工作成果
将工作内容转化为结果表达，尽量补充：
- 完成情况
- 进展状态
- 产生的价值
- 效率提升
- 问题解决效果
- 可量化数据
注意：没有数据时不要编造，使用稳妥表达。

### 4. 分析问题与不足
客观总结合存在的问题，可以从以下角度整理：
- 进度是否受阻
- 沟通是否充分
- 流程是否顺畅
- 方案是否还有优化空间
- 个人能力是否需要提升
表达要克制，不夸大也不回避。

### 5. 提炼经验与反思
重点写哪些方法有效、哪些流程可复用、哪些协作方式值得保留、后续如何改进。

### 6. 制定下一步计划
计划应具体、可执行，例如继续推进任务、优化流程、提升能力等。

## 字数要求
- 优先遵循用户明确要求。
- 默认800-1200字。
- 要求“简短”时300-600字。
- 要求“详细”时1200-2000字。
- 不凑字数，不删关键事实。

## 推荐结构
一、总体情况
二、主要工作
三、工作成果
四、问题与不足
五、经验总结
六、下一步计划

## 注意事项
- 不虚构关键事实、数据、项目名称。
- 信息不足时使用通用表达。
- 表达正式、自然、简洁。
- 多写具体行动，少写空泛态度。
- 总结个人工作时突出职责，不过度夸大。
- 问题与不足要真实可改进。
- 下一步计划要呼应前文。

## 输出要求
默认输出完整工作总结。只要求框架时输出结构。提供素材时优先基于素材改写。

至此，一个最小可用版本的 Skill 已经搭建完成。

第 5 步：验证 Skill 触发效果

保存文件后，使用真实场景的提示词进行测试：

帮我写一份本周工作总结。

或者：

把下面这些工作记录整理成月报，正式一点，控制在1000字左右。

测试时重点关注三个维度：是否按工作总结场景响应，是否遵循预设结构和字数规范，是否在信息不足时编造数据。若触发不稳定，优先优化 description 字段；输出质量波动，则细化正文中的执行步骤和边界约束。

第 6 步：何时引入 scripts、references 和 assets？

并非所有 Skill 都需要额外目录。像“工作总结写作”这类偏文本生成的场景，通常一个 SKILL.md 即可满足需求。

当任务复杂度提升后，再考虑按需拆分资源：

• 如果需要稳定执行文件扫描、数据导出等重复操作，将脚本放入 scripts/。
• 如果有大量操作规范、接口文档等知识体系，用 references/ 承载。
• 如果需要模板文件、参考图片等输出素材，统一存放在 assets/。

这种分层结构让 AI 无需每次重新推理，输出一致性也随之提升。

手写 Skill 的常见陷阱

手动创建 Skill 有助于理解底层原理，但有几个易错点需要规避：

1. description 边界过于模糊

反面案例：description: 写作助手

这种描述几乎能匹配任何写作类请求，边界形同虚设。更有效的做法是明确列出适用场景、触发关键词和核心能力。

2. 只写原则性要求，缺乏操作步骤

反面案例：输出内容需专业、自然、有深度。

真正的“专业”需要被拆解为具体动作——先确定总结范围、再提炼核心工作、然后整理成果……每一步可执行才算有效。

3. 将全部内容堆砌在 SKILL.md 中

当文件篇幅持续膨胀时，应当将长篇幅规范迁移到 references/，重复性操作封装到 scripts/，模板素材归类到 assets/。

4. 缺少反面约束和禁区声明

多数输出偏差并非源于 AI 不知道该做什么，而是不清楚哪些行为被禁止。例如工作总结中必须声明：不虚构数据、不写空口号、不夸大问题、不凑字数。限制条件越明确，输出越可控。

下一步：借助 skill-creator 实现自动化创建

手写流程走通一遍之后，就可以引入 skill-creator 了。它本身也是一个 Skill，专门负责其他 Skill 的创建和更新操作。目录结构编排、FrontMatter 配置、资源拆分，都由它自动处理。

安装完成后，直接通过指令启动：

使用 skill-creator，帮我创建一个 work-summary-writing skill。
目标：当用户需要写工作总结、周报、月报等时触发。
能力：1. 判断范围 2. 提炼核心 3. 整理成果 4. 输出正式总结。
注意事项：不虚构数据、信息不足时稳妥表达、避免口号、计划具体。
位置：安装到全局 Claude skills 目录。

这类结构化请求比“帮我创建一个写周报Skill”稳定得多。边界清晰，skill-creator 才能准确执行。

skill-creator 的自动化交付清单

它不仅是生成一个空目录。而是从“另一个 AI 后续如何使用该 Skill”的视角，帮你完成以下检查：

1. 理解待解决的任务本质。
2. 梳理触发条件和适用场景。
3. 评估是否需要配套资源目录。
4. 创建目录结构并生成核心文件。
5. 编写完整的配置信息和执行流程。
6. 按需补充辅助资源文件。
7. 验证结构完整性和路径正确性。
8. 支持基于实际使用反馈进行迭代优化。

为什么选择 skill-creator 而非手写？

手写适合理解底层逻辑。但如果要长期投入生产环境，交给 skill-creator 起草和迭代效率更高，四个核心优势：

1. 对 Skill 结构理解更系统

一个 Skill 涉及命名规范、触发条件、可执行流程、边界约束、资源拆分等多个维度，手动编写容易遗漏关键要素。

2. 降低触发错误率

低质量 Skill 最常见的缺陷是 description 写得太宽泛或太狭窄。它会引导你把能力边界、场景匹配和触发词写具体。

3. 资源拆分策略更合理

很多人习惯把所有规则塞进单一文件。它能根据任务特征判断是否需要脚本、参考资料或素材文件，实现按需加载。

4. 适合持续迭代维护

一个成熟的 Skill 通常不是一次性完成的。真实使用后触发不准、输出不稳、步骤遗漏等问题，可以持续用它进行诊断和更新。

手写与 skill-creator 的选择矩阵

因此建议：先手写一个最小可用版本，理解核心字段和流程的工作方式。后续要创建正式可用的 Skill，再交由 skill-creator 处理。

核心要点总结

构建 Skill 的关键不在于把提示词写长。真正的价值在于将高频任务固化为一套可触发、可执行、可维护的自动化工作流。

一个高质量的 Skill 至少需要回答四个问题：何时触发？触发后按什么顺序执行？输出格式和规范是什么？哪些行为被明确禁止？

手写能帮你建立底层认知，skill-creator 则擅长将结构做完整，并在持续使用中迭代优化。第一版不需要追求完美，先让它跑通流程。触发偏了就补条件，输出偏了就调规则，文本表现不稳定就拆资源加脚本。Skill 的能力是在使用过程中逐步增强的。