Anthropic 刚放的 Agent Skills 框架：把你的提示词固化成「技能包」，一次写好到处复用

你有没有这种经历：同一段提示词每天复制粘贴

你写了一段「把用户反馈按情绪分类」的提示词，很好用。第二天要给另一个项目用，你打开聊天框，翻历史记录，复制，改几个词，再发。第三天的第三个项目，又来一遍。

提示词一旦好用，就会开始「繁殖」：散落在各个对话框、文档、笔记里，谁也记不清哪一版是最新的。Anthropic 这周放的 Agent Skills 框架，本质上就是给这种「好用的提示词」一个正经的家。

以前我们怎么干的：复制粘贴的代价

你以为复制粘贴不要钱，其实它吃掉的是「一致性」。同一个分类标准，A 项目里写的是「分三类」，B 项目里你随手改成了「分四类」，半年后没人说得清到底该几类。更糟的是，当新人接手，他不知道有这份提示词，又从零写了一份更差的。

知识没有沉淀，团队就一直在重复造轮子。Skills 框架要解决的，正是「让好用的经验不随人走、不随对话散」。

Agent Skills 不是新模型，是一层「可复用能力」

它不训练模型，也不改模型权重。它做的是：把你的一段能力描述、命令、约束、参考文件，打包成一个标准目录，让 Agent（Claude Code、Claude 平台上的各种智能体）在需要时自动加载。

官方给的定义很克制：可组合、可移植、可执行的「专业技能模块」。说人话就是——你写一次，任何支持 Skills 的 Agent 都能用；你改一处，所有用到它的地方都更新。

一个最小可用技能长什么样

一个 Skill 就是一个文件夹，核心是 SKILL.md：

my-skill/
├── SKILL.md        # 必须：能力说明与触发条件
├── scripts/        # 可选：要运行的脚本
└── references/     # 可选：参考资料

SKILL.md 的最小结构：

---
name: refund-tones
description: 当用户需要生成「客服退货话术」时使用，按品牌语气输出三段式回复
---

# 退货话术生成

## 输入
用户提供：订单问题、用户情绪（平静/不满/愤怒）、品牌调性

## 步骤
1. 先共情，不辩解
2. 给明确解决方案（退款/换货/补偿）
3. 收尾留一个可继续对话的口子

## 约束
- 不承诺超出政策的范围
- 愤怒用户先道歉再解决

注意 description 不是装饰，它是 Agent 决定「要不要加载这个技能」的唯一依据。写清楚「什么时候用」，比写漂亮的能力描述重要得多。

三步把现有提示词改造成技能

1. 抽出来：把你最常用的那段提示词，从聊天框复制到 SKILL.md 的 body

2. 写 description：用「当用户……时使用」的句式，说清触发场景

3. 补参考资料：如果它依赖某个表格、模板、样例，放进 references/，在正文明明引用

改完之后，你不用再手动粘贴。Agent 在对话里识别到「退货话术」类需求，会自动去加载这个技能。

什么该做成技能、什么别做

适合做成技能的：

• 反复用、且步骤固定的任务（分类、抽取、话术、巡检）
• 带私有知识的任务（你们公司的退款政策、你们产品的术语表）
• 团队共享能力（一个人写好，全组都能调）

不适合的：

• 一次性的临时任务（直接聊就行，别为它建目录）
• 高度依赖实时上下文、没法标准化的活
• 你还没验证过效果的提示词（先跑通再固化）

一个团队能省多少：算笔时间账

假设一个 5 人运营团队，每人每周花 2 小时在「找旧的提示词、改、再发」上，一个月就是 40 小时，约等于一个人一周的工时。把这些高频提示词固化成 10 个技能后，新人第一天就能调，老员工不用再翻聊天记录。

省下的不只是时间，更是「输出不跑偏」的确定性——这件事对客服、合规、内容这类容错低的场景，比省那点时间更值钱。

误区：把技能当成「万能提示词库」

有人一听 Skills，就把所有提示词一股脑塞进去，结果目录里躺着三十个技能，Agent 每次加载都要判断用哪个，反而变慢。技能的精髓是「少而精」：只固化那些你反复用、且判断标准稳定的能力。一个团队有 5–10 个核心技能，比一百个杂乱提示词有用得多。

另一个误区是「写完就不动」。业务变了，技能里的约束也要跟着改。把 SKILL.md 当成会过期的文档，每月过一遍，删掉不再用的，比囤着强。还有人把机密写进技能正文，忘了它会被加载进模型上下文——涉及密钥、客户名单的内容，放 references/ 并用权限控制，别直接写进入口文件。

实战：给客服场景写一个「退货话术」技能

假设你是电商品牌运营，每天要回几十条退货咨询。技能写好后，你只需说「帮这位愤怒用户写个退货回复」，Agent 就会按你定的「先道歉、给方案、留口子」结构出三段话，语气还符合品牌。

关键点在于：技能的 value 不在「生成文字」，而在「把你的判断标准固化下来」。下次换人、换 Agent，输出的调性不会跑偏。

避坑：技能不是越长越好

新手容易把 SKILL.md 写成小作文，把所有可能的分支都写进去。结果 Agent 加载后反而抓不住重点。

经验法则：一个技能只解决一类问题，正文控制在能一眼看完的长度。需要展开的细节，放到 references/ 里按需读取，而不是全堆在入口文件。

技能之间也能组合

单个技能解决一类问题，多个技能串起来就能跑一段流程。比如「退货话术」技能 + 「情绪分类」技能 + 「补偿方案」技能，组合成一个完整的售后 Agent：先分类用户情绪，再选话术，最后给方案。

组合的好处是「各管各的」：话术改了不影响分类，分类逻辑升级不碰话术。比起把一个超长提示词塞满所有逻辑，拆成可组合的技能，后期维护和复用都轻松得多。这也是 Skills 框架强调「可组合、可移植」的用意。

你的第一个技能，今天就能建

别想着「我要建一套完整的技能体系」。先找一个你这周复制粘贴超过三次的提示词，按上面的三步改成技能。等它真的帮你省了时间，你自然会想建第二个。

Agent Skills 的意义不是「更聪明的 AI」，而是「让好用的经验不再流失」。对一个团队来说，这比追一个新模型实在得多。