大家拿 Jev 做了什么：从语义搜索到游戏 NPC

9 月 20 日至 21 日出现的一批 Jev 项目，已经不太像同一种“AI 应用”。有人拿它找网页原句，有人让它给代码审查分流，也有人把它接进 Home Assistant、销售通话和 Minecraft。共同点不在界面，而在 Jev 所处的位置：它通常接收已经整理好的文字或结构化状态，从有限候选里作选择、打分或判断，再由普通程序执行。

这 24 个案例取自 2026 年 9 月 20—21 日的公开项目动态，有已接入产品的功能，也有仍在开发的工具和演示；它们并非都在这两天首次发布。许多周边项目开放了代码，这与 Jev 模型本身开源是两回事。

先找，不急着生成

最顺手的一组用法，是从已有内容中找出“意思对”的那一项。

Needle 把这个思路做成了 Chrome 扩展和 React 应用。用户不必猜页面用了哪个关键词，可以问“取消后会怎样”；应用把网页或粘贴文本切成候选句，让 Jev 选择和打分，再回到原文高亮。它不另写一段答案，读者看到的仍是来源原句。对政策页、帮助中心和长文来说，这比“生成一份摘要”更容易核对。

JevGrep 把同一模式搬到代码库。问题可以是“会话过期在哪里处理”，返回的是文件路径、行号和源码片段，而不是生成的代码解释。它适合不知道符号名时按行为找实现；如果已经知道函数名或字面量，README 也明确建议先用普通文本搜索。代价同样清楚：搜索时，符合范围的源码片段会发给远程模型，使用者需要先检查排除项和代码隐私。

数据库里的做法更直接。MySQL AILIKE 让 SQL 的 WHERE 或 JOIN 包含自然语言比较，例如判断一行商品描述是否满足条件、两段描述是否匹配。每个未缓存的比较都可能触发远程调用，所以项目作者建议先用普通 SQL 缩小候选，而不是让语义判断扫描整张大表。

类似结构还出现在几个短小但具体的项目里：Zillow 自然语言筛选演示 用“建筑风格”“是否翻新”等传统筛选器没有的描述找房源；Hazumi 从很长的 Hacker News 讨论里挑评论；LikeThisGame 先在同类游戏池里排序候选，再交给生成模型写推荐理由。后者作者称已用于网站周更，但流程同时改了召回、排序和热门惩罚，不能把效果全部归给 Jev。

这组项目提供了一个可复用的产品结构：候选先存在，Jev 负责缩小范围，界面保留原始证据。 当错误不可避免时，能回到原句、源码或原始记录，通常比得到一段流畅但无法定位来源的解释更实用。

这类产品也有一条很实际的上限：候选集中没有答案，后面的判断再快也找不到。做原型时应把“召回漏了”和“Jev 选错了”分开记录。Needle 要先正确取得页面文字，JevGrep 要先把相关文件纳入扫描范围，MySQL AILIKE 则要先用确定条件缩小行数。评测也不该只看最终命中率；候选覆盖率、前几名是否含正确项、单次筛选要发送多少材料，以及错误结果能否让用户回到来源，分别对应不同的改进手段。搜索层缺候选时，换一个判断模型并不能修复问题。

把 Agent 前后两端拆开

第二组项目没有让 Jev 充当主 agent，而是把它放在执行前后。

执行前，GPT-Load Auto Model 根据任务选择模型档位和思考强度，并记录路由耗时与费用。它已经接入 GPT-Load，但作者把它标成实验性功能，也直说选档准确度还需要调教，而且多一次判断就多一段延迟。这里的价值不是“自动选最强模型”，而是让不同任务有机会走不同预算和延迟路径，同时把路由结果留下来复盘。

JCR 处理的是另一种前置成本。它在嵌套的能力目录里寻找当前任务需要的命令说明，把相关上下文交还给 agent。JCR 返回文档，不替 agent 执行命令。这个区分很重要：它减少的是寻找工具说明时带入主上下文的材料，实际操作仍由原来的 agent 和工具完成。

代码工作流里，CodeSafe 把项目规范写进 YAML，检查代码改动和提交信息；jev-auto-approve 分别判断 PR 是否可合并、是否有测试、是否需要人工，再决定是否批准；JevPR 接收 PR webhook，把改动分到低风险、常规或专家审查。后两者是 GitHub Action 或开发中的 GitHub App。概率、分流和审批规则能帮助安排审查队列，但都不能证明代码正确，更不应替代必要的人工责任。

