AI Skill 工作流沉淀：从重复提示词到可复用系统

一句话总结

提示词解决一次任务，Skill 固化一类任务——本文带你从 0 开始，把重复了无数次的 AI 对话沉淀成一套可安装、可测试、可分享的个人工作流。

---

如果你每周都要把同一段要求重新发给 AI，这篇文章就是写给你的。

比如每周五，你都要告诉 AI：「先整理本周成果，再提炼问题和经验，最后列出下周行动。不要编造数据，每个行动都要有完成标准。」一次这样写叫提示词，每周都这样写——背后其实已经有了一套固定工作流。

把这套工作流整理成一个文件夹，让 AI 以后遇到类似任务就知道什么时候接手、按什么步骤执行、结果达到什么标准，这就是 Skill。

什么是 Skill？

你可以把 AI 编程助手想成一位能力很强、但刚入职的新同事。它懂代码、写作和分析，但不知道：

• 你在什么情况下会启动某项工作
• 你习惯先做什么、后做什么
• 哪些规则不能违反
• 输出必须包含哪些栏目
• 做到什么程度才算合格

Skill 就是你交给这位新同事的「岗位说明书 + 标准作业流程 + 必要工具和资料」。

一份 Skill 通常会告诉 AI 四件事：

1. 什么时候使用：哪些任务和说法应该触发它
2. 怎么执行：收到任务后按什么步骤工作
3. 可以用什么：脚本、参考资料或模板放在哪里
4. 什么算完成：最终输出必须满足哪些标准

普通提示词通常只服务当前对话。Skill 会保存在固定目录中，之后你可以用 $skill-name 点名，也可以让 AI 根据任务自动判断是否使用。

---

什么工作流值得做成 Skill？

不要看到任何提示词都急着做 Skill。先用下面四个问题筛选：

1. 这件事是不是会重复发生？
2. 它有没有相对稳定的输入和输出？
3. 中间是否存在固定步骤、规则或判断标准？
4. 如果换一个 AI，你是不是还要重新解释一遍？

其中三个回答「是」，通常就值得沉淀。

适合的例子：每周复盘、X 长文写作、发布前检查清单、合同风险审核、固定格式的客服回复、重复处理同一类表格数据。

不适合的例子：一次性临时任务、一句话就能说明白的操作、完全依赖临场创意的任务、「帮我处理所有内容」这种没有边界的大目标。

好的 Skill，不是无所不能，而是能把一件具体的事稳定做好。

---

第 1 步：把工作流写到纸面上

先不要急着创建文件。选一件你最近一个月重复做过至少两次的工作，然后写出这张「工作流卡片」：

工作流名称：____
什么时候启动：____
用户会提供什么：____
执行步骤：
  1. ____
  2. ____
  3. ____
最后输出什么：____
什么结果算合格：____
信息不足时怎么办：____

以「每周复盘」为例：

工作流名称：把一周的零散记录整理成复盘
什么时候启动：用户提出周报、每周复盘、一周总结时
用户会提供什么：一周内完成的事情、问题、数据和下周计划
执行步骤：
  1. 提取事实和数据
  2. 分类为成果、进展、问题和经验
  3. 合并重复内容
  4. 把未完成事项转成下周行动
  5. 检查是否存在编造或空话
最后输出什么：结构化周复盘和下周行动表
什么结果算合格：保留原始数据；不虚构；行动有优先级和完成标准
信息不足时怎么办：标记"待补充"，最多提3个问题，不要猜

这张卡片很重要——因为 Skill 的 description、工作流程和质量标准，都来自这里。如果你填不完，说明这件事可能还没有形成稳定的工作流——先多做几次，记录自己每次的判断，再回来做 Skill。

---

第 2 步：准备 3 个真实触发案例

很多人只写了「这个 Skill 能做什么」，却没想过「用户会怎么说」。结果文件写得很长，但 AI 根本不知道什么时候应该使用。

写三句用户可能真的会说的话：

1. 明确点名：请使用 $weekly-review 整理这周的记录。
2. 自然表达：帮我把这些流水账整理成周报，再列出下周优先级。
3. 信息不完整：这周主要在做支付功能，帮我复盘一下。

这三句话分别测试：点名后能不能正确执行、没点名时能不能自动触发、信息不足时会不会乱编。

触发案例不是宣传文案，而是 Skill 的入口测试。

---

第 3 步：决定 Skill 里放什么

一份 Skill 最小只需要一个文件：

your-skill/
└── SKILL.md

比较完整的结构是：

your-skill/
├── SKILL.md           ← 必需：触发条件 + 工作流程 + 质量标准
├── agents/
│   └── openai.yaml    ← 推荐：名称、简介、默认提示
├── scripts/           ← 放需要稳定执行的代码
├── references/        ← 放公司规则、术语、API 文档等长资料
└── assets/            ← 放模板、图片、字体等素材

怎么判断要不要增加目录？

• 只有文字流程 → 先写一个 SKILL.md
• 同一段代码每次都要重写 → 放进 scripts/
• 背景资料很长，不是每次都要读 → 放进 references/
• 每次交付都要套相同模板 → 放进 assets/

先做最小可用版本，用到什么再增加什么。不要为了显得专业，先建立一堆空目录。

---

第 4 步：让 AI 初始化 Skill

Skill 名称只能使用：小写英文字母、数字、连字符。不要用空格和中文。

新手最简单的做法，是把前面完成的工作流卡片发给 AI 的 skill-creator：

请使用 skill-creator，把下面的工作流做成一个 Skill。

Skill 名称：weekly-review

工作流：
[粘贴你的工作流卡片]

要求：
1. 先创建在当前项目中；
2. 只创建真正需要的文件；
3. 完成后验证 Skill；
4. 告诉我如何测试和安装。

