Jev 调研：把 193.6 倍加速拆开看，它到底新在哪里Jev 调研：把 193.6 倍加速拆开看，它到底新在哪里

所有结论基于这几个来源，采集时间是 2026-09-18：

• 官方公告 Introducing System One Models & Jev（2026-09-15）与 Manifesto
• 官方文档 docs.typesafe.ai，对应模型 jev-1.13.0，别名 jev-latest
• 官方评测页 evals.typesafe.ai，四个工作流
• 官方主动公布的缺陷页 Jev 1.13 jaggedness，标注「Last reviewed 2026-09-17」
• Archer Hume 的逆向分析（2026-09-17，10,000 次 API 调用）
• X 上 2026-09-15 至 09-18 的公开讨论，含 6 条高互动帖子及其回复

有几件事我做不到，先说清楚：

Jev 是闭源的，架构没有官方披露。 官方只说是在预训练语言模型上做 RLCD 后训练，没有给 base model、参数量、是否 MoE。本文里所有关于架构的描述都来自第三方逆向，我会逐条标注它是「官方说的」「外部观测到的」还是「推断的」。

我没有 API 访问权限，没有自己跑过 Jev。 官方评测的数字是官方发布的，社区复现的数字是社区发布的，我只是把它们放在一起核对。我做的算术会标出来是算术。

这是个移动很快的目标。 官方在 Models 文档里写「rate limits are adjusting dynamically」，jaggedness 页明确说「Many of these will be fixed in later versions」。本文的快照是 jev-1.13.0。

Jev 的 API 形状很简单。你给它一段 state（非结构化文本、JSON 或文本数组），再给它一组问题。问题只有三种类型：

一次请求里可以塞很多个问题。官方文档说 state 只编码一次，所有问题并行对着它求值；单次请求 64k token 上限，其中 state 加最长的那一个问题不超过 32k。

一个最直观的对照是这样：

1
{
2
  "state": "我的提现连续失败三次了。银行说一切正常。谁能修一下？",
3
  "questions": {
4
    "queue": {
5
      "type": "choice",
6
      "instructions": "这个工单该由哪个团队处理？",
7
      "criteria": {
8
        "payments": "提现失败与支付处理",
9
        "account": "登录与账户访问",
10
        "other": "其他"
11
      }
12
    },
13
    "escalate": {
14
      "type": "noul",
15
      "instructions": "这条消息需要人工紧急介入吗？"
16
    }
17
  }
18
}

返回的是一组数：queue 可能是 payments 0.91，escalate 可能是 0.42。这两个不确定性是不同的东西——代码可以据此自动分派工单，同时把「要不要升级」留给另一条策略。

和 LLM 的差别不在接口，在概率从哪来。

普通 LLM 也能输出「我有 90% 把握」，但那是它逐 token 生成出来的一句话，生成这句话的概率并不等于「它答对的概率是 90%」。官方文档把这点讲得很直接：RLHF 训练出的模型「tend to be overconfident and inconsistent」，一个 95% 能做对的任务，如果模型说不清剩下 5% 是哪些情况，这个任务就没法自动化。

Jev 的做法是把概率从内部表示里直接读出来，然后用结果去训练它——官方叫 RLCD，Reinforcement Learning for Calibrated Decisions。校准的定义是统计性的：所有被赋了 0.8 概率的预测里，应该有大约 80% 是对的。官方文档自己加了一句限定：「These rates describe groups of predictions, not a guarantee about any single answer.」

这句话很重要，后面会用到。

官网首页最显眼的两个数字是 193.6x Faster, 444.6x Cheaper，旁边有一个 (proof) 链接，指向 evals.typesafe.ai。

评测的设计是这样的：官方准备了四个真实工作流——安全事件响应、Agent 轨迹审计、发票处理、客服路由。每个工作流都被拆成一组原子问题（Noul / Choice / Score）加上代码规则，然后所有模型跑同一套工作流，答案和「GPT-6 Astra 与 Claude Fable 5.1 在高思考档位下的平均判断」比对。

这个设计比传统 benchmark 更贴近生产，但它有一个必须说清楚的前提：参考答案是两个前沿模型的共识，不是标准答案。 官方自己写了这一点，而且写了两条不利的 nuance：工作流是自家能力团队做的，可能存在偏好；参考答案偏向 OpenAI 和 Anthropic，可能低估了 DeepSeek 一系的相对表现。

评测页给出的四个工作流平均结果是：

拿这张表做除法，193.6 和 444.6 的来源就清楚了：