执行后，评测工具把一条 agent 轨迹拆成较窄的问题。Typed Evals 面向 LLM、RAG 和工具调用轨迹，并支持用人工标签校准指标；jevals 一次检查工具选择、证据支持、范围遵守和安全风险。jevals 也支持其他后端，所以不能把它的全部运行都算成 Jev 使用。

更值得记住的是反例。TrueStandard 原本想在事实核验流水线前先筛掉不需要处理的句子。简化实验里，成本下降了 26%；放回真实流水线后只有 1.7%，小于同一方案重复运行约 2% 的波动。于是，分流组件虽然做出来了，生产开关仍保持关闭。真正保留下来的是另一段：抓取引文页面后，判断来源是否支持具体主张，并显示概率。作者把这称为端到端接线可行的证明，而不是准确率结论。

这个案例比漂亮的单价对比更有用。模型调用便宜，不等于整个产品会省钱；已有流水线可能早就用更便宜的方式完成了同一步。新组件要和真实基线比较，而不是和一个刻意简化的对照比较。

Agent 的长期上下文也被拆成了筛选问题。PerfectRecall 让 Jev 逐条判断合格记忆是否相关，再把原始证据交回 Hermes；仓库中的提升数字来自冻结的前身版本，不是当前重命名包的新验证。Jev Turn Analysis 则分析 Claude Code 或 Codex 会话中的卡点和浪费，Jev 做评分，最后的改进报告仍依赖其他 agent CLI。这两项都没有让 Jev“记住一切”或直接写复盘，而是先决定哪些旧材料值得进入下一步。

把这些工具画成一条链，会得到三个不同的控制点：路由器在任务开始前决定走哪条路，审查器在动作发生前决定是否放行，评测器在完成后判断结果是否合格。三者的错误成本并不一样。模型路由选错，可能增加费用或降低答案质量；自动批准选错，可能把风险改动送进主分支；离线评测选错，首先污染的是统计与后续调参。相同的判断接口不能自动带来相同的阈值。越靠近不可逆执行，越需要确定规则、人工确认和可恢复的回退路径。

实时产品里，先看数据是怎么来的

Call Coach 是一个在制的销售通话演示。浏览器先做 speech-to-text；每出现一句转写，服务端把文本发给 Jev，得到下一步动作、购买阶段和若干信号，界面再结合本地的平滑、稳定与阈值逻辑显示建议和置信度。Jev 没有直接听音频，项目也没有证明能提高成交率。

Home Assistant TypeSafe 同时评估用户意图和设备候选，高置信度时调用 Home Assistant 原生 intent，低置信度或超出范围时交给备用会话 agent。设备发现、权限和实际控制仍由 Home Assistant 负责；Jev 做的是意图与候选的结构化选择。仓库提供了集成代码，但本次调查没有在真实家庭环境里启动它。

朗读训练原型大声读 也先由 ASR 转写，再判断目标词是否对应、属于哪类错误、是否有语义偏差。它不做声学发音、重音或口音评分。Drape 虚拟试穿演示 根据转写和当前穿搭，从衣橱候选中选衣服，试穿图由系统的其他部分处理。语音和图像在这些产品里很显眼，但不能因此说 Jev 原生处理音频或生成图像。

四个案例共同提醒了一件小事：画系统图时，不要把一整条箭头都标成“AI”。ASR、候选召回、Jev 判断、阈值回退、Home Assistant 或前端执行，各自负责不同环节。只有把它们拆开，才知道慢在哪里、错在哪里，以及哪一段值得换模型。

实时界面还要处理“上一秒的判断是否仍然有效”。Call Coach 的仓库把平滑、迟滞和最低置信度放在本地逻辑里，就是因为逐句结果不能直接等同于稳定建议。智能家居则更敏感：设备名称相近、用户话没说完或请求超出已暴露设备，都可能让候选发生变化。一个实用界面应让用户看见系统准备做什么，并在低置信度时追问，而不是用速度掩盖不确定性。这里是产品设计原则，不是这些项目已经通过真实环境可靠性验证的结论。

游戏和仿真：Jev 选动作，环境执行动作

Astra + Jev Minecraft agent 把规划和动作选择分开：Astra 或另一规划模型提出目标，Jev 从玩家动作中选择，Mineflayer 再通过游戏接口执行。仓库描述了过关过程和检查，但调查时录像与生成日志没有随仓库公开，因此不能独立复核作者报告的速度。它展示的是一种受游戏接口约束的控制循环，不是对开放世界可靠性的概括。

JevUnreal 更像游戏开发积木。Unreal Engine 5.8 的 Blueprint 节点把游戏状态和问题发出，返回 Yes/No、选项或概率；Blueprint 决定 NPC 是否撤退、该说哪句对话，或是否调整难度。插件仍在开发中，示例也在整理。Jev 返回决定，真正改变游戏状态的是开发者写的 Blueprint 逻辑。

