如何评价AI技能

本文翻译自 https://github.com/shareAI-lab/shareAI-skills，他们编写了很重要的评价框架

什么是技能？

技能不是教程。技能是一种知识外化机制。

传统人工智能知识被锁定在模型参数中。要教授新的能力：

Traditional: Collect data → GPU cluster → Train → Deploy new versionCost: $10,000 - $1,000,000+Timeline: Weeks to months

技能会改变这一切：

Skill: Edit SKILL.md → Save → Takes effect on next invocationCost: $0Timeline: Instant

这是从“训练人工智能”到“教育人工智能”的范式转变——就像一个无需训练的热插拔LoRa适配器。你只需用自然语言编辑Markdown文件，模型的行为就会随之改变。

核心公式

优秀技能 = 专家级知识 - 克劳德已有的知识

技能的价值是通过其知识增量来衡量的——即它所提供的知识与模型已有的知识之间的差距。

• 专家专属知识：决策树、权衡取舍、边缘案例、反模式、领域特定思维框架——这些都需要多年的经验积累才能获得。
• Claude 已掌握的知识：基本概念、标准库用法、常见编程模式、通用最佳实践

当一项技能解释“什么是PDF”或“如何编写for循环”时，它实际上是在压缩Claude已经掌握的知识。这是一种资源浪费——上下文窗口是一种公共资源，它与系统提示、对话历史记录、其他技能和用户请求共享。

工具与技能

工具定义了能力边界——如果没有 bash 工具，模型就无法执行命令。技能注入知识——如果没有前端设计技能，模型只能生成通用的用户界面。

等式：

General Agent + Excellent Skill = Domain Expert Agent

同一个克劳德模型，加载不同的技能，就能成为不同的专家。

技能中的三种知识类型

评估时，请对每个部分进行分类：

技能设计的艺术在于最大限度地发挥专家级内容，谨慎使用激活，并毫不留情地消除冗余。

评估维度（总分120分）

D1：知识差值（20 分）——核心维度

最重要的维度：这项技能是否能带来真正的专业知识？

危险信号（即时得分≤5）：

• “什么是[基本概念]”部分
• 标准操作的分步教程
• 解释如何使用常用库
• 通用最佳实践（“编写简洁的代码”、“处理错误”）
• 行业标准术语的定义

绿色标志（表明知识差距较大）：

• 针对非显而易见的选择的决策树（“当 X 失败时，尝试 Y，因为 Z”）
• 只有专家才知道的权衡取舍（“A 速度更快，但 B 可以处理极端情况 C”）。
• 来自真实世界经验的极端案例
• “永远不要做X，因为[原因不明显]”
• 领域特定思维框架

评估问题：

1. 对于每个部分，都要问：“克劳德已经知道这些内容了吗？”
2. 如果要解释某事，请问：“这是在向克劳德解释，还是在替克劳德解释？”
3. 统计专家级段落、激活级段落和冗余段落的数量

D2：心态 + 适当的程序（15 分）

该技能是否能将专家思维模式与必要的领域特定流程相结合？

专家和新手之间的区别不在于“如何操作”，而在于“如何思考问题”。但当克劳德缺乏特定领域的程序性知识时，仅仅依靠思维模式是不够的。

主要区别：

哪些程序才算有价值：

• 克劳德没有接受过相关工作流程（新工具、专有系统）的培训。
• 正确的排序方式，即使它并不显而易见（例如，“在包装前进行验证，而不是包装后”）。
• 容易被忽略的关键步骤（例如，“编辑后必须重新计算公式”）
• 特定领域序列（例如，MCP 服务器的 4 阶段开发过程）

哪些程序属于冗余程序：

• 通用文件操作（打开、读取、写入、保存）
• 标准编程模式（循环、条件语句、错误处理）
• 常用且文档齐全的库用法

专家的思维模式如下：

Before [action], ask yourself:-**Purpose**: What problem does this solve? Who uses it?-**Constraints**: What are the hidden requirements?-**Differentiation**: What makes this solution memorable?

有价值的域过程如下所示：

### Redlining Workflow (Claude wouldn't know this sequence)1. Convert to markdown: `pandoc --track-changes=all`2. Map text to XML: grep for text in document.xml3. Implement changes in batches of 3-104. Pack and verify: check ALL changes were applied

