想把 Claude 的 Skill 学明白？这份 Anthropic 33 页 PPT 够你少走一周弯路

你是不是也有这种体验：

• 想做一个“可复用”的提示词/流程（也就是 Skill）。
• 写着写着变成一坨超长 Prompt，效果还忽好忽坏。
• 一旦翻车，你根本不知道是“需求没说清”还是“模型在瞎编”。

别硬扛。Anthropic 出了一个 33 页的 Skill 教程 PPT，把“怎么做、怎么测、怎么修”讲得很实在。

链接在这（自己补全可访问地址即可）：

• https://resources.anthropic.com/hubf…

下面这篇是我按“照做就能落地”的方式，帮你把 PPT 的学习路径变成一套可执行的训练计划。📌

0. Skill 到底是啥？别把它当玄学

一句话：Skill 就是一个稳定可复用的任务方案。

它通常包含：

• 清晰的输入/输出
• 明确的约束（格式、口吻、范围、禁止事项）
• 处理步骤（模型该怎么想、怎么查、怎么产出）
• 验收标准（怎样算对，怎样算错）

你可以把它理解成“给模型写的 SOP”。写得好，你每天能少加班一小时；写得烂，就会变成天天救火。

1. 基础知识：把“可控性”这件事搞到位

你要盯死的 3 个点

• 任务边界：模型该做什么、不该做什么
• 信息来源：只能用你给的材料？还是允许常识？能不能编？
• 输出协议：结构化输出（JSON/表格/分点）比散文稳定太多

练习：用一句话把 Skill 讲清楚

把下面这个模板填满：

当用户提供【输入】时，我要输出【输出】，遵守【格式/约束】，遇到不确定就【澄清/拒绝/标注假设】。

例子（你可以照抄再替换业务）：

• 输入：一段客服聊天记录
• 输出：投诉原因、情绪等级、建议回复
• 约束：只根据聊天记录，不补充臆测；输出 JSON；字段固定

你会发现：光把这句写顺，就已经把一半问题解决了。

2. 设计：别堆提示词，按“模块”搭起来

PPT 里最值钱的点一般都在这：设计结构。

一个好用的 Skill 结构（直接拿去用）

你可以用这种“分块式”提示，不容易失控：

• 角色与目标：你是谁、要达成什么
• 输入说明：输入长什么样、有哪些字段
• 规则：能做/不能做、优先级
• 步骤：按步骤处理（越短越稳）
• 输出格式：给示例，让模型照着填

设计时最容易踩的坑

• 规则写成道德说教：没用。改成可执行约束。

  • ❌“请认真思考”
  • ✅“只从材料中提取信息，缺失就返回 unknown”

• 输出格式不封死：模型就会自由发挥。

  • ✅ 给一份完整的输出样例（哪怕是假数据）。

• 要求太多还互相打架：比如“要简短”又“要非常详细”。

  • ✅ 给优先级：准确 > 完整 > 简洁。

直接可用：Skill 输出 JSON 模板

{
  "task": "",
  "assumptions": [],
  "result": {},
  "warnings": [],
  "next_questions": []
}

你会爱上 warnings 和 next_questions。

它们能让模型“有台阶下”，不会为了显得聪明瞎编。

3. 测试：别靠感觉，做一套“能复现”的用例

做 Skill 最爽的状态是：

• 你改了一句话
• 跑一遍用例
• 马上知道哪里变好了、哪里变烂了

你需要的测试集长什么样

准备 10~20 条就够你起飞，类型要覆盖：

• 标准样本：正常输入
• 边界样本：信息缺失、格式乱、超长文本
• 对抗样本：诱导编造、要求输出敏感信息、让它忽略规则
• 真实脏数据：复制几段你业务里最难搞的输入

验收标准别写虚的，写“可打分”的

• 格式正确：JSON 可解析 / 表格列齐全
• 事实正确：引用点是否来自输入材料
• 覆盖度：关键字段是否漏掉
• 稳定性：同一输入多次跑结果不漂移太多

快速测试方法（省时间版）

• 把用例整理成一个表格：输入 + 期望输出要点
• 每次修改 Skill，只跑 5 条“最容易翻车”的用例
• 通过再全量跑

你会发现：跑得越勤，返工越少。

4. Debug：模型翻车时，你该查哪里？

Skill 的 Debug 不靠玄学，基本就这几类问题。

问题 1：输出格式乱

常见表现：多解释、少字段、夹带自然语言。

处理方式：

• 把“输出格式”单独放一块，写得更硬
• 明确禁止额外文本：
  • “除 JSON 外不要输出任何文字”
• 给一份完整的 JSON 示例

问题 2：开始编造

常见表现：材料里没有，它给你补出一段“看起来很合理”的话。

处理方式：

• 强制“缺失即 unknown”
• 加一个引用机制：让关键结论附带来源片段（哪怕是短引用）
• 让模型在 assumptions 里写清楚假设

问题 3：回答不稳定

同样输入，结果漂移。

处理方式：

• 把步骤写短、写死
• 减少“开放式创作”要求
• 增加约束词：字段枚举、固定标签集合

问题 4：它不按你的流程走

处理方式：

• 把步骤改成“检查清单”风格
• 每一步输出一个中间结构（不一定给用户看，至少让它内部对齐）

一套 30 分钟上手路线（照着做）

• 打开那份 33 页 PPT
• 选一个你每天都在重复做的任务（比如：会议纪要、工单归类、内容改写、简历筛选）
• 用我上面给的“一句话模板”把 Skill 定义写清楚
• 按“分块结构”写出 Skill 提示
• 准备 10 条测试用例（标准/边界/对抗各来点）
• 跑用例，记录翻车点
• 只改一个变量（比如只改输出格式），再跑一次

记住：别一次改十处，不然你不知道是哪一刀起作用。

避坑清单（很实用，建议收藏）

• 需求没写清就开写 Prompt：返工概率极高
• 没有测试集就调参：你永远在“感觉变好了”
• 输出格式不固定：后续接自动化基本没戏
• 不允许 unknown：模型就会硬编
• 一上来追求通用：先把一个窄场景打穿

你可以拿它做什么？给你 3 个具体场景

• 客服/运营：自动归类问题 + 生成回复草稿，减少复制粘贴
• 内容团队：把选题、改写、质检做成 Skill，批量产出更稳
• 产品/研发：把需求评审记录、缺陷单、Release Note 格式固定下来

你把 Skill 做稳了，后面接工具调用、接工作流、接自动化，才是真正的“省命”。

如果你愿意，把你想做的 Skill 场景丢我一句（输入是什么、输出想要什么），我可以按这个教程的结构，帮你把第一版提示词框架搭出来。