这一周，TypeSafe 推出的决策模型 Jev ，仍在我的信息流里几乎是循环刷屏。浏览器自己丝滑点击，游戏自动操作，几百条数据几十秒跑完，Agent 自己挑 Skill，上下文一刀砍掉 99%。上一个这么热的是「小龙虾」，再往前是 Skill。

这让我有个错觉，好像所有的功能和场景，Jev 都能迅速的改天换地，尤其是被各种炫酷的效果视频洗脑后。

于是本着学习的态度，我去翻了社区里冒出来的一大堆项目，浏览器、手机操作、新闻筛选、语义搜索、Skill Router、上下文压缩、RAG、机器人、游戏、GEO、实体匹配，什么都有。

但，翻进代码、README 和测试方法以后，我的感觉反而复杂起来。有些项目一眼就能看出，场景天然适合 Jev。有些视频很丝滑，拆开一看，只是把一个写代码就能解决的问题改写成了 Choice。还有些数字漂亮得吓人，几十倍提速、99% Token 压缩，可要是不看测试条件，很容易把最好情况下的 Demo 当成普遍能力。

所以这篇我不做「Jev 项目大全」，案例已经够多了。我想把这些项目筛一遍，看看哪些真值得看，哪些主要是 Demo，哪些方向有机会进入真实的工程系统。

我的看法是，社区 Demo 很像卖家秀，负责告诉你这个东西最好的时候有多酷。工程系统要回答的是另一件事，碰到复杂页面、异常输入、错误状态、连跑几个小时，它还能不能稳定工作。如果一种能力真能包治百病，最有动力也最有能力把它产品化的，应该是 Codex、Claude Code、Cline、Browser Use 这些成熟工具。比起 GitHub 明天又多几个 Jev Demo，我更关心这些工具会不会把 Decision Model（决策模型）吸收成自己的内部组件。

带着这个初心，我扒拉了上百个项目，最后留下了 6 个案例。它们未必最强，但刚好代表 6 种完全不同的用法：

• Browser：最自然的 Jev 用法，也最容易被视频夸大
• NewsJack：高频批量判断为什么适合 Jev
• Semantic Grep：Jev 怎么变成一种「语义 if」
• Skill Router：Jev 开始钻进 Agent 的内部结构
• Context Compaction：那些夸张的性能数字该怎么看
• 2048：一个「能用，但未必该用」的反例

把这 6 个看明白，比再列 100 个仓库更能看清 Jev 的边界。

---

01 Browser：最顺理成章的 Jev 用法

如果只能拿一个案例给第一次接触 Jev 的人看，我会选 Browser。它算不上最炫，但几乎把 Jev 的设计意图写在了脸上。

Browser Agent 每走一步，表面上在操作网页，其实一直在回答同一个小问题：页面上摆着一堆能点、能输入、能选的东西，下一步选哪个？

传统做法是把截图或 DOM（网页的结构树）整个交给通用大模型，让它看页面、理解任务、思考、选动作、输出动作，一条龙包办。Jev Browser 把这一步拆开了。浏览器执行框架（Harness）先把页面整理成一张候选清单：

#12 input   Search#13 button  Submit#21 link    Releases...

再把任务和这张清单交给 Jev。Jev 不用描述网页，不用写计划，也不用解释理由，只回一组概率：

CLICK #21    0.96SCROLL       0.02DONE         0.01STUCK        0.01

代码执行 CLICK #21，页面变了，再来一轮。

公开的 jev-browser 已经能在真实网页上跑。作者贴过一段运行记录，从 Wikipedia 首页找到 Ristretto 词条，一共只调用了 3 次 Jev。还有项目直接把 Jev 塞进 Codex 或 Cline 的 Browser Skill，Jev 负责点，Codex 负责想和验证。

这个分工我觉得很值得琢磨。原本大模型一把梭的 Agent 循环，被拆成了三种活：开放式思考交给 LLM，有限的动作选择交给 Jev，确定的执行交给代码。

别被丝滑的 Browser Demo 带跑

这类视频也是现在最容易被选择性放大的。结构清楚、按钮语义明确、路径短的页面上，Jev 确实快得惊人。可真实网页远没这么规整。

