这个环境需要时linux，版本依赖在requirements.txt，版本蛮麻烦，全是bug
启动需要在根目录 命令都在操作指南.md
前端要做的主要就是
1.展示所有meeting
2.用户可以选择的操作是1.创建新的meeting，有一个录音功能。录音完了之后就提交。2.用户可以查看meeting列表中的某一个meeting的详情
3.创建新的meeting之后，重新获取列表。后端使用异步处理，所以直接展示就可以。
4.剩下的交互就是直接在前端做。就不经过后端了。包括历史对话啥的
5.用户进入指定的meeting详情的时候：
- 先请求 GET /meetings/{id} 获取 meeting.status
- 如果 status=processing：前端进入“处理中”状态，并做轮询
- 推荐每 2s 轮询一次 GET /meetings/{id}（或 GET /meetings/{id}/context 也行）
- 超时策略：例如最多轮询 10 分钟；到时间还没 done 就提示用户“仍在处理，可稍后再进来”
- 如果 status=done：请求 GET /meetings/{id}/context，渲染结构化文本
- 如果 status=failed：展示 error
- 备注：后端是异步任务，不会“主动回送”；最简单可控的方案就是前端轮询。
6.结构化文本（utterances）旁边建议加两类交互：
- 播放按钮：每条 utterance 都对应一个 message（1:1），message 的 start_s/end_s 来自完整音频切片。
- 前端点击播放时请求 GET /meetings/{meeting_id}/messages/{message_id}/audio，拿到 wav 直接播放。
- 改绑说话人：每条 utterance 渲染一个下拉框（用户列表来自 GET /users），可选择现有用户或新建用户。
然后前端在每一个用户那里都渲染一个下拉框，也可以新建用户角色，也可以选择现有的，也是跟后端查询。
7.修改完了之后点击上交就是覆盖，然后重新请求一遍这个meeting对应的结构化数据
后端 API 和前后端交互使用的数据结构见 联调.md
如果创建新的应用的话，就要重新创建一个app.db。 然后目前的方案是这样，我的huggingface-cli有问题，使用了本地的whisper这个asr模型，然后处理过程是这样 后端接收到一个audio的二进制数据之后，先把数据存到app.db里面去，然后提取出来根据文件头转成对应的文件。 然后有了文件，处理流程大致是:先VAD处理，增强+切割静音片段。分离片段也是利用VAD进行分离，然后通过声纹向量的embedding计算余弦相似度然后进行匹配。 有一个误差区间的。然后将每一段的VAD之后的片段都给ASR进行识别，然后生成一个个的Message，然后将Message与meeting-id绑定。按照slice的顺序输出的结构化数据。 默认的asr使用的是whisper ASR，如果需要更换阿里云的就设置环境变量，具体在操作指南.md的1.1 然后操作指南里面有启动命令 前后端的联调的话主要就是联调.md和数据说明.md 本地测试我使用的是操作指南.md里面的
python tools/upload_and_rename_two_http.py \
--base-url http://localhost:8000 \
--audio-path "/mnt/c/Users/20332/Documents/xwechat_files/wxid_xmfw2nu57inr12_9f6c/msg/file/2025-12/meeting_20251218_171043.wav" \
--name "2025-12-18 会议" \
--description "寝室舍友在打三角洲" \
--rename "张三,李四" \
--wait-seconds 1200现在的逻辑就是，对于库里存在非常相似的就会复用这个voice id ，否则创建新 的voice id，然后用户来判断
这个直接测试没有问题，考虑实时性，可能前端还是需要进行一个轮询，但是频率不用太高
"# intelligent_program"