秋天的第一个版本：Cassotis IME（言泉输入法）v1.12.0

昨天立秋，深夜我发布了 Cassotis IME（言泉输入法）v1.12.0。用这个稍微有点烂俗的标题，标记一个重要的里程节点。

去年十二月，冬天，当 GPT-5.2 让 Codex 变得真正可用的时候，Codex 写下了言泉输入法的第一行代码。不过，起初我并没有太上心，项目早期的基础设施搭建比较繁琐，尤其是 TSF 框架与稳定性的建立，磨合过程十分琐碎，我只是在有闲暇时才偶尔推进一下。

就这么慢慢磨合直到除夕那天，期间 Codex 背后的模型也升级到了 GPT-5.3。我觉得项目终于进展到了可以公开的程度，便将其开源至 GitHub。自此，项目才真正进入了“上心”且持续开发的阶段。

三月底，输入法框架终于趋于稳定，我便发布了第一个 Release 版本——v0.1.0。此后，根据身边朋友的反馈，我开始加入对长句/整句输入模式的支持，并在四月中旬，发布了第一个支持长句输入的 v0.2.0 版本。为了更准确地评估长句输入模式的质量，在四月的最后一天，我从自己仍在写作的小说《永恒的舞动》已完成章节中，抽取了16300句符合条件（没有数字、英文字母等）的长句作为语料，创建了 Cassotis 长句基准测试-16300。

随着 v0.x 系列版本的持续迭代，长句输入的准确率一点一点提升。不过，由于我个人的日常习惯偏向短词输入，长句体验并非我的痛点。对我而言，让输入法停留在“可用”而非“好用”的关键瓶颈，在于不跟手——逐键输入时的延迟比较高。但当时的精力仍然主要聚焦在长句算法的改进上。

7月4日，一位用户在 GitHub 上提交了一个名为“性能优化请求”的 issue：长句输入时程序会明显卡顿，敲完键盘后往往还要再等上几秒，视频中的单次延迟甚至接近八秒；而同一台设备上的 Rime 却几乎感知不到延迟。这个 issue 提醒了我，必须正面面对这个性能问题了，因为这不是提升机器配置或者放慢输入速度就能掩盖的问题了，不是“输入法本来就这样”，因为别人（Rime）完全能够做好。

输入本质上是一次次的搜索。一串拼音有许多种切分方式，每段拼音又对应若干词条，可能的组合会迅速铺开；人是一个字母一个字母敲的，相邻两次输入高度重叠，其中许多后缀、切分和词库查询却会被反复计算。句子越长，冗余计算就越多，卡顿与延迟便是这样一点点积聚出来的。关于这个问题，我此前并非没有尝试让 Codex 优化过，只是过去总是在“快一点但准得少一点”之间反复权衡，始终未能真正解决。

7月10日，Codex 换上了 gpt-5.6-sol max。“言出法随”这个词我用过很多次，但我发现它其实也是有程度之分的。我曾用“言出法随”来形容 gpt-5.3-xhigh，可当 gpt-5.6-sol 登场时，我却又一次忍不住感叹：这才是“真正”的言出法随。

升级到 gpt-5.6-sol 的 Codex 不再止步于小修小补，而是开始着手清理那些被白白浪费的计算：同一段后缀只要计算过一次，就按位置记录下来以供复用；相邻按键频繁检索到的词库结果，被放入有界缓存中；搜索和后处理环节则设定了明确的时间预算，避免极少数复杂句子无休止地拖长响应。这其中并没有什么玄妙之处，归根结底依旧是经典的优化思路：减少重复查询与合理缓存。但效果很好，在我特意于基准测试中加入延时指标后，数据明确显示输入延迟降低了近一个数量级，同时准确性不仅没有受到破坏，甚至还略有提升。

于是，我将版本号正式定为 v1.0.0。在我看来，它终于跨过了“好用”这道门槛。

之前提过，做输入法最初的念头，是将输入法与 AI 大模型相结合。此前我也做过接入本地大模型的尝试，但结论是目前尚不具备工程实用性，最终还是将这些测试代码彻底清理掉了。

在 v1.0.0 发布后，我问 Codex，要更大幅度提升输入法的候选排序质量以及长句模式的寻路算法的准确性，下一步应该做什么。Codex 提到可以通过统计语言模型来计算字词之间的转移关系，这需要使用比较大规模的语料。正好，我在7月1日启动了一个实验性的 GPT 模型训练项目，计划在单张 RTX-4090 显卡上训练一个 1.2B 参数的小型 GPT——nc-GPT。它和输入法本毫无关联，只是又一个个人探索性的项目。但为了训练这个 GPT，Codex 帮我找了几十 GB 清洗过的合规中英文语料。其中的中文部分，正好可以在此时作为输入法统计模型的训练语料。

