Docs

---
title: "什么工作流值得做成 Codex Skill：先从重复任务开始"
tags:
  - Codex Skill
  - AI 工作流
  - 自动化
description: "从重复频率、输入输出和验收标准三个角度筛选工作流，判断哪些任务适合沉淀成可复用的 Codex Skill。"
---
# 什么工作流值得做成 Codex Skill：先从重复任务开始

如果你每周都要把同一段要求重新发给 AI，问题可能不在提示词写得不够长，而在于你已经有了一套重复工作流，却还没有把它保存成可复用的能力。

例如，每周五你都会要求 AI 整理本周成果、提炼问题、记录经验，再列出下周行动。一次这样写，是提示词；每周都这样写，而且步骤、栏目和完成标准基本不变，这就已经接近一个 Skill。

Skill 的价值不是把一段提示词换个文件名，而是把一个人的做事方法拆成触发条件、输入、步骤、输出、异常处理和验收标准。这样，之后的 AI 实例不需要重新猜你的工作方式，团队成员也能看到这套流程到底怎样运行。

本文只解决一个问题：**哪些工作流值得做成 Codex Skill，以及在创建之前应该先完成什么设计。**文章不假设你会写代码，也不要求一开始就搭建插件或复杂自动化系统。

## 一、先区分提示词、工作流和 Skill

这三个概念经常被混在一起。

### 提示词解决一次任务

提示词通常包含当前任务的背景、要求和输出格式。它适合一次性问题，例如“帮我把这封邮件改得更简洁”。任务完成后，提示词本身不一定需要长期维护。

### 工作流描述重复的做事顺序

工作流关注的是过程：先收集什么，再判断什么，什么时候需要人工确认，最后怎样验收。它可以由人手动执行，也可以由脚本和 AI 共同执行。

### Skill 把工作流包装成可触发的能力

一个 Skill 通常由名称、描述和执行说明组成，也可以附带脚本、参考资料、模板和资源文件。Codex 先读取 Skill 的元数据，再在任务匹配时加载完整说明，这种渐进式加载可以减少无关上下文。

官方手册把 Skill 定义为可复用的任务工作流目录，要求其中包含 `SKILL.md`，并允许使用 `scripts/`、`references/` 和其他资源。具体能力和加载位置会随 Codex 表面与版本变化，实际使用时应以当前手册为准。

## 二、四个问题筛选一个工作流

不要看到任何提示词都立刻做成 Skill。先回答以下四个问题。

### 1. 它是否会重复发生

重复不一定意味着每天都做。每周、每月，甚至每次发布前都会发生的任务，都可能值得沉淀。

一次性的临时任务通常只需要保留结果；重复任务才值得承担 Skill 的命名、测试和维护成本。

### 2. 输入是否相对稳定

输入不要求完全相同，但至少应能描述清楚来源和格式。例如：

- 一组会议记录 Markdown 文件；
- 一周内的工作日志；
- 一个发布前待检查的目录；
- 一份固定字段的 CSV 表格；
- 一套有明确栏目要求的内容草稿。

如果每次输入都完全不同，Skill 很难判断应该读取什么，也很难定义异常情况。

### 3. 输出是否可以描述

“帮我把事情处理好”不是可执行的输出定义。“生成包含成果、问题、经验和行动四个栏目的一份 Markdown 复盘”就清楚得多。

输出越具体，越容易编写模板、测试案例和验收脚本。

### 4. 是否存在稳定规则

一个值得沉淀的工作流，通常包含至少一个稳定规则：字段必须保留、步骤不能跳过、某类风险必须确认、未知信息不能猜测，或者输出必须通过某种检查。

如果任务完全依赖临场创意，没有可以复用的判断方式，暂时不要急着做 Skill。先多做几次，记录自己每次如何判断，等规律形成后再抽象。

可以用这张表快速筛选：

| 问题 | 是 | 否 |
| --- | --- | --- |
| 最近一个月是否重复做过至少两次？ | 进入下一项 | 先保留为普通提示词 |
| 输入来源和格式是否能说明？ | 进入下一项 | 先整理输入 |
| 输出栏目和完成标准是否清楚？ | 进入下一项 | 先定义结果 |
| 是否有固定步骤或规则？ | 适合做 Skill | 继续观察工作流 |

## 三、哪些任务适合做成第一个 Skill

新手应该选择边界清楚、反馈周期短的任务。下面几类通常比较合适。

### 周报或每周复盘

输入是零散记录，输出是固定栏目。质量标准也容易描述：不编造数据，保留原始事实，行动有优先级和完成标准。

### 发布前检查

输入是文章、代码或资源目录，输出是检查结果和问题列表。检查项可以逐步从文字规则扩展到脚本验证。

### 会议记录整理

输入是会议记录，输出是决定、待办和未决问题。无法识别负责人或截止时间时，可以明确写成“待确认”。

### 固定格式的内容转换

例如把一份长文转换为摘要、标题候选和结构化大纲。只要目标格式稳定，就能通过模板和示例降低偏差。

### 文档或表格的预处理

例如检查字段完整性、统一日期格式、生成待处理清单。确定性部分优先由脚本完成，AI 只处理需要理解的内容。

## 四、哪些任务不适合一开始就做成 Skill

### 只发生一次的任务

