Skill的形态有哪些？什么样的Skill 叫做好Skill？

每个人都知道Skill 的渐进式披露（Progressive Disclosure） 特性，根据此特性演进为各种规范、各种工作流。而它的物理形态其实极其朴素------它就是一个平平常常的文件夹，是一个非常灵活的文件组织结构。

这是我佩服的地方，也是我接下来研究的地方。

既然 Skill 本质上只是一个自由度很高的文件夹，那它在现实代码库里到底会演化成哪些形态？

我们不用那些晦涩的学术词汇，从工程师日常开发的视角来看，它主要有下面五种非常通俗的形态。

形态一：纯文档与规范型（Pure Prompt & Style Guide）

这是最基础、也是最纯粹的形态。文件夹里通常只有一份 SKILL.md，没有任何可执行代码，也不依赖任何外部工具。

它的目的不是教大模型做什么计算，而是给大模型立规矩，统一审美与边界。比如团队代码规范、文档排版风格、或是某种特定的架构思考框架。

开源社区里一个非常典型的代表，就是 multica-ai/andrej-karpathy-skills。

前 OpenAI 联合创始人 Andrej Karpathy 平时写代码的极简哲学整理成了一个 Skill。它里面没有任何复杂的代码逻辑，就是一个简单的文件夹：

objectivec 复制代码

andrej-karpathy-skills/
├── README.md
└── SKILL.md

它的核心就是一份结构化的 Markdown，直接给大模型注入心智模型（此处将英文 Prompt 译为中文）：

yaml 复制代码

---
name: karpathy-coding-style
description: 应用 Andrej Karpathy 的极简编码风格、规范的 PyTorch 习惯以及零冗余思维。
---
# 核心指令（译文备忘）
- 优先考虑代码的可读性与极简性，绝不堆砌无谓的抽象层。
- 编写扁平、直观易读的 Python 代码，避免繁琐的多余面向对象（OOP）样板代码。
- 坚决避免过早优化和过度设计的复杂设计模式。

大模型本身早就会写 Python，但它默认喜欢写各种深层嵌套和过度设计的类。这份纯文档 Skill 就像一张放在显示器旁边的便签纸，时时刻刻提醒它"保持精简，不要过度封装"。

形态二：文档 + 脚本工具包（Prompt + Scripts）

当单纯靠文字说教搞不定的时候，文件夹里就会多出一个 scripts/ 目录，这就是第二种形态。

大模型本质上是一个概率预测模型，它擅长理解人类意图、梳理逻辑，但在做精确代数计算、复杂正则提取、或解析特定二进制文件时，极容易产生幻觉或计算缓慢。

这时候，把确定性的脏活累活下沉为本地脚本，是最好的解法。

css 复制代码

pdf-table-extractor/
├── SKILL.md
└── scripts/
    └── extract_tables.py

在 SKILL.md 里，我们只需要告诉大模型脚本的用途与命令行参数格式：

markdown 复制代码

# PDF 表格提取器（使用指南）

当用户要求从 PDF 文件中提取财务报表时：
1. 运行本地提取脚本：
   `python scripts/extract_tables.py --input <pdf文件路径> --format json`
2. 解析脚本输出的 JSON 数据，核对表格行级借贷平衡，并提炼核心结论汇报给用户。

大模型负责理解用户的要求、拼装调用命令、解释最终输出；脚本负责执行确定性的底层操作。这就是"大模型的脑 + 本地脚本的手"。

形态三：按需加载的查阅手册（Secondary Disclosure）

如果你要把整个云厂商的运维手册、或者一整套企业财务结算准则交给大模型，全写进一个 SKILL.md，文档又会重新变得又臭又长。

这时，文件夹的分层目录就成了天然的路由器。主文件 SKILL.md 只写概览和目录索引，具体的技术细节下沉到 references/ 目录：

markdown 复制代码

cloud-deploy/
├── SKILL.md
└── references/
    ├── aws.md
    ├── gcp.md
    └── azure.md

在主文档里，通过明确的链接指引大模型何时去按需读取：

markdown 复制代码

# 云端部署路由总览

## 可用云平台参考文档（按需加载）
- **AWS 部署**：涉及 ECS 容器、Lambda 函数或 S3 存储部署 → 查阅 [references/aws.md](references/aws.md)
- **GCP 部署**：涉及 Cloud Run 或 GKE 集群部署 → 查阅 [references/gcp.md](references/gcp.md)
- **Azure 部署**：涉及 App Services 或 AKS 部署 → 查阅 [references/azure.md](references/azure.md)

