用Agent Skill把会议纪要整理效率提升15倍：手把手拆解与实战

不瞒你说我第一次看到“1小时会议整理90分钟”这个说法时差点以为是自己记错了。但这事真的常发生——会议本身才60分钟会后整理纪要、对着录音核对结论、再把待办事项一条条抠出来分给对应的人前前后后没一个半小时下不来。更烦的是这活儿本身没什么技术含量纯靠耐心硬扛而且做完了也没人有空夸你做漏了反而容易背锅。后来我换了个思路把整理会议这套流程抽成一个Agent Skill让AI Agent按照固定流程干活先转写、再提炼、然后按模板生成纪要和待办、最后我只需要花两三分钟过一遍。实测下来一场60到90分钟的会议从拿到录音到产出可用的纪要和待办清单差不多6分钟搞定效率大概提了15倍。这篇文章就把整个拆解过程、Skill写法和踩过的坑都放出来给同样被会议纪要折磨的朋友一个能直接抄作业的参考。1. 内容整体设计与思路拆解1.1 为什么整理会议纪要这么费时间先说个扎心的事实手动整理会议纪要的90分钟里真正花在“写字”上的时间其实不到20分钟剩下70分钟全消耗在四件事上——听录音找关键信息、去口语化、把讨论过程压缩成结论、再把散落各处的待办捡出来。我听下来最耗时的环节是“对号入座”。一场会五六个人每个人说的话都带口头禅和语气词翻来覆去说同一件事。你手动整理时得反复拖动进度条确认“这个决策到底是谁拍板的”“这事最后让谁跟进”。尤其是那种开了一个小时、聊了六七个话题的会议中间穿插着两句玩笑和三段沉默录音里一片嘈杂找信息的成本极高。另一块隐形耗时是“去口语化”。现场讲话本来就是跳跃的说的人自己都没意识到逻辑断点整理的人却要把这些碎片拼成通顺的文字。经常是录音里一句“那这块就按上次说的弄吧”你得往前翻三分钟才能搞清楚“上次说的”到底是什么。这些工作有个共同特点规则明确、重复性高、但需要耐心。这正是AI工具擅长的地方也决定了它完全可以用Agent Skill来接管。1.2 拆解Agent Skill它到底是个什么东西要搞懂Agent Skill可以把它想成“给Agent写的一本岗位SOP”。一个刚入职的助理你把工作要求口头交代一遍他大概率会做漏但你把工作流程、输出格式、判断标准写成一页纸给他他就能稳定执行。Agent Skill就是这页纸只不过读者不是人而是AI Agent。Skill和Agent的区别其实很清晰。Agent是那个“能动手的执行者”它负责理解任务、调用工具、决定下一步做什么而Skill是“执行特定任务的知识包”它告诉Agent面对某类任务时该按什么步骤来、该输出什么格式、该注意什么规则。打个不严谨的比方Agent是厨师Skill是菜谱。厨师可以同时会做很多道菜但他看菜谱做菜比凭感觉做菜稳定得多。很多人问skill和agent的区别我的理解一句话就能说完Agent是执行主体Skill是附着在Agent身上的标准化能力模块。一个Agent可以挂很多个Skill每个Skill负责一块特定的事——比如一个是会议纪要Skill一个是周报Skill一个是代码审查Skill。它们不冲突反而是配合关系。1.3 Agent Skill和MCP到底有什么区别这个问题我最近被问得特别多因为MCP这个概念也很热。我自己用下来的感受是MCP和Skill解决的是不同层面的问题。MCP解决的是“Agent怎么连上外部工具”的问题你可以把它理解成一套统一的插头标准。比如Agent需要读文件、查数据库、调用某个API通过MCP协议接上对应的ServerAgent就能像用自己手脚一样调用这些外部能力。核心是打通“连接”。Skill解决的是“Agent怎么把事情做对”的问题。它不关心你连不连得上某个工具它关心的是输入一段会议录音转写稿你按什么逻辑提炼结论、按什么格式输出纪要、待办里哪些字段必须填、什么语气算客观。核心是“方法论封装”。所以你说Agent Skill和MCP有什么区别一个是教Agent“怎么干”一个是帮Agent“接通工具”。实际项目里两者经常一起用MCP负责把录音转写、日历信息、文档系统接进来Skill负责规定转写稿进来之后怎么变成一份合格的会议纪要。1.4 为什么6分钟能搞定这15倍效率怎么算出来的先说时间账。以一场85分钟的会议为例我现在的工作流是这样的录音转写用现成的转写服务处理85分钟音频大约花2分钟左右纪要生成把转写稿丢给挂了会议纪要Skill的Agent生成初稿约90秒人工审核修订通读一遍、改两处措辞、确认待办归属约3分钟加起来大约6分半按90分钟的原始工作量来算确实是14到15倍左右的提升。这里有个关键点我并没有让AI全程无人工参与。恰恰相反我保留了“人工终审”这个环节。原因后面细说但先记住一个结论——Agent Skill能帮你的是把“输入到初稿”这段最枯燥、最耗时、最不需要创造力的环节压缩到极限但最终校对确认权还是在人手上。2. 核心细节解析与实操要点2.1 会议纪要Skill的需求拆解写Skill之前先搞清楚这活儿到底要产出什么。我的会议纪要Skill需求可以拆成三块第一结构化纪要。包括会议主题、时间、参会人、核心议题、关键决策。其中“关键决策”是重点要写清楚谁在什么背景下拍板了什么事不能模糊成“大家一致认为”。第二待办事项清单。每条待办必须包含四个字段事项描述、负责人、截止时间、优先级。如果会议里没明确说截止时间或优先级宁可标“待确认”也不要让AI硬编一个日期出来。第三风险与遗留问题。会议里经常会冒出“这个问题今天不讨论下次再说”或者“某件事可能会影响上线时间”这类信息容易在整理时丢掉但它往往很重要。基于这三个需求输出数据结构基本就定了。我选择了JSON作为中间格式而不是纯文本原因很简单JSON字段明确方便后续导入到项目管理工具也方便人工快速校对。2.2 写Skill时的三个关键设计决策第一个决策按议题切分内容不按时间顺序流水账。真实会议里同一个议题会反复回炉按时间线写纪要会显得非常散。Skill里我要求Agent先扫描全文识别出所有议题然后把分散的讨论内容归并到对应议题下再在每个议题里提炼结论。这一步是整理质量提升最明显的地方。第二个决策待办提取必须带上下文。很多AI生成的待办列表是“散装”的比如“优化登录页”“跟进合同”——光看字面根本不知道在说什么。我在Skill里强制要求每条待办必须先写一句背景再写具体行动最后标注负责人。这样就算隔了一个月再翻纪要也能立刻看懂当时发生了什么。第三个决策先给模板再让AI填内容。这个可能和很多人想的不一样——我并没有让AI自由发挥写纪要而是先定义好了模板框架再让AI把转写稿内容填充进去。这样做的好处是输出格式极其稳定人工校对时扫一眼就知道哪些字段是空的、哪些地方需要补充。模板化会牺牲一点文采但会议纪要这个场景稳定性比文采重要得多。2.3 在哪里运行这套SkillAgent平台选型现在市面上的Agent平台很多有些支持自定义Skill有些只支持固定Prompt模板。我个人的选型标准有三条一是支持Skill的独立配置和版本管理最好能把Skill文件导出成文本格式方便改版和备份。二是支持输出结构化数据尤其是JSON格式否则待办信息只能靠解析文本提取容易出错。三是支持自定义工作流编排这样能把“转写→纪要→待办→人工确认”串成一条自动化链路。我目前用的是支持这三项的平台。如果你手上的平台不支持完整Skill机制退而求其次的办法是把Skill内容写成一个超长、超结构化的System Prompt塞进Agent里效果会打点折扣但也能用。3. 实操过程与核心环节实现3.1 定义Skill的元信息和触发条件我习惯把Skill写成YAML格式的配置文件方便维护。核心字段如下name: meeting_minutes_skill description: 将会议录音转写稿整理为结构化会议纪要与待办清单 version: 1.2.0 trigger: - 用户上传会议转写文本 - 用户提供录音转写稿 - 用户输入“整理会议纪要” inputs: - name: transcript description: 会议录音转写文本 required: true - name: meeting_meta description: 会议主题、时间、参会人等信息可选缺省时由AI从上下文中提取 required: false outputs: - structured_meeting_minutes_json这里面有两个容易忽略的点。一个是description字段。这个字段不是写给人看的而是写给Agent看的。Agent在选择用哪个Skill时靠的就是这个描述和你当前请求的语义匹配度。所以描述写得越具体、关键词覆盖越全Skill被调用的机会就越大。另一个是trigger里尽量写全用户可能的表达方式。我一开始只写了“整理会议纪要”结果用户说“帮我看下今天会上聊了啥”时Agent就乖乖用了通用对话能力而不是这个Skill。后来把触发条件扩展开命中率才明显上来。3.2 核心Prompt模板的设计思路Skill的核心是一段精心设计的Prompt模板。我不想贴一整个模板占篇幅但有几个段落结构是值得说的第一段是角色设定。不要写“你是一个会议纪要助手”这种空话而是写“你是一名拥有多年工作经验的项目助理擅长从冗长的会议讨论中提取关键决策和可执行动作”。角色设定越具体语言风格和判断倾向就越贴合。第二段是任务流程。这一步是关键要拆成可执行的动作先通读全文识别议题再对每个议题提取讨论要点然后综合判断出关键决策最后提取所有待办事项。流程写得越细AI越不会跳步。第三段是输出契约。即前文说过的JSON结构。样例如下{ meeting_summary: { topic: 会议主题, date: 会议日期, attendees: [参会人列表], duration_minutes: 85 }, topics: [ { topic_title: 议题一标题, discussion_points: [要点1, 要点2], decision: 本议题形成的明确决策 } ], action_items: [ { task: 具体行动描述, background: 为什么做这件事, owner: 负责人, due_date: 截止时间或待确认, priority: high/medium/low } ], open_issues: [遗留问题或风险] }输出契约这块我想多强调几句你给AI定义的结构决定了它会关注什么信息。一开始我没让AI输出background这个字段结果待办全是“优化xxx”“跟进xxx”这种干巴巴的话完全没法直接用。加上背景字段之后质量提升了一个档次。第四段是few-shot示例。我会在Prompt里附上一小段会议原文节选和对应的标准输出让AI“照葫芦画瓢”。一开始我省了这一步结果AI输出的摘要风格偏散文和我的预期差很远。加了两个示例之后风格一下就稳住了。3.3 运行效果实测一份真实的纪要长什么样拿一场产品评审会的转写稿来演示。这段转写稿大约6000字内容涉及新功能评审、UI走查、排期确认、和一个正经的风险讨论。进入Skill后AI先生成了这样的纪要结构{ meeting_summary: { topic: 移动端3.2版本功能评审会, date: 2026-02-13, attendees: [产品经理林某, 前端张某, 后端王某, 设计李某], duration_minutes: 85 }, topics: [ { topic_title: 新版首页信息流改版, discussion_points: [ 改版目标是提高人均浏览时长, 前端反馈接口已就绪可提前联调, 设计师提供三种卡片的视觉备选方案 ], decision: 采用卡片方案B进行下一步开发后续再做AB测试对比 }, { topic_title: 分享海报功能排期, discussion_points: [ 分享海报需新增设计资源, 后端接口工作量约2人天, 运营希望赶在活动前上线 ], decision: 排期定在2月20日启动开发2月25日前完成联调 } ], action_items: [ { task: 输出新版首页三种卡片的完整设计稿, background: 首页信息流改版需要视觉方案支撑, owner: 设计李某, due_date: 2026-02-16, priority: high }, { task: 和运营确认分享海报文案及活动时间节点, background: 分享海报功能排期依赖于运营活动时间, owner: 产品经理林某, due_date: 2026-02-15, priority: medium } ], open_issues: [ 后端反馈分享海报接口的并发压力需要压测确认 ] }从拿到转写稿到产出这份JSON实际耗时约110秒。我花了两分钟做人工校对改了一个参会人名字的错别字把“2026-02-16”这个截止日期从“待确认”改成了明确日期。整体可用度很高。这里要说明一下第一次跑的时候结果没这么顺。AI把“待办”和“讨论要点”混在一起还自己脑补了一个“发起用户调研”的任务出来。后来排查发现是因为Prompt里没有强调“待办必须来自参会人的明确表态或共识”AI把属于“讨论”的内容也当成行动项了。在输出契约里加了一条约束——“只有出现明确责任人或者共同决策的工作才允许列入action_items”问题就消失了。3.4 把Skill接入到日常工作流的完整链路Skill本身只是“能力模块”真正提效还得靠链路。我的日常链路长这样开会用手机录音关进一个固定的文件夹开完会直接把录音文件发给配置好的Agent工作流工作流第一步调用转写服务生成带时间戳的转写稿转写稿自动进入会议纪要Skill产出JSON工作流再把JSON渲染成两种格式一份Markdown纪要存到文档系统一份待办表格同步到任务管理工具最后推一条消息给我附上PDF预览链接整个过程从“把录音丢进去”到“收到完成通知”正好6分钟左右。人工介入只有最后一步打开预览链接快速过一遍确认没问题后点发布。这套链路配好之后我基本告别了“晚上回家对着录音整理纪要”这个动作。最有价值的不是省下的时间而是整理会议纪要这件事从“每天要做的负担”变成了“顺手确认一下的小事”。4. 常见问题与排查技巧实录4.1 AI把口语内容过度润色纪要反而失真了这个问题我第一次用Skill时就遇到了。AI把“那个新功能嗯就是那个首页的贼好看”润色成“参会人对首页新功能的视觉效果给予了高度评价”看完差点笑出来——但这要是发出去就是严重失实。排查下来问题出在Prompt里“语言精炼通顺”这个要求上。AI为了追求表达优美擅自补充了原文没有的评价色彩。解决办法有两个方向一是在Prompt里显式声明“不得添加原文未提及的观点、评价或数据”这条红线卡得非常有用。二是在输出契约里加一个字段speaker_said要求提取每个核心观点时附上说话人的原话片段作为依据。这样AI就不敢乱发挥因为原话就在旁边一对比就露馅。4.2 待办提取出现“假任务”所谓“假任务”是指AI把“可以考虑优化一下”“后续再看”这类开放性话题提取成了待办。这类任务根本没有明确负责人和责任时间提取出来只会污染待办列表。我的排查思路是在输出契约里做约束action_items里每条必须有owner字段且owner必须是转写稿中出现过的人名如果找不到明确负责人该条就不允许出现。同样的规则也适用于due_date——宁可写“待确认”也不要凭空生成一个日期。加了这条规则之后待办数量会明显减少但每一条都真实可执行。后来我发现这也是15倍效率能立住的关键之一省去人工筛选假待办的时间比生成纪要本身的提速更值钱。4.3 长会议内容太多、模型处理不全一场90分钟的会转写稿可能超过一万字。有些模型的上下文窗口有限或者处理到最后时“忘了”前面聊了什么导致纪要后段信息密度明显低于前段。这个问题我用两种方式处理。第一种是分段处理把长转写稿按时间戳切成两段每段分别进Skill生成局部纪要和局部待办最后再用一个Merge步骤把两部分合并、去重、排序。第二种是升级到支持更长上下文的模型版本但这看预算和平台支持情况不是人人都能选。如果只能用短上下文模型我会倾向于“分段合并”方案。好处除了解决长度问题还能顺便降低生成延迟因为每一步处理的数据量更小。4.4 平台不支持JSON结构化输出怎么破有些Agent平台或模型的输出不强制JSON经常会出现“有头无尾”或者“尾括号丢失”的情况。我提供两个应急方案第一个是在Prompt里给JSON示例并明确要求只输出JSON代码块不要任何解释文字。实测命中率能到八成以上剩下的靠后续解析时的容错逻辑兜底。第二个是解析端做容错提取转写稿代码块中的JSON片段然后用一个轻量的字符串修补逻辑补全缺失的括号。这不是最优雅的方案但作为兜底足够实用。我在处理早期版本Skill输出时靠这个方法救回了大量“半成品JSON”。4.5 快速自检清单让你的Skill一次跑通根据自己的实际经验我整理了一份会议纪要Skill的自检清单上线前逐项过一遍能少踩很多坑触发条件列够不够全用户说“整理一下”“会议记录”“刚才会上聊了什么”能不能命中输出契约里每个字段是否有说明或示例尤其是owner、due_date这种容易乱填的字段是否显式禁止了“添加原文没有的信息”这一条没写后患无穷有没有few-shot示例没有示例的Skill风格稳定性完全靠运气解析端对JSON格式错误有没有容错建议至少做一层兜底人工终审环节是否保留Skill再强我也建议不要让AI直接对外发布纪要5. 这套路能不能复制到其他场景写到这里可能有人会想会议纪要是个小场景这套方法论是不是有点大材小用其实反而相反。我选会议纪要来拆解是因为大家对这个场景都有体感容易理解。但“Skill”这套思路换到别处一样能打。前几天有个做前端的朋友在群里问“前端AI辅助编程好用的skill和agent有哪些”我就发现很多人其实已经在用类似的思路了只是没有系统总结过。前端开发的Skill可以封装成“页面结构审查Skill”“组件代码规范Skill”“接口联调检查Skill”。每个Skill都是一套判断规则加输出契约让Agent从“会写代码”变成“写你们团队风格的代码”。还有人问“Agent做项目是不是需要很多个Skill”。我的答案是起步阶段不需要多但每做一个复杂场景就该沉淀一个对应Skill。我一开始只有一个会议纪要Skill后来陆续加了周报Skill、复盘Skill、需求文档Skill。每个Skill都是用过才有手感一次性规划几十个Skill很容易沦为摆设因为很多细节你根本没想清楚。我个人现在的体会是Agent Skill最大的价值反而不是“快”而是“稳”。它把一次性的、靠运气的好发挥变成了可复现的、每次都好用的稳定输出。这个价值在会议纪要这种高频、低容错的任务上体现得最明显。如果你也有那种“每天都要做、不做又不行、做了又没人夸”的重复劳动不妨试试给它写一个Skill体验一下6分钟搞定90分钟工作的感觉。