给语音输入加个草稿区：边说边看，用口述修改前文

用语音输入写长一点的东西时，我常常说到一半就想回头改：前面有个名字说错了，某段解释重复了，或者两段的顺序不太对。可录音结束前看不到文字，等结束了再用键盘一处处找，说话的节奏也就断了。

所以我在自己用的闪电说 Windows 客户端上做了一个本地改造：给原来的录音胶囊加一个能展开的草稿区。说话时可以看到转写和整理好的段落。想改前面的内容，就切到“修改前文”，把要求说出来，先看红色删除、绿色新增的差异，确认后再接着说正文。

最近几轮自己用下来，主要流程已经能顺利走通。下面讲讲怎么用、怎么做的，以及几个花了不少功夫的细节。这是个人改造，不是官方功能，文中也不提供客户端或补丁。

#说话时就能看到文字

原来的用法没变，右 Alt 照常开始和结束录音。想看文字时，按左 Alt+Space 打开草稿区，焦点会落到面板上；如果面板已经开着，再按一次就把焦点拿回来。在面板里按 F 可以收起，录音不受影响。

实际使用中的草稿区。截图只用来展示界面，不代表识别准确率。

文字是边说边出来的。还在识别的那一句先显示出来，确认之后再一段段整理。这样我能随时发现漏了什么，也分得清哪些字还会变、哪些已经定下来了。想对照时，可以在“整理稿”和“原话”之间切换。

面板大小固定，正文长了就在面板里滚动；收起时胶囊的底边位置不变。要是每次展开、收起窗口都跳一下，其实挺打断思路的。

#用说话来修改前文

举个例子：已经说了几段，发现第一段的一个名字写错了。进入修改后，左边是修改要求，右边是正文。我可以说“把第一段的某某改成……”，也可以直接在左边打字，把准确的拼写补上。

生成的结果先作为候选显示，原文这时还没被替换。右边用红色标出删掉的部分、绿色标出新增的部分，看过之后选“保留”或“撤销”；不满意就改一下要求，重新生成。

候选直接显示在正文对应的位置，方便连着上下文看。这里的“撤销”只是放弃还没采纳的候选。

这几个操作名字相近，作用不一样：

生成成功后，这次处理过的要求会自动清空，候选还留着。之后如果又输入了新要求，旧候选就不能直接采纳，得重新生成；手动清空要求，也不会让过期的候选重新可用。

“清空”按钮修过一个很典型的 bug：我点它本来只想清掉左边的要求，结果右边的候选也一起没了。原因是这两块状态被绑在了一起，拆开以后，按钮的效果才和名字对得上。

目前还没有“采纳后再撤回”的功能，所以点保留之前最好看一眼差异。整轮录音结束时，只有保留过的修改会进入最终整理，没确认的候选会被丢掉，修改要求本身也不会混进正文。

#快捷键：要顺手，也不能抢输入

面板里的常用操作都有单键：E 进入修改或生成，Z 保留，X 撤销，B 返回正文，S 清空要求，C 切换原话和整理稿，F 收起。A 控制修改要求的收音；识别断流后，也可以用它手动重新连接。

这些单键只在面板有焦点、并且光标不在输入框里时才起作用。在左边打字时，按字母就是输入字母，不会误触按钮。这套流程主要用两个全局按键：左 Alt+Space 打开并聚焦面板，右 Alt 还是原来的录音键。

Alt+Space 在 Windows 上有个坑：它本来就是打开窗口系统菜单的快捷键。我遇到过按完以后弹出“移动、最小化、关闭”菜单的情况。虽然 Space 已经被接管，松开 Alt 时系统仍可能当成单按了一次 Alt。按键我没改，只在接管组合键时顺带把这个菜单压住。在单独的测试窗口里，改之前的代码会触发一次菜单；改之后按四次组合键、试两种松键顺序，都没再弹出。不过这只验证了这一处，没在各种软件、权限和多屏环境下逐一试过。

#背后的几层分工

原客户端仍然负责录音入口、胶囊，以及最后把文字输入出去。新加的界面负责显示草稿、收集修改要求、对比候选；一个本地服务负责转发流式识别和模型请求；还有一个很小的 Windows 辅助程序，管窗口位置、焦点和快捷键。

文字大致是这样流动的：

说正文 → 实时识别 → 已确认段落 → 分段整理 → 草稿区
说修改要求 → 独立的要求文本 → 模型生成候选 → 查看差异 → 保留
结束录音 → 最终整理 → 原客户端的输入流程

有一点要说清楚：原程序不会把实时文字交给这个浮窗，所以我另外采集了一路音频，专门做实时预览。这意味着语音识别会多一份用量，分段整理和修改也会多出模型调用。它也不是离线工具：音频会发到配置好的语音识别服务，正文和修改要求会发到配置好的模型服务。

我现在用火山的语音识别，整理用 DeepSeek。为了少等一会儿，分段、修改和终稿都关掉了思考模式。代价也实实在在：有一次测试纠正专有名词，用短提示词的请求很快就返回了，但名字并没有改过来。快不等于改得对，所以看差异、重新生成、直接打字给出拼写这几步我都留着。

#最麻烦的是切换时的状态

正文和修改要求必须是两套独立的内容，不能只是同一个输入框换个标题。切换的那一刻，可能还有音频在路上，识别的尾句还没回来，上一次模型请求也没结束。晚到的结果如果落进了新状态，就会把修改要求写进正文，或者用旧结果盖掉刚输入的内容。

我的做法是给每一轮录音、每一次修改都标上归属。切换时，把这一轮该收的内容收齐，过期的结果一律不再写入。按 B 返回正文时，还在等的修改请求会被取消，就算旧结果晚到，也不会覆盖正文。

还遇到过一次断流，服务端提示连续 8 秒没收到音频包。这条提示只能说明服务端没收到，到底是麦克风、浏览器还是转发链路出了问题，光凭它判断不了。现在断流后仍可以手动修改要求、清空或重新生成，也能重新连接、继续收音。但重连不代表刚才没丢字，这一轮会继续带着“可能不完整”的提示，必要时我会先核对再复制。

#现在做到哪一步

最后一轮改动跑过了 207 项 Node 自动检查，以及三种面板宽度、明暗两套主题共 6 组浏览器检查，覆盖了保留候选、清空、过期结果、取消请求这些行为。这些都是自动测试，浏览器里的音频用的是合成数据，代替不了真实的麦克风。

另一部分是我自己的使用：主要的口述和修改流程都试过，目前没遇到影响使用的问题。长时间录音、复杂的多屏环境和不同的窗口权限，还要在日常使用里继续观察；模型有没有理解每条要求，也得每次自己看。

对我来说，最有用的是说话过程中就能看到文字、改掉错处、确认结果。花心思最多的反倒是几个看着很普通的动作：清空只清要求，撤销只扔候选，切换时文字不串，快捷键不抢输入。

最后说明一下：这篇只分享个人改造的界面和设计思路，不提供修改后的客户端、补丁或下载。原软件的使用和修改仍受它的服务条款约束，个人学习用途也不代表已经获得官方授权。