什么工作流值得做成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

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

周报或每周复盘

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

发布前检查

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

会议记录整理

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

固定格式的内容转换

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

文档或表格的预处理

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

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

只发生一次的任务

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

一句话就能说清的操作

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

没有边界的全能助手

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

更好的第一个版本是：

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

而不是：

帮我完成所有内容工作

过度依赖临场创意的任务

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

五、先写一张工作流卡片

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

工作流名称：

什么时候启动：

用户会提供什么：

执行步骤：
1.
2.
3.

最终输出：

什么结果算合格：

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

以“每周复盘”为例：

工作流名称：每周复盘

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

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

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

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

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

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

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

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

可以从四个维度写：

内容完整

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

事实准确

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

结构稳定

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

风险可控

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

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

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

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

明确点名

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

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

自然表达

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

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

信息不完整

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

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

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

把这段文字翻译成英文。

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

八、从小范围开始迭代

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

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

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

九、一个简单的投入判断

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

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

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

结论

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

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

官方参考：Codex Build skills，用于核对 Skill 的组成、触发描述和渐进式加载方式。