一个完整的 Browser Agent 要经过感知页面、构造候选、决策、执行、验证结果这几段，Jev 只优化其中一格。页面理解错了，候选本身就是错的。点完没验证、出错不会恢复，Jev 选得再快也白搭。上图下面那一排动态渲染、Shadow DOM、Canvas、iframe、虚拟列表，卡住的全是候选构造那一段，跟 Jev 快不快关系不大。

所以很多视频展示的是「决策层很快」，观众记住的却是「Browser Agent 已经解决了」，这俩差得很远。我看这类 Demo 用一句话打底：Demo 展示最好的时候有多好，工程要回答最差的时候还能不能用。

Browser 在我这里证明的是另一件事，Agent 的很多步骤根本用不上开放式推理，只需要在已经列好的动作里快速挑一个。一个环境只要能被转成「观察 → 列候选 → 挑一个 → 执行」，就是 Jev 最舒服的那类场景。

---

02 NewsJack：判断数量一爆炸，生成式 LLM 就显得很重

Browser 是每一步做一个小决定。NewsJack 走到了另一个极端，一口气做成百上千个。

任务很实在：从当天的海量新闻里，给多个品牌找能借势的公关热点，顺手给新闻打上意图标签。拆开看，就是一个「新闻 × 品牌」的大矩阵。每一格只问两件事，这条新闻和这个品牌有关吗？有关的话，属于新品、竞品、行业趋势还是舆情风险？这正是 Jev 喜欢的问题形态。

梭哈.AI 公开过一个很有传播力的 Demo：428 条实时新闻，15 个品牌，Jev 大约 28 秒跑完，同一时间 DeepSeek V4.1-flash 只处理了 6 条。

这张对比图非常抓人，也最容易被读歪。只看它，很容易得出「Jev 比 DeepSeek 快几十倍，以后分类都换 Jev」，这个结论太粗了。

我更在意的是，两种模型在干完全不同的事。生成式 LLM 哪怕最后只需要回答「相关 / 不相关」，走的仍然是生成文本那条路。Jev 从一开始就只做判断。调用一次，差距也许没那么夸张。判断次数变成一百、一千、一万次，模型形态上的差距就被一层层放大。

它改变的也不止「一次 2 秒变成 300 毫秒」。以前因为太贵太慢，我根本不会让模型做 1 万次判断，现在这件事开始算得过账了。这比「快几十倍」重要得多。

428 条 28 秒是作者的演示数据，并发数、Prompt、API 限流、输出格式、准确率都会影响结果。但它准确展示了 Jev 最容易产生经济价值的一类活：大规模、重复、结构一致的语义判断。后来我筛案例一直带着这个问题，这个系统里有没有大量重复的小判断？至于它属于哪个行业，关系不大。

---

03 Semantic Grep：Jev 可能会变成一种新的 if

前两个案例还可以理解成「某个 AI 应用用了 Jev」。Semantic Grep 有意思的地方在于，它更像一个普通的软件能力，连 AI 产品都算不上。它想改造的是程序员用了几十年的 grep。

grep "timeout" system.log 回答的是哪些行里出现了 timeout 这个字符串。可我们翻日志、代码、文档的时候，想找的经常是一种意思：

找出所有「网络切换后请求失败」的日志找出「用户主动取消」的记录，排除系统异常退出找出「某个人在隐藏真实身份」的句子，哪怕原文根本没出现 hidden identity

这时关键词匹配就失灵了，Embedding（向量相似度搜索）也未必刚好等于我们心里那个判断逻辑。

Jev Semantic Grep 的做法很直接，把每一段文本变成一道 yes/no 判断题：

State:03-21 12:01:04 Network lost03-21 12:01:05 retry aborted03-21 12:01:06 request failedQuestion:这些内容是否描述了网络切换导致的请求失败？

Jev 返回一个概率，代码按阈值过滤。作者还把 AND / OR / NOT 也做了进去，原来只能写成一坨复杂规则的条件，现在用几句自然语言就能拼出来：包含网络异常，发生在网络切换之后，并且排除用户主动取消。

真有 10GB 日志的话，别天真地把每一行都扔给 Jev。更合理的形态是先用时间窗口、Tag、正则粗筛到几百行，再交给 Jev 判断语义，最后由代码做逻辑组合。

这个案例让我想到一个比「AI 搜索」更值得记住的词，语义 if。传统的 if 判断的是确定的变量：

if status_code == 500:

Jev 让程序开始能判断这种东西：

if 「这段内容看起来像服务异常」:

它是概率逻辑，阈值、兜底、人工复核一个都少不了。但我觉得这是 Jev 最容易被低估的方向。它不必活在 Agent 里，完全可以当一个普通的软件零件，硬编码规则表达不了某个语义条件时，用一次便宜的概率判断补上。它远没有 Browser Agent 炫，进入真实工程系统的可能性反而更大。

---

04 Skill Router：比「让 Jev 操作网页」更接近长期价值

如果 Browser 是最容易看懂的 Jev，Skill Router 就是我最想长期盯着的一类。它把 Jev 直接塞进了 Agent 自己的内部结构，没另起一个新应用。

2025 年聊 Agent，大家问的是它会不会调用工具。到了 2026 年，新问题越来越明显，工具、MCP、Skill 越装越多，它到底该调哪一个？

假设一个 Coding Agent 装了 100 个 Skill，用户说「帮我分析一下这个 Android crash」。最省事的办法是把 100 个 Skill 的说明全塞给主模型，让它自己挑。能用，但 Skill 越多上下文越大，主模型每一轮都在重复读一大堆元数据。Skill Router 的做法是先让 Jev 从候选里挑出 android-logcat，只加载这一个。

一个公开的 Jev Agent Skill Router 用 72 条合成请求做过测试，Jev 路由对了 68 条，词法匹配基线对了 51 条，也就是 94.4% 对 70.8%。

数字很好看。让我更愿意引用它的，反而是作者自己写在后面的说明：这是探索性测试，路由问题是看过早期结果后调整过的，数据被反复用于开发，94.4% 不能当生产准确率，概率值也没证明已经校准。这段说明比一张「准确率 94.4%」的宣传图有价值得多。

工程上真正要回答的，是另外一串问题。置信度低了怎么办？选不出来要不要同时加载几个 Skill？错选一个 Skill 代价多大？每条 prompt 都路由一次，还是每个 session 路由一次？

另一个 Skill Router 项目就在最后这个问题上改过设计。第一版每条 prompt 都重新路由，理论上更聪明，实际用起来很烦，后来改成每个 session 开头路由一次。Jev 不会替你解决产品问题，它只是一个决策零件。决策发生在哪、多久一次、置信度怎么用、谁拥有最终执行权，这些还得人来设计。

我看重这个方向，是因为 Jev 开始进入 Agent 运行框架的控制层了。它不负责生成最终答案，它在后台决定加载哪个 Skill、调哪个模型、保留哪段上下文、要不要升级给更强的模型、能不能继续执行。Agent 越复杂，越不可能让一个主模型同时扛推理、生成、路由、筛选、权限和上下文管理。这些小决定迟早会被拆出去，Jev 刚好就等在这个位置上。

---

05 Context Compaction：少用 99.3% 的 Token，能信吗？

前面几个案例，我基本在解释为什么这里适合 Jev。到了 Context Compaction，我更想先问一句，这个数字到底能不能信？它是我看到最诱人的 Jev 案例之一，也是我最不愿意照单全收的一个。

一个叫 jevskill 的项目，在大模型读上下文之前先让 Jev 做一轮语义筛选。比如 Coding Agent 排查问题，手里可能有两万 token 的日志，外加服务定义、YAML、历史输出、搜索结果、工具返回，真正有用的也许就几十行。

作者公开的一个例子里，20,542 个 token 被筛到只剩 111 个，主模型照样找到了那个写错的 image tag。整轮 A/B 测试下来，输入 token 少了 99.3%，任务答对 18/18，喂完整上下文的对照组只有 15/18。

漂亮到必须警惕。上下文能砍多少，高度取决于任务本身。一个两万 token 的文件，如果答案本来就只在 10 行里，砍掉 99% 一点也不奇怪。难的是另一个问题，它删掉的东西真的永远不重要吗？

主模型看到太多上下文，最多是贵、慢、注意力被稀释。前置过滤器要是把关键证据删了，主模型连判断错的机会都没有。所以这类方案最大的风险是漏召回（false negative）。

