Mac 上下文感知听写：应用如何知道你在哪里输入

假设你正在 Mail 里写一封回信，写到一半。按住 ⌥Space，说上十秒，松手。整理好的句子直接落进邮件正文，而不是某个单独的编辑器，也不是等着你手动搬过去的剪贴板。

你从没说过这段文字该去哪里。

多数语音工具处理目的地的方式正好相反。开口之前，它们先递给你一个选择器：原始模式、加标点模式、提示词模式、聊天风格、邮件风格。由你宣告目的地，工具则相信你的宣告。TalkTalkType 没有这样的选择器。它反过来，自己去读目的地。它看你当时所在的应用、光标下的那个输入栏，用一张固定的映射表把两者分类，然后在你亲自触发的语音润色环节里调整结果。

这篇文章要讲的，是这套读取如何工作、它改变了什么，以及它在哪里停下。

目的地在你按键的那一刻就被捕获

录音从按键那一刻开始。就在这一瞬间，Mac 应用把聚焦的应用捕获为一个送达目标：进程 ID、Bundle 标识符，以及应用的本地化名称。结果就绪后，送达会把文字原样送回那个应用。

送达有两条路径。Paste 模式下，应用通过 macOS 辅助功能 API，把文字插入你当时所在的输入栏，并先保存剪贴板、插入后再还原。Copy 模式下，结果只是留在剪贴板上，等你手动粘贴。无论哪种，目标都是你按键时正在用的那个应用，在你开口之前就已确定。

“按键时捕获”这个细节，正是整件事显得自动的原因。如果应用等到文字就绪才去找目标，你也许已经切换了窗口，结果就会落到错误的地方。现在则是：你在哪个输入栏开始，就在哪个输入栏结束。这套送达的机制，以及背后的 macOS 权限，在 Mac 上可在任意应用中使用的听写 里有详细说明。

分类是查表，不是猜测

目标应用确定后，分类器要判断你正面对的是哪一类输入面。它不会去问语言模型。

第一步，用一张固定的前缀映射表，把 Bundle 标识符归入应用族。Terminal、iTerm2、Warp、WezTerm、kitty 归为终端；VS Code、Xcode、JetBrains 系列、Sublime Text、Zed 归为代码编辑器；Mail 和 Outlook 归为邮件；Slack、Discord、LINE、Telegram 归为聊天；TextEdit、Notes、Pages、Word、Obsidian 归为文档；Safari、Chrome、Firefox、Arc 归为浏览器。

第二步，用输入栏的辅助功能 role 和 subrole 来细化输入面。搜索栏（AXSearchField）变成搜索查询。在 Mail 里，文本区域变成邮件正文，文本框变成主题。在聊天应用里，文本区域或文本框变成聊天消息。在文档应用里，文本区域变成文档，文本框变成短输入栏。在代码编辑器里，文本区域变成代码编辑器输入面。

这里没有推断，只有一张表和几次 role 检查。好处是：每一次分类都带一条可审计的理由字符串。Mail 正文会被分类为 app_family:email role:AXTextArea subrole:-。你能确切读到应用为何得出这个结论，因为结论来自两个可见的事实，而不是某个模型的置信度。

当查表失败时，它会朝安全的一侧失败。Bundle 标识符无法识别的应用，会被分类为 unknown，理由是 unknown_app。已知应用但 role 无法识别的输入栏，同样是 unknown，理由是 unknown_role。unknown 意味着应用不做任何特殊处理。这是安全的默认值：当 TalkTalkType 说不清一个输入栏是什么时，它宁可平实地对待你的话，也不去猜错。

不同输入面会改变什么

输入面的分类，决定了润色环节可以朝什么去调整。对应关系如下。

有两行值得单独说明。浏览器那一行永远是 unknown，这是刻意的。网页想画什么输入栏就画什么，而让原生 Mail 或 Slack 输入栏变得可读的那些结构信号，在浏览器标签页里并不成立，所以 TalkTalkType 不会假装去分类网页输入栏，而是放任不管。

代码编辑器和终端那两行，对技术词元有一条具体保证。在这些输入面上，说出口的文件名、路径或斜杠命令会被保留为普通文本，绝不会被当作某种确实存在、能够解析或将会执行的东西。对终端口述一条命令，得到的就是那串字面字符串，仅此而已。

调整是润色环节，不是静默改写

这是最容易被夸大的部分，所以边界很重要。

整理后的结果，首先以草稿形式出现在菜单栏 HUD 上。这第一次粘贴就是忠实的 Clean 输出。Clean 会保留你说的每一个词，按你说的顺序，保留你意图中的语气和简洁。它只去掉毫不含糊的迟疑填充词，把所有内容并成一行，绝不改写、扩写或润色。Raw 模式则完全跳过整理。你最先看到的，就是你说过的那些话。

