把我说的原样给我：不做 AI 改写的听写

关于 AI 增强的听写，有一种抱怨在你亲身经历之前听起来像自相矛盾：转写本身没问题 — 毁掉它的是转写之后发生的事。你说了一件事，工具交付了一件打磨过的、自信的、稍微不一样的事。一个限定词被悄悄丢掉。一处保留被抹平。一句话被重组成你绝不会那么说的样子。而在这个模式最糟的版本里 — 那种会让人当场卸载工具的版本 — 意思反了过来。“别在测试通过前部署”从另一头出来时，变成了一条关于部署的指令，少了那个别字。

对随手的听写来说这只是恼人。对我实际使用听写的方式来说 — 给 Claude Code 喂提示词，也就是用声音驱动 Claude Code里的那套工作流 — 这是毒药。编程智能体把你的话当作规格说明。它并不知道你的听写工具把你转述了一遍。如果那个让指令变安全的限定词，在你的嘴巴和终端之间被抹平了，智能体会兴高采烈地执行抹平后的版本。精确性正是一条提示词的全部意义所在，而一层 AI 改写就是一台专门用来清除精确性、同时让结果看起来更加深思熟虑的机器。

AI 听写工具为什么要改写你说过的话？

品类层面的答案不是有谁存心要扭曲你的语音。而是“把这段转写清理一下”确实是个诱人的功能，而实现它最显然的办法，就是把原始转写丢进一个语言模型。

原始语音是杂乱的 — 语气词、说到一半重来、重复的词、缺失的标点。让一个 LLM 去把它收拾干净，产出的东西很漂亮。麻烦在于，语言模型并不像一个删掉“um”的人类文字编辑那样编辑。它是重新生成。输出是一段新的文本，是模型认为的、你那段输入的一个好版本，而“好”正是你的意图漏出去的地方。朝着有用和流畅训练出来的模型是有主张的：保留语看起来像噪声，限定词看起来像杂物，一个笨拙但精确的措辞看起来像是有待改进的东西。大多数时候这种改写无伤大雅。但它是概率性的，而你从输出上看不出哪些句子是被转写的、哪些是被写出来的。打磨是均匀的；忠实度不是。

这就是 LLM 润色流水线的深层问题：它们失败得既安静又自信。一个听错你的语音识别器，通常会产出明显不对的东西。一个背叛你的改写层，产出的是明显对的东西 — 语法通顺、合情合理、还穿着你的语气 — 而这正是那句反过来的“别在测试通过前部署”会被发出去、而不是被拦住的原因。

默认字面

Keebye 的立场很简单：语音转文字模型听到了什么，落到你光标处的就是什么。默认情况下，转写和你的终端之间，没有语言模型坐在那里编写一个更好的你 — 默认的润色环节是一小串确定性规则，仅此而已。

这是一个刻意的押注，它来自氛围编程这个使用场景。当你的听写是编程智能体的控制通道时，工具的工作是运输，不是创作。你是作者；智能体是读者；听写这一层不该有任何主张。那套工作流 — 把整条提示词说出来而不是打出来 — 在给 AI 提示词用的语音听写里有完整描述。

Keebye 里确实有一个 LLM 润色 — 我马上会讲到 — 但它需要主动开启，完全在你的机器上运行，并且在一道防护之下工作，那道防护的设计目标是拒绝常见形式的漂移、失控扩写和重复。如果输出没通过那道检查，Keebye 就回退到规则。默认的仍然是规则。

那清理到底做了什么？

字面不等于必须原始。Keebye 提供一道可选的清理流程 — 增强，默认开启，且可按应用覆盖 — 但它是基于规则的，不是模型，它做的全部事情一段话就写得完：

它剥掉独立出现的语气词（um、uh、erm、you know）。它合并紧邻的重复词 — “the the”变成“the”。它压缩空白。它把首字母大写，如果你结尾没有句号，它补一个。这就是全部清单。这些规则是确定性的、范围很窄的；它们不会刻意重排从句、删除否定或替换同义词。