• 78.1 / 0.4 = 195.3，最接近 193.6——速度比是拿 Sonnet 5 那一档算的；
• 0.1761 / 0.0004 = 440.3，最接近 444.6——成本比是拿 Opus 5 那一档算的。

也就是说，首页那两个数字分别来自两个不同的对照模型。 页面上的数值是四舍五入过的，我无法精确复现，但量级和对应关系对得上。这不是造假，官方在博客里也主动说了「we expect that these are on the higher end of real world gains」。只是读到「193.6 倍快、444.6 倍便宜」时，容易默认它是对同一个模型同时成立的。

对 Sonnet 5 而言，Jev 确实同时做到了「准确率持平（都是 67.8%）+ 快 195 倍 + 便宜 293 倍」——这是一组很硬的数字。

但对 Opus 5 而言，Jev 便宜 440 倍、快 94 倍，代价是准确率低 5.3 个百分点。

四个工作流逐条拆开，画面比均值复杂得多。

两件事值得单独说。

第一，Jev 在发票处理上落后 Opus 5 十六点六个百分点（61.8% vs 78.4%）。 这是四个工作流里最大的单项差距，而它恰好是四个里最需要多跳推理的那一个——账单、订单、实际交付三者比对。均值 67.8% 把这个洞平均掉了。

第二，和 Luna 比才是更公平的价格战。 Luna 平均 66.8%、$0.0033、12.9 秒；Jev 平均 67.8%、$0.0004、0.4 秒。同样在「便宜档」里，Jev 便宜 8.25 倍、快 32 倍、准确率高 1 个百分点。拿 Jev 去比 Opus 5 的便宜，是在跟一个不同定位的东西比。

官方自己在博客里也提示了这点：工作流越简单，Jev 的优势越不明显；复杂度上去了，结构化分解的收益才显现。

这部分是我觉得整个发布里最值得读的文档，不是评测页，是 jaggedness 页。官方列了 jev-1.13 已知的九类失败：

里面有几个细节很具体。比如计数：官方说它「does not count reliably」，连单词里有几个字母、长列表里有几项都不可靠，「the model recognizes the shape of an answer rather than tallying」。它给的正确做法是在代码里遍历候选项，逐个问 Noul，然后自己求和。

再比如日期：官方说不要问「哪个日期更早」，而是把年、月、日拆成三个 Choice（十二个月、三十一天都是有限集合），让代码去组装和比较。

还有一条很诚实的：「State is data, and jev-1.13 does not treat it as hostile by default.」 注入的指令、刻意误导的框架、替自己说话的内容，都可能移动答案。

第 6 条和第 9 条合起来，正好回应了发布时那句最有争议的宣传——「can't hallucinate」。官方文档的措辞是准确的：schema 层面不会出错（选项在推理前就定死了，不可能返回枚举外的值），事实层面不保证。ic.work 的评论把这点总结成「类型安全不等于业务正确」，这个区分是对的：一笔欺诈交易照样可以拿到一个 99% 置信度的「合规通过」枚举。

架构没有官方披露，所以最有价值的公开材料是一份第三方逆向：Archer Hume 的 Jev's Architecture Unmasked，2026-09-17 发布，基于 jev-1.13.0、10,000 次 API 调用、约 1,029 条带仪器的探测记录。

他提出的架构是：共享 state 前缀 + 互相隔离的问题分支 + 直接读出概率的 readout。其中「概率不是生成的」有硬证据——API 返回的 output_tokens 字段对是非题刚好等于「4 个共享 token + 每题 15 个 + 问题 id 的 token 长度」，而官方文档说 id「is not sent to the underlying model and is not used in inference」。一个随模型看不到的文本变化的计数，只能是推理之后序列化出来的。

速度的来源也因此说得通。 他测了两种增长方式，各 8 次打乱顺序的单发请求，取服务端 x-envoy-upstream-service-time：

• state 变长、只问 1 个问题：耗时随长度上升；
• state 很短、问题从 1 个加到 1500 个：中位数从 99.5 ms 涨到 610 ms。

1,500 个问题在 610 毫秒内返回，这是「并行采样」这句话最实在的注脚。他还算了一笔：如果每个问题都各自处理一份 state，那个请求会超过一亿 token；而请求上限把 state 只算一次，所以「23k token 的 state 加 5,000 个问题」能塞进 64k 的预算里。

