背景与初衷
近年来 AI 在编码等领域的颠覆性应用，让我们开始思考另一个方向：通用大模型的能力，
能否被"小型化"地迁移到一个个垂直场景，由领域专用的小模型来承担聚焦的工作。
输入法是 PC 端绕不开的高频工具，是验证这一想法的理想切入点。我们对"AI 推理在垂直场景下"
持乐观态度——相比通用大模型，一个聚焦于"整句联想 / 语义续写"的小模型，可以在体积、
延迟、隐私（本地推理）上取得更好的平衡，让输入体验得到实质提升，而无需联网或庞大算力。
在调研过程中我们选择了 librime 作为基础，其清晰的模块化设计让插件能以非侵入的方式接入。
经过原型验证，我们确认了"用神经网络给输入法做整句联想"在体验上的价值，并已开源：
核心插件 librime-ai-predict，配套前端改动已通过 #1143 合并进 squirrel master。
承蒙各位指导，前端侧的通用扩展挂载点（ReservedProperty 协议）已经落地。在此基础上，
我们希望进一步探讨：将本插件作为官方插件集成的可能性，以及随之而来的模型分发方案。
试用与构建
欢迎大家先上手体验，再参与讨论：
关于几个前置条件的说明
针对此前提到的几点顾虑，我们先做明确答复：
1. 技术栈完全开源
插件本体与推理链路均基于开源技术，不含任何闭源或私有依赖，可供社区完整审阅与复现。
2. 训练数据来源清白
模型训练数据来自主流媒体的公开文章，用途是训练语法结构与语义词句的准确性，
不涉及版权或隐私争议。我们会在仓库中补充数据来源与授权的说明文档。
3. 团队承诺长期维护
我们承诺对插件进行长期维护：定期收集 issues 中的反馈，针对性地调整训练，
持续提升推理效果与联想质量。这不是一次性投放，而是会随社区使用反馈迭代的项目。
待探讨的核心议题：模型数据如何分发到用户端
这是我们认为最需要公开征求意见的部分。当前模型为 int8 量化、约 300MB（简体中文），
"如何把模型数据交付到终端用户"直接关系到能否作为官方插件集成。我们抛出几个方向，
请大家评估、补充：
方案 A —— 随发行版捆绑（基础保底方案）
模型文件直接打包进发行包，随输入法一同安装。优点是开箱即用、无需联网、行为可预期；
代价是发行包体积增大。这是我们能保证可行的最低限度方案。
方案 B —— 独立更新机制（规划方向）
模型与主程序解耦，支持按需下载 / 增量更新，参考业界主流做法（如词典、语言包的
独立分发模式）做规划设计。这样既能控制发行包体积，也便于模型单独迭代而不必重新发版。
这部分我们目前还在设计阶段，希望听取社区在实现路径上的建议。
我们倾向于"先以方案 A 保证可用，再逐步演进到方案 B"的节奏，但具体取舍想先听听大家的想法。
期待的反馈
- 作为官方插件集成，除上述三条件外是否还有需要补齐的要求；
- 模型分发方案的取舍与实现思路；
- 任何关于仓库结构、文档、协作方式上的建议。
流程上若有不妥之处，恳请不吝指正。感谢。
背景与初衷
近年来 AI 在编码等领域的颠覆性应用，让我们开始思考另一个方向：通用大模型的能力，
能否被"小型化"地迁移到一个个垂直场景，由领域专用的小模型来承担聚焦的工作。
输入法是 PC 端绕不开的高频工具，是验证这一想法的理想切入点。我们对"AI 推理在垂直场景下"
持乐观态度——相比通用大模型，一个聚焦于"整句联想 / 语义续写"的小模型，可以在体积、
延迟、隐私（本地推理）上取得更好的平衡，让输入体验得到实质提升，而无需联网或庞大算力。
在调研过程中我们选择了 librime 作为基础，其清晰的模块化设计让插件能以非侵入的方式接入。
经过原型验证，我们确认了"用神经网络给输入法做整句联想"在体验上的价值，并已开源：
核心插件 librime-ai-predict，配套前端改动已通过 #1143 合并进 squirrel master。
承蒙各位指导，前端侧的通用扩展挂载点（ReservedProperty 协议）已经落地。在此基础上，
我们希望进一步探讨：将本插件作为官方插件集成的可能性，以及随之而来的模型分发方案。
试用与构建
欢迎大家先上手体验，再参与讨论：
https://github.com/wyjrichhh/librime-ai-predict/releases/tag/v0.1.0-macos ，
下载后即可体验整句联想效果。
提供完整源代码与构建说明，可自行编译验证技术栈与推理链路。
关于几个前置条件的说明
针对此前提到的几点顾虑，我们先做明确答复：
1. 技术栈完全开源
插件本体与推理链路均基于开源技术，不含任何闭源或私有依赖，可供社区完整审阅与复现。
2. 训练数据来源清白
模型训练数据来自主流媒体的公开文章，用途是训练语法结构与语义词句的准确性，
不涉及版权或隐私争议。我们会在仓库中补充数据来源与授权的说明文档。
3. 团队承诺长期维护
我们承诺对插件进行长期维护：定期收集 issues 中的反馈，针对性地调整训练，
持续提升推理效果与联想质量。这不是一次性投放，而是会随社区使用反馈迭代的项目。
待探讨的核心议题：模型数据如何分发到用户端
这是我们认为最需要公开征求意见的部分。当前模型为 int8 量化、约 300MB（简体中文），
"如何把模型数据交付到终端用户"直接关系到能否作为官方插件集成。我们抛出几个方向，
请大家评估、补充：
方案 A —— 随发行版捆绑（基础保底方案）
模型文件直接打包进发行包，随输入法一同安装。优点是开箱即用、无需联网、行为可预期；
代价是发行包体积增大。这是我们能保证可行的最低限度方案。
方案 B —— 独立更新机制（规划方向）
模型与主程序解耦，支持按需下载 / 增量更新，参考业界主流做法（如词典、语言包的
独立分发模式）做规划设计。这样既能控制发行包体积，也便于模型单独迭代而不必重新发版。
这部分我们目前还在设计阶段，希望听取社区在实现路径上的建议。
我们倾向于"先以方案 A 保证可用，再逐步演进到方案 B"的节奏，但具体取舍想先听听大家的想法。
期待的反馈
流程上若有不妥之处，恳请不吝指正。感谢。