从「只做选择题」到删差评、筛电影、接管电脑：Jev 能力边界盘点，fast-jev-compaction 只用了 1%

从「只做选择题」到删差评、筛电影、接管电脑：Jev 能力边界盘点，fast-jev-compaction 只用了 1%

【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction

2026 年 9 月中旬，一家结束两年隐身期的初创公司 TypeSafe AI 在 Hacker News 上发布了一个「不生成一个字」的模型 Jev，单日冲到 1863 分、491 条评论。此后两周，围绕它的开源生态迅速膨胀到 28 个项目：有人拿它打宝可梦对战，有人让它接管浏览器，有人让它分类邮件、给商品打标、筛选电影，甚至有人让它「删差评」——这些玩法听起来一个比一个离谱，而其中真正拿到 4.7k star、被大量开发者装上生产环境反复验证的，是本文要拆解的 fast-jev-compaction：一个用 Jev 逐条决策替代 LLM 摘要、给 Claude Code 做上下文压缩的插件。

这个巧合很有信息量。Jev 的能力边界到底画在哪里？为什么「删差评、筛电影、接管电脑」这种热闹玩法，热度远不如一个老老实实做压缩的工具？本文结合社区实测与仓库源码，把 Jev 的玩法版图铺开，再回到 src/ 与 hooks/ 里逐行核对这个「爆款落地」到底做对了什么——以及它为何只算是 Jev 能力的一小角。

Jev 已公开的玩法版图：从上下文压缩到浏览器 Agent

先把 Jev 是什么说清楚。它不是「加了输出限制的 LLM」，而是一类新的模型形态：不生成文本，只对给定的问题输出带类型、带概率的答案。官方定义三种原语（primitives）：boolean（是/否，返回 P(true)）、choice（选哪个，返回全分布 + 置信度）、score（打几分，返回分数 + 分布）。一次请求里所有问题并行评估，官方实测 13 个问题合并成一次调用比拆 13 次便宜 11.5 倍、快 9.6 倍。名字取自《思考，快与慢》：LLM 是 System 2（慢、深、逐 token 推理），Jev 想做 System 1（快、直觉、直接给判断）。

过去两周社区用这套原语长出来的玩法，大致可以分成四类：

判断型 Agent 控制。最出圈的是 Browser Use 官方集成 jev-ultrafast：把浏览器的动作空间做成「操作 + 目标」两组 choice 问题，一次网络往返出两个决策，全程无截图，Google Flights 搜一趟苏黎世→伦敦机票只要 7.1 秒。官方 demo 还有用结构化游戏状态驱动 Doom，每秒问 10 次「往哪走、开不开枪」，成本约 $7/小时。HN 评论区为此吵了一架：「游戏 QA 要变天了」对阵「你们 reinvent 了外挂」。

内容分类与打分。删差评、筛电影属于这一类：把待处理内容丢进 state，问「这条评论该删吗」「这部电影打几分」，一次请求批量扫完，之后整张表可以直接用 SQL 查。这类玩法门槛最低，也最接近 Jev 的「语义列」定位——一句话个性化分类器、评论属性抽取、简历初筛都是同一路线。

模型路由与护栏。用 Jev 分类意图、估算难度，把简单请求路由给便宜模型、难的升级给贵模型；或者用它审 LLM 输出、查引用、测越狱。HN 上的共识是这类前置层能替掉 pipeline 里 40~70% 的 LLM 调用，是公认最稳的用法。

上下文压缩。也就是 fast-jev-compaction 所在的位置：不生成摘要，而是对整个会话历史里的每条工具调用逐条做「留不留」的二元判断。

这四类玩法的共同特征是：高频、窄域、可回退。它们都没有让模型「自由发挥」，而是把判断逻辑留在代码里，让模型只负责在封闭空间内给出带概率的选择。

fast-jev-compaction 为何出圈：决策模型的第一个爆款落地

