Multilingual Meeting Notes Generator基于 AssemblyAI 与 LLM 的多语言会议纪要自动生成实战【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub导读本教程围绕multilingual-meeting-notes-generator项目展开讲解如何构建一个自动检测会议口语语种、输出英文结构化纪要含议题、关键决策、下一步、发言人级分析与行动项提取的多语言会议纪要生成器。读完本文你将掌握AssemblyAI 语音转写与说话人分离speaker diarization的配置方法、以任意多语言 LLM 驱动结构化摘要与行动项抽取的 Prompt 工程要点以及用 Streamlit 将整套流水线封装为可直接运行的 Web 应用的全过程。源码位置app.py核心服务在 src/services 目录配置依赖见 pyproject.toml。一、整体工作流程从音频到完整会议纪要项目以**流水线pipeline**方式串联多个能力正如 README 的 How It Works 所述整个流程分为五步音频输入用户上传会议录音文件语言检测AssemblyAI 自动检测会议使用语言转写方向支持 99 种语言语音转写高质量转写并开启说话人分离diarization以区分不同发言人智能处理由任意的多语言 LLM 完成摘要、发言人识别与行动项提取结果输出综合生成英文摘要、发言人分析、行动项与完整转写文本。这套流水线在源码中由 MeetingProcessor 统一编排它持有两个子服务转写交给AudioTranscriberAssemblyAI语义分析交给TextAnalyzer多语言 LLM最终把各环节结果封装为一个 MeetingResult 数据对象交给前端展示。其关键流程如下音频文件 │ AudioTranscriberAssemblyAI │ ① language_detectionTrue → 自动检测语种 │ ② speaker_labelsTrue → 说话人分离 ▼ 全量转写 分段(utterances) 说话人 语种 │ TextAnalyzerLLM │ ① identify_speaker_names → 给说话人分配真实姓名 │ ② generate_meeting_summary → 英文结构化摘要 │ ③ extract_action_items → 提取行动项 │ ④ generate_meeting_title → 生成会议标题 ▼ MeetingResult标题/摘要/说话人/分段/行动项/语种/时长 │ Streamlit UIui_components export ▼ 英文纪要 说话人分析 行动项 完整转写 Markdown 导出值得注意的健壮性设计process_meeting_audio在转写内容过短或分段为空时主动抛错而 LLM 分析说话人名识别、摘要、行动项、标题则各自包在try/except中单项失败只打印 Warning 并走兜底值不会中断整场处理——例如摘要失败时返回提示文案、标题失败时自动回退为 Meeting - 日期见 audio_processor.py。二、环境准备与依赖安装1. 准备 API Key参照项目根目录的 env_example.txt在项目根目录创建.env文件并填入两组密钥README 只写了 AssemblyAI Key但实际运行还需要一个 LLM 的 Key见源码与 UI 校验逻辑ASSEMBLYAI_API_KEYyour_assemblyai_api_key OPENAI_API_KEYyour_openai_api_key其中ASSEMBLYAI_API_KEY用于语音转写与说话人分离OPENAI_API_KEY由文本分析服务使用默认模型gpt-4o见 text_analyzer.py。也可以改用任意多语言 LLM——项目通过 OpenAI 兼容接口调用凡是支持 Chat Completions 接口且具备多语言能力的模型均可按此模式替换。2. 安装依赖项目使用 uv 管理依赖见 pyproject.tomlPython 要求3.9核心依赖包括streamlit1.49.1—— Web 界面assemblyai0.21.0—— 语音转写/语言检测/说话人分离openai1.99.9—— 多语言 LLM 分析与摘要python-dotenv1.0.0—— 加载.env执行以下命令即可一键同步环境uv sync三、运行应用安装完成后运行下面命令启动 Streamlit 应用uv run streamlit run app.py启动后浏览器会打开交互界面app.py从上传音频到纪要生成再到导出 Markdown 的完整闭环均由该页面承载。四、界面使用指南README 的 Usage 章节把操作分为四个步骤结合 app.py 的侧边栏实现可以拆得更细配置 API Key在左侧Configuration区域输入 AssemblyAI API Key 与 OpenAI API Key密码框形式。代码会先做基础格式校验——两把 Key 都不能为空且长度 ≥ 20 字符见 app.py 中 _validate_api_keys不合法会提示Invalid API key format。上传音频在Audio Input区域上传会议录音支持mp3 / wav / m4a / mp4 / webm / flac六种格式注意比 README 列举的四种更多。上传文件会被写入临时文件后再交给处理管线处理完毕自动删除并执行垃圾回收见 app.py 中 _save_uploaded_file / _cleanup_temp_file。开始处理点击 Start Processing处理全程有状态提示Processing… → Processing complete!失败则显示具体错误原因。查看结果主区域按序展示以下五块内容渲染逻辑见 ui_components.py顶部指标卡会议时长、说话人数、行动项数量Meeting Summary按 Topics Discussed / Key Decisions / Next Steps 三类渲染英文纪要Speaker Diarization每位说话人的发言时长与词数并可展开查看其全部发言片段Action Items按负责人分组展示行动项含截止时间与优先级无归属的归入 UnassignedMeeting Transcript 与 Transcript Statistics可开关时间戳/置信度的分段转写附总分段数、总词数、平均置信度、独立说话人数。下载报告点击 Download as Markdown即可将完整纪要导出文件名自动带上处理时间如meeting_notes_20260908_1030.md内容包含标题、处理时间、时长、纪要、说话人明细、行动项以及带时间戳和置信度的完整转写见 app.py 中 _generate_markdown_export。仓库还自带一段示例音频 audio/sample-audio-meeting.mp3可用于快速体验完整流程。五、源码解析AssemblyAI 转写与语言检测配置转写服务 transcriber.py 直接使用官方 SDK构造时通过aai.settings.api_key注入密钥并创建aai.Transcriber()见 L13-L16。真正核心的是TranscriptionConfig配置项见 L22-L33配置参数取值作用说明speaker_labelsTrue开启说话人分离让返回结果带 speaker 标识language_detectionTrue开启自动语言检测无需预知语种language_detection_options.expected_languages[en,es,fr,de,it,pt,hi,zh,ja,ko]给出优先候选语种提高检出准确率language_detection_options.fallback_languageauto候选之外仍自动兜底识别punctuateTrue自动加标点format_textTrue输出规范化文本大小写等dual_channelFalse不按双声道分离webhook_urlNone关闭异步回调采用轮询方式AssemblyAI 官方能力上语言检测与转写覆盖 99 种语言说话人分离覆盖 95 种语言因此英文、西班牙语、法语、德语、意大利语、葡萄牙语、俄语、日语、韩语、中文、阿拉伯语、印地语等常见语种都落在支持范围内README 的 Supported Languages 章节有专门说明。请求发出后采用轮询等待最多等待 300 秒、每 2 秒通过transcript.id拉取一次状态直到completed或error超时会抛出 Transcription timeout。转写失败时还会根据错误信息中是否出现speaker/language关键词给出针对性的排查提示音频质量与说话人区分度、语种是否受支持见 L37-L57。结果解析部分有四处关键处理分段提取_extract_segments把transcript.utterances逐条映射为TranscriptSegment开始/结束毫秒时间戳、speaker_id、文本、置信度并按开始时间排序保证时序L86-L109说话人统计_extract_speakers对每个 speaker_id 汇总发言时长毫秒转秒与词数L111-L136语种回读_get_detected_language优先从json_response的language_code字段取语言码回退字段取不到时默认enL138-L153时长获取get_transcript_duration优先读audio_duration否则从 json 响应取再不行由MeetingProcessor用最后一段的结束时间换算毫秒→秒兜底transcriber.py L76-L84。六、源码解析多语言 LLM 的四类文本分析文本分析服务 text_analyzer.py 内置gpt-4o通过 Chat Completions 完成四项子任务且每个任务都有明确的英文输出约束这是多语言输入 → 统一英文纪要的核心实现1. 生成结构化英文摘要generate_meeting_summary使用前 3000 字符要求 LLM无论原文是什么语言都输出英文并返回严格 JSONtopics_discussed/key_decisions/next_steps三个数组明确禁止把具体任务分派写进摘要例如不要出现 Juan will work on…随后格式化为三段要点文本L17-L104。请求参数max_tokens800、temperature0.1以保证低随机、格式稳定。2. 提取行动项extract_action_items使用前 2000 字符要求返回 JSON 数组每个元素含description / assignee / due_date / priority(high|medium|low)四个字段L106-L178。Prompt 中的关键语言规则是行动描述必须译为英文但人名、公司名、技术术语保留原文同时引导模型捕捉任务指派、后续跟进、截止日期、参会承诺、需跟进决策等六类信号。参数max_tokens500、temperature0.2。3. 识别说话人真实姓名identify_speaker_names使用前 1500 字符把 AssemblyAI 返回的A、B、C…这类 speaker ID 映射为真实姓名L180-L277。Prompt 内置了一套分析策略先找主持人通常开场/收尾、点名他人如 Juan, sigues tú再根据点名后谁接着发言来建立映射A先被叫到且随后发言则A很可能就是被叫到的名字不确定时回退为Speaker X参数max_tokens300、temperature0.1。4. 生成会议标题generate_meeting_title使用前 1000 字符只返回 3–8 个词的标题式短语Title Case例如 Weekly Team Standup参数max_tokens20、temperature0.3L282-L317。容错细节四类请求都会剥掉模型可能输出的 json 代码围栏再对 JSON 做json.loads解析失败时先用正则兜底抽取 JSON 片段仍失败才走默认值/返回空最大程度保证整条流水线不因一次 JSON 解析异常而中断。七、数据模型一览所有中间与最终结果都由 data_models.py 中的 dataclass 承载便于前端统一消费Speakerid、name、speaking_time秒、word_countTranscriptSegmentstart_time/end_time毫秒、speaker_id、text、confidence默认 0.8ActionItemdescription、assignee可空、due_date可空、priority默认mediumMeetingResult聚合标题、摘要、说话人、分段、行动项、语种、时长与处理时间并通过total_words、avg_confidence、unique_speakers_count三个计算属性直接给出转写统计供指标卡与导出文件使用。八、局限性与扩展建议从当前仓库实现出发以下几点是继续使用时需要注意的前提与可扩展方向依赖外部 API转写依赖 AssemblyAI文本分析依赖 OpenAI 兼容服务两者都需要真实 Key 且按调用量计费把TextAnalyzer的client/model替换为任意多语言 LLM本地部署模型或兼容网关即可实现完全本地化的分析链路长文本截断策略摘要/行动项/说话人识别/标题分别只取前 3000/2000/1500/1000 字符超长会议的中后段内容可能未被语义分析覆盖——若会议较长可考虑先分段再聚合map-reduce的方式改进语言回退默认值检测不到语种时默认en在 UI 上不会明显报错但会影响后续统计的语种语义说话人姓名识别依赖点名模式Prompt 对点名后接话的会议模式效果较好对无点名的自由讨论可能部分 speaker 落回Speaker X兜底属预期行为。结语结合 README 与仓库源码可以看到这个多语言会议纪要生成器把语音转写 说话人分离 多语言 LLM 文本分析这条成熟技术链组装成了一个开箱即用的 Streamlit 应用AssemblyAI 负责把任意语种的口语转为带说话人标签的文本LLM 负责统一产出英文纪要、真实姓名映射与可执行的行动项清单。对于团队有多语言会议纪要需求、或想上手打通ASR → LLM 结构化抽取 → Web 交付整条链路的开发者而言这份代码是很好的可运行范本。【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Multilingual Meeting Notes Generator：基于 AssemblyAI 与 LLM 的多语言会议纪要自动生成实战
Multilingual Meeting Notes Generator基于 AssemblyAI 与 LLM 的多语言会议纪要自动生成实战【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub导读本教程围绕multilingual-meeting-notes-generator项目展开讲解如何构建一个自动检测会议口语语种、输出英文结构化纪要含议题、关键决策、下一步、发言人级分析与行动项提取的多语言会议纪要生成器。读完本文你将掌握AssemblyAI 语音转写与说话人分离speaker diarization的配置方法、以任意多语言 LLM 驱动结构化摘要与行动项抽取的 Prompt 工程要点以及用 Streamlit 将整套流水线封装为可直接运行的 Web 应用的全过程。源码位置app.py核心服务在 src/services 目录配置依赖见 pyproject.toml。一、整体工作流程从音频到完整会议纪要项目以**流水线pipeline**方式串联多个能力正如 README 的 How It Works 所述整个流程分为五步音频输入用户上传会议录音文件语言检测AssemblyAI 自动检测会议使用语言转写方向支持 99 种语言语音转写高质量转写并开启说话人分离diarization以区分不同发言人智能处理由任意的多语言 LLM 完成摘要、发言人识别与行动项提取结果输出综合生成英文摘要、发言人分析、行动项与完整转写文本。这套流水线在源码中由 MeetingProcessor 统一编排它持有两个子服务转写交给AudioTranscriberAssemblyAI语义分析交给TextAnalyzer多语言 LLM最终把各环节结果封装为一个 MeetingResult 数据对象交给前端展示。其关键流程如下音频文件 │ AudioTranscriberAssemblyAI │ ① language_detectionTrue → 自动检测语种 │ ② speaker_labelsTrue → 说话人分离 ▼ 全量转写 分段(utterances) 说话人 语种 │ TextAnalyzerLLM │ ① identify_speaker_names → 给说话人分配真实姓名 │ ② generate_meeting_summary → 英文结构化摘要 │ ③ extract_action_items → 提取行动项 │ ④ generate_meeting_title → 生成会议标题 ▼ MeetingResult标题/摘要/说话人/分段/行动项/语种/时长 │ Streamlit UIui_components export ▼ 英文纪要 说话人分析 行动项 完整转写 Markdown 导出值得注意的健壮性设计process_meeting_audio在转写内容过短或分段为空时主动抛错而 LLM 分析说话人名识别、摘要、行动项、标题则各自包在try/except中单项失败只打印 Warning 并走兜底值不会中断整场处理——例如摘要失败时返回提示文案、标题失败时自动回退为 Meeting - 日期见 audio_processor.py。二、环境准备与依赖安装1. 准备 API Key参照项目根目录的 env_example.txt在项目根目录创建.env文件并填入两组密钥README 只写了 AssemblyAI Key但实际运行还需要一个 LLM 的 Key见源码与 UI 校验逻辑ASSEMBLYAI_API_KEYyour_assemblyai_api_key OPENAI_API_KEYyour_openai_api_key其中ASSEMBLYAI_API_KEY用于语音转写与说话人分离OPENAI_API_KEY由文本分析服务使用默认模型gpt-4o见 text_analyzer.py。也可以改用任意多语言 LLM——项目通过 OpenAI 兼容接口调用凡是支持 Chat Completions 接口且具备多语言能力的模型均可按此模式替换。2. 安装依赖项目使用 uv 管理依赖见 pyproject.tomlPython 要求3.9核心依赖包括streamlit1.49.1—— Web 界面assemblyai0.21.0—— 语音转写/语言检测/说话人分离openai1.99.9—— 多语言 LLM 分析与摘要python-dotenv1.0.0—— 加载.env执行以下命令即可一键同步环境uv sync三、运行应用安装完成后运行下面命令启动 Streamlit 应用uv run streamlit run app.py启动后浏览器会打开交互界面app.py从上传音频到纪要生成再到导出 Markdown 的完整闭环均由该页面承载。四、界面使用指南README 的 Usage 章节把操作分为四个步骤结合 app.py 的侧边栏实现可以拆得更细配置 API Key在左侧Configuration区域输入 AssemblyAI API Key 与 OpenAI API Key密码框形式。代码会先做基础格式校验——两把 Key 都不能为空且长度 ≥ 20 字符见 app.py 中 _validate_api_keys不合法会提示Invalid API key format。上传音频在Audio Input区域上传会议录音支持mp3 / wav / m4a / mp4 / webm / flac六种格式注意比 README 列举的四种更多。上传文件会被写入临时文件后再交给处理管线处理完毕自动删除并执行垃圾回收见 app.py 中 _save_uploaded_file / _cleanup_temp_file。开始处理点击 Start Processing处理全程有状态提示Processing… → Processing complete!失败则显示具体错误原因。查看结果主区域按序展示以下五块内容渲染逻辑见 ui_components.py顶部指标卡会议时长、说话人数、行动项数量Meeting Summary按 Topics Discussed / Key Decisions / Next Steps 三类渲染英文纪要Speaker Diarization每位说话人的发言时长与词数并可展开查看其全部发言片段Action Items按负责人分组展示行动项含截止时间与优先级无归属的归入 UnassignedMeeting Transcript 与 Transcript Statistics可开关时间戳/置信度的分段转写附总分段数、总词数、平均置信度、独立说话人数。下载报告点击 Download as Markdown即可将完整纪要导出文件名自动带上处理时间如meeting_notes_20260908_1030.md内容包含标题、处理时间、时长、纪要、说话人明细、行动项以及带时间戳和置信度的完整转写见 app.py 中 _generate_markdown_export。仓库还自带一段示例音频 audio/sample-audio-meeting.mp3可用于快速体验完整流程。五、源码解析AssemblyAI 转写与语言检测配置转写服务 transcriber.py 直接使用官方 SDK构造时通过aai.settings.api_key注入密钥并创建aai.Transcriber()见 L13-L16。真正核心的是TranscriptionConfig配置项见 L22-L33配置参数取值作用说明speaker_labelsTrue开启说话人分离让返回结果带 speaker 标识language_detectionTrue开启自动语言检测无需预知语种language_detection_options.expected_languages[en,es,fr,de,it,pt,hi,zh,ja,ko]给出优先候选语种提高检出准确率language_detection_options.fallback_languageauto候选之外仍自动兜底识别punctuateTrue自动加标点format_textTrue输出规范化文本大小写等dual_channelFalse不按双声道分离webhook_urlNone关闭异步回调采用轮询方式AssemblyAI 官方能力上语言检测与转写覆盖 99 种语言说话人分离覆盖 95 种语言因此英文、西班牙语、法语、德语、意大利语、葡萄牙语、俄语、日语、韩语、中文、阿拉伯语、印地语等常见语种都落在支持范围内README 的 Supported Languages 章节有专门说明。请求发出后采用轮询等待最多等待 300 秒、每 2 秒通过transcript.id拉取一次状态直到completed或error超时会抛出 Transcription timeout。转写失败时还会根据错误信息中是否出现speaker/language关键词给出针对性的排查提示音频质量与说话人区分度、语种是否受支持见 L37-L57。结果解析部分有四处关键处理分段提取_extract_segments把transcript.utterances逐条映射为TranscriptSegment开始/结束毫秒时间戳、speaker_id、文本、置信度并按开始时间排序保证时序L86-L109说话人统计_extract_speakers对每个 speaker_id 汇总发言时长毫秒转秒与词数L111-L136语种回读_get_detected_language优先从json_response的language_code字段取语言码回退字段取不到时默认enL138-L153时长获取get_transcript_duration优先读audio_duration否则从 json 响应取再不行由MeetingProcessor用最后一段的结束时间换算毫秒→秒兜底transcriber.py L76-L84。六、源码解析多语言 LLM 的四类文本分析文本分析服务 text_analyzer.py 内置gpt-4o通过 Chat Completions 完成四项子任务且每个任务都有明确的英文输出约束这是多语言输入 → 统一英文纪要的核心实现1. 生成结构化英文摘要generate_meeting_summary使用前 3000 字符要求 LLM无论原文是什么语言都输出英文并返回严格 JSONtopics_discussed/key_decisions/next_steps三个数组明确禁止把具体任务分派写进摘要例如不要出现 Juan will work on…随后格式化为三段要点文本L17-L104。请求参数max_tokens800、temperature0.1以保证低随机、格式稳定。2. 提取行动项extract_action_items使用前 2000 字符要求返回 JSON 数组每个元素含description / assignee / due_date / priority(high|medium|low)四个字段L106-L178。Prompt 中的关键语言规则是行动描述必须译为英文但人名、公司名、技术术语保留原文同时引导模型捕捉任务指派、后续跟进、截止日期、参会承诺、需跟进决策等六类信号。参数max_tokens500、temperature0.2。3. 识别说话人真实姓名identify_speaker_names使用前 1500 字符把 AssemblyAI 返回的A、B、C…这类 speaker ID 映射为真实姓名L180-L277。Prompt 内置了一套分析策略先找主持人通常开场/收尾、点名他人如 Juan, sigues tú再根据点名后谁接着发言来建立映射A先被叫到且随后发言则A很可能就是被叫到的名字不确定时回退为Speaker X参数max_tokens300、temperature0.1。4. 生成会议标题generate_meeting_title使用前 1000 字符只返回 3–8 个词的标题式短语Title Case例如 Weekly Team Standup参数max_tokens20、temperature0.3L282-L317。容错细节四类请求都会剥掉模型可能输出的 json 代码围栏再对 JSON 做json.loads解析失败时先用正则兜底抽取 JSON 片段仍失败才走默认值/返回空最大程度保证整条流水线不因一次 JSON 解析异常而中断。七、数据模型一览所有中间与最终结果都由 data_models.py 中的 dataclass 承载便于前端统一消费Speakerid、name、speaking_time秒、word_countTranscriptSegmentstart_time/end_time毫秒、speaker_id、text、confidence默认 0.8ActionItemdescription、assignee可空、due_date可空、priority默认mediumMeetingResult聚合标题、摘要、说话人、分段、行动项、语种、时长与处理时间并通过total_words、avg_confidence、unique_speakers_count三个计算属性直接给出转写统计供指标卡与导出文件使用。八、局限性与扩展建议从当前仓库实现出发以下几点是继续使用时需要注意的前提与可扩展方向依赖外部 API转写依赖 AssemblyAI文本分析依赖 OpenAI 兼容服务两者都需要真实 Key 且按调用量计费把TextAnalyzer的client/model替换为任意多语言 LLM本地部署模型或兼容网关即可实现完全本地化的分析链路长文本截断策略摘要/行动项/说话人识别/标题分别只取前 3000/2000/1500/1000 字符超长会议的中后段内容可能未被语义分析覆盖——若会议较长可考虑先分段再聚合map-reduce的方式改进语言回退默认值检测不到语种时默认en在 UI 上不会明显报错但会影响后续统计的语种语义说话人姓名识别依赖点名模式Prompt 对点名后接话的会议模式效果较好对无点名的自由讨论可能部分 speaker 落回Speaker X兜底属预期行为。结语结合 README 与仓库源码可以看到这个多语言会议纪要生成器把语音转写 说话人分离 多语言 LLM 文本分析这条成熟技术链组装成了一个开箱即用的 Streamlit 应用AssemblyAI 负责把任意语种的口语转为带说话人标签的文本LLM 负责统一产出英文纪要、真实姓名映射与可执行的行动项清单。对于团队有多语言会议纪要需求、或想上手打通ASR → LLM 结构化抽取 → Web 交付整条链路的开发者而言这份代码是很好的可运行范本。【免费下载链接】ai-engineering-hubIn-depth tutorials on LLMs, RAGs and real-world AI agent applications.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-hub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考