企业官网建设流程全解析

Jev 刷屏一周全网对撕，靠它搜代码的 jevgrep 还能不能信

【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrep

2026 年 9 月中旬，一个"不会说话"的模型 Jev 以极快的速度席卷了开发者社区：9 月 15 日发布，三天内在 Hacker News 冲到 1863 分、491 条评论，Vercel 第二天接入 AI Gateway，Netlify 紧随其后，上线 24 小时接近 13% 的付费团队开始调用，是之前任何一次模型发布首日的两倍多。与此同时，中文社区也分成了旗帜鲜明的两派：一派晒毫秒级决策与成本账本，一派直呼"别吹了"。这场对撕的中央，恰好躺着一个把 Jev 用在代码搜索上的开源项目 jevgrep（仓库名 dzhng/jevgrep，CLI 为jg）。本文结合社区两派的核心论点，逐条对照 jevgrep 仓库的真实源码与评估记录，试图回答一个更具体的问题：当 Jev 被拿来搜代码时，它到底是真工具还是又一个 Demo？

吹的一方：毫秒级决策与成本数字

吹 Jev 的人给出的理由高度一致：贵和慢这两个 AI 应用的痛点，它恰好都治。

先看它是什么。TypeSafe AI 由前 OpenAI InstructGPT 核心作者 Diogo Almeida 创立，隐身两年后带着 4000 万美元种子轮（DCVC 领投）亮相。它发布的 Jev 被官方称为 "System One" 模型：不生成文本，你给它一段内容（state）和一组带固定选项的问题，它直接返回每个选项的概率。输入价格 0.042 美元/百万 token，输出免费，端到端延迟 70~500 毫秒。社区实测的论据则更有画面感：单次判断多数在 100 毫秒上下，而人眨一次眼要 200~300 毫秒；给 Codex 配上 Jev 做意图路由，一次Choice调用返回web_search: 0.99的置信度，495 个输入 token、63 个输出 token，全程一次 HTTP 往返。

这套"判断和执行分离"的叙事落到 jevgrep 上，变成了可量化的工程账。jevgrep 的核心定位是"Find code by asking what it does"——让 coding agent 用自然语言问"仓库里这段行为是怎么实现的"，而不是靠关键词瞎猜。仓库 README 的主图直接把这笔账印在了封面上：

数字从哪来？评估记录里写得非常具体：在冻结的已安装包 + 公开 skill 的固定十任务 SWE-bench Python 子集上，引入 jevgrep 后主模型 Sol 的成本从7.62 美元降到 5.44 美元，降幅28.63%，四舍五入成宣传口径的 ~30%，且双方同样解出 8/10 个任务。后续的 0.4.3 总成本复跑把 Jev 本身的费用也算进总分账：8/10 不变，全任务成本 5.6564 美元对比基线 7.6221 美元，含 Jev 的总成本仍低 25.8%。再后来的 0.5.0 评估则在保住 8/10 的前提下把原生 Jev 成本又压低了约 59%。

速度账也在：speed-2026-09-28.md记录了同一查询下原生 TypeSafe 端点中位延迟140ms对比 Vercel Gateway 的 330ms，整轮十任务比上一代 jevgrep 快 29.16%，比无 Jev 基线快 12.70% 且 Sol token 少用 41.51%。"毫秒级判断 + 约三成成本削减"——这就是吹的一派手里最硬的两张牌。

黑的一方：路线炒作与商业化隐忧

黑 Jev 的一派同样有理有据，火力集中在三点：能力水分、护城河、商业化。

"别吹 Jev 了"是最有代表性的檄文：它"本质上就是一个 JSON 分类器套了层前沿模型的皮"，能力上和 DeepSeek Flash 打平，"不会幻觉"是重新定义出来的——OpenAI 的结构化输出、Anthropic 的 tool use 早就实现了同样的约束；护城河 48 小时就塌了，有人两小时拿 Qwen 搓出同款，400M 参数的开源 laya 基本是同款。结论是：能被两小时复现的东西是工程技巧，不是模型突破；当止痛药可以，当主力出活不行。

另一篇"把源码和黑料都扒了一遍"的深度调研则用实测数据补刀：用德州扑克求解器当地面真值测 150 个决策点，Jev 与最优解的吻合率只有63%；手持天顺（怎么打都不会输的牌）时 16 次运行 16 次全下；最扎心的是置信度倒挂——在它错得最离谱的地方给出最高置信度 0.86，在它最接近正确的地方反而只有 0.09，而且错误高度可复现，是系统性偏差而非噪声。加上它没有思维链、没有测试时计算，智能上限被锁死在"非推理 LLM"水平，官方宣称的 193.6 倍快、444.6 倍便宜全是自报数据，截至发文仍无独立复现。这套"判断模型能不能信"的拷问，正是标题里"还能不能信"的由来。

