建议：结合已上屏文字、候选框内容与当前字母的联想猜词和拼音纠错

[LightningFlashEvE]

建议与使用场景

建议增加联想猜词，适合连续输入一整段话：结合前面已上屏的文字、候选框内尚未上屏的文字，以及后面正在输入的字母，推测用户真正想输入的后续文字。 候选框中的前半段也可以作为临时语境，不必先逐词确认上屏，才能帮助判断后面的输入。

重点是在继续输入拼音时，让已上屏前文与当前候选内容的语义参与候选生成与排序，同时容忍少量误按字母。希望减少两类问题：键盘按错一个字母后找不到目标词；拼音本身能够匹配，但得到的候选与想表达的意思不一致。

预期交互示例

以下仅为待讨论的验收目标，尚未实现，也不保证每次都能猜对：

• 已确认“我要去”，接着输入 yiyusn（将 yiyuan 的 a 误按成相邻的 s）：结合前文和字母相似度，尝试提供“医院”。
• 已确认“下午我们讨论”，接着输入 fangan：结合语境优先建议“方案”，降低“犯案”等不合当前表达的候选优先级。
• “我要去”仍在候选框内、尚未上屏时，继续输入后半段误按的 yiyusn：利用候选中的“我要去”作为临时语境，尝试给出“我要去医院”的组合候选。无需先把“我要去”提交到应用。

无新字母时推荐下一词可以另行扩展；本讨论优先关注“前文＋当前字母”的联想、纠错和候选排序。

可评估的实现方向

1. 在正常拼音匹配的基础上，对少量相邻键误按、漏字母、多字母或字母顺序颠倒生成受限的纠错候选，再结合已上屏前文及尚未上屏的候选前半段的语义与词语搭配排序。候选内容尚未确定，需要评估多种候选解释，避免把一次错误猜测固定为后续判断的唯一依据。容错范围与性能需要评估，不把具体算法作为已确定方案。
2. 保留正常匹配候选和用户实际输入，让用户能够拒绝误猜；纠错候选应有清楚提示。新输入、候选切换／翻页、组合取消、删改或上下文变化时，旧结果失效，避免把旧建议提交到新位置。
3. 纠错后的拼音仍需通过真实引擎查询、候选校验和正确消费流程，不能直接把模型生成文字当作合法候选提交。如何对应原字母与纠错拼音的消费范围，需要专门设计。

隐私与范围

建议先评估本地方案，使用当前连续输入会话中由灵果确认上屏的有限前文，以及灵果自身正在处理的组合输入与候选框内容；不扫描宿主正文、不读取剪贴板、不持久化或上传句子。跨应用／输入框、移动光标、删除或外部编辑等无法保证前文连续性的情况下清空上下文；密码等敏感输入框禁用。

现有 MiniMax 授权仅用于当前中文候选翻译，不包含把前文发送到云端进行猜词；账号同步仍只处理所选词条元数据。如需新增语料或模型，应单独确认来源、许可和打包声明。

希望讨论的问题

• 已上屏前文保留多长，候选框中的未确认内容如何作为临时上下文？参考当前选中候选还是多个候选解释，如何避免错误猜测不断累积？
• 允许多大程度的拼音错误，如何避免错误纠正专名、英文、网址和用户原本想输入的内容？
• 联想与纠错是否共用开关？建议先提供独立开关、默认关闭；候选如何标记，是否沿用现有选择按键？
• 是否同时展示联想词的英文释义，英文确认后如何维护上下文？
• 两端如何共享引擎能力与验收用例，同时保证各自原生输入行为？

状态：功能建议，待讨论。后续分别记录 macOS 与 Windows 的实现和实机验证；验收需覆盖误按／漏按／多按／颠倒字母、语境歧义、连续段落输入、未上屏候选参与推断、候选切换／翻页／组合取消后的重算与旧结果失效、候选拒绝、新拼音接管、光标与焦点变化以及关闭功能后的正常输入。