结论先行
Skill 适合把一类重复任务的做法留下来，例如每次都按相同顺序整理资料、核对表格、制作文件。它通常由说明和相关资源组成，由兼容的助手按需使用；它不是一个独立聊天机器人，也不意味着装上之后就能正确完成所有任务。本文讲清机制并提供一个可检查的练习，不为未实际试用的产品定星，也不把示意练习写成实测结果。
判断一个 Skill 值不值得用，先问三件事：我是否反复做这件事，它是否交代清楚输入与输出，以及我有没有办法检查结果。名字听起来专业、文件很多、演示漂亮，都不能替代这三个问题。一次只有几句话的小任务，直接说明要求往往更方便。
适用与不适用
适合使用的场景，是任务的步骤相对稳定，但每次材料不同。比如你每周读三篇材料，希望每次都得到“核心观点、原文依据、尚未证实的问题”；或者你每次收到一份表格，都要先检查缺失值，再统一单位，最后输出一份异常清单。把顺序与要求保存下来，可以减少反复解释。
不适合的场景，是目标本身还没有确定。例如你还不知道汇报给谁、希望对方做什么决定，就先寻找“万能汇报 Skill”，结果往往只是把不清楚的目标包装得更漂亮。任务涉及金额、客户隐私、发布内容或修改正式文件时，也不能把一个 Skill 的存在理解为授权。权限仍应按具体动作确认。
新手还要区分“任务说明模板”和“可运行的 Skill”。你可以在普通聊天窗口粘贴一份做法，这只是使用同一套说明；真正装到某个宿主里时，还可能涉及发现机制、资源加载、脚本、依赖和目录结构。本文的练习不要求安装，因此不会声称已经完成某个产品的 Skill 配置。
怎么用：先把一份阅读笔记做对
先准备一段明确标为虚构、没有隐私的练习材料：
示例项目计划在周五完成第一版演示稿。小林负责整理用户反馈，小周负责检查数据。现有反馈共十二条，其中三条涉及操作步骤。材料没有给出预算，也没有说明最终审批人。
第一步，先手工写出你需要的结果。这里需要一份简短笔记，包含三条要点，每条要点附对应的原文，再列出材料没有给出的信息。输入只有上面这一段，不要让工具自行搜索背景。你先知道正确结果大概长什么样，才有能力判断生成结果。
第二步，把方法写成清楚的任务说明。下面这份是本网站编排的练习，不是某个官方产品的安装包：
任务：把提供的材料整理为可核对的阅读笔记。
输入：仅使用用户提供的原文。
步骤：
1. 提取最多三条关键事实，不补充外部背景。
2. 每条事实附上对应的原句。
3. 列出材料没有给出的重要信息。
输出：事实表、待确认问题。
验收：每条事实都有原文；人数、日期和职责不改变。
遇到缺失信息：写“材料未提供”，不推测。
第三步，在你已经能够使用的助手中，把原文和说明一同提交。这里观察的是方法是否清楚，不要求使用某个品牌。生成过程中不要追加真实业务文档，也不要因为第一次结果顺眼，就把同一方法立即用于更敏感的材料。
第四步，把结果复制到一份临时文档，逐项比对。记录发现的问题，然后只修改任务说明中对应的部分。例如结果出现了审批人的名字，就补充“不得依据常识推断人员”；结果把十二条反馈全写成操作问题，就强调“总数与子集分别保留”。
第五步，用另一段不同材料重复一次。只会处理最初那段材料，说明你的方法还没有得到足够检验。第二段可以故意不写截止日期，观察助手会不会自行编一个周五。通过这种小规模反例，比不断增加华丽的角色描述更容易发现边界。
怎么确认做对了
第一项验收是事实。演示稿时间应保留为周五，不能变成一个具体年月日；十二条是总反馈数，三条只是其中一个子集，不能相加成十五条。小林和小周的职责应能在原文找到对应句子。这些都可以直接对照，不需要相信模型的自我评价。
第二项验收是缺失信息。预算和最终审批人应标记为“材料未提供”。如果输出看起来更完整，却补出了金额、负责人或审批流程，这不是额外帮助，而是越过了材料边界。把这类错误记下来，再缩小任务范围。
第三项验收是交付。你要求的是笔记，就检查结构是否便于阅读；如果将来换成文件处理 Skill，还要实际打开文件，检查分页、文字遮挡、表格和数字。聊天窗口里显示“文件已完成”，不能证明文件可以正常交给别人。
第四项验收是可重复性。更换材料后，输出规则应该仍能工作。它不必每次使用同样措辞，但必须持续遵守来源边界。如果你还需要逐段重写大部分结果，应重新评估这个方法是否省时，而不是只计算“生成用了几秒”。
限制与坑
安装前先看来源、适用宿主和授权。Anthropic 的官方说明介绍了按需加载说明、脚本与资源的组织方式；其示例仓库也分别给出了不同技能的内容和许可。不能据此推断所有同名扩展都来自官方，也不能把仓库里的不同许可合并为一句“全部免费商用”。
脚本可能需要读取文件、调用程序或联网。请先读它会做什么，用副本和测试数据运行，并确认需要哪些依赖。不要因为说明里写着“自动化”，就提供整个工作目录、密钥或客户资料。你不能解释的权限，先不要给。
另一个常见问题是规则堆得太多。格式、语气、长度、来源、计算和排版同时提出，未必比拆成两步更稳。先完成事实提取并核对，再安排表达与排版，通常更容易定位是哪一步出了问题。具体表现仍需在你的宿主和任务上检验，本文不承诺成功率。
延伸：回到六个概念
模型提供理解与生成能力；平台提供你使用的入口；工具处理具体动作；Agent 把多步任务往下推进；Skill 保存一类任务的做法；API 则让程序调用服务。这些是帮助理解的分工，同一个产品可能同时具备其中几种形态。
真正要选的时候，可以先写下“输入是什么、最终交付什么、怎样算正确”，再决定是否需要 Skill。如果只是修改两句话，不必为了新名词绕远路；如果同类材料每周都来，而且验收规则稳定，才更值得把方法整理成可复用资源。
更新记录
2026-10-20：针对原有短笔记扩写为有步骤、原始材料与验收条件的修订草稿。本文由 AI 辅助起草，依据官方机制说明整理；未进行具体宿主的安装实测，没有真实界面截图，不声称已经核实产品功能。本次按站内说明发布；仍未做具体产品的全流程实测。
参考资料：
- Anthropic：Equipping agents for the real world with Agent Skills，https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills ↗
- Anthropic 官方技能示例与各技能许可说明，https://github.com/anthropics/skills ↗