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

如何把脑子里重复的做事方法，沉淀成一套 AI 可以稳定执行的 Skill 系统——从识别工作流、拆解步骤、编写 SKILL.md、三案例测试到上传 GitHub 的完整实操路线。

一句话总结

提示词解决一次任务，Skill 固化一类任务。本文带你从零开始，把重复无数次的AI对话沉淀成一套可安装、可测试、可分享的个人工作流。
如果你每周都要把同一段要求重新发给AI，这篇文章就是写给你的。

举个例子：每周五你都要告诉AI：「先整理本周成果，再提炼问题和经验，最后列出下周行动。不要编造数据，每个行动都要有完成标准。」 单次使用叫提示词；每周重复使用，背后已经是一套固定工作流。

把这套工作流整理成文件夹，让AI遇到同类任务就知道何时接手、按什么步骤执行、输出达到什么标准，这就是 Skill。

什么是 Skill？

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

• 在什么场景启动某项工作
• 你的执行先后习惯
• 哪些规则绝对不能违反
• 输出必须包含哪些栏目
• 做到什么程度才算合格

Skill = 岗位说明书 + 标准作业流程 + 必要工具与资料

一份Skill会告诉AI4件核心信息：

1. 什么时候使用：哪些任务、哪些话术会触发该Skill
2. 怎么执行：收到任务后的完整工作步骤
3. 可以用什么：脚本、参考文档、模板素材存放位置
4. 什么算完成：输出必须满足的验收标准

普通提示词仅服务当前对话；Skill保存在本地固定目录，可以通过 $skill‑name 手动调用，也可以让AI自动识别场景触发。

什么工作流值得做成 Skill？

不要拿到提示词就急于封装Skill，用4个问题筛选：

1. 这件事是否会重复发生？
2. 是否拥有相对稳定的输入输出？
3. 是否存在固定步骤、规则、判断标准？
4. 如果更换AI，是否需要重新解释一遍？

4个问题中3个回答「是」，就值得沉淀为Skill。

✅ 适合做Skill的场景 每周复盘、长文写作、发布检查清单、合同风险审核、固定格式客服回复、同类表格批量处理。

❌ 不适合做Skill的场景 一次性临时任务、一句话即可说明的操作、强临场创意任务、边界模糊的大目标（例如：帮我处理全部内容）。

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

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

先不要创建任何文件。挑选近一个月重复至少2次的工作，填写工作流卡片。

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

示例：每周复盘工作流卡片

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

卡片是Skill的源头。如果填不完，说明还没有稳定工作流，先多实操几次，再回来制作Skill。

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

很多人只写Skill能力描述，忽略用户真实表达方式，导致AI无法识别触发时机。准备3类用户话术，作为Skill的入口测试用例：

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

三类案例分别验证：点名调用、自动识别触发、信息不全时不会虚构编造。触发案例是测试用例，不是宣传文案。

第3步：决定 Skill 里放什么

最小可用Skill，只需要单个文件：

your‑skill/
└── SKILL.md

完整Skill目录结构：

your‑skill/
├── SKILL.md          # 必需：触发条件、工作流程、质量标准
├── agents/
│   └── openai.yaml   # 推荐：Skill名称、简介、默认提示
├── scripts/          # 存放稳定复用代码脚本
├── references/       # 存放规则、术语、API文档等长参考资料
└── assets/           # 存放输出模板、图片、字体素材

目录取舍原则：

• 只有文字流程 → 仅保留SKILL.md
• 反复重写的代码 → 放入scripts/
• 大段背景文档 → 放入references/
• 固定交付模板 → 放入assets/

优先做最小可用版本，需要什么再新增，不要提前创建一堆空文件夹。

第4步：让 AI 初始化 Skill

Skill命名规则：仅小写英文字母、数字、连字符，禁止中文、空格。

新手直接把上面的工作流卡片交给 skill‑creator：

请使用 skill‑creator，把下面的工作流做成一个 Skill。
Skill 名称：weekly‑review
工作流： [粘贴你的工作流卡片]
要求：
1. 先创建在当前项目中；
2. 只创建真正需要的文件；
3. 完成后验证 Skill；
4. 告诉我如何测试和安装。