在 Jev 的所有落地里，fast-jev-compaction 拿到的是最快的 star 增长曲线（发布当天即 1500+ 星，后续到 4.7k）。原因很朴素：它解决的是一个所有 Coding Agent 用户每天都会遇到的痛，而不是一个 demo 式的新奇场景。

痛点本身在 README.md 里说得很直白：传统上下文压缩是让 LLM 把旧对话「总结」成一段话。摘要是有损的——一个文件路径、一条精确报错、一个约束、一条命令，可能正好在关键时刻消失。fast-jev-compaction 的立场是：从不改写任何东西，只删除。用户和助手的文本保持原文、保持顺序，Jev 只对「这条工具调用还要不要、这条工具结果还要不要原文」做出判断。

这个思路在社区里被反复概括成一句话：把压缩从「生成题」变成「选择题」。CSDN 上多篇热评都抓住了同一个核心——「摒弃传统 LLM 有损摘要」「杜绝摘要式改写，确保用户/助手文本与保留内容零失真」。而这正是 Jev 这类决策模型唯一擅长的能力形态。

仓库源码把「选择题」做得相当扎实。整个压缩管线在 src/compact.ts 里清晰可见：

1. 配对：src/state.ts 的collectToolCalls用tool_use_id把每条tool_use和它的tool_result配对，第一条消息和最新preserveRecentMessages条消息里的调用被「钉住」（pinned），永不参与决策。
2. state 构建：发给 Jev 的 state 是完整对话（最旧在前），每条工具结果被替换成一行简短标注——ok, 4213 chars (omitted)，工具输入和文本全量保留，什么都不总结。
3. 两问一决策：对每条未钉住的调用，Jev 收到两个 noul 问题——call_t1（「知道这条调用发生过、带着它的输入，对后续还重要吗」）和result_t1（「这条调用的完整输出还需要原文保留吗」）。见 src/compact.ts 的questionsFor。
4. 阈值裁决：src/compact.ts 的decideCall按keepThreshold（默认 0.5）决定三种动作：keepResult ≥ 阈值→ 调用和结果都保留；否则keepCall ≥ 阈值→ 保留调用、结果截断到truncateHeadChars（默认 300 字符）加一行说明；否则调用连同结果一起删除。

关键在于第 5 步之后的重建（applyDecisions）：被判定删除的调用连结果一起消失，被截断的结果保留一个头部和说明——[fast-jev-compaction truncated 1700 chars of this tool result; re-run the tool if needed]，任何结果都不会脱离它的调用单独存在，未触碰的消息以原对象原样返回。

「1%」的说法也来自这里：Jev 官方能力远不止 noul 一种原语——choice 可以做浏览器动作选择、score 可以做内容打分——而 fast-jev-compaction 全程只用了一个 boolean 原语，把「判断」做得足够好。它验证的正是那句「带概率的智能 if 语句」：一个足够可靠、足够便宜的二元判断，就足以重构一个高频基础设施。

能力边界的本质：System-1 判断型任务的适用面

为什么 fast-jev-compaction 用 1% 的能力就立住了？因为它精准踩在 Jev 的能力边界之内。这个边界可以从两个维度刻画。

第一维度：任务的封闭性。Jev 的「零幻觉」是有严格适用范围的——它不可能输出选项集合之外的值，因为分布永远定义在你给的 criteria 上，这是数学保证；但它可以在选项之内高置信度地选错。所以它适合的是「判断有标准答案、错误可回退」的任务。上下文压缩恰好如此：删错了，助手随时可以重跑工具、重读文件。README 的 Limitations 部分白纸黑字写着：The assistant can always re-run the tool——这不是免责声明，而是这套方案的回退前提。

第二维度：任务的推理深度。社区泼冷水的实测给出了清晰的负样本。有人用德州扑克求解器做地面真值测了 150 个决策点：Jev 与最优解吻合率只有 63%，手持天顺时 16 次运行 16 次全下（正确动作是 check），而且置信度倒挂——错得最离谱的地方给出 0.86 的最高置信度。结论是：它没法从原始牌面自己推理出「我输了」，得有人把答案嚼碎喂到嘴边。迷宫单步也解不稳，推测训练分布里压根没有空间推理。换句话说，Jev 是「判断器」不是「推理器」——它不生成、不推理链、没有测试时计算，智能上限被锁在「非推理」水平。

