2026年10月报名参加Datawhale当月组队学习里的共学从0开始入门、了解jev本篇记载我的 Task05 学习笔记主要内容是智能家居实验。【教程地址】https://github .com/datawhalechina/jev-cookbookTask 05 智能家居实验上一篇我们把 18 个实战 Notebook 按四条路线梳理了一遍而这一篇的智能家居实验室就是这条路线最完整的一次工程落地从一句自然语言指令进来系统要判断意图、识别设备、决定动作还要处理复合命令和知识问答但每一步都不是让 LLM 自由发挥而是用 Jev 在代码预先画好的边界里做选择题。场景实验用一个 Three.js 搭的 3D 房子做模拟器5 个房间客厅、厨房、书房、卧室、玄关11 个设备5 盏灯、1 台风扇、1 个音箱、1 台咖啡机、2 把门锁。用户在输入框里说把咖啡烧上右侧面板会把整条决策链展开咖啡机随即亮起来。支撑这个演示的有三块代码01_智能家居实验.ipynb核心实验验证 Jev 三种用法——投机提问、复合命令拆分、路由守卫。serve_smart_home.py一个本地代理服务把 Jev 的 typesafe 接口、ASR语音识别、传统 LLM 聊天统一封装成 HTTP 接口顺便解决浏览器跨域和密钥不能暴露在前端的问题。smart_home_playground.html3D 交互页面支持Jev 投机 / 传统 LLM / 双路对比三种管线切换还能接麦克风语音输入。健康检查会告诉你当前配了哪些能力jevtrue, asrfalse, chatfalse表示只有 Jev 可用语音和聊天模型没配 key——这时候页面会自动降级到本地模拟不影响看决策流程。核心实验一投机提问——一次调用问完所有问题智能家居最朴素的做法是串行先问意图再问设备类别再问动作一问一答好几轮但每多一轮调用就多一次网络往返和一次出错概率。所以这一篇的第一个实验就是把所有可能要问的问题打包进一次/v1/systemone调用让 Jev 一次性回答。拿把咖啡烧上举例一次调用里塞了 6 个 question意图判断、是否复合、设备类别、以及五种设备各自的动作预测灯/风扇/音箱/电器/门锁。关键代码长这样questions [ {name: intent, type: choice, instructions: 判断用户意图, criteria: [smart_home_command, information_request, ambient]}, {name: is_compound, type: noul}, {name: category, type: choice, criteria: [light, fan, speaker, appliance, lock]}, {name: light_action, type: choice, criteria: [turn_on, turn_off, leave_unchanged]}, {name: appliance_action, type: choice, criteria: [turn_on, turn_off, leave_unchanged]}, # ...风扇、音箱、门锁同理 ]真实 API 实测上游耗时 777 ms返回的结果是question结果top 概率是否采纳intentsmart_home_command1.00✅is_compound否0.09剪枝投机categoryappliance1.00✅appliance_actionturn_on1.00✅light_actionleave_unchanged0.97剪枝投机lock_actionleave_unchanged0.97剪枝投机Jev 老老实实把 6 个问题都答了但代码只采纳 category 对应的那个设备动作。咖啡机的指令里灯和门锁的动作虽然也被预测为不变但这是投机算出来的因为代码端知道主目标是 appliance就把其他分支直接剪掉根本不进入后续执行逻辑。这就是投机提问的精髓用一次调用的成本换来所有分支的答案用代码的领域知识决定哪些答案该被当真。零额外往返也没让 Jev 承担它不该承担的编排责任。核心实验二复合命令——Noul 判断、小模型拆分、依赖排序关掉厨房的灯然后锁上书房的门这种一句话两个动作的指令投机提问就不够用了——需要先判断是不是复合命令再拆成子任务还要保证顺序。实验分三步Noul 判断是否复合Jev 用noul原语回答是/否。如果是复合进入拆分流程如果不是走单命令的投机分支。小LLM拆分让一个轻量模型把复合句切成原子指令列表例如[{room: 厨房, device: light, action: turn_off}, {room: 书房, device: lock, action: lock}]。依赖排序与并行/串行用noul判断子任务之间有没有必须先后的依赖关系。有依赖就串行执行没有就并行。这里的理论根基是偏序partial order和幂等性每个动作带action_id做幂等去重失败时回滚已完成的动作避免半执行状态。README 里明确说了一条纪律——复合命令的执行顺序、权限校验、失败补偿都由代码负责Jev 只做这是不是复合这两个动作有没有依赖这种语义判断。核心实验三路由守卫——常识问题别让 Jev 硬猜用户可能突然问一句1989 年世界大赛冠军是谁。这不是设备控制让 Jev 硬猜只会瞎编。路由守卫的做法是Jev 把意图判成information_request代码检测到这个意图直接把请求转发给通用 LLM如step-5-preview回答确定性的设备控制走 Jev开放性的知识问答走 LLM。页面里还有个双路对比模式同一句话同时跑 Jev 投机管线和传统 LLM 管线面板上并排展示两边的耗时、token、决策路径。实测下来Jev 管线因为是结构化选择速度更快、结果可预测LLM 管线更灵活但成本高、输出不稳定。这个对比本身就是实验的一部分——不是为了证明谁更强而是让你看到什么场景该用谁。服务端与前端为什么要套一层代理serve_smart_home.py本身没什么魔法就做了四件事/api/jev转发到 typesafe 的 systemone 接口/api/asrSSE 流式转发 stepfun 的语音识别麦克风音频边录边出文字/api/chat转发到 stepfun 聊天模型/api/health返回当前配了哪些 key。套这层代理有两个原因一是浏览器直接调第三方接口会跨域二是 API key 绝对不能写在前端 HTML 里。如果TYPESAFE_API_KEY没配页面会自动降级到本地模拟模式让你不花一分钱也能看完整个决策流程。前端的 3D 场景和右侧决策追踪面板是演示的核心。你说一句话右侧会按顺序展示耗时阶梯 → 意图 Choice → 复合 Noul → 投机提问列表 → 最终动作 JSON。整个决策链透明可查这是和传统 LLM 黑盒输出最大的区别。如果说前面的实战 Notebook 是在练单项动作智能家居实验室就是把这些动作串成一套能跑的流程。它最值得带走的一句话是Jev 只做它擅长的语义判断执行链路上的设备白名单、动作映射、顺序编排、失败补偿全都是代码的活。这条边界划清楚了你的智能家居系统才不会因为模型一次幻觉就把门锁打开。学习总结以上就是这次组队学习所有的任务学习以下分享我的学习心得。模型不是执行者是判断者学之前总觉得大模型应该端到端地把活干了给一句话直接吐出执行结果。但 Jev 把这个边界划得很死模型只输出概率不做任何执行动作。转人工开锁退款这些事由业务代码直接完成。这个划分乍看是限制实际是保护。模型的概率是群体统计意义上的校准值单次调用哪怕 0.99 也可能翻车。把执行权留在代码手里才能配上阈值、人工兜底、回滚补偿这些真正能兜底的东西。智能家居实验里那句把咖啡烧上Jev 只负责说我觉得是开电器真正去操作咖啡机的是代码这种分工让我对AI 应用的架构有了更务实的理解。投机提问是性价比最高的一招第三章讲架构模式时看到投机扇出第五章智能家居一用就懂了一次调用把意图、设备类别、五种设备的动作全问了花一轮调用的钱拿到所有分支的答案再用代码的领域知识剪掉无关分支。它没有追求让模型更聪明而是在调用成本和信息完备性之间找到了最优解。模型多答几个问题的边际成本很低但能省掉好几轮往返。工程优化没有去刷模型能力而是在调用方式上做文章。结构化处理是对抗幻觉的根本办法第四章把 18 个实战 Notebook 归成四条路线其中结构化处理这条线让我印象最深代码先把候选范围定死比如设备只能是灯/风扇/音箱/电器/门锁动作只能是开/关/不变再让 Jev 在这个有限集合里做选择。这其实是在用工程手段约束模型的自由度。LLM 自由生成容易跑偏但如果让它在你给的选项里挑正确率和可控性都会上一个台阶。所谓Prompt Engineering很多时候不是写更花哨的提示词而是设计更合理的选择题。校准思维是一种工程素养。第一章讲校准说概率 0.8 意味着长期频率约 80%不保证单次正确。这句话看似平淡实则是整个 Jev 体系的地基。过去容易把模型输出的置信度当成正确率来用看到 0.95 就放心执行。但校准告诉你这只是个统计量。高风险场景金融、医疗、智能家居里的门锁必须设阈值、必须有 fallback、必须能人工接管。把概率和确定性分开是从用模型到用好模型的关键一步。这五章学下来最大的收获是建立了一套务实的 AI 应用观 让模型做它擅长的语义判断把确定性、安全性、可维护性留给代码和工程流程 。Jev 不是来替代工程师的而是把工程师从写一堆 prompt 调参里解放出来去设计更稳健的系统边界。
2026年10月报名参加Datawhale当月组队学习里的共学从0开始入门、了解jev本篇记载我的 Task05 学习笔记主要内容是智能家居实验。【教程地址】https://github .com/datawhalechina/jev-cookbookTask 05 智能家居实验上一篇我们把 18 个实战 Notebook 按四条路线梳理了一遍而这一篇的智能家居实验室就是这条路线最完整的一次工程落地从一句自然语言指令进来系统要判断意图、识别设备、决定动作还要处理复合命令和知识问答但每一步都不是让 LLM 自由发挥而是用 Jev 在代码预先画好的边界里做选择题。场景实验用一个 Three.js 搭的 3D 房子做模拟器5 个房间客厅、厨房、书房、卧室、玄关11 个设备5 盏灯、1 台风扇、1 个音箱、1 台咖啡机、2 把门锁。用户在输入框里说把咖啡烧上右侧面板会把整条决策链展开咖啡机随即亮起来。支撑这个演示的有三块代码01_智能家居实验.ipynb核心实验验证 Jev 三种用法——投机提问、复合命令拆分、路由守卫。serve_smart_home.py一个本地代理服务把 Jev 的 typesafe 接口、ASR语音识别、传统 LLM 聊天统一封装成 HTTP 接口顺便解决浏览器跨域和密钥不能暴露在前端的问题。smart_home_playground.html3D 交互页面支持Jev 投机 / 传统 LLM / 双路对比三种管线切换还能接麦克风语音输入。健康检查会告诉你当前配了哪些能力jevtrue, asrfalse, chatfalse表示只有 Jev 可用语音和聊天模型没配 key——这时候页面会自动降级到本地模拟不影响看决策流程。核心实验一投机提问——一次调用问完所有问题智能家居最朴素的做法是串行先问意图再问设备类别再问动作一问一答好几轮但每多一轮调用就多一次网络往返和一次出错概率。所以这一篇的第一个实验就是把所有可能要问的问题打包进一次/v1/systemone调用让 Jev 一次性回答。拿把咖啡烧上举例一次调用里塞了 6 个 question意图判断、是否复合、设备类别、以及五种设备各自的动作预测灯/风扇/音箱/电器/门锁。关键代码长这样questions [ {name: intent, type: choice, instructions: 判断用户意图, criteria: [smart_home_command, information_request, ambient]}, {name: is_compound, type: noul}, {name: category, type: choice, criteria: [light, fan, speaker, appliance, lock]}, {name: light_action, type: choice, criteria: [turn_on, turn_off, leave_unchanged]}, {name: appliance_action, type: choice, criteria: [turn_on, turn_off, leave_unchanged]}, # ...风扇、音箱、门锁同理 ]真实 API 实测上游耗时 777 ms返回的结果是question结果top 概率是否采纳intentsmart_home_command1.00✅is_compound否0.09剪枝投机categoryappliance1.00✅appliance_actionturn_on1.00✅light_actionleave_unchanged0.97剪枝投机lock_actionleave_unchanged0.97剪枝投机Jev 老老实实把 6 个问题都答了但代码只采纳 category 对应的那个设备动作。咖啡机的指令里灯和门锁的动作虽然也被预测为不变但这是投机算出来的因为代码端知道主目标是 appliance就把其他分支直接剪掉根本不进入后续执行逻辑。这就是投机提问的精髓用一次调用的成本换来所有分支的答案用代码的领域知识决定哪些答案该被当真。零额外往返也没让 Jev 承担它不该承担的编排责任。核心实验二复合命令——Noul 判断、小模型拆分、依赖排序关掉厨房的灯然后锁上书房的门这种一句话两个动作的指令投机提问就不够用了——需要先判断是不是复合命令再拆成子任务还要保证顺序。实验分三步Noul 判断是否复合Jev 用noul原语回答是/否。如果是复合进入拆分流程如果不是走单命令的投机分支。小LLM拆分让一个轻量模型把复合句切成原子指令列表例如[{room: 厨房, device: light, action: turn_off}, {room: 书房, device: lock, action: lock}]。依赖排序与并行/串行用noul判断子任务之间有没有必须先后的依赖关系。有依赖就串行执行没有就并行。这里的理论根基是偏序partial order和幂等性每个动作带action_id做幂等去重失败时回滚已完成的动作避免半执行状态。README 里明确说了一条纪律——复合命令的执行顺序、权限校验、失败补偿都由代码负责Jev 只做这是不是复合这两个动作有没有依赖这种语义判断。核心实验三路由守卫——常识问题别让 Jev 硬猜用户可能突然问一句1989 年世界大赛冠军是谁。这不是设备控制让 Jev 硬猜只会瞎编。路由守卫的做法是Jev 把意图判成information_request代码检测到这个意图直接把请求转发给通用 LLM如step-5-preview回答确定性的设备控制走 Jev开放性的知识问答走 LLM。页面里还有个双路对比模式同一句话同时跑 Jev 投机管线和传统 LLM 管线面板上并排展示两边的耗时、token、决策路径。实测下来Jev 管线因为是结构化选择速度更快、结果可预测LLM 管线更灵活但成本高、输出不稳定。这个对比本身就是实验的一部分——不是为了证明谁更强而是让你看到什么场景该用谁。服务端与前端为什么要套一层代理serve_smart_home.py本身没什么魔法就做了四件事/api/jev转发到 typesafe 的 systemone 接口/api/asrSSE 流式转发 stepfun 的语音识别麦克风音频边录边出文字/api/chat转发到 stepfun 聊天模型/api/health返回当前配了哪些 key。套这层代理有两个原因一是浏览器直接调第三方接口会跨域二是 API key 绝对不能写在前端 HTML 里。如果TYPESAFE_API_KEY没配页面会自动降级到本地模拟模式让你不花一分钱也能看完整个决策流程。前端的 3D 场景和右侧决策追踪面板是演示的核心。你说一句话右侧会按顺序展示耗时阶梯 → 意图 Choice → 复合 Noul → 投机提问列表 → 最终动作 JSON。整个决策链透明可查这是和传统 LLM 黑盒输出最大的区别。如果说前面的实战 Notebook 是在练单项动作智能家居实验室就是把这些动作串成一套能跑的流程。它最值得带走的一句话是Jev 只做它擅长的语义判断执行链路上的设备白名单、动作映射、顺序编排、失败补偿全都是代码的活。这条边界划清楚了你的智能家居系统才不会因为模型一次幻觉就把门锁打开。学习总结以上就是这次组队学习所有的任务学习以下分享我的学习心得。模型不是执行者是判断者学之前总觉得大模型应该端到端地把活干了给一句话直接吐出执行结果。但 Jev 把这个边界划得很死模型只输出概率不做任何执行动作。转人工开锁退款这些事由业务代码直接完成。这个划分乍看是限制实际是保护。模型的概率是群体统计意义上的校准值单次调用哪怕 0.99 也可能翻车。把执行权留在代码手里才能配上阈值、人工兜底、回滚补偿这些真正能兜底的东西。智能家居实验里那句把咖啡烧上Jev 只负责说我觉得是开电器真正去操作咖啡机的是代码这种分工让我对AI 应用的架构有了更务实的理解。投机提问是性价比最高的一招第三章讲架构模式时看到投机扇出第五章智能家居一用就懂了一次调用把意图、设备类别、五种设备的动作全问了花一轮调用的钱拿到所有分支的答案再用代码的领域知识剪掉无关分支。它没有追求让模型更聪明而是在调用成本和信息完备性之间找到了最优解。模型多答几个问题的边际成本很低但能省掉好几轮往返。工程优化没有去刷模型能力而是在调用方式上做文章。结构化处理是对抗幻觉的根本办法第四章把 18 个实战 Notebook 归成四条路线其中结构化处理这条线让我印象最深代码先把候选范围定死比如设备只能是灯/风扇/音箱/电器/门锁动作只能是开/关/不变再让 Jev 在这个有限集合里做选择。这其实是在用工程手段约束模型的自由度。LLM 自由生成容易跑偏但如果让它在你给的选项里挑正确率和可控性都会上一个台阶。所谓Prompt Engineering很多时候不是写更花哨的提示词而是设计更合理的选择题。校准思维是一种工程素养。第一章讲校准说概率 0.8 意味着长期频率约 80%不保证单次正确。这句话看似平淡实则是整个 Jev 体系的地基。过去容易把模型输出的置信度当成正确率来用看到 0.95 就放心执行。但校准告诉你这只是个统计量。高风险场景金融、医疗、智能家居里的门锁必须设阈值、必须有 fallback、必须能人工接管。把概率和确定性分开是从用模型到用好模型的关键一步。这五章学下来最大的收获是建立了一套务实的 AI 应用观 让模型做它擅长的语义判断把确定性、安全性、可维护性留给代码和工程流程 。Jev 不是来替代工程师的而是把工程师从写一堆 prompt 调参里解放出来去设计更稳健的系统边界。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
