识别历史管理功能上线：轻松查询与导出过往结果
在语音技术逐渐渗透进日常办公、医疗记录和客户服务的今天，一个常被忽视的问题浮出水面：我们如何找回上周那场会议的转录文本？那个加了热词但结果仍不理想的音频，还能不能复现当时的识别条件？很多本地语音识别工具能“听”，却无法“记”——任务一结束，结果就随页面刷新而消失。
Fun-ASR WebUI 最近推出的“识别历史”功能，正是为了解决这个看似简单却影响深远的痛点。它不再把每次识别当作一次孤立操作，而是构建了一条可追溯、可检索、可沉淀的数据链路。这不仅是功能叠加，更是一种思维方式的转变：从“做完即忘”到“用过留痕”。
当一次语音识别完成时，系统并没有就此停步。相反，它悄悄启动了一个自动化归档流程。识别结果、原始文本、是否启用ITN（文本规整）、使用的热词、目标语言、时间戳、文件路径……这些信息被打包成一条结构化记录，写入本地 SQLite 数据库history.db中。整个过程对用户完全透明，无需手动保存或命名，就像后台有个自动记笔记的助手。
这个设计背后有个明确判断：真正的易用性，不是让用户做更多选择，而是替他们记住该记的事。
数据库表结构简洁但完整：
CREATE TABLE recognition_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, filename TEXT NOT NULL, filepath TEXT, language TEXT, hotwords TEXT, itn_enabled BOOLEAN, raw_text TEXT, normalized_text TEXT );每一列都对应实际使用中的关键上下文。比如当你发现某段专业术语识别不准，就可以回溯历史记录，确认当时是否漏掉了热词配置；又或者想对比不同语言模型在同一类音频上的表现，只需按语言字段筛选即可快速比对。
前端展示默认列出最近100条记录，按时间倒序排列。你可以通过关键词模糊搜索文件名或识别内容，系统会实时过滤匹配项。点击任意记录ID，弹窗即显示完整详情。支持单条删除或清空全部记录（后者需二次确认），避免误操作导致数据丢失。
更重要的是，这些数据不是锁死在系统里的“黑箱”。用户可以直接导出为 CSV 或 JSON 格式，无缝对接其他分析工具或归档系统。对于需要合规存档的场景——比如法律咨询录音、医疗问诊记录——这种本地可控的数据出口尤为关键。
来看一个典型场景：你在周五上传了一份名为strategy_review_20250405.wav的会议录音，设置了中文识别并启用了ITN，还添加了几个项目代号作为热词。识别完成后关闭了浏览器。三天后同事问起会上提到的“Q2资源分配方案”，你已经不记得具体细节。
过去的做法可能是重新上传、重新识别，甚至找不到原文件。而现在，你打开 Fun-ASR WebUI，切换到“识别历史”页，在搜索框输入“Q2”，系统瞬间高亮出那条记录。点击查看，原文清晰呈现：“Q2资源将优先投入A项目，B项目暂缓。”随后一键导出为CSV，附在邮件中发送给团队。
整个过程没有翻找文件夹，没有重复识别，也没有依赖云端服务。所有操作都在本地完成，数据始终掌握在自己手中。
实现上，核心逻辑非常轻量。Python 后端通过标准sqlite3模块完成数据持久化：
import sqlite3 from datetime import datetime def save_recognition_record(filename, filepath, language, hotwords, itn_enabled, raw_text, normalized_text): conn = sqlite3.connect('webui/data/history.db') cursor = conn.cursor() cursor.execute(''' INSERT INTO recognition_history (timestamp, filename, filepath, language, hotwords, itn_enabled, raw_text, normalized_text) VALUES (?, ?, ?, ?, ?, ?, ?, ?) ''', ( datetime.now(), filename, filepath, language, "\n".join(hotwords) if hotwords else "", itn_enabled, raw_text, normalized_text )) conn.commit() conn.close() print(f"Record saved for {filename}")这里有几个实用考量：
-hotwords以换行符拼接存储，既保持可读性，也便于后续解析；
- 时间戳由 Python 层统一生成，避免数据库端与应用端时间不一致；
- 显式调用commit()确保事务落地，防止意外中断导致写入失败。
前端通过一个极简的 Flask 接口获取历史摘要：
from flask import jsonify @app.route('/api/history', methods=['GET']) def get_history(): conn = sqlite3.connect('webui/data/history.db') conn.row_factory = sqlite3.Row cursor = conn.cursor() cursor.execute('SELECT id, timestamp, filename, language FROM recognition_history ORDER BY timestamp DESC LIMIT 100') records = [dict(row) for row in cursor.fetchall()] return jsonify(records)只返回关键字段，减少传输负担，页面加载更快。真正需要查看详情时再按 ID 查询完整内容，这是一种典型的“懒加载”思维，在资源受限的本地环境中尤为重要。
这套机制虽然简单，但它解决了几个长期存在的现实问题：
| 用户痛点 | 对应解决方案 |
|---|---|
| 结果容易丢失 | 自动持久化，断电不丢 |
| 多次识别难以区分 | 记录时间、参数、文件名等元信息 |
| 查找旧内容费时费力 | 支持全文模糊搜索，响应迅速 |
| 缺乏统一导出方式 | 支持CSV/JSON导出，便于后续处理 |
| 数据无法积累复用 | 形成本地语音文本知识库雏形 |
特别是在多人共用设备或高频使用的场景下，这种系统化的管理能力直接决定了工具能否真正融入工作流。
当然，也要面对一些边界情况。SQLite 虽然轻便，但长期运行可能面临数据库膨胀问题。建议定期清理无用记录，或将重要数据导出备份。history.db文件本身也可直接复制迁移，配合外部存储或版本控制工具（如 Git LFS）实现轻量级历史追踪。
安全方面，由于识别内容可能包含敏感信息，应避免将数据库文件暴露在共享目录中。在公共设备上使用后及时清除他人记录，或结合操作系统权限进行访问控制，都是值得推荐的做法。
未来扩展空间也很清晰：比如增加标签分类（会议/访谈/培训）、支持自定义导出模板、甚至对接外部数据库（MySQL/PostgreSQL）以适应更大规模部署。但当前版本坚持“够用就好”的原则，专注于解决最普遍的需求——让每一次识别都能被记住。
从工程角度看，“识别历史”这类功能往往不像识别准确率提升那样引人注目，但它却是系统走向成熟的标志之一。准确率决定你能不能“听清”，而数据管理能力决定你能不能“用好”。
Fun-ASR WebUI 正是通过这样一系列扎实的迭代，逐步摆脱“玩具级”工具的标签。它不再只是一个能跑模型的界面，而是一个具备数据意识、支持闭环操作的生产力平台。在这个语音交互日益频繁的时代，那些默默工作的“幕后模块”，或许才是决定用户体验深浅的关键所在。
