Jia Sui
5d1a9a6cc2
五笔敲满四码且码表只答一个候选时不再需要空格：第四个字母落下即上屏，下一个 字母直接开新组合。行为无条件生效，不设配置开关：业界默认开启（微软五笔、 搜狗五笔、极点、Rime 主流五笔方案），唯一候选没有第二选择，确认空格是纯冗余； 而一条开关要牵动配置五处同步，换不来可形成预期的行为差异，不值。 - engine 只报告事实（wubi_unique_four_code：完整四码、码表作答、候选恰好一个）， 是否上屏由 Server 决定；判定收在 input_key_policy.h 的纯函数里，随 portable 目标进 ASan/UBSan；组词（creating_word）激活时组合保持打开，唯一四码不会把 正在拼的词截断上屏 - 提交复用 ProcessSelectionKey，与空格上屏同一套记账；但只能走 worker 管道推送 CommitCandidate：字母键在默认 raw 预编辑样式下不读请求-回复管道，回一帧 Normal 既不会上屏，还会在 TSF 侧留下永不释放的回复帧，而 Server 已按 Normal 清掉组合 - 上屏前按当前组合同步重建候选页：候选页异步发布，提交路径读的 ui.items / page_words 否则可能还停在第三码那一拍 - 非唯一四码不做顶字上屏：一个按键只能回一条管道消息，真顶字需要扩 IPC 协议
输入方案
一个「输入方案」负责把按键序列变成一次候选查询。全拼、双拼、五笔、日文罗马字四种方案共用同一个接口，彼此不知道对方存在——加一种新方案（注音、粤拼、仓颉……）不需要改动任何一个已有方案。
这一页说明加一种方案要动哪几处、每一处要做什么。招募文档把「实现新的输入方案」列为门槛最高的方向，但此前这个目录下只有一个 17 行、零注释的纯虚基类。
接口
input_scheme.h 定义了全部五个方法：
class IInputScheme
{
public:
virtual ~IInputScheme() = default;
virtual void reset() = 0;
virtual void handle_key(ImeKeyCode vk, ImeModifierMask modifiers_down, ImeCharacter wch) = 0;
virtual QueryRequest build_request() const = 0;
virtual std::string get_preedit() const = 0;
virtual SchemeType type() const = 0;
};
| 方法 | 职责 | 注意 |
|---|---|---|
reset() |
清空当前编码串与按键记录 | 上屏、取消、切换方案时都会调用，必须回到干净状态 |
handle_key() |
收一个按键，更新内部状态 | 不查词库、不发网络请求、不碰全局状态。 这个方法在每一次击键的关键路径上，宿主进程等着它返回 |
build_request() |
把当前状态打包成 QueryRequest |
const 方法，不改状态；同样的状态调用两次必须得到同样的结果 |
get_preedit() |
返回要显示在编辑区的文本 | 用户看到的正在输入的内容，不一定等于原始按键 |
type() |
返回本方案的 SchemeType |
候选提供者据此路由 |
handle_key 只接受方案自己认得的键。哪些键该由方案处理、哪些该交回宿主（翻页、选词、方向键），由调用方 ImeSession 决定，方案不需要关心。
QueryRequest：方案与候选查询之间的契约
../core/query_request.h 里的这个结构是方案唯一的输出。字段不必全填，但 valid 必须准确——valid == false 表示当前编码还不足以查询，会话不会去查词库。
几个容易搞错的字段：
raw_input是规范化后的编码串（通常是小写），raw_input_with_cases保留原始大小写。英文混输和以词定字要用后者。normalized_input是拿去查库的键。全拼里它是纠错、简拼展开之后的结果；一个不做这类处理的方案直接填成和raw_input一样即可。segmentation/raw_segmentation/normalized_segmentation是分词结果，音节之间用'分隔。不分音节的方案（五笔）留空。key_strokes是原始按键序列。候选窗要还原用户实际敲了什么时用它，比如显示原始编码。enable_*那几个开关由会话按用户配置填写，方案不要自己设。
加一种新方案要动的地方
以五笔为例走一遍（wubi_scheme.h / wubi_scheme.cpp 是最短的一个实现，适合照着看）：
-
../core/scheme_type.h— 在SchemeType里加一个枚举值。 -
schemes/<name>_scheme.{h,cpp}— 实现IInputScheme。构造函数可以带参数：双拼方案就接收一个ShuangpinProfile，方案表由调用方注入而不是硬编码在方案里。 -
../core/ime_session.cpp的create_scheme()— 在 switch 里加一个分支返回你的实现。这是唯一注册点，没有别的注册表或工厂宏。 -
候选提供者 — 决定查询走哪条路。
../providers/provider_registry.h的resolve(SchemeType)把方案映射到一个ICandidateProvider。如果新方案查的是已有的库（比如注音可以复用拼音库，只是编码转换不同），映射到已有的 provider 即可，不必新写一个。查全新的表才需要实现../providers/candidate_provider.h的ICandidateProvider——注意它有八个方法，除了query()还包括造词、调频、删词和动态候选缓存，都要实现。 -
词库 — 新方案如果需要自己的表，表结构受
../contracts/dictionary/format.json约束。建库流水线不在本仓库内（见../UPSTREAM.md），词库是product-lock.json钉住的发布产物，所以新表要先有人出一版带这张表的词库发布，再把锁指过去；在那之前方案只能落在已有的表上。数据的再分发授权要求见../NOTICE.md。 -
../CMakeLists.txt与../tests/CMakeLists.txt— 两份源码列表都要加上新文件。只加前者会导致测试链接失败，只加后者会导致产品里没有这个方案。 -
测试 —
tests/src/下加一个test_<name>_scheme.cpp，并登记到tests/CMakeLists.txt。参考test_shuangpin.cpp（方案层的按键与 preedit）与test_pinyin.cpp（编码与查询）。最低限度要覆盖：一串典型按键得到的get_preedit()、build_request()的valid何时为真、reset()之后状态确实干净、以及非法按键不会破坏状态。
提交之前
cmake -S . -B build && cmake --build build && ctest --test-dir build全绿。- 说明你实际敲了什么、看到什么。输入法的正确性很难靠读代码判断，PR 里请写清验证方式（见组织的贡献指南）。
- 方案本身不联网、不读配置文件、不写日志。这些都由上层负责。