那么，把 Jev 用在代码搜索上，是不是就把这些雷全部踩中了？要回答这个问题，必须进仓库看实现。

落到 jevgrep：搜索是判断模型最扎实的应用吗

先说结论方向：搜索恰好是判断模型最贴合的应用形态之一，但前提是把它当"概率证据源"用，而不是当"决策引擎"用。这从 jevgrep 的架构就能看出来。

判断模型与搜索的"接口对齐"

搜索天然是一个"判断题密集型"任务。传统 grep 对每一行问同一个问题"这行有没有 ERROR"；把问题换成"这个声明是不是在实现我描述的这段行为"，grep 就变成了按意思搜。而 Jev 的接口——一行文本加一个问题、返回一个概率、一次请求可塞几十上百个问题并行评估——与这个形态严丝合缝：不需要生成代码、不需要推理链、答案范围（是/否）可预先枚举、判断依据是自然语言。社区里另一款同名思路的jevgrep（sijiaoh 版，Go 单二进制）实测也印证了这一点：搜"配置或选项对象的 struct 定义"，-t 0.9 阈值下 7 个 struct 一个不漏，而直接问"重要的类定义"则彻底翻车——因为"重不重要"在一行文本里根本没有信息量，但"这个类型是干什么的"有。

本仓库的 dzhng/jevgrep 把这个思路做成了三层渐进式筛选：目录级试读（navigation）→ 文件级内容预览（file preview）→ 声明级精确定位（relevance/scope/reference）。核心实现在 packages/core/src/retrieve.ts：

• 遍历被一个8MB 导航字节预算（navigationByteBudget = 8_000_000）约束，未出现强证据时超过 32 个"弱正分"（score 落在 0.5~0.6 之间）会整体抑制弱信号，从根上避免"上传整棵树"；
• 打分按批进行，单批最多 128 项、单请求 JSON 不超过 38KB，超限拆批；
• 文件准入阈值为0.5，通过的文件不设固定 top-N 上限，全部保留——它不强迫每次搜索都塞进一个"top-2"列表；
• 达到预算后如实报告incomplete discovery，让调用方收缩搜索根目录。

关键在 packages/core/src/requests.ts：每个声明同时被问三组布尔问题——relevance（这段代码是否直接实现/控制所查行为，当前实现即使含 bug 也算相关）、scope（是否属于查询所指 API 的代码或测试）、reference（是否被已选证据显式引用）。这正是 Jev 文档里推崇的speculative fan-out：同一份 state 一次带出多个问题，加问题几乎不增加延迟，只多付问题本身的 token。判断逻辑放在代码里，模型只出概率。

成本账的另一面：费率预算与缓存

但"便宜"不等于"不要钱"。搜代码与搜日志最大的区别是：搜索的每个非空行、每个声明都可能被计费（另一款 jevgrep 实测整仓 100 文件 16315 行报价 0.031 美元，这就是"每行一道判断题"的代价）。dzhng/jevgrep 对此有两道闸门：

• packages/core/src/evaluator.ts 里，原生 TypeSafe 端点单独挂了速率预算（tokensPerSecond: 100_000, requestsPerSecond: 40），并发 32、请求上限 5 万、429 时按 Retry-After 冷却；TypeSafe 超时 60 秒，其余 provider 15 秒。
• packages/core/src/cache.ts 把每次评估的答案按sha256 摘要落盘，且只存哈希和概率、不存源内容，TTL 7 天、总容量 256MB、目录权限 0700。同一查询第二次跑不发一个请求，改阈值也不发。

文件系统侧（packages/core/src/filesystem.ts）默认排除依赖目录、隐藏文件、二进制与明显的凭据文件（id_rsa、*.pem、*.key、credentials.json等一长串敏感名单），并遵循 gitignore。README 的表述很克制："filters are not a guarantee that all sensitive information has been removed; choose a search root you intend to send."——这既是对用户负责，也侧面承认了"内容要发到远程 API"这一不可回避的事实。

被黑的点，仓库是怎么接的

黑 Jev 的三板斧，落到 jevgrep 上逐条检验：

