企业官网建设流程全解析

我算是半个亲历者看完了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则是另一个方向。它主打的是“大动作模型”（LAM，Large 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在发布会上演示的操作流程都是提前准备好的，真实环境里稍微遇到一个弹窗、一个验证码、一个页面加载慢，流程就断了。

我把这两个产品的失败原因整理成一张表，方便对照理解：

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硬件项目的评估和复盘，把最常见的坑列成一张速查表，供读者对照自己的项目排查。

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硬件的风口一波接一波，只有活下来的产品，才有资格谈未来。