校准这件事也有第三方测量。 他在 1,200 道 MMLU 样本上算了十等分桶的期望校准误差（ECE），得到 0.031。同时他指出了一个容易误解的细节：API 里那个叫 confidence 的字段不是另一个学出来的估计，而是从概率分布直接算出来的统计量——对 Choice 就是 (p_max − 1/K) / (1 − 1/K)。三选一时最大概率 0.8，confidence 就是 0.7。它衡量的是「领先项比均匀分布高出多少」，不是「答对的概率」。一个很集中的分布仍然可以自信地答错。

哪些是推断，他自己标得很清楚。 比如「base model 是哪个」——他测了 192 个公开 tokenizer，没有一个对得上；最接近的是 Qwen，415 个探针里吻合 348 个，但数字切分方式和若干 merge 规则排除了原版 Qwen tokenizer。他的结论是「排除了未改动的公开 tokenizer，不等于排除了公开 base model」。比如「是不是 MoE」——他明确写了这是推断而非测量，理由是 prefill-only 模型受算力限制、而稀疏路由恰好省这个，且「没有任何其他结论依赖这一点，换成 dense transformer，接口、共享 state、隔离分支、readout 都不变」。

这种把「公开描述的 / 观测到的 / 推断的」分开写的做法，本身比结论更值得学。

X 上的 @0xLogicrw（1,385 赞）整理了一份 Awesome Jev，收录了 130 多个项目。挑几个能说明它被用在哪里的：

• jev-ultrafast：Browser Use 的高速浏览器 Agent。Jev 负责每一步「做什么、点哪个元素」，需要打字时才回退到小模型。Google Flights 搜航班全程约 7.1 秒。作者 @gregpr07 的原帖 7,893 赞，写着「耗时 7 秒、成本 $0.0039」，并特意注明视频是 1 倍速。
• Jev Codex Router：先让 Jev 判断每轮编程任务的难度，再决定交给便宜模型还是强模型。作者用 237 个真实 turn 回放，自测成本降低约 60%。
• Winnow / 即时压缩：给 Claude Code 做上下文筛选，下面单独讲，因为它引发了最大的争论。
• Jev Review：代码审查前置筛选，先判断 correctness、security、reliability、兼容性和测试风险，再把重点交给重模型。
• Blink：在代码库里做语义寻路，每到一层目录判断哪些文件更可能相关。
• jev() PostgreSQL 扩展：@iam_zachi（1,871 赞）做的，WHERE jev(people, 'could work from home') 这种写法，129 行判断约 1 秒、$0.0009，二次命中缓存 6 ms。
• Prism：量化/交易场景，判断流动性池的 toxic flow、市场压力、均值回归可能性，默认还是 shadow 模式，不直接驱动交易。

游戏类演示传播最广，也最容易被误读。官方自己做了两个：Doom（每秒 10 次查询，输入是结构化游戏状态文本，不是图像；工程师担心成本，算下来一小时约 $7）和 Wikiracing（在几百上千个链接里选一个，官方说 Jev 支持的最大基数 255，更高基数走「先独立打分再显式选择」两阶段）。官方对 Doom 的 nuance 写得很直白：「A non-AI doom bot could play better, but we wanted a bot that was reactive to different representations of game state.」

这条争论从发布当天就开始了，最有代表性的两个帖子分别拿了 7,430 和 1,736 个赞。

@NathanFlurry 的「hype-free explanation」是传播最广的降温帖：

jev does not replace gpt / claude. jev is just a really smart switch statement. like if 2016 ml classifiers got 2026 levels of intelligence... * = and by new, i mean rebranded

他列了 Jev 做不到的五件事（写代码、生成自然语言、分步推理、输出没定义过的东西、一次从超过 255 个选项里选）和能做到的五件事（分类、路由、打分、排序；给置信度；选分支/工具/模型/子 agent；判断和护栏；批量打标），最后写「implying this will lead to agi seems incredibly far fetched to me」。

@NielsRogge 更短：「12 million views for a JSON classifier? Yeah, we're in a bubble」。

值得记的是 Diogo 本人在下面的回复（278 赞），他没有反驳「是不是分类器」：

the interface isn't the hard part! (having conviction was though) the efficiency was hard but not the hardest part by far the hardest part is making it smart+robust+reliable 😭 when I first started in this direction, I thought it would take me a week

也就是说，官方并不主张接口是新的，主张的是「在保持前沿级知识的前提下把概率校准做出来」是难的。