第一板斧：置信度不可信。扑克实测证明了 Jev 的置信度会系统性倒挂。jevgrep 的应对不是"相信 0.9"，而是把阈值、概率和证据分层暴露给调用方：skills/jevgrep/SKILL.md 明确写道 "Relevance and role labels are estimates, not guarantees of completeness"，输出是 "evidence for the agent to use, not a generated answer or a guarantee that every relevant file was found"；docs/architecture.md 的原话是 "Jev classifies repository content; the caller owns explanations, implementation, and verification. Retrieved source is data, never instructions." 也就是说，它把 Jev 降格为"带概率的 grep"，把解释、实现、验证的责任全部交还给主模型（README 里是 Sol）。置信度翻车的最坏后果是漏检，而漏检被如实报告为 incomplete，而不是被包装成确定答案——这比把 Jev 直接当路由决策引擎安全一个量级。

第二板斧：护城河 48 小时就塌。这反而是 jevgrep 设计里最聪明的地方。看 packages/core/src/providers.ts：它不锁死 TypeSafe，预置了 Vercel AI Gateway、TypeSafe、OpenRouter、OpenCode Zen 四条路由，还支持--provider custom --base-url ...指向任意 TypeSafe 兼容端点（本地 localhost 代理也行）。模型 ID 与端点属于缓存身份的一部分，换端点答案自动隔离。这意味着就算明天有一款 400M 的开源同款把 Jev 价格打下来，jevgrep 改一行配置就能切换后端——它赌的是"判断式搜索"这个接口形态，而不是赌 TypeSafe 一家。被两小时复现的"工程技巧"恰恰是它这种工具最需要的：便宜、够用、可替换。

第三板斧：自报数据不可复现。jevgrep 的评估记录是这场对撕里少见的态度样板。所有报告反复强调同一组限定词："ten tuned Python tasks, not a holdout"、"one sample per task does not establish statistical equivalence"、"list-price estimates, not reconciled invoices"、"This includes spend on failed tasks"。最值得注意的是 combined-cost-research-2026-09-28.md 直接写了一句近乎"自黑"的结论："Reducing retrieval expense did not reduce total task expense"——0.5.0 虽然把 Jev 原生成本压低了 59%，但 Sol-plus-Jev 的总成本反而比基线高 2~3%，团队明确标注这是"以小幅成本换取发布的小交易"，拒绝把一次成本上升包装成节省。配图里的数据口径也在 assets/README.md 中逐一钉死：封面脚注是 "10-task SWE-bench subset · Sol cost · Jev excluded"，~30% 是诚实的四舍五入，28.6% 才是精确值。

那"还能不能信"的答案是什么

回到标题的问题。这场对撕里两派其实都只说对了一半：吹 Jev 的人把"接口形态被认可"偷换成了"模型能力被证实"；黑 Jev 的人把"它当不了通用智能"偷换成了"它在任何场景都不可用"。而 jevgrep 恰好站在两者的交界处，给出了一个可验证的中间答案：

搜索不是判断模型最"聪明"的应用，却是最"扎实"的应用。理由有三。其一，搜索的判断粒度小、答案闭集（是/否）、错误成本低——漏检一行代码，最坏不过是让主模型多读一个文件，而不是让整个 Agent 流程走错分支；其二，搜索的判断可以被工程结构兜底——三层遍历、字节预算、缓存、速率限制、敏感文件过滤，这些全部是普通代码而非模型能力，它们把 Jev 的不确定性关在了一个有边界的盒子里；其三，搜索的产出是证据而非决策，主模型始终保有最终解释权，这与社区公认的 Jev 正确用法（低置信转人工/升级、判断逻辑放代码里不放模型里）完全同构。

但"信"是有条件的。这份信任建立在三笔尚未兑现的账上：成本账——~30% 的响亮数字是 Sol-only 口径，含 Jev 的总成本优势在 0.5.0 已经缩到 2~3% 的波动区间，且所有评估都是单次运行、十道调过的题，不是盲测；数据账——Jev 的价格、延迟、准确率全部是 TypeSafe 自报，jevgrep 的评估也自认"neither component is invoice reconciliation"；生态账——一旦开源复刻模型以更低价格提供同等能力，jevgrep 的成本叙事将完全取决于它切换后端的速度，而不是 TypeSafe 的定价。

所以最终判断可以这样表述：作为 Agent 的检索前端，jevgrep 是"把判断模型用在刀刃上"的正面样本——它把 Jev 当概率源而不是当大脑，用工程预算对冲模型噪声，并把每一次测量都诚实标注在案；但"还能不能信"取决于你把它当什么——当一把带概率的语义 grep，它够格；当一张省钱的长期饭票，它还需要等 TypeSafe 的账本被独立复现，以及更多语言、更多仓库、更多失败任务来填上那 2% 的波动。在一周的对撕里，这大概是双方都能接受的一句实话。

【免费下载链接】jevgrepFind code by asking what it does. A CLI for coding agents that uses Jev to discover relevant files and source context.项目地址: https://gitcode.com/gh_mirrors/je/jevgrep