开完会那半小时才是真正让人崩溃的开始。会议本身一小时散会后整理纪要、抠待办、回看录音重点零零散散又搭进去一个半小时。这不是个例是几乎所有职场人都在反复经历的时间黑洞。我试过各种所谓效率工具模板做了一堆最后发现问题的核心不在记录而在整理。直到我把整理纪要这件事交给 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。把一个小时压缩成六分钟省出来的时间用来干什么不好 用Agent Skill把会议纪要整理从90分钟压缩到6分钟
开完会那半小时才是真正让人崩溃的开始。会议本身一小时散会后整理纪要、抠待办、回看录音重点零零散散又搭进去一个半小时。这不是个例是几乎所有职场人都在反复经历的时间黑洞。我试过各种所谓效率工具模板做了一堆最后发现问题的核心不在记录而在整理。直到我把整理纪要这件事交给 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。把一个小时压缩成六分钟省出来的时间用来干什么不好