如何把一套工作流沉淀成自己的 Codex Skill：从 0 到上传 GitHub

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

比如每周五，你都会告诉 Codex：

先整理本周成果，再提炼问题和经验，最后列出下周行动。不要编造数据，每个行动都要有完成标准。

第一次这样写，叫提示词。

但如果你每周都这样写，说明背后已经存在一套固定工作流。

把这套工作流整理成一个文件夹，让 Codex 以后遇到类似任务时知道：

• 什么时候应该接手；
• 应该按照什么步骤执行；
• 输出需要达到什么标准。

这就是 Skill。

Skill 的本质，是把你脑子里的做事方法，沉淀成一套可以重复执行的系统。

这篇文章会用“每周复盘”作为例子，带你完成完整流程：

找到工作流 → 拆解工作流 → 创建 Skill → 测试 → 上传 GitHub

你不需要先会编程。

---

一、先理解：Skill 到底是什么？

你可以把 Codex 想象成一个能力很强的新同事。

它会写代码、整理资料、分析数据，但它不知道你的工作习惯：

• 什么情况下启动某项任务；
• 你通常先做什么，再做什么；
• 哪些规则不能违反；
• 什么样的结果才算完成。

Skill 就像你给这个新同事的一份：

岗位说明书 + 标准流程 + 工具资料包

一个 Skill 通常解决四件事：

1. 什么时候使用哪些任务应该触发它。
2. 怎么执行收到任务后按照什么流程处理。
3. 可以调用什么是否需要脚本、模板、参考资料。
4. 什么算完成最终输出必须满足哪些标准。

普通提示词只解决一次任务。

Skill 则是把一类任务固定下来。

提示词告诉 AI：

这次帮我做什么。

Skill 告诉 AI：

以后遇到这类事情，你应该怎么做。

---

二、什么任务值得做成 Skill？

不要看到一个提示词就马上做 Skill。

先问自己四个问题：

• 这件事是否会重复发生？
• 输入和输出是否比较稳定？
• 中间是否有固定步骤？
• 换一个 AI，是否还需要重新解释？

如果有三个答案是“是”，通常就值得沉淀。

适合做 Skill 的任务：

• 每周整理复盘和计划；
• 按固定规则写 X 长文；
• 发布产品前执行检查清单；
• 审核合同中的风险项；
• 按品牌规范回复客服；
• 将会议记录转换成任务列表；
• 批量处理固定格式的数据。

不适合做 Skill：

• 一次性的临时任务；
• 一句话就能描述的问题；
• 完全依赖灵感的创作；
• “帮我处理所有内容”这种没有边界的目标。

很多人第一个 Skill 就想做：

内容运营助手。

这是最容易失败的。

范围越大，触发越模糊，结果越不稳定。

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

---

三、先不要创建文件，先拆解你的工作流

创建 Skill 前，先写一张工作流卡片：

工作流名称：

什么时候启动：

用户会提供什么：

执行步骤：
1.
2.
3.

最后输出什么：

什么结果算合格：

信息不足时怎么办：

例如：

工作流名称：
把一周零散记录整理成复盘

什么时候启动：
用户提出周报、每周复盘、一周总结、工作回顾时

用户会提供什么：
完成事项、问题、数据、下周计划

执行步骤：
1. 提取事实和数据
2. 分类成果、问题、经验
3. 合并重复信息
4. 转换成下周行动
5. 检查是否存在编造

最后输出什么：
结构化周复盘和行动计划

什么结果算合格：
不虚构数据，每个行动都有完成标准

信息不足时怎么办：
标记待补充，最多提出3个问题，不猜测

这一步非常重要。

因为 Skill 的 description、执行流程和质量标准，基本都来自这张卡片。

如果你连这张卡片都写不清楚，说明你的工作流还没有稳定。

不要把混乱包装成 Skill。

先把自己的方法想清楚。

---

四、创建 Skill：从最小版本开始

一个最简单的 Skill，只需要：

