企业官网建设流程全解析

不瞒你说，我第一次看到“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协议接上对应的Server，Agent就能像用自己手脚一样调用这些外部能力。核心是打通“连接”。

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 在哪里运行这套Skill：Agent平台选型

现在市面上的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分钟工作的感觉。