有意思的是，这个项目自己留下过失败记录。早期一个 YAML 配置漂移测试里，Jev 0/3，脚本规则 3/3。复盘发现问题出在判断单元切错了。原问题要比较「prod 的值和默认值是否不同」，这是跨行比较，测试却把每一行单独交给 Jev，它根本拿不到完成判断需要的信息。

这个失败在我看来比 99.3% 更重要。它暴露了 Jev 编程里最核心的一件事：你怎么切决策单元（decision unit），直接决定了模型有没有可能答对。

Context Compaction 很可能是 Jev 最有商业价值的方向之一，难点在于证明被删掉的内容真的不重要。能上生产的系统，至少得有兜底、可回滚、可观测、用真实数据做的评测，外加专门盯漏召回的监控。否则很可能 Token 是省下来了，证据也一起删没了。

---

06 2048：Jev 连游戏都能玩，但这说明不了多少

前面几个都在回答 Jev 哪里有价值，最后这个我想反过来问，什么问题看起来特别适合 Jev，实际上却未必值得用？

Jev 玩 2048 是很好传播的 Demo。输入棋盘，下一步只有上下左右四个选项，Jev 每一轮给出一组概率，比如向左 0.73，代码执行，拿到新棋盘，接着判断。从接口形态看，简直是为 Jev 量身定做的。

我一开始也觉得它很典型。可把 2048 的规则拆开以后，结论反过来了。2048 是确定性游戏，给定当前棋盘，程序可以直接算出往四个方向走之后分别是什么样，还能继续往后搜，用启发式算法、Expectimax 这类传统方法评估后面的局面。这里找不到任何难以编码的语义。

代码本来就能精确、便宜地算出来，为什么还要让模型去猜？

这是 Jev 火了以后最容易出现的误区，万物皆可 Choice。游戏下一步、数据库策略、路径规划、算法分支，技术上都能写成 Choice，可能写成 Choice 和该交给 Jev 是两码事。我现在会先问一句，这里缺的是语义判断，还是只是计算？是后者的话，代码通常更便宜、更稳，也更好验证。

还有个细节要交代。这个 2048 Demo 来自 LogJev，它底层用的是支持 top_logprobs 的普通 LLM，在外面封装出类似 Jev 的 choice / score / noul 接口，和 TypeSafe 官方的 Jev 没有关系。拿它当 Decision Model 编程思想的教学 Demo 很合适，拿来证明 Jev 性能就不合适了。

---

看懂这 6 个，剩下上百个项目就好归类了

社区 Demo 很有价值，它们在替大家试边界：Jev 能不能控制浏览器，能不能玩游戏，能不能做语义筛选和路由，能不能上手机和机器人。

现在回头看那些五花八门的项目，Computer Use、Mobile Use、Voice Agent、GEO、实体匹配、RAG 证据过滤、聊天审核、马里奥、Doom、地铁跑酷、无人机、机器人，我发现根本不用按行业去理解它们。该看的是软件内部那个判断长什么样。我自己用两个维度，答案空间有多封闭，这个判断发生得有多频繁。

越靠近高频、答案有限、又需要一点语义理解，越像 Jev 的甜点区。拿这张图去套，很多项目就好判断了：

项目类型	Jev 真正在做什么	我的判断
Computer / Mobile Use	从当前界面的候选里选动作	Browser 的自然延伸，上限取决于 Harness
GEO / 品牌提及	判断品牌有没有被提到、相不相关	很典型的批量判断
实体匹配	两条记录是不是同一个实体	规则难写死、答案封闭，很适合
RAG 证据过滤	检索结果是否真的支持当前问题	有价值，但漏召回必须测
内容审核	内容是否违规或负面	吞吐有优势，高风险场景不能只看速度
Doom / 马里奥等游戏	从有限动作里选下一步	好玩，先问问传统算法是不是更合适
机器人 / 无人机	选动作，或决定是否升级给大模型	研究价值高，放进真实环境验证难得多

---

要不要用 Jev，只问 4 个问题

翻完这些项目，我觉得最值得留下的，是一套很简单的判断方法。某个仓库、某个 benchmark，过两个月可能就没人记得了。

