适合谁，不适合谁
开始前准备
- 一个已经真实执行过的重复任务，以及至少一份成功样例和一份容易出错的样例。
- 明确的触发场景、输入材料、输出位置、允许工具和禁止操作。
- 记录过人工判断点、常见失败和遇到缺失信息时的停止条件。
- 可观察的验收方法，例如数量、格式、关键值、测试、截图或人工抽样。
完整步骤
选择高频、低风险、可验证的流程
优先选择重复发生、输入输出清楚、失败可回退的小任务，例如每周数据检查，而不是“自动完成所有工作”。
复盘一次成功和一次失败
逐步记录使用了哪些材料和工具、哪里需要人工决定、失败为什么发生，以及怎样发现错误。
定义触发条件和不触发条件
写清用户怎样表达需求时应使用这个 Skill，以及材料不完整、任务超范围或风险过高时应停止或转人工。
整理指令、参考资料和脚本
核心说明保持简洁；稳定规则放在 Skill 指令中，大段参考资料或可复用脚本按当前 Codex Skills 结构分开放置。
把验收与汇报写进流程
规定必须运行的检查、需要保存的证据、最终汇报格式和未完成项说明，不能只要求“生成结果”。
用不同输入测试并持续维护
测试正常、缺失、异常和边界输入；记录误触发、漏步骤和错误结果，更新版本后重新跑回归样例。
把每周报告流程整理成 Skill 说明
这不是完整文件模板，而是封装前必须回答清楚的流程规格。
【名称】每周数据与报告检查 【触发】用户要求用本周数据更新固定格式图表和报告时。 【不触发】数据来源不明、生产数据库需要写入、报告模板版本无法确认时。 【输入】本周数据文件、上周报告、当前模板、指标定义表。 【步骤】校验文件 -> 检查字段 -> 生成测试输出 -> 对比关键值 -> 写入报告副本。 【停止条件】缺少必填字段、关键值异常、目标路径不是测试目录。 【验收】文件数量、字段完整率、三项关键值、图表数量和报告页数可核对。 【汇报】列出输入、生成文件、检查结果、异常、未完成项和下一步。
以后只要我说做周报，就自动处理所有东西。
只有输入、模板和测试目录齐全时才运行；缺少字段或关键值异常立即停止；最终报告必须列出检查证据。
怎样判断结果是否可用？
可用规格能让另一次执行判断何时开始、何时停止、使用哪些材料、输出到哪里以及如何验证；如果这些问题仍需临场猜测，流程还不适合封装。
常见问题与报错
Skill 经常在不相关任务里触发
收窄名称和触发描述，补充明确的不触发条件，并用相似但不应触发的任务做测试。
同一输入每次结果差异很大
检查步骤是否依赖未写明的人工判断、动态数据或外部状态；固定输入结构、输出格式和检查规则。
流程跑完了，但错误没有被发现
把数量、关键值、测试或抽样检查设为强制步骤，并规定失败时停止，不继续生成最终成果。
Skill 越改越长、规则互相冲突
删除重复和过期说明，把大段背景移到参考资料；保留单一事实来源，并为更新建立回归样例。
完成后的检查方法
- 流程真实重复过，至少有成功和失败样例。
- 触发条件、不触发条件和适用范围明确。
- 输入、输出、工具、路径、权限和停止条件写清楚。
- 人工判断、高风险操作和最终责任没有被隐藏。
- 验收依赖可观察证据，而不是模型自述。
- 正常、缺失、异常和边界输入都已测试。
- 版本更新后会用固定样例重新验证。
FAQ
Skill 和普通提示词有什么区别？
普通提示词更适合一次任务；Skill 面向可重复工作，通常还包含触发条件、步骤、参考资料、工具使用和验收方法。具体结构以当前 Codex 官方说明为准。
不会写代码也能做 Skill 吗？
可以先整理不依赖脚本的文件或内容流程。关键是你了解真实步骤、风险和检查方法；需要脚本时再让工具辅助实现并测试。
一个 Skill 应该包含多少任务？
优先只解决一类边界一致的任务。触发条件、输入或验收完全不同的工作应拆开，避免一个 Skill 变成万能说明书。
怎样训练自己的 Skills？
每次真实执行后记录误触发、缺失步骤、失败原因和人工修正，把稳定经验补回说明，并用原有样例做回归测试。
Skill 可以直接执行发布或删除吗？
技术上是否可执行取决于工具和权限，但高影响操作应有明确授权、预览、人工审批、日志和回退，不应默认自动完成。
资料来源与版本说明
- OpenAI Codex Skills 官方说明
用于复核 Skills 的当前结构、发现方式和使用范围；具体字段与目录以最新官方文档为准。
- OpenAI Codex 官方文档
用于复核当前 Codex 产品形态和可用能力。
从一个已经跑通的小流程开始训练。
先在项目中保存成功与失败样例，完成输入、停止条件和验收规格；需要接入相关客户端时，再到小贺API查看当前配置说明与基础协助。 模型、价格、额度与规则以对应业务站当前展示为准。
进入小贺API查看使用入口