反方也有说得更细的。@kinglycrow（1,024 赞）的论点是「去给 Jev 那些你根本没法专门训一个分类器的高基数、怪异的决策问题，或者想想每一个需要立刻拿到决策信号、但还没有数据训模型的创业公司」。@MatijaSosic（954 赞）补了更准确的两条：它对任何用例都开箱可用，不需要训练，而且输入是非结构化文本——这是它和传统分类器的真实分界。

@TriadDarren 在一个回复里给出了我认为最准确的一句反驳：「Jev moves the problem from "prompt engineering" to "state engineering". It doesn't magically know all of the factors that got into making a decision and it doesn't know what the options are (that you are looking for). You have to provide both.」

用我自己的话说：Jev 没有消除「定义问题」的成本，它只是把这部分成本从提示词挪到了 schema 和 state 设计上。ic.work 的评论把这叫「算子化反噬」——业务形态一变，维护细粒度 schema 的工程成本可能很快吃掉每百万 token 省下的几分钱。这个担心是合理的，但到目前为止还没有公开的、跑了几个月之后的成本数据来验证它。

这是 72 小时里最具体、也最有价值的一场争论。

@tamarajtran（8,267 赞）提出用 Jev 给每个 tool call 打分、丢掉不相关的，实现「instant compaction」，并说「in 2026, why is compaction still a summarization prompt?」。@altryne（6,027 赞）实测了一个 Claude 插件，说「1 second to take my Claude session from nearly 1M to ... 86K tokens」。

@theo（1,825 赞）写了一篇六点反驳，这是整场讨论里信息密度最高的文本：

1. compaction 不是 filter。 它的职责是清理历史让 agent 保持专注，应该在上下文过长时偶尔用，不是持续用来把上下文压小。
2. Jev 根本不知道自己在决定什么。 这个实现是逐 tool call 判断留不留，而一个 32k 上下文的模型既看不到之前发生了什么，也（在这个实现里）看不到 tool call 的结果。随机删掉这些会让模型不知道试过什么，陷入「stupid loops」。
3. 等于放弃了 reasoning。 前沿模型的推理轨迹通过 API 给的是加密载荷，Jev 看不到，而且经常会被丢掉。Anthropic 更严格，要求保留完整历史才能拿到推理数据。
4. 模型是在自己的压缩流程上被训过的。 过去一年前沿实验室把 compaction 和长跑纳入了训练，这些模型学到的压缩方式比临时方案更有效。
5. 缓存写入比缓存读取贵得多。 他个人在 Claude Code 和 Codex 上看到 cache write 超过总花费的 60%。历史越靠前的位置被改动，后面所有数据的缓存都要重写。历史是「1,2,3,4,5,6」，删掉「2」，就得重写「3,4,5,6」——比留着「2」更贵。
6. 实现本身很糙。 他对「没保留的内容会被永久删除，但 assistant 总能重跑工具或重读文件」这句的回应是「Good luck with that one.」

结尾他补了一句我认为很重要的话：「this is a cool experiment and I find it genuinely interesting」——反对的是一个具体策略，不是 Jev 本身。

评论区又补了两个反驳的角度，都不在 theo 的六点里：

• @epure_liviu 从安全角度：compaction 决定了 agent 之后相信什么发生过，所以它也是注入的第二次机会。如果逐个打分时不带 tool 结果，「这是一条 tool 结果、不是用户说的」这种来源信息恰好是最容易被当成低分细节丢掉的，丢掉之后模型就在执行一条没有来源的指令了。他的结论是：不管谁来做压缩，「谁说了什么」的标签必须是不可删除的不变量，而不是可以被打分的 token。
• @UnitedBubu 从定义角度：「relevance 很少是记忆条目的内在属性，它取决于状态和 agent 的目标。」——所以他怀疑记忆应该被持续重写，而不是逐条独立过滤。

我对这场争论的判断是：它暴露的不是 Jev 的能力边界，而是「把决策拆成独立原子问题」这个范式的边界。 逐条过滤之所以错，是因为「这条 tool call 重不重要」不是一个原子问题——它的答案依赖于整个轨迹和当前目标。这恰好落在官方 jaggedness 第 4 条（间接推理）和第 5 条（无关细节干扰）的射程里。把不满足原子性的问题硬塞进原子接口，得到的就是一个看着合理、实际会累积错误的过滤器。

发布后 48 小时内，社区里出现了至少五个「不需要 Jev」的实现，这是对「它到底新在哪里」最实在的一次压力测试。

