企业官网建设流程全解析

上周我开完一场 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 不是一个聊天对话框，也不是一句“帮我总结一下会议”的普通提示词。它是一个结构化的任务能力包，通常包含四样东西：

1. 任务描述：这个 Skill 处理哪一类任务、在什么条件下使用。
2. 处理流程：先做什么、后做什么的分步指令。
3. 输出协议：产出什么格式，Markdown 或 JSON，字段有哪些。
4. 可绑定的工具：读写文件、调用 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 是被问得最多的一组概念。可以这样分：

• MCP（Model Context Protocol）解决的是“Agent 手能伸到哪”：文件系统、数据库、第三方 API、会议系统，都是通过这层标准化协议接入的。它更多是传输和连接层的东西。
• Skill 解决的是“这个活怎么干才漂亮”。同样是拿到一份转写文本，有人直接让模型总结，结果一团乱麻；而 Skill 定义的是先清洗、再切议题、再抽结论、最后提炼待办的完整工序。

实际配合方式是：MCP 负责把会议文件、任务清单应用等外部资源接到 Agent 环境里；Skill 负责规定“拿到资源之后怎么处理”。一个偏“连接”，一个偏“手艺”，两者不是同一层的东西，也不互相取代。

理解了这层关系，再看“会议纪要 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 六步处理流水线

定完协议，再把处理过程拆成六个步骤。这六步是我反复试出来的，步骤太多会拖慢速度，太少则输出不稳定。

1. 文本清洗：去掉“呃、那个、就是说”等语气词，把重复的半截话合并。这步不做，后面所有步骤都会被噪声干扰。
2. 发言人归一：转写文本里的 Speaker 0、Speaker 1 要映射到真实人名。没人名就先占位，等人工校验时替换。
3. 粗切议题：按语义断点和关键词把 60 分钟内容切成若干议题块。这一步决定了纪要大纲，切分质量直接影响后面的结论提取。
4. 逐块精读：对每个议题块抽取背景、结论、分歧点、待定项。要求模型必须引用原文片段作为依据。
5. 决策与待办提取：把“谁能做、什么时候做、做到什么标准”单独提炼出来，转成 action items。
6. 合并去重与排序：多个议题块可能出现重复待办，按负责人归并、按优先级排序，最终输出。

每一步都很关键。尤其第 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，把最需要人的部分留给自己，这套打法放到哪个会议场景都成立。