冗余的通用程序如下所示：

Step 1: Open the file Step 2: Find the section Step 3: Make the change Step 4: Save and test

测试：

1. 它告诉克劳德应该想什么吗？（思维模式）
2. 它是否告诉克劳德如何去做它原本不知道的事情？（领域程序）

优秀的技能可以在需要时提供这两者。

D3：反模式质量（15分）

该技能是否有有效的“绝对禁止事项”清单？

为什么这很重要：专家知识的一半在于知道什么不该做。一位资深设计师看到白色背景上的紫色渐变会本能地感到不适——“太像人工智能生成的了”。这种“绝对不能做什么”的直觉来自于无数次踩到雷区的经验。

克劳德还没踩到这些雷区。它不知道Inter字体被滥用了，也不知道紫色渐变是人工智能生成内容的标志。优秀的技能必须明确列出这些“绝对禁忌”。

专家级反模式（具体+原因）：

NEVER use generic AI-generated aesthetics like:- Overused font families (Inter, Roboto, Arial)- Cliched color schemes (particularly purple gradients on white backgrounds)- Predictable layouts and component patterns- Default border-radius on everything

弱反模式（模糊不清，缺乏逻辑）：

Avoid making mistakes. Be careful with edge cases. Don't write bad code.

测试：专家阅读反模式列表后会说“是的，我以前也吃过亏才学到这一点”吗？还是会说“这对每个人来说都是显而易见的”？

D4：规范符合性——尤其体现在描述方面（15 分）

该技能是否符合官方格式要求？请特别关注描述质量。

Frontmatter 要求：

• name：仅限小写字母、字母数字组合及连字符，长度≤64个字符
• description最关键的领域——决定技能是否能得到运用。

为什么描述是最重要的字段：

┌─────────────────────────────────────────────────────────────────────┐│  SKILL ACTIVATION FLOW                                              ││                                                                     ││  User Request → Agent sees ALL skill descriptions → Decides which  ││                 (only descriptions, not bodies!)     to activate    ││                                                                     ││  If description doesn't match → Skill NEVER gets loaded            ││  If description is vague → Skill might not trigger when it should  ││  If description lacks keywords → Skill is invisible to the Agent   │└─────────────────────────────────────────────────────────────────────┘

残酷的现实是：技能内容完美但描述糟糕是毫无用处的——它永远不会被激活。描述是唯一能告诉特工“在这些情况下使用我”的机会。

描述必须回答三个问题：

1. 功能：这项技能的作用是什么？（功能性）
2. 何时使用：在哪些情况下应该使用？（触发场景）
3. 关键词：哪些词语应该触发此技能？（可搜索词语）

描述非常出色（涵盖所有三个要素）：

description: "Comprehensive document creation, editing, and analysis with supportfor tracked changes, comments, formatting preservation, and text extraction.When Claude needs to work with professional documents (.docx files) for:(1) Creating new documents, (2) Modifying or editing content,(3) Working with tracked changes, (4) Adding comments, or any other document tasks"

分析：

• 内容：创建、编辑、分析、跟踪更改、评论
• 时间：“当克劳德需要与……合作时：（1）……（2）……（3）……”
• 关键词：.docx 文件、修订痕迹、专业文档

描述不完整（缺少要素）：

description: "处理文档相关功能"

问题：

• 什么：模糊（“文档相关功能”——具体是什么？）
• 何时：缺失（代理何时应该使用此功能？）
• 关键词：缺失（无“.docx”文件，无具体场景）

另一个糟糕的例子：

description: "A helpful skill for various tasks"

这没用——代理根本不知道何时激活它。

描述质量检查清单：

• 列出具体功能（而不仅仅是“有助于X”）
• 包含明确的触发场景（“当……时使用”、“当用户请求时……”）
• 包含可搜索的关键词（文件扩展名、域名、动作动词）
• 具体到足以让代理人确切地知道何时使用它
• 包括必须使用此技能的场景（而不仅仅是“可以使用”）。

D5：逐步披露（15 分）

该技能是否实现了适当的内容分层？

技能负荷分为三个层次：

