技能提升网团队里有些工作并不难，却总在消耗时间。每周整理同一份进展报告，发布文章前检查相同字段，导出文件后逐项确认格式。负责的人知道完整做法，换个人接手，就得从聊天记录里重新拼一遍。
这类流程适合自动化，但并非都要先写一套大系统。规则已经稳定、输入和结果能够说清时，可以把操作要求整理成 Skill，让 AI 在遇到对应任务时读取同一套说明、参考资料和检查方法。
先判断这项工作值不值得封装
适合做成 Skill 的任务通常会重复出现，而且每次都遵循相近步骤。例如文章发布要核对标题、分类、标签、图片和状态；月度报告要读取固定表格，再按约定字段输出。结果好不好也应有检查依据。
如果工作仍在频繁改规则，或者每次都依赖负责人临场判断，先维护一份普通 SOP 更省事。Skill 不会消除业务判断。它只是把已经确认的做法放进可调用的执行环境，减少遗漏和重复解释。
开始前，把最近几次真实任务摆在一起。记录用户通常怎么提出需求、需要哪些输入、最终交付什么文件，以及最常见的错误。别只写“提高效率”或“帮助完成工作”。这类目标无法指导后续步骤，也很难测试。
把 SOP 拆成触发、执行和验收
一份常见 SOP 可能写着：“收到资料后整理内容，检查无误再发布。”人能结合经验补齐细节，AI 看到的空白却很多。整理成 Skill 时，要把它拆成三块。
- 什么情况下使用：用户提到哪些任务、文件或结果时应加载这套能力。
- 具体怎样执行：资料从哪里来，步骤按什么顺序，哪些地方需要停下来判断。
- 怎样确认完成：输出必须有哪些字段，哪些错误必须拦住，线上变更后如何复查。
范围也要写清。一个负责 WordPress 文章发布的 Skill，不应顺手管理网址导航分类；处理内部材料的 Skill，不应默认把敏感内容发送给外部服务。边界越模糊，实际使用时越容易误触发或扩大操作范围。
SKILL.md 只保留需要立即知道的事
Skill Creator 的官方说明把 SKILL.md 视为核心文件，其中包含名称、描述和执行规则。描述决定 Skill 在什么任务中被发现和触发，因此要同时说明“能做什么”和“什么时候使用”，相近但不适用的任务也可以在描述里排除。
正文写执行路线、关键约束和资源入口。遇到一两百行的领域规范，不必全部塞进主文件。官方给出的分层方式是：名称和描述作为常驻元数据，Skill 触发后读取 SKILL.md，较长的参考资料和脚本则在需要时加载或运行。
资源目录按用途增加即可。重复且要求精确的机械步骤适合放进 scripts，例如校验 JSON 或转换文件；references 用来保存字段规范、审核标准和接口流程；assets 则存放交付时要复用的模板或素材。只有一页简单说明的 Skill，不需要为了看起来完整而创建三个空目录。
以内容发布流程为例
假设团队经常把文章发布到同一个网站。一个能工作的 Skill 至少要回答这些问题：
- 收到“发布文章”时需要哪些正文、分类、标签和图片信息。
- 文章引用的工具怎样核实，无法核实时如何处理。
- 发布前检查哪些字段，重复标题或无效分类是否应阻止提交。
- 线上写入属于什么风险级别，什么时候已经获得用户授权。
- 发布后如何读取文章状态，并确认图片、链接和特色图设置。
这五项来自真实工作要求。若只写“根据用户内容生成并发布高质量文章”，执行者仍要临时决定分类、图片、权限和验证方法，团队最想减少的差异依旧存在。
还可以把结构化 JSON 设为唯一事实来源。正文、分类和图片先写进同一份文件，预检、发布和更新都读取它。这样修改不会散落在聊天内容、临时表单和线上页面之间，失败后也更容易重现提交内容。
写完以后先找它的麻烦
Skill 能完成一个顺利案例，只说明基本路径能走通。测试还要加入缺少输入、容易混淆和不应触发的任务。比如文章没有分类、图片文件不存在、用户只是询问接口原理，并没有要求发布。最后一种情况用于确认 Skill 不会把解释请求误当成线上操作。
官方 Skill Creator 建议准备两到三个真实测试提示，并比较启用 Skill 和不启用时的结果。评价不必只看文字是否更长。更有用的指标包括必填字段是否齐全、错误是否在写入前被拦住、输出能否重复执行，以及完成后有没有验证证据。
主观任务可以保留人工评审。例如写作 Skill 的语气是否自然、设计 Skill 的页面是否符合品牌，都很难用一个数字判断。客观字段则适合写成自动检查。把两类评价混在一个总分里，往往会掩盖真正的问题。
失败时别急着加更多规则
测试失败后，先定位错误来自哪里。该触发时没有触发，通常要检查名称和描述；已经触发却漏步骤，应查看正文指令和资源入口；脚本输出不稳定，则需要修复脚本或输入校验。若每次失败都向 SKILL.md 末尾补一条规定，文件会很快变成长而重复的补丁集合。
修改时保留原任务作为回归测试，同时加入导致失败的新案例。这样可以看到问题是否修好，也能发现新规则有没有破坏原来的正常路径。团队还应记录版本、依赖和负责人，外部接口或模板变化后才知道由谁复查。
需要人工保留的决定
发布、删除、付款和对外发送等操作会改变真实系统，Skill 里应写明授权与发布后验证要求。账号凭据不要放进说明文件或示例，脚本只读取运行时配置。第三方依赖和社区 Skill 也要核对来源、许可证和权限。
当一套 Skill 可以被新人用真实任务跑通，遇到缺失信息会停下，完成后能拿出检查结果，这项流程才算真正沉淀下来。下一次规则改变，更新同一份 Skill 和测试集，不要再从新的聊天记录开始积累另一套口头 SOP。