当用户询问"怎么在 AWS 上部署容器"时，大模型先读主干，发现属于 AWS 范畴，才会调用文件读取工具打开 references/aws.md。这种在渐进式披露之上的"二次披露"，使得即便利纳几万字的专业文档，常驻的上下文依然保持轻盈。

形态四：分步流水线与状态机（Workflow & Pipeline）

很多复杂的工程问题，不能指望大模型一拍脑袋一次性输出最终结果。

比如软件工程中开发一个复杂功能，通常必须遵循严格的顺序：先写需求规格（Spec），基于需求推导技术方案（Plan），将方案拆解为依赖有序的任务清单（Tasks），最后才进入具体编码（Implement）。

流水线型 Skill 就像一个状态机，严格控制研发步骤与产物交付：

markdown 复制代码

feature-workflow/
├── SKILL.md
└── references/
    ├── spec_template.md
    ├── plan_template.md
    └── tasks_template.md

它的核心 Prompt 会明确规定前置依赖门禁：

markdown 复制代码

# 需求实施流水线

1. **第一阶段：需求规格（Specification）**
   - 梳理用户真实意图，生成需求规格文档 `spec.md`。
   - 【停下确认】必须等待用户明确确认批准后，方可进入第二阶段。
2. **第二阶段：技术规划（Planning）**
   - 细读 `spec.md`，推导技术方案文档 `plan.md`。
   - 在此规划阶段，严禁编写任何生产环境代码。
3. **第三阶段：任务执行（Execution）**
   - 严格按顺序逐项执行 `tasks.md` 中的任务，每完成一项必须立即进行自测验证。

它用硬性的流程步骤，管住了大模型容易急于求成、未经规划就乱敲代码的冒进行为。

形态五：多 Agent 协作分工（Subagent Delegation）

当工程复杂度进一步上升，单个上下文窗口无论如何都会被日志和排查过程撑爆时，Skill 就变成了"指挥官"。

主 Skill 不直接下场翻找每一行代码，而是通过调度专门的子智能体（Subagent）分头作业。比如一个子智能体负责以只读模式在代码库里 grep 和搜索历史背景，另一个子智能体专门负责跑单测和看堆栈。

主流程仅负责拆解子任务、唤起子智能体、并在子智能体汇报结论后做出全局决策，以此保持主对话环境的绝对纯净。

弄清楚了 Skill 的五种基本形态，下一个关键问题就来了：什么样的 Skill 才算是一个优秀的 Skill？

这个标准不能凭空捏造。如果我们去深入分析 Anthropic 官方开源的知名工具库 anthropics/skills/tree/main/skills/skill-creator，去翻阅它的核心代码与设计文档，就能清晰地提炼出真正工业级的好 Skill 必须具备的五个核心标准。

标准一：严格把控的三级上下文经济学

在 skill-creator 的官方设计指南中，明确写着这样一段加载规范（原文档译文）：

markdown 复制代码

Skill 采用三级渐进式加载架构：
1. 元数据层（名称 name + 描述 description）：始终常驻上下文（约 100 词）
2. 正文主体层（SKILL.md 正文）：仅在技能被触发时载入（理想少于 500 行）
3. 扩展资源层（外部脚本与参考手册）：完全按需加载（资源大小不受限，脚本可直接运行无需全量注入上下文）

官方把这个标准量化得非常具体：

常驻在模型上下文中的元数据（Name 和 Description），必须高度凝练，控制在 100 词左右；
Skill 触发后载入的主体正文，理想长度应该小于 500 行；
如果内容超过 500 行，官方建议坚决建立下一级目录（references/），并在大于 300 行的参考文档顶部提供目录索引（TOC）。

一个优秀 Skill 的首要修养，就是对大模型上下文的极度吝啬与克制。

标准二：路标精准，且带有对抗懒惰的"推力"描述（Pushy Description）

在大模型驱动的系统里，description 就像挂在门外的招牌。模型进不进这个房间，完全取决于招牌怎么写。

在 skill-creator 的说明文档中，官方专门提醒开发者注意一个大模型的天然缺陷：

"注意：目前 Claude 往往存在'漏触发'（undertrigger）技能的倾向------在明明很有用的时候却想不到去调用。为了对抗这种懒惰，请在编写技能描述时让语气'更具推动力'一点（a little bit pushy）。"

因为大模型往往更倾向于依赖自身预训练的常识去敷衍回答，导致很多好用的 Skill 经常被漏触发。

官方给出了非常生动的正反例子：如果你的 Skill 是做内部数据看板的，如果你只写"用于构建展示内部数据的快速看板"，模型经常会视而不见；

