把你的专业知识打包给 AI 反复调用：Skill 的写法和几条硬限制

很多人手上有一份越写越长的提示词文档：报价怎么算、合同该看哪几条、客诉按什么顺序处理、内容发布前检查哪些项。用的时候翻出来复制粘贴，改一改再发。

这套做法的问题不在麻烦，在你没法把它交给别人，也没法让它自动生效。Skill 这种组织方式解决的就是这件事：把一段专业知识连同它的触发条件打包，AI 判断该用的时候自己调出来。

Anthropic 是 2025 年 10 月 16 日发的这套东西，2025 年 12 月 18 日把它更新成了开放标准。下面讲它的机制、写法和几条必须知道的限制。

一、它跟「把提示词写长一点」的区别在哪

核心机制叫三级渐进披露，官方给了很具体的 token 口径：

这张表解释了它为什么比「把所有规则写进一份长文档」划算：二十个技能常驻的开销大约是 2000 token，而它们展开后的总量可能是十万 token。

换句话说，你可以把二十件事的专业知识都放在手边，而不用为此付出二十份文档的上下文代价。这是「提示词收藏夹」做不到的事——收藏夹要么你手动翻（不自动），要么全塞进去（贵且互相干扰）。

二、一个 Skill 长什么样

最小结构就是一个目录 + 一个 SKILL.md 文件：

SKILL.md 开头是一段元数据，然后是正文：

元数据这两行，比正文更值钱

因为第一级常驻的就是这两行，它们决定了 AI 到底会不会在正确的时刻调用这个技能。

官方对这两个字段有硬限制，写错了技能加载不上：

name：不超过 64 个字符，只能用小写字母、数字和连字符，不能含 XML 标签，不能包含 "anthropic" 或 "claude" 这两个词。

description：必须非空，不超过 1024 个字符，不能含 XML 标签，而且官方明确要求它必须同时写清楚「做什么」和「何时用」。

第二条里「何时用」那半句是最多人漏的。只写「审核报价单」，AI 不知道用户说「帮我看看这个价给得合不合适」算不算触发条件。把用户可能用的说法都列进去——description 的本质是一个触发器，不是一句介绍。

正文怎么写

正文的读者是一个执行力很强但不了解你们业务的人。所以：

• →写顺序，不写原则。 「先查毛利率再查付款节奏」比「要注意商业风险」有用一百倍。
• →写数字。 「毛利低于 35% 要标出来」比「毛利偏低要提醒」可执行。
• →写例外。 「老客户续约可以放宽到 28%，但要写明是续约」——例外是你的专业知识里最值钱的部分。
• →控制长度。 官方建议正文在 5000 token 以内。超了就把细节挪到第三级的附带文件里，正文只写「详细的历史价格在 历史成交价.csv 里，需要时去查」。

三、四条必须知道的限制

这几条在官方文档里写得很清楚，但很多人是踩了才知道。

限制一：运行环境不一样，能干的事也不一样

同一个技能，放在不同的地方能力不同：

所以一个「去某个网站抓数据再整理」的技能，在命令行里能跑、在 API 沙箱里跑不了。写技能之前先确定它主要在哪跑。

限制二：三端不同步，各存各的

这一条很反直觉：claude.ai 上传的技能不会出现在 API 里，API 上传的不会出现在 claude.ai，Claude Code 的是文件系统上独立的一份（放在 ~/.claude/skills/ 或项目里的 .claude/skills/）。

共享范围也不一样：claude.ai 上的只归个人，Claude API 上的是工作区全员可用，Claude Code 走的是个人目录或项目目录（也可以打成插件分发）。

实际影响：如果你的团队既有人用网页、又有人用命令行，你得分别部署两份。 把技能目录放进 git 仓库是最省事的做法——用命令行的人直接就有了。

限制三：技能是可执行的东西，要当软件审

Anthropic 在文档里给了一条很硬的安全警告：只用可信来源的 Skill，恶意 Skill 可能导致数据外泄和未授权的系统访问，对待 Skill 应当像安装软件一样审计。

这不是形式主义。技能里可以带脚本，在有网络权限的环境里跑起来，能做的事跟你自己在终端里敲命令没区别。

配套的一条提醒来自 OpenAI 那边：他们在 GPT-6 的指南里明确警告，新模型对 skill 文件和 AGENTS.md 里的指令更敏感，「强烈建议」审计这些文件中可能影响模型行为的指令。官方还给了一个优先级声明的模板句：用户的指令优先于技能里提供的指引。

落到纪律上：别人给的技能包，读完每一个文件再用。 尤其是带脚本的。

限制四：技能不是越多越好

常驻开销虽然小，但触发判断是有成本的——技能多了，AI 判断「该用哪个」的准确率会下降，尤其是当几个技能的 description 写得互相重叠的时候。

一个实用的判断：如果两个技能的触发条件你自己都要想一下才能区分，就合并成一个。

四、哪些活适合做成技能，哪些不适合

适合

• →有固定检查顺序的活：报价审核、合同粗筛、内容发布前的检查、上线前的自检清单。
• →有大量你们自己的规则的活：定价规则、退款政策、行业术语的特殊含义。
• →偶尔才用、但用的时候必须精确的活：年度对账、某个特殊客户的对接规范。第三条尤其划算——平时不占地方，用到才展开。
• →需要带附件的活：模板文件、历史数据表、示例文档。这些放第三级，不用的时候完全零成本。

不适合

• →每次都不一样的创作类工作。规则写死反而限制发挥。
• →只有一两句话的规则。直接写进项目说明里就行，包一层技能是过度工程。
• →变化非常快的东西。技能是静态文件，一周改三次的规则维护成本比收益高。

五、从零建第一个技能：四步

第一步，找那份你已经在重复使用的文档。 不要凭空设计，从你已经在复制粘贴的东西开始。那份东西被你反复用，说明它已经被验证过。

第二步，把它拆成「触发条件」和「正文」。 问自己一句话：我在什么情况下会翻出这份文档？把答案写进 description。

第三步，把超过 5000 token 的部分挪出去。 数据表、模板、长例子，全部变成同目录下的独立文件，正文里只写「需要时去看哪个文件」。

第四步，验一次。 新开一个会话，用一句自然的、你平时会说的话触发它，看它有没有被调用、有没有按你写的顺序执行。

第四步不能跳。最常见的失败是：技能写得很好，但 description 里的触发条件跟你实际的说话方式对不上，结果它从来没被调用过，而你以为它在工作。

六、一条容易被忽略的收益

写技能这件事，最大的收益往往不在 AI 那边，在你自己这边。

把一份专业知识写成「触发条件 + 执行顺序 + 例外」这三段，会逼你把一直在脑子里的判断显式化。 很多人写到一半会发现：自己所谓的「凭经验」，其实是三条能说清楚的规则加两个例外。

写清楚之后，这份东西就同时具备了三个用途：AI 能调用、新同事能照着做、你自己三个月后还记得当初为什么这么定。手上有十份这样的文件，比手上有一百条提示词技巧值钱得多。