2.8 KiB
2.8 KiB
独立 WebUI 项目路线
定位
独立的会议、电话录音处理应用。WebUI 是主要操作界面，Telegram 只做可选通知， 不依附任何 Agent CLI。当前源码已抽出，但仍是旧实现基线，尚未独立部署上线。
目标架构
浏览器 → 应用 API → 持久化任务队列 → 后台 Worker → 外部 ASR / LLM / Hindsight。 SQLite 保存任务、处理阶段、审核、实体词库和修改历史；原音频、中间产物单独保存。 Obsidian 是可选发布目标，不是应用内部的任务队列或运行数据库。
ASR GPU 服务继续位于 unRaid，模型调用优先接入统一 LiteLLM。 应用状态、配置和存储必须通过环境配置，不绑定特定机器或个人工作区。
核心页面
- 任务列表：上传、背景输入、进度、失败原因、重试、最近任务。
- 任务详情：原音频播放、带说话人与时间轴的原文、处理版本、来源。
- 审核：背景确认、候选词、说话人身份、关键歧义、最终纪要确认。
- 词库：实体、别名、模糊音规则、关系和人工确认历史。
- 设置：ASR、LLM、Hindsight、通知、输出路径和数据保留策略。
实施顺序
第一阶段：独立运行闭环
- 配置与运行数据分离；迁移个人词库、审核状态时使用一致性备份。
- 将 systemd 路径监听/模板任务改为应用内部持久化队列与 Worker。
- 实现任务互斥、幂等、重启恢复、超时和阶段重试，不重跑已确认步骤。
- 修复独立通知适配器，停止依赖本机 Hermes 状态文件。
- 对照现有 vault SOP，审计输出路径；只有确认后的正式稿可发布。
- 上传、转写、审核、发布全链路通过后，再切换生产消费者。
第二阶段：WebUI 完整化
- 保留现有纯 Python 页面作过渡，先明确 API 和状态模型，再选前端框架。
- 增加播放器、原文对照、编辑、版本回退与清晰的阶段状态。
- 把说话人确认、词库维护及上下文确认放入一致的任务工作流。
第三阶段：Docker 发布
- API/WebUI 和 Worker 可分别运行；持久卷承载 SQLite 与音频。
- 不在容器内运行 systemd；不依赖宿主 Agent home。
- Obsidian 发布器可持有专用 Git checkout，不直接修改主工作副本。
- 确定 Dockerfile 与验收测试后，再接 GitHub Actions + GHCR 构建发布。
验收原则
原文不可覆盖；候选纠错须有依据；背景不伪装为录音事实；重要歧义交人工确认。 以关键内容和行动线索为目标，不追求伪精确的逐字恢复。 合成测试与真实录音端到端验收分开，不能以单元测试通过代替上线验收。
本文件是后续开发计划，本轮不新增推理请求、不切换生产服务、不自动部署容器。