答案能不能提前列出来？

连候选答案是什么都不知道，那更像开放问题，交给 LLM 去探索。候选早就明确，比如继续还是停止、保留还是丢弃、用 Skill A 还是 Skill B，Jev 才开始有意义。

这里真的需要语义理解吗？

这是很多 Demo 最容易跳过的一问。if x > 10 能解决的，就别上模型。传统算法能精确求解的，也别因为 Jev 能 Choice 就硬改成模型。Jev 该填的，是代码很难写死的那一段。

这个判断会不会发生很多次？

Jev 的优势很少在一次调用里完全体现。一次省 1 秒无所谓，一天要判断 10 万次，成本、吞吐和延迟就开始影响架构了。NewsJack、Semantic Grep、Browser 循环都属于这种。

判错了有没有兜底？

这一条经常比准确率更重要。置信度低于阈值时，要能交给更强的模型、规则或者人工复核，别搞成 Jev 说什么就执行什么。碰上权限、删除、财务、安全这类高风险操作更是如此。Jev 待在判断层就好，别让它自动拥有无限的执行权。

四个问题压成一句话：代码写不死，大模型又太重，这件事一天还要判断很多次，这时候才适合 Jev。

---

想试 Jev，先别急着做一个「Jev 项目」

看完这些 Demo，很容易手痒，也想做个 Browser、做个小游戏、做个邮件分类器。TypeSafe 官方提供的 Agent Skill 给了一个更实在的起点。

这个 Skill 可以装进 Claude Code、Codex 这类 Coding Agent。它装进去的其实是一本 Jev 编程手册，告诉 Agent 什么问题适合 Choice、什么适合 Score、什么适合 Noul，State 怎么组织，阈值怎么设，哪些脆弱的规则值得换成 Jev 试试。

官方直接给了一句起手 Prompt，可以原样抄：

Using the TypeSafe skill, explore the project and find opportunitiesfor using intelligent judgement to stand in for complex parsingor other fragile code.

翻成大白话：把我的项目扫一遍，找出那些代码很难写稳、其实只是在做判断的地方。

我觉得这比重新做一个 Demo 有意义得多。Jev 真正值钱的位置，可能早就藏在你的项目里了：十几条正则拼起来的分类器，越写越长的路由 if/else，主模型每一轮都在重复做的小判断，搜完还得人工筛一大堆噪声的环节，为了「判断一下」就调一次完整 LLM 的地方。

我自己要试 Jev 的话，会先问一句：我现在的软件里，哪里正在为一个小判断付出大模型的成本？

---

最后

上一篇回答的是 Jev 是什么。这一篇让我重新想清楚的，是 Jev 应该放在哪。

刚看到 Jev，很容易只记住快和便宜。再看一批社区项目，又容易走到另一头，觉得什么都能 Jev 化。项目看得越多，我越不信「什么都能用」这种结论。我更关心的是，哪些地方用了 Jev 以后，软件的分工真的变合理了。

Browser 算，动作候选天然有限。NewsJack 算，它要做海量重复判断。Semantic Grep 算，它补上了硬规则和自然语言之间的空白。Skill Router 大概率算，Agent 的控制层正在变得越来越复杂。Context Compaction 值得期待，前提是证明删掉的东西真的不重要。2048 则提醒我，能做和值得做是两回事。

这几个案例压到最后，反复出现的是同一个结构：代码定义候选的边界，Jev 做判断，代码再去执行、路由或过滤。软件里有些判断该交给代码，有些需要 LLM 去探索和生成，中间还有一大块，代码写不死，答案又不开放。Jev 盯上的，就是这块过去经常被大模型顺手包掉的中间地带。

社区还能做出多少炫酷 Demo，我倒没那么在意了。接下来我最想看的，是主流 AI 工具会不会悄悄把它吸收进内部架构。哪天 Skill 路由、浏览器动作选择、上下文过滤、模型路由这些能力不再顶着「Jev Demo」的名义单独出现，变成 Codex、Claude Code、Cline 里一个普通的内部组件，那时候 Jev 才算从一个很火的新模型，变成了一层新的 AI 基础设施。

在那之前，我打算先拿那四个问题，去翻翻自己项目里那些越写越长的 if/else。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】