Codex创建Skill怎么做：先选重复任务，再固化材料和验收

不是每个提示词都值得做成Skill

适合每周或每天重复同一类工作，已经有稳定步骤，希望Codex下次直接按流程执行的人。

如果没有真实材料、说不清结果要用在哪里，或准备把输出不经检查直接提交，先不要扩大任务。补齐最小输入，再从一份样本开始。

Skill可能带着Codex读取文件、运行脚本或修改内容，所以权限边界也要成为流程的一部分。默认从副本和最小权限开始，不把高风险操作藏在自动步骤里。

先准备两次真实任务记录

• 至少两次真实任务记录
• 稳定步骤与常见异常
• 输入、输出和验收样例
• 建立一个测试副本或新目录，不直接操作唯一原件。
• 写下一句验收标准：Skill能在一份新样本上按相同步骤交付，缺材料时会暂停，结果可用明确清单验收

两次任务记录要保留当时的输入、输出和失败点，不能只留最终成品。样例里若含个人路径、账号或临时文件名，先抽象成参数。

把说明、脚本和样例分开

先对比两次真实执行记录

把两次任务的输入、步骤、异常和验收结果并排看。只有两次都出现的部分，才可能是稳定流程；只在一次任务中出现的要求先不要写死。

先定义Skill什么时候该被触发

优先选频率高、判断规则稳定、结果能检查的任务，不从“帮我运营全部业务”开始。

用一句话写清任务类型、必要输入和预期输出，再补一条“什么情况不要使用”。触发范围越模糊，Skill越容易被错误调用。

把判断规则、机械步骤和样例分开放

把执行规则写在入口说明，可重复机械步骤放脚本，合格输出放样例。

需要理解语境的规则留在说明文件，稳定且可重复的操作交给脚本，样例只展示合格输入输出。这样修改一处不会牵动全部内容。

换一份没参与设计的新材料测试

不要只用创建时的原案例测试，换一份结构相近但内容不同的输入。

新样本要结构相近但内容不同，最好由另一位使用者发起。记录Skill是否正确触发、是否索要缺失材料，以及输出能否按原标准验收。

把失败条件写成明确的停止点

说明何时使用、何时不用、缺什么材料应暂停，并根据失败迭代。

缺少关键文件、需要不可逆操作或无法判断结果时，Skill应该暂停并说明缺什么，而不是靠猜测继续。把测试中出现的失败逐条补进边界。

给版本号，并保留一份回归样例

发布前固定一个已知合格样例和验收清单。以后修改说明或脚本时重新跑它，确认旧能力没有悄悄失效。

用一个新样本测试Skill

“每周从工作记录生成证据化周报”适合做Skill，因为输入、栏目和验收稳定；“帮我成为优秀产品经理”没有清晰输出，不适合作为第一个Skill。

可以先这样描述任务：

我正在处理“从一个已跑通的重复任务提炼首个可维护Codex Skill”。已有材料包括至少两次真实任务记录、稳定步骤与常见异常、输入、输出和验收样例。请先不要扩大任务范围，也不要补造缺失信息。先完成“选择边界清楚的任务”，输出可以人工检查的中间结果；我确认后，再继续“分离说明、脚本和样例”。最终请按照“Skill能在一份新样本上按相同步骤交付，缺材料时会暂停，结果可用明确清单验收”列出验收结果和仍需人工确认的内容。

判断示例是否成立时，不看字数和语气，重点看另一位同事能否沿着文件、页码、表格或命令输出复查。

只在原项目能用，问题通常在哪

Skill只有在原项目里能用

检查是否把绝对路径、个人账号、临时文件名或未说明依赖写死；改成参数、相对路径和明确前置条件。

Skill遇到缺材料时仍然继续生成

把必要输入列在入口说明中，并写明缺少任一项时的停止响应。测试时故意删掉一个输入，确认它会暂停而不是编造。

每次维护后，旧任务的结果都不一样

为Skill保留版本、变更说明和固定回归样例。一次只调整说明或脚本中的一个范围，跑完回归再继续下一项。

排查Skill时，分别看触发判断、说明执行、脚本输出和验收结果。一次只改一个层面，才能确认问题究竟出在说明还是工具步骤。

发布前最后检查触发与失败边界

• Skill能在一份新样本上按相同步骤交付，缺材料时会暂停，结果可用明确清单验收
• 触发条件、必要输入和不适用场景已经写清。
• 说明、机械脚本和样例各自承担单一职责。
• 新样本能独立跑通，缺材料时会停下来说明原因。
• 固定回归样例与版本记录都已保留，后续修改可以复测。

验收通过的标准很朴素：结果能用、过程能查、出错能退、未知项没有被伪装成结论。