把两个维度叠起来看，Jev 的能力边界就非常清晰：System-1 判断型任务——封闭选项、可回退、不需要从原始信息推出隐含结论。分类、打分、路由、护栏、压缩，全在这个象限里；扑克、迷宫、需要推理链的任何任务，都在边界之外。

fast-jev-compaction 的高明之处在于它甚至没有让 Jev 做「整段对话值不值得留」这种大判断，而是把它拆成每一条工具调用的小判断。compact函数里batchCalls把问题分批、Promise.all并发请求、答案合并——把「判断逻辑放在代码里而不是模型里」这个原则执行到了极致。这是 Jev 生态里公认的最佳实践：speculative fan-out（一次发全部问题）+ composite scoring（多个简单判断加权合成复杂判断），fast-jev-compaction 是 fan-out 的教科书级示范。

哪些「看着好玩」的应用其实不靠谱

Jev 的传播热度主要靠「好玩」，但好玩和靠谱之间隔着一条明确的线。把社区实测和源码对照着看，可以给三类热门玩法各贴一个结论。

「删差评」类内容审核——可用，但有校准前提。这类任务在 Jev 的适用象限内：封闭判断、可回退、标准相对明确。但社区实测反复强调一个前提：置信度是针对预测群体校准的，不保证单个答案正确。CSDN 的一篇热评也点出了同样的顾虑——「置信度不可控」正是传统 LLM 做压缩的老毛病，Jev 通过校准改善了它，但阈值必须在自己业务的数据上调。直接全自动删差评，是把「概率」当「证明」用。fast-jev-compaction 的处理方式值得抄作业：minReductionRatio默认 0.25，压缩收益不够就回退到内置摘要（见 hooks/fast-jev.ts 的register），Jev 失败、响应畸形、缺 key、历史装不进 state，全部走同一个 fallback 路径——这是「决策模型 + 确定性回退」的工程范式。

「接管电脑」类动作选择——方向对，但还远。Browser Use 官方集成证明了浏览器 Agent 的可行性（7.1 秒搜完机票），但注意它的实现细节：动作空间被做成 choice 问题，一次网络往返出两个决策，全程无截图。它把「看屏幕」这个感知问题整个绕过了——感知仍然在代码侧完成，Jev 只做动作选择。Doom demo 同理，游戏状态是代码喂进去的结构化数据，不是 Jev 自己「看」出来的。所以「接管电脑」的真相是：Jev 是动作选择器，不是环境理解器，真正的智能感知仍然要靠外部系统。任何宣传「Jev 自己看懂屏幕然后操作」的说法，都越过了实测边界。

「筛电影」类批量打分——性价比最高，但别当推荐系统。这类是 Jev 的甜点区：$0.042/百万 token 的输入价，扫库才扫得起；一个 score 原语，整张表几分钟几美元扫完。但同样有边界：它是「语义列」不是「推荐引擎」，打分标准完全由你的 criteria 定义，模型不会自己建立用户画像。HN 上那句总结很准确——它适合「大语料 map-reduce」，不适合需要推理链的个性化推荐。

最后回到那个 1%。fast-jev-compaction 的启示不在于 Jev 有多强，而在于一个 100ms、一厘钱的判断原语，如何重构了一个每天被上亿次执行的基础设施。它只用了 boolean 一个原语，就替代了 LLM 摘要式压缩——不是因为它聪明，而是因为「这个调用还要不要」恰好是 Jev 能给出可信答案的那类问题。判断型 AI 的工程化路径，从来不是让模型做更多，而是把任务拆到模型能可靠回答的最小粒度，再把回退逻辑写进代码。理解了这条线，你就能从「看着好玩」的 demo 里，分辨出哪些是真正的生产级落地。

【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction