如果一件工作总要给AI重复交代，你可能已经有了写Skill的素材。但我不建议一上来写一份“什么都能做”的说明书。先挑一件小事，把什么时候用、输入是什么、怎样算完成说清楚，通常更容易检查。
我的起步方法是：选一项重复任务，写成“触发条件、输入、步骤、输出、验收”五部分。先用正常样例验证，再测试缺资料和不该触发的情况。Skill能帮助复用方法，结果仍需要验收。
资料核查日期：2026年9月18日。本文以Claude Code中的SKILL.md为例，模板属于我的编辑建议，没有声称已在你的环境运行。不同产品的技能加载方式要各自查文档。
先选任务，我会避开太宽的题目
“帮我提高效率”很难写成可检查的步骤。我更愿意从“整理三份公开资料，输出带来源的观点清单”开始。输入数量不是重点，重点是资料范围和交付方式能说清楚。
你可以先回看最近几次重复交代：哪些要求每次都一样？哪些是本次任务才需要的？前者适合放进Skill，后者留在每次请求里。这样不容易把某个客户、某个日期的临时要求写成永久规则。
SKILL.md放在哪里？
根据 官方资料，Claude Code支持在个人技能目录或项目的.claude/skills目录下放置技能文件。SKILL.md包含开头的YAML元数据和后面的正文说明；description用于说明任务和适用时机。本文选择项目目录，便于围绕该项目维护。
.claude/skills/source-notes/
SKILL.md
references/
output-example.md我会让文件夹名短一点，含义清楚。准备修改现有项目时，也会先看是否已经有承担相同任务的Skill，避免同一件工作出现几份相互矛盾的规则。
一份可以改写的入门模板
下面的内容是一份资料整理示例。它不包括发布、发消息或修改业务系统。你可以把输出字段换成自己的需求，别只改标题就直接复用。
---
name: source-notes
description: 整理用户提供的公开资料，输出带来源的观点清单。用于资料梳理和文章准备。
---
# 公开资料整理
## 输入
使用本次请求明确提供的文件或链接。
缺少关键材料时列出缺项，不编造内容。
## 步骤
1. 确认本次要回答的问题和资料范围。
2. 为每份资料记录标题、日期和来源。
3. 提取与问题有关的观点和支持证据。
4. 区分事实、来源表述和编辑判断。
5. 输出清单，并说明仍待确认的地方。
## 输出
观点 | 依据 | 来源 | 日期 | 待确认项
## 验收
主要事实可回到原始来源。
未知信息有明确标记。
输出只覆盖本次问题。我把未知信息写进模板，是为了让缺口显眼。没有资料时生成一段看起来顺畅的话，很容易给后续编辑增加核查成本；列出缺项，反而方便下一步补材料。
正文怎么写，才不会越写越长？
我的建议是让主文件保留任务的关键动作，把详细字段解释和示例放到参考文件。方法与说明 说明了技能按需读取说明和附加资料的组织方式。参考文件需要在主说明中给出用途，避免把它们放进目录后就忘了什么时候读。
| 内容 | 我会放哪里 | 原因 |
|---|---|---|
| 触发条件和主要步骤 | SKILL.md | 决定什么时候用、怎么完成 |
| 完整输出示例 | references | 需要时再对照细节 |
| 本次资料列表 | 本次请求 | 避免固定过期输入 |
| 最终检查项 | SKILL.md | 让完成条件清楚 |
我不会因为文档长就认定它更专业。如果一条规则无法解释它避免什么实际错误，我会考虑删掉，或者把它改成更具体的输入、动作和检查。
写完以后，我会这样验收
- 正常样例：资料齐全，检查观点与来源能否对应。
- 缺资料样例：故意不给一份关键材料，看是否明确列缺项。
- 范围样例：给一份无关资料，检查是否仍围绕本次问题。
- 不触发样例：问一个简单常识问题，观察是否无故套用资料清单流程。
我会把实际问题记下来，只修改导致失败的规则。比如来源日期遗漏，就补一条明确的检查；不要因为一次遗漏，继续堆出十段笼统要求。这个做法是我的维护建议，不是某种效果保证。
遇到触发问题，先检查这几处
我会先核对目录和文件名，再读description是否清楚。只写“帮助工作”很难表达用途；写出具体任务和适用场景更容易定位问题。也要确认当前产品支持你选择的目录方式，不要把API上传流程和本地目录混用。
Claude Code文档还提供disable-model-invocation字段，可限制模型自行调用某项技能。需要由人决定执行时机的任务，可以按官方说明评估使用。这个字段不能代替结果检查，也不应被理解为所有执行环境通用的权限规则。
我会保留哪些限制？
模板清楚，仍可能遇到来源变化、文件不可读或说明相互冲突。我的验收会看实际产物，尤其是事实能否回到来源。不要只看AI是否说“完成”。
如果任务会改变真实系统，除了说明步骤，还需要确认可执行范围和批准条件。本文的小模板用于资料整理；换成部署、发消息或公开发布时，需要另外设计具体工作流，不能顺手沿用全部规则。
FAQ：写第一份Skill前，我会先回答这些
一定要会写代码吗？
本文的基础示例是说明文件，不需要额外脚本。后续是否加入脚本，取决于任务是否需要可重复的处理或验证。
能把所有提示词都塞进一个Skill吗？
我会按任务范围拆开。输入、输出和验收差别很大时，各自说明更容易维护。
写好了就不用检查输出了吗？
我仍会核对结果。Skill保存了做事方法，实际输入和来源每次可能变化，验收是流程的一部分。
参考资料
官方资料（Claude Code官方技能文档；核查于2026年9月18日）
方法与说明（Claude Platform技能概述；核查于2026年9月18日）
