你的听写不该就这么消失

九十秒完全按我想要的说法说出来的东西 — 一整段 PR 描述，一封写给客户的谨慎回复 — 然后在插入的那一刻，某个小地方出了岔子。目标窗口没有被聚焦。粘贴没生效。应用打了个嗝。于是文字就这么没了。没有被保存在哪里。没有待在某个缓冲区里。没了。任何把插入当作转写唯一一份副本的听写流水线，都有这个失败模式。

接下来是一种具体而失衡的愤怒，我觉得它是正当的。丢掉的那点时间不是重点。重点是活是你干的 — 你把想法组织好了，你说得也漂亮，机器甚至把它转写对了 — 而工具因为一个投递问题毁掉了结果。第二遍永远不如第一遍。凭记忆重新口述过一段话的人都知道，你不会复现它；你只会产出它一个更扁平的表亲。

在 Keebye 存在之前，我自己也在别的工具里这样丢过听写。这是这款应用围绕着解决的那些小型紧急状况之一。

口述出来的文字为什么会凭空消失？

这不是某家厂商的 bug。这是品类层面的设计决定，而值得理解这个品类为什么这么决定。

一款听写应用是一根管子，不是一个编辑器。语音从一端进去；文字从另一端出来，进到别人的窗口里 — 一个终端、一个 Slack 输入框、一份 Google Doc。它没有属于自己的文档，而这恰恰是这类工具隐形而快速的原因。但这意味着转写往往只在一个瞬间存在：那次插入。而插入是整条流水线里最脆弱的一步。它取决于投递那一毫秒是哪个窗口拥有焦点，取决于剪贴板没有被另一个应用抢跑，取决于辅助功能权限当时心情如何，取决于目标应用到底接不接受合成输入。任何一环失手，一根纯粹的管子背后就什么都没有。水已经泼在地上了。

工具们对保留副本一直很谨慎，也有一个原则性的理由：一份你口述过的所有内容的日志是敏感的。你的听写就是你的消息、你的提示词、你那些还没想清楚的决定。一个把它们存下来的厂商 — 尤其是存在云端附近 — 就制造了一份责任，而回避这份责任最简单的办法就是什么都不留。用户继承的，就是这份谨慎所变成的转瞬即逝：从厂商的角度看，最安全的听写是那条从未存在过的听写。

我理解这个逻辑。我只是认为它在为错误的一方做优化。保留本地历史记录的失败模式，是你自己磁盘上的一个文件。什么都不留的失败模式，是你的工作因为一个窗口失去焦点而蒸发。

Keebye 留下什么，留在哪里

所以 Keebye 保留一份历史记录，默认开启，而下面就是它确切的含义 — 不多，不少。

在历史记录启用的情况下，每一次完成的听写都会被写进你 Mac 上的一个本地 SQLite 数据库（rusqlite，WAL 模式，写给在意底层管道的人）。这个文件住在应用支持目录里 — com.keebye.app/keebye.db — 而它从不离开这台机器。没有同步，没有上传，也不挂在任何账户上。它就是一个文件，在你的磁盘上，归你所有。

恢复功能是围绕你实际丢失文字的两种方式设计的。常见的那种 — 插入刚刚失败，就在一秒之前 — 有最快的路径：托盘菜单里有一项 Copy Last Dictation。点它，你最近一次的听写就在剪贴板上了，粘到它本该去的地方，继续干活。更少见的那种 — “我周二口述过一个东西，现在想要回来” — 走 Dictation History…，一个带完整列表的窗口：可搜索，可逐条删除，也有一个想把石板擦干净时用的全部清除。

保留期是 30 天，自动执行。清理会在数据库打开时运行，并在每次插入之后再跑一遍，所以这个窗口确实是 30 天，而不是“大概 30 天，等我们哪天想起来”。而如果你想要过去那种转瞬即逝的行为 — 有些人确实应该要，我待会儿会说是谁 — 历史记录是一个设置项（history_enabled），关掉它就意味着什么都不会被写下来。

只有文本。绝不留音频。

我最在意的部分，是这份历史记录不是什么。它只有文本。Keebye 的历史记录表结构里没有音频列 — 不是一个默认关闭的音频保留设置，而是根本没有那一列。录音本身从不被存储。这是结构性的、有意为之的：一句“回复 Andrei，说迁移要推迟一周”的转写已经够敏感了；而你说这句话时的声音，带着时间戳，是另一个量级的产物，我不希望这款应用具备积攒它的能力。

还有一个细微之处，其分量大于它的字数：如果你往一个安全输入框 — 密码类的输入框 — 里口述，历史记录不会记录它。唯一一个连文字痕迹都不该留的地方，就是我们唯一不留痕迹的地方。

这和这款应用其余部分的姿态是一致的 — 语音转文字在端侧运行，我们在用你自己的语言口述的语境里写过这件事 — 但历史记录是这个姿态受到检验的地方，因为历史记录是 Keebye 唯一会持久保存你话语的地方。本地、仅含文本、自动删除，感觉才是那个配得上“默认开启”的形状。

诚实的限制

诚实环节，一如既往。

你没法回听。 仅含文本是把双刃剑。如果转写错了 — 模型听错了一个名字，把一个数字搅乱了 — 历史记录会忠实地保留那段错误的文字，而能了结这场争议的音频，按设计已经不在了。对大多数恢复场景来说这无所谓；失败的是插入，不是转写。但如果你想把听写历史当作语音备忘录的存档，它有意不是那个东西。

三十天就是三十天。 历史记录是一张安全网，不是一份档案。如果一段听写的意义超过一个月，那它的家是你把它口述进去的那份文档，而不是应用的数据库。清理不会问你。

只在本地就是只在本地。 你的历史记录不会跟着你跨机器。你在台式机上做的听写，在笔记本上找不回来。我把这说成一个隐私特性，它也确实是一个 — 什么都不同步是因为什么都不传输 — 但我不会假装它同时不是一个限制。它两者都是。在你依赖它之前，你应该知道对你来说它是哪一个。

还有那个边界情况：如果你是那种威胁模型要求一点痕迹都不留的人，就把历史记录关掉。这是一个设置项，应用会完全尊重它。默认开启对大多数用户是正确的选择，他们更希望能把上周二那段话找回来；但它不该成为剩下那些人的陷阱。

工作不该有单点故障

这个功能存在的更深理由：我把一天当成并行的任务线来跑 — 有些窗口里是智能体在构建，另一些窗口里是人在等 — 而语音是喂养它们全部的那条通道。那套工作流正是用声音驱动 Claude Code的全部前提。一条偶尔会毁掉自己载荷的通道，不是一条你能拿来搭建工作日的通道。开发者期待有恢复路径 — 撤销、日志、reflog、废纸篓 — 然而当插入失败时，许多听写流程没有提供任何对等的东西。

如果你正在这个品类里权衡工具，我们的比较对别家出色的地方同样诚实：Keebye vs Superwhisper 和 Keebye vs Wispr Flow。另外，文字消失还有一个孪生抱怨 — 听写的第一个词在麦克风醒来之前被吃掉 — 我们写在了听写应用为什么会吃掉你的第一个词里。

Keebye 处于 macOS 早期访问阶段。在下方开始你的免费试用，口述一段话，故意错开目标窗口，然后用 Copy Last Dictation 把文字找回来。焦点错了仍然要付一步恢复的代价；但它不必再让你付上那个想法。