评估 Agent Skill 的设计品质是否符合官方规范与最佳实践。在审查、审计或改进 SKILL.md 档案及 Skill 套件时使用。提供多维度评分与可落地的改进建议。
Skill Judge
根据源自 17+ 个官方范例的规范与模式，评估 Agent Skill 的设计。
核心理念
什么是 Skill？
Skill 不是教学指南。Skill 是一种知识外置机制。
传统的 AI 知识是被锁在模型参数之中的。若要教授新能力：
传统方式：收集资料 → GPU 丛集 → 训练 → 部署新版本
成本：$10,000 - $1,000,000+
时程：数周至数个月
Skill 改变了这一点：
Skill：编辑 SKILL.md → 储存 → 下一次调用立即生效
成本：$0
时程：即时
这就是从“训练 AI”到“教育 AI”的典范转移——就像无需训练即可热插拔的 LoRA 适配器。你只要用自然语言编辑 Markdown 档案，模型的行为就会随之改变。
核心公式
好的 Skill = 专家专有知识 − Claude 已经知道的知识
Skill 的价值取决于它的知识增量（knowledge delta）——亦即它所提供的知识与模型既有知识之间的差距。
- 专家专有知识：决策树、权衡取舍（trade-offs）、边缘情况（edge cases）、反模式（anti-patterns）、领域特定的思考框架——这些需要多年经验才能积累的知识
- Claude 已经知道的知识：基础概念、标准函式库用法、常见编程模式、通用最佳实践
当 Skill 在解释“什么是 PDF”或“如何编写 for 循环”时，它只是在压缩 Claude 已经具备的知识。这就是 Token 浪费——Context Window 属于公共资源，是由系统提示词（system prompt）、对话历史、其他 Skill 以及使用者需求共同共享的。
工具 vs Skill
| 概念 | 本质 | 功能 | 范例 |
|---|---|---|---|
| Tool | 模型能做什么 | 执行动作 | bash、read_file、write_file、WebSearch |
| Skill | 模型知道如何做 | 指导决策 | PDF 处理、MCP 建置、前端设计 |
Tool 划定了能力边界——没有 bash 工具，模型就无法执行命令。
Skill 注入了专业知识——没有 frontend-design Skill，模型就会生成平淡无奇的通用 UI。
核心等式：
通用 Agent + 优秀的 Skill = 领域专家 Agent
相同的 Claude 模型，载入不同的 Skill，就会变成不同领域的专家。
Skill 中的三种知识类型
评估时，请将各章节归类：
| 类型 | 定义 | 处理方式 |
|---|---|---|
| 专家级 (Expert) | Claude 确实不知道的内容 | 必须保留——这是 Skill 的核心价值 |
| 激活级 (Activation) | Claude 知道但未必会想到的内容 | 若精简可保留——作为提示与提醒 |
| 冗余级 (Redundant) | Claude 肯定已经知道的内容 | 应该删除——纯粹浪费 Token |
Skill 设计的艺术在于：将专家级内容最大化，谨慎使用激活级内容，并无情地剔除冗余级内容。
评估维度（总分 120 分）
D1：知识增量（20 分）——核心维度
最关键的维度。这个 Skill 是否增加了真正的专家知识？
| 分数 | 标准 |
|---|---|
| 0-5 | 解释 Claude 已经知道的基础（例如什么是 X、如何写程式码、标准函式库教学） |
| 6-10 | 掺杂：包含部分专家知识，但被显而易见的内容稀释 |
| 11-15 | 绝大部分为专家知识，几乎没有冗余内容 |
| 16-20 | 纯粹的知识增量——每一段文字都物有所值（值得所消耗的 Token） |
红旗警讯（出现即扣分至 ≤5 分）：
- “什么是 [基础概念]” 的章节
- 标准操作的按部就班教学
- 解释如何使用常见函式库
- 通用的最佳实践（例如“撰写干净的代码”、“处理错误”）
- 行业标准术语的定义
绿旗指标（高知识增量的特征）：
- 针对非显而易见选择的决策树（例如“当 X 失败时，尝试 Y，因为 Z”）
- 只有专家才知道的权衡取舍（例如“A 速度更快，但 B 能处理边缘情况 C”）
- 来自真实世界实战经验的边缘情况
- “绝不要做 X，因为 [非显而易见的原因]”
- 领域特定的思考框架
评估思考问题：
- 检视每个章节并自问：“Claude 是不是早就知道了？”
- 如果是在解释某件事，自问：“这是在‘向’Claude 解释，还是在‘替’Claude 解释？”
- 统计专家级、激活级与冗余级段落的数量
D2：思维模式 + 必要的领域流程（15 分）
Skill 是否在传授专家思考模式的同时，也提供了必要的领域特定流程？
专家与新手之间的差距不在于“知道如何操作”，而在于“如何思考问题”。然而，当 Claude 缺乏领域特定的流程知识时，仅凭思考模式也是不够的。
关键区别：
| 类型 | 范例 | 价值 |
|---|---|---|
| 思考模式 | “在设计之前先问：是什么让这个设计令人印象深刻？” | 高——塑造决策思维 |
| 领域特定流程 | “OOXML 工作流：解压缩 → 编辑 XML → 验证 → 压缩” | 高——Claude 可能不知道 |
| 通用流程 | “步骤 1：开启档案，步骤 2：编辑，步骤 3：储存” | 低——Claude 已经知道 |
| 分数 | 标准 |
|---|---|
| 0-3 | 仅包含 Claude 已知的通用流程 |
| 4-7 | 包含领域流程，但缺乏思考框架 |
| 8-11 | 良好的平衡：思考模式 + 领域特定工作流 |
| 12-15 | 专家级：既能引导思考，又能提供 Claude 原本不知道的流程 |
算作有价值的流程：
- Claude 未曾接受过训练的工作流（新工具、专有系统）
- 非显而易见的正确顺序（例如“必须在压缩‘之前’进行验证，而不是之后”）
- 容易忽略的关键步骤（例如“编辑后‘必须’重新计算公式”）
- 领域特定的操作步骤（例如 MCP 伺服器的 4 阶段开发流程）
算作冗余的流程：
- 通用的档案操作（开启、读取、写入、储存）
- 标准编程模式（循环、条件式、错误处理）
- 文件健全且通用的函式库用法
专家思考模式范例：
在执行 [动作] 之前，先自问：
- **目的**：这解决了什么问题？谁会使用它？
- **限制**：有哪些隐藏的需求或限制？
- **差异化**：是什么让这个解决方案脱颖而出、令人难忘？
有价值的领域流程范例：
### 红线标记工作流（Claude 不会知道这个顺序）
1. 转为 Markdown：`pandoc --track-changes=all`
2. 将文本映射至 XML：在 document.xml 中 grep 查找文本
3. 以 3-10 个为一组分批套用变更
4. 打包并验证：检查是否所有变更皆已生效
冗余的通用流程范例：
步骤 1：开启档案
步骤 2：找到对应章节
步骤 3：进行修改
步骤 4：储存并测试
测试标准：
- 它是否告诉了 Claude 该思考“什么”？（思考模式）
- 它是否告诉了 Claude 如何去做它原本不知道的事？（领域流程）
好的 Skill 会在需要时同时提供这两者。
D3：反模式质量（15 分）
Skill 是否包含有效的“绝不要做（NEVER）”清单？
为什么这很重要：专家的知识有一半在于知道“不该做什么”。资深设计师看到白色背景配紫色渐层会本能地感到尴尬——“太像 AI 生成的了”。这种对于“绝对不要做什么”的直觉，来自于踩过无数的坑。
Claude 并没有踩过这些坑。它不知道 Inter 字型已经被滥用，也不知道紫色渐层是 AI 生成内容的典型标志。好的 Skill 必须明确指出这些“绝对禁忌”。
| 分数 | 标准 |
|---|---|
| 0-3 | 未提及任何反模式 |
| 4-7 | 通用的警告（例如“避免错误”、“注意边缘情况”、“谨慎处理”） |
| 8-11 | 具体的 NEVER 清单，并附带部分原因 |
| 12-15 | 专家级反模式并解释“为什么”——这些都是只有靠实战经验才能获得的教训 |
专家级反模式（具体 + 解释原因）：
绝不要使用常见且平庸的 AI 生成美学，例如：
- 滥用的字型系列（Inter、Roboto、Arial）
- 陈词滥调的配色方案（特别是白色背景配紫色渐层）
- 可预测的版面配置与元件模式
- 替所有元素加上预设的 border-radius
弱反模式（模糊、无原因）：
避免犯错。
注意处理边缘情况。
不要写糟糕的代码。
测试标准：专家看到这个反模式清单时，会说是“对，这是我吃过亏才学到的教训”？还是会说“这不是大家早就知道的废话吗”？
D4：规范合规性——特别是 Description（15 分）
Skill 是否遵循官方格式要求？特别关注 Description 的品质。
| 分数 | 标准 |
|---|---|
| 0-5 | 缺少 frontmatter 或格式无效 |
| 6-10 | 包含 frontmatter，但 description 模糊或不完整 |
| 11-13 | frontmatter 有效，description 包含“做什么”，但在“何时使用”上偏弱 |
| 14-15 | 完美：完整的 description，包含“做什么”、“何时使用”以及触发关键字 |
Frontmatter 要求：
name：全小写，仅限英数字 + 连字号（-），≤64 个字元description：最关键的字段——决定了 Skill 是否会被激活使用
为什么 Description 是最关键的字段：
┌─────────────────────────────────────────────────────────────────────┐
│ SKILL 激活流程 │
│ │
│ 使用者请求 → Agent 检视“所有”Skill 的 description → 决定激活哪一个 │
│ （仅检视 description，不包含正文！） │
│ │
│ 若 description 不吻合 → Skill 永远不会被载入 │
│ 若 description 很模糊 → Skill 可能无法在需要时被触发 │
│ 若 description 缺少关键字 → Agent 视此 Skill 为“不可见” │
└─────────────────────────────────────────────────────────────────────┘
残酷的现实：一个正文完美但 description 写得很差的 Skill 是毫无用处的——它永远不会被激活。description 是告诉 Agent “请在这些情况下使用我” 的唯一机会。
Description 必须回答三个问题：
- 做什么（WHAT）：这个 Skill 的功能是什么？（功能性）
- 何时使用（WHEN）：在什么情况下应该使用它？（触发场景）
- 关键字（KEYWORDS）：哪些词汇应该触发这个 Skill？（可搜寻的术语）
优秀的 Description（包含这三个要素）：
description: "完整的文件建立、编辑与分析，支持追踪修订、批注、版面格式保留与文字提取。
当 Claude 需要处理专业的文档（.docx 档案）以进行：
(1) 建立新文件、(2) 修改或编辑内容、
(3) 处理追踪修订、(4) 新增批注，或任何其他文件任务时使用"
解析：
- 做什么：建立、编辑、分析、追踪修订、批注
- 何时使用：“当 Claude 需要处理...以进行：(1)... (2)... (3)...”
- 关键字：.docx 档案、追踪修订、专业文档
差劲的 Description（缺少要素）：
description: "处理文档相关功能"
问题：
- 做什么：模糊（“文档相关功能”——具体是什么？）
- 何时使用：缺失（Agent 什么时候该用它？）
- 关键字：缺失（没有 ".docx"，没有具体场景）
另一个差劲的范例：
description: "A helpful skill for various tasks"
这完全没用——Agent 根本不知道什么时候该激活它。
Description 品質检查清单：
- [ ] 列出了具体的技能与功能（而不只是“协助处理 X”）
- [ ] 包含了明确的触发场景（“在...时使用”、“当使用者要求...时”）
- [ ] 包含了可搜寻的关键字（副档名、领域术语、动作动词）
- [ ] 足够具体，使 Agent 能“确切”知道何时该使用它
- [ ] 包含了“必须”使用此 Skill 的场景（而不只是“可以使用”）
D5：渐进式揭露（15 分）
Skill 是否实现了适当的内容分层架构？
Skill 载入分为三个层级：
第 1 层：元资料（常驻于内存中）
仅包含 name + description
