如何把一套工作流沉淀成自己的 Codex Skill：从 0 到上传 GitHub
文章目录
如果你每周都要把同一段要求重新发给 AI，这篇文章就是写给你的。
比如每周五，你都要告诉 Codex：
先整理本周成果，再提炼问题和经验，最后列出下周行动。不要编造数据，每个行动都要有完成标准。
一次这样写，叫提示词。
每周都这样写，背后其实已经有了一套固定工作流。
把这套工作流整理成一个文件夹，让 Codex 以后遇到类似任务就知道什么时候接手、按什么步骤执行、结果达到什么标准，这就是 Skill。
Skill 的本质，是把你脑子里的做事方法沉淀成一套可以重复执行的系统。
下面我会用“每周复盘”作为贯穿示范，带你走完这条路线：
找到工作流 → 拆解工作流 → 创建 Skill → 测试 → 上传 GitHub。
你不需要先会编程。
一、先理解：什么是 Skill？
你可以把 Codex 想成一位能力很强、但刚入职的新同事。
它懂写作、代码、表格和分析，但不知道：
-
你在什么情况下会启动某项工作；
-
你习惯先做什么、后做什么；
-
哪些公司规则不能违反；
-
输出必须包含哪些栏目；
-
做到什么程度才算合格。
Skill 就是你交给这位新同事的：
岗位说明书 + 标准作业流程 + 必要工具和资料。
一份 Skill 通常会告诉 Codex 四件事：
-
什么时候使用：哪些任务和说法应该触发它；
-
怎么执行：收到任务后按什么步骤工作；
-
可以用什么：脚本、参考资料或模板放在哪里；
-
什么算完成：最终输出必须满足哪些标准。
普通提示词通常只服务当前对话。
Skill 会保存在固定目录中。之后你可以用 $skill-name 点名，也可以让 Codex 根据任务自动判断是否使用。
提示词解决一次任务，Skill 固化一类任务。
二、什么工作流值得做成 Skill？
不要看到任何提示词都急着做 Skill。
先用下面四个问题筛选：
-
这件事是不是会重复发生？
-
它有没有相对稳定的输入和输出？
-
中间是否存在固定步骤、规则或判断标准？
-
如果换一个 AI，你是不是还要重新解释一遍？
其中三个回答“是”，通常就值得沉淀。
适合做成 Skill 的例子：
-
每周把零散记录整理成复盘和下周计划；
-
每次写 𝕏 长文的提示词技能或者按照同一套标准如何起标题；
-
发布产品前执行固定的检查清单；
-
审核合同时检查相同的风险项；
-
根据品牌规则回复客服消息；
-
把固定格式的会议记录整理成任务清单；
-
重复处理同一类 PDF、表格或接口数据。
不适合的例子：
-
只会发生一次的临时任务；
-
一句话就能说明白的简单操作；
-
完全依赖临场创意、没有稳定步骤的任务；
-
“帮我处理所有内容”这种没有边界的大目标。
这里最容易犯的错误，是一上来就做“全能内容助手”。
范围越大，触发越模糊，执行越不稳定。
“帮我做内容运营”不适合作为第一个 Skill。
“把访谈记录整理成一篇符合固定结构的 𝕏 长文”就清楚得多。
好的 Skill，不是无所不能，而是能把一件具体的事稳定做好。
三、第一步：把脑子里的工作流写到纸面上
先不要急着创建文件。
选一件你最近一个月重复做过至少两次的工作，然后写出下面这张“工作流卡片”：
工作流名称：
什么时候启动：
用户会提供什么：
执行步骤：
1.
2.
3.
最后输出什么：
什么结果算合格：
信息不足或出错时怎么办：
以“每周复盘”为例：
工作流名称：
把一周的零散记录整理成复盘
什么时候启动：
用户提出周报、每周复盘、一周总结或工作回顾时
用户会提供什么：
一周内完成的事情、问题、数据和下周计划
执行步骤：
1. 提取事实和数据
2. 分类为成果、进展、问题和经验
3. 合并重复内容
4. 把未完成事项转成下周行动
5. 检查是否存在编造或空话
最后输出什么：
结构化周复盘和下周行动表
什么结果算合格：
保留原始数据；不虚构；行动有优先级和完成标准
信息不足时怎么办：
标记“待补充”，最多提出 3 个问题，不要猜
这张卡片很重要。
因为 Skill 的 description、工作流程和质量标准，基本都来自这里。
如果你填不完，说明这件事可能还没有形成稳定工作流。
这时先多做几次，记录自己每次如何判断，再回来做 Skill。
不要把混乱包装成 Skill，先把工作流本身想清楚。
四、第二步：准备 3 个真实触发案例
接下来写三句用户可能真的会说的话。
第一句是明确点名：
请使用 $weekly-review 整理这周的记录。
第二句是自然表达：
帮我把这些流水账整理成周报，再列出下周优先级。
第三句是信息不完整的边界情况：
这周主要在做支付功能，帮我复盘一下。
这三句话分别测试：
-
点名后能不能正确执行；
-
没点名时能不能自动触发；
-
信息不足时会不会乱编。
很多人只写“这个 Skill 能做什么”，却没有想过“用户会怎么说”。
结果就是文件写得很长，但 Codex 根本不知道什么时候应该使用。
触发案例不是宣传文案，而是 Skill 的入口测试。
五、第三步：决定 Skill 里要放什么
一份 Skill 最小只需要一个文件：
your-skill/
└── SKILL.md
比较完整的结构是：
your-skill/
├── SKILL.md
├── agents/
│ └── openai.yaml
├── scripts/
├── references/
└── assets/
每个部分解决的问题不同：
-
SKILL.md：必需，写触发条件、工作步骤和质量标准；
-
agents/openai.yaml：推荐，控制界面里的名称、简介和默认提示；
-
scripts/：放需要稳定执行的代码，例如格式转换和数据校验；
-
references/：放公司规则、术语、接口文档等长资料；
-
assets/：放最终交付会用到的模板、图片、字体等素材。
怎么判断要不要增加目录？
-
只有文字流程：先写一个 SKILL.md；
-
同一段代码每次都要重写：放进 scripts/；
-
背景资料很长，不是每次都要读：放进 references/；
-
每次交付都要套相同模板：放进 assets/。
不要为了显得专业，先建立一堆空目录。
Skill 会占用上下文，应该只保留完成任务真正需要的内容。
先做最小可用版本，用到什么再增加什么。
六、第四步：让 Codex 初始化 Skill
Skill 名称只使用：
-
小写英文字母；
-
数字；
-
连字符。
不要使用空格和中文，文件夹名称要和 Skill 名保持一致。
例如：
weekly-review
x-article-writer
check-release
contract-risk-checker
新手最简单的做法，是直接让 Codex 调用自带的 skill-creator。
把前面完成的工作流卡片发给 Codex：
请使用 skill-creator，把下面的工作流做成一个 Skill。
Skill 名称：weekly-review
工作流：
[粘贴你的工作流卡片]
要求：
1. 先创建在当前项目中；
2. 只创建真正需要的文件；
3. 完成后验证 Skill；
4. 告诉我如何测试和安装。
skill-creator 会使用初始化脚本，生成符合结构要求的文件夹。
这次实际生成的是：
weekly-review/
├── SKILL.md
└── agents/
└── openai.yaml
截图要点：在 Codex 中运行 skill-creator 初始化 weekly-review 后的终端，应能看到新建的 SKILL.md 与 agents/openai.yaml 两个文件。
看到 SKILL.md 和 agents/openai.yaml，说明初始化完成。
但这时只是有了空房子，真正决定 Skill 是否好用的，是接下来写进去的内容。
七、第五步：写好 SKILL.md
SKILL.md 分为两部分：
-
YAML 头部；
-
Markdown 正文。
1. YAML 头部决定“什么时候触发”
文件开头必须是：
---
name: weekly-review
description: 将一周的零散记录整理成结构化复盘和下周行动计划。用户提到周报、每周复盘、一周总结、工作回顾、学习复盘，或要求从流水账中提炼成果、问题、经验和下一步行动时使用。
---
这里最重要的是 description。
它必须同时回答两个问题：
-
这个 Skill 能做什么？
-
用户在什么场景下应该使用？
不要只写：
帮助用户复盘。
这句话没有具体场景。
应该把“周报、每周复盘、一周总结、流水账”等真实触发方式写进去。
Codex 会先读取 name 和 description 判断是否触发，然后才会读取正文。
所以“什么时候使用”要写在 description 中，不要藏在正文最后。
2. 正文决定“触发后怎么做”
正文不需要介绍 Skill 有多厉害。
它是给另一个 Codex 实例看的执行说明。
可以使用这套通用结构：
# Skill 名称
用一句话说明目标。
## 工作流程
1. 收集并检查输入
2. 按固定规则处理
3. 生成结果
4. 检查结果
## 信息不足或异常时
- 缺少重要信息时怎么处理
- 哪些内容不能猜测
- 什么时候应该停止并询问用户
## 输出格式
[固定栏目、顺序或模板]
## 质量标准
- 必须包含什么
- 不能出现什么
- 怎么判断已经完成
这次的每周复盘 Skill，核心流程是：
## 工作流程
1. 提取事实：识别已完成事项、进展、数据、问题和未完成事项。
2. 分类整理：归入本周成果、关键进展、问题与原因、经验与洞察。
3. 提炼重点：合并重复内容，不编造用户没有提供的事实。
4. 制定行动：把未完成事项和问题转成下周行动。
5. 检查输出：行动不超过 5 个，最高优先级不超过 3 个。
## 信息不足时
- 缺少日期、数据或负责人时，标记为“待补充”，不要猜测。
- 记录过少时，先输出可确认的内容，再提出最多 3 个问题。
## 质量标准
- 使用具体动词，避免“持续优化”“积极推进”等空话。
- 区分事实与推断。
- 每个行动都要有可以检查的完成标准。
截图要点：终端里查看 SKILL.md 的内容，展示 YAML 头部（name / description）与「工作流程」「质量标准」等正文。
写正文时记住三条：
-
只写完成任务必须知道的内容；
-
越容易出错的环节，规则越要具体；
-
能用 30 行说清楚，就不要写 300 行。
Skill 不是知识百科，而是执行手册。
八、第六步：验证并安装
写完后，不要直接宣布完成。
先让 skill-creator 验证：
请使用 skill-creator 验证 ./weekly-review。
如果发现格式、命名或 YAML 问题，直接修复后重新验证。
验证器会检查：
-
文件夹名称和 Skill 名称是否一致；
-
YAML 格式是否正确；
-
name 和 description 是否存在；
-
名称是否符合规则。
成功时会看到类似 Skill is valid! 的通过提示（具体文案以你本地 skill-creator 版本为准）。
然后把整个 Skill 文件夹安装到 Codex 的 Skill 目录。
默认通常是：
~/.codex/skills/
Codex 不同版本/文档里也出现过 .agents/skills 的写法，本质一样，选一个保持前后一致即可；本文沿用 .codex/skills/。
macOS 或 Linux 可以执行：
cp -R ./weekly-review ~/.codex/skills/
也可以直接告诉 Codex：
请把 ./weekly-review 安装到我的 Codex Skills 目录。
截图要点：skill-creator 验证通过的终端输出，以及 ~/.codex/skills/weekly-review 安装后的目录结构。
如果安装后没有立刻出现，新开一个 Codex 任务；仍然没有，再重启 Codex。
结构校验通过，只能证明文件格式正确。
它还不能证明这套工作流真的好用。
九、第七步：拿真实工作测试
回到前面准备的三个案例，逐个测试。
测试 1：明确点名
请使用 $weekly-review 整理下面的记录。
检查是否按照 Skill 规定的栏目和顺序输出。
测试 2：不点名
把这些流水账整理成周报，再列出下周优先级。
检查 description 是否足够清楚，能让 Codex 自动识别。
测试 3：信息不完整
这周主要在做支付功能，帮我复盘一下。
检查它是否明确标记缺失信息，而不是虚构日期、数据和负责人。
我实际测试时，输入了首页上线、支付联调故障、证书过期、页面修复和下周 A/B 测试等零散记录。
Skill 自动整理出了：
-
本周成果；
-
关键进展；
-
问题与原因；
-
经验与洞察；
-
带优先级和完成标准的下周行动；
-
需要补充的信息。
截图要点：输入零散记录后，weekly-review 自动整理出的「本周成果 / 关键进展 / 问题与原因 / 经验与洞察 / 下周行动」输出。
如果结果不理想，不要马上推翻整个 Skill。
先判断问题发生在哪里：
-
没有自动触发：改 description；
-
执行顺序不稳定：改工作流程；
-
总是出现空话：增加质量标准；
-
信息不足时乱编：增加异常处理规则；
-
同一段代码反复生成：把它放进 scripts/；
-
SKILL.md 越写越长：把长资料放进 references/。
测试的目的不是证明第一版正确，而是找到下一次应该改哪里。
十、第八步：上传到 GitHub
Skill 在本地跑通后，再上传 GitHub。
GitHub 能帮你：
-
备份自己的工作流；
-
记录每次修改；
-
在多台设备之间同步；
-
分享给团队或粉丝；
-
出问题时回到旧版本。
先在 GitHub 创建一个空仓库。
如果 Skill 包含公司流程、客户案例或内部规则，选择 Private。
公开之前，检查并删除：
-
API Key；
-
Token；
-
密码和账号；
-
客户数据；
-
公司内部地址；
-
未公开的业务规则。
然后在本地项目目录执行：
git init -b main # 需要 Git ≥ 2.28；老版本用 git init && git branch -m main
git add .
git commit -m "feat: add my first Codex skill"
git remote add origin <你的仓库地址>
git push -u origin main
以后每次修改，只需要：
git add .
git commit -m "docs: improve skill workflow"
git push
上传前可以用：
git status
git diff --cached
确认即将提交的文件中没有敏感信息。
截图要点：Skill 已 push 到私有 GitHub 仓库的页面，能看到仓库内的 SKILL.md、agents/ 等文件。
到这一步，你完成的已经不只是一段提示词。
你拥有了一套可以安装、测试、修改、同步和分享的个人工作流。
十一、新手最容易踩的 5 个坑
1. 把聊天记录直接塞进 SKILL.md
聊天记录不是工作流。
先提炼触发条件、步骤、异常处理和验收标准。
2. 一个 Skill 想解决所有问题
范围越大，自动触发和输出越不稳定。
先从一个明确输入、一个明确输出开始。
3. 只有步骤，没有完成标准
“生成报告”不是验收标准。
“包含 5 个固定栏目，每个行动有优先级和完成标准”才是。
4. 验证通过就认为已经完成
验证器只能检查结构。
真正的质量必须用正常、模糊和缺失信息三类任务测试。
5. 把敏感信息上传到公开仓库
GitHub 的 Public 代表任何人都可能看到。
不确定时先使用 Private。
十二、你今天就能做的第一步
打开你的聊天记录，找出最近一个月里，你向 AI 重复解释过两次以上的任务。
不要先写代码。
直接填好第三节那张「工作流卡片」（六行：什么时候启动、用户提供什么、执行步骤、最终输出、什么结果算合格、信息不足时怎么办）。
然后把它交给 skill-creator，生成第一版 Skill。
第一版不需要完美。
先让它在一个真实任务中跑起来，再根据结果修改。
沉淀 Skill 的核心只有一句话：把“我每次都要重新解释”，变成“它以后知道该怎么做”。
关于作者
Punk｜中科大 MBA｜HerName 首席设计师｜Stanley 商学院执行院长｜
｜AI提示词｜3个月赚了8位数｜Learn in Public｜@AdrianPunk115
沿着这个主题继续读
从一篇文章，找到相关的教程、经验和阅读路径。