一个优秀的 Description 必须带有一点"推力"，指明具体的触发上下文（官方示范译文）：

yaml 复制代码

# 官方示范：极具推力的 Description 描述写法（已译为中文备忘）
description: 用于构建快速展示内部数据的看板。务必牢记：只要用户提到仪表盘、数据可视化、内部指标，或表达了想要展示任何公司业务数据的意图时，哪怕用户没有显式说出"dashboard"这个词，也必须立即调用此技能。（原文：Make sure to use this skill whenever the user mentions dashboards... even if they don't explicitly ask for a 'dashboard.'）

好 Skill 的路标不仅要写明"能做什么"，更要清清楚楚地指出"在什么场景、遇到什么关键词时必须启用它"。

标准三：自由度与任务特征的精准匹配（Matching Degrees of Freedom）

在 skill-creator 的编写指南中，提到了一个非常高级的工程哲学：不要无脑堆砌大写的 MUST 和死板要求：

"尝试向模型解释'为什么这件事很重要'，而不是一味生硬地堆砌大写的 MUST；运用心智模型，尽量让技能具备通用概括性，而不是死板地局限于具体个例。"

对于需要大模型发挥创造力、权衡利弊的任务（比如架构设计、风格润色），要给予高自由度，告诉它背后的原理和权衡逻辑，让它自行判断；

但对于严谨的输出格式契约（比如测试报告、Commit 规范），skill-creator 又会给出毫不含糊的死规约：

markdown 复制代码

## 报告产出结构（严格格式契约示例）
必须且始终严格使用以下模版结构输出：
# [报告标题]
## 执行摘要（Executive summary）
## 核心发现（Key findings）
## 行动建议（Recommendations）

该放权的地方给足推理空间，该收紧的地方给出绝对模板，这才是成熟的工程分寸感。

标准四：把确定性交给代码，不让模型用概率猜（Scripts vs Prompts）

在 skill-creator 的自动化评测流程中，有这样一处很值得深思的工程细节：

"凡是可以通过编程方式校验的断言，务必编写并运行脚本来检查，绝不要凭肉眼扫视或靠模型盲猜------脚本速度更快、结果更可靠，而且可以在多次迭代中持续复用。"

很多人沉迷于用几百字的自然语言去命令大模型做正则提取、浮点数校验、数组排序，这在工程上是极不划算的。

好的 Skill 一定会在需要精确计算、格式转换、API 轮询的地方，果断放上一段 Python 或 Shell 脚本。让脚本负责确定性，让模型负责理解意图。能用 10 行脚本解决的事情，坚决不浪费一个 Token 让大模型用概率去碰运气。

标准五：评测驱动与闭环生长（Eval-Driven Iteration）

一个好的 Skill 绝不是在键盘前凭感觉一次性敲出来的，这也是 skill-creator 整个项目的核心灵魂。

在 skill-creator 的工作流里，写完 SKILL.md 初稿只是第一步，紧接着必须配套准备真实用户会提问的测试用例集（evals/evals.json）：

json 复制代码

{
  "skill_name": "示例技能名称",
  "evals": [
    {
      "id": 1,
      "prompt": "真实用户的提问提示词（例如：请提取本季度的 ARR 数据）",
      "expected_output": "预期输出结果的明确描述与断言标准"
    }
  ]
}

随后，系统会同时启动两组运行（一组加载当前 Skill，一组作为对照 baseline），由评测脚本计算通过率、Token 开销与耗时，生成 benchmark.json，并调用 eval-viewer/generate_review.py 提供可视化的前后对比复盘。

当大模型在实际运行中翻车时，把那个翻车的 Query 沉淀为一条新的评测用例，倒逼 Skill 文档修改与迭代。拥有这种基于真实缺陷反哺、持续演进的评测机制，一个 Skill 才能真正走出玩具阶段，具备工业级的可靠性。

回过头来看，Skill 之所以展现出如此旺盛的生命力，恰恰就在于它那种极其简朴的物理结构。

一个简简单单的文件夹，可以只是一张轻巧的行为规范便签，也可以是一套由脚本、手册、多智能体协同驱动的复杂系统。它没有把开发者捆绑在某种厚重晦涩的私有框架里，而是用最符合 Unix 哲学的平铺文件，赋予了我们自由创造的无限可能。

把自然语言的理解力与现代软件工程的严密性结合在一起，用清晰的轨道引导大模型释放潜能，这大概就是今天我们用自然语言和工程化手段与 AI 沟通的最大魅力所在。

Skill的形态有哪些？什么样的Skill 叫做好Skill？

推荐资料