生成后看到 SKILL.md + agents/openai.yaml，代表初始化完成。

第5步：写好 SKILL.md

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

YAML头部：控制什么时候触发

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

description 是核心！AI优先读取name和description判断是否触发，触发场景写在这里，不要藏在正文末尾。

Markdown正文：定义触发后如何执行

正文写给AI阅读，不需要吹嘘Skill能力，通用模板：

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

## 信息不足或异常时
- 缺少重要信息时怎么处理
- 哪些内容绝对不能猜测
- 什么时候停止执行并向用户提问

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

## 质量标准
‑ 输出必须包含什么
‑ 输出禁止出现什么
‑ 任务完成的判断依据

每周复盘示例正文：

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

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

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

撰写正文三条原则：

1. 只写任务必须的信息；
2. 越容易出错的环节，规则写得越具体；
3. 30行讲清楚，绝不写300行。

第6步：验证并安装

调用skill‑creator校验格式：

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

校验项：文件夹名称匹配、YAML语法合法、name与description字段存在、命名符合规范。

校验通过后安装到Codex的Skill目录：

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

也可以直接指令AI：请把 ./weekly‑review 安装到我的 Skills 目录。

第7步：拿真实工作测试

⚠️ 格式校验通过只代表文件合法，不等于工作流可用。

使用前面准备的3个案例逐项测试：

测试场景	输入	检查重点
明确点名调用	$weekly‑review 整理这周记录	是否严格按照Skill规定栏目、顺序输出
无点名自动触发	把流水账整理成周报，列出优先级	description描述是否足够清晰，能否自动识别
信息残缺输入	这周主要在做支付功能，帮我复盘	是否标记待补充，而不是虚构数据

问题定位：

• 不会自动触发 → 修改description
• 执行步骤混乱不稳定 → 修改工作流程
• 输出大量空话 → 补充质量标准
• 信息缺失时AI编造内容 → 完善异常处理规则
• 反复生成相同代码 → 迁移至scripts/
• SKILL.md文件过于臃肿 → 长资料迁移到references/

测试目的不是证明第一版完美，而是找到待修改点。

第8步：上传到 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. 敏感信息上传公开仓库 Public公开仓库任何人都可以访问，不确定安全性就使用Private私有仓库。

你今天就能做的第一步

打开AI聊天记录，找到近一个月你重复解释2次以上的任务。

不要写代码，先填写工作流卡片：

什么时候启动、用户提供什么、执行步骤、输出产物、合格标准、信息不足如何处理。

将卡片交给skill‑creator生成第一版Skill。第一版不需要完美，先跑通真实任务，再迭代优化。

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

SKILL模板

---
name: replace-with-skill-name 
description: 在这里写清楚触发条件与能力描述，AI依靠这段文字判断什么时候启用本Skill。列出用户常见提问、关键词、适用场景。
---

# {{skill-name}} Skill

## 目标
一句话说明这个Skill要解决什么问题。

## 触发判定
当用户出现以下情况时启用：
- 关键词：xxx、xxx、xxx
- 用户诉求：xxx
- 禁止触发场景：xxx

## 输入要求
用户会提供的内容：
1.
2.

> 如果缺少核心输入，不要编造，最多提出3个问题进行确认，标记待补充项。

## 执行流程
1. 接收输入，校验信息完整性，识别已知事实，区分猜测和事实。
2. 按照固定规则处理内容。
3. 组织输出内容，遵循指定格式。
4. 自检输出，对照质量标准检查。

## 输出格式

## 质量标准
 必须包含：
-
禁止出现：
- 禁止编造不存在的数据、事实
- 禁止空话套话，内容可落地可核验

## 异常与边界处理
1. 信息不足：标记【待补充】，不自行脑补
2. 输入超出范围：直接告知用户本Skill不支持该场景
3. 冲突条件：优先遵循硬性规则

## 完成判定
满足全部质量标准、格式正确，即为任务完成。

使用说明

1. 修改 yaml 头部 name，只用小写字母、数字、连字符，不要中文空格
2. description 非常关键，写清楚什么时候自动触发
3. 把流程、输出模板、质量标准替换成你的业务逻辑
4. 保存为 SKILL.md，放在 skill 文件夹内即可