Skill 不是把一大段提示词换个地方保存，而是把一类可重复任务沉淀成稳定、可调用、可迭代的 AI 工作流。一个好 Skill 能让 Codex 在遇到类似任务时自动知道该读什么、用什么脚本、按什么顺序验证结果，从而减少重复沟通和临时拼流程的成本。
先从重复任务里找 Skill 机会
最适合做成 Skill 的不是偶发需求，而是你已经重复做过几次、每次都要解释上下文、重复运行脚本或反复纠错的工作。例如发布文章、修复 CI、生成周报、处理特定格式文档、审核 UI、分析日志等。只要流程有稳定输入、稳定步骤和可验证输出，就值得考虑沉淀成 Skill。
输入是否固定：比如文章 ID、PR 链接、报表文件、日志目录、设计稿地址。
步骤是否重复：比如读取上下文、生成素材、调用后台、跑测试、截图验证。
结果是否可检查：比如字段保存成功、页面 200、图片命中、测试通过、报告生成。
是否经常被纠正：如果总要提醒同一件事，就应该写进 Skill。
把触发边界写清楚
Skill 的 description 非常重要，因为它决定 Codex 什么时候会主动选择这个 Skill。描述要说清楚“它做什么”和“什么场景该用它”，不要只写一个抽象名称。比如“发布文章”不如“用于 Weguiding iCMS 文章创建、优化、配图、上传、后台发布和前台验证”。边界越清晰，误触发越少，真正需要时也更容易被命中。
同时要写清楚哪些场景不该用它。例如图片生成类 Skill 不适合处理可编辑 SVG，GitHub PR 评论 Skill 不应该被普通代码解释任务触发。好的 Skill 像一把专用工具，不需要覆盖所有情况。
用渐进披露控制上下文成本
高效 Skill 不应该把所有知识都塞进 SKILL.md。核心流程、关键警告和常用命令放在主文件里；较长的规范、字段说明、案例、分类表、复杂运行手册放到 references；稳定脚本放到 scripts；模板、字体、示例素材放到 assets。这样 Codex 只有在需要时才加载额外内容，既节省上下文，也降低跑偏概率。
SKILL.md：放触发后必须马上知道的流程和禁忌。
references/：放长文档、字段规范、分类表、案例说明。
scripts/：放可重复执行的读取、生成、发布、验证脚本。
assets/：放模板、图片、字体、示例文件等资源。
把脆弱步骤脚本化
凡是容易出错、容易乱码、容易漏字段、需要反复执行的步骤，都应该尽量脚本化。比如后台表单发布、图片上传、字段回读、前台验证、文档渲染检查、数据清洗等。脚本的价值不是替代思考，而是把已经明确的机械步骤变得稳定。
脚本还应该输出结构化 JSON，而不是只打印一堆难读日志。这样 Codex 可以继续读取结果，判断下一步该修正文案、重传图片，还是做前台验证。涉及后台 token、密钥、Cookie 的日志要默认脱敏，避免把敏感信息带进最终答复。
让验证成为流程的一部分
很多 Skill 的失败不是写得不够多，而是缺少验证闭环。发布文章要回读后台字段并检查前台页面；生成文档要渲染成图片检查版式；改前端要跑浏览器截图；改代码要跑测试或至少做静态检查。把验证写进 Skill，后续每次执行都会更可靠。
保存前验证：检查 payload 是否乱码、字段是否齐全、图片路径是否存在。
保存后验证：回读后台字段，确认标题、摘要、正文、缩略图一致。
前台验证：打开真实前台 URL，检查状态码、标题、H1、图片和关键正文。
异常处理：把常见失败原因写成明确的重试或停止条件。
从一个代表任务开始迭代
制作 Skill 不需要一开始追求完美。更好的方式是先选一个最典型的任务，把流程跑通；第二次遇到类似任务时记录重复劳动；第三次再把脚本、参考文档和校验规则补进去。一个 Skill 的质量通常来自真实使用中的修正，而不是第一次就写出大而全的说明书。
一个实用的制作清单
确定这个 Skill 服务哪一类任务，而不是服务所有任务。
写出 2 到 3 个真实使用场景，反推输入、步骤和输出。
把触发描述写得具体，包含常见用户说法和边界。
把长资料拆到 references，把重复命令沉淀到 scripts。
为关键步骤设计验证，并让验证结果机器可读。
每次真实使用后更新 Skill，删掉无用内容，保留能减少错误的内容。
总结
高效制作 Skill 的核心，是把“我这次怎么做”变成“以后遇到同类任务都能稳定这样做”。它不是单纯提示词，也不是越长越好，而是把触发边界、上下文组织、脚本能力和验证闭环组合起来。真正好的 Skill 会让 AI 少猜、多查、会执行、能自检，并在一次次真实任务中变得更顺手。
