这是本系列第 8 轮，也是收官性的方法论一轮：不再横向评 Skill，而是从当前 Skills 生态中最热门的几个代表——官方 skill-creator、市场头部的内容创作类与浏览器操控类 Skill、以及本周新榜上的垂直件——提炼 SKILL.md 的写作模式。核心发现有三：其一，热门 Skill 的 SKILL.md 高度收敛于「触发描述→核心流程→资源披露→边界声明」四段式；其二，头部 Skill 普遍采用“渐进披露”架构，把 SKILL.md 压到 100 行以内，把重货放脚本与参考文件；其三，触发描述是整个 Skill 的“API 签名”，写错一个词就难以被召回。本文给出 6 个可直接套用的模式，并手把手教你写第一个 Skill。
| Skill | 来源 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度 | 加权 |
|---|---|---|---|---|---|---|---|
| skill-creator（官方） | anthropics/skills | ★★★★★ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★★ | 4.8 |
| frontend-design（官方） | anthropics/skills | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★☆ | 4.6 |
| pdf（官方） | anthropics/skills | ★★★★★ | ★★★★☆ | ★★★★★ | ★★★★★ | ★★★★☆ | 4.7 |
| baoyu-infographic | 社区（宝玉） | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★☆ | ★★★★☆ | 4.4 |
| browser-use 类（如 chrome-automation） | 社区 | ★★★★☆ | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | ★★★★☆ | 3.9 |
| 人物角色类（如 luxun-skill） | 社区 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ | ★★★★★ | ★★★☆☆ | 3.4 |
评分说明：功能完整度 25%、设计质量 25%、实战效果 20%、上手难度 15%、社区活跃度 15%。人物角色类是本机装机目录里数量最庞大的一个族（百余个），但设计上普遍是“一段人设提示词”的极简模式，作为反例参照收录。
抓取本周榜单头部 Skill 的 SKILL.md 原文后，结构高度趋同：
---
name: skill-name
description: 一句话说明做什么 + 何时触发（这是唯一的召回入口）
---
# 标题
简短定位（1-3 句，说明能力与产出物）
## 何时使用（可选，有些并入 description）
## 核心流程（Step 1 → Step N，命令式祈使句）
## 资源引用（scripts/、references/、assets/ 的使用时机）
## 注意事项 / 边界（不适用场景、失败兜底）
以官方 pdf Skill 为例，其 SKILL.md 的 description 写的是处理 PDF 的场景化描述（填表单、提文本、合并拆分），正文按操作类型分节，每节指向脚本化的工作流而非大段散文。这不是偶然：Claude 在运行时只加载 name+description 做召回判断，正文是命中后才注入的“第二层”——所以 description 决定生死，正文决定质量。
反例：不少社区 Skill 把长篇背景知识全部塞进 SKILL.md 正文，正文超过 300 行。结果是无论触发什么小需求，都注入全部内容，token 成本高且容易让模型在长上下文中“迷路”。官方 skill-creator 的文档里明确建议正文控制在 5k token 以内，理想更短。
本周拆过的官方 pdf 技能已验证过这个架构，这里提炼为可复用模式：
flowchart TD
A["用户消息进入"] --> B{"description 召回判断"}
B -->|"匹配"| C["加载 SKILL.md 正文"]
B -->|"不匹配"| D["Skill 不参与本轮"]
C --> E{"正文是否引用资源"}
E -->|"引用脚本"| F["按需执行 scripts/"]
E -->|"引用参考"| G["按需读取 references/"]
F --> H["产出结果"]
G --> H
三层分别对应三种 token 成本档位：
| 层 | 内容 | 加载时机 | 成本 |
|---|---|---|---|
| 第一层 | YAML frontmatter（name+description） | 每轮对话都在场 | 极低，几十 token |
| 第二层 | SKILL.md 正文 | 触发后注入 | 中，数百 token |
| 第三层 | scripts/references/assets | 正文按需引用 | 按文件计 |
把重货放第三层的好处不只是省 token：脚本比自然语言更不容易被模型“即兴发挥”。官方 pdf Skill 处理表单字段时直接调 pypdf 脚本，而不是让模型凭理解生成代码——确定性显著更高。
实践建议：凡是能用脚本固化的步骤（格式转换、API 调用、文件校验），一律下沉到 scripts/；凡是模型需要“查了再答”的知识（规范、风格指南、API 文档），放 references/；SKILL.md 正文只保留流程编排与判断逻辑。
对比本周拆过的头部 Skill，description 写法收敛为三种有效范式：
范式 A：动词 + 宾语 + 触发场景（官方系首选）
description: Extracts text and tables from PDF files, fills forms, merges documents. Use when the user mentions PDF files or asks to process document content.
要点：前半句说“能做什么”，后半句以 "Use when..." 显式给出触发条件。显式触发词是给召回机制的路标。
范式 B：角色 + 输出规格（内容创作系常用）
宝玉的 infographic 类 Skill 在描述里同时声明输出形态（信息图/图像规格），让模型在命中瞬间就知道交付物长什么样。这类 Skill 的正文往往再配一个“输出前自检清单”，形成描述与正文的闭环。
范式 C：反触发声明（高精度场景）
部分工程类 Skill 会在描述或正文开头写明“不适用场景”（如 security-review 类 Skill 声明不替代渗透测试）。反触发能有效减少误召回——这在浏览器操控类 Skill 上尤其重要，否则用户随便聊到“浏览器”就触发一次全页扫描。
写 description 的三条军规： 1. 用第三人称写完整句（"Extracts..."而非"Extract..."），这是官方文档的硬性要求，因为 description 会被填入系统提示的句子里 2. 必须包含用户会说出来的词，而不是你给项目起的内部代号——召回靠的是语义匹配用户原话 3. 不超过 1024 字符，超长部分不参与召回，纯浪费
拆解正文写作水平时，头部 Skill 与腰部 Skill 差距最大的是这一层。三个可复用的手法：
手法 1：祈使句流程。头部 Skill 的流程步骤全部是祈使句（"Run the script"、"Validate output"），每步一个动作，可执行可校验。腰部 Skill 常写成描述性散文（“本 Skill 将会……”），模型读完不知道第一步干什么。
手法 2：检查点回读。官方 skill-creator 自己的 SKILL.md 里就示范了这个模式：在产出最终结果前，插入一个“对照需求清单逐项自检”的步骤。内容创作类 Skill（如知识转课程、知识转幻灯片类）普遍用「输出前自检清单」实现同样的约束。
手法 3：失败兜底。工程类 Skill 会写“如果 X 失败，改用 Y"。例如部署类 Skill 通常声明：CLI 未登录时的处理、环境缺失时的降级路径。没有兜底的 Skill 在边界场景会把错误直接抛给用户。
my-skill/
├── SKILL.md # 唯一必需品
├── scripts/
│ └── process.py # 可执行脚本（bash/python）
├── references/
│ ├── api-docs.md # 查阅型知识
│ └── examples.md # 少量few-shot示例
└── assets/
└── template.pptx # 模板/静态资源
这个布局不是官方强制的，但已是事实标准——skill-creator 生成的新 Skill 默认就是这个骨架，市场目录（skillsmp、skills.sh 等）的索引器也按这个结构解析。两个细节值得注意：
综合以上模式，给出一个 20 行的最小可用模板：
---
name: weekly-report
description: Generates weekly work reports from git commits and todo notes. Use when the user asks for 周报, weekly summary, or work report.
---
# 周报生成器
从 git 提交记录与本周笔记生成结构化周报。
## 流程
1. 运行 `git log --since="7 days ago" --oneline` 获取提交
2. 按「已完成/进行中/风险」三栏归类
3. 对照用户上次周报的格式（如存在）
4. 输出前自检：每条都有可验证的产出物，无空话
## 边界
- git 不可用时，明确告知并请求用户提供手写清单
- 不虚构未发生的工作项
写完放进去就能用：个人级放 ~/.claude/skills/weekly-report/，项目级放 .claude/skills/。验证方式也简单——开新会话，说一句“帮我写周报”，观察是否召回；不召回就回头改 description 里触发词。
最适合当写作范本学的 Skill（学结构）： 1. skill-creator（官方）——它既是工具也是元教材，生成新 Skill 的过程本身就是模式示范 2. pdf（官方）——渐进披露与脚本化教学的满分样本 3. frontend-design（官方）——description 触发词设计的教科书
最适合抄骨架改造的 Skill（学布局）： 1. baoyu-infographic——单人作者也能把设计与工程结合到位 2. chrome-automation——资源脚本与正文编排的工程化样本
新手最容易写砸的三个点： 1. description 写成关键词堆砌而非完整句——召回率显著下降 2. 正文塞满背景知识——token 成本失控 3. 不写边界与兜底——边界场景直接翻车
Skills 生态跑完八轮，看得越细越确认一件事：SKILL.md 不是文档，是给模型读的程序。它的每一行都在花 token、都在影响召回、都在约束或放任模型的即兴发挥。本周榜单上的头部 Skill 无论来自官方还是单人作者，赢法是一致的——用最小的第二层注入，换取最确定的第三层执行。想入门的读者，不需要等任何教程更新：抄上面 20 行模板，今天就能发布你的第一个 Skill。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。