在清理运行之前，你的词典替换会先生效 — 由你定义的替换项，针对语音模型总是弄错的术语和专有名词，让“pnpm”和你的模块名以你代码库里的拼法到达。

而如果连基于规则的这一遍都比你想要的干预更多，那就把增强关掉，Keebye 会插入语音模型的原始转写：语气词、重复，一个不落。在某些场景下 — 引述别人的话、往一个末尾句号会坏事的输入框里口述 — 原始转写是更好的选择，按应用覆盖让你可以这么选。

需要主动开启的润色，以及围着它的那道忠实度防护

现在说我答应过要讲的那个 LLM。对于确实想要更聪明清理的人，Keebye 提供一个可选的润色模式（把 polish_mode 设为 local_llm）：一个小的 Qwen3 模型，通过 llama.cpp 在端侧运行，由 Metal 加速，什么都不往外发。它的指令是润色的窄版本 — 修正标点和大小写，去掉语气词，保留用户的原话、语言和意思，逐字保留代码和文件名。生成是确定性的（贪心采样，同样的输入 → 同样的输出）并有上限；如果模型卡过两秒的截止时间，它的输出会被丢弃。

但指令只是期望，而这篇文章存在的理由就是期望不等于保证。所以每一个 LLM 润色过的结果，在能碰到你的光标之前，都要经过一道忠实度防护。输出必须保留原始转写至少 50% 的 token。它不能膨胀 — 任何超过原长度大约两倍（外加四个 token）的结果都会失败。失控的重复会被检测出来。如果润色结果没通过其中一项检查，Keebye 会把它丢掉，改用基于规则的清理。

那道防护能在模型的输出替换掉规则清理后的转写之前，抓住严重的 token 丢失、失控扩写和重复。它是一种启发式判断，不是语义证明：一次简短的改写，或者一处被改动的否定，仍然可能通过它的阈值。如果某个限定词经不起漂移，那就把 AI 润色关掉，并在发送前审阅插入的文字。

诚实说说限制

字面就是字面。如果你说得东拉西扯，落地的就是东拉西扯 — 即便是需要主动开启的润色，它的指令和防护也都朝着清理而不是创作，所以 Keebye 不会把一段绕来绕去的想法变成一条利落的指令。把话说清楚这项修炼，仍然归你自己。

基于规则的清理是刻意做得很笨的。它会删掉“um”；它不会修你的语法，不会重组一个长句，也不会注意到你自相矛盾。任何更聪明的东西，都会把这套设计存在的意义 — 避免主观判断 — 重新引回来。

还有，忠实度防的是改写，不是听错。如果语音模型把 “cache” 听成 “cash”，那个错误会被忠实地保留下来 — 防护完全不知道你本来想说什么，只知道被转写出来的是什么。字面听写把信任边界挪到了 STT 模型上；它并没有消除这条边界。（相关：如果你的问题是模型整段用错了语言，那是另一种失败，有另一种修法 — 锁定你的听写语言。）

最后是品类层面的定位：AI 润色不是骗局，确实有很多用户就是更喜欢读起来比自己说得更顺的输出。如果那就是你，别的工具在这方面做得很投入，我们的比较也诚实地这么说了 — Keebye vs Wispr Flow 和 Keebye vs Superwhisper 都有一节真诚的“另一款工具更合适的时候”。

运输，不是创作

Keebye 提供的这笔交易刻意做得很窄：你说话，一段轻度清理过的转写落在你光标所在的地方。当那些词是要被一个会照字面执行的智能体收到的提示词时，窄就是一个功能。一个听写工具能对开发者做的最昂贵的事，不是一个错别字。而是一句你从未说过的、通顺的句子。

Keebye 处于 macOS 早期访问阶段。在下方开始你的免费试用，口述“别在测试通过前部署”，然后检查这条约束有没有原样挺过清理。这个测试就是整个产品。