Jev AI

JEV 项目

302
条记录
227
个代码仓库
75
篇实践记录

这里每个 Jev 项目都把 Jev 用在一个真实的类型化判断上——路由、打分、校验、防护栏。但并非全是代码，「类型」那一列会告诉你哪个是哪个。

302 / 302

发布一周之内，Jev 项目的生态从零涨到几百条，而且涨出了一个很特别的形状：几乎没人做 Jev 产品，大家做的都是层。一个 Jev 项目把 API 包成某种语言的 SDK；一个 Jev 项目把 Jev 的判断暴露成 MCP 工具；一个 Jev 项目往一个本来就存在的 agent 循环里塞了一次 Jev 调用。

对于一个自己什么都干不了的模型来说，这正是应有的样子。一个 Jev 项目几乎总是 Jev 和别的什么之间的一段管道——浏览器 agent、编程 harness、RAG 管道、交易策略、游戏循环。关于任何一个 Jev 项目，真正有意思的问题不是「它是什么」，而是「它决定把一次判断放在别人系统的哪个位置」。

这份 JEV 项目索引怎么读

并非每一条都是代码

上游列表把代码仓库和 X 讨论串、博客文章、在线演示混在一起。这是他们有意为之——一篇有据可查的实践也是证据——但这意味着某一行 Jev 项目可能是一篇文章。「类型」列把 REPO、PACKAGE、WRITE-UP、SITE 分开，你点进去之前就知道。

被收录不等于被背书

上游只做收录规则：公开、可引用、确实把 Jev 用在类型化判断上。没有人审查过这里任何一个 Jev 项目的代码质量、安全性，甚至跑不跑得起来。有好几批同一天批量提交的条目共用同一套脚手架、提交历史也很薄。

决策类型是推断出来的

当一个 Jev 项目的一句话描述能看出提问类型时，我们标 CHOICE、SCORE 或 NOUL；看不出就留空，不猜。大约五分之二的条目属于后者。

分类沿用上游

分类体系是上游自己的，每个 Jev 项目按其直接应用领域归入且仅归入一个。其中「科学流水线」这一类确实是空的，我们照实显示，而不是把它藏起来。

JEV 项目的聚集告诉了你什么

最大的一簇遥遥领先，是基础设施：SDK 封装、网关适配、MCP server、评测脚手架。这是「大家想在已有系统里试一下，而不是围着它重建一个系统」的典型特征。如果你刚开始，先看这里——针对你这套技术栈的适配器，多半已经有人写好了。

第二簇是 agent 决策，这一簇最能解释 Jev 为什么被采纳得这么快。一个每次点击都调前沿模型的浏览器 agent，又慢又贵；一个把每步判断换到 Jev 上、只在必须打字时才叫大模型的 Jev 项目，两边都能拿到一个数量级。同样的替换也出现在编程 agent、桌面自动化和机器人里。

接下来是校验与防护栏，这里才是校准真正挣到钱的地方。这一簇里的 Jev 项目通常是一道闸门：判断这次工具调用会不会造成破坏、这个「做完了」的声明诚不诚实、这个召回段落支不支撑论断、生成的答案引的是不是它说的那篇。这些都是带阈值的 Noul，也是把 Jev 放进一个已经能跑的系统里风险最低的方式。

长尾——金融、游戏、内容审核、数据标注、合规——条目更少但更有意思，因为每一条都是某个人发现：自己那个领域其实充满了有界判断，只是过去单次成本算不过账，所以从没人自动化过。

挑一个 JEV 项目作为起点

如果你想直接调 Jev，从官方 SDK 开始，跳过各种封装。Python 包是 typesafe-sdk，JavaScript 是 @typesafe-ai/sdk，两个都很薄；索引里大部分做封装的 Jev 项目，存在的意义是把它们桥接进某个具体框架，而不是在它们之上做改进。

如果你已经在跑 agent，去找 MCP server 那几个。有好几个 Jev 项目把 Choice、Score、Noul 暴露成 Claude Code、Codex 这类 harness 能直接调用的工具，意味着你可以在一个危险动作前面加一道 Jev 判断，而完全不用写集成代码。

如果你想先看清形态再决定，找一个小的从头读到尾。防护栏和上下文裁剪这类 Jev 项目通常就几百行，因为有意思的部分是提问设计而不是管道。这是理解「一个好的 Jev 提问长什么样」最快的路。

而如果你还在评估 Jev 到底合不合适，决策模式页面比任何单个 Jev 项目都更适合当起点——它把十一种反复出现的形态的 state、提问和路由策略都写出来了，没有别人代码库的噪音。

这些 JEV 项目数据从哪来

索引里的每个 Jev 项目都来自社区的 awesome-jev 列表，MIT 许可，维护者不是我们。我们解析他们的分类文件、按 URL 去重、把每条归为代码或实践记录、在描述允许时推断决策类型，然后直接链回原始出处。

我们不添加自己的描述。每一行 Jev 项目上的那句话都是上游维护者写的——把别人的摘要改写一遍让它听起来像我们的，既不诚实，效果也更差。

JEV 项目常见问题

一共有多少个 Jev 项目？
这份索引收录 302 条：227 个代码仓库或包，75 篇实践记录，分布在 14 个确实有内容的分类里。
这些 Jev 项目都能上生产吗？
不能，而且没人检查过。上游只做收录规则——公开、可引用、确实用了 Jev——并且明确警告有好几批同一天批量提交的条目共用脚手架、提交历史很薄。把「被收录」当成一个指路牌，不是推荐。
为什么有些 Jev 项目不在 GitHub 上？
因为大约四分之一的条目不是代码。上游列表把 X 讨论串、博客文章和在线演示也作为实践信号收录。「类型」列会把它们标成 WRITE-UP 或 SITE，你可以据此筛掉。
我的 Jev 项目怎么被收录？
去上游 awesome-jev 列表提交。这份索引从那个列表构建，那边通过了，下次构建这边就会出现。
该先读哪个 Jev 项目？
挑一个小的防护栏或上下文裁剪项目。它们通常就几百行，而且几乎全是提问设计而不是管道——这部分才是能迁移到你自己东西上的。
做 Jev 项目一定要用官方 SDK 吗？
不用。Jev 可以用裸 HTTP 调，索引里有好几条就是这么干的。SDK 主要是省掉你自己写重试和 schema 代码的功夫。