我们需要的智能设备到底是什么样

本文探讨了智能家居设备的真正价值所在,指出智能设备不应仅限于简单的远程控制,而应聚焦于提升用户生活的舒适度和便利性。通过分析智能浴霸和烟灶的实际使用场景,阐述了智能设备应如何优化用户体验,以及手机在智能家居交互中的角色。

好奇心日报做了一个关于智能设备的调研:“你在智能设备上都发现过哪些一言难尽的白痴设定?”有8412位用户发表了他们对智能设备的吐槽。

  • 智能手环硬加二十种功能,但屏幕过小大部分都用不到;
  • 语音助理“打电话给XX”老听错,却会学大象叫、会背古诗;
  • 用智能牙刷刷完牙,被它表扬“你太棒了!”;
  • 智能烹饪设备需要自己把菜洗好切好丢进去;
  • 智能音箱不能连续对话,每次必须“叮咚叮咚”“天猫精灵”

在大家的描述里,智能设备并没有我们想象中的那么智能,甚至有点“弱智”,一些在我们看来很简单、很理所应当的交互和对话,到了智能设备上,就总是有点别扭。

作为一个智能家居的从业者,我也收到过用户各种各样的吐槽,甚至我自己对某些智能设备的功能也难以理解,真正的智能设备是什么样,我们到底需要什么样的智能设备?

我们把这个问题缩小来讨论,只从家庭场景中去讨论这个问题,可能会有更清晰的结论。

