【学习工作赛道】智能会议纪要系统 — AI 声纹识别 + 跨录音关联 + 智能纪要
体验地址：http://52.221.245.125:20010/ | GitHub：[待上传](file:///C:/Users/skya2/Documents/trea%20work/trae-demo-post.html#)
0. 先和大家打个招呼
你是谁
一个在工作中需要频繁参加评审会、对齐会、复盘会的职场人。每次会议结束后，整理纪要的平均时长是会议本身的 50% 到 75%，更麻烦的是：转录出来的文字往往是一整段流水账，谁说了什么、做了什么决定、谁负责跟进，全靠整理人逐句回溯。
你是怎么用 TRAE 把 Demo 做出来的
整个项目从想法到可部署的产品，是和 TRAE 一句一句聊出来的。最初脑子里只有一个模糊画面：上传一段会议录音，AI 自动告诉我谁说了什么、核心结论是什么、有哪些待办任务。但怎么落地，完全没头绪。
我把大目标拆成小步讲给 TRAE 听：
-
先让它帮我设计后端架构：FastAPI + SQLAlchemy + SQLite 异步数据库；
-
再接入 faster-whisper 做语音识别、pyannote.audio 做说话人分离；
-
然后引入 wespeaker 提取 512 维声纹向量，实现跨录音的说话人关联；
-
最后用 OpenAI 兼容接口接入大语言模型，自动生成结构化纪要；
-
前端用原生 HTML/CSS/JS 做暗色主题界面，和 AI 一起打磨交互细节。
最让我感到"原来这么简单"的瞬间有两个：
**1. 声纹关联功能。**当我随口说"如果第一段录音里识别出了王总，第二段录音应该能自动认出他"时，TRAE 直接引入了 wespeaker ResNet34 模型和余弦相似度算法，设计了双阈值策略（0.75 匹配 / 0.85 自动确认），并实现了加权平均的声纹融合——每多一次匹配，声纹档案就越精确。这种原本以为要折腾一整天的功能，几轮对话就跨过去了。
**2. 说话人试听验证。**当我说"每个识别出来的说话人，卡片里应该能播放一段只有他一个人的音频，让用户确认对不对"时，TRAE 在 embedding 提取阶段同步保存最长音频片段，前端直接绑定 audio 元素播放。这个细节让声纹关联的可信度从"猜"变成了"可验证"。
一、Demo 简介
1.1 作品是什么
智能会议纪要系统是一款AI 原生会议效率工具。用户只需上传一段会议录音，系统自动完成：语音识别（带说话人分离）→ 声纹跨录音关联 → AI 生成结构化纪要 → 提取可执行任务清单。整个过程无需人工介入，从"一段音频"到"一份完整纪要"，只需几分钟。
它不是一款只能"看"的转录工具，而是一套**"识别 → 关联 → 纪要 → 任务"的完整工作流**。核心创新在于声纹层面的跨录音说话人关联——不同时间、不同会议的录音，只要是同一个人说话，系统就能自动认出，并关联到他已有的档案（姓名、职位、联系方式、职责等）。
1.2 面向谁
面向所有需要处理会议记录的人：
-
项目经理和产品经理 —— 快速产出评审纪要、对齐结论、待办清单；
-
行政助理和秘书 —— 告别逐句听写，AI 自动整理；
-
团队负责人 —— 跨多次会议追踪同一个人的发言和任务；
-
法律和金融从业者 —— 需要精确区分说话人、保留完整发言记录的场景；
-
任何"不想花时间整理会议纪要"的人 —— 哪怕完全不懂技术，上传录音即可。
1.3 主要功能
| 功能模块 | 核心能力 | 解决痛点 |
|---|---|---|
| 语音识别 + 说话人分离 | faster-whisper + pyannote.audio，支持多语言自动检测 | 听不清、分不清谁说了什么 |
| 声纹跨录音关联 | wespeaker 512 维向量 + 余弦相似度，双阈值策略 | 不同录音需重复登记说话人 |
| 说话人档案管理 | 卡片式管理：姓名、职位、部门、电话、邮箱、职责 | 说话人信息无法持久化 |
| AI 智能纪要 | OpenAI 兼容接口，支持三种风格：详细/简要/行动导向 | 人工整理纪要耗时费力 |
| 任务清单提取 | 自动从纪要中提取任务：标题、负责人、截止日期、优先级 | 会议决议被遗忘 |
| 说话人试听验证 | 每个说话人卡片附带专属音频片段，可播放确认 | AI 识别是否正确无法验证 |
1.4 技术栈
| 维度 | 说明 |
|---|---|
| 后端 | Python 3.12 + FastAPI + SQLAlchemy async + SQLite |
| 语音识别 | faster-whisper (本地 ASR，支持 VAD 和多语言) |
| 说话人分离 | pyannote.audio 3.3 (diarization pipeline) |
| 声纹识别 | wespeaker ResNet34 (512 维向量 + cosine similarity) |
| 大语言模型 | OpenAI 兼容接口 (GPT-4o-mini / DeepSeek / 通义千问) |
| 前端 | 原生 HTML5 + CSS3 + JavaScript (暗色主题) |
| 部署 | AWS EC2 (Ubuntu 24.04) + uvicorn + 独立 Demo HTML |
| 数据 | SQLite 异步 + SQLAlchemy ORM，说话人声纹向量 JSON 存储 |
产品总览 / 前端界面截图
二、Demo 创作思路
2.1 灵感来源
灵感来自工作中反复出现的真实场景。一次一小时的会议，人工整理纪要平均需要 30 到 45 分钟。现有的语音转文字工具（讯飞、飞书妙记等）解决了"听不清"的问题，但没有解决三个更深层的问题：
-
分不清人 —— 转录出来是一整段文字，谁说了什么需要人工标注；
-
记不住人 —— 不同会议的录音，同一个说话人每次都要重新识别、重新标注；
-
理不清结论 —— 录音变成文字后，讨论要点、决策结论、待办任务仍需人工提炼。
一直在想：**能不能有一个工具，上传录音后自动告诉我谁说了什么、核心结论是什么、谁该做什么，而且不同录音能认出同一个人？**这就是智能会议纪要系统的起点。
2.2 想解决的问题
痛点一：说话人分离的精度与可用性。
现有的说话人分离技术（diarization）可以区分"这是 A 说的、那是 B 说的"，但做不到"这是王总说的"。用户每次都要手动把 SPEAKER_00 改成"王总"，然后在下一段录音里重复这个过程。智能会议纪要系统通过声纹向量把"分离"升级为"识别"，让系统记住每个人的声音特征。
痛点二：跨录音的说话人关联。
企业场景下，一个人会参加多次会议。如果第一段录音里已经维护好了"王总，财务总监，138-xxxx"的档案，第二段录音应该能自动关联，而不是从零开始。这是声纹识别技术最自然的应用场景，但现有会议纪要产品几乎都没有实现。
痛点三：纪要整理的人力成本。
转录后的文字往往几千字，人工提炼讨论要点、决策结论、待办任务需要大量时间。大语言模型天然擅长信息压缩和结构化，但前提是输入数据已经包含了说话人信息——这正是前两步要解决的问题。
2.3 为什么做这个方向
判断一：声纹识别是说话人管理的"最后一公里"。
语音识别解决了"说了什么"，说话人分离解决了"谁在说"，但只有声纹识别才能解决"这是谁"。三者组合在一起，才能构成完整的会议信息闭环。
判断二：跨录音关联的价值被严重低估。
几乎所有语音转文字产品都把每段录音当作独立任务处理，忽略了企业场景下"人"是跨会议、跨时间的连续实体。声纹关联让系统从"工具"变成了"档案"——每一次使用都在积累说话人的声纹档案，越用越准。
判断三：端侧模型 + 大模型是最佳组合。
faster-whisper 和 pyannote.audio 都是本地运行的模型，不需要把音频上传到云端，保证了数据隐私。纪要生成通过 OpenAI 兼容接口调用，用户可以选择 OpenAI、DeepSeek、通义千问等任意服务商，灵活可控。
判断四：纯前端 Demo 降低体验门槛。
为了让评审能快速体验，我打包了一个 63KB 的独立 HTML Demo 文件，预置了完整的示例会议数据。评委无需部署后端、无需配置 API 密钥，打开即可看到说话人卡片、转录文本、纪要和任务清单的完整交互。
三、Demo 体验地址
| 入口 | 地址 | 说明 |
|---|---|---|
| 在线体验 | http://52.221.245.125:20010/ | 完整后端服务（需后端配置 API 密钥后可用） |
| 独立 Demo | http://52.221.245.125:20010/demo | 前端独立展示版，预置示例数据，打开即用 |
| API 文档 | http://52.221.245.125:20010/docs | FastAPI 自动生成的 Swagger UI |
| 源码仓库 | GitHub (待上传) | 完整后端 + 前端代码 |
建议从独立 Demo进入体验，无需任何配置，浏览器直接打开即可看到完整的转录文本、说话人卡片、AI 纪要和任务清单。
四、TRAE 实践过程
4.1 完整开发流程
智能会议纪要系统的开发并非一次性生成，而是通过多轮对话逐步迭代。整体流程如下：
第一步：需求拆解与架构设计。
与 TRAE 对话梳理出"上传 → 转录 → 分离 → 声纹匹配 → 纪要生成 → 任务提取"的技术链路。TRAE 帮我判断出"每个录音独立处理"这个常见做法的局限，建议引入声纹向量实现跨录音关联。
第二步：后端核心搭建。
在 TRAE 协助下完成 FastAPI 项目骨架：config.py 统一管理配置、database.py 设计 SQLAlchemy 异步模型（Meeting / Task / Speaker / MeetingSpeaker 四表关联）、models.py 定义 Pydantic 请求响应模型、main.py 实现全部 REST API 路由。
第三步：语音识别与说话人分离。
集成 faster-whisper 做本地 ASR（支持多语言自动检测和 VAD 过滤），集成 pyannote.audio 做说话人 diarization。最复杂的是时间对齐算法——如何把 diarization 的说话人时间段和 whisper 的词级别时间戳精确匹配，TRAE 设计了基于中点投影的对齐策略。
第四步：声纹识别与跨录音关联。
这是整个项目最核心的创新。引入 wespeaker ResNet34 模型提取 512 维声纹向量，设计双阈值匹配策略（0.75 匹配 / 0.85 自动确认），实现加权平均的声纹融合。每次新录音匹配成功后，声纹向量会与历史向量做加权平均，档案越用越准。
第五步：说话人档案与试听验证。
设计卡片式说话人管理界面：姓名、职位、部门、职责、电话、邮箱。在声纹提取阶段同步保存每个说话人的最长音频片段，前端通过 audio 元素实现一键试听，让用户验证 AI 识别是否正确。
第六步：AI 纪要生成与任务提取。
通过 OpenAI 兼容接口接入大语言模型，将转录文本（含说话人信息）发送给 LLM，生成结构化的会议纪要（讨论要点、决策结论、行动项）。同时从纪要中自动提取任务清单，支持增删改查和完成状态管理。
第七步：前端界面与部署工程化。
暗色主题前端界面，四个标签页（转录、说话人、纪要、任务）。打包独立 Demo HTML（63KB，预置示例数据），部署到 AWS EC2，配置 nginx + uvicorn 生产环境。
4.2 开发关键步骤截图
【开发截图1】因为trae work记录太长，旧记录界面上找不到了，只能找memory里的记录了
【开发截图2】说话人卡片与试听功能开发过程的截图
【开发载图3】进度更新 AI 纪要生成和任务提取功能开发的截图
【开发载图4】部署到 AWS 的终端操作截图
4.3 关键任务对话 Session ID
| Session ID | 对应任务 |
|---|---|
6a43ea0f841cef430fd46055 |
完整应用开发：后端 API + 前端界面 + 声纹关联 + 说话人试听 + 参赛准备（7月1日-4日，主开发会话） |
6a47a2bec982790df9644d5b |
参赛材料整理 + 部署工程化：Dockerfile + docker-compose + AutoDL 部署脚本 + .gitignore（7月3日-4日） |
6a48c907c982790df9644edf |
项目进度管理 + Git 初始化 + 前端独立 Demo 打包（7月4日） |
五、对应的报名审核通过的帖子链接
【学习工作赛道】智能会议纪要系统 —— 声纹识别让会议纪要自动归因