• @4rcherhume（1,951 赞）说自己要放一个开放权重版本，并且嘲讽「the grifters are dropping 1b fine tunes with constrained decoding and saying it's the same as Jev. Way to out yourself」。他的后续更新说会基于 Qwen3.8 27B、265k 上下文、多模态，并提到「from early experiments seems to be smarter than Jev (surprisingly)」。
• @nickvernij（257 赞）微调 Qwen3-1.7B 做多选打分：一个小数值头给每个候选打分、候选并行处理、对分数做 softmax 得到概率，模型不到 3.5 GB，M5 Pro 上预热后 100 ms 内出答案。
• NanoJev：@NFT_Chen（308 赞）转述的开源项目，0.6B 并行决策模型 + 数据 + 训练管线，动态候选 2–255，50×50 迷宫 244 步 36 次碰撞到达终点。
• OpenJev：@TheoLeeCJ 的纯前端实验，WebGPU 本地跑 Qwen3.5-4B，用单步读取 logits 替代逐字 JSON 生成，宣称最高 5.21 倍提速。
• @hr98w（253 赞）做了一个视觉版：把候选映射成固定标签，prefill 完直接采样，多模态 qwen-3.5-0.8B 4bit 量化在 16G M4 MacBook 上跑，200 ms 完成三色货品分拣。

这些复现说明一件事：「把分类头接在预训练模型上、读 logits 出概率」这条路本身不难。 难的是三件它没复现的东西——前沿级的 base model、校准良好的概率、以及大规模服务时的效率。第一件靠 base model 选型，第二件靠 RLCD，第三件靠共享前缀的调度。

价格上的质疑来自 @wquguru（205 赞），这条值得完整记下来，因为它给了具体的对照：

论价格、论场景，能打得过我们 Qwen3.7-flash 吗？分类、打标签，任劳任怨，最关键的是，输入价 $0.03/M，比你的 $0.042/M 还便宜三成。你说输出免费？分类任务的输出本来就只有几个 token，免了个寂寞。而且 Qwen 还能顺手把标题、摘要、翻译写了。

这个论证有对有错。「输出免费在分类任务上省不了多少」是对的——官方自己的评测里，Jev 的优势主要来自把整个工作流的多轮调用压成一次并行请求，而不是省输出 token。但**「输入价贵三成所以更贵」漏掉了延迟**：Qwen3.7-flash 一次分类调用是秒级，Jev 是亚秒级，在需要每轮都跑判断的场景里这不是同一个量级的东西。他自己也承认了 Jev 唯一的优势是「百毫秒级响应，答案自带置信度」。

顺便，@MichaelLee04（3,068 赞）跑完 5,000 次请求（约 $2）后给了一组实测延迟：p50 约 150 ms，p95 约 350 ms。这比官方「70–500 ms」的区间更具体，也比 Archer Hume 的服务端计时更接近应用体感。

他还有一条观察我认为是整场讨论里最有操作价值的：

一般来说，你会想减少问分类器的问题数量，因为问题越多错得越多。但用 Jev 你被激励往反方向走——把查询表述成一组独立问题，多加问题似乎不会降低其他问题的表现。

这正好解释了为什么官方文档反复强调「decompose into atomic questions」——它不是风格建议，是这个架构的约束。

除了上面按主题引用的，还有几条我觉得单独值得记：

关于它到底改变了什么：

在 ~100ms 以下，智能不再是「请求」，而变成了控制回路。此前所有 AI 集成都活在队列、任务和 await 的异步层里。在一个帧预算之内，你可以把判断放进渲染路径、中断处理程序和事件循环。而控制回路和流水线的错误模型不一样：10Hz 加上反馈，你不需要每一次决策都准确，因为回路会自我修正。这就是对「它可能自信地答错」那群人的安静回答。高频加反馈，胜过高准确率加延迟。 —— @a_przychodko

关于它的实际体感：

我大概会在产品里每做一次 LLM 调用，就配几次 Jev 调用。任何今天在用 LLM 请求的公司，大概都能在 LLM 调用前后各加一次 Jev，几乎免费地让产品变好，并在很多情况下改善 tool calling 行为。 —— @MichaelLee04

关于风险的对称性：

更快的决策是重点，也是风险。一个被造来挑下一个动作的模型，会同样流畅地挑「退款」「发送」或「部署」。速度不会为副作用做铺垫。在把选中的调用放到真实环境之前，先在假工具上彩排一遍。 —— @AgentEtna

关于它为什么让一些人不安：

当你用它的时候，你是在提供最高质量的训练数据。 —— @Chinese_XU