Layer 1: Metadata (always in memory)         Only name + description         ~100 tokens per skillLayer 2: SKILL.md Body (loaded after triggering)         Detailed guidelines, code examples, decision trees         Ideal: < 500 linesLayer 3: Resources (loaded on demand)         scripts/, references/, assets/         No limit

对于包含参考目录的技能，请检查“加载触发器质量”：

加载问题：

Loading too little ◄─────────────────────────────────► Loading too much- References sit unused                    - Wastes context space- Agent doesn't know when to load          - Irrelevant info dilutes key content- Knowledge is there but never accessed    - Unnecessary token overhead

良好的加载触发器（嵌入工作流程中）：

### Creating New Document**MANDATORY - READ ENTIRE FILE**: Before proceeding, you MUST read[`docx-js.md`](docx-js.md) (~500 lines) completely from start to finish.**NEVER set any range limits when reading this file.****Do NOT load**`ooxml.md` or `redlining.md` for this task.

错误的加载触发器（仅列出）：

## References- docx-js.md - for creating documents- ooxml.md - for editing- redlining.md - for tracking changes

对于简单的技能（无参考文献，<100 行）：根据简洁性和自洽性评分。

D6：自由度校准（15 分）

这种具体程度是否与任务的复杂性相符？

不同的任务需要不同程度的限制。这关乎自由与脆弱性的平衡。

自由光谱：

高度自由（基于文本的指令）：

Commit to a BOLD aesthetic direction. Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic natural...

中等自由度（伪代码或参数化）：

Review priority:1. Security vulnerabilities (must fix)2. Logic errors (must fix)3. Performance issues (should fix)4. Maintainability (optional)

自由度低（特定脚本，精确步骤）：

**MANDATORY**: Use exact script in `scripts/create-doc.py`Parameters: --title "X" --author "Y" Do NOT modify the script.

测试：询问“如果代理人犯了错误，后果是什么？”

• 高后果 → 低自由
• 低后果 → 高自由

D7：模式识别（10分）

该技能是否遵循既定的官方模式？

通过分析 17 项官方技能，我们总结出了 5 种主要设计模式：

图案选择指南：

D8：实际可用性（15 分）

特工真的能有效运用这项技能吗？

检查以下内容：

• 决策树：对于多路径场景，是否有明确的指导方针来决定采取哪条路径？
• 代码示例：它们真的能运行吗？还是只是会出错的伪代码？
• 错误处理：如果主要方法失败怎么办？是否有备用方案？
• 特殊情况：是否涵盖了不常见但实际存在的情况？
• 可操作性：代理人能否立即采取行动，还是需要弄清楚情况？

良好的可用性（决策树+备选方案）：

| Task | Primary Tool | Fallback | When to Use Fallback ||------|-------------|----------|----------------------|| Read text | pdftotext | PyMuPDF | Need layout info || Extract tables | camelot-py | tabula-py | camelot fails |**Common issues**:- Scanned PDF: pdftotext returns blank → Use OCR first- Encrypted PDF: Permission error → Use PyMuPDF with password

可用性差（模糊不清）：

Use appropriate tools for PDF processing. Handle errors properly. Consider edge cases.

评估时绝对不要这样做

• 千万不要仅仅因为作品“看起来很专业”或格式良好就给出高分。
• 绝不可忽视冗余段落——每个多余的段落都应扣分。
• 永远不要被长度所迷惑——一个43行的技能动画可能比一个500行的技能动画效果更好。
• 永远不要跳过对决策树进行心理测试——它们真的能得出正确的选择吗？
• 永远不要用“但这能提供有用的背景信息”来解释基础知识。
• 永远不要忽视遗漏的反模式——如果没有一份“绝不容许发生的情况”清单，那将是一个重大缺陷。
• 切勿想当然地认为所有程序都有价值——要区分特定领域的程序和通用程序。
• 千万不要低估描述字段的重要性——描述不好，技能就永远用不上。
• 切勿仅在请求体中放置“何时使用”信息——代理程序在加载前只能看到描述。

评估方案

步骤 1：初筛——知识差值扫描

请完整阅读 SKILL.md 文件，并针对每个部分提出以下问题：

