处理进度条实时更新，让用户清晰掌握Fun-ASR任务执行状态
在语音识别系统日益普及的今天，一个常被忽视却至关重要的问题浮出水面：用户面对长时间运行的任务时，往往陷入“黑屏等待”的焦虑中。尤其是当上传了十几个会议录音或一整季播客准备转写时，点击“开始”后界面毫无反应——这种体验几乎让人怀疑程序是否卡死。
这正是 Fun-ASR 在设计批量处理功能时重点解决的问题。作为钉钉与通义联合推出的轻量级语音识别平台，它没有止步于模型准确率的优化，而是将用户体验延伸到了任务执行过程本身。通过引入实时处理进度条机制，系统不再是封闭的“黑盒”，而是一个持续反馈、可追踪、有温度的交互伙伴。
这个看似简单的进度条背后，其实融合了前后端协同、状态管理、异常容错和人机交互设计的多重考量。它的核心并不只是“显示百分比”，而是构建一套完整的任务可观测性体系。
整个机制的核心驱动力来自 Python 的生成器（generator）特性与 Gradio 框架的流式响应能力结合。传统 Web 请求是“请求-响应”一次性完成的模式，不适合长时间任务。而 Fun-ASR 采用yield关键字，在函数执行过程中分阶段返回中间结果，使得前端能够逐步接收并刷新 UI 状态。
比如，当你提交一组音频文件时，后端会立即进入一个循环处理流程：
def batch_transcribe(files, language="zh", use_itn=True): total = len(files) if total == 0: yield 0, "未检测到文件，请重新上传", None return results = [] for idx, file in enumerate(files): filename = file.name.split("/")[-1] yield (idx + 1) / total, f"正在处理: {filename}", None time.sleep(2) # 模拟 ASR 推理延迟 transcribed_text = f"[模拟] 这是 {filename} 的识别结果。" results.append({ "filename": filename, "text": transcribed_text }) df = pd.DataFrame(results) yield 1, "全部处理完成！", df这段代码的关键在于使用了yield而非return。每次yield都会把当前进度（0~1）、状态提示和中间输出推送到前端。Gradio 自动捕获这些值，并驱动gr.Progress()组件更新进度条、文本提示和表格预览区。
这意味着用户不再需要轮询接口或依赖 WebSocket 来获取状态——单次 HTTP 请求就能实现“边处理边展示”的效果。不仅降低了网络开销，也避免了浏览器超时限制带来的中断风险。
但真正让这一机制落地的，远不止技术选型这么简单。工程实践中有很多细节决定了它的稳定性和可用性。
首先是进度映射的准确性。理想情况下，每个文件处理耗时相近，那么按文件数平均分配权重即可。但在实际场景中，有的音频长达半小时，有的只有几十秒。如果简单地用(已处理数 / 总数)计算进度，可能会出现前9个短文件快速跳到90%，然后最后一个长文件卡住半小时的情况，反而加剧用户焦虑。
因此更合理的做法是对大文件进行内部细分。例如结合 VAD（语音活动检测）将长录音切分为多个语段，在单个文件内部也提供子进度反馈。这样整体进度曲线会更加平滑，预估剩余时间也更有参考价值。
其次是错误隔离与容错能力。批量任务中最怕“一颗老鼠屎坏了一锅粥”。某个文件格式损坏或编码异常，不应导致整个批次中断。系统应在捕获异常后记录错误日志，标记该文件为失败状态，继续处理后续文件。最终结果表格中可通过颜色区分成功/失败项，并支持单独重试。
再者是资源调度感知。在 CPU 模式下，ASR 处理速度可能仅为实时速率的 0.3~0.6 倍，意味着一段 10 分钟的录音要花近 20 分钟才能转写完。此时若能在状态栏动态显示“预计剩余 XX 分钟”，能极大提升用户耐心。而开启 GPU 加速后（如 CUDA 或 MPS），推理速度可提升至 1.5x 以上，进度推进明显加快。系统可根据设备类型自动调整预期，帮助用户合理安排任务批次。
从架构角度看，该功能嵌入在 Fun-ASR WebUI 的任务闭环中：
[前端界面] ↓ 文件上传 + 参数配置 [Gradio 后端服务] ↓ 触发 batch_transcribe 函数 [任务调度层 → 文件遍历循环] ↓ 逐个调用 ASR 推理引擎（funasr-sdk） [状态管理器 ←→ Progress 组件 & 日志显示]整个链路依托 Gradio 的事件驱动模型，实现了从输入到输出的端到端反馈。所有中间状态都通过内存中的临时对象共享，无需额外数据库写入，保证低延迟的同时也减少了 I/O 开销。
当然，也有一些边界情况需要特别注意。比如用户在处理中途关闭页面怎么办？虽然目前版本尚未引入后台任务队列（如 Celery），但至少可以通过 JavaScript 监听beforeunload事件，弹出确认框提醒：“任务仍在运行，关闭浏览器将停止处理”，防止误操作。
另外，批处理规模也需要合理控制。建议每批不超过 50 个文件，以防内存堆积或浏览器响应阻塞。对于更大规模的需求，未来可扩展为支持断点续传、分布式处理甚至邮件通知的生产级工作流系统。
有趣的是，这个功能的价值并不仅体现在技术层面，更深刻影响着用户的信任感和使用习惯。当用户能看到“正在处理第 7 个文件（共 20）”时，他们会更愿意等待；当发现某文件失败时，也能快速定位是否是格式问题或静音片段。这种透明化设计，让 Fun-ASR 从一个“能跑模型”的工具，进化为一个真正可信赖的生产力平台。
无论是企业用户整理上百条客服录音，还是学生复盘讲座内容，清晰的过程反馈都在无形中提升了工作效率与满意度。而这正是现代 AI 应用区别于早期实验性项目的标志之一：不再只追求“能不能做”，而是深入思考“好不好用”。
可以预见，随着更多高级特性的加入——比如多任务并行调度、GPU 利用率监控、历史任务对比分析——这类细粒度的状态可视化将成为智能语音系统的标配。而 Fun-ASR 正通过这样一点一滴的打磨，逐步树立起国产开源 ASR 工具的专业形象。
