上周我开完一场 1 小时的方案评审会散会时我下意识看了一眼时间心头一沉。脑子里已经有画面了回听录音、拖进度条、把零散讨论拼成纪要、再给十几条待办逐条找负责人这一套下来今晚九点前别想下班。这种“会开 1 小时整理 90 分钟”的体验每个被塞过会议纪要活的人都不会陌生。不过这一次我只花了 6 分多钟就拿到了完整纪要加待办清单。秘诀不是换了什么新笔记软件而是我把自己那套 AI Agent 工作流里的“会议纪要 待办整理”封装成了一个可复用的 Agent Skill。如果你经常开会、需要输出纪要和待办或者一直没搞明白最近铺天盖地的“Agent Skill”和 Agent、MCP 到底什么关系这篇可以当一份实战参考。接下来我会把完整方案拆开讲Skill 为什么能省这么多时间、它和 Agent 与 MCP 怎么分工、一个能跑的会议纪要 Skill 内部长什么样、实测数据以及我踩过之后才调明白的几个坑。1. 为什么整理一次会议纪要会吃掉 90 分钟1.1 时间都花在哪了很多人以为整理纪要就是把语音转成文字、删掉“那个那个”就完事了所以不理解怎么会花 90 分钟。但实际做过的人清楚一次 1 小时会议的转写文本大约有 1.1 万到 1.5 万字真正的问题在于信息密度极低但关键信息你一条都不敢漏。我自己梳理过手写纪要的 90 分钟大概是这样被吃掉的回听定位约 25 到 30 分钟。录音里找某个结论你得反复拖进度条听三五遍才确定发言人当时说的到底是“下周三”还是“周三前”。口语转书面约 15 到 20 分钟。把带口头禅、语气词、半截话的原始表达转成别人看得懂的书面语这个活比想象中费神。信息结构化约 30 分钟。散乱的讨论要按议题重新排区分“背景、结论、分歧、待办”这是整个环节里脑力消耗最大的部分。待办分发约 15 到 20 分钟。核对每条待办的责任人、截止时间、优先级写清楚验证标准否则发出去没人认领。这几项加起来轻松破 90 分钟。而且这个活往往发生在你“已经开完 1 小时会”之后注意力早就透支了越往后越容易漏漏了还要返工。1.2 现成工具做不到的事这几年的语音转写工具确实把“回听定位”这部分省掉了但直接拿来用还是差一口气转写工具给你的是“白描文本”谁说了什么都有但没有结论、没有待办等于是把原材料递给你饭还得你自己做。通用 AI 总结工具把一万多字全文塞进去效果不稳定经常把重点淹没在大段背景里。而且每个团队的纪要结构和待办习惯都不一样通用模型不认你的规范。会议平台自带的纪要功能前提是你每次都在那个平台开会并且愿意把敏感内容交给外部服务处理。所以我把目光从“找一个更听话的笔记软件”转到了“把我自己的整理能力做成 Agent 的一项 Skill”。这个转向才是效率提升的根本原因。2. Agent Skill 到底是啥和 Agent、MCP 的边界2.1 Skill 的本质把“会干活”变成可复用的资产先给结论Skill 不是一个聊天对话框也不是一句“帮我总结一下会议”的普通提示词。它是一个结构化的任务能力包通常包含四样东西任务描述这个 Skill 处理哪一类任务、在什么条件下使用。处理流程先做什么、后做什么的分步指令。输出协议产出什么格式Markdown 或 JSON字段有哪些。可绑定的工具读写文件、调用 API、创建待办等。你可以把 Skill 想象成一位老员工手里的“工序卡”。老员工闭着眼都能干是因为工序已经内化成了肌肉记忆新人照着工序卡也能干出七八分。Skill 的作用就是把内化的干活方式显性化让 Agent 在不同项目里反复复用同一套标准。我最早接触这个概念时也觉得挺虚但一旦你把任务拆成“输入、处理、输出”Skill 就不再神秘了它就是一个可执行的流程定义加上约束。2.2 Skill 和 Agent主厨与工序卡很多人问Skill 和 Agent 到底啥区别是不是一回事不是。Agent 是一个目标驱动的执行主体它的特点是自主决策给定一个目标它会拆解任务、选择工具、多轮试错。Skill 则是 Agent 调用的一项具体能力负责解决“某类任务该怎么干”。这里拿做菜来类比比较直观Agent 是主厨负责今天出哪些菜、先做哪道、火大了就调小。Skill 是“宫保鸡丁的标准工序卡”里面写清楚鸡丁怎么腌、料汁怎么配、什么火候出锅。MCP 是传菜口和厨房设备的接口标准主厨说“开烤箱”传菜口知道怎么把指令翻译成烤箱能听懂的信号。所以一个 Agent 做项目往往需要很多个 Skill 协同有的负责拆解需求有的负责生成代码有的负责写纪要有的负责发消息。Skill 越多Agent 在对应领域的“手艺”越精细。这也是“Agent 做项目是不是需要很多 Skill”这个问题的答案是的按任务板块拆能力边界越清晰越好。2.3 Skill 和 MCP手艺与接口Skill 和 MCP 是被问得最多的一组概念。可以这样分MCPModel Context Protocol解决的是“Agent 手能伸到哪”文件系统、数据库、第三方 API、会议系统都是通过这层标准化协议接入的。它更多是传输和连接层的东西。Skill 解决的是“这个活怎么干才漂亮”。同样是拿到一份转写文本有人直接让模型总结结果一团乱麻而 Skill 定义的是先清洗、再切议题、再抽结论、最后提炼待办的完整工序。实际配合方式是MCP 负责把会议文件、任务清单应用等外部资源接到 Agent 环境里Skill 负责规定“拿到资源之后怎么处理”。一个偏“连接”一个偏“手艺”两者不是同一层的东西也不互相取代。维度AgentSkillMCP本质目标驱动的自主执行主体单类任务的标准工作流加约束模型与外部工具、数据源的标准化接口回答的问题这个目标怎么做这类活怎么干才标准指令怎么安全触达外部资源类比主厨工序卡传菜口和设备接口依赖关系调用 Skill并通过 MCP 连外部工具可被 Agent 按需选择被 Agent 用来连接和操作外部系统理解了这层关系再看“会议纪要 Skill”你就明白它不是玄学而是把“怎么整理一个会议”这件具体的事标准化成了 Agent 能稳定执行的能力。3. 落地一版会议纪要和待办 Skill从协议到流水线3.1 先定输入输出别上来就堆 Prompt很多人设计 Skill 时第一步就开始写提示词这是错的。我建议先把输入输出边界定清楚否则后面会反复改。我这一版 Skill 的输入如下会议录音转写文本纯文本或 SRT 格式通常 1 万到 1.5 万字。会议主题可选但加上更稳。参与人名单可选用于角色映射。输出偏好纪要结构和待办格式。输出方面我选择“Markdown 给人看 JSON 给机器用”双通道Markdown 方便直接贴到文档或工作群JSON 方便下游程序自动创建任务、同步到项目管理工具。JSON 结构大致是这样的{ meeting_meta: { topic: 官网改版方案评审, duration_minutes: 51, date: 2025-06-10 }, sections: [ { topic: 新版首页方向确认, conclusion: 确定优先保首屏加载速度采用 A 方案, divergence: [图片素材风格仍未定], open_questions: [预算审批时间待确认] } ], action_items: [ { summary: 输出新版首页线框稿, owner: 小李, due: 2025-06-13, priority: high, acceptance: 在 Figma 产出三个方向线框并附优缺点说明 } ] }这样设计的好处是字段稳定下游好解析待办可以直接转成任务卡不用二次复制粘贴。3.2 六步处理流水线定完协议再把处理过程拆成六个步骤。这六步是我反复试出来的步骤太多会拖慢速度太少则输出不稳定。文本清洗去掉“呃、那个、就是说”等语气词把重复的半截话合并。这步不做后面所有步骤都会被噪声干扰。发言人归一转写文本里的 Speaker 0、Speaker 1 要映射到真实人名。没人名就先占位等人工校验时替换。粗切议题按语义断点和关键词把 60 分钟内容切成若干议题块。这一步决定了纪要大纲切分质量直接影响后面的结论提取。逐块精读对每个议题块抽取背景、结论、分歧点、待定项。要求模型必须引用原文片段作为依据。决策与待办提取把“谁能做、什么时候做、做到什么标准”单独提炼出来转成 action items。合并去重与排序多个议题块可能出现重复待办按负责人归并、按优先级排序最终输出。每一步都很关键。尤其第 4 步我要求“每条结论对应原文引用”这就是后面防幻觉的关键钩子。3.3 核心 Prompt 模板下面是我当前在用的 Skill Prompt 骨架你可以直接拿去改。核心是“流程强制 输出格式强制 事实锚点强制”。# 角色 你是一名资深的会议记录整理专家擅长从嘈杂的会议转写文本中抽取结构化信息。 # 任务 根据用户提供的会议转写文本生成一份包含会议纪要和待办清单的 Markdown 文档以及一份结构化的 JSON 数据。 # 处理步骤 1. 清洗文本去掉语气词、重复词、口误标记保留原始信息完整性。 2. 角色归一如果文本带有 Speaker 标记结合用户提供的参与人名单进行映射无法确定时保留占位符。 3. 议题切分根据讨论主题的切换将全文切分为若干议题块为每个议题块命名。 4. 逐块提取对每个议题块提取背景、结论、分歧、待定项每条结论必须引用原文句子作为锚点。 5. 提炼待办找出明确需要有人跟进的事项。每条待办必须包含负责人、截止时间、优先级、完成标准。使用动词开头。 6. 汇总统稿去重、排序、按优先级组织输出。 # 输出要求 - 待办必须具体到可执行禁止出现跟进一下处理一下这类无法验收的表态。 - 没有明确出现的事实不得写成结论只能标记为待确认。 - 输出包含 Markdown 纪要和 JSON 数据两部分。 # 事实锚点 每条结论和待办都必须附上源出处的简短引用便于人工核验。这个模板并不复杂但“事实锚点”和“禁止无依据结论”这两句是输出质量的命门。少了这两句模型会表现得像一个特别爱加戏的会议记录员。3.4 工具绑定与触发方式Skill 不一定要绑一堆工具但绑对了能少走很多弯路。我这边绑了三个文件读取读取转写文本支持纯 txt 和 SRT。Markdown 输出自动把纪要写入指定文档目录。待办同步通过 MCP 接到任务管理应用把 action_items 直接创建为带负责人和截止时间的任务卡。触发方式有两种一种是在对话里输入“整理会议纪要”并附带文件另一种是配置监听目录一旦有新转写文件进来Agent 自动调用这个 Skill 处理。第二种更像“管道”特别适合每周固定例会。4. 实测1 小时会议6 分钟拿到纪要和待办4.1 测试场景准备上个月我拿一次真实的“官网改版方案”评审会做了测试。会议时长 51 分钟4 个发言人转写文本约 1.2 万字。我特意选同一场会议做对照实验会议结束当晚我用 90 分钟手动整理了一份完整纪要和待办清单第二天我把同一份转写文本丢给 Skill 跑完整流程。两次产出一对比问题出在哪、省在哪里都很清楚。4.2 运行过程与耗时分布运行前我做了点准备给 Skill 喂了会议主题、参会人名单小李、阿哲、Mia、我指定了输出偏好。整个流程如下丢入 1.2 万字转写文本后Agent 先做清洗和发言人归一大概 30 到 40 秒。议题切分把 51 分钟内容切成了 5 个议题块包括“新版信息架构”“视觉风格”“首屏性能目标”“内容迁移范围”“上线时间与风险”。逐块提取结论和分歧耗时最长大约 2 分 10 秒。提炼待办去重排序生成 Markdown 和 JSON约 40 秒。我人工通读校验修正两处角色归错和一处表述约 2 分钟。从丢入文本到最终可用稿机器处理约 4 分钟出头加上人工校验 2 分钟总耗时 6 分钟左右。对比前一晚的 90 分钟效率提升约 15 倍。这里有一个诚实的补充这 6 分钟里有 2 分钟左右是人工校对不是完全甩手。但这已经足够说明问题因为最耗精力的“结构化、找结论、制作待办”这三块机器全包了。4.3 产出长什么样简要看一下产出。Markdown 纪要部分的一个切片## 议题 2新版首页视觉风格 - 背景目前首页转化率偏低团队怀疑是主视觉信息层级不够清晰。 - 结论确定走大留白、强焦点的方向首屏核心动作按钮不超过两个。 - 分歧Mia 建议采用深色背景突出产品质感小李认为深色可能影响浏览型用户阅读效率。 - 待确认深色背景方案需要在下周三前拉一个 5 人小范围用户测试。 引用锚点Mia我个人还是倾向深色背景质感确实不一样小李但你要考虑用户是来看信息的不是来看设计的。JSON 里的 action_items 部分长这样{ action_items: [ { summary: 产出新版首页线框稿明确首屏两个核心按钮, owner: 小李, due: 2025-06-13, priority: high, acceptance: Figma 输出三个方案附优缺点说明 }, { summary: 组织深色背景方案的 5 人用户小测试, owner: Mia, due: 2025-06-18, priority: medium, acceptance: 输出测试结论和是否采用深色背景的建议 } ] }相比我手工写的版本机器版在“完成标准”上写得比我更具体。我之前写待办经常就是“出首页线框稿”五个字看的人毫无推进动力现在每条都有验收方式。4.4 关于 15 倍效率的计算口径简单说明一下这个数字的算法免得有人说我标题党。分母是人工整理耗时 90 分钟分子是本次 Skill 流程耗时约 6 分钟90 除以 6 等于 15。这个口径只针对“会议纪要加待办整理”这个具体环节不包含会议本身的时间。如果你用更快的推理通道、把人工校对时间压到 1 分钟以内其实还能更快。但 15 倍的核心参考价值在于这项重复劳动可以被压缩到接近“通读一遍确认一下”的程度而不是从零开始写。5. 这些坑我不说你一定会踩微调与避坑实录5.1 转写层错误错别字让纪要变成笑话第一个坑不在 Skill 本身而在上游转写。转写工具对专业术语和同音词经常出错。测试里“首屏”被识别成“手屏”“埋点”被识别成“美点”。如果这一层不处理纪要里全是这种错别字发到团队里很不专业。我的处理办法在 Skill 的清洗步骤里加一个“术语纠正表”每次接入新项目时把常见的产品词、业务词、人名先填进去类似自定义词典。碰到不确定的词宁可标注“待确认”也不要让模型瞎猜。5.2 角色错配结论说错人纪要等于白做第二个坑更严重是发言人角色错配。转写工具的分说话人功能在同声、抢话场景下准确率会明显下降而纪要里最忌讳的就是“张三拍板的方案写成了李四拍的板”这会直接引发执行中的责任混乱。我的办法Skill 在做角色归一的时候先参考参与人名单和发言风格特征词拿不准的段落尤其有抢话、笑声、重叠说话的地方默认标记为“发言人待确认”。宁可多留一个待确认标签也不给团队输出一份角色张冠李戴的文件。5.3 模型幻觉没说过的话被写成了“会议结论”这是所有 AI 摘要类工具的通病也是我最在意的一点。测试第二版 Skill 时模型把 Mia 的一句反问“要不要考虑深色”自动加工成了“团队决定测试深色方案”这属于典型的幻觉。治这个问题的核心就一条强制事实锚点。我在 Prompt 里明确要求“每条结论必须附带原文引用原文没有明确出现的只能写成待确认”。加了这一句之后模型的“创造性”收敛了非常多。另外输出初稿后一定要保留那句被引用的原文方便团队核验。可以执行一个规则如果一条结论找不到对应原文就不写进纪要主体直接放到“待确认”清单。5.4 待办生成不可用粒度、动词与校验待办是会议纪要里最值钱的部分也是最容易生成废稿的部分。早期版本里模型经常输出“跟进官网改版”“处理一下视觉风格”这类话等于没说。我给待办列了一条硬标准每条待办必须满足“谁 在什么时间前 完成什么 完成标准”并且用动词开头。没有截止时间就标“待定”没有验收标准就标“由负责人确认”。宁缺毋滥一条无效待办比没有更糟糕因为它会制造虚假的进度感。5.5 数据安全敏感会议内容不能无脑进公网最后一条很多人会忽略。有些团队讨论的是战略、财务、人员这类敏感信息把原始录音或转写文本直接交给公网大模型处理存在数据暴露风险。个人建议敏感会议先脱敏再送模型或者直接用本地部署的模型跑这个 Skill。效率再高也不能拿数据安全去换。我的做法是把 Skill 拆成“脱敏”和“整理”两段。先跑脱敏步骤把姓名、金额、项目代号替换成匿名标记整理完成后再替换回来。整个过程多花一两分钟但心里踏实很多。6. 同一个 Skill 骨架换场景还能接着用6.1 客户访谈与需求调研会议纪要 Skill 换个输入定义就是一套“客户访谈整理器”。输入是访谈录音转写文本输出从“结论、分歧、待办”变成“客户核心诉求、痛点、决策链、跟进待办”。访谈场景里最重要的不是纪要本身而是“谁在什么时间前跟进什么客户”这套结构几乎可以原样复用。我当时只改了输出协议和 Prompt 里的角色设定处理流水线基本没动。6.2 播客课程与内容二次创作长音频内容也是同一个原理。把一集 40 分钟播客的转写文本丢进去Skill 可以输出节目金句、核心观点、待查证信息和三段式摘要直接当 Show Notes 用。做课程笔记更简单把课堂录音转写后输出“概念解释、案例、重点结论、课后行动”学习效率会高不少。6.3 代码评审和面试记录代码评审会这种场景纪要里的待办统一变成“缺陷修复、责任认领、复查人”输出格式几乎不用改。面试记录则可以把“结论、待办”换成“候选人亮点、风险点、下一步面试安排”还能让 Skill 输出结构化评分方便横向对比候选人。6.4 复用的关键不是改 Prompt而是定边界最后说一个方法论层面的体会Skill 复用的关键不是简单改几句提示词而是先想清楚“输入输出边界”和“处理流程边界”。输入边界决定了它能吃什么数据输出边界决定了下游怎么用流程边界决定了它稳不稳定。只要这三条定住了换场景基本就是换字典、换格式的事。我在这次实践里最深的感受是AI 不会替你开会但它能把“会后 90 分钟的脏活”压缩成一个 6 分钟就能复核完的标准动作。Skill 真正的价值不是让你完全不用动脑而是让你把那点脑力放在最该放的地方——判断、决策、确认而不是从一团转写文字里捞关键词。把最重复的部分交给 Skill把最需要人的部分留给自己这套打法放到哪个会议场景都成立。
上周我开完一场 1 小时的方案评审会散会时我下意识看了一眼时间心头一沉。脑子里已经有画面了回听录音、拖进度条、把零散讨论拼成纪要、再给十几条待办逐条找负责人这一套下来今晚九点前别想下班。这种“会开 1 小时整理 90 分钟”的体验每个被塞过会议纪要活的人都不会陌生。不过这一次我只花了 6 分多钟就拿到了完整纪要加待办清单。秘诀不是换了什么新笔记软件而是我把自己那套 AI Agent 工作流里的“会议纪要 待办整理”封装成了一个可复用的 Agent Skill。如果你经常开会、需要输出纪要和待办或者一直没搞明白最近铺天盖地的“Agent Skill”和 Agent、MCP 到底什么关系这篇可以当一份实战参考。接下来我会把完整方案拆开讲Skill 为什么能省这么多时间、它和 Agent 与 MCP 怎么分工、一个能跑的会议纪要 Skill 内部长什么样、实测数据以及我踩过之后才调明白的几个坑。1. 为什么整理一次会议纪要会吃掉 90 分钟1.1 时间都花在哪了很多人以为整理纪要就是把语音转成文字、删掉“那个那个”就完事了所以不理解怎么会花 90 分钟。但实际做过的人清楚一次 1 小时会议的转写文本大约有 1.1 万到 1.5 万字真正的问题在于信息密度极低但关键信息你一条都不敢漏。我自己梳理过手写纪要的 90 分钟大概是这样被吃掉的回听定位约 25 到 30 分钟。录音里找某个结论你得反复拖进度条听三五遍才确定发言人当时说的到底是“下周三”还是“周三前”。口语转书面约 15 到 20 分钟。把带口头禅、语气词、半截话的原始表达转成别人看得懂的书面语这个活比想象中费神。信息结构化约 30 分钟。散乱的讨论要按议题重新排区分“背景、结论、分歧、待办”这是整个环节里脑力消耗最大的部分。待办分发约 15 到 20 分钟。核对每条待办的责任人、截止时间、优先级写清楚验证标准否则发出去没人认领。这几项加起来轻松破 90 分钟。而且这个活往往发生在你“已经开完 1 小时会”之后注意力早就透支了越往后越容易漏漏了还要返工。1.2 现成工具做不到的事这几年的语音转写工具确实把“回听定位”这部分省掉了但直接拿来用还是差一口气转写工具给你的是“白描文本”谁说了什么都有但没有结论、没有待办等于是把原材料递给你饭还得你自己做。通用 AI 总结工具把一万多字全文塞进去效果不稳定经常把重点淹没在大段背景里。而且每个团队的纪要结构和待办习惯都不一样通用模型不认你的规范。会议平台自带的纪要功能前提是你每次都在那个平台开会并且愿意把敏感内容交给外部服务处理。所以我把目光从“找一个更听话的笔记软件”转到了“把我自己的整理能力做成 Agent 的一项 Skill”。这个转向才是效率提升的根本原因。2. Agent Skill 到底是啥和 Agent、MCP 的边界2.1 Skill 的本质把“会干活”变成可复用的资产先给结论Skill 不是一个聊天对话框也不是一句“帮我总结一下会议”的普通提示词。它是一个结构化的任务能力包通常包含四样东西任务描述这个 Skill 处理哪一类任务、在什么条件下使用。处理流程先做什么、后做什么的分步指令。输出协议产出什么格式Markdown 或 JSON字段有哪些。可绑定的工具读写文件、调用 API、创建待办等。你可以把 Skill 想象成一位老员工手里的“工序卡”。老员工闭着眼都能干是因为工序已经内化成了肌肉记忆新人照着工序卡也能干出七八分。Skill 的作用就是把内化的干活方式显性化让 Agent 在不同项目里反复复用同一套标准。我最早接触这个概念时也觉得挺虚但一旦你把任务拆成“输入、处理、输出”Skill 就不再神秘了它就是一个可执行的流程定义加上约束。2.2 Skill 和 Agent主厨与工序卡很多人问Skill 和 Agent 到底啥区别是不是一回事不是。Agent 是一个目标驱动的执行主体它的特点是自主决策给定一个目标它会拆解任务、选择工具、多轮试错。Skill 则是 Agent 调用的一项具体能力负责解决“某类任务该怎么干”。这里拿做菜来类比比较直观Agent 是主厨负责今天出哪些菜、先做哪道、火大了就调小。Skill 是“宫保鸡丁的标准工序卡”里面写清楚鸡丁怎么腌、料汁怎么配、什么火候出锅。MCP 是传菜口和厨房设备的接口标准主厨说“开烤箱”传菜口知道怎么把指令翻译成烤箱能听懂的信号。所以一个 Agent 做项目往往需要很多个 Skill 协同有的负责拆解需求有的负责生成代码有的负责写纪要有的负责发消息。Skill 越多Agent 在对应领域的“手艺”越精细。这也是“Agent 做项目是不是需要很多 Skill”这个问题的答案是的按任务板块拆能力边界越清晰越好。2.3 Skill 和 MCP手艺与接口Skill 和 MCP 是被问得最多的一组概念。可以这样分MCPModel Context Protocol解决的是“Agent 手能伸到哪”文件系统、数据库、第三方 API、会议系统都是通过这层标准化协议接入的。它更多是传输和连接层的东西。Skill 解决的是“这个活怎么干才漂亮”。同样是拿到一份转写文本有人直接让模型总结结果一团乱麻而 Skill 定义的是先清洗、再切议题、再抽结论、最后提炼待办的完整工序。实际配合方式是MCP 负责把会议文件、任务清单应用等外部资源接到 Agent 环境里Skill 负责规定“拿到资源之后怎么处理”。一个偏“连接”一个偏“手艺”两者不是同一层的东西也不互相取代。维度AgentSkillMCP本质目标驱动的自主执行主体单类任务的标准工作流加约束模型与外部工具、数据源的标准化接口回答的问题这个目标怎么做这类活怎么干才标准指令怎么安全触达外部资源类比主厨工序卡传菜口和设备接口依赖关系调用 Skill并通过 MCP 连外部工具可被 Agent 按需选择被 Agent 用来连接和操作外部系统理解了这层关系再看“会议纪要 Skill”你就明白它不是玄学而是把“怎么整理一个会议”这件具体的事标准化成了 Agent 能稳定执行的能力。3. 落地一版会议纪要和待办 Skill从协议到流水线3.1 先定输入输出别上来就堆 Prompt很多人设计 Skill 时第一步就开始写提示词这是错的。我建议先把输入输出边界定清楚否则后面会反复改。我这一版 Skill 的输入如下会议录音转写文本纯文本或 SRT 格式通常 1 万到 1.5 万字。会议主题可选但加上更稳。参与人名单可选用于角色映射。输出偏好纪要结构和待办格式。输出方面我选择“Markdown 给人看 JSON 给机器用”双通道Markdown 方便直接贴到文档或工作群JSON 方便下游程序自动创建任务、同步到项目管理工具。JSON 结构大致是这样的{ meeting_meta: { topic: 官网改版方案评审, duration_minutes: 51, date: 2025-06-10 }, sections: [ { topic: 新版首页方向确认, conclusion: 确定优先保首屏加载速度采用 A 方案, divergence: [图片素材风格仍未定], open_questions: [预算审批时间待确认] } ], action_items: [ { summary: 输出新版首页线框稿, owner: 小李, due: 2025-06-13, priority: high, acceptance: 在 Figma 产出三个方向线框并附优缺点说明 } ] }这样设计的好处是字段稳定下游好解析待办可以直接转成任务卡不用二次复制粘贴。3.2 六步处理流水线定完协议再把处理过程拆成六个步骤。这六步是我反复试出来的步骤太多会拖慢速度太少则输出不稳定。文本清洗去掉“呃、那个、就是说”等语气词把重复的半截话合并。这步不做后面所有步骤都会被噪声干扰。发言人归一转写文本里的 Speaker 0、Speaker 1 要映射到真实人名。没人名就先占位等人工校验时替换。粗切议题按语义断点和关键词把 60 分钟内容切成若干议题块。这一步决定了纪要大纲切分质量直接影响后面的结论提取。逐块精读对每个议题块抽取背景、结论、分歧点、待定项。要求模型必须引用原文片段作为依据。决策与待办提取把“谁能做、什么时候做、做到什么标准”单独提炼出来转成 action items。合并去重与排序多个议题块可能出现重复待办按负责人归并、按优先级排序最终输出。每一步都很关键。尤其第 4 步我要求“每条结论对应原文引用”这就是后面防幻觉的关键钩子。3.3 核心 Prompt 模板下面是我当前在用的 Skill Prompt 骨架你可以直接拿去改。核心是“流程强制 输出格式强制 事实锚点强制”。# 角色 你是一名资深的会议记录整理专家擅长从嘈杂的会议转写文本中抽取结构化信息。 # 任务 根据用户提供的会议转写文本生成一份包含会议纪要和待办清单的 Markdown 文档以及一份结构化的 JSON 数据。 # 处理步骤 1. 清洗文本去掉语气词、重复词、口误标记保留原始信息完整性。 2. 角色归一如果文本带有 Speaker 标记结合用户提供的参与人名单进行映射无法确定时保留占位符。 3. 议题切分根据讨论主题的切换将全文切分为若干议题块为每个议题块命名。 4. 逐块提取对每个议题块提取背景、结论、分歧、待定项每条结论必须引用原文句子作为锚点。 5. 提炼待办找出明确需要有人跟进的事项。每条待办必须包含负责人、截止时间、优先级、完成标准。使用动词开头。 6. 汇总统稿去重、排序、按优先级组织输出。 # 输出要求 - 待办必须具体到可执行禁止出现跟进一下处理一下这类无法验收的表态。 - 没有明确出现的事实不得写成结论只能标记为待确认。 - 输出包含 Markdown 纪要和 JSON 数据两部分。 # 事实锚点 每条结论和待办都必须附上源出处的简短引用便于人工核验。这个模板并不复杂但“事实锚点”和“禁止无依据结论”这两句是输出质量的命门。少了这两句模型会表现得像一个特别爱加戏的会议记录员。3.4 工具绑定与触发方式Skill 不一定要绑一堆工具但绑对了能少走很多弯路。我这边绑了三个文件读取读取转写文本支持纯 txt 和 SRT。Markdown 输出自动把纪要写入指定文档目录。待办同步通过 MCP 接到任务管理应用把 action_items 直接创建为带负责人和截止时间的任务卡。触发方式有两种一种是在对话里输入“整理会议纪要”并附带文件另一种是配置监听目录一旦有新转写文件进来Agent 自动调用这个 Skill 处理。第二种更像“管道”特别适合每周固定例会。4. 实测1 小时会议6 分钟拿到纪要和待办4.1 测试场景准备上个月我拿一次真实的“官网改版方案”评审会做了测试。会议时长 51 分钟4 个发言人转写文本约 1.2 万字。我特意选同一场会议做对照实验会议结束当晚我用 90 分钟手动整理了一份完整纪要和待办清单第二天我把同一份转写文本丢给 Skill 跑完整流程。两次产出一对比问题出在哪、省在哪里都很清楚。4.2 运行过程与耗时分布运行前我做了点准备给 Skill 喂了会议主题、参会人名单小李、阿哲、Mia、我指定了输出偏好。整个流程如下丢入 1.2 万字转写文本后Agent 先做清洗和发言人归一大概 30 到 40 秒。议题切分把 51 分钟内容切成了 5 个议题块包括“新版信息架构”“视觉风格”“首屏性能目标”“内容迁移范围”“上线时间与风险”。逐块提取结论和分歧耗时最长大约 2 分 10 秒。提炼待办去重排序生成 Markdown 和 JSON约 40 秒。我人工通读校验修正两处角色归错和一处表述约 2 分钟。从丢入文本到最终可用稿机器处理约 4 分钟出头加上人工校验 2 分钟总耗时 6 分钟左右。对比前一晚的 90 分钟效率提升约 15 倍。这里有一个诚实的补充这 6 分钟里有 2 分钟左右是人工校对不是完全甩手。但这已经足够说明问题因为最耗精力的“结构化、找结论、制作待办”这三块机器全包了。4.3 产出长什么样简要看一下产出。Markdown 纪要部分的一个切片## 议题 2新版首页视觉风格 - 背景目前首页转化率偏低团队怀疑是主视觉信息层级不够清晰。 - 结论确定走大留白、强焦点的方向首屏核心动作按钮不超过两个。 - 分歧Mia 建议采用深色背景突出产品质感小李认为深色可能影响浏览型用户阅读效率。 - 待确认深色背景方案需要在下周三前拉一个 5 人小范围用户测试。 引用锚点Mia我个人还是倾向深色背景质感确实不一样小李但你要考虑用户是来看信息的不是来看设计的。JSON 里的 action_items 部分长这样{ action_items: [ { summary: 产出新版首页线框稿明确首屏两个核心按钮, owner: 小李, due: 2025-06-13, priority: high, acceptance: Figma 输出三个方案附优缺点说明 }, { summary: 组织深色背景方案的 5 人用户小测试, owner: Mia, due: 2025-06-18, priority: medium, acceptance: 输出测试结论和是否采用深色背景的建议 } ] }相比我手工写的版本机器版在“完成标准”上写得比我更具体。我之前写待办经常就是“出首页线框稿”五个字看的人毫无推进动力现在每条都有验收方式。4.4 关于 15 倍效率的计算口径简单说明一下这个数字的算法免得有人说我标题党。分母是人工整理耗时 90 分钟分子是本次 Skill 流程耗时约 6 分钟90 除以 6 等于 15。这个口径只针对“会议纪要加待办整理”这个具体环节不包含会议本身的时间。如果你用更快的推理通道、把人工校对时间压到 1 分钟以内其实还能更快。但 15 倍的核心参考价值在于这项重复劳动可以被压缩到接近“通读一遍确认一下”的程度而不是从零开始写。5. 这些坑我不说你一定会踩微调与避坑实录5.1 转写层错误错别字让纪要变成笑话第一个坑不在 Skill 本身而在上游转写。转写工具对专业术语和同音词经常出错。测试里“首屏”被识别成“手屏”“埋点”被识别成“美点”。如果这一层不处理纪要里全是这种错别字发到团队里很不专业。我的处理办法在 Skill 的清洗步骤里加一个“术语纠正表”每次接入新项目时把常见的产品词、业务词、人名先填进去类似自定义词典。碰到不确定的词宁可标注“待确认”也不要让模型瞎猜。5.2 角色错配结论说错人纪要等于白做第二个坑更严重是发言人角色错配。转写工具的分说话人功能在同声、抢话场景下准确率会明显下降而纪要里最忌讳的就是“张三拍板的方案写成了李四拍的板”这会直接引发执行中的责任混乱。我的办法Skill 在做角色归一的时候先参考参与人名单和发言风格特征词拿不准的段落尤其有抢话、笑声、重叠说话的地方默认标记为“发言人待确认”。宁可多留一个待确认标签也不给团队输出一份角色张冠李戴的文件。5.3 模型幻觉没说过的话被写成了“会议结论”这是所有 AI 摘要类工具的通病也是我最在意的一点。测试第二版 Skill 时模型把 Mia 的一句反问“要不要考虑深色”自动加工成了“团队决定测试深色方案”这属于典型的幻觉。治这个问题的核心就一条强制事实锚点。我在 Prompt 里明确要求“每条结论必须附带原文引用原文没有明确出现的只能写成待确认”。加了这一句之后模型的“创造性”收敛了非常多。另外输出初稿后一定要保留那句被引用的原文方便团队核验。可以执行一个规则如果一条结论找不到对应原文就不写进纪要主体直接放到“待确认”清单。5.4 待办生成不可用粒度、动词与校验待办是会议纪要里最值钱的部分也是最容易生成废稿的部分。早期版本里模型经常输出“跟进官网改版”“处理一下视觉风格”这类话等于没说。我给待办列了一条硬标准每条待办必须满足“谁 在什么时间前 完成什么 完成标准”并且用动词开头。没有截止时间就标“待定”没有验收标准就标“由负责人确认”。宁缺毋滥一条无效待办比没有更糟糕因为它会制造虚假的进度感。5.5 数据安全敏感会议内容不能无脑进公网最后一条很多人会忽略。有些团队讨论的是战略、财务、人员这类敏感信息把原始录音或转写文本直接交给公网大模型处理存在数据暴露风险。个人建议敏感会议先脱敏再送模型或者直接用本地部署的模型跑这个 Skill。效率再高也不能拿数据安全去换。我的做法是把 Skill 拆成“脱敏”和“整理”两段。先跑脱敏步骤把姓名、金额、项目代号替换成匿名标记整理完成后再替换回来。整个过程多花一两分钟但心里踏实很多。6. 同一个 Skill 骨架换场景还能接着用6.1 客户访谈与需求调研会议纪要 Skill 换个输入定义就是一套“客户访谈整理器”。输入是访谈录音转写文本输出从“结论、分歧、待办”变成“客户核心诉求、痛点、决策链、跟进待办”。访谈场景里最重要的不是纪要本身而是“谁在什么时间前跟进什么客户”这套结构几乎可以原样复用。我当时只改了输出协议和 Prompt 里的角色设定处理流水线基本没动。6.2 播客课程与内容二次创作长音频内容也是同一个原理。把一集 40 分钟播客的转写文本丢进去Skill 可以输出节目金句、核心观点、待查证信息和三段式摘要直接当 Show Notes 用。做课程笔记更简单把课堂录音转写后输出“概念解释、案例、重点结论、课后行动”学习效率会高不少。6.3 代码评审和面试记录代码评审会这种场景纪要里的待办统一变成“缺陷修复、责任认领、复查人”输出格式几乎不用改。面试记录则可以把“结论、待办”换成“候选人亮点、风险点、下一步面试安排”还能让 Skill 输出结构化评分方便横向对比候选人。6.4 复用的关键不是改 Prompt而是定边界最后说一个方法论层面的体会Skill 复用的关键不是简单改几句提示词而是先想清楚“输入输出边界”和“处理流程边界”。输入边界决定了它能吃什么数据输出边界决定了下游怎么用流程边界决定了它稳不稳定。只要这三条定住了换场景基本就是换字典、换格式的事。我在这次实践里最深的感受是AI 不会替你开会但它能把“会后 90 分钟的脏活”压缩成一个 6 分钟就能复核完的标准动作。Skill 真正的价值不是让你完全不用动脑而是让你把那点脑力放在最该放的地方——判断、决策、确认而不是从一团转写文字里捞关键词。把最重复的部分交给 Skill把最需要人的部分留给自己这套打法放到哪个会议场景都成立。