“克劳德已经知道这件事了吗？”

将每个部分标记为：

• [E] 专家：克劳德确实不知道这一点——增值
• [A] 激活：克劳德知道，但简短提醒一下还是有用的——可以接受
• [R] 冗余：克劳德肯定知道这一点——应该删除

计算粗略比率：E:A:R

• 优秀技能：>70% 精通，<20% 激活，<10% 冗余
• 中等技能：40-70% 专家级，高激活率
• 低技能：<40% 专家级，高度冗余

步骤二：结构分析

[ ] Check frontmatter validity[ ] Count total lines in SKILL.md[ ] List all reference files and their sizes[ ] Identify which pattern the Skill follows[ ] Check for loading triggers (if references exist)

步骤 3：对每个维度进行评分

针对以下8个维度中的每一个：

1. 找到具体证据（引用相关语句）
2. 用一行文字说明评分
3. 如果分数低于最高分，请记录具体的改进情况。

第四步：计算总分和成绩

Total = D1 + D2 + D3 + D4 + D5 + D6 + D7 + D8Max = 120 points

评分标准（百分制）：

步骤 5：生成报告

# Skill Evaluation Report: [Skill Name]## Summary-**Total Score**: X/120 (X%)-**Grade**: [A/B/C/D/F]-**Pattern**: [Mindset/Navigation/Philosophy/Process/Tool]-**Knowledge Ratio**: E:A:R = X:Y:Z-**Verdict**: [One sentence assessment]## Dimension Scores| Dimension | Score | Max | Notes ||-----------|-------|-----|-------|| D1: Knowledge Delta | X | 20 ||| D2: Mindset vs Mechanics | X | 15 ||| D3: Anti-Pattern Quality | X | 15 ||| D4: Specification Compliance | X | 15 ||| D5: Progressive Disclosure | X | 15 ||| D6: Freedom Calibration | X | 15 ||| D7: Pattern Recognition | X | 10 ||| D8: Practical Usability | X | 15 ||## Critical Issues[List must-fix problems that significantly impact the Skill's effectiveness]## Top 3 Improvements1.[Highest impact improvement with specific guidance]2.[Second priority improvement]3.[Third priority improvement]## Detailed Analysis[For each dimension scoring below 80%, provide:- What's missing or problematic- Specific examples from the Skill- Concrete suggestions for improvement]

常见故障模式

模式 1：教程

Symptom: Explains what PDF is, how Python works, basic library usageRoot cause: Author assumes Skill should "teach" the modelFix: Claude already knows this. Delete all basic explanations.     Focus on expert decisions, trade-offs, and anti-patterns.

模式二：垃圾场

Symptom: SKILL.md is 800+ lines with everything includedRoot cause: No progressive disclosure designFix: Core routing and decision trees in SKILL.md (<300 lines ideal)     Detailed content in references/, loaded on-demand

模式 3：孤立引用

Symptom: References directory exists but files are never loadedRoot cause: No explicit loading triggersFix: Add "MANDATORY - READ ENTIRE FILE" at workflow decision points     Add "Do NOT Load" to prevent over-loading

模式 4：复选框程序

Symptom: Step 1, Step 2, Step 3... mechanical proceduresRoot cause: Author thinks in procedures, not thinking frameworksFix: Transform into "Before doing X, ask yourself..."     Focus on decision principles, not operation sequences

模式五：模糊的警告

Symptom: "Be careful", "avoid errors", "consider edge cases"Root cause: Author knows things can go wrong but hasn't articulated specificsFix: Specific NEVER list with concrete examples and non-obvious reasons     "NEVER use X because [specific problem that takes experience to learn]"

模式六：隐形技能

Symptom: Great content but skill rarely gets activatedRoot cause: Description is vague, missing keywords, or lacks trigger scenariosFix: Description must answer WHAT, WHEN, and include KEYWORDS     "Use when..." + specific scenarios + searchable termsExample fix:BAD:  "Helps with document tasks"GOOD: "Create, edit, and analyze .docx files. Use when working with       Word documents, tracked changes, or professional document formatting."

模式七：位置错误

