我算是半个亲历者看完了2024年这轮AI硬件大考。年初的时候Humane AI Pin和Rabbit R1一个比一个风光一个卖699美元加月费一个199美元预售即爆全网都在喊“手机要死了”。结果呢AI Pin被评测机构骂到停产团队连公司带专利打包卖给了惠普Rabbit R1更惨发布时吹的LAM大模型操作系统最后被扒出是个套壳安卓应用激活量都撑不起股价。这两款产品几乎成了2024年AI硬件领域最大的负面样本。但我不觉得这两款产品是纯粹的失败。它们其实把“端侧AI硬件部署”这个行业最关键的问题全部踩了一遍硬件完成度、交互范式、云端依赖、生态冷启动、场景定义。这篇文章我想从做产品的角度把这两款设备的翻车原因拆开聊顺带聊聊端侧AI硬件部署到底应该怎么落地。适合正在做AI硬件、准备做AI硬件、或者单纯想搞明白“为什么AI硬件总翻车”的朋友里面有大量我在实际项目里验证过的判断和教训直接抄作业那种。1. 内容整体设计与思路拆解1.1 这两款产品到底想解决什么问题先说Humane AI Pin。它的原始定位是“取代手机的AI伴侣”形态是一个可以别在胸前的方形小盒子没有屏幕靠激光投影在手掌上显示信息通过语音和手势交互。核心卖点是“环境计算”Ambient Computing——让AI随时在场你不需要掏出手机、解锁、打开App只需要说话信息就会出现在手掌上拍个照就能知道眼前食物的卡路里。Rabbit R1则是另一个方向。它主打的是“大动作模型”LAMLarge Action Model宣称可以学会人的操作习惯替你在App里完成订车、点餐、买票这类跨应用操作。机身是一个亮橙色的掌上设备带一个可以旋转的摄像头有一个滚轮和一个按键同样没有常规意义上的触屏。它想解决的问题是“App之间的割裂”——你不用在几十个App里来回切换一个设备帮你把事办了。单从产品概念看这两个方向的想象力都不差。问题是“解决什么问题”和“怎么解决”之间隔着一条巨大的工程鸿沟。AI Pin想替代手机但手机是一个集成了通信、支付、导航、社交、娱乐的超级终端你用一个激光投影小盒子怎么替代Rabbit R1想让LAM操控所有App但App的界面检测、意图识别、指令执行在技术上远没成熟而且第三方App根本不给你开放接口。这里面的根本矛盾在于AI硬件想在“体量更小”的设备上实现比手机更强的智能体验这本身就违背了硬件行业的物理规律。芯片算力、电池容量、散热空间、传感器数量全都受体积限制。你不可能在一个胸针大小的设备里塞进旗舰手机的硬件配置更不可能指望它在没有成熟生态的情况下凭空长出杀手级应用。1.2 我的整体复盘思路从需求倒推技术我复盘这两款产品时习惯用一条倒推链用户场景 → 交互效率 → 技术方案 → 硬件形态 → 成本与量产。先问清楚用户在什么场景下愿意多带一台设备再问这个设备的交互是不是真的比手机更快然后再考虑用什么样的技术方案支撑这个交互最后落到硬件上能不能做出来、能不能量产、能不能赚钱。用这条链去套AI Pin和Rabbit R1会发现它们全部卡在了第一环。用户没有一个高频场景是“愿意多带一台设备”的。AI Pin说“解放双手”但用户掏出手机只要3秒Rabbit R1说“帮你操作App”但用户自己操作App只要30秒而R1完成同样的操作可能要几分钟还不一定成功。高频场景不成立后面的技术再炫都是自嗨。行业里真正跑出来的AI硬件比如Meta Ray-Ban眼镜、AI翻译耳机它们的共同点是找到手机做起来很别扭的单一场景然后把这个场景做到极致。第一视角拍照、面对面翻译这些场景手机能做但做得不够好专用设备才有存在价值。AI Pin和Rabbit R1恰恰相反它们想要的是“everything”结果“nothing”做到了极致。2. 核心细节解析与实操要点2.1 Humane AI Pin的技术架构与致命伤从技术拆解看Humane AI Pin的核心组件包括高通骁龙平台、1300万像素摄像头、激光投影系统、麦克风阵列、各种环境传感器加速度计、陀螺仪、环境光传感器等然后通过eSIM联网把语音、图像等数据传到云端调用GPT-4o等大模型做理解和生成。这套架构最明显的问题有三个。第一个是激光投影在户外基本不可用。它的投影亮度在室内还行但到了阳光下面手掌上的字根本看不清。这是个典型的“实验室里没验证真实场景”的失误。你在室内演示的时候效果很好但用户真正用它的场景大概率是在路上、在室外、在移动中。想象一下你站在马路边阳光直射抬手看手掌上的投影字结果一片白茫茫这体验甚至不如掏手机看一眼屏幕。第二个是交互耗能高、效率低。AI Pin宣传“0秒唤醒”但实际上你每次都要抬手、对准手掌、等待投影稳定、然后阅读内容。这个过程比“掏出手机看一眼”要慢得多而且还要消耗电量来驱动投影系统。那个激光投影模块的功耗在生产环境里实测非常夸张直接导致续航尿崩。官方宣称续航一整天的电池在重度使用下几个小时就没电了而且设备发热严重别在胸前久了会烫。第三个是摄像头拍照的角度问题。AI Pin的宣传片里用户对着食物拍一下AI就能识别卡路里。看起来很美但那个摄像头装在机身顶部你要拍什么东西就得把整个胸口的设备对准目标动作非常别扭。你可以试一下把手机固定在胸口然后弯腰去拍一盘菜那个姿势跟做康复训练差不多。这种违背人体工学的交互设计拿着PPT演示没问题落地就是灾难。2.2 Rabbit R1的技术架构与“套壳门”Rabbit R1的技术方案更值得玩味。它使用联发科MT6765处理器Helio P35一颗2018年的低端芯片4GB内存128GB存储2.88英寸触摸屏还有一个可以360度旋转的摄像头。软件上它宣传搭载自研的Rabbit OS核心卖点是LAM大动作模型。问题就出在这个OS上。评测机构拆解后发现Rabbit R1的“自研OS”其实是一个Android AOSP的定制ROM所有App都是一个Android App的WebView封装。所谓“LAM操控App”本质上是服务端用Android自动化工具去操作云端虚拟机里的App然后把画面实时传到R1的屏幕上。这跟“AI学习你的操作习惯”的宣传天差地别。更麻烦的是LAM本身的技术不成熟。你想让AI学会操作各种App就需要针对每个App单独训练动作模型还要处理App版本升级带来的界面变化。这根本不是“教会一个模型”就能解决的事而是一个需要持续运营的工程系统。Rabbit在发布会上演示的操作流程都是提前准备好的真实环境里稍微遇到一个弹窗、一个验证码、一个页面加载慢流程就断了。我把这两个产品的失败原因整理成一张表方便对照理解维度Humane AI PinRabbit R1核心卖点激光投影 环境计算LAM大动作模型 自动操作App失效点投影户外不可用、交互效率低LAM落地不成熟、OS被扒为套壳Android硬件问题续航差、发热严重、人体工学差使用低端芯片、触控体验卡顿软件生态无第三方应用生态应用兼容性差、操作成功率低定价699美元 24美元月费199美元最终结局被惠普收购服务关停销售惨淡估值缩水2.3 端侧AI硬件部署为什么Pin和R1都要依赖云端这里得把“端侧AI硬件部署”这个概念掰开讲。很多人以为AI硬件就应该是设备本地跑大模型不依赖云端。但现实中端侧部署的核心瓶颈不是“能不能跑”而是“跑什么级别的模型”以及“跑多久”。以Humane AI Pin为例它用的是高通骁龙平台理论上支持端侧NPU推理。但GPT-4o这种级别的大模型参数量动辄千亿模型文件超过100GB本地根本没有空间放更别说跑起来。所以Pin只能走云端路线设备采集语音、图像传到云端云端的模型生成回复再传回设备播报或投影。这个链路带来的问题是延迟不可控、必须持续联网、而且每一轮会话都有API成本。实际上即使牺牲模型效果把参数量降到10B以内在2024年主流的端侧AI硬件上要流畅跑起来也很吃力。我拿一个实际例子计算过一个7B参数的量化模型INT4精度模型文件大约4GB显存占用大概5-6GB推理一个token大约需要几十毫秒到几百毫秒。听起来还行但在一个体积受限的可穿戴设备上你需要同时解决内存带宽、功耗、散热三个问题。7B模型跑一次推理的功耗大约是几瓦到十几瓦这对一个电池容量只有几百毫安时的胸针设备来说简直是灾难。所以“端侧AI硬件部署”不等于“在端侧跑大模型”。真正可行的路径是模型分层把实时性要求高、计算量小的任务放在端侧跑比如唤醒词、人脸检测、简单指令识别把复杂推理任务放到云端跑比如多轮对话、复杂决策。AI Pin和Rabbit R1的问题在于它们的核心卖点恰恰都依赖云端大模型而端侧只承担了最简单的输入采集和输出呈现。一旦网络状况不好产品就变成了一个“哑巴铁块”。3. 实操过程与核心环节实现3.1 如果让我重做AI硬件产品的存活路径聊完了失败案例我更想聊聊“如果重新做应该怎么做”。这里我给出一套个人认为更靠谱的端侧AI硬件产品落地路径基于我在真实项目里踩坑后的复盘适配各种类型AI硬件产品的早期验证。第一步定义一个低于手机使用成本的单一场景。这句话的意思是这个设备必须比手机更快、更自然。我用一个“3秒原则”来判断——如果用户完成这个动作用手机需要3秒而你的设备用了超过3秒那这个产品没有存在价值。Meta Ray-Ban眼镜就是典型的正面案例按下镜腿按键说“拍张照”2秒内完成而掏出手机、解锁、打开相机、对准拍摄需要5秒以上。这个“3秒差”就是专用设备的价值空间。第二步确认端侧能承载的最小功能闭环。不要在第一天就想端侧跑一个70B模型。先把产品里的功能分成两类一类是端侧负责的实时功能唤醒、拍摄、简单识别一类是云端负责的智能功能对话、规划、生成。端侧模型的选择标准是量化后能塞进设备的存储和内存推理延迟在1秒内连续工作功耗不能导致设备明显发热。这一步可以用开源模型快速验证比如用llama.cpp在开发板上跑通一个量化到INT4的3B/7B模型实测吞吐量和功耗。# 以llama.cpp在端侧设备上跑的典型配置示例 模型Qwen2.5-3B-Instruct-GGUF 量化q4_k_m 文件大小约1.9GB 内存占用约2.5GB 端侧推理速度约30-50 tokens/s取决于NPU/CPU 单次查询功耗约3-5W 最大允许连续推理时长受散热和电池约束建议单次不超过30秒第三步硬件形态跟随交互定义而不是反过来。AI Pin选择激光投影是因为它想“无屏化”但投影本身就是低效的交互方式。更好的思路是根据你要解决的核心场景选择最成熟的交互模态。第一视角录制就做成眼镜即时翻译就做成耳机健康监测就做成手表。不要为了创新而创新把一个已经验证有效的交互形态推翻重做。第四步做爆一款功能再考虑扩展。行业里一个常见误区是AI硬件一定要功能大而全。实际用户对AI硬件的容忍度很低他们只会为一个特别痛的点买单。你先把“第一视角拍照”做到极致再慢慢加语音助手、直播、导航。别学Rabbit R1一上来就想让AI学会操作所有App结果一个App都没操作好。3.2 端云协同架构怎么设计才合理端侧AI硬件部署绝不是“二选一”而是“怎么分”。我见过太多团队一上来就纠结“模型跑本地还是跑云端”其实正确的问题是“哪些任务必须本地哪些任务可以上云”。这里有个判断优先级延迟敏感度 数据隐私敏感度 离线可用性要求 成本约束。延迟敏感度最高的是唤醒和实时交互反馈。用户说了一句“Hey设备”设备必须在100毫秒内响应这个必须端侧做。数据隐私敏感度最高的是涉及个人生物信息、位置、健康数据的处理这类数据默认端侧优先不上云。离线可用性要求取决于产品的使用场景如果设备经常在户外、地铁、电梯里使用至少要把语音识别这样的核心链路做到端侧可跑。最后才是成本约束云端的API调用成本在用户量起来之后会非常可怕必须在产品设计初期就规划好哪些任务在端侧消化。一个验证过得比较稳的架构长这样端侧跑一个3B左右的语音/视觉理解模型负责唤醒、意图识别、简单指令执行云端跑一个70B以上或商业API的大模型负责复杂对话、推理、生成中间有一个轻量级的“路由层”决定哪些请求走端侧、哪些走云端。这个路由策略本身可以通过一个很小的端侧分类器实现延迟增加可以控制在20毫秒以内但这个分层能把云端成本降低60%-80%同时保证产品在弱网环境下依然可用。4. 常见问题与排查技巧实录4.1 问题速查表AI硬件产品最常见的5个坑我参与过多个AI硬件项目的评估和复盘把最常见的坑列成一张速查表供读者对照自己的项目排查。坑典型表现排查方法解决方案需求不真实团队自嗨用户不买单在量产前找100个目标用户做盲测砍掉非核心功能聚焦单一高频场景交互效率低于手机操作步骤比手机还多录屏对比用户完成同一任务的时间用“3秒原则”重新定义核心交互端侧算力不足本地模型跑不动或发热严重持续压力测试功耗和温升模型量化 分层计算降低端侧负载云端过度依赖断网即变砖模拟弱网环境跑测试用例核心链路端侧化云端只做增强生态冷启动没有第三方应用和服务开发早期就接触开发者社区先做一个App级功能开放API给开发者4.2 我在真实项目里踩过的“验尸”心得前两年我也参与过一个智能语音助手硬件的早期评估那款产品跟Rabbit R1有相似的问题——想做一个“不需要手机的智能终端”结果连最基本的“闹钟”和“天气查询”都没做好。当时团队在demo阶段特别兴奋因为语音识别在安静环境下的准确率非常高展示效果很惊艳。但等到拿给真实用户试用问题全冒出来了家里的电视声、厨房的流水声、窗外的车流声每一个都是语音识别的敌人用户不会像演示那样字正腔圆地说指令而是“哎那个明天天气怎么样来着”这种碎片化语言。测试到第三周项目组自己都没信心了。这个经历让我养成一个习惯任何AI硬件产品在立项之前先花一周时间做“假产品测试”。拿手机装一个像样的演示App模拟你要做的设备的交互流程让目标用户用一周。如果这一周里用户每天主动使用超过5次再考虑做真硬件。如果用户新鲜感三天就没了那这个需求大概率是伪需求做出来的硬件只会亏更多钱。4.3 端侧AI硬件部署的散热与功耗排查再分享一个关于端侧AI硬件部署的实操经验。很多团队在开发板上验证模型时跑得好好的一做进真机就翻车核心原因几乎都是散热和功耗。我建议在产品原型阶段就要做三个测试连续推理稳定性测试让设备持续跑模型推理30分钟记录帧率下降和温度曲线、电池供电波动测试模拟低电量情况下推理精度和速度的变化、场景温度测试分别在25度室内、35度户外、0度低温下测试设备表现。这三个测试会暴露绝大多数硬件的真实问题。用AI Pin举例它的激光投影模块本身就很耗电再加上持续的云端通信和传感器工作在夏天户外环境下设备表面温度会明显上升。这样的产品就算功能再炫用户也不愿意把它贴在胸口。很多时候AI硬件产品的上限不是算法、不是模型而是热设计和电池续航这两个最不性感的环节。谁先解决这两个环节谁才能真正把端侧AI硬件部署做出体验。5. 从失败样本里提炼的行业启示5.1 别把AI硬件做成手机的“低配替代品”AI Pin和Rabbit R1最大的战略失误是试图用一款非主流形态的设备去替代手机。手机是一个经过十几年进化的超级生态它在用户的位置是不可动摇的。AI硬件要做的不是替代手机而是补充手机做不好的那些缝隙场景。行业里目前跑得比较稳的方向无论是智能眼镜、AI耳机还是AI戒指都是在特定场景里“快手机一步”。AI Pin如果想活下来它的正确路线可能是放弃“替代手机”的叙事越做越小、越做越专只保留“智能助理”这一个核心能力做成手机的一个配件而不是独立终端。但融资撑不起这样的战略收缩资本市场要的是“iPhone时刻”不是“一个不错的配件”。这个教训对做端侧AI硬件部署的团队非常关键先让产品活下来再讲颠覆故事。产品能不能活下来取决于有没有人为一个“比手机快3秒”的体验付费。有了这个基础你才有资格去谈“下一代计算平台”。5.2 端侧AI硬件部署的成本结构会决定产品命运很多团队忽略了一个残酷的事实AI硬件的成本不只是BOM成本还包括云端的持续调用成本。一个依赖云端大模型的硬件设备用户每问一个问题厂商都要支付一次API费用。我做过一个粗略测算假设一个AI硬件设备日活用户每天产生100次交互每次交互平均消耗2000个token输入输出调用的模型价格按输入1美元/百万token、输出3美元/百万token计算一个用户一天的成本大约0.6美元一个月就是18美元。而AI Pin的月费是24美元看似覆盖了成本但实际用户交互量远高于100次再加上客服、带宽、存储等支出月费模式根本撑不住。这就是为什么端侧AI硬件部署会成为一个越来越重要的方向——只有把核心推理尽量下沉到端侧云端成本才能降到可控范围。未来的AI硬件产品经理必须学会算两笔账一笔是硬件BOM账一笔是云资源消耗账。两个账本都健康产品才有活下去的可能。5.3 供应链和量产能力是AI硬件最隐形的门槛AI Pin和Rabbit R1的另一个共同教训是低估了硬件供应链和量产的门槛。设计一个原型机很容易但要做到工厂量产面临的都是非常实际的问题元器件的供货周期、整机的良率、外壳的CNC加工成本、电池的安全认证、无线通信的入网许可……Humane AI Pin的创始人来自苹果但在供应链把控上依然翻了车。它的激光投影模块成本极高零部件供应不稳定导致产能上不来上市时间一拖再拖。等产品终于开售时手机上的AI功能已经进化了好几轮消费者的期待值也被抬到了一个新高度——你DELAY了这么久结果交付的东西还不如手机里的App好用。对做端侧AI硬件部署的团队来说我建议在产品定义阶段就要引入供应链视角至少要想清楚三个问题核心芯片的供货周期是多久最贵的三个元器件是什么有没有替代方案电池和充电方案是否通过了安全认证这三个问题想不清楚产品做得再好也可能死在量产前夜。我的个人反思与后续建议说实话看着AI Pin从发布到关停我内心挺复杂的。它大胆、有想象力但osted在了一些最基础的工程问题上。AI硬件这个行业从来不缺让人眼前一亮的概念缺的是把一个概念认真打磨到能用、好用、有人愿意付费的耐心。我做端侧AI硬件部署项目这几年最大的体会有两条。第一硬件产品的审美是“克制”——你会做的技术很多但用户只需要一个你最擅长的点。第二千万不能被“非手机设备”这个概念绑架——用户不在乎你是什么形态他们在乎的是“解决问题快不快、顺不顺手”。如果你现在正准备做一款AI硬件我的建议是先把手机App做好验证需求再用开发板做硬件原型验证功耗和散热最后才考虑量产和渠道。三步走下来虽然慢但每一步都在帮你排雷。AI硬件的风口一波接一波只有活下来的产品才有资格谈未来。 从AI Pin到Rabbit R1：端侧AI硬件部署为何总翻车？
我算是半个亲历者看完了2024年这轮AI硬件大考。年初的时候Humane AI Pin和Rabbit R1一个比一个风光一个卖699美元加月费一个199美元预售即爆全网都在喊“手机要死了”。结果呢AI Pin被评测机构骂到停产团队连公司带专利打包卖给了惠普Rabbit R1更惨发布时吹的LAM大模型操作系统最后被扒出是个套壳安卓应用激活量都撑不起股价。这两款产品几乎成了2024年AI硬件领域最大的负面样本。但我不觉得这两款产品是纯粹的失败。它们其实把“端侧AI硬件部署”这个行业最关键的问题全部踩了一遍硬件完成度、交互范式、云端依赖、生态冷启动、场景定义。这篇文章我想从做产品的角度把这两款设备的翻车原因拆开聊顺带聊聊端侧AI硬件部署到底应该怎么落地。适合正在做AI硬件、准备做AI硬件、或者单纯想搞明白“为什么AI硬件总翻车”的朋友里面有大量我在实际项目里验证过的判断和教训直接抄作业那种。1. 内容整体设计与思路拆解1.1 这两款产品到底想解决什么问题先说Humane AI Pin。它的原始定位是“取代手机的AI伴侣”形态是一个可以别在胸前的方形小盒子没有屏幕靠激光投影在手掌上显示信息通过语音和手势交互。核心卖点是“环境计算”Ambient Computing——让AI随时在场你不需要掏出手机、解锁、打开App只需要说话信息就会出现在手掌上拍个照就能知道眼前食物的卡路里。Rabbit R1则是另一个方向。它主打的是“大动作模型”LAMLarge Action Model宣称可以学会人的操作习惯替你在App里完成订车、点餐、买票这类跨应用操作。机身是一个亮橙色的掌上设备带一个可以旋转的摄像头有一个滚轮和一个按键同样没有常规意义上的触屏。它想解决的问题是“App之间的割裂”——你不用在几十个App里来回切换一个设备帮你把事办了。单从产品概念看这两个方向的想象力都不差。问题是“解决什么问题”和“怎么解决”之间隔着一条巨大的工程鸿沟。AI Pin想替代手机但手机是一个集成了通信、支付、导航、社交、娱乐的超级终端你用一个激光投影小盒子怎么替代Rabbit R1想让LAM操控所有App但App的界面检测、意图识别、指令执行在技术上远没成熟而且第三方App根本不给你开放接口。这里面的根本矛盾在于AI硬件想在“体量更小”的设备上实现比手机更强的智能体验这本身就违背了硬件行业的物理规律。芯片算力、电池容量、散热空间、传感器数量全都受体积限制。你不可能在一个胸针大小的设备里塞进旗舰手机的硬件配置更不可能指望它在没有成熟生态的情况下凭空长出杀手级应用。1.2 我的整体复盘思路从需求倒推技术我复盘这两款产品时习惯用一条倒推链用户场景 → 交互效率 → 技术方案 → 硬件形态 → 成本与量产。先问清楚用户在什么场景下愿意多带一台设备再问这个设备的交互是不是真的比手机更快然后再考虑用什么样的技术方案支撑这个交互最后落到硬件上能不能做出来、能不能量产、能不能赚钱。用这条链去套AI Pin和Rabbit R1会发现它们全部卡在了第一环。用户没有一个高频场景是“愿意多带一台设备”的。AI Pin说“解放双手”但用户掏出手机只要3秒Rabbit R1说“帮你操作App”但用户自己操作App只要30秒而R1完成同样的操作可能要几分钟还不一定成功。高频场景不成立后面的技术再炫都是自嗨。行业里真正跑出来的AI硬件比如Meta Ray-Ban眼镜、AI翻译耳机它们的共同点是找到手机做起来很别扭的单一场景然后把这个场景做到极致。第一视角拍照、面对面翻译这些场景手机能做但做得不够好专用设备才有存在价值。AI Pin和Rabbit R1恰恰相反它们想要的是“everything”结果“nothing”做到了极致。2. 核心细节解析与实操要点2.1 Humane AI Pin的技术架构与致命伤从技术拆解看Humane AI Pin的核心组件包括高通骁龙平台、1300万像素摄像头、激光投影系统、麦克风阵列、各种环境传感器加速度计、陀螺仪、环境光传感器等然后通过eSIM联网把语音、图像等数据传到云端调用GPT-4o等大模型做理解和生成。这套架构最明显的问题有三个。第一个是激光投影在户外基本不可用。它的投影亮度在室内还行但到了阳光下面手掌上的字根本看不清。这是个典型的“实验室里没验证真实场景”的失误。你在室内演示的时候效果很好但用户真正用它的场景大概率是在路上、在室外、在移动中。想象一下你站在马路边阳光直射抬手看手掌上的投影字结果一片白茫茫这体验甚至不如掏手机看一眼屏幕。第二个是交互耗能高、效率低。AI Pin宣传“0秒唤醒”但实际上你每次都要抬手、对准手掌、等待投影稳定、然后阅读内容。这个过程比“掏出手机看一眼”要慢得多而且还要消耗电量来驱动投影系统。那个激光投影模块的功耗在生产环境里实测非常夸张直接导致续航尿崩。官方宣称续航一整天的电池在重度使用下几个小时就没电了而且设备发热严重别在胸前久了会烫。第三个是摄像头拍照的角度问题。AI Pin的宣传片里用户对着食物拍一下AI就能识别卡路里。看起来很美但那个摄像头装在机身顶部你要拍什么东西就得把整个胸口的设备对准目标动作非常别扭。你可以试一下把手机固定在胸口然后弯腰去拍一盘菜那个姿势跟做康复训练差不多。这种违背人体工学的交互设计拿着PPT演示没问题落地就是灾难。2.2 Rabbit R1的技术架构与“套壳门”Rabbit R1的技术方案更值得玩味。它使用联发科MT6765处理器Helio P35一颗2018年的低端芯片4GB内存128GB存储2.88英寸触摸屏还有一个可以360度旋转的摄像头。软件上它宣传搭载自研的Rabbit OS核心卖点是LAM大动作模型。问题就出在这个OS上。评测机构拆解后发现Rabbit R1的“自研OS”其实是一个Android AOSP的定制ROM所有App都是一个Android App的WebView封装。所谓“LAM操控App”本质上是服务端用Android自动化工具去操作云端虚拟机里的App然后把画面实时传到R1的屏幕上。这跟“AI学习你的操作习惯”的宣传天差地别。更麻烦的是LAM本身的技术不成熟。你想让AI学会操作各种App就需要针对每个App单独训练动作模型还要处理App版本升级带来的界面变化。这根本不是“教会一个模型”就能解决的事而是一个需要持续运营的工程系统。Rabbit在发布会上演示的操作流程都是提前准备好的真实环境里稍微遇到一个弹窗、一个验证码、一个页面加载慢流程就断了。我把这两个产品的失败原因整理成一张表方便对照理解维度Humane AI PinRabbit R1核心卖点激光投影 环境计算LAM大动作模型 自动操作App失效点投影户外不可用、交互效率低LAM落地不成熟、OS被扒为套壳Android硬件问题续航差、发热严重、人体工学差使用低端芯片、触控体验卡顿软件生态无第三方应用生态应用兼容性差、操作成功率低定价699美元 24美元月费199美元最终结局被惠普收购服务关停销售惨淡估值缩水2.3 端侧AI硬件部署为什么Pin和R1都要依赖云端这里得把“端侧AI硬件部署”这个概念掰开讲。很多人以为AI硬件就应该是设备本地跑大模型不依赖云端。但现实中端侧部署的核心瓶颈不是“能不能跑”而是“跑什么级别的模型”以及“跑多久”。以Humane AI Pin为例它用的是高通骁龙平台理论上支持端侧NPU推理。但GPT-4o这种级别的大模型参数量动辄千亿模型文件超过100GB本地根本没有空间放更别说跑起来。所以Pin只能走云端路线设备采集语音、图像传到云端云端的模型生成回复再传回设备播报或投影。这个链路带来的问题是延迟不可控、必须持续联网、而且每一轮会话都有API成本。实际上即使牺牲模型效果把参数量降到10B以内在2024年主流的端侧AI硬件上要流畅跑起来也很吃力。我拿一个实际例子计算过一个7B参数的量化模型INT4精度模型文件大约4GB显存占用大概5-6GB推理一个token大约需要几十毫秒到几百毫秒。听起来还行但在一个体积受限的可穿戴设备上你需要同时解决内存带宽、功耗、散热三个问题。7B模型跑一次推理的功耗大约是几瓦到十几瓦这对一个电池容量只有几百毫安时的胸针设备来说简直是灾难。所以“端侧AI硬件部署”不等于“在端侧跑大模型”。真正可行的路径是模型分层把实时性要求高、计算量小的任务放在端侧跑比如唤醒词、人脸检测、简单指令识别把复杂推理任务放到云端跑比如多轮对话、复杂决策。AI Pin和Rabbit R1的问题在于它们的核心卖点恰恰都依赖云端大模型而端侧只承担了最简单的输入采集和输出呈现。一旦网络状况不好产品就变成了一个“哑巴铁块”。3. 实操过程与核心环节实现3.1 如果让我重做AI硬件产品的存活路径聊完了失败案例我更想聊聊“如果重新做应该怎么做”。这里我给出一套个人认为更靠谱的端侧AI硬件产品落地路径基于我在真实项目里踩坑后的复盘适配各种类型AI硬件产品的早期验证。第一步定义一个低于手机使用成本的单一场景。这句话的意思是这个设备必须比手机更快、更自然。我用一个“3秒原则”来判断——如果用户完成这个动作用手机需要3秒而你的设备用了超过3秒那这个产品没有存在价值。Meta Ray-Ban眼镜就是典型的正面案例按下镜腿按键说“拍张照”2秒内完成而掏出手机、解锁、打开相机、对准拍摄需要5秒以上。这个“3秒差”就是专用设备的价值空间。第二步确认端侧能承载的最小功能闭环。不要在第一天就想端侧跑一个70B模型。先把产品里的功能分成两类一类是端侧负责的实时功能唤醒、拍摄、简单识别一类是云端负责的智能功能对话、规划、生成。端侧模型的选择标准是量化后能塞进设备的存储和内存推理延迟在1秒内连续工作功耗不能导致设备明显发热。这一步可以用开源模型快速验证比如用llama.cpp在开发板上跑通一个量化到INT4的3B/7B模型实测吞吐量和功耗。# 以llama.cpp在端侧设备上跑的典型配置示例 模型Qwen2.5-3B-Instruct-GGUF 量化q4_k_m 文件大小约1.9GB 内存占用约2.5GB 端侧推理速度约30-50 tokens/s取决于NPU/CPU 单次查询功耗约3-5W 最大允许连续推理时长受散热和电池约束建议单次不超过30秒第三步硬件形态跟随交互定义而不是反过来。AI Pin选择激光投影是因为它想“无屏化”但投影本身就是低效的交互方式。更好的思路是根据你要解决的核心场景选择最成熟的交互模态。第一视角录制就做成眼镜即时翻译就做成耳机健康监测就做成手表。不要为了创新而创新把一个已经验证有效的交互形态推翻重做。第四步做爆一款功能再考虑扩展。行业里一个常见误区是AI硬件一定要功能大而全。实际用户对AI硬件的容忍度很低他们只会为一个特别痛的点买单。你先把“第一视角拍照”做到极致再慢慢加语音助手、直播、导航。别学Rabbit R1一上来就想让AI学会操作所有App结果一个App都没操作好。3.2 端云协同架构怎么设计才合理端侧AI硬件部署绝不是“二选一”而是“怎么分”。我见过太多团队一上来就纠结“模型跑本地还是跑云端”其实正确的问题是“哪些任务必须本地哪些任务可以上云”。这里有个判断优先级延迟敏感度 数据隐私敏感度 离线可用性要求 成本约束。延迟敏感度最高的是唤醒和实时交互反馈。用户说了一句“Hey设备”设备必须在100毫秒内响应这个必须端侧做。数据隐私敏感度最高的是涉及个人生物信息、位置、健康数据的处理这类数据默认端侧优先不上云。离线可用性要求取决于产品的使用场景如果设备经常在户外、地铁、电梯里使用至少要把语音识别这样的核心链路做到端侧可跑。最后才是成本约束云端的API调用成本在用户量起来之后会非常可怕必须在产品设计初期就规划好哪些任务在端侧消化。一个验证过得比较稳的架构长这样端侧跑一个3B左右的语音/视觉理解模型负责唤醒、意图识别、简单指令执行云端跑一个70B以上或商业API的大模型负责复杂对话、推理、生成中间有一个轻量级的“路由层”决定哪些请求走端侧、哪些走云端。这个路由策略本身可以通过一个很小的端侧分类器实现延迟增加可以控制在20毫秒以内但这个分层能把云端成本降低60%-80%同时保证产品在弱网环境下依然可用。4. 常见问题与排查技巧实录4.1 问题速查表AI硬件产品最常见的5个坑我参与过多个AI硬件项目的评估和复盘把最常见的坑列成一张速查表供读者对照自己的项目排查。坑典型表现排查方法解决方案需求不真实团队自嗨用户不买单在量产前找100个目标用户做盲测砍掉非核心功能聚焦单一高频场景交互效率低于手机操作步骤比手机还多录屏对比用户完成同一任务的时间用“3秒原则”重新定义核心交互端侧算力不足本地模型跑不动或发热严重持续压力测试功耗和温升模型量化 分层计算降低端侧负载云端过度依赖断网即变砖模拟弱网环境跑测试用例核心链路端侧化云端只做增强生态冷启动没有第三方应用和服务开发早期就接触开发者社区先做一个App级功能开放API给开发者4.2 我在真实项目里踩过的“验尸”心得前两年我也参与过一个智能语音助手硬件的早期评估那款产品跟Rabbit R1有相似的问题——想做一个“不需要手机的智能终端”结果连最基本的“闹钟”和“天气查询”都没做好。当时团队在demo阶段特别兴奋因为语音识别在安静环境下的准确率非常高展示效果很惊艳。但等到拿给真实用户试用问题全冒出来了家里的电视声、厨房的流水声、窗外的车流声每一个都是语音识别的敌人用户不会像演示那样字正腔圆地说指令而是“哎那个明天天气怎么样来着”这种碎片化语言。测试到第三周项目组自己都没信心了。这个经历让我养成一个习惯任何AI硬件产品在立项之前先花一周时间做“假产品测试”。拿手机装一个像样的演示App模拟你要做的设备的交互流程让目标用户用一周。如果这一周里用户每天主动使用超过5次再考虑做真硬件。如果用户新鲜感三天就没了那这个需求大概率是伪需求做出来的硬件只会亏更多钱。4.3 端侧AI硬件部署的散热与功耗排查再分享一个关于端侧AI硬件部署的实操经验。很多团队在开发板上验证模型时跑得好好的一做进真机就翻车核心原因几乎都是散热和功耗。我建议在产品原型阶段就要做三个测试连续推理稳定性测试让设备持续跑模型推理30分钟记录帧率下降和温度曲线、电池供电波动测试模拟低电量情况下推理精度和速度的变化、场景温度测试分别在25度室内、35度户外、0度低温下测试设备表现。这三个测试会暴露绝大多数硬件的真实问题。用AI Pin举例它的激光投影模块本身就很耗电再加上持续的云端通信和传感器工作在夏天户外环境下设备表面温度会明显上升。这样的产品就算功能再炫用户也不愿意把它贴在胸口。很多时候AI硬件产品的上限不是算法、不是模型而是热设计和电池续航这两个最不性感的环节。谁先解决这两个环节谁才能真正把端侧AI硬件部署做出体验。5. 从失败样本里提炼的行业启示5.1 别把AI硬件做成手机的“低配替代品”AI Pin和Rabbit R1最大的战略失误是试图用一款非主流形态的设备去替代手机。手机是一个经过十几年进化的超级生态它在用户的位置是不可动摇的。AI硬件要做的不是替代手机而是补充手机做不好的那些缝隙场景。行业里目前跑得比较稳的方向无论是智能眼镜、AI耳机还是AI戒指都是在特定场景里“快手机一步”。AI Pin如果想活下来它的正确路线可能是放弃“替代手机”的叙事越做越小、越做越专只保留“智能助理”这一个核心能力做成手机的一个配件而不是独立终端。但融资撑不起这样的战略收缩资本市场要的是“iPhone时刻”不是“一个不错的配件”。这个教训对做端侧AI硬件部署的团队非常关键先让产品活下来再讲颠覆故事。产品能不能活下来取决于有没有人为一个“比手机快3秒”的体验付费。有了这个基础你才有资格去谈“下一代计算平台”。5.2 端侧AI硬件部署的成本结构会决定产品命运很多团队忽略了一个残酷的事实AI硬件的成本不只是BOM成本还包括云端的持续调用成本。一个依赖云端大模型的硬件设备用户每问一个问题厂商都要支付一次API费用。我做过一个粗略测算假设一个AI硬件设备日活用户每天产生100次交互每次交互平均消耗2000个token输入输出调用的模型价格按输入1美元/百万token、输出3美元/百万token计算一个用户一天的成本大约0.6美元一个月就是18美元。而AI Pin的月费是24美元看似覆盖了成本但实际用户交互量远高于100次再加上客服、带宽、存储等支出月费模式根本撑不住。这就是为什么端侧AI硬件部署会成为一个越来越重要的方向——只有把核心推理尽量下沉到端侧云端成本才能降到可控范围。未来的AI硬件产品经理必须学会算两笔账一笔是硬件BOM账一笔是云资源消耗账。两个账本都健康产品才有活下去的可能。5.3 供应链和量产能力是AI硬件最隐形的门槛AI Pin和Rabbit R1的另一个共同教训是低估了硬件供应链和量产的门槛。设计一个原型机很容易但要做到工厂量产面临的都是非常实际的问题元器件的供货周期、整机的良率、外壳的CNC加工成本、电池的安全认证、无线通信的入网许可……Humane AI Pin的创始人来自苹果但在供应链把控上依然翻了车。它的激光投影模块成本极高零部件供应不稳定导致产能上不来上市时间一拖再拖。等产品终于开售时手机上的AI功能已经进化了好几轮消费者的期待值也被抬到了一个新高度——你DELAY了这么久结果交付的东西还不如手机里的App好用。对做端侧AI硬件部署的团队来说我建议在产品定义阶段就要引入供应链视角至少要想清楚三个问题核心芯片的供货周期是多久最贵的三个元器件是什么有没有替代方案电池和充电方案是否通过了安全认证这三个问题想不清楚产品做得再好也可能死在量产前夜。我的个人反思与后续建议说实话看着AI Pin从发布到关停我内心挺复杂的。它大胆、有想象力但osted在了一些最基础的工程问题上。AI硬件这个行业从来不缺让人眼前一亮的概念缺的是把一个概念认真打磨到能用、好用、有人愿意付费的耐心。我做端侧AI硬件部署项目这几年最大的体会有两条。第一硬件产品的审美是“克制”——你会做的技术很多但用户只需要一个你最擅长的点。第二千万不能被“非手机设备”这个概念绑架——用户不在乎你是什么形态他们在乎的是“解决问题快不快、顺不顺手”。如果你现在正准备做一款AI硬件我的建议是先把手机App做好验证需求再用开发板做硬件原型验证功耗和散热最后才考虑量产和渠道。三步走下来虽然慢但每一步都在帮你排雷。AI硬件的风口一波接一波只有活下来的产品才有资格谈未来。