感知上下文的调整发生在之后，也就是 Voice Patch 流程里。从草稿出发，你可以在文字插入之前用语音下达一次润色，也可以原样提交、复制丢弃。当某次润色要求应用按输入面调整时，给模型的指令字面上就是“仅按所提供的确定性桌面应用与输入栏分类进行调整”。同一个流程会保留含义和每一条受保护的事实，只做必要的最小改动，并把收到的所有屏幕信息当作数据，绝不当作指令。

也就是说，应用不会一看到 Mail，就把你的第一次粘贴悄悄改写成“邮件风”。它先给你一份忠实的草稿，而调整是你用语音主动要求的，并且以它已经检测到的输入面为依据。

这套设计回答的问题是：为什么别的工具还在递给你一个选择器。TalkTalkType 的设置里任何地方都没有输出模式的选择。唯一的开关是 Clean 开或关——忠实的轻度整理，或者什么都不做。一切跟目的地相关的处理，都来自读取输入栏，而不是来自一个由你维护的模式。这才是值得拿来评判它的强项：开口之前少设置一样东西，而且没有任何东西会被你设置错。

你的上下文要么越过同意边界，要么根本不发出

读取输入栏会引出一个显而易见的问题：屏幕上其他一切信息怎么办？

应用能够组装的上下文快照，包含应用身份、窗口标题、输入栏结构（role、subrole、是否多行、是否为安全密码栏）、光标紧前与紧后的文本、当前选区、一张可选的活动窗口截图、捕获时间戳，以及权限状态。涉及的面很广，所以边界由服务器强制，而不是交给客户端的自觉。

最重要的有两条。第一，输入栏的标签和占位符绝不发给 AI 提供方。这些字符串是别的应用提供的任意文本，而分类只需要结构属性，所以服务器会直接拒绝任何含有标签或占位符的请求。第二，每一条上下文通道（文本上下文、截图、偏好记忆）都处在一个由服务器拥有的功能开关之后。三者在生产环境默认开启，并可按部署覆盖。如果某条通道对某个请求未启用，服务器会拒绝该上下文，而不是悄悄剥离。被拒绝的请求会告诉客户端：它的同意状态已经过期——而悄悄剥离会把这一点藏起来。

完整的数据台账，说明 Mac、服务方和提供方各自保留什么，在 Mac 上的隐私听写 里。

偏好只在这台 Mac 上、按应用学习

上下文的最后一块是偏好记忆，它留在这台 Mac 上。

偏好存放在一个本地 SQLite 数据库里，路径是 ~/Library/Application Support/TalkTalkType/PreferenceMemory/preferences.sqlite，没有云端同步。存储的键被刻意收得很窄：回复语气（简洁、中性、正式、友好）、是否使用牛津逗号、0 到 2 的详细程度，以及一份偏好术语列表。每条偏好的作用域是所有应用，或按 Bundle 标识符指定的某一个应用，而单应用偏好优先于全局偏好。

这里的一切，在被明确批准并启用之前都不会被使用。只有抽象后的值才会随润色请求一起发出；原始语音、草稿文本、被否决的候选，绝不会写入这个存储。如果你在某个应用里反复纠正它，它可能会提出一条偏好建议，但建议在你批准之前不会起任何作用。

它做不到什么

诚实的局限是设计的一部分，不是脚注。

浏览器会被分类为 unknown，所以网页表单没有输入面调整可言；应用不信任网页输入栏的结构。调整发生在语音润色流程中，而不是作为对第一次粘贴的静默改写——第一次粘贴按设计保持忠实。调整绝不会把你的话改写没了：含义和受保护的事实都会保留，改动只是满足指令所需的最小幅度。

平台仅限 Mac，并要求 macOS 26（Tahoe）或更高版本。转写在云端运行，因此处理期间音频会离开 Mac；服务方默认不存储音频或转写文本。识别语言为日语和英语。“复制”“打开 Safari”这类语音命令是同一思路的另一种表达：它们会作为针对所捕获应用的 Mac 操作来执行，而不是被当作文字输入。

放回你自己的工作流里判断

这套设计的理由是：目的地是一个应用能读取的事实，而不是一项需要你去维护的设置。模式选择器把这份工作外包给了你，而选择器是这样一种承诺——你一旦忘了切换，工具就可以违背它。一张基于 Bundle 标识符和输入栏 role 的映射表更枯燥，也更诚实：它精确地认识一小撮应用，并在不认识时坦然承认。

TalkTalkType 计量用量的单位是每周听写次数加一个每周语音时长池，而不是字数。截至 2026 年 7 月 30 日，各方案为：Free 0 美元（每周 30 次、15 分钟），Plus 1 美元（80 次、30 分钟），Pro 7 美元（500 次、250 分钟，单次可达 2 分钟），Max 18 美元（1,200 次、600 分钟）。当前数字与方案供应情况见价格页。

你可以下载 TalkTalkType，在自己真正使用的输入栏上试试这套检测。在 Mail 里、在终端里、在网页表单里分别按住热键，看结果落到哪里，又对什么刻意不碰。应用早已知道你在哪里输入。真正有意思的，是当它不知道时，它会多么坦率地告诉你。