> 来源：Useful AI Lab（实用 AI / Useful AI）— https://usefulai.cloud/insights/claude-skill-not-longer-prompt/
> 作者：CarryChang · 最近更新：2026-07-30 · 语言：zh-CN

[实用 AI 指南](https://usefulai.cloud/) › [深度阅读](https://usefulai.cloud/insights/)

Anthropic
Claude Code
Skill
MCP

# Skill 不是更长的 Prompt——如何让 AI 按流程稳定完成复杂任务

很多人第一次写 Skill，会下意识地写成一个更长的 Prompt，把背景、规则、注意事项、示例全都塞进去。看起来很完整，但实际并不好用。Anthropic 官方给出的答案是：Skill 的价值在于让 Agent 自动识别场景、加载流程、使用合适工具，并稳定完成任务。我基本认同这套方法论，但也想指出它回避了一个不小的成本问题。

**我的立场：**这篇官方最佳实践里，渐进式披露和最小权限两条我完全认同，是实打实能落地的工程原则。但「验证 + 打分 + 基线对比」这套流程说起来轻巧，真正照做的团队成本不低——文档里没有正面回答这笔账划不划算，这也是我认为整套方法论里最薄弱的一环。

### Skill 是可复用的工作流，不是更长的 Prompt

Prompt 是一次性指令，Skill 是**可复用、自主触发、可维护、可进化**的工作流。官方用厨房比喻：MCP 提供「专业厨房」——通向 Notion、飞书等服务的接口；Skill 提供「食谱」——告诉 AI 怎么用工具做出有价值的东西。**MCP 决定 AI 能做什么，Skill 决定 AI 该怎么做。**这个比喻我认为是这篇文档里最清晰的一句话，比后面大段的规则条目都更能一次讲明白两者的分工。

### 动手之前，先定 2-3 个具体用例

先回答四个问题：用户想完成什么？需要哪些多步流程？需要哪些工具？应该嵌入哪些领域知识？每个用例写清四件事——**用例、触发、步骤、结果**。定不出 2-3 个具体用例，说明你需要的可能只是一段 Prompt。

Anthropic 把 Skill 归成三类：**文档与资源创建**（重点是质量检查和模板结构）、**工作流自动化**（重点是步骤衔接和关卡验证）、**MCP 增强**（服务提供方写给用户的「怎么用」说明书）。开工前想清自己在哪一类，写法重点完全不同。

### 按需加载：Description 决定成败

Skill 的特点是 **on-demand loading（按需加载）**——平时不会把整个 SKILL.md 塞进上下文，只有当用户输入与 description 匹配时才加载。关键细节：Skill 正文不常驻，但 **description 会长期参与匹配**，直接决定 Skill 会不会被正确触发。Anthropic 公式：**[做什么] + [什么时候用] + [关键能力]**，不超 1024 字符，必须用第三人称。

> 好的描述示例：拆解小红书爆款笔记的封面、标题、开头、结构、关键词，输出可复用的模板。当用户说「拆解一下这条笔记」、「分析这个爆款」，或贴一条小红书链接时，使用这个 skill。 — — Anthropic Skill 最佳实践

### 最小权限 + 匹配合适模型

核心原则：**只给完成任务所需的最小权限**。不要让只负责生成建议的 Skill 默认能修改文件，甚至可以细致到子命令级别——发布文章的 Skill 只允许跑发布脚本，不能动其他文件。不同任务对模型要求不同：写文档用写作强的；数据分析用推理不错但便宜的；信息爬取用快而便宜的。配合 effort 字段控制思考深度：简单任务低思考省钱，复杂决策高思考换准确率。

**图解 15**：
渐进式披露：Skill 的三级加载，各级付的成本不同
（适合：工程师向）

Skill 好不好用，一半取决于**你把哪些内容放在哪一级**。**description 是唯一常驻的部分**，所以它既是触发开关也是持续成本；**SKILL.md 只在匹配后加载**，超过 500 行通常意味着该拆；**大段模板与脚本应该沉到第三级**，按需读取。做这个分层不只为省钱，更是为了不让关键指令被淹没在过长的上下文里。

### 渐进式披露：SKILL.md 不承载所有内容

这是最容易被忽略的原则。三级加载：**Description**（始终加载）→ **SKILL.md 正文**（匹配时加载）→ **捆绑文件**（按需读取，放在 references/、scripts/、assets/）。SKILL.md 建议 500 行以内——超过通常说明你把太多东西混在一起，拆完还长可能说明这不是一个 Skill 而是几个。

> 渐进式披露的目的是「在保持专业知识的同时，最小化 token 用量」。省钱看得见，省上下文空间看不见——但长对话里后者影响更大。 — — Anthropic 官方文档

两个原因：**省 token**（一个月几万次调用就是真金白银的 API 账单）与**省上下文空间**——内容太多会挤占对话历史、埋没关键指令（「中段迷失」）、触发自动压缩导致模型表现下降。

### 写完必须验证、打分、迭代——但这笔账没那么好算

Skill 写完不代表能用。至少做三类验证：**能不能跑**、**能不能正确触发**（该触发的触发、不该触发的不触发）、**结果是否比不用 Skill 更好**——最容易被忽略的一点。每个用例 0-10 分打分，主要测试至少 5 分以上。想更专业可以做**基线对比**：同一个测试跑两次，7 分变 7 分说明没增益，4 分变 8 分才说明经验真正被固化了。

评论员视角
这套验证流程本身没有问题，我质疑的是它被轻描淡写地放在文末，像是「顺手做一下」的收尾动作。事实是：定 2-3 个用例、写触发测试、做 0-10 打分、再做基线对比——这四步做完的工作量，很可能超过写 SKILL.md 正文本身。文档全篇在教你怎么写好一个 Skill，却没有给出一个粗略的判断标准：什么规模的重复任务，值得付出这套验证成本？

我的判断是这样算账的：如果这个任务你一周只做一次，手写 Prompt 反而更便宜；只有当同一个流程要被反复调用几十次以上，验证成本才能被摊薄。文档把 Skill 的适用范围讲得很宽，但没有讲清楚这条成本线在哪里，这是我认为整篇最佳实践里最该补上的一块。

#### 核心观点

- Skill 是可复用的工作流，不是更长的 Prompt

- MCP 决定能做什么，Skill 决定该怎么做

- Description 是 Skill 的灵魂，写好三段公式

- 渐进式披露：省 token、省上下文、保模型表现

- 写完必须验证、打分、迭代——不能只靠感觉

#### Skill 速查清单

- 定 2-3 个具体用例（用例 / 触发 / 步骤 / 结果）

- 判断类别：文档创建 / 工作流 / MCP 增强

- Description = 做什么 + 什么时候用 + 关键能力

- SKILL.md ≤ 500 行，详细内容拆到子目录

- 工具最小权限 + 匹配合适模型

- 触发测试 + 质量打分 + 基线对比

#### 我持保留意见的地方

- 验证 + 打分 + 基线对比这套流程的人力成本被低估了

- 文档没给出「值不值得写 Skill」的调用频次门槛

- 低频任务上，手写 Prompt 可能比养一个 Skill 更省事

## 继续阅读

[如何从零构建你自己的大语言模型：GPT 和 Claude 背后的 5 阶段流水线 → 所有前沿模型都由同样的五个阶段构建：数据 → 预训练 → 监督微调 → 奖励建模 → 强化学习。学会这套骨架，你就不会再把模型当作魔法。](https://usefulai.cloud/insights/how-llms-are-built/)
[Anthropic 工程师：我们日常如何使用 Claude Code → 用一个真实 repo 演示 Anthropic 工程师怎样配置 Claude Code、让它问问题、生成 HTML 规格稿，再把验证流程做进 React 组件和浏览器。](https://usefulai.cloud/insights/anthropic-how-we-use-claude-code/)
[深度阅读 → 6 篇 AI 长文的完整中文解读：Claude Code、Skill、Agent、大模型原理。](https://usefulai.cloud/insights/)