weekly-review/
└── SKILL.md

完整一点：

weekly-review/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

每个目录负责不同事情：

• SKILL.md：写触发条件、流程和标准；
• agents/openai.yaml：定义展示信息；
• scripts/：存放重复执行的代码；
• references/：保存背景资料；
• assets/：保存模板和素材。

不要一开始创建一堆空目录。

Skill 会占用上下文。

只保留真正需要的内容。

---

五、让 Codex 帮你生成 Skill

Skill 名称建议使用：

• 小写英文；
• 数字；
• 连字符。

例如：

weekly-review
x-article-writer
release-checker
contract-risk-check

然后让 Codex 使用 skill-creator：

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

Skill 名称：
weekly-review

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

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

生成后：

weekly-review/
├── SKILL.md
└── agents/
    └── openai.yaml

注意：

生成文件只是开始。

真正决定 Skill 好不好用的是 SKILL.md。

---

六、写好 SKILL.md：重点不是介绍，而是规定执行方式

SKILL.md 通常分两部分：

1. YAML 头部：决定什么时候触发

例如：

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

description 很重要。

它必须回答：

两个问题：

• 这个 Skill 做什么？
• 用户什么时候应该使用？

不要只写：

帮助用户复盘

太模糊。

应该写：

当用户需要整理周报、复盘、总结流水账时使用

---

2. Markdown 正文：告诉 AI 怎么执行

推荐结构：

# Skill名称

目标说明

## 工作流程

1. 收集输入
2. 提取事实
3. 分类整理
4. 输出结果

## 信息不足时

- 不允许猜测
- 缺少数据时标记待补充

## 输出格式

固定栏目

## 质量标准

- 必须包含什么
- 禁止出现什么

例如：

## 工作流程

1. 提取事实：识别完成事项、数据、问题。
2. 分类整理：归入成果、问题、经验。
3. 制定行动：转换成下一步任务。
4. 检查输出：避免空话和虚构。

## 质量标准

- 区分事实和推断。
- 每个行动必须有完成标准。
- 避免“持续优化”等无意义表达。

记住：

Skill 不是知识库。

它是一份执行手册。

能30行说清楚，就不要写300行。

---

七、验证、测试，再安装

先验证：

请使用 skill-creator 验证 ./weekly-review。
如果发现格式问题，请直接修复。

验证主要检查：

• 文件结构；
• YAML 格式；
• name 是否存在；
• description 是否存在；
• 命名是否符合规则。

但验证通过，不代表 Skill 好用。

真正测试需要三类案例：

1. 明确调用

请使用 $weekly-review 整理下面的记录。

测试是否正确执行。

2. 自然表达

帮我把这些流水账整理成周报。

测试 description 是否能触发。

3. 信息不足

这周主要做支付功能，帮我复盘一下。

测试是否会乱编。

好的 Skill 不只是完成任务。

它还知道什么时候应该说：

信息不足，需要补充。

---

八、上传 GitHub，让 Skill 成为你的长期资产

Skill 本质上也是代码资产。

上传 GitHub 可以：

• 保存版本；
• 多设备同步；
• 分享给团队；
• 持续优化。

提交前检查：

不要上传：

• API Key；
• Token；
• 密码；
• 客户资料；
• 公司内部规则。

然后：

git init -b main
git add .
git commit -m "feat: add weekly review skill"
git remote add origin <仓库地址>
git push -u origin main

以后修改：

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

---

最后：今天就做第一个 Skill

打开你的聊天记录。

找一个最近一个月里，你已经向 AI 重复解释两次以上的任务。

不要先写代码。

先完成一张工作流卡片：

• 什么时候启动；
• 用户提供什么；
• 执行步骤；
• 输出什么；
• 什么算完成；
• 信息不足怎么办。

然后交给 skill-creator。

第一版不需要完美。

让它先跑起来，再根据真实结果优化。

Skill 的核心只有一句话：

把“我每次都要重新解释”，变成“它以后知道该怎么做”。