开完会那半小时，才是真正让人崩溃的开始。
会议本身一小时，散会后整理纪要、抠待办、回看录音重点，零零散散又搭进去一个半小时。这不是个例，是几乎所有职场人都在反复经历的时间黑洞。我试过各种所谓效率工具，模板做了一堆，最后发现问题的核心不在"记录"，而在"整理"。直到我把整理纪要这件事交给 Agent Skill 来做，才真正把这个流程从 90 分钟压到了 6 分钟。这篇文章就聊聊我实际搭建和使用的过程，包括 Agent、Skill、MCP 这几个概念到底什么关系，以及为一个具体场景设计 Skill 时真正该注意什么。
1. 为什么整理纪要比开会还累：拆解会议收尾的真实工作流
很多人觉得会议纪要不就是把录音转成文字吗？真这么简单，市面上早就没有这个痛点了。我自己拆了一下整理纪要的全流程，发现里面至少有五个隐性环节在拖时间。
1.1 转写之后的"二次翻译"才是时间大头
录音转文字只是第一步，而且是最不需要脑子的那一步。真正的耗时在于把口语化的、逻辑跳跃的、穿插着闲聊的原始文本，转成"可以发给别人看"的结构化文档。
举个例子，会上有人说："那个，下周那个客户方案，老张你抓紧弄一下，然后跟小李那边对一下，费用方面再跟财务确认确认。"这句口语如果直接贴进纪要里，基本等于没写。你需要自行脑补：这是哪个客户？方案要什么时间节点给到？"跟小李对一下"是指确认什么内容？费用确认的截止日期是谁来定？这中间的信息补全和逻辑串连，才是最消耗精力的地方。
另一个被严重低估的时间点是"分类"。一场 1 小时的会议，有效决策可能就两三条，但这些决策往往淹没在十分钟的讨论中。你得在转写文本里来回翻找，才能定位到"这条到底算正式结论，还是只是某个人的随口提议"。这个筛信息的过程，本质上就是在做一次非正式的文本挖掘。
1.2 待办提取的高遗漏率问题
整理过纪要的人都有这种经验：会议开完觉得自己记住了所有待办，真到写的时候还是漏。特别是当待办不是按人分配，而是散落在讨论过程中时——张三提了个想法，李四补充了两句，王五说"那这个我来跟"，最后形成的结论和最初的话题已经隔了三层。
传统纪要工具最大的问题就是"只记录不追踪"。它能帮你把文字整理好，但不会主动告诉你"这里头藏着一个待办"。所以大部分人的做法是：先通读一遍文稿，自己先做一次待办标注，再手动整理到任务管理工具里。两个工具之间来回切换，每切换一次都是时间和注意力的损耗。
1.3 90分钟到底耗在哪里
我自己测试过，用传统的"转写 + 手动整理 + 手动录待办"流程处理 1 小时会议：
- 听录音补全信息约 30 分钟。越是内容重要的会，越不敢快进。
- 结构化整理约 25 分钟。要在空文档里搭框架、填内容、调整语气。
- 提取和校对待办约 20 分钟。反复确认"这条到底是不是承诺了负责人"。
- 格式排版和发送约 10 分钟。把纯文本变成好看的邮件格式，顺手改几处错别字。
如果赶上会议内容本身存在分歧没达成共识，或者有大量技术细节需要精确描述，时间还会进一步膨胀。90 分钟其实是保守估计，复杂项目周会整理一两个小时很常见。
这也是我后来转向 Agent Skill 的核心动机——转写后的整个"整理"链条，本质上是一个高度规则化、模式化的信息处理流程，完全具备被自动化替代的条件。
2. Agent Skill 到底是什么：一个 Skill 加进 Agent 的完整过程
在分享具体操作前，先把概念理清。最近 Agent Skill 这个词热度挺高，但不少人把它跟 Agent 本身、跟 MCP 混为一谈。我用一个特别生活化的比喻来理解这三者的分工。
2.1 Skill、Agent、MCP 的关系：从零搭建一个"实习生"
把 Agent 想象成一个刚入职、理解能力很强但什么都不懂的实习生。他会用各种工具（MCP 提供了这些工具，比如打开浏览器、查询日历、发消息），但他不知道"整理会议纪要"这件事具体该怎么做，才算干得漂亮。
Skill 就是写给他看的"岗位工作手册"。手册里写了做这件事的完整步骤、判断标准、输出格式、注意事项。他拿到手册，再调用手边的工具，就能把活干出来。
MCP 呢，相当于给他接通了公司内部的各个系统权限。没这个权限，他想查公司通讯录都查不了。所以可以简单理解成：
- MCP 解决的是"手能伸多长"的问题（工具层）
- Skill 解决的是"活能干什么样"的问题（方法论层）
- Agent 解决的是"怎么调度这一切"的问题（执行层）
实际使用中，Skill 通常是一个包含指令文件的文件夹，里面写清楚"当用户提出某类需求时，你按如下流程执行"。Agent 在收到用户请求后，会根据请求内容匹配对应 Skill，然后在 Skill 的引导下调用合适的 MCP 工具完成工作。
2.2 会议纪要场景：这个 Skill 管住了 Agent 的哪几个关键环节
针对"会议纪要 + 待办提取"这个场景，我的 Skill 做了一件事：把之前说的那个 90 分钟的隐性工作流，全部显性化为指令规则。它管住了四个关键环节：
第一，角色预设。它会告诉 Agent，你现在是资深会议记录官，输出风格是"结构化但不失口语化温度"，不是简单复述，而是提炼核心信息。
第二，信息分层规则。它定义了纪要必须包含哪些区块：会议基本信息、关键讨论摘要、明确决议、待办事项、风险与开放问题。每个区块有各自的生成标准，比如"待办事项必须包含负责人、截止时间、是否明确承诺"。
第三，原文引用规则。这个非常关键。Skill 会规定 Agent 在从原文中提取某个观点时，如果要归纳转述，必须附带原话片段，防止 Agent 自己脑补内容或歪曲原意。
第四，遗漏率控制。Skill 里强制内置一道"查漏补缺"流程，让 Agent 在生成完整纪要后，再对照原始转写文本做一次交叉检查，专门查找那些散落在对话缝隙里、容易被漏掉的隐性待办。
你看，整个 Skill 的核心思想就是一条：把"资深助理"处理纪要知道的一切隐性门道，全部明明白白写进工作手册里。
2.3 手动加一个 Skill 的真实操作画面
具体到操作层面，不同 Agent 平台的 Skill 添加方式略有差异，但底层的目录结构基本通用了。我在用的方案是创建一个以 skill 命名的文件夹，里面包含一个用于描述 Skill 能力与触发条件的说明文件，以及一个核心指令文件。在核心指令文件里写清楚：
- Skill 的名称和适用场景
- 触发器（什么情况下该启用这个 Skill）
- 完整执行流程（按步骤编号展开）
- 每一步的输入输出要求
- 质量标准与自查清单
把这个文件夹放进 Agent 平台的指定目录里，系统就能自动识别并加载。加载后，我在发起会议整理请求时，即使只是简单说了一句"帮我把这份转写稿整理成纪要和待办"，Agent 也能自动匹配到这套技能，而不是把它当成一次普通的问答来处理。
从我实际测试的结果来看，加了 Skill 和没加 Skill 的差距不是一星半点。没加 Skill 时，它的输出更像"一段整理得比较清楚的文字"，有逻辑但缺少会议纪要特有的严谨结构，待办提取基本靠运气；加了 Skill 之后，输出的完整性、精准度和可用性都判若两人。
3. 从零搭建"会议纪要 Skill"：核心提示词模板与执行链路
概念说完了，直接上实操。我把这个 Skill 的核心内容做了一个脱敏简化版，它的结构基本能覆盖绝大多数会议纪要场景。你不需要完全照抄，可以根据自己的会议类型（比如周会、需求评审会、客户沟通会）来调整。
3.1 让 Agent 知道"什么时候启动"：触发器设计
整个 skill 文件里，我第一块写的是技能描述和触发条件。别小看这一段，它决定了 Agent 在什么情况下会主动用这个手册。
- 技能描述：适用于将会议录音转写文本整理为结构化会议纪要与待办清单
- 触发条件：输入内容为会议转写文本，或用户明确要求整理纪要、提取待办时
- 输出格式：Markdown 结构化文本，包含"会议信息、讨论摘要、决议事项、待办清单、遗留问题"五个区块
这样写的目的是给 Agent 一个明确的"匹配信号"。我测试过，只要触发条件写得足够清晰，基本不会出现该用的时候没用、不该用的时候乱用的情况。
3.2 纪要生成主环节：五段式输出结构
核心执行流程是整个 Skill 的心脏。我把它拆成了五步：
第一步：通读转写文本，提取会议基本信息。包括会议主题、参会人（从对话中推断）、会议时长，这个阶段不做任何归纳，只做信息的直接摘录。
第二步：梳理关键讨论内容。按"话题-观点-核心信息"三层结构整理，每条摘要尽量控制在 100 字内，必须附带原文锚点（原话片段），不能出现原文没有的信息。
第三步：识别明确决议。判定标准是我在 Skill 里专门定义的"决议三要素"：有明确的动作指向、有明确的负责人指向、有明确的结论性措辞（比如"就这么定了""按这个方案来"）。只有同时满足两个以上要素的内容才能进决议区，有效过滤掉大量讨论型噪音。
第四步：提取待办清单。每条待办必须包含负责人、事项描述、截止时间三类信息。这里我特别加了一条引申规则：如果原文出现了"我跟一下""我来反馈"这类模糊责任表述，统一标记为"需向相关人员确认"。
第五步：输出遗留问题。把那些讨论了很久但没有结论、或者明显需要后续专门会议再碰的话题单列出来，避免它们消失在大段讨论文本中。
3.3 二次复查环节：防止 Agent "自信地胡说"
这是我最看重的一步，也是踩了好几次坑之后总结出来的。
第一次测试时，我用的流程是"读文本 → 生成纪要"，结果发现 Agent 在补全信息时偶尔会自作主张加入一些原文根本没出现过的描述，比如自行推断某个任务的截止日期。这在专业纪要里是大忌。
所以在流程的最后，我强制追加了一个"交叉校验"环节：让 Agent 对照原始转写文本逐条检查自己的输出，凡是无法在原文中找到对应锚点支持的内容，必须删除或标注为"推断内容"。
我还设置了置信度标注规则。对于从原文中明确提取的信息，标记为"高置信"；对于因为口语模糊或信息不全而做的推断，标记为"中置信"并附备注说明。这个细节让最终纪要的可用性大幅提升。
3.4 一句话触发完整链路的妙处
整个流程设计完之后，一句话就能跑通全场。比如我会说：
"帮我把下面这段会上的转写记录整理成正式会议纪要，提取所有待办，按人归好类。确认不清的内容不要猜测，标注待确认。"
这么一句简单指令，就能让 Agent 完整走完上面的五步流程和交叉校验，最终输出一份结构完整的纪要。从把转写文本丢进去到结果出来，大概只需要几分钟，后面需要人工介入的，只剩下"对个别表述做润色"或者"补充真实语境里才知道的细节"。
4. Skill 设计的通用方法论：一个项目需要多少个 Skill 才算合理
聊完了具体实现，我想把视角拉高一点，说说 Skill 设计这件事本身。热搜词里有一个问题特别典型："agent 做项目是不是需要很多个 skill？"这个问题我一开始也困惑，实际用下来之后有了比较清晰的判断。
4.1 前端编程场景的反思：Skill 是"岗位手册"，不是"问题答案"
我最早入坑时也犯过贪多求全的毛病，给 Agent 塞了一堆场景的 Skill，以为越多越强。后来发现，真正让前端辅助编程变得好用的 Skill，核心不在"多"，而在"精准定义了这个岗位该有的工作方式"。
比如前端场景里一个好用的 Skill，它管的不是"怎么写某个组件"，而是规定了这个项目里代码的输出边界：怎么组织目录、哪些逻辑必须抽取成公共函数、提交前如何自测。这和会议纪要 Skill 的思路完全一致——它约束的是一套流程和标准，不是某个具体问题的答案。
所以我觉得更合适的思路是：按"角色"而不是按"任务"来规划 Skill。同一个角色（比如前端工程师）的编码 Skill 只有一个，但在这个 Skill 内部可以涵盖多类编码任务的标准流程。会议纪要也是一样，我只需要一个"会议纪要整理"这个角色，而不是给"周会纪要""评审会纪要"各做一套。
4.2 Skill 的最优粒度判断标准
怎么判断粒度合不合理？我用三个问题来自检：
- 这个 Skill 是否描述了一类稳定重复出现的任务？如果只是某个一次性的需求，不值得做。
- 这个 Skill 是否包含了一套完整的执行方法论，而不只是输入输出规则？如果一个问题就能问清楚，说明它太单薄，不适合做成 Skill。
- 这个 Skill 是否会和其他已有 Skill 产生大量内容重叠？重叠多了，Agent 会不知道该用哪个。
如果三个问题都回答正确，说明这个 Skill 的粒度是合理的。否则就继续拆分或合并。一般来说，一个项目主要角色的核心工作流，每个对应一个 Skill 就足够应对绝大多数场景了，最多不超过两三个。
以我自己的项目经验来说，用的最顺的 Skill 配置通常是：一个面向业务场景的"流程型 Skill"，一个面向技术质量的"标准型 Skill"，偶尔再加一个面向特别复杂场景的"专项型 Skill"。三个 Skill 之间各有领地、互不重叠，Agent 调度起来非常清爽。
4.3 和 MCP 的分工边界：什么该做成 Skill，什么该做成工具
最后再补一刀，把 Skill 和 MCP 的边界说透。很多人纠结同一件事既能通过 Skill 实现，也能通过 MCP 工具实现，到底是走哪条路？
我的经验是：凡是"需要做判断、定流程、走步骤"的，放进 Skill；凡是"单纯的功能调用、数据获取、系统交互"的，做成 MCP 工具。
会议场景就是一个最好的例子：把转写文本整理成纪要，这中间有大量判断和流程组织，一定要用 Skill；如果 Agent 需要主动把成型的纪要按照固定格式写进某个项目管理工具的"议事纪要"字段里，这种对接动作才需要 MCP。前者管脑子，后者管手。
这两个配合好了，Agent 才能真正意义上从"理解需求"一路干到"落地执行"，而不是只停在"给你一段好看的文字"。
5. 6 分钟背后的实测数据与那些不为人知的坑
光讲方法论没有说服力，我把自己真实跑过的测试数据和踩坑记录列在下面，供你参考。
5.1 三组典型会议转写文本的实测结果
我准备了三份不同类型的测试文本，每份都是从真实场景脱敏改写的，长度接近一小时会议的转写量。
第一份是项目周会，特点是信息密度高，有大量进度同步和风险反馈，但决议少，待办分布很散。传统方式我预计整理加复核需要约 85 分钟，Skill 生成核心内容耗时约 5 分钟，人工校对微调大约 8 分钟，整体流程对比下来快了接近 7 倍。
第二份是客户需求沟通会，口语化内容极多，大量关于方案的反复讨论，还有几处相互否定的对话。这种文本最考验 Agent 的信息梳理能力。Skill 生成后我核对了一下，调研范围描述和最终决策内容全部正确，但有一处"负责人到底是张工还是李工"的判断需要人工介入确认。
第三份是内部技术评审会，充满了术语和简称。这里踩到了一个明显的坑：Agent 会把某些简称的潜在指向搞混，尤其是同一个简称在上下文里有两个含义的场景。后来我在 Skill 的说明文件里补充了一条规则：凡是遇到专业术语和简称，优先参考上下文中的说明性语句，无法判断时标注"术语指向待确认"。
三组数据加起来，单份转写文本用 Skill 生成加人工校对，耗时基本控制在 6 到 8 分钟，对比 80 到 90 分钟的传统流程，确实做到了 15 倍左右的效率提升。
5.2 绕开"看着合理其实错了"的隐性坑
最隐蔽的坑不在生成环节，在"看似合理实则错误"的误导性输出。有一次处理一份讨论预算分配的会议，原话是"主要费用还是压在采购这块"，Agent 在纪要里悍然写了一句"预算重心为采购部门"，仔细对照上下文，这句话的本意是在探讨成本归集方式，并不是在做部门归属定论。这类错误很难通过格式规范来规避，只能靠"交叉校验 + 置信度标注"来让读者注意到这种推断属性。
所以我也调整了心态：Skill 的价值不是让 Agent 取代你做判断，而是让它把 80% 的机械整理工作做到完美，让你把自己的精力全部集中在真正需要经验判断的那 20% 上。
5.3 真正提升体验的三个细节
最后分享三个对效果影响最大的细节。
第一个，转写质量决定纪要质量，建议用专业会议转写工具生成原始文本后再投喂给 Skill，而不是用现场收音较差、大量重叠语音的录音直接让 Agent 处理，否则再好的 Skill 也会被输入噪音拖垮。
第二个，Skill 不是一次写死的，要和 Agent 磨合。我第一次跑出来的纪要和现在的版本差别极大，中间调了好几轮，每次发现问题就回到 skill 文件里补一条规则。它是不断生长的，不是一锤子买卖。
第三个，提交任务前别偷懒，一句话指令最好带上"确认不清的内容不要猜"这个约束条件。这个看似多余的叮嘱，能让 Agent 的输出容易被校验的可靠度大幅提高。
会议纪要只是一个例子。凡是那些"你闭着眼睛也知道该怎么做、但就是不想亲自做"的重复性工作，都值得为它写一个 Skill。把一个小时压缩成六分钟，省出来的时间用来干什么不好？
