Jeff

Jeff 是一个 0.8B 的开源模型，定位是坐在更大的模型前面、把快的决定先做掉：它先回答，只有不确定时才把查询交给像 Qwen3.8-27B 这样的模型。一个基座配可替换的 LoRA adapter——2026-10-01 的 v1.2 社区预览随附九个——覆盖守卫、分诊、支持意图、工具选择、依据核对、导航、垃圾信息与合同条款。README 报告：准确率 95.3% 对「全部由 27B 决定」的 86.6%，每次决定 0.25 秒而不是 8.1 秒，九个 adapter 全加载时额外占用 1.96 GB。

谁做的仓库 14 次提交里有 13 次是他的，第 14 次来自另一位贡献者。14 次中有 9 次带共同作者尾注，且 9 次全部署名 Claude Opus 5.5（1M 上下文）。

1. 01

   从空仓库到带九个 adapter 的预览，四天

   仓库创建于 2026-09-28，共 14 次提交，九月 12 次、十月 2 次。它是作为社区预览而不是正式版发布的：README 宣布 Jeff v1.2 与九个 adapter，请读者把能用的部分提成 issue，并写明稳定的长期支持基座 v1.3 大约 36 小时后发布、官方 adapter 随后重训。它同时把由此带来的限制直说而不是埋起来——adapter 不能在基座版本之间沿用，必须重训；而数据集可以沿用，前提是按公布的规范来做。

2. 02

   是谁写的：14 次提交里有 9 次署名模型

   14 次提交里 13 次是作者的，1 次来自另一位贡献者。9 次带共同作者尾注，且 9 次全部署名 Claude Opus 5.5（1M 上下文）——占全部历史的三分之二。这是本批里比例最高的一条，也值得说清它意味着什么、不意味着什么：它是「模型写了那些提交中相当一部分代码」的证据，不是关于训练数据、也不是关于基准数字如何得出的证据。

3. 03

   主张是一场对比，而且被完整印了出来

   README 并没有论证「小模型好」，而是把两种配置放在同一批测试行上并排。跨八个 adapter：全部由 27B 决定的配置是 86.6%，由 Jeff 加 adapter 决定、只在不确定时交给 27B 的配置是 95.3%。每次决定耗时从 8.1 秒降到 0.25 秒，错误率从 13.4% 降到 4.7%，内存代价写成数字而不是形容：九个 adapter 全加载 +1.96 GB，即 28.6 GB 之上的 6.9%。第二张表把同样的对比按任务拆开——守卫 84.0% 到 98.0%、分诊 81.3% 到 91.0%、支持意图 86.0% 到 95.3%、工具选择 90.3% 到 98.0%、垃圾信息 88.0% 到 98.7%——而其中一行最值得看：依据核对从 96.7% 变成 96.3%，是唯一一项小模型没有更好的任务，说明原因的是旁边那列——1.7% 的查询被继续交了下去。

4. 04

   仓库里有什么，没有什么

   182 个文件里占主导的是媒体而不是代码：videos/ 24 个文件、58.8 MB，assets/previews 另占 2.9 MB，而 docs/data-sources.md 只有 7 KB，用来说明训练数据来自哪里。模型自身的大小在 README 里写成字节数——v1.2 基座 1,706,027,688 字节，合同条款 adapter 41,459,776 字节（权重加读出层）。视频、adapter 体积与数据规范合在一起，说明了仓库的形状是为谁准备的：展示 adapter 能做什么，以及告诉别人怎么自己做一套。