「执行壳决策脑」会不会成为 AI 编程新标配Codex 套 Jev 的组合拳实战横评【免费下载链接】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-jarvis2026 年 9 月 15 日前 OpenAI InstructGPT 核心作者 Diogo Almeida 创立的 TypeSafe AI 带着 4000 万美元种子轮融资结束两年隐身发布了首个「System One」模型 Jev。它不写文本、不写代码只输出「选择 打分 是非」三类类型化判断却在发布 3 天内登顶 Hacker News1863 分、491 条评论一周内催生 2170 个关联项目GitHub 上基于它的浏览器 Agent 插件狂揽 21k star甚至有社区文章称「上线 24 小时13% 的付费团队连夜换到 Jev」。一个「哑巴模型」为什么让整个 Agent 生态沸腾答案指向一种正在成形的组合范式用 Codex 这类执行壳负责跑任务、改文件、跑测试用 Jev 这类决策脑负责在关键节点上做毫秒级判断。本文不聊概念直接从一个开源落地项目聊天辅助决策工具 jev-chat-jarvis的源码出发拆解「执行壳 决策脑」的分工逻辑对照社区横评中的批量重构、Bug 修复、测试生成场景最后老实算一笔组合拳的代价账。决策脑到底是什么为什么「不生成一个字」反而是卖点社区里关于 Jev 的讨论有一个高频比喻「不是聊天机器人而是一个智能 if 语句」。理解这个比喻就理解了决策脑的全部意义。传统 LLM 的工作方式是「生成」给定上下文吐出一段文本、一行代码、一个解释。Jev 的工作方式是「判定」给定上下文和一个封闭选项集返回带概率与置信度的类型化结果——noul是非题返回 0~1 的概率、choice单选题返回选项及其概率分布、score分档打分返回加权分数与各档概率。它从架构上就不生产自由文本因此没有幻觉式发挥的余地换来了两个硬指标单次判断 70–500ms输入 token 单价 $0.042/百万输出 token 免费。这个定位在 jev-chat-jarvis 的题目集里看得最清楚。项目把「判断层」固化成 7 道判断题 1 道排序题一次请求全发literal_questionnoul对方最新消息是字面意思还是话里有话true_intentchoice对方真实意图6 个互斥选项danger_levelscore对话离吵架/伤感情有多近10 档情景化打分should_reply_nownoul现在该不该给出实质回复best_actionchoice下一步最佳动作类型she_needschoice对方现在要什么tension_resolvednoul紧张是否已解除best_replychoice给定 3 条候选回复选最合适的一条这 8 道题的完整定义在 cn/app/src/main/java/com/jev/probe/jev/JevQuestions.ktPython 侧的原型在 cn/tools/jev/questions.py。注意一个细节所有题目的 instructions 和 criteria 用英文写而 state 里的聊天内容保留中文原文——因为 Jev 的主训练语言是英文措辞直接决定判断质量。这是「决策脑」工程化的第一课你喂给判断模型的不是提示词而是一份精心校准的问卷。另一个细节更能体现决策脑的思路should_reply_now被刻意限定为「该不该给出实质内容」而不是「该不该回复」best_action的选项里不允许再出现「要不要现在回」这个维度she_needs必须保留明确的「nothing / 事情已经过去了」档。项目在 cn/tools/jev/TASK.md 里记录了这样做的原因用真实截图测题时should_answer_now给出 0.77、best_action却给出「先翻聊天记录」0.60两题互相打架——决策脑内部各题结论矛盾是比单个题目答错更致命的问题因为下游流程会无所适从。于是项目建立 25 条标注集、以danger_level平均绝对误差 1.0 档、true_intent和she_needs命中率 ≥ 60% 为验收线最多迭代 3 轮调措辞。判断模型的精度不是模型给的是题目集校准出来的——这是决策脑工程的核心方法论。执行壳 决策脑一次典型协作的分工边界「Codex 为执行壳、Jev 为决策脑」的组合方式社区文章给出的架构很清晰Codex 负责与环境交互读文件、改代码、跑测试、提交在需要做判断的节点上通过 OpenAI 兼容 API 调 Jev 的 decisions 接口拿回结构化结论后继续执行。Jev 不碰代码Codex 不拍板。这个分工在 jev-chat-jarvis 里有一个完整的、可运行的实现三路客户端拆分。看 cn/app/src/main/java/com/jev/probe/jev/JevClient.ktJudgeClientcn/app/src/main/java/com/jev/probe/jev/JudgeClient.kt只走 Jev 判断路由发 7 道判断题 排序题解析choice/score/noul全程无生成能力ReplyClientcn/app/src/main/java/com/jev/probe/jev/ReplyClient.kt只走生成路由任何 OpenAI 兼容的/chat/completions端点都能接负责起草 3 条候选回复JevClient是薄外观层draftAndRank()把两个阶段串起来先起草再让 Jev 排序。一次完整协作是这样的程序通过无障碍服务读到屏幕上最近 10 条消息buildState()把它们连同关系描述打包成 Jev 的stateJevQuestions.kt 中buildState的实现from只取me/other两个值英文描述统一称对方为 the other person判断路由一次返回 7 个结构化结论生成路由按结论起草 3 条候选判断路由再对 3 条候选做best_reply排序给出占比人点一下填入输入框发送键永远在自己手里。注意这里最值得称道的分工纪律判断与生成在代码层就是隔离的两个路由。判断路由永远不产生文本生成路由永远不参与决策。你在 cn/CLAUDE.md 能看到实测数字7 道判断题一次请求约 900ms、约 1000 输入 token、0.00004 美元。社区横评中「Agent 决策比 LLM 快 40–200 倍、便宜 40–400 倍」的说法对应到本仓库就是把「该不该现在回」「对方意图是什么」这类高频小判断从 DeepSeek/OpenAI 这类生成模型上卸载到 Jev每次省下的不只是 token 费还有几百毫秒到几秒的等待时间。海外版核心引擎global/core把「先定目标、再起草、后检查打分」的管线做得更完整是理解执行壳内部分工的好样本。流程是定 GoalGoal.kt起草前先把「这条回复要达成什么」固化——must_include、must_avoid、authorized_commitments只允许承诺列表内的事甚至「用户自己输入的内容作为用户事实」也进 Goal。目标不先定死后续所有判断都失去参照系起草Drafting.kt生成模型在 Goal 的约束内写回复温度 0.7、单条最多 420 token系统提示词 19 条硬规则输出 JSON解析时过滤套话STOCK_PHRASES里列了 I hope this message finds you well 这类模板句、剔除与首条近似重复的候选检查 打分CandidateCheck.kt每一条候选回复单独过一组 Jev 是非题硬检查编造事实、未经授权承诺、替他人承诺、越界、越权认错等再打 G目标契合度与 E语气契合度两档分总分 S 0.7G 0.3E。概率阈值在 Analysis.kt 里集中定义违规 ≥ 0.7 直接拦、≤ 0.45 放行、中间地带要求人「看一眼再发」。这一套「生成模型负责发挥判断模型负责把关」的结构和 Codex 套 Jev 在逻辑上完全同构生成端负责「把话/代码写出来」决策端负责「这个方案行不行、哪个最好、该不该继续」。用判断模型做质控闸门而不是用生成模型自检自纠是这套组合拳最反直觉也最有效的地方——生成模型自检自己的输出等于让运动员兼任裁判。组合 vs 纯 LLM三类典型场景的横评逻辑社区横评把 Codex 套 Jev 与纯 LLM 编码的对比集中在三个场景批量重构、Bug 修复、测试生成。这三个场景有一个共同点动作多、判断密、每一步的成败都取决于一个明确的二值或多选结论。这正是决策脑的主场。结合本仓库的管线设计可以还原出每类场景下「执行壳 决策脑」比纯 LLM 强在哪、又付出了什么。批量重构纯 LLM 的典型翻车方式是「改到一半忘了约束」或在不同文件间传播不一致的假设。决策脑方案把约束变成显式的判断题重构前先问「这个改动是否保持公开 API 不变」「是否引入了未授权的依赖变更」每次批量操作前用 noul 判断题闸一下违规即拦。这与仓库里CandidateChecks的hardChecks设计同源unsupported_fact是否陈述了对话里没有的事实、new_commitment是否承诺了未授权的事、commits_others是否替他人承诺——每个硬检查都是一道 noul 题概率过 0.7 就判NEEDS_REWRITE候选回复直接不可复制。把「合规性」从提示词里的软约束变成判断题里的硬闸门是批量场景可复现性的来源。Bug 修复难点在于定位而不在于写补丁。决策脑方案让 Jev 在修复前先做类型化判断「这个报错更可能是类型问题还是状态问题」「修改范围是否超出该函数」。仓库里没有直接的 debug 场景但有同构的「下一步动作判定」best_action的选项里有check_history先翻聊天记录确认事实不要凭空道歉或编计划——当信息不足时决策脑会输出「先查证」而不是「硬编一个答案」这正是 Bug 修复场景最需要的纪律。should_reply_now的题面里甚至写明了边界需要背诵/证明的事实不在当前片段里时答案必须是 FALSE因为「you would be guessing」。让判断模型主动承认「现在不该动」是纯 LLM 最难教会的技能。测试生成测试的价值在于断言准确生成模型容易写出「通过率好看但断言空洞」的测试。决策脑方案把每个候选测试当作候选回复处理起草多条 → 判断题检查是否覆盖必需断言、是否越权 → 排序选最优。仓库里draftAndRank的流程就是这条链路的最小实现3 条候选Jev 排序并给出概率占比parseRanked按概率降序返回JudgeClient.kt。海外版线上评估global/docs/TESTING.md给出了一组值得正视的实测数据37 个 pilot case 上违规候选拦截 6/6干净候选误拦 11/12打分阶梯 4 组无倒序端到端起草 检查一轮 21 次请求、花费 $0.0038。同时文档诚实列了已知弱点隐含表达Itll be ready on Monday, sorry for the delay 这类没明说「要迟交」的句子有时落在 unsure 带两个同名联系人共享身份哈希15 分钟缓存看不到被编辑或删除的旧消息。这些「弱点清单」本身就是横评里最该抄走的部分——决策脑不是万能判断器它只对「题目集覆盖到的封闭集」负责题目没设计到的场景它只会诚实地输出 unsure然后把决定权交还给人。组合拳的代价上下文、权限与排错的三本账任何架构选择都有代价Codex 套 Jev 的代价集中在三处本仓库的源码恰好把每一处都暴露得很清楚。第一本账上下文管理。判断模型不吃大上下文这是它的优势也是约束。仓库的处理方式值得借鉴buildState只带最近 10 条消息takeLast(10)知识库背景和更早历史作为可选字段单独传空时整个字段省略保证请求体与 v1.2 完全一致JevQuestions.kt。但多字段带来新问题背景字段可能不被生产端点识别——JudgeClient.postDecisions专门写了一段防御性逻辑带background/history的请求如果收到 4xx就去掉这两个字段原样重发一次让「未经验证的字段最多降级分析、绝不搞挂请求」JudgeClient.kt。这个「可降级的新字段」模式是双模型组合里最实用的工程技巧之一。此外排序题还有个隐藏坑3 条候选如果两条太像排序就没意义。Drafting.parse用词重叠率做nearDuplicate去重短句过半词相同、长句四分之三词相同即视为同一条并在解析时丢弃套话候选——上下文管理的另一半是输出管理。第二本账权限控制。决策脑给了判断但执行权必须留在人手里。这是本仓库的红线体现在两层。采集层NewMessageGate.kt 用「side text」做消息去重只在上方出现过已读消息、下方出现新消息时才判定为「新消息」翻历史不算新、不触发分析避免误读。写入层GuardedInputWriter.kt 是整套权限控制的精华——fill()先把文本设进输入框150ms 后重新解析输入框校验是否写入成功失败则聚焦重试再失败退到剪贴板粘贴任何分支都不碰发送按钮。而且每一步resolve()都要重新校验当前会话是否还活着防止填入时界面已切走造成串台。海外版引擎则用RunBudgetAssistant.kt做预算控制单次分析默认最多 17 次模型请求、最多 90 秒模型等待达到任一上限就停止发请求而不是悄悄继续——执行壳的自由度必须被显式预算约束这是组合拳安全性的底线。第三本账排错成本。双模型意味着双倍的错误面。决策接口的错误码要单独学401 key 错、422 body 不合法、429 限流、529 过载429/529 需要指数退避重试cn/tools/jev/TASK.md。生成路由的坑则在超时ModelGateway的实现里专门写了一段注释——OpenRouter 会用空字节保活慢请求纯读超时永远不会触发实测起草调用曾耗 38 秒所以必须加看门狗定时器在整请求超时点强制disconnect()ModelGateway.kt默认 20 秒。还有一类排错成本最隐蔽判断模型内部各题结论矛盾。前文提到的should_reply_now与best_action打架就是典型案例仓库用标注集 验收线 三轮迭代来解决——这意味着每个接入决策脑的团队都要建立自己的「判断题校准」基础设施这是纯 LLM 方案完全不需要的投入。会不会成为标配判断是便宜的生成才是贵的回到标题的问题「执行壳 决策脑」会不会成为 AI 编程新标配从本仓库的实践和社区横评的数据看结论更接近「会但以你意想不到的方式」。Jev 这类 System One 模型的出现把 Agent 架构里一个长期被忽视的事实摆到了台面上在 Agent 循环里真正高频执行的是判断而不是生成。每一步「继续/停止」「这个/那个」「通过/违规」都是一次判断如果用生成模型来做每次都要付全量推理的延迟和 token 费而 Jev 把这类判断压缩到 70–500ms、$0.042/百万输入 token输出还免费。当判断变得几乎免费「多问几次 Jev」就成了比「让 LLM 一次想清楚」更优的工程选择——这会让 Agent 的架构从「大模型一次生成到底」迁移到「生成端保持最少调用、决策端高频廉价把关」。但「标配」不会以「人人都把 Codex 和 Jev 接起来」的形式出现而会以更底层的方式沉淀判断模型成为 Agent 框架的中间件像数据库索引一样藏在执行壳内部。社区文章里已经能看到这个趋势的雏形模型路由该用哪个模型、工具风险门控这个工具调用危不危险、上下文压缩哪些历史该丢、输出护栏这段输出能不能过——这些全是封闭集判断题全是 Jev 的主场。jev-chat-jarvis 的价值在于提供了一个完全开源、可端到端运行的参考实现三路客户端拆分、7 题判断集、起草—排序管线、预算与权限控制以及最重要的——一套「题目校准 标注集 验收线」的方法论。至于 Codex 套 Jev 是否会成为每个开发者桌上的标配社区横评里那句更实在的总结值得记住判断是便宜的生成才是贵的。当判断成本趋近于零任何拒绝把判断从生成模型里拆出来的架构都会在延迟、成本和可控性三笔账上同时失分。而判断模型答不上来的场景它诚实输出的 unsure 带和「请人看一眼」的降级策略恰恰是比 LLM 自信的幻觉更稀缺的品质——这也是为什么一个「哑巴模型」能在发布三天内登顶 HN它把 AI 从「什么都能编」的表演者变成了「只对自己答得上的事负责」的裁判。如果你也想在自己的工具链里试这套组合仓库给出了最直接的起点读一遍 cn/tools/jev/TASK.md 的题目校准方法论再看 cn/app/src/main/java/com/jev/probe/jev/JudgeClient.kt 里那 100 行不到的判断路由实现——你会发现把「决策脑」接入现有执行壳难度远低于想象而收益曲线陡峭得超乎预期。【免费下载链接】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），仅供参考
「执行壳决策脑」会不会成为 AI 编程新标配Codex 套 Jev 的组合拳实战横评【免费下载链接】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-jarvis2026 年 9 月 15 日前 OpenAI InstructGPT 核心作者 Diogo Almeida 创立的 TypeSafe AI 带着 4000 万美元种子轮融资结束两年隐身发布了首个「System One」模型 Jev。它不写文本、不写代码只输出「选择 打分 是非」三类类型化判断却在发布 3 天内登顶 Hacker News1863 分、491 条评论一周内催生 2170 个关联项目GitHub 上基于它的浏览器 Agent 插件狂揽 21k star甚至有社区文章称「上线 24 小时13% 的付费团队连夜换到 Jev」。一个「哑巴模型」为什么让整个 Agent 生态沸腾答案指向一种正在成形的组合范式用 Codex 这类执行壳负责跑任务、改文件、跑测试用 Jev 这类决策脑负责在关键节点上做毫秒级判断。本文不聊概念直接从一个开源落地项目聊天辅助决策工具 jev-chat-jarvis的源码出发拆解「执行壳 决策脑」的分工逻辑对照社区横评中的批量重构、Bug 修复、测试生成场景最后老实算一笔组合拳的代价账。决策脑到底是什么为什么「不生成一个字」反而是卖点社区里关于 Jev 的讨论有一个高频比喻「不是聊天机器人而是一个智能 if 语句」。理解这个比喻就理解了决策脑的全部意义。传统 LLM 的工作方式是「生成」给定上下文吐出一段文本、一行代码、一个解释。Jev 的工作方式是「判定」给定上下文和一个封闭选项集返回带概率与置信度的类型化结果——noul是非题返回 0~1 的概率、choice单选题返回选项及其概率分布、score分档打分返回加权分数与各档概率。它从架构上就不生产自由文本因此没有幻觉式发挥的余地换来了两个硬指标单次判断 70–500ms输入 token 单价 $0.042/百万输出 token 免费。这个定位在 jev-chat-jarvis 的题目集里看得最清楚。项目把「判断层」固化成 7 道判断题 1 道排序题一次请求全发literal_questionnoul对方最新消息是字面意思还是话里有话true_intentchoice对方真实意图6 个互斥选项danger_levelscore对话离吵架/伤感情有多近10 档情景化打分should_reply_nownoul现在该不该给出实质回复best_actionchoice下一步最佳动作类型she_needschoice对方现在要什么tension_resolvednoul紧张是否已解除best_replychoice给定 3 条候选回复选最合适的一条这 8 道题的完整定义在 cn/app/src/main/java/com/jev/probe/jev/JevQuestions.ktPython 侧的原型在 cn/tools/jev/questions.py。注意一个细节所有题目的 instructions 和 criteria 用英文写而 state 里的聊天内容保留中文原文——因为 Jev 的主训练语言是英文措辞直接决定判断质量。这是「决策脑」工程化的第一课你喂给判断模型的不是提示词而是一份精心校准的问卷。另一个细节更能体现决策脑的思路should_reply_now被刻意限定为「该不该给出实质内容」而不是「该不该回复」best_action的选项里不允许再出现「要不要现在回」这个维度she_needs必须保留明确的「nothing / 事情已经过去了」档。项目在 cn/tools/jev/TASK.md 里记录了这样做的原因用真实截图测题时should_answer_now给出 0.77、best_action却给出「先翻聊天记录」0.60两题互相打架——决策脑内部各题结论矛盾是比单个题目答错更致命的问题因为下游流程会无所适从。于是项目建立 25 条标注集、以danger_level平均绝对误差 1.0 档、true_intent和she_needs命中率 ≥ 60% 为验收线最多迭代 3 轮调措辞。判断模型的精度不是模型给的是题目集校准出来的——这是决策脑工程的核心方法论。执行壳 决策脑一次典型协作的分工边界「Codex 为执行壳、Jev 为决策脑」的组合方式社区文章给出的架构很清晰Codex 负责与环境交互读文件、改代码、跑测试、提交在需要做判断的节点上通过 OpenAI 兼容 API 调 Jev 的 decisions 接口拿回结构化结论后继续执行。Jev 不碰代码Codex 不拍板。这个分工在 jev-chat-jarvis 里有一个完整的、可运行的实现三路客户端拆分。看 cn/app/src/main/java/com/jev/probe/jev/JevClient.ktJudgeClientcn/app/src/main/java/com/jev/probe/jev/JudgeClient.kt只走 Jev 判断路由发 7 道判断题 排序题解析choice/score/noul全程无生成能力ReplyClientcn/app/src/main/java/com/jev/probe/jev/ReplyClient.kt只走生成路由任何 OpenAI 兼容的/chat/completions端点都能接负责起草 3 条候选回复JevClient是薄外观层draftAndRank()把两个阶段串起来先起草再让 Jev 排序。一次完整协作是这样的程序通过无障碍服务读到屏幕上最近 10 条消息buildState()把它们连同关系描述打包成 Jev 的stateJevQuestions.kt 中buildState的实现from只取me/other两个值英文描述统一称对方为 the other person判断路由一次返回 7 个结构化结论生成路由按结论起草 3 条候选判断路由再对 3 条候选做best_reply排序给出占比人点一下填入输入框发送键永远在自己手里。注意这里最值得称道的分工纪律判断与生成在代码层就是隔离的两个路由。判断路由永远不产生文本生成路由永远不参与决策。你在 cn/CLAUDE.md 能看到实测数字7 道判断题一次请求约 900ms、约 1000 输入 token、0.00004 美元。社区横评中「Agent 决策比 LLM 快 40–200 倍、便宜 40–400 倍」的说法对应到本仓库就是把「该不该现在回」「对方意图是什么」这类高频小判断从 DeepSeek/OpenAI 这类生成模型上卸载到 Jev每次省下的不只是 token 费还有几百毫秒到几秒的等待时间。海外版核心引擎global/core把「先定目标、再起草、后检查打分」的管线做得更完整是理解执行壳内部分工的好样本。流程是定 GoalGoal.kt起草前先把「这条回复要达成什么」固化——must_include、must_avoid、authorized_commitments只允许承诺列表内的事甚至「用户自己输入的内容作为用户事实」也进 Goal。目标不先定死后续所有判断都失去参照系起草Drafting.kt生成模型在 Goal 的约束内写回复温度 0.7、单条最多 420 token系统提示词 19 条硬规则输出 JSON解析时过滤套话STOCK_PHRASES里列了 I hope this message finds you well 这类模板句、剔除与首条近似重复的候选检查 打分CandidateCheck.kt每一条候选回复单独过一组 Jev 是非题硬检查编造事实、未经授权承诺、替他人承诺、越界、越权认错等再打 G目标契合度与 E语气契合度两档分总分 S 0.7G 0.3E。概率阈值在 Analysis.kt 里集中定义违规 ≥ 0.7 直接拦、≤ 0.45 放行、中间地带要求人「看一眼再发」。这一套「生成模型负责发挥判断模型负责把关」的结构和 Codex 套 Jev 在逻辑上完全同构生成端负责「把话/代码写出来」决策端负责「这个方案行不行、哪个最好、该不该继续」。用判断模型做质控闸门而不是用生成模型自检自纠是这套组合拳最反直觉也最有效的地方——生成模型自检自己的输出等于让运动员兼任裁判。组合 vs 纯 LLM三类典型场景的横评逻辑社区横评把 Codex 套 Jev 与纯 LLM 编码的对比集中在三个场景批量重构、Bug 修复、测试生成。这三个场景有一个共同点动作多、判断密、每一步的成败都取决于一个明确的二值或多选结论。这正是决策脑的主场。结合本仓库的管线设计可以还原出每类场景下「执行壳 决策脑」比纯 LLM 强在哪、又付出了什么。批量重构纯 LLM 的典型翻车方式是「改到一半忘了约束」或在不同文件间传播不一致的假设。决策脑方案把约束变成显式的判断题重构前先问「这个改动是否保持公开 API 不变」「是否引入了未授权的依赖变更」每次批量操作前用 noul 判断题闸一下违规即拦。这与仓库里CandidateChecks的hardChecks设计同源unsupported_fact是否陈述了对话里没有的事实、new_commitment是否承诺了未授权的事、commits_others是否替他人承诺——每个硬检查都是一道 noul 题概率过 0.7 就判NEEDS_REWRITE候选回复直接不可复制。把「合规性」从提示词里的软约束变成判断题里的硬闸门是批量场景可复现性的来源。Bug 修复难点在于定位而不在于写补丁。决策脑方案让 Jev 在修复前先做类型化判断「这个报错更可能是类型问题还是状态问题」「修改范围是否超出该函数」。仓库里没有直接的 debug 场景但有同构的「下一步动作判定」best_action的选项里有check_history先翻聊天记录确认事实不要凭空道歉或编计划——当信息不足时决策脑会输出「先查证」而不是「硬编一个答案」这正是 Bug 修复场景最需要的纪律。should_reply_now的题面里甚至写明了边界需要背诵/证明的事实不在当前片段里时答案必须是 FALSE因为「you would be guessing」。让判断模型主动承认「现在不该动」是纯 LLM 最难教会的技能。测试生成测试的价值在于断言准确生成模型容易写出「通过率好看但断言空洞」的测试。决策脑方案把每个候选测试当作候选回复处理起草多条 → 判断题检查是否覆盖必需断言、是否越权 → 排序选最优。仓库里draftAndRank的流程就是这条链路的最小实现3 条候选Jev 排序并给出概率占比parseRanked按概率降序返回JudgeClient.kt。海外版线上评估global/docs/TESTING.md给出了一组值得正视的实测数据37 个 pilot case 上违规候选拦截 6/6干净候选误拦 11/12打分阶梯 4 组无倒序端到端起草 检查一轮 21 次请求、花费 $0.0038。同时文档诚实列了已知弱点隐含表达Itll be ready on Monday, sorry for the delay 这类没明说「要迟交」的句子有时落在 unsure 带两个同名联系人共享身份哈希15 分钟缓存看不到被编辑或删除的旧消息。这些「弱点清单」本身就是横评里最该抄走的部分——决策脑不是万能判断器它只对「题目集覆盖到的封闭集」负责题目没设计到的场景它只会诚实地输出 unsure然后把决定权交还给人。组合拳的代价上下文、权限与排错的三本账任何架构选择都有代价Codex 套 Jev 的代价集中在三处本仓库的源码恰好把每一处都暴露得很清楚。第一本账上下文管理。判断模型不吃大上下文这是它的优势也是约束。仓库的处理方式值得借鉴buildState只带最近 10 条消息takeLast(10)知识库背景和更早历史作为可选字段单独传空时整个字段省略保证请求体与 v1.2 完全一致JevQuestions.kt。但多字段带来新问题背景字段可能不被生产端点识别——JudgeClient.postDecisions专门写了一段防御性逻辑带background/history的请求如果收到 4xx就去掉这两个字段原样重发一次让「未经验证的字段最多降级分析、绝不搞挂请求」JudgeClient.kt。这个「可降级的新字段」模式是双模型组合里最实用的工程技巧之一。此外排序题还有个隐藏坑3 条候选如果两条太像排序就没意义。Drafting.parse用词重叠率做nearDuplicate去重短句过半词相同、长句四分之三词相同即视为同一条并在解析时丢弃套话候选——上下文管理的另一半是输出管理。第二本账权限控制。决策脑给了判断但执行权必须留在人手里。这是本仓库的红线体现在两层。采集层NewMessageGate.kt 用「side text」做消息去重只在上方出现过已读消息、下方出现新消息时才判定为「新消息」翻历史不算新、不触发分析避免误读。写入层GuardedInputWriter.kt 是整套权限控制的精华——fill()先把文本设进输入框150ms 后重新解析输入框校验是否写入成功失败则聚焦重试再失败退到剪贴板粘贴任何分支都不碰发送按钮。而且每一步resolve()都要重新校验当前会话是否还活着防止填入时界面已切走造成串台。海外版引擎则用RunBudgetAssistant.kt做预算控制单次分析默认最多 17 次模型请求、最多 90 秒模型等待达到任一上限就停止发请求而不是悄悄继续——执行壳的自由度必须被显式预算约束这是组合拳安全性的底线。第三本账排错成本。双模型意味着双倍的错误面。决策接口的错误码要单独学401 key 错、422 body 不合法、429 限流、529 过载429/529 需要指数退避重试cn/tools/jev/TASK.md。生成路由的坑则在超时ModelGateway的实现里专门写了一段注释——OpenRouter 会用空字节保活慢请求纯读超时永远不会触发实测起草调用曾耗 38 秒所以必须加看门狗定时器在整请求超时点强制disconnect()ModelGateway.kt默认 20 秒。还有一类排错成本最隐蔽判断模型内部各题结论矛盾。前文提到的should_reply_now与best_action打架就是典型案例仓库用标注集 验收线 三轮迭代来解决——这意味着每个接入决策脑的团队都要建立自己的「判断题校准」基础设施这是纯 LLM 方案完全不需要的投入。会不会成为标配判断是便宜的生成才是贵的回到标题的问题「执行壳 决策脑」会不会成为 AI 编程新标配从本仓库的实践和社区横评的数据看结论更接近「会但以你意想不到的方式」。Jev 这类 System One 模型的出现把 Agent 架构里一个长期被忽视的事实摆到了台面上在 Agent 循环里真正高频执行的是判断而不是生成。每一步「继续/停止」「这个/那个」「通过/违规」都是一次判断如果用生成模型来做每次都要付全量推理的延迟和 token 费而 Jev 把这类判断压缩到 70–500ms、$0.042/百万输入 token输出还免费。当判断变得几乎免费「多问几次 Jev」就成了比「让 LLM 一次想清楚」更优的工程选择——这会让 Agent 的架构从「大模型一次生成到底」迁移到「生成端保持最少调用、决策端高频廉价把关」。但「标配」不会以「人人都把 Codex 和 Jev 接起来」的形式出现而会以更底层的方式沉淀判断模型成为 Agent 框架的中间件像数据库索引一样藏在执行壳内部。社区文章里已经能看到这个趋势的雏形模型路由该用哪个模型、工具风险门控这个工具调用危不危险、上下文压缩哪些历史该丢、输出护栏这段输出能不能过——这些全是封闭集判断题全是 Jev 的主场。jev-chat-jarvis 的价值在于提供了一个完全开源、可端到端运行的参考实现三路客户端拆分、7 题判断集、起草—排序管线、预算与权限控制以及最重要的——一套「题目校准 标注集 验收线」的方法论。至于 Codex 套 Jev 是否会成为每个开发者桌上的标配社区横评里那句更实在的总结值得记住判断是便宜的生成才是贵的。当判断成本趋近于零任何拒绝把判断从生成模型里拆出来的架构都会在延迟、成本和可控性三笔账上同时失分。而判断模型答不上来的场景它诚实输出的 unsure 带和「请人看一眼」的降级策略恰恰是比 LLM 自信的幻觉更稀缺的品质——这也是为什么一个「哑巴模型」能在发布三天内登顶 HN它把 AI 从「什么都能编」的表演者变成了「只对自己答得上的事负责」的裁判。如果你也想在自己的工具链里试这套组合仓库给出了最直接的起点读一遍 cn/tools/jev/TASK.md 的题目校准方法论再看 cn/app/src/main/java/com/jev/probe/jev/JudgeClient.kt 里那 100 行不到的判断路由实现——你会发现把「决策脑」接入现有执行壳难度远低于想象而收益曲线陡峭得超乎预期。【免费下载链接】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），仅供参考