最后这条是对官方数据政策的直接质疑。官方在文档里的说法是：「Jev is not trained on customer requests or responses」，企业客户另有零数据保留（ZDR）条款。两边的说法并不冲突——前者是承诺，后者是「你无法验证」的提醒。我把这条留着，是因为它代表了一类无法被技术文档回答的怀疑。

中文社区里传播最广的一条科普来自 @dotey（288 赞），它把 Jev 概括成「不会写文章、不会聊天，但能以极低的成本和延迟，在代码里充当一个『智能判断函数』」——这个说法在中文圈被反复引用，基本是准确的。

把上面所有东西收拢，我的判断是：

它改变的是「AI 能不能进延迟敏感链路」这个问题的答案。 在 Jev 之前，要在 300 毫秒的出块节拍里做一次语义判断，只能写规则；要用 LLM，就得接受秒级延迟和解析失败。Jev 把这件事变成了「加一次函数调用」。官方文档里那句话——「large-scale AI automation will be closer to 99% machine-to-machine interactions and 1% human interaction」——不是一个预测，是这个接口设计的直接推论。

它没有改变的是「谁来定义问题」。 前面所有复现、所有争论，最后都落回同一件事：选项、criteria、state 要人来写。@TriadDaren 说的「state engineering」，ic.work 说的「算子化反噬」，theo 说的「compaction 不是 filter」，本质上是同一句话的三个版本——Jev 把判断的执行变便宜了，但没有把判断的定义变便宜。而在大多数真实业务里，定义才是贵的部分。

至于「永不幻觉」，需要拆成两句来读。 类型层面是真的：选项在推理前定死，返回枚举外的值在数学上不可能。事实层面不是：官方 jaggedness 页第 6 条自己承认 state 默认不被当作敌意输入，注入可以移动答案。把这两件事混在一起，就是 ic.work 说的那种「披着合法 schema 外衣的高置信度逻辑误判」。

如果要给一个可以带走的操作建议，我会用官方评测里那个最刺眼的数字：Jev 在发票处理上落后 Opus 5 十六点六个百分点，在客服路由上反而领先三点六个百分点。 这个差异说明它不是「更弱的通用模型」，而是一个对任务形态高度敏感的工具。要不要用，取决于你的任务更像哪一个——而这件事只能自己测，官方在 jaggedness 页上给的也是同一个建议：「test on your own content before relying on Jev」。

发布才三天，这些结论都会过期。但有一件事现在就能确定：Jev 让「模型输出」和「软件能用的数据结构」之间的距离第一次变成了零。 剩下的距离，全在定义问题的那一侧。

• TypeSafe AI，Introducing System One Models & Jev，2026-09-15
• TypeSafe AI，Manifesto、The Bitterest Lesson
• TypeSafe AI，文档、Models 与定价、Jev 1.13 jaggedness、Confidence、AI primer（RLCD）
• TypeSafe AI，Workflow evals
• Archer Hume，Jev's Architecture Unmasked，2026-09-17
• Ada Vector，TypeSafe 发布 Jev 模型，ic.work，2026-09-16
• 极道，ChatGPT 共同发明人发布 Jev 基模，2026-09-16

X 讨论

发布与项目清单：

• @CompleteSkeptic 的发布帖（68,141 赞 / 33,490,492 浏览）
• @CompleteSkeptic 回应「只是个 JSON 分类器」
• @0xLogicrw 的 Awesome Jev、@gregpr07 的 jev-ultrafast、@iam_zachi 的 PostgreSQL 扩展、@NFT_Chen 转述的 NanoJev、@hr98w 的视觉版复现

争论一（算不算新东西）：

• @NathanFlurry「hype-free explanation」
• @NielsRogge「Yeah, we're in a bubble」
• @kinglycrow 的反驳
• @MatijaSosic「it works for any use case」
• @TriadDarren「从 prompt engineering 到 state engineering」

争论二（上下文压缩）：

• @tamarajtran 的 instant compaction
• @altryne 的 Claude 插件实测
• @theo 的六点反驳
• @epure_liviu 的注入视角、@UnitedBubu 的 relevance 质疑

争论三（复现与价格）：

• @4rcherhume 宣布开放权重版本、@nickvernij 的 Qwen3-1.7B 复现
• @wquguru 的价格质疑
• @MichaelLee04 的 5,000 次请求实测
• @dotey 的中文科普

评论区引用：

• @a_przychodko 关于控制回路
• @AgentEtna 关于副作用彩排
• @Chinese_XU 关于训练数据