Symptom: "When to use this Skill" section in body, not in descriptionRoot cause: Misunderstanding of three-layer loadingFix: Move all triggering information to description field     Body is only loaded AFTER triggering decision is made

模式 8：过度设计

Symptom: README.md, CHANGELOG.md, INSTALLATION_GUIDE.md, CONTRIBUTING.mdRoot cause: Treating Skill like a software projectFix: Delete all auxiliary files. Only include what Agent needs for the task.     No documentation about the Skill itself.

模式 9：自由错配

Symptom: Rigid scripts for creative tasks, vague guidance for fragile operationsRoot cause: Not considering task fragilityFix: High freedom for creative (principles, not steps)     Low freedom for fragile (exact scripts, no parameters)

快速参考清单

┌─────────────────────────────────────────────────────────────────────────┐│  SKILL EVALUATION QUICK CHECK                                           │├─────────────────────────────────────────────────────────────────────────┤│                                                                         ││  KNOWLEDGE DELTA (most important):                                      ││    [ ] No "What is X" explanations for basic concepts                   ││    [ ] No step-by-step tutorials for standard operations                ││    [ ] Has decision trees for non-obvious choices                       ││    [ ] Has trade-offs only experts would know                           ││    [ ] Has edge cases from real-world experience                        ││                                                                         ││  MINDSET + PROCEDURES:                                                  ││    [ ] Transfers thinking patterns (how to think about problems)        ││    [ ] Has "Before doing X, ask yourself..." frameworks                 ││    [ ] Includes domain-specific procedures Claude wouldn't know         ││    [ ] Distinguishes valuable procedures from generic ones              ││                                                                         ││  ANTI-PATTERNS:                                                         ││    [ ] Has explicit NEVER list                                          ││    [ ] Anti-patterns are specific, not vague                            ││    [ ] Includes WHY (non-obvious reasons)                               ││                                                                         ││  SPECIFICATION (description is critical!):                              ││    [ ] Valid YAML frontmatter                                           ││    [ ] name: lowercase, ≤64 chars                                       ││    [ ] description answers: WHAT does it do?                            ││    [ ] description answers: WHEN should it be used?                     ││    [ ] description contains trigger KEYWORDS                            ││    [ ] description is specific enough for Agent to know when to use     ││                                                                         ││  STRUCTURE:                                                             ││    [ ] SKILL.md < 500 lines (ideal < 300)                               ││    [ ] Heavy content in references/                                     ││    [ ] Loading triggers embedded in workflow                            ││    [ ] Has "Do NOT Load" for preventing over-loading                    ││                                                                         ││  FREEDOM:                                                               ││    [ ] Creative tasks → High freedom (principles)                       ││    [ ] Fragile operations → Low freedom (exact scripts)                 ││                                                                         ││  USABILITY:                                                             ││    [ ] Decision trees for multi-path scenarios                          ││    [ ] Working code examples                                            ││    [ ] Error handling and fallbacks                                     ││    [ ] Edge cases covered                                               ││                                                                         │└─────────────────────────────────────────────────────────────────────────┘

元问题

在评估任何技能时，始终要回到这个基本问题：

“该领域的专家在看到这项技能时，会说：‘是的，这涵盖了我花了多年时间才学到的知识’吗？”

如果答案是肯定的 → 该技能具有真正的价值。如果答案是否定的 → 它只是对克劳德已有知识的压缩。

最好的技能是浓缩的专家智慧——他们将设计师 10 年的审美积累浓缩成 43 行，或者将文档专家的操作经验浓缩成 200 行的决策树。

被压缩的必须是克劳德没有的东西。否则，压缩就是无用的。

自我评估表

这项技能（技能评判员）本身应该通过评估：

• 知识增量：提供克劳德自己无法生成的具体评估标准。
• 思维模式：影响人们对技能质量的思考方式，而不仅仅是对清单项目的思考。
• 反模式：“评估时绝对不要这样做”部分列出了具体的禁忌事项
• 规范：包含完整描述的有效前言。
• 渐进式披露：独立完整，无需外部参考资料
• 自由度：中等自由度，适合评估任务
• 模式：遵循工具模式，并采用决策框架
• 易用性：清晰的流程、报告模板、快速参考

将这项技能与自身进行比较评估，作为一项校准练习。