从用户输入到结果复用的完整链路
- 录音试听、文件上传、异步转写与历史内容读取。
- 时间戳定位、同步高亮、生词候选及 TXT / SRT 导出。
- 账户归属检查、对象存储直传、阶段队列与两类转写引擎。
- Chromium 回归使用模拟 API 和麦克风,覆盖录音、播放、跳转、失败恢复与移动布局。
PART 02 / 从性能目标,到整体架构
左侧看完整架构,右侧读设计。选择维度,再点图中编号。
先看全局:业务请求、媒体文件和耗时任务各走自己的路径。
处理顺序:上传 → 转码 → 回报任务服务 → 长短转写分流 → 保存结果。图示为逻辑架构,云端 worker 需按部署启用。
识别 API 提供语音识别能力,单体也可以实现完整产品。这里比较的是三种实现范围与资源组织方式;Vox 的价值在于把这些能力接成了可持续使用的工作流。
左右滑动,查看完整方案对比 →
| 关注点 | 仅接入转写 API最小接入方式 | 同步单进程应用Web 与耗时处理同部署 | Vox归档 + 回听 + 异步处理 |
|---|---|---|---|
| 转写之后 | 得到识别结果;个人内容库与回听交互需继续建设。 | 可以实现归档与阅读,体验取决于额外的产品设计。 | 文件、结果、时间戳和生词在同一工作台中关联,支持再次使用与导出。 |
| 等待长任务 | 调用方负责管理等待、状态和结果保存。 | 同步处理会延长请求等待,并与 Web 共享运行资源。 | 任务创建与执行分开;阶段与结果可查询,前端定期更新。 |
| 增加处理能力 | 受服务提供方配额和调用预算约束。 | 通常以整个应用为部署单位;也可进一步拆分后台任务。 | 按转码、短转写、长转写分别增加消费者,针对积压分配资源。 |
| 引擎与成本选择 | 采用选定提供方的能力与计费方式。 | 同样可以集成不同引擎,但需自行设计切换与结果适配。 | 以统一接口接本地与云端引擎,按时长分流;成本取舍可继续调优。 |
| 需要承担的复杂度 | 接入轻;仍需补齐用户、内容管理与异常处理。 | 部署和本地调试简单,适合较小规模或早期验证。 | 增加了跨服务通信、队列、部署与一致性治理成本。 |
适合 Vox 的场景:希望长期积累音视频资料、经常按句复听,且转码与转写负载需要分别安排资源。
固定音频、任务目标、模型版本、硬件与并发条件,先记录基线,再比较优化后的表现。以下是测量计划,目前尚无量化基准结果。
以下链接指向仓库实现,便于继续追问设计细节。没有用未经测量的性能数字或“零丢失”承诺代替验证。
两类转写引擎已有实现;当前 Compose 没有包含云端 worker,需按实际部署启用。任务阶段与结果可查询,处理中的状态回报仍需完善。搜索目前针对文件名与 ID;段落定位依赖已有时间戳。未提交的录音草稿只保存在当前页面,提交成功后才进入服务器端内容管理。真实设备、线上存储及 Safari/iOS 仍需联调验证。
设计回到使用中,才有意义
体验录音、转写与按句回听,或回到性能理念继续了解产品目标。