这篇公众号居然能点，JEV 为什么适合实时交互一眼就懂

昨天看到一篇讲 JEV 的公众号，我第一反应不是它写得多深。

是这玩意居然能点。

正文里散着一些小圆点和卡片。手指点一下，隐藏内容滑进来；再点一个区域，当前页码从 03 变成 08；有些横向内容还能一页页切换。它没有把你扔到外部网页，交互就发生在公众号正文里。

好家伙，我一直以为公众号排版的上限是字体、色块和长图。结果人家直接在文章里塞了一个小型交互界面。

灵感来自 AGI Hunt 的《什么是 Jev？》，作者尹John。原文用微信原生 SVG 做了大量点击、展开与切换交互。本文不转载原文，只拆解这种表达方式，并用新的案例框架和两段原创 SVG 继续讲 JEV。

先说明白，原文开头的翻页是预设演示，不是公众号现场调用 JEV。可它选这个形式特别聪明，因为交互方式本身就在解释 JEV。

读者给一个点击，SVG 切换状态。程序给一段 state 和几个问题，JEV 返回选择、评分或概率。下一步怎么执行，仍由程序决定。

一个负责判断，一个负责动作。

我把原文和源码都翻了一遍，还顺手看了 QMuse 整理的 JEV 案例库。下面这篇不再重复上一篇的申请和 API 接入，而是聊两个更有意思的问题。

JEV 到底适合放进什么产品，以及公众号为什么突然可以做出这种能点的内容。

JEV 其实只有三种回答

先把最重要的放前面。

JEV 不写一段长答案。它主要返回三种东西。

• Choice，从你给出的选项里挑一个，例如工单交给销售、账单还是技术团队
• Score，在有顺序的档位上评分，例如客户有多着急、风险有多高
• Noul，判断一个命题成立的概率，例如这条消息是否需要立刻升级人工

结果自带概率，程序可以设阈值。高置信度继续，模糊的结果让用户确认，高风险动作交给人工。

下面不是截图。点卡片里的任意位置，看这三种结果从右侧滑进来。

它为什么能在微信里动

原理没有想象中复杂。

SVG 里预先放好两组画面，第二组先藏在右侧。读者点击后，SVG 自带的位移动画把它滑进来。透明热区负责接住手指点击，不需要作者在文章里运行 JavaScript。

你可以把它理解成一张会响应点击的矢量图，而不是藏在公众号里的小程序。

真正麻烦的是制作和测试。点击区域要足够大，第一次点击前要有提示，关键结论还要在正文重复一遍。发布前最好在微信 iOS、Android 和网页预览各试一次。

交互是增强层，正文才是保底层。一篇文章放一两段就够了，多了会从阅读变成找彩蛋。

为什么这个形式特别适合讲 JEV

TypeSafe 的官方定义是，JEV 接收当前状态和预先定义的问题，返回类型化决策与概率。它不写长答案，也不负责和用户聊天。

很多人看到这里会问，那不就是分类模型吗？

只看接口，确实很像。但 JEV 想抢的位置不是训练一个固定垃圾邮件分类器，而是程序运行时不断出现的小判断。

演讲者正在讲哪一页。

这个请求该交给哪个 Agent。

浏览器当前应该点哪个控件。

这段上下文该保留、压缩还是丢弃。

这些问题有三个共同点，答案空间有限，调用频率很高，结果需要立刻交给代码继续执行。让一个生成模型每次写几百个 token 的分析再吐 JSON，当然也能做，就是像每按一次电梯都请专家写一份楼层研判报告，多少有点隆重了。

JEV 的卖点就是把这一步压成一个快而便宜的判断函数。

再点一下下面这张图。

它真正适合的位置不是替代所有大模型，而是夹在确定性代码和生成模型之间。

确定性代码处理权限、金额、日期和明确规则。JEV 处理需要一点常识的选择、分类和评分。遇到多步推理、长期规划和内容生成，再交给 Claude、Codex、DeepSeek 这一类生成模型。

三层各干各的，程序反而更容易控制。

202 条案例，最后都落到四种形状

向明整理的 QMuse JEV 案例库标注自己是非官方索引，目前页面展示 202 条公开案例。数量会继续变化，案例里的速度、成本和准确率也多半来自作者自报，不能拼成一个统一排行榜。

把这些热闹的 demo 拆开看，主要落在四种产品形状里。

第一种是实时控制。

自动翻 PPT、语音控制浏览器、操作 Figma、玩俄罗斯方块、吃豆人和 Minecraft。这里最值钱的不是模型棋力，而是判断速度能跟上人的操作节奏。一次调用慢五秒，演示就会像网络卡顿；两三百毫秒，界面才开始有即时感。

第二种是批量分类。

论文、广告、邮件、文书、商品、视频片段，一次处理几百到几万条。JEV 对每条数据做选择或评分，程序再聚合。它不负责写报告，省掉的正是大量重复生成文本的时间和费用。

第三种是 Agent 路由。

根据任务选 Claude、Codex 或别的模型，选择下一件工具，判断是否继续循环，给技能库挑最合适的 Skill。它像 Agent 系统里的高速分诊台，不做手术，只决定病人往哪走。

第四种是门禁与复核。

PR 是否需要人工审查，模型回答有没有违反规则，某次工具调用风险多高，旧上下文能不能丢。这里不能迷信置信度。模型给 0.95 仍然可能错，高风险动作依旧需要权限检查、确认和回滚。

你会发现，四类场景都不是让 JEV 独自完成一个宏大任务。

它们都是把一个大流程拆成很多窄判断，然后让程序把判断组合起来。

能点的公众号，也是一种产品原型

这篇《什么是 Jev？》给我的另一个刺激，是公众号文章不一定只能解释产品，它也可以先让读者体验产品的思维方式。

讲状态机，就让卡片切换状态。

讲模型路由，就让读者点开不同分支。

讲 Agent 流程，就把每个节点做成可展开的证据。

讲 JEV，就让一次点击触发一个确定动作。

内容从说明书变成了一个很轻的产品原型。

但我不建议为了新颖，把每篇文章都做成 24 节交互长卷。原文的信息量和制作量都很大，读者很可能点到一半就累了。小岛AI 更适合控制在两个交互块，每个只回答一个问题，同时保留普通正文和静态截图作为兜底。

形式应该替理解省力，不该让读者来参加密室逃脱。

所以这篇只留了两次点击。

第一次告诉你 JEV 不生成长答案，它返回程序能读取的判断。

第二次告诉你 JEV 该站在代码和生成模型之间，而不是替代它们。

如果点完以后，这两件事比看一张参数表更容易记住，那 SVG 就没白写。

模型给出判断，程序决定动作。

读者给出点击，文章切换状态。

同一件事，两种表达。

你还想让我把哪个 AI 概念做成一篇能点的公众号？