开会开到崩溃？我让 AI 给自己写了个「数字小秘书」，从此告别"收到收到收到"
读完这篇文章你会学到：每个重复性脑力劳动，都值得被封装成一个 AI Skill。 文末有完整方法论，你可以立刻动手做自己的。
一、你是不是也这样？
早上九点半，第四个会议。你坐在会议室角落，手机震动——第五个会议提醒弹出来了。
你在群里回了个"收到"，然后继续盯着投屏上的争论：产品经理想加需求，程序员说要排期，设计师觉得交互不合理，测试在旁边补刀"上次那个 bug 还没修呢"。
一个小时后，你看着电脑上 8000 字的录音转写稿，开始手动整理会议纪要——"什么主题"、"谁负责"、"截止日期是什么"。
同样的格式，同样的动作，第 37 次。
你揉了揉干涩的眼睛，心想："这东西能不能让 AI 自己弄？"
然后你打开手机想刷会儿技术资讯放松一下，结果信息流推荐了 47 篇 AI 相关文章。你根本没时间看，但你知道不跟进行业动态就落后了。
这就是当代打工人的日常——
- 开不完的会
- 回不完的"收到"
- 看不完的信息
每件事都谈不上"难"，但每件事都在重复消耗你的注意力。
我最近就在这种状态里，直到我在 Claude Code 里折腾出了一套自动化方案。今天这篇文章，就把完整的思路和方法论拆给你看。
二、一个被低估的认知：AI 不只是聊天，它能被「封装」
大多数人用 AI 的方式是这样的：
打开 ChatGPT / Claude → 问一个问题 → 得到一个回答 → 关掉
这没问题，但远远不够。
真正能拉开差距的用法是：把你反复做的、有固定模式的工作，封装成 AI 的"专业技能包"。
在 Anthropic 的生态里，这个东西叫 Skill。简单理解，Skill 就是——
一个文件夹，里面有一份 SKILL.md 文件，文件里写好了"什么时候触发、怎么做、输出什么"。AI 读到它之后，就像学会了这项技能，遇到对应场景就自动执行。
它的目录结构长这样：
my-skill/
├── SKILL.md ← 核心：技能说明书
├── scripts/ ← 可选：可执行脚本
├── references/ ← 可选：参考文档
└── assets/ ← 可选：模板、资源文件
其中 SKILL.md 的头部用 YAML 声明两个关键信息：
---
name: meeting-minutes
description: >
根据会议文字稿生成结构化会议纪要。当用户要求"整理会议纪要"、"生成会议记录"、
"写会议纪要"时触发。即使用户没有明确说"会议纪要"，只要提供了对话形式的文字稿
并要求结构化整理，也应使用此技能。
---
注意那个 description 字段——它是整个 Skill 的"触发器"，决定了 AI 在什么时候自动调用这个技能。
这不是一个花哨的概念验证。我自己已经用这套方法论搞定了两个高频场景。下面我一个个拆给你看。
三、案例一：会议纪要自动生成——从此再也不用"整理"会议了
痛点有多痛？
想象一下典型会议的产出物：
- 会议室智能硬件的录音文件
- 转写成文字 → 8000 到 15000 字的散装对话
- 充满了"嗯""啊""就是说""那个那个"的口语填充词
- 各方观点交错穿插，跳跃性极强
手工整理这样一份纪要，从听录音到出文档，至少 1 小时起步。而且你做的第 37 次和第 1 次，本质上没有任何区别——这件事的「重复率」是 100%。
我做了个什么？
我创建了一个叫 meeting-minutes 的 Skill，它的工作流程只有两步：
第一步：通读并清洗
- 自动去除停顿词和填充词（"嗯"、"啊"、"就是说"）
- 过滤寒暄闲聊、与主题无关的插话
- 修正明显转写错误（不确定的保留原文）
- 保留所有关键信息：观点、数据、决策、分歧、承诺
第二步：结构化输出——按照固定模板生成纪要
模板长这样（核心部分）：
# [会议标题]
## 一、会议基本信息
| 会议时间 | 会议地点 | 参会人员 | 记录人 |
## 二、会议目标
### 背景 / 会议目的 / 预算资源
## 三、会议内容
### 主题一：[名称]
讨论要点 / 各方观点 / 结论决议
## 四、行动项 ← 老板最关心的部分
| 行动项 | 负责人 | 截止时间 | 备注 |
## 五、下次会议
是否确定 / 暂定时间 / 待议事项
来，看一个真实效果
这是输入——一段关于"公司团建去哪玩儿"的会议录音转写：
"今天咱们四个人过来碰个头……说咱们公司好久没团建了……我觉得应该去北京郊区，门头沟延庆房山……可以吃农家饭，体验农家生活……我觉得两天比较合适，周六去周日下午回来……你总不能出去太长时间，领导也不批准……"
输出是这样的：
会议标题：团队建设活动策划讨论
会议目的：确定下半年团建活动形式与方案
主题一：团建地点选择
- 多数意见：北京郊区（门头沟/延庆/房山等），不出京
- 反对出京理由：部分同事有家庭顾虑，舟车劳顿影响休息
主题二：团建时间安排
- 方案：周六上午出发，周日下午返程，两天一夜
结论：倾向北京郊区，两天一夜模式
行动项：
序号 行动项 负责人 截止时间 1 向领导申请团建预算 发言人1（部门负责人） 待确定 2 筛选郊区具体目的地 发言人2 待确定 3 统筹考量女同事及家庭需求 发言人1 待确定
从散装对话到结构化纪要，人只需要最后扫一眼确认，中间的"整理"过程 AI 全包了。
这个 Skill 的关键设计点
SKILL.md 里我特别加了几条约束，事后证明每一条都很重要：
- "不确定的内容直接留空，不要编造" —— 这是防止 AI "脑补"信息的关键。会议纪要最怕的不是漏记，是记了不存在的东西。
- "行动项必须包含三个要素：谁、做什么、何时完成" —— 缺了任何一个，纪要就变废纸。
- "如果存在分歧，同时记录不同意见" —— 避免纪要变成"一言堂"的二手加工品。
四、案例二：AI 日报自动生成——信息焦虑终结者
另一个每天折磨你的东西
每天醒来打开手机，AI 领域至少发生这些事情：
- OpenAI 又发了新模型 / 被收购 / 被起诉
- Google 在 I/O 上展示了一个 demo（一年后才上线）
- Anthropic 默默更新了文档
- 某家 AI 公司融了 2 亿美元，方向是 AI + 垂直行业
- 开源社区又爆出一个吊打闭源的项目
- 国内大厂发布对标产品……
- ……
信息源分散在 TechCrunch、The Verge、Hacker News、Twitter/X、微信公众号、即刻、知乎……你一个个刷过去，一小时没了。
但你不看不行的——做这行，信息差就是竞争力。
我的解法：tian-aiidaily Skill
这个 Skill 的核心思路是：把"收集 → 筛选 → 翻译 → 排版"整条链路全部自动化。
它分五步走：
第一步：并行采集
├── WebSearch "site:techcrunch.com AI news today"
├── WebSearch "site:theverge.com AI artificial intelligence"
├── WebSearch "site:news.ycombinator.com AI LLM"
└── WebSearch "AI industry breakthroughs 2026"
第二步：筛选去重
保留：产品发布 / 技术突破 / 融资并购 / 政策法规 / 开源项目
剔除：纯教程 / 泛科技 / 营销软文 / 重复报道
目标：8-15 条精选
第三步：中文摘要
标题翻译（≤20字） + 50-100字摘要 + 智能标签
标签示例：#大模型 #开源 #OpenAI #多模态 #Agent
第四步：生成 HTML 日报
卡片式布局 + 紫色渐变标题 + 响应式设计
第五步：保存文件，告知用户
产出物长什么样？
最终生成的是一个完整的、可以直接在浏览器打开的 HTML 文件——
- 顶部：
甜甜AI日报 - 2026年07月17日，渐变紫色大标题 - 统计栏："今日精选 10 条资讯 | 覆盖 3 个来源"
- 内容区：每篇新闻一张卡片——标题可点击跳原文、中文摘要、彩色标签徽章、来源+时间
- 标签按类别变色：产品/发布是绿色、技术/模型是蓝色、融资/商业是橙色、政策/法规是红色
桌面端 3 列网格、移动端自动折叠成 1 列。每天打开看一眼卡片，五分钟搞定一天的 AI 资讯。
设计决策：为什么用 HTML 而不是 Markdown？
因为 AI 日报是"看"的不是"读"的。一张排版精美的网页，信息层次一目了然，比一段 markdown 文本的阅读体验好 10 倍。
而且 HTML 文件天然可分享、可存档、可以部署到任意静态托管。你把每天的 HTML 攒下来，一个月就是一本完整的 AI 资讯合辑。
五、关键认知：为什么这两个 Skill 能真的用起来？
看完上面两个案例，你可能觉得"这不就是写了个 prompt 模板吗？"
不是的。 普通的 prompt 模板和 Skill 之间，有本质区别：
| 维度 | Prompt 模板 | Skill |
|---|---|---|
| 触发方式 | 每次手动复制粘贴 | 自动识别场景，主动触发 |
| 一致性 | 你每次写的不一样 | 每次都走同一套 SOP |
| 可维护性 | 散落在聊天记录里 | 一个文件夹，版本管理 |
| 可进化 | 靠记忆迭代 | 有测试用例，可度量改进 |
| 可分享 | 没法给同事用 | 打包成 .skill 文件，一键安装 |
换句话说，Prompt 是一次性的，Skill 是资产。
这也是为什么 Anthropic 专门搞了一个叫 skill-creator 的元技能——它就是来帮你标准化"创建 Skill"这件事情的。
六、skill-creator：教你"造轮子"的轮子
什么是元技能（Meta-Skill）？
如果说 meeting-minutes 是"会议纪要"这个轮子，tian-aiidaily 是"AI 日报"这个轮子——那 skill-creator 就是教你怎么造轮子的轮子。
它是 Anthropic 官方推出的一套标准化工作流，用来：
- 从零创建一个新的 Skill
- 对已有的 Skill 进行测试和迭代优化
- 评估 Skill 的表现（有 Skill vs 无 Skill 对比）
- 优化 Skill 的触发描述（让 AI 在该触发的时候更准确地触发）
创建工作流的四步循环
skill-creator 的核心流程是一个持续迭代的闭环：
┌─────────────────────────────────────────┐
│ │
│ ① 捕获意图 │
│ "这个 Skill 要做什么？什么时候触发？" │
│ │
│ ↓ │
│ │
│ ② 起草 SKILL.md │
│ 写 YAML 头部 + 工作流程 + 输出模板 │
│ │
│ ↓ │
│ │
│ ③ 测试 │
│ 用 2-3 个真实测试用例跑一遍 │
│ 同时跑"有 Skill"和"没有 Skill"对比 │
│ │
│ ↓ │
│ │
│ ④ 评估 → 改进 → 回到② │
│ 看输出质量 + 读反馈 + 改 Skill │
│ 直到满意为止 │
│ │
└─────────────────────────────────────────┘
SKILL.md 的结构——记住这三点就够了
每个 SKILL.md 必须包含：
1. YAML 前端（必需的）
---
name: your-skill-name
description: >
这个 Skill 做什么、什么时候触发。
这是 AI 判断"要不要加载这个技能"的唯一依据。
写得好 AI 自动识别场景；写得不好 never trigger。
---
2. 工作流程（正文核心）
用清晰的步骤描述 AI 拿到任务后应该怎么一步步做：
- 第一步做什么
- 第二步做什么
- 输出格式是什么
3. 输出模板 + 注意事项
给出固定格式和边界约束：
- "不确定的留空，不要编造"
- "行动项必须包含谁/做什么/何时完成"
- "分歧要同时记录，不偏向任何一方"
一个反直觉的要点：description 比正文更重要
很多人在写 SKILL.md 时把所有精力花在正文上，结果 Skill 从来不被触发。为什么？
因为 AI 的工作机制是：先用 description 判断"这件事值不值得加载这个 Skill"，只有判断通过后，才会去读正文。
所以 description 需要做到两件事：
- 覆盖所有触发场景：用户可能用哪些说法？（"整理纪要" vs "生成会议记录" vs "meeting minutes" vs 什么关键词都没说但给了对话文本）
- 不要太宽泛：避免在不该触发的时候也触发，抢了其他 Skill 的工作
skill-creator 甚至专门有一个「描述优化」模块——它会生成 20 个测试查询（10 个应该触发的 + 10 个不该触发的），用自动化脚本跑 5 轮迭代，帮你找到最佳 description。
七、更重要的认知：所有重复性脑力劳动都可以 Skill 化
回到开头那个场景——
第 37 次做会议纪要，心想"能不能让 AI 自己弄？"
这件事的本质不是"会议纪要"，而是：
任何你做第 2 次时就开始不耐烦的事情，理论上都可以被封装成一个 Skill。
我不是在说"所有工作都交给 AI"这种宏大叙事。我说的是——你身边这些高频重复的事情：
| 场景 | 可能的 Skill |
|---|---|
| 每天的 AI 资讯 | AI 日报生成 |
| 周报 / 月报 | 按模板自动汇总本周工作，输出周报 |
| Code Review 前自查 | 检查代码变更，输出 review 问题清单 |
| 新 PRD 评审 | 读 PRD → 输出逻辑漏洞、边界条件检查 |
| 技术方案评审 | 读方案文档 → 输出风险点、替代方案对比 |
| 英文文档翻译 | 技术文档英译中，保留术语一致性 |
| 竞品分析 | 按固定模板收集竞品动态，生成分析报告 |
| 数据报表 | 读原始数据 → 按模板输出分析报告 + 可视化 |
它们的共同特征是：
- 有固定输入（会议录音、新闻源、Git diff、PRD 文档）
- 有固定输出模板（纪要模板、日报卡片、review 清单）
- 有固定的处理步骤（清洗→分类→提取→排版）
- 你做第 N 次和第 1 次的操作完全一样
这四个条件凑齐了，就是一个完美的 Skill 候选。
这个时代的核心能力
以前我们说"程序员的核心能力是编程"。
现在编程的门槛正在被 AI 快速拉低。有人说"以后人人都是程序员"，但我觉得更准确的说法是：
以后每个人的核心能力，不是"写代码"，而是"识别什么可以自动化"以及"设计自动化流程"。
Skill 就是这种能力的载体。它不需要你会写 Python，只需要你——
- 看得见自己的重复劳动
- 理得清步骤和模板
- 能用自然语言把流程写下来
- 愿意跑两次测试看看效果
这就是你在这个时代和别人的差距所在。
八、现在你可以做的三件事
第一步：盘点你的「重复率清单」
拿出一张纸（或打开一个文档），写下你过去两周里做了 3 次以上的、每次都差不多的事情。
不用管能不能自动化，先写下来。
第二步：挑一件最痛的事，写一个「如果是 AI 做，它该怎么办」的 SOP
不要写代码，就写自然语言步骤：
1. 拿到 [输入材料]
2. 先 [做什么预处理]
3. 然后 [提取什么信息]
4. 最后按 [什么模板] 输出
5. 注意 [什么坑不能踩]
你写出来的这个，就是 SKILL.md 的初稿。
第三步：丢给 Claude Code，跑一遍看效果
把你的 SOP 放到一个文件夹里，命名为 SKILL.md，补上 YAML 头部。然后在 Claude Code 里试一次。
第一次大概率不够好——没关系，这是正常的。看看哪里不对，改两行，再试一次。
做 Skill 和写代码一样：先跑出一个能用的版本，再慢慢打磨。
九、写在最后
写这篇文章的时候，我又回看了一遍那段 8000 字的会议录音转写——四个人讨论"团建去哪儿"，有说去郊区的，有说想住一晚的，有说当天来回的……
没有 AI 的话，整理这段文字需要至少 40 分钟，还不包括中间的走神时间。
现在，Skill 跑完大约 30 秒，人只需要花 2 分钟扫一眼确认关键信息没有丢。
重复的劳动不会消失，但它可以被封装。
你需要的不是更努力地"收到收到收到"，而是停下来花一个下午，给自己造一把更趁手的工具。
🔧 文中涉及的 Skill 基于 Claude Code + Anthropic Skill 生态。如果你也想动手试试，建议从 skill-creator 开始——它会手把手带你走完「意图 → 起草 → 测试 → 优化」的完整闭环。
记住那句核心的话：skill-creator 是一切 Skill 的源头。
文章写于 2026 年 7 月，基于真实项目实践。如果对你有帮助，欢迎点赞收藏，后续我会继续分享更多 AI 自动化实战案例。