一次性的旅行计划、临时邮件或单次头脑风暴，不必为了“可复用”强行抽象。保存成普通提示词或结果就够了。

### 一句话就能说清的操作

如果任务没有固定背景、步骤和验收，做成 Skill 只会增加入口和维护负担。

### 没有边界的全能助手

“帮我做内容运营”“处理所有客户问题”“管理我的全部工作”都太宽。范围越大，触发条件越模糊，输出越难验收。

更好的第一个版本是：

```text
把访谈记录整理成固定结构的文章大纲
```

而不是：

```text
帮我完成所有内容工作
```

### 过度依赖临场创意的任务

创意任务也可以有 Skill，但第一版应沉淀资料准备、结构检查和交付格式，而不是试图把创意本身完全标准化。

## 五、先写一张工作流卡片

创建目录之前，先用一张卡片描述任务。卡片写不清楚，说明工作流本身还没有稳定。

```text
工作流名称：

什么时候启动：

用户会提供什么：

执行步骤：
1.
2.
3.

最终输出：

什么结果算合格：

信息不足或出错时怎么办：
```

以“每周复盘”为例：

```text
工作流名称：每周复盘

什么时候启动：
用户提出周报、每周总结、工作回顾，或要求从流水账中提炼成果和下一步。

用户会提供什么：
一周内完成的事情、问题、数据、反馈和下周计划。

执行步骤：
1. 提取事实、数据、完成事项和未完成事项。
2. 分类为成果、进展、问题、原因和经验。
3. 合并重复内容，保留关键证据。
4. 把未完成事项转成下周行动。
5. 检查是否存在编造、空话或没有完成标准的行动。

最终输出：
结构化周复盘和下周行动表。

什么结果算合格：
保留原始事实；不虚构缺失数据；行动有优先级、负责人或待补充标记，以及可检查的完成标准。

信息不足或出错时怎么办：
先输出可确认内容；缺少重要信息时标记“待补充”；最多提出三个问题；不要猜测。
```

## 六、把“完成”写成可检查的标准

很多工作流失败，不是步骤不够，而是最后一句只有“生成结果”。完成标准需要让另一个人能够判断通过还是不通过。

可以从四个维度写：

### 内容完整

必需栏目是否都出现，关键字段是否有值或明确标记缺失。

### 事实准确

是否保留来源，是否把推断和原始事实区分开，是否存在模型自行补全的数字。

### 结构稳定

标题、顺序、字段和文件命名是否符合约定，是否方便后续程序读取。

### 风险可控

哪些操作只生成草稿，哪些操作必须确认，失败时是否保留原始输入和中间结果。

例如，“写一份报告”不是验收标准；“包含五个固定栏目、每个结论有证据、每个行动有完成标准、缺失字段标为待补充”才接近可执行标准。

## 七、准备三个真实触发案例

Skill 的描述最终要面对真实语言，而不是面对作者想象中的命令。至少准备三类输入：

### 明确点名

```text
请使用 $weekly-review 整理这一周的工作记录。
```

验证用户直接调用时是否进入正确流程。

### 自然表达

```text
把这些流水账整理成周报，再列出下周优先级。
```

验证 Skill 的描述是否足够清楚，能否被隐式匹配。

### 信息不完整

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

验证 Skill 是否会标记缺失信息，而不是编造日期、数据和负责人。

再增加一个不应触发的案例：

```text
把这段文字翻译成英文。
```

如果一个周报 Skill 在这个请求上频繁触发，说明 description 的范围写得太宽。

## 八、从小范围开始迭代

第一版 Skill 不需要覆盖所有例外。先让它在一个真实任务中跑通，再根据失败原因修改：

```text
没有自动触发 -> 补充真实触发词和场景
执行顺序不稳定 -> 把步骤写成编号清单
输出经常空泛 -> 增加反例和质量标准
信息不足时乱编 -> 增加停止条件和待确认格式
代码每次重写 -> 将确定性部分移到 scripts/
SKILL.md 变得过长 -> 将长资料移到 references/
```

Skill 的第一版不是终稿，而是一个可以被测试和修改的工作流版本。每次改动都应该能回答：哪个真实问题促使我改了这条规则？改完后用什么案例验证？

## 九、一个简单的投入判断

维护 Skill 需要命名、整理、测试和后续更新。可以用一个很粗的估算判断是否值得：

```text
每次重复任务节省的时间 × 预计使用次数
是否明显大于
首次整理时间 + 后续维护时间
```

这不是精确的 ROI 计算，只是帮助你避免为极少发生的小任务搭建复杂系统。真正的收益还包括减少重复解释、降低遗漏和让工作方式可以被迁移。

## 结论

适合做成 Codex Skill 的，不是“听起来很厉害”的任务，而是重复出现、输入相对稳定、输出可描述、步骤能够复用的任务。

先写工作流卡片，再准备明确、自然、信息不足和不应触发四类案例。等触发条件、执行步骤、输出格式和完成标准都说清楚之后，再创建 `SKILL.md`。一个范围小但验收清楚的 Skill，通常比一个什么都想做的全能 Skill 更容易稳定运行。

官方参考：[Codex Build skills](https://learn.chatgpt.com/docs/build-skills)，用于核对 Skill 的组成、触发描述和渐进式加载方式。