机器人演示的边界更要收紧。EmbodiedJev 在 MuJoCo 工作台里展示抓取、堆叠和越障的“观察—判断—动作”；RoboJEV 先选即时意图，再选 XYZ 方向和夹爪动作，最后由物理控制器执行。两者都是仿真项目，后者给 Jev 的还是结构化状态。它们不能证明模型原生看图，也不能替代实物机械臂的安全与可靠性测试。

游戏是很合适的试验场，因为状态、合法动作和失败结果都容易记录，动作也常能重放。但“能在规则明确的环境里选动作”与“能自己理解任意画面并安全行动”之间隔着感知、状态估计、执行控制和异常恢复。把这些层写进日志，才能知道一次失败究竟来自规划目标、Jev 选择、游戏接口，还是物理控制器。

从这些项目还能长出什么产品

下面是基于现有结构提出的产品假设，不是已经存在的 Jev 功能，也不是上述项目的路线图。

一是“带证据的工作记录搜索”。 把 Needle 的原文高亮和 PerfectRecall 的原始证据结合起来，用于个人待办、客服记录或研究笔记：用户问“哪些问题反复拖延”，系统只返回原记录及发生时间。先把候选限制在用户已有资料，再测召回率和误报，不急着生成总结。

二是移动端的低风险意图层。 参考 Home Assistant，把“打开哪个页面、使用哪个本地动作、是否需要追问”做成有限选择；低置信度一律停下或回退。它不应直接获得无限操作权。可先从可撤销动作开始，记录每次候选、判断、阈值和最终执行结果。

三是实时转写后的教练，而不是实时监听模型。 Call Coach 和大声读都说明，可以先用成熟 ASR 得到文字，再让判断模型处理很窄的问题。新的产品可以针对客服话术遗漏、访谈提问覆盖或朗读词义偏差，但必须分别评估转写错误和判断错误，不能把两者混成一个“AI 准确率”。

四是游戏中的可审计 NPC 决策。 候选动作由游戏规则给出，Jev 只排序或选择，设计师保留硬约束和回退。日志记录当时状态、候选、概率与最终动作，方便重放。这个提案借鉴 JevUnreal 和 Minecraft agent，但并不表示它们已经提供完整的制作管线。

一个两周内能结束的试点

别从“把 Jev 接进所有流程”开始。选一个每天都会发生、答案空间有限、结果可回看的判断，例如从 20 条工单中筛出需要升级的 3 条，或者给代码审查选择普通队列与专家队列。

先保存现有流程一周的基线：人工结果、处理时间、下游费用和返工。接着固定候选与问题格式，让 Jev 只负责判断，不直接执行不可撤销动作。设定置信度阈值和回退；日志至少保留输入摘要或可追溯 ID、候选、输出、概率、耗时、费用、人工改判和最终结果。最后同时看质量与整条链路成本。若收益落在正常波动里，就像 TrueStandard 那样关掉它；若只在某一类任务有效，就只保留那一段。

试点开始前还要写清停止条件。比如，漏掉高风险工单即暂停自动分流；人工改判率连续高于团队能接受的范围，就退回只提示不执行；发送给远程服务的数据超出既定字段，也应立即停用。数值阈值要由具体业务确定，不能从这些演示里抄一个通用答案。测试集则应保留正常样本、边界样本和明确无答案的样本，避免系统只会在“候选里必有正确项”的理想条件下工作。

上线判断也不要只比较模型单价。把候选准备、网络等待、失败重试、人工复核、下游生成和返工都算进来，再和旧流程比较。TrueStandard 的结果之所以有参考价值，正是因为它把组件放回了真实流水线。若一个判断很便宜，却让每位用户多等一次网络往返，或让审核者花更多时间解释误判，它依然可能不值得保留。

评审时问六个问题就够：候选是否完整，Jev 是否只看到了它该看的数据，错误能否回退，执行者是谁，日志能否复盘，真实基线是否改善。Needle 的原句、JevGrep 的源码、Home Assistant 的原生 intent、Minecraft 的游戏接口，看起来分属不同产品，却都把“判断”和“执行”切开了。

这 24 个案例里，最可靠的启发不是某个演示速度，而是一种朴素的工程取舍：先把问题压缩成可检查的选择，再决定这个选择值不值得上线。TrueStandard 留下了来源支持检查，关掉了没测出收益的分流组件。一个试点能得出同样清楚的“不开”，也算完成了任务。