AI 会议助手:让每场会议的价值不止于散会那一刻
从老板提案到0到1落地:先用Dify跑通最小Demo,再迭代到可用工具,AI总结与人工修改点匹配度从1.0的80-90%提升至2.0约91-92%。
我的背景是交互设计师。这个项目是我从"用 AI 辅助设计"到"独立做出 AI 产品"的转折点——从 Dify 验证可行性,到独立完成开发上线,再到持续迭代至团队日常使用的工具。
核心数据:
- 从零到一构建的这个产品,解决的团队内早期没有AI会议助手的一个空白。
- AI 总结与人工总结的可执行修改点匹配度:早期 70-85% → 优化后约 91-92%
- 体感效果优于付费产品讯飞听见(在 2025 年 11 月的同样本对比中)
- 会议信息整理时间:30 分钟 → 5 分钟以内
- 支持 20+ 种音视频格式、多角色分析、说话人筛选、一键分享
产品演示视频(上传 → 转写 → 总结)
下面这段视频展示从音视频输入到纪要输出的完整链路,重点看处理速度与结果可读性。
核心流程图(端到端工作流)
这张流程图说明系统关键阶段与信息流转关系。
AI 会议助手流程图(竖向)
一、快速验证
需求来源很直接:2024 年项目会议密集,团队在“会后纪要整理与待办分发”上消耗了大量时间,未参会同事也缺少统一、可执行的信息入口。 我把目标收敛为一件事:先做一个可用的 AI 会议助手,验证“音频转写 + AI 总结”能否稳定覆盖关键决策与待办。 技术路径同步收敛:先用成熟的语音转写服务打通输入,再把主要精力放在总结质量校准。 判断标准不是“能不能生成”,而是“是否能直接用于执行与协同”。
我用 Dify 花一天在本地跑通了最小 MVP:音频转文字 → AI 生成总结。结论:能用,但离好用差很远。AI 能覆盖大部分内容,但对隐含决策和待办的提取很粗糙。
精准度取决两个主要因素:一是模型,二是背后的提示词。 关键判断:瓶颈不在工程实现,而在怎么跟 AI 对话——转写质量靠云服务已经成熟,真正的杠杆在提示词设计。这直接决定了后续投入分配:没在转写、界面上花大量时间,精力集中在提示词调教上。验证通过后,我独立完成了从开发到部署上线的全流程,后续持续迭代。
这成了我做 AI 项目的起手式:不预设产品形态,先用最低成本找到真正的瓶颈在哪。
二、模型选择 × 提示词设计:精准度的两个杠杆
匹配度从 70-85% 提升到 91-92%,靠的不是单一变量——是模型选择和提示词结构的交替优化。
提示词结构决定输出的下限。 最初的做法是把所有要求塞进一段长指令。效果很差——AI 要么面面俱到但每个点都浅,要么抓住某个点但漏掉其他。后来我设计了模板系统:每种任务(会议纪要、调整点提取、角色分析)用独立模板,分阶段引导 AI 输出。核心发现:把一个大任务拆成明确的小步骤,比给一个"完美指令"有效得多。 这和交互设计的底层逻辑是相通的——理解用户要什么、拆解任务结构、控制输出质量。
模型能力决定输出的上限。 早期我内置了多个分析角色(设计师、产品、CEO 视角),本质是用角色提示词弥补模型分析能力的不足。后来接入讯飞星火 Spark X1(具备推理能力),再切到 Google Gemini 2.5 Pro 后,模型自己能深度思考,多角色反而变成了噪音——我及时砍掉冗余角色,让提示词回归精简。模型升级时,提示词必须跟着瘦身;提示词越精准,模型的能力释放越充分。两者是螺旋上升的关系。
这让我形成了一个核心判断:AI 产品不能固化在某个阶段的解决方案上,模型和提示词必须作为一个整体持续调优。
提示词调试过程文档
1.0 提示词基线(v1.0.1)
先放出 1.0 阶段的线上提示词原文,作为早期基线。
1.0 提示词(约 300 字):
你是一位专业的资深交互设计师,本次承担会议记录分析师。你任务是从详细的会议记录中提取关键的设计和功能调整点,并将它们简明扼要地总结出来。请按照以下指导进行:
1. 仔细阅读整个会议记录。
2. 识别讨论中提到的主要设计更改、功能调整和开发重点。
3. 将这些要点浓缩为简洁的条目,每个条目应该:
- 清晰表达一个具体的调整或决定
- 使用简洁的语言,避免冗长的解释
- 尽可能保留原文中使用的关键术语
4. 按照讨论的顺序或重要性排列这些条目。
5. 使用数字列表格式输出总结,每个要点占一个条目。
6. 总结应该简洁明了,通常不超过10-15个要点。
7. 不要添加任何在原文中没有确提到的内容或个人解释。
请记住,你的目标是创建一个类似于提供的人工总结的输出,但要基于原始会议记录的内容。
会议记录:
${transcription}
请根据以上指导生成调整点总结。1.0 阶段做了多模型效果测评,最终选型为 GPT 4.0。

项目排期(v1.0.0)

三、2.0 开发过程:竞品对标与模型升级
2.0 阶段的核心不是重做功能,而是围绕“总结质量”做系统升级。我们先做了市面调研,把讯飞听见作为核心竞品进行对标。
第一步,我们先深度体验讯飞听见产品,并基于其结果做提示词与能力反推。对同一段音频做总结对比后,我们的输出和讯飞听见官网产品结果基本接近,因此判断其核心能力可由讯飞星火 Spark X1 代表,并在系统中接入该模型。这个阶段效果已经不错,能稳定覆盖关键结论与执行点。
第二步,在后续试验中我接入 Google Gemini 2.5 Pro 模型,并继续做提示词微调。对比同一批会议样本后,团队体感反馈是:结果完整度、重点提取准确度和可执行性都优于讯飞听见。
2.0 提示词(约 2000 字,v2.0)
## 任务目标
根据用户提供的语音转写文稿,整理一份内容完整、结构清晰、易于阅读和理解的会议纪要。
## 工作流程
### 步骤1:理解会议内容
- 仔细阅读语音转写文稿,从头到尾完整阅读所有对话内容
- 理解各个说话人讨论的要点和观点
- 识别参与人员和他们的角色
- 初步判断会议性质和涉及的领域
### 步骤2:识别核心议题
从对话中提取主要讨论主题,形成3-7个核心议题的清单(这将成为正文的主要章节)
### 步骤3:规划输出结构
根据识别出的核心议题,设计会议纪要的章节结构。根据实际讨论内容灵活设计章节,常见结构包括:
- 项目背景与现状
- 核心需求与目标
- 实现方案与设计
- 技术实现与计划
- 风险与注意事项
- 待办事项
### 步骤4:提取和整合内容
#### 按章节提取信息
- 提取事实信息:具体的数据、时间、方案、决策
- 提取观点和建议:各说话人的意见和建议
- 提取问题和风险:讨论中提到的问题点和风险点
- 提取决策结果:达成的共识和最终决定
#### 合并相似观点
- 如果多位说话人提到相似的观点,合并到同一条
- 将分散在不同位置的同一话题合并
- 将同一观点的多次提及整合为一条
- 按逻辑关系重新组织内容(而非按时间顺序)
#### 区分说话人(必要时)
- 如果涉及责任分工、不同立场的观点,需要明确说话人
- 如果只是补充性讨论,可以统一整理,不必标注具体说话人
#### 标注重要信息
- 优先级:如"先做两个核心玩法"
- 时间节点:如"本周五前完成"
- 数量/金额:具体数据准确记录
- 决策点:如"确定采用方案A"
#### 保持层次结构
- 每个章节下使用清晰的小节标题
- 使用项目符号(•)或数字编号组织内容
- 确保层次分明(一级标题 → 二级标题 → 三级内容)
### 步骤5:完善会议纪要
#### 补充会议基本信息
- 会议主题:用一句话概括会议的核心内容
- 参会人员:列出所有说话人
- 会议时间:如果能从对话中识别出来
#### 提取待办事项
专门设立"待办事项"章节,使用表格形式呈现:
| 执行人 | 待办事项 | 备注 |
|--------|---------|------|
| XXX | 具体任务描述 | 优先级/截止时间等 |
待办事项来源:
- 会议中明确分配的任务
- 需要进一步核算、评估、设计的事项
- 需要协调、推进的工作
#### 生成会议结论
在纪要结尾用一句话高度概括:
- 会议的核心决策
- 下一步的主要方向
- 关键的执行重点
格式:会议结论:[一句话总结核心决策和执行方向]
#### 添加免责声明
在最后添加:*内容由AI生成,仅供参考
### 步骤6:质量检查
#### 完整性检查
- 是否涵盖了所有重要讨论点?
- 是否遗漏了预算、时间、责任人等关键信息?
- 待办事项是否完整提取?
#### 准确性检查
- 数据、时间、金额等具体信息是否准确?
- 是否曲解了说话人的原意?
- 决策点是否表述清晰?
#### 可读性检查
- 结构是否清晰、层次是否分明?
- 语言是否简洁明了?
- 是否有冗余或重复的内容?
## 输出格式
```
会议纪要
会议主题:XXX
参会人员:XXX、XXX、XXX
[会议时间:XXXX年XX月XX日](如果能识别)
一、一级标题
1. 二级标题
• 三级内容
• 三级内容
二、一级标题
...
X、待办事项(MD表格)
| 执行人 | 待办事项 | 备注 |
|--------|---------|------|
| XXX | XXX | XXX |
会议结论:XXX
*内容由AI生成,仅供参考
```
## 语言风格
- 客观准确:基于事实,不添加主观臆测
- 简洁明了:避免冗长表述,直击要点
- 结构化:善用标题、编号、符号组织内容
- 专业正式:符合商务会议纪要的语言规范
## 特别注意
### 区分讨论和决策
- 讨论过程可以简化或省略
- 最终决策必须清晰记录
- 如果某个问题讨论了但没有定论,标注为"待确认"或"待进一步讨论"
### 提取隐含信息
从讨论中提取隐含的需求和结论:
- "这个可能有问题" → 提取为需要评估的风险点
- "我们看看能不能..." → 提取为待办事项
- "参考一下XX的做法" → 提取为设计参考
### 保持中立客观
- 不要偏向某个说话人的观点
- 如果有不同意见,客观呈现多方观点
- 避免使用"我认为"、"我觉得"等主观表述2.0 的结论是:模型升级 + 提示词微调必须联动推进,才能持续拉高总结质量上限。
四、从个人工具到团队资产
技术上能跑通不等于团队愿意用。设计师的职业本能让我始终从使用者的角度做产品判断:
让用户"看见"AI 在思考。 AI 分析结果实时展示推理过程,而不是等几十秒后一次性输出。团队实测发现,看到 AI 逐步展开分析的用户,对结果的信任度明显更高。这不是技术选型问题,是用户心理问题——"AI 在认真想"比"AI 在转圈"体验好得多。
流式输出上线后,用户等待焦虑显著降低。

分享必须零摩擦。 一条总结生成后,一个链接就能发给不在场的同事。同一内容多次分享返回同一链接,更新后自动指向最新版本——不会出现"你看的和我看的不一样"。
只看你关心的人说了什么。 转录完成后支持按发言人筛选,再交给 AI 分析。开完一小时的会,产品经理只想知道"老板到底拍了什么板"——这个场景洞察来自我旁听了十几场不同类型会议后的观察。
角色管理可编辑并即时生效,支撑按角色输出会议结论。

部署上线后已可在云端稳定使用。

这张图记录的是 1.0 阶段的开发过程与版本迭代轨迹:从功能开发、问题修复到优化上线,完整体现了当时持续推进的节奏。

写在最后
回头看,设计师背景在这个项目中不是劣势,反而是最大的杠杆:验证先行的习惯来自用研思维,提示词设计本质上就是交互设计,而对用户场景的敏感度决定了产品最终能不能被团队真正用起来。 工程实现反而是最容易补的部分——AI 编程工具已经把这个门槛拉到很低了。
做 AI 产品,最值钱的不是写代码的能力,而是三个判断:哪里是真正的瓶颈、提示词该怎么设计、什么时候该跟着模型能力重新设计产品。