skill-creator 会生成符合结构要求的文件夹。看到 SKILL.md 和 agents/openai.yaml，说明初始化完成。

---

第 5 步：写好 SKILL.md

SKILL.md 分为两部分：YAML 头部和 Markdown 正文。

YAML 头部 — 决定「什么时候触发」

---
name: weekly-review
description: 将一周的零散记录整理成结构化复盘和下周行动计划。用户提到周报、每周复盘、一周总结、工作回顾、学习复盘，或要求从流水账中提炼成果、问题、经验和下一步行动时使用。
---

description 最重要——AI 会先读取 name 和 description 判断是否触发，然后才会读取正文。所以触发方式和场景要写在 description 中，不要藏在正文最后。

正文 — 决定「触发后怎么做」

正文是给 AI 实例看的执行说明，不需要介绍 Skill 有多厉害。通用结构如下：

## 工作流程
1. 收集并检查输入
2. 按固定规则处理
3. 生成结果
4. 检查结果

## 信息不足或异常时
- 缺少重要信息时怎么处理
- 哪些内容不能猜测
- 什么时候应该停止并询问用户

## 输出格式
[固定栏目、顺序或模板]

## 质量标准
- 必须包含什么
- 不能出现什么
- 怎么判断已经完成

以每周复盘为例，核心流程是：

## 工作流程
1. 提取事实：识别已完成事项、进展、数据、问题和未完成事项。
2. 分类整理：归入本周成果、关键进展、问题与原因、经验与洞察。
3. 提炼重点：合并重复内容，不编造用户没有提供的事实。
4. 制定行动：把未完成事项和问题转成下周行动。
5. 检查输出：行动不超过5个，最高优先级不超过3个。

## 信息不足时
- 缺少日期、数据或负责人时，标记为"待补充"，不要猜测。
- 记录过少时，先输出可确认的内容，再提出最多3个问题。

## 质量标准
- 使用具体动词，避免"持续优化""积极推进"等空话。
- 区分事实与推断。
- 每个行动都要有可以检查的完成标准。

写正文记住三条：只写完成任务必须知道的内容；越容易出错的环节规则越要具体；能用 30 行说清楚就不要写 300 行。

---

第 6 步：验证并安装

写完后，先让 skill-creator 验证结构和格式：

请使用 skill-creator 验证 ./weekly-review。
如果发现格式、命名或 YAML 问题，直接修复后重新验证。

验证器会检查：文件夹名称一致、YAML 格式正确、name 和 description 存在、名称符合规则。

通过后安装到 Skill 目录（以 Codex 为例）：

cp -R ./weekly-review ~/.codex/skills/

也可以直接告诉 AI：「请把 ./weekly-review 安装到我的 Skills 目录」。

---

第 7 步：拿真实工作测试

结构校验通过只证明文件格式正确，不证明工作流好用。 回到你准备的那三个案例，逐一测试：

测试场景	输入	检查重点
明确点名	$weekly-review 整理这周记录	是否按 Skill 规定的栏目和顺序输出
不点名	把流水账整理成周报，列出优先级	description 是否足够清楚，能被自动识别
信息不完整	这周主要在做支付功能，帮我复盘	是否标记”待补充”而非虚构日期、数据和负责人

如果结果不理想，先判断问题出在哪里：

• 没有自动触发 → 改 description
• 执行顺序不稳定 → 改工作流程
• 总是出现空话 → 增加质量标准
• 信息不足时乱编 → 增加异常处理规则
• 同一段代码反复生成 → 放进 scripts/
• SKILL.md 越写越长 → 把长资料放进 references/

测试的目的不是证明第一版正确，而是找到下一次应该改哪里。

---

第 8 步：上传到 GitHub

Skill 在本地跑通后再上传。GitHub 能帮你：备份工作流、记录每次修改、多设备同步、分享给团队、出问题时回退。

先在 GitHub 创建一个空仓库（如有敏感信息选 Private），然后：

git init -b main
git add .
git commit -m "feat: add my first Codex skill"
git remote add origin <你的仓库地址>
git push -u origin main

上传前务必检查：

git status
git diff --cached

确认没有 API Key、Token、密码、客户数据、公司内部地址等敏感信息。

以后每次修改只需要：

git add .
git commit -m "docs: improve skill workflow"
git push

---

新手最容易踩的 5 个坑

1. 把聊天记录直接塞进 SKILL.md

聊天记录不是工作流。先提炼触发条件、步骤、异常处理和验收标准。

2. 一个 Skill 想解决所有问题

范围越大，自动触发和输出越不稳定。先从一个明确输入、一个明确输出开始。

3. 只有步骤，没有完成标准

「生成报告」不是验收标准。「包含 5 个固定栏目，每个行动有优先级和完成标准」才是。

4. 验证通过就认为已经完成

验证器只能检查结构。真正的质量必须用正常、模糊和缺失信息三类任务测试。

5. 把敏感信息上传到公开仓库

GitHub 的 Public 代表任何人都可能看到。不确定时先使用 Private。

---

你今天就能做的第一步

打开你的聊天记录，找出最近一个月里，你向 AI 重复解释过两次以上的任务。

不要先写代码。直接填好「工作流卡片」的六行：什么时候启动、用户提供什么、执行步骤、最后输出什么、什么结果算合格、信息不足时怎么办。

然后交给 skill-creator，生成第一版 Skill。

第一版不需要完美。先让它在一个真实任务中跑起来，再根据结果修改。

沉淀 Skill 的核心只有一句话：把「我每次都要重新解释」，变成「它以后知道该怎么做」。

---

本文参考了 Adrian Punk（@AdrianPunk115）的 X 长文「如何把一套工作流沉淀成自己的 Codex Skill：从 0 到上传 GitHub」，结合实操经验整理。