把重复任务封装成 Codex Skill：从结构到可复用工作流
本篇从真实任务出发，解释一个 Skill 需要解决哪些边界问题，以及如何把“能跑一次”变成“可以稳定复用”。
经验：先写清楚输入、输出和失败条件，再考虑提示词长度。结构清楚比堆叠指令更重要。
为什么要把任务做成 Skill
当一个任务需要重复执行，真正消耗时间的往往不是点击，而是每次重新说明上下文、确认输出格式和补救失败步骤。Skill 的价值在于把这些隐含判断固定下来。
- 明确任务适用范围，不把所有场景塞进同一个 Skill；
- 把必要输入变成可检查的字段；
- 为关键阶段设置可观察的检查点；
- 失败时能够告诉使用者下一步该怎么做。
一个可用 Skill 的基本结构
YAML · skill.yaml
name: content-audit
version: 1.0.0
inputs:
source_path:
type: string
required: true
steps:
- inspect_source
- extract_claims
- verify_output
output:
format: markdown先写清楚输入，而不是急着写步骤
输入应当能够被校验。路径、文件类型、目标平台和输出长度都应该有明确边界。这样才能在任务开始前发现问题，而不是执行到一半才失败。
用检查点替代模糊的“认真完成”
例如，在发布内容前，要求检查是否存在未经来源支持的数据、是否泄露隐私、链接是否有效。检查项越具体，结果越稳定。
注意：原型中的外部仓库链接仅为占位，不会自动访问网络。真实上线后应在新窗口打开并显示外部链接标识。
示例仓库：skill-starter
skill-starter
用于理解 Skill 文件结构、参数声明和本地测试流程的最小示例。适合刚开始搭建自定义 Skill 的课程学员。
发布前检查清单
- 输入字段是否都能验证；
- 失败条件是否可被用户理解；
- 输出是否有固定结构；
- 是否在真实样本上测试过；
- 是否写明权限、成本和数据边界。