macOS 键盘甚至会区分您骂的“对象是谁”

一位昵称为 Helgesver（헬게스버）的研究者在 macOS 15.6 环境下，利用 AI 智能体（Claude）的 agent-desktop 功能，尝试将 “well fuck this shit, damn it.” 插入文本编辑器（TextEdit），并通过逐键输入方式进行测试。然而，系统内部的 VulgarWordUsage.db 文件并未新增任何行，文件的最后修改时间也未发生变化 ¹。这并非因为 macOS 无条件地屏蔽粗俗用语。该系统所记录的，并不是用户“说出”脏话这一事件本身，而是当键盘试图将脏话替换为其他词语（例如 “ducking”）时，用户拒绝该替换并坚持使用原词的那个瞬间 ¹。

macOS 并不将词语本身列入禁用名单，而是根据应用（app）和接收者（recipient）等上下文，动态调节自动更正的介入程度。在与朋友的即时通讯中自然被接受的表达，在发送给上司的电子邮件中则可能成为被修正的对象。本文将详细探讨这种差异是如何产生的，以及系统依据何种标准来学习用户的意图。

调节“推荐”而非禁止输入的词典

要理解 macOS 的键盘自动更正逻辑，必须明确区分系统用于词语分类的词典（Lexicon）与随用户使用习惯累积形成的学习数据库。Helgesver 通过分析私有系统框架 Lexicon.framework，提取了 Apple 在内部赋予词语的标记（flags）。研究结果显示，在美国英语（en_US）词典的 199,019 个词条中，有 4,271 个被标记为与粗俗用语相关 ¹。由于 Apple 未在官方文档中明确说明此分类，这些名称是根据词语的实际使用上下文以及系统代码中相邻的枚举类型反推得出的 ¹。该分类大致分为三个层级。

1. vulgar（脏话及性俚语）：包含 “fuck”、“shit”、“crap” 等 1,050 个词语。这里聚集了最直接的脏话 ¹。
2. offensive（群体蔑称）：包含 663 个针对特定种族或社会群体的侮辱性表达，如 “asshole” 或 “Oriental” ¹。
3. sensitive（敏感表达）：包含 “damn”、“abortion”、“gun”、“suicide” 等 2,558 个在日常对话中宜避免主动推荐的词语，涉及药物、政治、疾病及身体功能等领域 ¹。

值得注意的是，这些标记并不用于强制阻断（审查）用户的输入。当用户直接键入某个词语时，系统会予以接受。研究者指出，这一分类体系似乎被用于抑制键盘的 QuickType（预测输入） 条主动建议这些词语 ¹。换言之，系统管理的方式是：除非用户先主动输入以“唤起”该词，否则键盘不会主动提议脏话。此外，还有 11 个按主题划分的位掩码（bitmask）（如排泄、政治、宗教等）存在，用以进一步细化词语的属性 ¹。

同为 “fuck”，上下文不同则记为不同条目

如果说词典标记负责“抑制键盘的主动推荐”，那么管理用户刻意使用粗俗用语时的自动更正，则依赖另一个独立的本地数据库。~/Library/Keyboard/VulgarWordUsage.db 正是这样一个文件，它学习用户在何时、何地、何种上下文中坚持使用了粗俗用语 ¹。

该数据库的记录方式并非仅仅存储“使用了脏话”这一事实。vword_usage 表的主键索引由以下四个要素的组合构成 ¹。

• 应用标识符：区分程序，如 Messages（信息）应用、Mail（邮件）应用等。
• 接收者标识符：记录对话对象（对方）的唯一标识符。
• 粗俗用语本身：存储所用词语的种类。
• 发音表记形式：词语的读音形式（在日语等重视读音的语言中尤为重要）。

得益于这种（应用、接收者、词语、发音）的四元键结构，即使输入相同的 “fuck”，在 Messages 应用中发送给特定“朋友”与在 Mail 应用中发送给“上司”的情况，在系统内部也会被区分为不同的条目 ¹。

系统内部存在 set_current_app_id、set_current_recipient_ids 等函数，用于识别用户当前的输入上下文 ¹。在评估自动更正候选项的阶段，系统通过 every_vulgar_word_is_allowlisted 函数判断在该（应用+接收者）上下文中是否允许使用粗俗用语 ¹。一旦某个上下文被学习为“允许”，系统便不会强制修改用户的输入，也不会优先提供像 “ducking” 这样委婉的替代表达 ¹。

为什么输入了脏话却未被学习？

用户通常认为，只要输入脏话，系统就会将其学习记录下来。但 Helgesver 的实验结果（拼写正确的句子输入后数据库未发生变化）清晰地表明，记录的触发条件并非“词语输入”本身 ¹。

数据库的实际记录仅在以下两个条件同时满足时才会发生 ¹。

1. 自动更正的介入：系统（AppleSpell）提出了将用户键入的脏话替换为 “ducking” 等替代表达的修改建议。
2. 用户的拒绝：用户无视该建议，坚持保留原始的脏话。

实验中输入的 “well fuck this shit, damn it.” 所有词语拼写均正确。由于拼写无误，系统没有理由提出修改建议（拼写检查或自动补全建议），因此也就没有可供用户拒绝的建议产生 ¹。既然没有建议，increment_usage_count 函数便未被调用，数据库也未发生任何变化 ¹。

换言之，macOS 只有在用户“克服自动更正的干预并坚守脏话”时，才会学习“该用户在该上下文（例如与朋友的聊天）中坚持使用此词”。Apple 曾在 2023 年 6 月的 WWDC 上宣布，iOS 17 的自动更正计划将学习用户最常用的词语（包括脏话）（来源：TechCrunch）²。尽管来源未明确说明 macOS 的 VulgarWordUsage.db（按应用和接收者分离历史记录的结构）与 iOS 17 特性之间的直接先后关系，但两者都共享“尊重用户坚持使用的词语”这一相同方向。

可能悄然失效的功能

这种精密的学习结构并非在所有 Mac 上都始终有效。在 macOS 环境中，该功能可能会悄然失效。

最常见的原因是数据库文件缺失。应当存储 VulgarWordUsage.db 的 ~/Library/Keyboard 文件夹在某些 macOS 安装环境中可能未被默认创建 ¹。SQLite 数据库引擎在缺少数据库文件时会尝试新建，但如果上级文件夹不存在，创建便会失败 ¹。此时，系统会在内部记录 no such file or directory 错误，但不会向用户弹出专门的错误提示窗，而是禁用该功能并继续正常运行 ¹。

因此，如果用户使用脏话时，键盘固执地建议其他词语，或者无论上下文如何都总是进行修改，其原因可能是由于文件夹缺失导致的数据库创建失败。要解决此问题，用户需手动创建 ~/Library/Keyboard 文件夹，并重启系统自动更正服务（AppleSpell）¹。

macOS 之所以针对相同的脏话根据接收者和应用做出不同处理，是因为词典标记控制的推荐抑制，与按（应用、接收者）单位分离的用户拒绝历史共同作用的结果。然而，该判断标准仅依赖用户的“拒绝修改”行为，且需注意：若数据库创建条件未满足，则可能无法实现上下文感知。这一系统更准确地说，是一个致力于“抑制符合上下文的自动补全”而非“审查”的精密个性化工具。