按一下 说话 文字就出现在光标处

边界

架构

1. 1界面进程（Qt）

   • 所有操作走同一个入口
   • 全局热键 F2，先于模型启动
   • 原生绘制的录音胶囊
   • 交付与本地历史

2. 2三个受监督的子进程

   • 录音进程：采集麦克风，同时留一份可恢复的录音
   • 预览进程：流式模型，边说边出字
   • 识别进程：SenseVoice 读完整段录音，出终稿

3. 3交付链

   • 写入剪贴板，逐字回读核对
   • 复核停止那一刻的前台窗口
   • 只发一次 Ctrl+V，不盲目重试
   • 写进本地历史

每个子进程都有心跳、有界队列和强制结束路径。驱动或模型卡死，只重启那一个进程，界面和热键照常响应。

每次听写都可以恢复。停下的那一刻，先锁定最后一段声音，预览随即作废，终稿只认对完整录音的识别结果。文字在剪贴板里核对无误、写进历史，才算完成；没送到的录音留在本机，下次启动时提醒找回。

取舍

• 默认只带 SenseVoice 一个终稿模型

  原因同机、中英各一条公开样本上，它最快，也没有输；Qwen3-ASR 输出了繁体，Whisper 多出约 1 GB 却没有更好

  放弃的方案让用户在设置里自己挑模型

• 预览和终稿分开

  原因流式模型负责“快”，完整音频负责“准”，预览永远不能覆盖终稿

  放弃的方案一个模型同时管两件事

• 不接在线识别

  原因它会打破“离线”这个承诺

  放弃的方案更多模型、更高的上限

• 成功时不弹“已完成”

  原因文字已经出现在输入框里，再确认一次只会显得更慢

  放弃的方案每次都播一段确认动画

• 胶囊改用 Qt 原生绘制

  原因一个 34 px 高的小胶囊，不该带上整套 Chromium 运行时

  放弃的方案更省事的网页渲染

验证

v0.3.1 在发布机上实测（Windows 11 · Ryzen 7 5800H）。每一档 20 个样本，数字是 95% 的情况都能做到的值：

• 6 ms按下 F2 到第一帧反馈门槛 ≤ 50 ms
• 427 ms10 秒内的录音，说完到送出文字门槛 ≤ 500 ms
• 541 ms两分钟的录音，说完到送出文字门槛 ≤ 2.5 s
• 1,024 MB安装后私有内存（v0.3.1）早期 1,324.6 MB

• 829 项自动化测试，v0.3.3 时是 396 项。
• 500 次录音生命周期，10,000 组随机的开始、停止、取消、退出序列，50,000 个异常文本模糊用例。
• 从 v0.3.2 起，每个版本都附一份发布与验证记录。
• 用户提过的 12 条反馈，每条都写下结论和理由：采纳、按门槛暂缓，或者拒绝。

这些是延迟和机制的证据，不是准确率。项目的规矩：没有足够的授权真实语料，就不对外宣称准确率。

历程

1. 2026.05.23第一次提交
2. 2026.07.04v0.1.0 发布
3. 2026.07.28v0.2.0：逐条回应 12 条用户反馈
4. 2026.08.10v0.3.0：可恢复的会话，交付前先核对剪贴板
5. 2026.08.25v0.3.2：三个受监督的子进程，每版附发布证据
6. 2026.10.11v0.3.8：原生胶囊
7. 2026.10.21v0.3.9：设置只留一个保存入口，词典可以搜索、批量删除、撤销；822 项测试
8. 2026.10.22v0.3.10：设置界面按系统设置的样子重做；识别中的字逐个淡入，终稿原地替换草稿；829 项测试