做输入法至今，虽然代码全部由 Codex 编写，但自己的参与度和精力投入却一点也不少。当然，我的角色就更像是产品经理＋测试，技术层面的选择与决策，越往后就越倾斜到 Codex 一边了。

有了自己的输入法，最爽的莫过于一旦有了新想法，就能随时在上面快速实现、验证并切实体会到它带来的便利。

聊到输入法时，常有人问我支不支持“联想”功能。我知道，他们指的是类似移动端输入法的体验：当输入一个词后，系统会自动预测并推荐下一个词。比如在 iPhone 上输入“你好”，软键盘上方就会出现“吗”、“开心”、“可爱”等候选词。但大家往往忽略了，桌面端（非触控）输入法其实很难直接照搬这种模式——倒不是技术上做不到，而是受限于实体键盘的交互方式，无法直观地通过点按候选条来完成选择。

周六晚上洗澡时，突然有了一个灵感。

程序员在现代 IDE 中编写代码时，通常都会依赖代码自动补全功能。只需敲入前几个字符，IDE 就会预测后续的代码片段；只要预测准确，按下 Tab 或回车键便能直接补全整行代码，大幅减少击键次数。

同理，言泉输入法也可以引入类似的补全机制。当用户输入两个字或更多时，就可以通过词库以及语料训练的强转移词来预测用户实际最可能希望输入的长词或者长句。如果用户认为正确，则可以通过“Tab”或者“`”键将长词/长句直接上屏，大幅减少键盘敲击次数。

得益于言泉已有的架构，Codex 很快便把这个灵感变成了现实。

昨天立秋，深夜我发布了 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

随着 Vibe Coding 项目的持续深入，你会在与 AI 一轮又一轮的沟通、探讨与推敲中，在反复测试与验证的循环里，在逐步提升的思考过程中，悄然获得成长。因为不断出现的关键决策，会越来越依赖你给出清晰、具体且可验证的方向。否则，AI 很可能会陷入一种看似忙碌、实则原地打转的状态：代码不断生成，问题不断修补，目标却始终若即若离，仿佛深陷泥潭。

言泉输入法今天完成了 v0.4.1。这个版本除了在长句输入方面持续改进之外，最重要的变化，是彻底区分了字词输入与长句输入这两种模式及其状态。最初，言泉输入法是基于我个人按字词输入的习惯而开发的；后来了解到很多人更偏好长句输入，于是从 v0.2.0 开始支持长句输入模式。然而，随着长句模式被不断改进，我逐渐发现：当我自己使用按字词模式输入时，候选中时常会因为受到“污染”而冒出一些生造词。我渐渐意识到，污染源正是长句模式中的寻路算法，于是让 AI 设法解决。但 AI 的表现，却像玩跷跷板：顾此失彼，按下这头，那头便翘起；优化了字词输入，长句效果就受损；强化了长句路径，字词候选又被干扰。最终，在与 AI 经过数轮沟通、修改与验证之后，我自己终于形成了一套更清晰的算法思路。我把这个明确、清晰的结论交给 AI，由它据此重构代码，才终于得到了现在这个还算不错的阶段性结果。当然，它距离理想状态仍然很远，后续还需要继续打磨和优化。

Vibe Coding 并不是你轻描淡写地说一句“要有光”，AI 便立刻为你捧出光来。真正的 Vibe Coding，需要你与 AI 共同进步。AI 模型会持续升级，能力也必然越来越强，但它并不是——至少在短期内还不会是——全知全能的神。倘若把一个需要长期迭代、不断权衡、持续验证的复杂任务完全交给它独自完成，最终你很可能得不到真正可用的结果。你自己的思考，才是校正航向、修正偏差、推动 AI 向目标逼近的关键力量。

官网：https://www.cassotis.org 或者 https://www.yanquan.org
Github：https://github.com/shenmin/cassotis-ime

在 v0.2.0 发布后，我继续让 Codex（gpt-5.4-xhigh）完善长句支持，并增加词库层。

我为输入法设计了一个 Benchmark：将我的小说《永恒的舞动》作为测试语料，选出不包含英文字母和数字的完整语句作为测试案例，转换为拼音后送入言泉输入法的引擎。如果结果的第一候选与原句完全一致，则计入 Top1 Pass；如果第一、第二候选任一个与原句一致，则计入 Top2 Pass。我让 Codex 按照这一测试方法的指标执行优化，由此创下了 Codex 单次任务运行 72 小时的纪录。

然而，没想到这只是 Codex 陷入近两周泥潭的开始。结果总是在“性能（延迟）”、“长句效果”、“短句效果”三者之间摇摆，犹如打地鼠般。直到 gpt-5.5-xhigh 到来，Codex 仿佛获得了新的力量，终于爬出了泥潭。不过，后来在修复另一个小 Bug 时，它却又像跌入了水沟。挣扎了三天后，我开了一个新的 session，相当于给 Codex 换了个脑子（丢弃旧上下文），问题根源终于被找到。

今天，我让 Codex 使用 v0.2.0 的引擎和 v0.3.1 的引擎分别做了 Cassotis 长句 Benchmark-16300 测试，结果如下：

版本	Top1	Top2
v0.3.1	23.59%	28.53%
v0.2.0	16.39%	17.56%

改进显著。

官网：https://www.cassotis.org 或者 https://www.yanquan.org

v0.1.0 版本发布后，收到一些朋友的反馈，我才发现许多人更习惯或偏爱长句输入。于是，我将下一步的开发重点放在了对长句和整句输入的支持上。我向 Codex 征求了技术层面的落实建议，它建议：……（其实我并没有仔细看），我便直接让它按照自己的思路去实现了。

很快便有了初步成果，当时我还颇觉惊喜。但没想到的是，随后的三天仿佛陷入了泥沼。代码越改问题越多，彻底陷入了细节的反复拉扯中。眼看当前的状况已不是多改几轮就能解决问题的，我便提醒 Codex 是否该反思一下现有的策略。Codex 终于承认此前的方向似乎有误，并表示已经找到了正确的新路径。于是，我让它将代码库的 worktree 回退到上一个发布版本，推倒重来。

或许是反思奏效了，所幸这次它没有重蹈覆辙。重新实现的版本一扫前几日的阴霾，在各方面的表现都达到了令人满意的程度。又经过几天的细致打磨，v0.2.0 版本正式出炉。

现在，算是初步支持长句输入了。

当然，Codex 的脚步并未就此停歇。我问它：“长句输入还有没有进一步改善优化的空间？”它回答：“还很大。”很好，那就让它继续加油开干吧。

另外，最近我找到了一种让 Codex 一次性完成整项任务的工作方式，每次它都能连续工作4到6个小时，可谓勤勤恳恳。

官网：https://www.cassotis.org 或者 https://www.yanquan.org

用 Codex 消耗了近三亿 token，写出近五万行 Delphi 代码，开源 Windows 输入法——言泉输入法的首个正式版本 v0.1.0 已经可以在 GitHub 下载了。

我还让 Codex 和 Claude Code 合作设计、优化出了官网：https://www.cassotis.org 或者 https://www.yanquan.org

之前提过，最初萌生 Vibe Coding 一个输入法的想法，是希望尝试让输入法结合 AI 的能力。但经过实际接入本地大模型的尝试后，我认为当下尚不具备实用性，于是便让 Codex 将项目中的 AI 相关代码全部移除。所以，现在实际 release 的版本完全不包含任何 AI 特性。对我而言，她就是一个用来取代十多年前停止更新的谷歌拼音 2.0 的替代品。就连输入风格也是——适合按词输入，而非长句/整句输入。

启动这个项目的另一个原因，是想探索纯 Vibe Coding、完全依赖 AI 写代码究竟能做到什么程度，同时摸索如何驾驭 AI 写出更高质量的生产级代码。与 AI 沟通的过程，会让自己对项目本身产生更深入的理解。我对 Windows 系统的输入法开发框架完全不了解，但在 Vibe Coding 的过程中，随着项目推进，虽然我一行代码都没写，却也逐渐熟悉了整套框架。这和传统开发流程——先研究、熟悉相关框架再动手写代码——有着非常大的差别。

关于 Vibe Coding 当下的心得：

1. 首先你自己需要清楚知道要做什么（才能检验结果）；
2. 要有极强的耐心（可能会遇到与 AI 反复拉扯的情况）；
3. 用最好的模型（不要在低质量的廉价模型上浪费时间）；

言泉输入法还会继续迭代。虽然现在开始流行 AI 加持的语音输入（究其原因，我认为是当下语音模型的效率与性能已达到实用级别），但我个人无法接受对着电脑说话作为输入方式——我爱键盘！Vibe Coding 不就是为了能做市面上找不到满意的而首要服务于自己的东西么？

十几天断断续续的 Vibe Coding，加上 Codex 确实给力了许多，输入法已经具备了初步的可用性。比如：支持接入本地 LLM（虽然在速度和效果上还不尽如人意，尚未达到实用程度）；创建了基础词库；支持简拼；支持词条动态权重；中英文状态切换/显示，以及提升了TSF框架的稳定性等。

Delphi 代码规模已增长到 25000+ 行（首次上传到 GitHub 是 12000+ 行）。

至于后续计划，首先会将言泉输入法切换为个人主力（甚至唯一）中文输入法，实际的高频使用才有可能将不爽、不顺畅的点一一发现并改进；再尝试引入基于上下文预测的 LLM 增强模式。对于本地 LLM，我评估其暂时难以达到工程上的实用性，但作为探索，相信不需要等待太久，LLM 本身就会得到改进并落地。

输入法：https://github.com/shenmin/cassotis-ime
词库：https://github.com/shenmin/cassotis-lexicon

（作者使用言泉输入法输入本文）

2025 年年中，我萌生了一个想法：中文输入法与大语言模型在本质上都有“接龙式”预测的共性。由此自然引出一个设想——能否借助大语言模型的力量，显著提升中文输入体验？

在 Windows 平台上，当前主流的中文拼音输入法几乎全由互联网大厂主导，而开源方案则普遍体验欠佳。多年来，我不得不使用早已停止维护十余年的谷歌拼音输入法 2.0。即便到今天，想要找到一款干净、纯粹且用户体验出色的输入法，也几乎不可能。

想法与现状不断碰撞，最终在“Vibe Coding”的催化下迸发出火花。

“Vibe Coding”概念提出已一年有余，但 AI 编程能力在不同领域、不同开发者眼中的表现始终大相径庭。然而到 2025 年下半年，Codex CLI 在 Delphi/Pascal 语言的代码生成上已具备实际可用性（相比之下，Claude Code 即便搭配 Opus 4.6 仍只会“添乱”）。12月，我借助 Codex CLI（gpt-5.2-xhigh）启动了“Cassotis IME（言泉输入法）”项目。

英文名 Cassotis 源自 Delphi 神庙内的一眼圣泉——女祭司皮媞亚（Pythia）在发布神谕前会饮此泉水，以进入通灵状态。这眼泉水被视为预言与灵感的真正源头，是神谕诞生之地，完美呼应了从 Delphi 到人类语言的神圣路径。中文名“言泉”既契合 Cassotis 作为预言之泉的意象，又取“言如泉涌”的寓意，寄托了对流畅、智能输入体验的期许。

现在，Codex CLI 背后的模型已升级至 gpt-5.3-codex(xhigh)，即便面对 Delphi 这类小众语言，也已近乎“言出法随”。修复 bug 而不引入新问题的能力，已明显超越 codex-5.2。

今天的版本已能正常输入中文单字（数据源自 Unihan）及用户自定义词汇。未来有很多演进路径，我首先想尝试的，是以本地部署的小型 LLM 替代规模巨大的传统静态词库。如果短期内在响应速度或效果上难以达到理想水平，则将转向工程层面的优化策略。

无论如何，这个项目会保持 Vibe Coding 的开发方式。

GitHub地址：https://github.com/shenmin/cassotis-ime