今天要聊的东西，起源于一个很真实的痛点------开不完的会，写不完的纪要。
你有没有经历过这样的场景：一场会议下来，老板、产品、开发你一言我一语，录音转文字丢给你一坨几千字的文本。然后你得从里面抠出"谁说了什么""决定了什么""谁来执行""什么时候完成"。这活儿高度重复、高度结构化，但又不得不做。
更别说每天还要刷 TechCrunch、Hacker News、Reddit 追 AI 资讯------明明套路一样，却要每天重新来一遍。
这些，都适合用 Claude Code 的 Skill 来搞定。
今天这篇文章，我会用两个真实的 Skill 案例------会议纪要生成 和 AI 日报生成------带你一步步看懂 Skill 是怎么封装的，以及背后那个"模具"（skill-creator）是怎么设计的。读完你会发现，Skill 的固定格式其实很简单，一旦掌握，任何重复性工作你都能自己封装。
一、先看产物：两个 Skill 能做什么
1.1 meeting-minutes：录音转写 → 结构化纪要
这是第一个场景。你手上有一段部门团建会议的录音转文字文本，像这样：
发言人1 00:22
今天咱们四个人过来，碰个头，开个小会。主要是说咱们公司，
咱们那个小部门好久没团建了......
发言人2 00:45
口罩就没什么问题了。
发言人1 00:48
然后大家觉得咱们现在有必要团建吗？
发言人2 00:51
这里边我觉得有必要团建。
发言人3 00:53
是得玩玩是吧？对市场工作压力太大了。将近 500 行，四个人，七嘴八舌讨论团建去哪玩。人工整理少说要半小时。
meeting-minutes Skill 的输出是这样的：
markdown
# 会议纪要
## 一、会议基本信息
| 项目 | 内容 |
|------|------|
| 会议主题 | 部门团建活动方案讨论 |
| 参会人员 | 发言人1（部门负责人/主持人）、发言人2（男同事代表）... |
## 三、会议内容
### 议题一：是否有必要组织团建
**讨论内容：**
- 发言人1提出部门已八个月未团建，询问大家意见。
- 发言人2认为有必要团建，可以增进同事间的友谊、信任度。
**结论/共识：**
全员一致认为有必要组织团建活动。
## 四、行动项
| 序号 | 行动事项 | 负责人 | 截止时间 |
|------|----------|--------|----------|
| 1 | 向领导申请团建费用 | 发言人1 | |
| 2 | 确定具体场地并预订 | | |
| 3 | 预订包车（大巴） | | |口播稿 → 会议基本信息 → 议题讨论+结论 → 行动项 → 待决事项 → 下次会议安排。全程自动。
1.2 xie-ai-daily：多源搜索 → 精美日报
第二个场景更日常------每天需要了解 AI 行业动态，但没时间一个一个网站刷。
xie-ai-daily Skill 会并行搜索 TechCrunch、The Verge、Hacker News、Reddit，筛选 8-15 条高价值资讯，生成中文摘要，打上关键词标签，最后输出一个这样的 HTML 页面：
- 深色渐变 Header，居中显示"谢哥AI日报"和日期徽章
- 统计栏：精选 X 条 / 覆盖 X 个领域 / 来源 X 个媒体
- 快速筛选标签栏（点击"OpenAI"只看相关卡片）
- 每条资讯一张卡片：来源徽章 + 标题 + 中文摘要 + 关键词标签 + 原文链接
- 响应式布局，手机也能看
每天生成一个新的 HTML 文件，打开就是一份精美日报。
关键点 ：这两个 Skill 解决的是同一类问题------输入非结构化数据，输出固定格式的结构化结果。会议纪要是这样，AI 日报也是这样。
二、skill-creator：造 Skill 的"模具"
上面两个 Skill 不是凭空写的，它们是用 Anthropic 官方提供的 skill-creator 创建出来的。可以说，skill-creator 是"造 Skill 的 Skill"。
来拆一下它的内部结构：
javascript
skill-creator/
├── SKILL.md ← 核心：定义如何从零创建/迭代/评估/打包 Skill
├── agents/ ← 子代理：帮你做评测的"评分员"
│ ├── grader.md ← 按断言评估输出是否合格
│ ├── comparator.md ← 盲测 A/B 对比两版 Skill 谁更好
│ └── analyzer.md ← 分析 benchmark 数据，找出统计盲区
├── scripts/ ← 自动化脚本
│ ├── package_skill.py ← 打包成 .skill 文件
│ ├── run_eval.py ← 运行评估
│ ├── run_loop.py ← 优化 description 触发准确率
│ ├── aggregate_benchmark.py ← 聚合 benchmark 数据
│ └── ...
├── references/ ← 参考文档（按需加载，不常驻上下文）
│ └── schemas.md ← JSON 数据结构定义
├── eval-viewer/ ← 评测结果可视化
│ ├── generate_review.py
│ └── viewer.html
└── assets/
└── eval_review.html ← 触发词评估审查页面skill-creator 的核心理念是"迭代闭环"：
写草稿 → 跑测试用例（并行：有 Skill vs 无 Skill）→
评分 + 查看输出 → 收集反馈 → 改进 Skill → 再跑测试 →
重复直到满意 → 打包 .skill 文件这个闭环里最精妙的设计是 "并行对比评估" ：每个测试用例同时跑两个版本------一个带着你的 Skill，一个不带（baseline）。然后生成 benchmark 数据对比：通过率提升了多少？耗时多了还是少了？Token 消耗增加了多少？
有了数据，优化就有了方向。
三、方法论沉淀：SKILL.md 的固定格式
把两个产物（meeting-minutes、xie-ai-daily）和模具（skill-creator）放在一起看，会发现一个共同的骨架------每个 Skill 都由以下结构组成：
objectivec
skill-name/
├── SKILL.md ← 必需
├── scripts/ ← 可选：可执行脚本
├── references/ ← 可选：参考文档
└── assets/ ← 可选：模板、图标等静态资源而 SKILL.md 本身，只有两个固定部分：
第一部分：YAML 前置元数据（Frontmatter）
yaml
---
name: meeting-minutes
description: 根据会议文字稿生成结构化会议纪要。当用户提供会议记录、
会议文字稿、录音转文字内容，或提到"会议纪要"、"整理会议"、
"meeting minutes"、"生成纪要"等关键词时，使用此技能。
---name：技能唯一标识，英文 kebab-case。description：这是最重要的字段 。Claude 根据这段话决定是否触发你的 Skill。要写清楚两件事：这个 Skill 做什么 + 什么时候该用它。关键词要具体，场景要明确。
举个反例------如果 description 只写了"生成会议纪要"，当用户说"帮我把这段会议录音整理一下"，Claude 可能就不会触发你的 Skill。但如果你写了"当用户提到'会议纪要'、'整理会议'、'meeting minutes'、'生成纪要'等关键词"，命中率就打打提高。
💡 一个小贴士：skill-creator 的
scripts/run_loop.py就是专门用来优化 description 的------它会生成 20 条触发评估查询（有应该触发的 + 不该触发的"近义词陷阱"），自动迭代 5 轮，找出最佳 description。
第二部分：Markdown 正文（指令体）
YAML 块之后的一切，都是 Skill 的"专业大脑"。没有强制格式，但五个模块几乎成了所有好 Skill 的标配：
| 模块 | 作用 | meeting-minutes 示例 | xie-ai-daily 示例 |
|---|---|---|---|
| 处理流程 | 分步 SOP | 通读全文 → 清洗内容 → 结构化输出 | 多源抓取 → 智能筛选 → 生成摘要 → 标注标签 → 生成 HTML |
| 输出模板 | 用代码块写死格式 | Markdown 表格（会议基本信息/议题/行动项/待决事项） | HTML 模板（{{DATE}} {{NEWS_CARDS}} 占位符） |
| 质量要求 | 好输出的标准 | 完整性、准确性、简洁性、诚实性（不确定就留空） | 时效性、权威性、多样性、准确性、可读性 |
| 示例 | Input → Output 对照 | 一段口播文本 → 完整会议纪要 | --- |
| 注意事项 | 边界情况 | 多人同时说话标 [听不清]、分别如实记录 |
--- |
用一句话概括：告诉 AI 先做什么、再做什么，输出长什么样，怎样算好，给个例子，再交代一下坑在哪。
四、写作原则：少写 MUST，多讲 Why
skill-creator 本身就是一个很好的写作范本，它里面提到一个很重要的原则：
"Try hard to explain the why behind everything you're asking the model to do. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag."
翻译一下：不要用满屏的大写 MUST 和 NEVER 来压迫 AI，而是解释清楚"为什么这样做很重要"。
比如 meeting-minutes 里写质量要求的时候，不是写：
sql
MUST NOT add any information not in the original transcript.而是写：
markdown
- **诚实性**：信息不确定时宁可留空，绝不编造效果一样，但后者 AI "理解"了意图，而不是被动服从命令。这就好比带新人------告诉他"为什么要这样检查"，比吼一句"不许出错"有用一百倍。
另外几条原则：
- 用祈使句（"通读全文""按照模板输出"），不是商量语气
- 控制在 500 行以内 ，超出就拆到
references/做二级索引 - 示例驱动，一个好的 Input → Output 对照胜过千言万语
五、两个 Skill 的"输入→输出"闭环
最后，我们把这套体系串起来看一张全景图：
less
┌─────────────────────┐
│ skill-creator │
│ (造 Skill 的模具) │
│ │
│ 定义流程 → 跑测试 │
│ → 评分 → 改进 → 打包 │
└────────┬────────────┘
│ 用模具造出
┌──────────────┼──────────────┐
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ meeting-minutes │ │ xie-ai-daily │
│──────────────────│ │──────────────────│
│ 输入: │ │ 输入: │
│ meeting_content │ │ WebSearch 多源 │
│ .txt (录音转写) │ │ 搜索结果 │
│ │ │ │
│ 处理: │ │ 处理: │
│ 通读→清洗→结构化 │ │ 抓取→筛选→摘要 │
│ │ │ →标签→HTML │
│ │ │ │
│ 输出: │ │ 输出: │
│ 会议纪要.md │ │ 谢哥AI日报- │
│ (结构化Markdown) │ │ 2026-07-17.html │
└──────────────────┘ └──────────────────┘
│ │
└──────────┬──────────────────┘
│ 方法论提炼
▼
┌──────────────────┐
│ readme0717.md │
│──────────────────│
│ SKILL.md 固定格式: │
│ │
│ 1. YAML 元数据 │
│ name + desc │
│ │
│ 2. Markdown 正文 │
│ 流程+模板+质量 │
│ +示例+注意事项 │
└──────────────────┘输入 → Skill → 输出 → 方法论沉淀，四个环节构成了完整的学习闭环。
今日收获
- Skill 解决的是"重复 + 结构化"问题------会议纪要、AI 日报都符合这个特征，一旦封装，每次调用就是几秒钟的事。
- SKILL.md 只有两个固定部分：YAML 头（name + description）和 Markdown 正文。description 写得好不好，直接决定了 AI 能不能在正确时机触发你的 Skill。
- skill-creator 是"元 Skill" ------它定义了 Skill 的标准化创建流程：捕获需求 → 写草稿 → 并行跑测试（含 baseline）→ 评分 → 改进 → 打包。这套方法论适用于创建任何 Skill。
- 写 Skill 的核心原则：解释"为什么"而非堆砌 MUST、控制在 500 行以内、示例驱动、渐进式加载（metadata → body → references）。
- 两个实战产物给我们最大的启发：非结构化 → 结构化的流水线，只需要一个写好的 SKILL.md 就能跑起来。
#ClaudeCode #AI自动化 #Skill开发 #效率工具 #Prompt工程