统计语言模型不像 GPT 模型训练那么耗费算力。没有使用到显卡，在v1.0.0 发布后的第二天，第一版统计语言模型就构建完成，其量化后的结果被写入词库，于是就有了 v1.1.0。这样的模型在运行时，仅仅是本地静态函数打分，不需要联网，不依赖显卡算力，也不需要额外的推理框架，却让“长句-16300”的基准测试的 Top1 相比 v1.0.0 提升了3.5个百分点。随后发布的 v1.2.0 则进一步扩展了字符语言模型，使其能够更早地参与长句路径保留与完整候选排序。

后来，引擎里逐步加入真正的小型神经模型。v1.3.0 有了项目的第一个可部署的长句残差重排器：模型在离线环境中训练，参数转换成确定性的原生代码，运行时只对已经生成的少量候选做一次谨慎复核。v1.4.0 和 v1.5.0 又把类似的思路用到短词上，让输入法参考光标前的文字，判断同一个拼音下更可能是哪一个词。v1.6.0 把模型前移到长句路径搜索，由第二阶段和最终候选模型逐级复核， 并复用中间计算控制延迟；v1.7.0 依据语料训练的词路径转移证据识别四音节输入中的双词组合；v1.8.0 为完整长句增加成对比较、局部差异和最终可见候选的残差复核，并为没有可用前文的短词建立独立排序， 模型证据不足时仍以高置信度的精确匹配为准；v1.9.0 将多种完整路径汇入统一候选池， 再结合语言模型、N-best 共识和残差信号统一复核；v1.10.0 将语料转移证据扩展到三音节 1+2 / 2+1 精确词组合，并为长句首两项加入保守复核；v1.11.0 进一步利用小说、聊天和大规模中文语料训练转移证据， 覆盖 1+2、2+1、2+2、2+3 和 3+2 精确词组合；

现在，v1.12.0 又将语料证据扩展到最细的一格：受控的 1+1 单字组合。

如今，在“长句-16300”基准测试中，Top1 已经从最初 v0.2.0 的 16.39%，提升到了 59.92%。这在理论上意味着，它已经能够应付日常长句输入的大多数场景了。“好用”更进一步——“越来越好用”。

在建立了“长句-16300”基准测试之后，针对我日常习惯的短词输入模式，我觉得也应该有一套对应的基准测试，来评估和衡量后续的改进。Claude Fable 5 发布后，我便借助 Claude Code 让 Fable 5 同样基于《永恒的舞动》，整理出 65000 个二至四字词（排除了人名、机构名等专有名词）及其真实出现的位置，并保留每个词之前已经上屏的前文。由此创建了“短词上下文基准测试-65000”。尤其是，其中包含 11728 条案例的竞争集（同一拼音串对应多个不同候选词的歧义项）是一个极具价值的测试子集——它的 Top1 从 v1.3.0 的 70.99%，提升到了如今的 79.33%。

除了性能与准确率的提升，迭代中还根据用户反馈，增加了双拼（六种方案）和模糊拼音的支持。

回看这大半年，言泉输入法从零起步，逐渐变成了一款“很不错的输入法”。在 Vibe Coding 中，模型能力的升级非常关键。没有 gpt-5.6-sol，延迟这一关或许至今仍卡在原地。但同样关键的，还有这个项目终于有了可靠的度量体系。之前我曾写过 Codex 在性能、长句、短句三者之间来回摇摆，犹如打地鼠。后来我才明白，那种困境的根源在于判断依据的缺失：当一次修改的收益无法被稳定测量，AI 便会不知疲倦地一直改下去，而你无法判断它是在前进还是原地打转，它自己也不知道。

基准测试将结果量化，“这一版是不是真的更好”才不再只是感觉问题。新版本的寻路算法是不是更好，我说了不算，Codex 说了也不算，只有基准测试的数据说了才算。

与 AI 一起做一件需要长期迭代的复杂工程，应该先建立度量，再谈优化。方向是你的，判断依据也必须由你预先设定。

秋天大概是个适合盘点的季节。从去年冬天写下第一行代码至今，言泉输入法已经成了我唯一在用的中文输入法。这句话在那时还只是一个计划。

官网：https://www.cassotis.org 或者 https://www.yanquan.org
输入法：https://github.com/shenmin/cassotis-ime
词库：https://github.com/shenmin/cassotis-lexicon