引子：这个目录到底装了什么？
打开 ai/skills/hys/meeting 这个文件夹，你看到的不是一堆业务代码，而是一份写给 AI 看的"工作手册"。它由四部分组成：
- 两个技能（Skill） ——
.claude/skills/下面躺着meeting-minutes（会议纪要生成）和tian-ai-daily（AI 日报生成），核心都是一个SKILL.md文件。 - 一份原始素材 ——
meeting_context.txt，一段 32 分钟的真实会议录音转写稿，4 个人在讨论"要不要团建、怎么团建"。 - 一套评测工作区 ——
meeting-minutes-workspace/iteration-1/，"用了技能"和"没用技能"两组 AI 输出的对照实验，配了打分表和统计报告。 - 一份实战产物 ——
甜甜AI日报-2026-07-17.html，是tian-ai-daily技能实际跑出来的日报网页。
换句话说，这个目录讲的是一个完整的故事：如何把一个重复的脑力活儿（写会议纪要），写成一份 AI 能照着执行的说明书，并且用实验证明这份说明书确实有用。
一、什么是 Skill（技能）
先解决一个最朴素的问题：什么是 Skill？
你可以把它理解成 "给 AI 准备的岗位说明书 + 标准作业流程（SOP）"。平时我们让 AI 干活，是在对话框里临时打一段提示词，比如"帮我把这段会议记录整理成纪要"。这段话说完就没了，下次还得再说一遍，而且每次说的详略不同，AI 输出的格式也就飘忽不定。
Skill 做的事情是：把这类重复出现的活儿，固化成一份文件，放在项目里。 以后 AI 一遇到"生成会议纪要"这类请求，就自动把这份文件读进来，按照里面写好的流程和格式干活。对使用者来说，你不用再反复交代要求；对 AI 来说，它有了稳定的"操作手册"。
用 readme.md 里作者的大白话就是：
重复的工作、专业的技能，
SKILL.md记录下来；prompt 固化在我们的项目中。
Anthropic 官方还专门推出了 skill-creator，用来标准化、简化技能的封装流程，让任何人都能随时创建自己的技能。这套体系已经成了行业里的事实标准，hys/meeting 就是一个标准的示例工程：文件夹名 + SKILL.md，结构简单到一眼就能看懂。
那 AI 是怎么知道"此刻该不该用这个技能"的呢？答案藏在文件头部。
二、SKILL.md 的三段式结构
每个 SKILL.md 都由三段组成，最好用的比喻是"简历 + 工作流程 + 注意事项"。
第一段：YAML 头部（AI 的"判断依据"）
文件开头用两行横线 --- 夹起来的一小段，叫 YAML frontmatter：
---
name: meeting-minutes
description: 根据会议文字稿生成结构化的会议纪要。当用户提供会议记录、
会议转录、会议文字稿，或要求"生成会议纪要"、"整理会议记录"、
"写会议纪要"、"会议总结"、"meeting minutes"时使用此技能……
---
这里只有两个字段，但每一个都至关重要：
name是技能的身份证，必须唯一。description是整个机制里最关键的一行字。为什么？因为 AI 拥有的技能可能有几十上百个，它不可能每次都把所有技能文件从头读到尾——那样太浪费算力。它读到的是一个技能清单，每条只有name和description。AI 靠这两行字判断："用户这句话，该不该触发这个技能？"
所以你会看到 description 写得特别"啰嗦"，把各种可能的说法都列了出来："生成会议纪要""整理会议记录""写会议纪要""会议总结"……连英文 meeting minutes 都带上了。这不是凑字数，而是在尽可能多地覆盖用户可能说出的触发词——写得越全，AI 越不容易漏判。同理，tian-ai-daily 的描述里也塞进了"今日AI新闻""AI日报""最近AI有什么大事""甜甜日报"等等。
记住一句话：description 决定了技能会不会被"想起来"。
第二段：工作流程（AI 的"做事步骤"）
头部下面是正文，用大白话分步骤写清楚"这件事该怎么做"。比如 meeting-minutes 写的是三步：通读全文 → 清洗文本 → 提取并结构化输出。这部分相当于 SOP，越具体越好。
第三段：输出格式与注意事项（AI 的"交付标准"）
最后规定好输出的模样（这里是一份 Markdown 模板），再补几条注意事项，比如"不确定就留空""保留分歧"。
三、拆解 meeting-minutes：一份会纪要的正确打开方式
三步工作流
第一步：通读全文。 先别急着总结，而是建立整体印象——这场会在聊什么、都有谁、谁是主持、节奏大致是"开场—讨论—总结"的哪一段。这一步是让 AI 先有全局观，避免一上来就抓错重点。
第二步：清洗文本。 录音转写成文字后，会有大量"垃圾"：口语停顿词（"嗯""啊""那个""就是说"）、重复寒暄、语音识别错误、跟主题无关的闲聊，甚至"网络不太好，能听到吗"这类调试设备的话。这一步就是把这些噪声去掉。
但这里有一条极妙的补充说明：
注意：保留说话人的语气立场（如"强烈反对"、"持保留意见"），这些对理解观点很重要。
这条规则体现了非常好的设计感。清洗的目标是去噪，不是把会议"洗成温吞水"。如果张三说"我强烈反对这个方案"，你把它压缩成"张三是有所保留的"，会议的火药味和真实分歧就丢了。去噪 ≠ 抹平差异，这个度拿捏得很准。
第三步：提取并结构化输出。 按模板把信息填进去，并且强调"不确定的内容直接留空，不要编造或猜测"。这一点后面还会再讲。
输出模板的五段式
模板规定了纪要必须包含五大块，这也是职场里一份合格纪要的标准骨架：
- 会议基本信息 —— 表格列出时间、地点、参会人员、主持人、记录人；
- 会议目标 —— 为什么要开这个会、涉及多少预算资源、有什么背景；
- 会议内容 —— 按主题拆开，每个主题下分"讨论要点 / 主要观点 / 结论共识"；
- 行动项 —— 表格列出"序号 / 任务描述 / 负责人 / 截止时间 / 备注"；
- 下次会议 —— 时间 + 议程要点。
注意第三块里的"主要观点"要求写成 [发言人A]：[观点/立场] 的形式——保留每个人的原话立场，而不是笼统地写"大家讨论了一下"。这就是"会议纪要"和"会议总结"的区别：纪要要留痕，总结可以概括。
六条注意事项
模板之后还有六条"注意事项"，条条都是血泪经验：
- 忠于原文 —— 只能写文字稿里有的信息；
- 不确定就留空 —— 确认不了的字段直接空着或标"待确认"，绝不猜测填充；
- 主题划分 —— 按内容的自然转折分主题，数量不设限；
- 行动项要具体 —— 必须能回答"谁、在什么时间之前、完成什么"；
- 保留分歧 —— 没达成一致的，如实记录各方观点，别刻意抹平；
- 语言风格 —— 专业、客观、简洁，且跟随原文语言（中文会议就用中文）。
第 2 条和第 5 条尤其值得琢磨：AI 最大的毛病之一就是"一本正经地编"。 会议里没提主持人是谁，它可能顺手给你编一个名字；大家吵得不可开交，它可能给你和稀泥说"经过讨论达成一致"。这两条规则就是专门给 AI 上的"诚信锁"。
四、拆解 tian-ai-daily：让 AI 帮你刷完所有 AI 新闻
第二个技能解决的痛点写在 readme.md 里："每天，我们都被海量的 AI 信息淹没。想要了解行业动态，但没有时间一个一个网站去刷。"
这是一个典型的"信息过载"问题，tian-ai-daily 的解法是六步：多源搜索（从产品发布、研究突破、行业商业、政策监管、中文资讯五个方向各搜一遍近 24 小时资讯）→ 智能过滤（挑出 8-12 条最有价值的，排掉营销软文、重复报道、来源不明和无关新闻）→ 写中文摘要（每条 50-100 字）→ 打关键词标签（每条 2-4 个，如 OpenAI 大模型 融资）→ 填 HTML 模板 → 简要汇报。
这套流程里有两个细节特别能说明"技能"的思维方式：
- 占位符机制。模板里写着
__TITLE__、__NEWS_COUNT__、__CARDS__等占位符，技能文档专门用一张表解释每个该填什么、什么格式。把"内容"和"样式"分开，AI 只负责填内容，样式由模板保证——这样每次生成的日报长得都一样好看，不会今天像网页、明天像记事本。 badge-hot只给 1-2 条。模板里新闻卡片支持一个"HOT"角标，但技能强制规定只有当天最重磅的 1-2 条才能用。这是个很聪明的约束：如果每条都标 HOT，就等于没有 HOT。 用规则强制 AI 做取舍，才能体现出真正的"编辑判断"。
五、Skill 和"随便写段提示词"到底差在哪
看到这你可能会问：这不就是写了一段比较长的提示词吗？
区别在于三个字：可复用、可管理、可评测。
- 可复用：写死在对话里的提示词，关掉窗口就没了；写成
SKILL.md，就变成了项目资产，谁都能用、随时随地都能用。 - 可管理：文件可以进版本管理，可以 review、可以迭代。今天发现"应该保留语气立场"，就加一条规则；明天发现"容易编造信息"，就加一条"不确定就留空"。技能是可以长大的，聊天气泡里的提示词不能。
- 可评测：既然技能是文件，那就能拿它做 A/B 实验，用数据回答"这个技能到底有没有用"。这正是下一章要讲的。
六、评测工作区：用数据证明"技能有用"
meeting-minutes-workspace/iteration-1/ 是一套完整的技能评测（skill eval）工程。它的核心思路非常朴素，就是控制变量做对照实验：
- with_skill（实验组）：让 AI 带着
meeting-minutes技能去做题； - without_skill（对照组）：同一个模型、同一道题，但不给技能，让它自由发挥。
然后比较两组的输出质量、耗时和 token 消耗。
三个测试用例
evals.json 里定义了三道题，都是真实场景的会议转写稿：eval-0 / product-launch（智能门铃 Pro 上市会，涉及定价 459 元、推广预算 80-100 万）、eval-1 / sprint-review（Scrum 迭代回顾，12 个 story points 只完成 9 个）、eval-2 / budget-meeting（2024 年度预算评审，技术部想把预算从 1000 万要到 1100 万）。
每道题都配了 10 条断言（assertions），也就是"评分点"。比如 budget-meeting 的 10 条里包括：
- 基本信息里有时间（2024 年 2 月 20 日）
- 正确列出参会人员（CEO 老赵、孙总、钱总、周总、小马）
- 记录最终预算方案（技术 1100 万、市场 700 万、HR 200 万、机动 60 万）
- 体现了技术部预算从 1000 万调整到 1100 万的决策过程
- 输出是结构化 Markdown
注意倒数第二条——它考的不是"结果对不对"，而是"过程有没有留住"。这正是会议纪要和简单摘要的核心分野。
结果怎么看
benchmark.md 给出的汇总表是：
| 指标 | With Skill | Without Skill | 差值 |
|---|---|---|---|
| 通过率 | 100% ± 0% | 100% ± 0% | +0.00 |
| 耗时 | 33.0s ± 3.0s | 25.8s ± 1.4s | +7.2s |
| Token | 14441 ± 112 | 12895 ± 117 | +1545 |
这份数据非常诚实，甚至有点"打脸"：
第一，通过率两组都是 100%，技能没带来提升。 于是 benchmark.json 的 notes 里主动写下诊断："所有 30 条断言在两个配置下均 100% 通过 —— 断言偏向基础内容提取，未区分技能带来的深层格式和质量差异。" 翻译成人话：是考题出得太简单了，没考出差距，而不是技能没用。这反而是评测最宝贵的产出——它告诉你下一步该改的不是技能，而是题目。
第二，用技能更慢、更贵。 慢了 7.2 秒（+28%），多花了约 1545 个 token（+12%）。原因很明确：AI 得先读技能文件，再严格按模板输出，自然费时费钱。这说明技能不是白来的——它用一点效率换来了规范性。
第三，真正的差异在"质"上，虽然没被分数捕捉到。 notes 里记录了肉眼可见的区别：with_skill 的输出严格遵循五段式结构，而 without_skill 每次格式都不一样；with_skill 对不确定的信息会主动标"待确认"，比如 budget-meeting 输出里记录人一栏写的是 待确认、会议时间是 2024-02-20，具体时间待确认，而 without_skill 倾向于直接省略。
这就是评测工程的完整闭环：设计考题 → 跑对照实验 → 看数据 → 发现考题不够狠 → 改进考题。grading.json 记录每条断言的判定结果和证据，timing.json 记录耗时，benchmark.json 做统计汇总，review.html 是给人看的可视化报告。数据留痕，才能一轮一轮迭代。
七、实战演练：把团建会议稿交给技能
最后用一个真实例子串起来。meeting_context.txt 是一段 32 分钟、4 个发言人的团建讨论录音稿，通篇都是"嗯""那个""就是说"和各种跑题。如果按 meeting-minutes 的流程处理，会得到这样的结果：
清洗后，噪声（口语词、寒暄、设备调试）被剥掉，但分歧被完整保留：
- 玩什么？—— 否决了"K 歌吃饭"（太俗），定下郊区农家乐 + 对抗性活动（CS、拔河）+ 游山玩水；
- 一天还是两天？—— 发言人 3 主张一天（家里有孩子），发言人 2 主张住一晚，最终定周六上午出发、周日午饭后返程；
- 要不要出北京？—— 有人想走远，最终因疫情管控、健康码、家庭因素定为不出北京；
- 要不要请专业拓展教练？—— 一致否决（"跟军训似的""花钱不如自己吃喝"）；
- 交通 —— 统一包大巴（安全、好调度、能喝酒），不自己开车。
第三块的"主要观点"会如实写成 发言人2：主张住一宿 / 发言人3：主张一天往返 —— 而不是含糊地写"大家讨论了行程安排"。
第四块的行动项会落到人和时间上，比如"发言人 1 负责联系大巴和怀柔场地，本周内确认"。
第五块的"下次会议" 则留空或标"待确认"，因为原稿里没有明确。
对比一下 readme.md 里那句吐槽——"开不完的会，牛马不停地收到收到""会议有个主题，抽象，要解决什么问题，谁负责？截止日期？"——你会发现整个技能的设计目标，就是把这几个问号自动化地填满：主题填进"会议目标"，谁负责和截止日期填进"行动项"。人只需要提供一段乱糟糟的录音稿，剩下的结构化工作交给技能。
小结
把这个目录看成一个整体，它示范了 AI 应用工程中非常核心的一套方法论：
- Skill = 把重复的专业工作固化成文件。 结构就三段——YAML 头部（
name+description，其中description决定技能能否被触发）、工作流程（SOP）、输出格式与注意事项（交付标准）。 - 好的技能文档，一半在教 AI"怎么做"，一半在防 AI"乱做"。 "不确定就留空""保留分歧""badge-hot 只给 1-2 条"，都是在用规则约束模型的坏习惯。
- 技能必须可评测。 with_skill 与 without_skill 的对照实验，用通过率、耗时、token 三个指标量化收益与代价；当分数区分不出来时，要敢于承认"是考题不行"，然后去改进考题。
- 技能的代价是真实的。 更慢、更贵，换来的是稳定和规范。所以值得做成技能的，是那些高频、重复、对格式有要求的工作——会议纪要就是教科书级的例子。
从一个 SKILL.md 文件开始，你其实是在给 AI 写一本只属于你自己业务的操作手册。它会越写越厚，也会越用越准。