(张竞成的博客http://process-z.com/blog/

第一代家庭“智能”设备

人类对于“懒惰”的追求和探索从来没有停止过,下图是世界上第一台洗衣机,它诞生于1858年,由汉密尔顿·史密斯在美国匹茨堡制成,该洗衣机由一只圆桶、桶内装有一根带有桨状叶子的直轴组成,使用时需要人摇动曲柄。

这应该是第一代家居设备了,不通电,无法和人交互,甚至还需要人操作,和今天的洗衣机比起来可能显得很愚蠢,但它的核心却从来没有变——为人省力,让洗衣变简单。

第一台洗衣机

被曲解的“智能家居”

在家居环境中,智能的意义在于让生活变得简单舒适,而不是简单的设备上云,远程控制。

我见过很多可以用手机控制的家电,比如用手机控制的浴霸、烟灶、晾衣架等等,但绝大多数都误解了“智能家居”的意义,智能的不在于可以使用手机远程遥控,而在于找到使用场景,服务于人,提供舒适生活,手机控制只是一个方式而已。

智能浴霸

比如浴霸,一般我们在洗澡前几分钟打开,等卫生间温度升高后再洗澡,所以有的商家就想让浴霸联网,可以远程预约和定时,宣传道“在回家路上打开浴霸,免去等待”。看起来省去了提前打开浴霸的麻烦,可是仔细想想真的变方便了么?

打开浴霸需要关卫生间门,一般关门时顺手就打开了浴霸,如果要远程打开,就得保证卫生间的门时关着的,而大多家庭平时都习惯开着卫生间门。加热卫生间一般只要几分钟,上班路上就打开,加热时间长还会产生安全隐患······

再比如智能烟灶,我们在使用烟灶时,操作烟灶是顺手的事,所以APP远程控制就显得很鸡肋。

如何定义智能

评判智能家居的唯一标准,就是看它能为舒适生活提供多少便利。

上面举例的浴霸,它的卖点不应该是在回家路上提前预约,因为提前打开浴霸这件事,并不能优化浴霸的使用体验,所以“预约”这个功能,就不能引起大家的共鸣。

浴霸的核心功能是加热,要热的舒服,就应该从温度下手,每个人洗澡时有不同的舒适温度,智能浴霸应该能根据不同的用户,加热到不同的温度。在洗澡过程中,室温会由于热水自然升高,人在热水中对室温的要求又会不同,在这种种条件之间维持舒适的温度,达到人体舒适的体验,才是智能。有的人不喜欢刺眼的灯光,浴霸的风暖和灯暖就应该适时切换,预加热时同时打开,快速加热,人进入卫生间后降低灯光功率,改为使用风暖,避免刺眼。

上面举例的烟灶也是一样,现在烟灶宣传的卖点主要是烟机和灶具的联动,打开灶具自动打开烟机,看起来是省了一些力,但实际对使用流程的体验提升并没有大的改善。

烟机的核心功能是管理厨房的空气,它不仅需要在做菜时向外抽气,还需要在不做菜时保证厨房空气清新。一般小区高层的排烟系统环境复杂,在饭点高峰期,整栋楼向公共排烟道排烟,如果烟机的气密性不好,或者功率不够,很可能排不出去,甚至烟气逆流,这就要求只能烟机可以根据烟道的气压,实时调整排风速率。烟机的清洗也是一件麻烦的事,一般是由专业师傅上门清洗,智能烟机应该打通这方面的服务,预约师傅上门清洗。

手机在智能家居中的意义

我认为真正的智能设备是应该摆脱手机,直接与人交互的,但在目前的技术条件下,手机和语音就是我们与设备交互的路径。

目前成熟的交互路径有3种,一是物理上的交互,如机械旋钮和按钮,二是视觉交互,即屏幕和触控,三是语音交互,如音箱。这三种交互方式各有优缺点,物理交互传递的信息少,操作简单,视觉交互传递的信息量大,但方便程度不如语音,语音交互在某种情境下不适用,且传递的信息少。智能设备应该灵活地选择这三种交互方式。

本文这里我们主要讨论手机在智能家居中的意义,即视觉交互。还以上面所说的两款产品举例,如果让我不计成本的来做,我会在上面加一块屏幕,因为要实现我们上面说的那些功能,需要大量的信息传递,只凭几个按键或语音,是不可能做到那些设置和控制的,一定需要一块屏幕来承载这些信息。

但是,增加硬件参数就要增加成本,如果要在尽量少成本的情况下让设备有屏幕怎么办呢,手机就是一个很好的屏幕。手机可以看作一个通用的屏幕,下载APP,绑定设备后,手机就成了设备的的显示屏,这块显示屏可以随处携带,而且增加这块屏对设备厂商来说的成本只有一个wifi模块的价格。

重新思考智能

智能不在于联网,也不在于用手机控制,那些只是一种实现智能的方式,真正的智能家居在于找到用户场景提供舒适的生活体验。手机在目前看来是一种方便的交互方式,可以实现远程控制和设置功能,但实现了功能也不代表就智能了,需要思考设备具体的使用场景,针对用户痛点进行优化。

(张竞成的博客http://process-z.com/blog/

<think>嗯,用户这次问的是“软件智能机器是什么样的机器”,重点在“样子”这个词。不过结合引用材料和对话历史,用户可能被“机器人外观”的描述带偏了——ta真正想问的应该是软件智能体的本质形态,而非物理外观。 注意到上次对话中用户似乎混淆了硬件机器人和软件智能体(引用[1]提到儿童机器人的外观,引用[2]则定义智能体本质)。需要明确区分:用户查询的“软件智能机器”实际是引用[2]中描述的“通过程序实现的AI实体”,没有物理形态。这里的关键矛盾在于: 1. 用户用“样子”这种具象化词汇提问 2. 但对象本质是虚拟程序 或许用户存在两个认知盲点: - 不理解智能体与硬件机器人的根本差异 - 对“软件形态”的感知缺乏具体参照物 上次提供的定义性回答可能不够直观,这次应该用更场景化的方式解释。比如用操作系统里的语音助手(隐藏进程)、游戏NPC(虚拟形象)、客服机器人(对话框)这些例子说明“形态取决于载体”——这正是引用[3]提到的应用领域交叉性。 特别要注意避免被引用[1]带偏,绝不能讨论颜色/触角等物理特征。需要强调三点: 1. 软件智能体无固定形态 2. 其呈现形式依附于交互媒介 3. 核心特征是引用[2]提到的“感知-决策-执行”闭环 用户可能需要具象化案例来理解抽象概念,考虑补充: - 手机地图导航(语音+图形界面) - 自动交易程序(无界面后台运行) 这类对比案例能直观展示“同个智能体在不同载体呈现不同形态”。 </think>软件智能机器(或称**智能体**)的本质是**程序化实体**,没有物理形态,其“样子”取决于交互界面和应用场景。以下是关键特征解析: --- ### **一、核心形态特征** 1. **无实体代码系统** - 由算法、数据模型和决策逻辑构成,存在于服务器/终端设备中 - **基础架构示例**: ```python class SoftwareAgent: def __init__(self, model): self.knowledge_base = [] # 知识库 self.decision_model = model # 决策模型 def perceive(self, data): return self.decision_model.analyze(data) # 环境感知 def act(self, decision): execute(decision) # 执行决策 ``` *▲ 代码化存在是其根本形态[^2]* 2. **交互界面决定“外在”** | 交互形式 | 呈现方式 | 案例 | |----------------|---------------------------|--------------------------| | **图形界面** | 虚拟形象/对话框 | 微软小冰(拟人化聊天机器人) | | **语音交互** | 声波+语音合成 | 智能客服语音系统 | | **API接口** | 无界面数据流 | 股票自动交易程序 | | **混合现实** | AR/VR投影 | 工业设计辅助智能体 | --- ### **二、功能形态映射(引用[3]扩展)** 1. **决策型智能体** - 形态:**数据驾驶舱**(可视化仪表盘) - 例如:企业智能决策系统,通过图表展示供应链优化方案 2. **服务型智能体** - 形态:**多模态交互界面** - 例如:银行APP智能助手,结合语音+文字+动画引导操作 3. **嵌入式智能体** - 形态:**无界面进程** - 例如:手机系统资源调度程序,隐形提升电池续航 --- ### **三、与传统硬件的本质区别** | 维度 | 软件智能体 | 硬件机器人 | |--------------|-----------------------------|--------------------------| | 存在形式 | 代码/数据流 | 物理机械结构 | | 感知方式 | API/传感器数据接入 | 物理传感器 | | “样貌”可变性 | 实时切换皮肤/形象(如游戏NPC) | 外观固定 | | 部署成本 | 云端更新即可迭代 | 需硬件改造 | > 💡 **关键认知**:用户看到的“样子”本质是**人机交互媒介的设计**(对话框、虚拟形象、数据可视化等),内核始终是执行`感知→决策→行动`循环的代码系统[^2][^3]。 --- ### 相关问题 1. 软件智能体需要怎样的运行环境支持? 2. 如何设计符合用户认知的智能体交互界面? 3. 无界面智能体(如算法交易程序)如何验证其有效性? 4. 智能体的决策过程是否可视觉化呈现?有何技术方案? [^1]: 外观设计仅适用于硬件机器人交互场景 [^2]: 智能体的核心是持续感知-决策-行动的代码实体 [^3]: 呈现形态由具体应用场景决定
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值