❓ 常见问题¶
先解决问题，再解释原理。
本页收集万象用户最容易遇到的安装、更新、配置、词库、辅助码、英文混输与 Lua 功能问题。问题选题会参考 Rime 社区中的高频讨论，但答案统一以万象当前的 Schema、Lua 与项目文档实现为准，不会直接套用其他方案的配置。
FAQ 使用原则
先确认版本，再确认配置来源，最后重新部署。
万象的大量能力并不是单个 YAML 字段独立完成的，而是 Schema、挂接方案、词库、Lua 与 Rime 编译结果共同工作。遇到问题时，不建议先删除用户词库或大范围改配置。
安装、更新与部署¶
Q：第一次用万象，Base、Pro、Lite、Pure 应该怎么选？¶
大多数用户先从 Base 开始。
- Base：适合全拼、常规双拼，以及希望保留自动调频习惯的用户,词库带声调还能通过声调筛选，也能用反查数据进行lookup辅筛。
- Pro：面向双拼 + 专属辅助码用户，词库本身携带辅助码信息，更强调精确筛选和可控造词，万象全功能安排。
- Lite：在base的基础上简化词库声调去掉部分lua，主要面向不常用声调用户以及可以作为前端OEM首选。
- Pure：适合低版本环境、不能正常使用 Lua，或者只需要基础输入能力的场景。
如果你只是想“先稳定用起来”，选 Base；如果你明确知道自己需要哪一种辅助码，再选对应的 Pro 分包。
Pro 不是“Base 的绝对升级版”，而是不同输入哲学。
相关文档：方案介绍与版本对比
Q：万象更新时，怎样避免自己的配置被覆盖？¶
不要长期直接改仓库自带的 *.schema.yaml、default.yaml。个人配置尽量写进对应的 *.custom.yaml。
例如修改主方案时：
更新时可以替换项目原文件，而自己的 wanxiang.custom.yaml 继续保留。
词库也一样：个人固定短语、专业词库、用户数据应放在自己的文件或数据库中，不要把长期个人内容直接塞进万象官方词库。
总之就是仓库有的文明你不要与之重名，重名就会被覆盖这是计算机规律。
Q：我修改了 YAML，为什么输入法一点变化都没有？¶
先确认三件事：
- 改的是用户目录里实际正在使用的文件；
- 修改写在正确的方案或正确的
*.custom.yaml； - 保存后执行了重新部署。
Rime 工作时使用的是部署后生成的编译结果，不会因为你保存了一份 YAML 就立刻热更新。
其次任何schema、custom文件都不支持折叠到其他路径中，只能在用户目录最上层。
如果只是改皮肤、前端候选布局，则还要注意：这些往往属于小狼毫、鼠须管、Fcitx5 等前端自己的配置，不一定由 wanxiang.schema.yaml 控制。
相关文档：Rime 工作机制
Q：为什么第一次部署万象会比较慢？¶
这是正常现象。首次部署需要编译词典、生成拼写映射 / Prism、加载语法模型，并初始化相关组件。
其中根据转写的复杂度，部署速度各有不同，虽然我们提倡一次部署后就好好用就好了，但使用rime不可避免地想要自定义和多次部署。
部署过程中不要连续重复点击“重新部署”。尤其词库较大、语法模型已启用时，第一次编译本来就需要时间。
后续如果源文件没有变化，正常情况下不应该每次都完整重建所有内容。
Q：方案已经出现在方案选单里了，但切过去完全打不了字，怎么办？¶
“能看到方案名”只说明方案被发现了，不代表它的依赖、Lua、词典和编译结果都正常。
优先检查：
- 部署日志有没有
error、依赖缺失或 Lua 加载错误； - 使用的平台是否支持当前万象版本所需的 librime / Lua；
- Base / Pro 的词库和语法模型是否放完整；
- Linux / Fcitx5 是否存在前端快捷键或组件冲突。
不要因为“方案名能看到”就把问题直接归到词库。
相关文档：Windows · macOS · Fcitx5 Linux
Q：切换全拼、小鹤、自然码后，为什么有些挂接功能还是原来的编码？¶
万象的拼音类型不只影响主翻译器，还可能影响英文、反查等挂接方案。
因此推荐使用万象提供的方案切换指令，例如：
/flypy → 小鹤双拼
/mspy → 微软双拼
/zrm → 自然码
/sogou → 搜狗双拼
/znabc → 智能ABC
/ziguang → 紫光双拼
/pyjj → 拼音加加
/gbpy → 国标双拼
/lxsq → 乱序17
/ltsp → 蓝天双拼
/sdpy → 首道双拼
/pinyin → 全拼
/zrlong → 自然龙(反查是全拼)
/hxlong → 汉心龙(反查是全拼)
/jjf → 间接辅助
/zjf → 直接辅助
执行切换后再重新部署，让主方案与相关挂接方案保持一致。
不要只改主方案的一行 algebra，就默认整个万象生态已经全部切换。
这只是一种自动方式，其背后的真正原理是把custom目录中携带的预设文件帮你复制到了根目录，原则上这些都要自己打开文件进行修改，可在文档--快速上手--手动设置阅读相关内容
配置与 Patch¶
Q：为什么推荐 wanxiang.custom.yaml，而不是直接改 wanxiang.schema.yaml？¶
因为 *.custom.yaml 是 Rime 原生的覆盖机制。
官方文件负责提供“默认实现”，你的 custom 只写“我与默认值不同的部分”。这样做有两个好处：
- 更新万象时不容易覆盖个人配置；
- 出问题时可以快速判断是官方默认还是个人 Patch 导致的。
对于长期使用，这比直接魔改主方案文件更容易维护。
Q：一个 custom 文件里是不是每改一段都要再写一个 patch:？¶
不是。一个 custom 文件顶部只需要一个 patch:。
正确：
patch:
menu/page_size: 7
super_processor/enable_backspace_limit: false
super_comment/candidate_length: 3
不要写成：
后者会让 YAML 顶层键发生覆盖或产生与你预期不同的结果。
别人写文档、教程是为了体现段落层级，不要看见每一个都有patch: 就都写上。
相关文档：自定义万象方案
Q：@0、@next、/+ 到底是什么意思？¶
它们主要用于处理 YAML 列表。
例如：
表示修改 switches 列表中的第 1 项。
追加内容可以使用类似：
如果你想彻底接管一个数组，而且数组顺序本身决定行为，直接整体覆盖往往比不断插入更清楚。但官方有更新的时候你同样也不是万事大吉，可能需要解构冲突。
Q：我已经改了翻页快捷键，为什么原来的 -、= 还是能翻页？¶
优先检查：
import_preset: default 会把 default.yaml 中的快捷键一起导入。你只修改主方案自己的 key_binder/bindings，并不代表继承进来的规则自动消失。
如果冲突来自 default.yaml，应在 default.custom.yaml 中一并处理。
这也是“明明改了，旧快捷键却还在”的高频原因。
其次是你使用的/+这样的命令来修改的按键，这个表示在原来的末尾追加因此相当于有了两种翻页的按键存在。
Q：可以随便调整 engine/processors、translators、filters 的顺序吗？¶
不建议。
rime的很多 Lua 组件有明确的先后关系。例如字符过滤、注释处理、替换、英文格式化、手动排序、最终去重，各自依赖上游候选的状态。
尤其：
通常应当留在过滤链最后完成最终去重。
如果只是修改某个功能的参数，优先 Patch 对应配置项，不要为了“看起来整齐”重排整个引擎流水线。
Q：我只想修改一个开关默认状态，需要把整段 switches 复制过来吗？¶
不用。
例如修改第一个开关：
只有当你要大幅重排、删除、重建整个列表时，才考虑整体覆盖。
局部修改尽量局部 Patch，结构变化再整体接管。
Q：为什么有些配置改的是主方案，有些还要改挂接方案？¶
因为万象不是一个单文件方案。
例如英文词库可以由 wanxiang_english.schema.yaml 负责独立编译，主方案再通过：
调用它。
所以当你把英文词典换成另一个名字时，通常需要同时保证：
- 挂接方案编译的是新词典；
- 主方案调用的也是同一个新词典名。
只改一头，就可能出现“文件明明存在，主方案就是不用”的情况。
相关文档：词库管理与同步
词库、自造词与同步¶
Q：我只是想加邮箱、地址、签名、固定短语，应该改主词库吗？¶
不用，优先使用 custom_phrase.dict.yaml。
它就是给固定内容和短编码准备的，例如：
三个字段之间使用 Tab 制表符：
不要拿普通空格冒充 Tab。
万象默认给 custom_phrase 较高初始质量，本来就适合做快捷置顶短语。
相关文档：词库管理与同步
Q：custom_phrase.dict.yaml 明明写了内容，为什么不生效？¶
依次检查：
- 列与列之间是不是 Tab；
- 文件编码是否正常；
custom_phrase/dictionary是否仍然指向custom_phrase；- 保存后有没有重新部署。
万象当前默认：
custom_phrase:
dictionary: custom_phrase
enable_completion: false
enable_sentence: false
initial_quality: 99
如果你的目标只是固定快捷短语，没必要为了“同步”或“调频”随意改变这套数据库类型。
Q：custom_phrase、专业固定词典、用户词库、自造词，分别适合什么？¶
可以这样理解：
固定少量内容 → custom_phrase.dict.yaml
大量专业词、长期维护的数据 → 独立 .dict.yaml 并通过 Patch 挂载
日常输入产生的动态学习 → 主翻译器用户词库
我明确想记住一个新词 → 万象的自造词 / 无感造词机制
不要把所有个人数据都塞进一种机制里。用途分开后，更新、同步和排错都会轻松很多。
Q：我有自己的专业词库，怎样挂载才不怕以后更新万象被覆盖？¶
不要直接编辑万象官方 .dict.yaml。
更稳妥的方式是：
- 给自己的词典单独命名；
- 放在用户目录；
- 通过
*.custom.yaml修改对应dictionary或扩展关系； - 重新部署。
如果你替换的是独立挂接词库，例如英文，还要同时保证挂接方案与主方案的调用名称一致。
相关文档：词库管理与同步
Q：为什么 Base 默认会调频，而 Pro 更强调关闭自动调频？¶
这是两个版本输入哲学上的差异。
Base 更接近普通拼音用户熟悉的体验：输入、选择、逐渐学习。
Pro 面向重度辅助码用户，强调“词库和排序本身尽量稳定”，避免无差别学习不断改变精确候选。需要某个私人词明显提前时，可以通过造词和手动排序解决，而不是让所有候选都持续漂移。
所以不要简单理解为：
对 Pro 来说，稳定和可控本身就是设计目标。
Q：PRO版本我造了一个私人名字，为什么没有自动压过系统高频词？¶
这是预期行为之一。
私人名字对你可能极重要，但对于正常语句来说，系统高频词也不能因为一次造词就永久失去合理排序。
万象提供了更明确的方式：先造词，再手动置顶或移动候选。
默认手动排序配置：
这样可以把“私人偏好”与“系统词库整体排序”分开管理。
相关文档：手动排序
Q：多设备同步用户词，应该同步哪个文件？¶
Rime 的动态用户词通过 UserDB 同步。
重点配置在：
建议每台设备设置不同、容易识别的：
并把：
指向同一个同步目录。
执行“同步用户数据”后，Rime 会把用户数据库导出为文本形式，例如：
再由其他设备导入、合并。
相关文档：词库管理与同步
Q：custom_phrase.dict.yaml 会跟着 UserDB 自动同步吗？¶
它本质上是你自己维护的固定文本文件，不等同于输入过程中产生的 UserDB。
如果你希望多设备共用同一份 custom_phrase.dict.yaml，可以用自己的网盘、Git 或其他文件同步方式管理；不要把“Rime 用户词同步”和“任意配置文件同步”当成一回事。你可以选择在一个地方维护变更，其他设备都只是单向下载你的更新。这与UserDB多个设备文件夹合并数据是不同的。
Q：从别的 Rime 方案迁移用户词库，只改 db_name 就一定能用吗？¶
不一定。
用户词不仅有“词文本”，还与原方案的编码、拼写规则、数据库结构有关。
如果来源方案和万象的编码体系不同，尤其涉及带调编码、双拼转写或不同拼写运算时，单纯改数据库名可能把数据导进去了，却无法按你当前输入方式正常召回。
迁移时应先小批量验证，不要直接覆盖现有万象 UserDB。
辅助码、反查与字符集¶
Q：Base 没有 Pro 的专属辅助码，那是不是完全不能辅助筛选？¶
不是。
Base 仍然可以利用万象的：
- 声调；
- 两分 / 多分部件；
- 笔画；
- 反查数据库；
进行筛选。
Pro 的核心增强是：词库编码本身进一步携带专属辅助码信息，因此能在更多输入场景里直接使用对应辅助码。
简单说：
相关文档：辅助码系统
Q：反引号 ` 到底是干什么的？¶
它是万象默认的反查 / 辅筛引导键之一。
主方案中：
而 wanxiang_lookup 也使用：
因此它既连接部件 / 笔画反查，也参与候选中的辅助筛选。
如果你自行修改这个键，要同时理解 speller/alphabet、recognizer、reverse translator 和 super_lookup 之间的关系，不能只改一个地方就结束。
Q：Super Lookup 为什么不像传统辅助码那样必须“第一个码对第一个字”？¶
因为万象采用的是有序模糊匹配思路。
对于词组，它更关注你输入的辅助信息是否按顺序出现在候选的辅助序列中，而不是强迫你每一个码都严格标明属于第几个汉字。
这样做的目的，是让用户“知道多少打多少”，减少为了筛词反而先计算位置的负担。
相关文档：候选辅筛
Q：我不想看辅助码提示，但还想保留反查 / 辅筛，可以吗？¶
可以把“显示提示”和“筛选能力”分开理解。
例如超级注释中的：
控制的是辅助码等注释显示范围。把显示关闭，并不等于必须删除 super_lookup 或 wanxiang_reverse。
因此如果你只是嫌候选注释太多，优先调整 super_comment，不要直接拆掉整套反查组件。
相关文档：超级注释
Q：为什么有些生僻字完全不出现，有些却出现成方框或问号？¶
这是两个不同问题。
完全不出现：先检查字符集过滤。万象的 charset_filter 可以按不同字符集合、白名单、黑名单控制候选范围。
候选存在但显示成方框 / 问号：更可能是当前前端或字体没有对应字形，这不是把字符加入白名单就一定能解决的。
排查时先分清楚是“候选被过滤”，还是“候选已经有了但字体画不出来”。
Q：小字集里缺一个我常用的字，能不能只加这一个？¶
可以。
万象的字符集配置支持 addlist 和 blacklist 微调，而不要求为了一个字彻底关闭过滤。
例如：
实际使用时建议通过 custom Patch 修改，避免更新覆盖。
Q：反查时我更想先看单字，不想先看词组，能切吗？¶
万象提供了对应的候选优先策略开关。
当前方案中有：
用于在特定编码重合、反查 / 辅筛场景下控制“词组先”或“单字先”。
这类需求优先使用已有开关，不需要为了排序单独重写反查词典。
英文混输与内置功能¶
Q：万象为什么有时候会自动给英文加空格？可以关吗？¶
可以。
万象英文 Lua 提供四种策略：
可选：
smart 是默认思路：连续英文输入时智能维护单词间空格，同时允许回车、空格或超时打断状态。
还可以设置：
相关文档：中英与混合编码
Q：我替换了 wanxiang_english.dict.yaml，为什么主方案还是在用旧英文词库？¶
因为英文是“挂接方案编译 + 主方案调用”的结构。
如果新词典叫：
通常要同时让：
和：
指向同一个名字。
只改词典文件名，不同步修改调用关系，很容易出现“编译了一套，主方案叫的是另一套”。
相关文档：词库管理与同步
Q：AI绘画、型号、品牌、英文缩写这类中英混合词应该放哪里？¶
少量固定内容可以直接放 custom_phrase.dict.yaml。
如果是成体系的中文 + 英文 + 数字 + 符号混合词汇，则更适合使用万象的 wanxiang_mixedcode 数据体系，而不是把所有混合词都塞进普通中文用户词。
这样可以保留不同 Translator 之间更清楚的职责边界。
Q：日期、时间的显示格式能自己改吗？¶
可以。
万象把常用格式直接开放在 YAML：
例如：
写几行，就会生成几种候选；顺序就是候选顺序。
时间插件还支持中文星期、英文星期、ISO 周数、时区、12 / 24 小时等占位符。
相关文档：时间日期
Q：/sj、/rq、N20250101 是同一套东西吗？¶
它们都由时间日期体系处理，但入口不同。
/sj：当前时间；/rq：当前日期；/dt：日期 + 时间；/ed：英文日期；N...：数字日期输入 / 查询模式。
其中 /sj、/rq 等前缀来自：
默认可以使用 / 和 o 两种引导方式。
相关文档：时间日期
Q：大写 V、R、U 分别是什么？总记混。¶
记住它们是不同 Translator 的入口：
它们在 recognizer/patterns 中分别分发，不要把 R 的金额转换和 N 的日期模式混在一起。
相关文档：魔法字母
Q：我知道一个符号长什么样，但不知道怎么输入，万象有搜索吗？¶
有。
超级符号支持精确和模糊两种思路，例如：
Emoji 也使用类似规则：
模糊模式可以按关键词搜索 Codex 名称，多关键词还能使用 . 组合。
相关文档：超级符号
Q：候选词后面输入反斜杠，为什么会出现括号包裹功能？¶
这是万象的 paired_symbols / super_filter 能力。
默认触发符：
在已有候选的情况下输入触发符，再追加映射键，可以把当前候选包进：
等成对符号中。
它不是普通标点替换，而是对当前候选进行包装。
相关文档：成对符号
Q：怎么判断是不是 Lua 没加载成功？¶
如果只是一个词打不出来，不足以说明 Lua 有问题。
更有价值的现象是：多个彼此独立的 Lua 功能同时失效，例如时间、计算器、随机工具、超级符号等都没有反应。
这时再结合部署 / 前端日志查看 Lua 模块加载错误，会比盯着某一个候选可靠得多。
Q：为什么同一个词典，多个方案部署时还会各自出现 Prism？¶
因为词典和 Prism 不是同一个东西。
词典提供“有哪些词、编码是什么”；Prism 更接近某个方案经过 speller/algebra 后的拼写映射结果。
不同方案即使共用同一个 dictionary，只要拼写规则不同，也可能需要不同的 Prism。
万象的主翻译器也预留了：
用于明确指定共享 Prism 的场景。
所以“词典一样”并不自动等于“所有方案只编译一个 Prism”。
Q：为什么我的 custom_phrase、英文词、主词库候选优先级看起来不一样？¶
这是设计如此。
不同 Translator 有各自的：
例如 custom_phrase 默认就是为了固定短语快速上屏，因此质量通常高于普通拼音、英文候选。
不要只用“第三列权重”解释所有跨 Translator 排序；词条内部权重和 Translator 初始质量是两个层次。
Q：输入一个不存在的三编码时，为什么偶尔还能吐出前面两码的单字？¶
这是 super_filter 的轻量兜底逻辑。
它会在特定情况下记录两码首选单字；当第三码导致完全无候选时，再把之前的单字作为 fallback 候选吐出来，避免输入突然“断掉”。
这类候选属于兜底，不应误认为主词库真的存在对应三码。
Q：为什么我把候选包裹、动态时间占位之类功能删掉后，其他地方也开始异常？¶
因为 super_filter 并不只负责一件事。
当前实现中它同时承担：
- 文本转义；
- 动态时间占位；
- 成对符号包裹；
- 候选锁定；
- 三码空候选兜底；
等能力。
如果你只是“不想用某一种效果”，优先关闭对应配置或映射，不要随手把整个过滤器从 engine/filters 删除。
还没找到你的问题？¶
建议先这样描述问题
尽量同时提供：平台 / Rime 前端、万象版本、Base / Pro / Lite / Pure、当前输入方案、复现输入、期望结果、实际结果、相关 custom 配置、部署或运行日志。
“不能用”“突然坏了”通常不足以定位问题，而一条完整的复现路径往往几分钟就能判断出问题在哪一层。
FAQ 编写说明¶
本页的问题池会持续吸收万象自身 Issue / Discussion，以及社区中反复出现的共性问题，有什么特定问题也可以进行PR共建