从「哄人」到「干活」：Jev式「少说多做」会否让AI助手集体转向克制表达

从「哄人」到「干活」Jev式「少说多做」会否让AI助手集体转向克制表达【免费下载链接】jev-chat-jarvisThe chat decision assistant: before you reply, Jev reads the chat, judges intent and risk, and drafts replies you fill in with one tap. You press send. Android · Windows · macOS · iOS | 聊天辅助决策工具先看懂对方再回复发不发由你。项目地址: https://gitcode.com/gh_mirrors/je/jev-chat-jarvisAI 助手正在经历一场罕见的「话痨疲劳」聊天模型越卷越能聊动不动先夸你三句、再回你一段正确的废话可当用户真的想让它办成一件事时它又开始「一本正经地胡说八道」。2026 年 9 月中旬一个「不生成文字」的模型 Jev 却一夜刷屏——不写诗、不寒暄、不哄人只回答选择题、打分和是非判断。社区给它起了两个外号「哑巴模型」和「一个智能 if 语句」。本文不打算复述热度而是结合本地仓库 jev-chat-jarvis一个把 Jev 判断模型装进聊天场景的「对话副驾」的真实源码回答三个问题用户为什么开始反感 AI 的废话「不生成」如何被工程化成产品竞争力决策与表达的分离会不会成为下一代助手的默认架构。「哄人式对话」的行业反思用户开始反感 AI 的废话过去两年对话式大模型的迭代主线是「更会说话」更长的上下文、更圆滑的措辞、更周到的情绪价值。社区里流传的吐槽一针见血——模型「拼命展现自己有多能聊、多能写还会对用户各种吹捧」但真到了要它干活的时候它「最直白、最不绕弯、最一本正经地胡说八道」见社区文章《Jev是什么哑巴模型居然全网爆火》。用户要的从来不是被哄而是被理解、被办成事过度表达不仅不增加价值反而稀释了信息的可信度这就是「哄人式对话」的反噬。Jev 的出现正好踩在这个情绪转折点上。2026 年 9 月 15 日前 OpenAI InstructGPT 核心作者 Diogo Almeida 创立的 TypeSafe AI 带着 4000 万美元种子轮融资结束两年隐身发布首个「System One」模型 Jev。它最出圈的特点恰恰是「不做」不生成文本、不写代码只输出带概率与置信度的类型化结果——选择choice、打分score、是非noul。社区文章的标题几乎就是行业情绪的注脚《Jev不是聊天机器人而是一个智能 if 语句》《发布 3 天登顶 HN不生成一个字的模型》。HN 上这篇介绍帖冲到 1863 分、491 条评论随后「只做选择题的模型火了 2170 个项目」「上线 24 小时 13% 的付费团队连夜换到 Jev」等报道接连出现甚至传出估值 100 亿美元的说法。当然爆火之下也有降温声。社区文章《别吹 Jev 了》直言「最大的特点是不说话、不生成文字」并提醒别把「不生成」神化成「新技术路线」。这其实是对的Jev 的价值不在于「不说话」本身而在于它把「判断」从「生成」里剥离出来——判断可以更便宜、更快、更可验证而表达则留给更擅长写字的模型。这个分离才是真正值得讨论的设计思想。Jev 的「不生成」表达克制如何被工程化成竞争力判断模型的取舍只回答不寒暄先看 Jev 的硬指标。据社区实测与文档响应约 70–500ms输入价格约 $0.042/百万 token输出 token 免费一次典型判断约消耗 1000 输入 token见仓库 cn/CHANGELOG.md 中 OpenCode Zen 预置说明。它能做到这种成本结构前提是任务被严格收窄在封闭集合里做类型化判断——选一个、打一个分、判一个是非每个答案都附带概率分布和置信度而不是自由生成一段话。关键在于题目本身的设计。在仓库 cn/tools/jev/questions.py 里判断层被固化为 7 道固定题 1 道排序题literal_question对方最新消息是不是字面意思、true_intent真实意图、danger_level危险等级10 档、should_reply_now该不该马上给出实质内容、best_action下一步最佳动作、she_needs对方现在要什么、tension_resolved紧张是否已解除外加对 3 条候选回复排序的best_reply。项目文档 cn/tools/jev/TASK.md 把口径定得很死题目用英文写Jev 主训练语言是英文聊天内容保留中文原文7 道判断题一次请求全发即官方推荐的 speculative fan-out省时省钱。「少说」是被设计出来的输出克制表达在这套题目里不是修辞而是显式定义的选项。先看should_reply_now它的 instructions 特意澄清「这不是『该不该发消息』时机无关只有所需的事实、明确的过错或明确的时间地点已经出现在这段对话里才答 true」。换句话说它判断的是「下一条消息该不该携带实质内容」——当对方在考验你记不记得某件事、而回忆内容不在眼前时正确答案是 false即「先别急着给内容别瞎猜」。再看best_action的选项专门有一个say_less「少说或什么都不加多余的词会过度解释、重新打开已经结束的话题或在对方已经下最后通牒时火上浇油」。she_needs也有明确的nothing档「对方已真正满意、事情已经过去」并且指令强调一旦对方说出「没事了 / 那就这样 / 收到了 / 过去了」即使更早时对方要过行动或道歉也必须选 nothing。把「不说」设计成一道标准答案这在以生成为中心的助手产品里几乎不可想象。这套题目不是拍脑袋写的。cn/tools/jev/TASK.md 记录了一个真实的校准事故用截图里的对话实测时should_answer_now给出 0.77该回而best_action给出「先翻聊天记录」0.60两题互相打架对话结尾「她还需要什么」被判断成「行动」0.62压过了正确答案「什么都不用了」0.38。项目的解法是把题目措辞重写并靠人工标注集把矛盾压下去——cn/tools/jev/fixtures/labeled_set.json 提供了 20 条覆盖情侣拌嘴、对方明显生气、对方已满意、纯闲聊、同事催进度、阴阳怪气、最后通牒等场景的中文对话片段危险等级标注覆盖 0–9 全程cn/tools/jev/calibrate.py 跑完全部标注集输出每道题的命中率验收线是danger_level平均绝对误差 1.0 档、true_intent与she_needs命中率 ≥ 60%见 cn/docs/acceptance.md。产品化先判断、再写字、发不发由你判断层只是上游。jev-chat-jarvis 的产品思路在 cn/README.md 里一句话讲完「它先判断再写字。」整个链路是无障碍服务读取聊天界面 → Jev 一次返回真实意图、危险等级、对方要什么、该不该马上回、最佳动作约 1 秒→ 生成模型起草 3 条口语化候选 → Jev 再对候选排序 → 悬浮窗展示 → 用户一键填入输入框发送键永远由人按下。Android 端把这条链路拆成了三个可独立配置的客户端cn/app/src/main/java/com/jev/probe/jev/JudgeClient.kt 只负责判断题与排序题cn/app/src/main/java/com/jev/probe/jev/ReplyClient.kt 只负责起草与摘要视觉 OCR 走独立一路见 cn/docs/v1.3-plan.md。有趣的是生成侧也被要求「克制」cn/app/src/main/java/com/jev/probe/jev/ReplyClient.kt 的系统提示词规定「每条不超过 40 字英文不超过 30 个单词、口语、自然、像真人在聊天软件里发消息。不要解释」且要求回复与知识库一致——「可以直接引用其中事实不要编造知识库里没有的事实」。候选回复还可以只出 1 条跳过排序出得更快或换一组判断不变、只重新生成见 cn/CHANGELOG.md v1.7。「不发送」则被做成了工程上的硬约束。cn/app/src/main/java/com/jev/probe/capture/GuardedInputWriter.kt 的填入流程是ACTION_SET_TEXT写入输入框 → 150ms 后校验文本是否真的写进去了 → 失败则聚焦重试 → 再失败退到剪贴板 ACTION_PASTE→ 再次校验。整个过程只碰输入框绝不碰发送动作配合 cn/app/src/main/java/com/jev/probe/capture/NewMessageGate.kt 只在「对方发来新消息」时才触发分析翻历史、自己的消息都不触发克制既体现在「AI 说什么」也体现在「AI 什么时候开口」。数据边界同样克制只读无障碍树暴露的屏幕内容、截屏只在本机 OCR 不上传、密钥与知识库存 App 私有目录、历史记录默认关闭见 cn/README.md 与 cn/docs/v1.3-plan.md。一个有意思的产品细节是悬浮窗的折叠态卡片收起时只显示危险等级和对方意图点击才展开看完整判断与候选cn/CHANGELOG.md v1.7。「克制」一路从模型选项渗透到题目设计、提示词、填入行为再到 UI 的信息密度——这是把「少说多做」当成完整产品哲学在做的典型。趋势推演决策与表达的分离会成为下一代助手的默认架构吗Jev 本身是一个模型但它真正撬动行业的地方是让「判断」成为一种可以被单独定价、单独部署、单独调用的基础设施。社区实测给出的成本账相当极端Agent 决策比 LLM 快 40–200 倍、便宜 40–400 倍、输出 token 免费见社区文章《给Codex配上Jev直接起飞》。之所以有这种数量级差距是因为判断模型不需要为「生成」付出推理代价——它在封闭集合上做选择相当于把一张「选择题试卷」交给一个专用模型而不是让通用模型边写作文边做判断。架构层面的证据也在快速积累。社区报道的 Jev-Mobile 方案提出「低频 VLM 高层规划 高频轻量 Jev 执行器」的协同架构VLM 只输出局部子目标Jev 基于无障碍树生成的结构化候选动作做类型化决策一次 VLM 调用可执行多步 GUI 动作在 AndroidWorld 基准上达到 79% 任务成功率成功轨迹端到端延迟降低 32.7%、VLM API 开销减少 73.4%。浏览器 Agent 插件方向也出现「基于 Jev 的判断模型改变浏览器代理高延迟运行模式」的 21k star 项目。还有文章系统梳理了判断器在智能体中的十个落点实时控制循环、浏览器操作选择、工具风险门控、模型路由、目标/卡住检查、上下文压缩、技能与工具选择、输出护栏、工单邮件分类、RAG 重排序——本质是把「重复性判断」从 LLM 上卸载到专用决策层。TypeSafe 自己也把 Jev 定位成可嵌入 Harness智能体编排外壳的中间件判断器可接入 middleware 或工具链替代传统 LLM 做分类任务。本仓库正是这个趋势的一个最小闭环样本在 cn/docs/v1.3-plan.md 的公共契约里判断接口Jev、回复接口任意 OpenAI 兼容 chat/completions、视觉接口OCR三路地址、密钥、模型完全解耦判断接口还内置了 OpenRouter、博查 Jev、TypeSafe 直连、Vercel、OpenCode Zen 等多个预设见 cn/CHANGELOG.md v1.4/v1.7。用户可以把判断交给 Jev、把写字交给 DeepSeek、把视觉交给通义三路各自计费、各自调优——「决策与表达分离」在这里不是一个概念而是配置文件里的三个字段。官方兼容协议POST /v1/systemone请求体{model, state, questions}让多家服务商博查、Vercel AI Gateway、OpenCode Zen都提供 Jev 的托管入口判断层正在变成像「路由、限流、护栏」一样的基础组件。那么这是否意味着 AI 助手会「集体转向克制表达」从成本与质量两个维度看答案是方向性的「会」但形态不是所有模型都变成哑巴。更可能出现的是分工表达层继续由通用模型承担但「该不该说、说什么类型、说到什么程度、什么时候闭嘴」这类决策被逐步下沉到判断层——因为判断可以被标注、被校准、被验收本仓库的 7 题命中率标准就是一个例子而生成很难被这样约束。产品层面「少说」将成为显式卖点回复长度上限、折叠面板、发送权分离、只在必要时开口这些今天还是差异化设计明天可能就是默认选项。当然也要给狂热降温判断模型不生成文本不等于它天然正确。本仓库的实践恰恰说明判断层的价值高度依赖题目质量和标注集——7 道题的措辞经历了「两题互相打架」的返工danger_level 的 10 档要求每档写具体情景而非抽象程度见 cn/tools/jev/TASK.md这才是 Jev 式「少说多做」能成立的前提。从「哄人」到「干活」AI 助手缺的不是更多话术而是更可靠的判断以及判断之后的克制。当一个助手既能看懂潜台词、又知道什么时候该闭嘴、还从不替你做最后决定时「克制」就不再是风格问题而是信任问题——这可能是这场「哑巴模型」狂欢留下的最长期的价值。【免费下载链接】jev-chat-jarvisThe chat decision assistant: before you reply, Jev reads the chat, judges intent and risk, and drafts replies you fill in with one tap. You press send. Android · Windows · macOS · iOS | 聊天辅助决策工具先看懂对方再回复发不发由你。项目地址: https://gitcode.com/gh_mirrors/je/jev-chat-jarvis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考