用户感受到的「适配」是什么
场景适配不是一个用户能看到的开关，用户感知到的是它的结果。
最常见的感知有两种。一种是在聊天软件里打字，候选栏里的语气词、表情相关词排得比较靠前。另一种是在代码编辑器里打字，英文词、符号的优先级更高，中文候选往后排。同一个拼音输入，不同应用里的候选顺序不一样，这就是场景适配在起作用。
还有一种感知不太容易注意到：同一个应用里，一天中不同时段输入同样的拼音，候选顺序可能略有差异。这跟场景适配本身无关，是语言模型在持续学习用户的输入习惯。两者叠加，用户感受到「输入法越来越懂我」，但很难区分哪部分来自场景适配，哪部分来自其他机制。
把场景适配单独拎出来看，它的作用范围其实有限：只调整词库权重，不改变候选生成的整体逻辑。它让某些词在特定场景下更容易排到前面，不是决定性的。搜狗输入法的场景适配是本地行为，不需要联网也能工作，云端只是补充一部分场景词表。
输入法怎么判断自己在哪个应用里
判断应用类型的依据来自操作系统接口。输入法能拿到的主要是前台窗口的进程信息。
Windows 上，输入法通过文本服务框架（TSF）或更老的输入法管理器（IMM）接口获取前台窗口的进程 ID，再根据进程 ID 找到可执行文件名。比如 WeChat.exe 归为即时通讯，Code.exe 归为代码编辑器，chrome.exe 归为浏览器。
进程名之外，输入法还能拿到窗口类名和窗口标题，这两项在部分情况下能进一步细分。但细分能力有限，多数实现主要靠进程名。
判断是在光标进入编辑框时触发的。用户从一个应用切到另一个应用，如果焦点落在可编辑控件上，输入法重新识别前台进程并更新场景分类。同一个应用内切换窗口，通常不重新分类，因为进程没变。
这套判断依赖应用是否走系统接口。绕过 TSF 和 IMM 的应用，比如全屏游戏和部分自绘 UI 工具，输入法拿不到进程信息，场景分类只能退回默认。这类应用里的候选排序跟其他应用不同，原因就在这里。
场景分类有多细
场景分类的颗粒度比用户想象的要粗。它不是按具体应用分，而是按应用类型分几个大类。
常见的大类包括：即时通讯、浏览器、代码编辑器、文档编辑、表格处理、邮件客户端、命令行工具、终端模拟器。这些大类的划分依据是输入内容的典型特征，不是应用本身的功能。
同一个大类下的应用共享一套场景权重。WeChat.exe 和 DingTalk.exe 都归为即时通讯，共享同一套加权规则。即使两个应用的聊天风格差异很大，输入法也不会为它们分别建模。
分类之外还有一层「未识别」。不在预置大类里的应用，走默认权重，跟没有任何场景适配的效果接近。这解释了为什么一些小众应用里，输入法的表现跟平时不一样——它们没有被归入任何大类，走了默认逻辑。
| 应用类型 | 抬高的词库 | 压低的词库 | 典型表现 |
|---|---|---|---|
| 即时通讯 | 语气词、表情相关词、网络用语 | 专业术语、代码词 | 日常聊天候选顺序更贴口语 |
| 代码编辑器 | 英文标识符、编程词汇、符号 | 语气词、口语词 | 变量名输入更方便 |
| 文档编辑 | 书面语词、成语、正式表达 | 口语词、网络用语 | 长句候选质量更好 |
| 表格处理 | 数字、日期、单位符号 | 长词、句子级候选 | 数值输入更顺手 |
| 浏览器 | 网址相关词、搜索热词 | 长句候选 | 地址栏输入更贴近搜索意图 |
| 未识别应用 | 无 | 无 | 走通用词频 |
切换在什么时候发生
切换不是在应用启动时发生的，是在光标进入编辑框时发生的。用户点进一个聊天输入框，输入法识别到前台进程是即时通讯类应用，场景权重生效。用户切到代码编辑器，焦点进入编辑区，输入法重新识别并切换权重。
切换本身耗时很短，用户感知不到。切换后候选生成用的是新的权重，之前已经生成的候选不受影响。用户切换应用后再输入一个新拼音，候选就按新权重排了。
切换有一个容易忽略的边界：同一个应用里，不同输入位置的场景分类可能不同。比如浏览器里，地址栏和网页搜索框都是浏览器进程，但输入内容特征完全不同。当前多数实现按进程分类，不做这种细分，所以地址栏和搜索框走同一套场景权重。
一个可以自己验证的观察：在聊天软件里输入某个拼音，记下候选顺序。切到浏览器地址栏输入同样的拼音，比较顺序。两者如果有差异，说明场景适配生效了。如果完全一样，可能是这个拼音的候选在两个场景下都不受权重影响，也可能是场景识别没有生效。
实测：跨场景候选差异
下面的数据为人工构造，测试环境为 Windows 11 24H2、16.8 正式版、默认词库、关闭云输入。测试方式是准备三组拼音样本，每组 30 条，分别在即时通讯、代码编辑器、浏览器三类应用里输入，记录目标词的候选位次。样本量小，数据仅供说明差异量级。
| 词类 | 即时通讯位次 | 代码编辑器位次 | 浏览器位次 |
|---|---|---|---|
| 口语词（如「好的」） | 第 1 位 | 第 3 位 | 第 2 位 |
英文词（如 key） |
第 3 位 | 第 1 位 | 第 2 位 |
| 专业术语（如「迭代」） | 第 2 位 | 第 2 位 | 第 3 位 |
用户能调的三个相关设置
场景适配没有直接的开关，但有几个相关设置可以间接影响它的效果。
场景词库开关。部分版本在设置里有场景词库相关的选项。关闭后所有应用退回同一套词频排序，跨软件的候选顺序差异明显缩小。代价是失去场景适配带来的效率提升。适合对顺序一致性有要求的用户。
应用名单。部分版本允许用户为特定应用单独指定输入偏好。这类设置的颗粒度跟版本相关，不一定所有版本都有。有的话，可以把某个应用固定到某种输入模式，让它的表现不随场景分类变化。
用户词库。用户在某应用里反复选过的词，会进入用户词库并带上场景标记。下次在同一应用里输入同样的拼音，这些词排位更靠前。这是适配的本地学习层，跟云端无关，关闭云同步后仍然有效。
三个设置里，实际最常用的是用户词库。它不需要用户主动配置，选词一次就自动生效。场景词库开关更激进，影响全站表现，改动前要清楚代价。
场景适配做不到什么
不能区分同一应用里的不同用途。浏览器里的地址栏、搜索框、网页表单都归为浏览器，走同一套权重。用户在这些位置输入的内容差异很大，但输入法无法区分。这是进程级分类的固有局限。
不能为每个应用单独建模。场景分类是大类，不是应用级。两个同属即时通讯的应用共享权重，即使一个偏正式、一个偏口语，输入法也不会分别处理。细分到应用级需要更复杂的配置，多数版本没有做。
不能识别绕过系统接口的应用。全屏游戏、自绘 UI 工具不走 TSF 或 IMM，输入法拿不到进程信息，场景分类退回默认。这类应用里的表现跟通用状态一致，没有适配。
不能替代用户词库的作用。场景适配调整的是大类权重，用户词库记录的是具体选词。两者是不同层级的机制。场景适配让某些词更容易出现，用户词库让某个词排得更前。前者是背景，后者是个人偏好。
不能保证顺序一致。即使关闭场景词库，候选顺序也不完全一致。不同应用的接口支持程度、光标信息、上下文判断有差异，这些因素跟场景适配无关，但会影响顺序。想让所有应用的候选完全一致，目前做不到。
使用建议
跨类型软件混用时，观察一下差异。如果你同时用聊天、写代码、写文档三类应用，注意一下候选顺序在不同应用里是否不同。有明显差异说明场景适配生效了；没有差异可能是场景识别没覆盖到你用的应用。
对顺序一致性有要求，关闭场景词库。写代码时经常被场景权重干扰，或者希望所有应用里都是同一套候选顺序，关闭场景词库是直接的方式。代价是失去场景适配的便利，需要靠其他设置补充。
在特定应用里多选几次词。如果某个应用里经常用同一个词，手动选几次，用户词库会记住。下次在同一应用里输入同样的拼音，这个词排位更靠前。这是场景适配最实在的应用方式。
不要指望场景识别覆盖所有应用。小众应用、自绘 UI 工具、全屏游戏通常不在预置分类里。这些应用里的输入表现跟通用状态一致。想改善只有两个办法：靠用户词库积累，或者改用支持这些应用的输入法方案。
场景适配是输入法的一个辅助层。它不改变核心输入流程，只是在不同场景下调整权重。理解它的作用范围和局限，就能判断哪些体验差异来自它、哪些来自其他机制，也能决定是不是要把它关掉。
关于场景自动适配的常见问题
下面 5 个问题是读者反馈中最常被问到的
场景自动适配和跨软件候选顺序差异是一回事吗？
不是。场景适配是输入法主动做的调整——识别应用类型后抬高或压低某些词库的权重。候选顺序差异是结果——适配效果加上上下文信息、接口支持程度共同作用后的表现。场景适配只是顺序差异的一个来源。
怎么知道输入法当前识别成了什么场景？
多数版本没有直接显示当前场景分类。用户能看到的间接信号是候选顺序和词条构成。如果聊天软件里输入某个拼音，候选里出现较多语气词和表情相关词，说明场景分类生效了；如果所有软件里候选顺序完全一样，说明场景分类可能没生效。
场景分类可以手动指定吗？
不能直接指定。输入法按进程名自动分类，用户改不了某个应用归到哪一类。可以做的是关闭场景词库开关，让所有应用回到同一套词频排序，或者按应用调整其他设置来间接影响输入体验。
为什么在同一个应用里场景适配时有时无？
场景分类依据的是前台窗口的进程名，同一进程内不同窗口通常不会重新分类。用户感受到的「时有时无」，更可能是上下文判断的差异。同一个应用里不同位置输入的上下文不一样，语言模型给出的排序不同。
关闭场景词库后会怎样？
所有应用退回同一套词频排序。跨软件的顺序差异会明显缩小，但不会完全消失，因为接口支持和上下文信息的差异还在。代价是失去场景适配带来的效率提升——写代码时不再优先给英文词，聊天时不再优先给语气词。