最近 AI 硬件圈最热的讨论都围绕着一个奇怪的传闻OpenAI 要和苹果前首席设计师 Jony Ive 合作推出一款没有屏幕的 AI 硬件设备渲染图里它看起来像一个「甜甜圈」。说实话第一次看到这个消息我的反应和你一样为什么是这个形状为什么连屏幕都不要这篇文章不打算聊八卦而是把这件事拆成一个技术问题来看。我会从产品定位、语音交互闭环、端侧 AI 部署、开发者接入这几个维度展开说说无屏 AI 硬件到底怎么做、怎么连、怎么调试以及 OpenAI 选择「甜甜圈」形态背后的工程逻辑。如果你正在做语音产品、端侧 AI 部署或者想提前了解 AI 硬件开发的技术方向这篇文章应该对你有帮助。先说清楚一个前提目前 OpenAI 官方并没有正式发布这款产品所有形态描述都来自公开报道和供应链消息。因此下面凡是产品层面的细节我都以“公开报道 技术推理”的方式呈现不当作官方参数使用。1. 背景与产品解读OpenAI 首款 AI 硬件究竟想解决什么问题1.1 甜甜圈形态与当前公开信息综合已有的外媒报道、设计专利和供应链消息这款设备比较确定的设计倾向是没有屏幕外形接近环形或椭圆形中间有孔看起来确实像甜甜圈大概率采用可穿戴或随身携带的形态。为什么明明没有屏幕还要做成环形这里有一个很多人忽略的工程理由环形结构在空间上天然适合“穿戴”。它可以当戒指、挂脖子上、夹在背包肩带上中孔本身就是一个固定的物理作用点。相比需要握持的方形设备环形设计在“不占用注意力”的场景下明显更合理。从体验角度看这台设备的核心交互是语音。你不需要解锁手机、不需要打开 App、不需要输入文字开口说话就能完成操作。这种“环境级交互”和手机上的 App 级交互有本质区别也决定了它不能用传统硬件设计的思路来理解。1.2 模型公司为什么亲自下场做硬件OpenAI 的核心是模型和 API按道理它只需要把 GPT 能力开放出来让硬件厂商调用就够了。但它选择自己下场可以从三个层面理解第一入口焦虑。手机是超级入口但在手机上AI 助手被困在 App 里。用户和助手之间隔着解锁、打开 App、输入点按的过程。OpenAI 需要一种“不需要解锁就能对话”的入口否则再强的模型也只是别人 App 里的一个功能。第二交互数据闭环。语音交互产生的真实对话数据、环境音频、用户习惯是优化模型的宝贵资源。第三方硬件虽然也能调用 API但数据不出第三方设备OpenAI 很难拿到关键信息来迭代模型。第三定义“AI 原生交互”的标准。屏幕上的 AI 交互本质上还是 App 时代的产品逻辑。无屏语音交互才是真正意义上的 AI 原生设备体验OpenAI 想亲手定义这个标准。这和当年苹果定义触屏交互是同一个逻辑。1.3 无屏不是退步而是降低注意力成本很多人第一反应是没有屏幕怎么看消息、怎么付款、怎么刷视频这个提问预设了“设备等于屏幕”的心智模型。但无屏设备并不想替代手机它想替代的是“用户掏手机之前的那个念头”。语音设备的核心价值是降低交互成本。正常情况下从“想设置一个提醒”到“设置完成”手机上的操作路径是亮屏、解锁、打开提醒事项、新建、输入内容、确认至少五六个步骤。而无屏语音设备只需要一句话“帮我 20 分钟后提醒我给客户回电话。”从工程角度看这是交互范式的迁移两类设备的定位完全不同维度屏幕设备无屏语音设备输入方式文字、手势、触控语音、环境感知输出方式视觉文字/图像听觉TTS为主注意力占用高必须盯着看低可以边做别的事典型场景阅读、浏览、游戏提醒、查询、控制失败恢复信息可回看需要对话式确认这种设计也符合大模型的能力边界。大模型在复杂任务上的推理能力很强但“把复杂信息读出来”这件事更适合用 TTS 做成短提示而不是朗读长文本。所以无屏设备适合做短任务不适合做沉浸式内容消费。它是在需求发生的那一刻用最低成本把问题解决掉而不是把信息堆到你面前。2. 无屏硬件的核心技术拆解2.1 一条完整的语音交互闭环无屏设备的所有价值都依赖语音闭环是否好用。整个链路可以拆成下面几步用户说话 ↓ 麦克风阵列采集端侧 ↓ 唤醒词检测端侧常驻低功耗 ↓ 语音活动检测 VAD 回声消除 降噪端侧 ↓ ASR 语音转文字端侧轻量模型或云端 Whisper ↓ LLM 意图理解 / 任务执行云端配合 Function Calling 或 Agent ↓ TTS 文字转语音云端流式合成或端侧小模型 ↓ 扬声器播放每一段都有明确的工程指标要求唤醒词检测必须常驻在麦克风上功耗要极低误唤醒率要压到每天几次以内。VAD 和降噪在嘈杂环境下要把说话人声音和背景噪声分开否则后续 ASR 全是噪音。ASR中文场景下准确率要足够高人名、地名、品牌这类专有名词都要能识别。LLM响应延迟直接影响体验。用户感知到的“快”要求首字 TTS 输出在 800ms 左右出现而不是等完整回答生成完再播放。TTS要流畅自然支持流式输出不能把音频累计到最后一次性播。这里最难的是“端到端延迟”。单独看每个环节都不算慢但串起来就容易超过用户的耐心阈值。所以无屏设备的工程重点不是单点优化而是全链路协同。2.2 端侧与云侧一颗芯片和一个大脑的分工无屏设备的计算资源和电池空间都非常有限不可能在设备里跑一个完整的大参数模型。所以它的架构一定是“端侧 云侧”的混合架构端侧负责唤醒词、VAD、降噪、部分轻量 ASR、简单命令词识别、离线兜底回复。云侧负责复杂语义理解、多轮对话、工具调用、代码执行、联网搜索、高质量 TTS 合成。这个分工有几个关键设计点。第一断网要有兜底。如果断了网设备就是一块砖体验一定很差。技术上需要内置一批离线命令词比如“关灯”“打开空调”“现在几点”这些可以直接在本地执行。更复杂的问题可以缓存到网络恢复后处理。第二延迟预算要严格划分。在端侧把唤醒和 VAD 做好能帮云端争取时间。比如用户说完“嘿小O”之后设备可以先预连接云端把会话通道提前建好等 ASR 文本一出来直接丢给 LLM而不是等识别完成后再建立连接。这种“预建连”的优化能让体感延迟下降一个量级。第三端侧模型尺寸有限但可以针对场景压缩。在设备上跑一个 1B 到 3B 参数的对话模型或者只跑一个意图分类模型把“用户这句话应该理解成什么”先弄清楚再交给云侧大模型做深层推理是业界比较常见的做法。纯端侧方案和纯云端方案都各有短板混合架构是当前最稳妥的选择。2.3 环形设计的工程意义甜甜圈造型不只是为了好看它对硬件工程有实际影响。环形结构可以把麦克风阵列均匀分布在圆周上实现接近 360 度的拾音范围不用像手机那样依赖某个方向的麦克风。中孔位置可以用来固定挂绳、指环或其他佩戴结构降低设备被误触摔落的风险。中间镂空减少了外壳材料用量也让内部结构自然形成环形 PCB 布局有利于天线走线和电池排布。更重要的是环形形态在视觉上“不像手机”这可以降低用户把它当成屏幕设备的预期引导用户主动使用语音交互。产品设计上有一种做法叫“形态即引导”甜甜圈的造型本身就是最好的产品说明书。当然环形也带来不小的难题内部空间挤电池容量、扬声器尺寸、散热设计全都受限。所以这类设备的续航和音质注定没法跟手机比。如何在有限空间里平衡体验是硬件团队的第一课题。3. 开发者视角像接 API 一样接入 AI 硬件既然 OpenAI 做硬件那它对开发者一定是开放 API 的。对开发者来说真正的机会在于“把设备当成大模型的一个传感器和执行器”。下面我们用 Python 模拟一条无屏语音设备的完整交互链路。3.1 准备环境你需要一个可用的 OpenAI API Key以及安装好openaiPython SDK。如果你还没有安装 SDK先执行pip install openai本文示例环境Python 3.10 及以上版本openai SDK 1.x本地音频文件用于模拟麦克风输入注意下面代码调用的是 OpenAI 官方 API 的常规用法模型名称和接口字段在不同版本间可能有差异实际使用时请以官方文档为准。3.2 用 Whisper 把语音转成文本先写一个模拟 ASR 的函数把音频文件转成文字# 文件路径src/asr.py from openai import OpenAI client OpenAI(api_keysk-YOUR_KEY) # 实际使用请从环境变量读取 def speech_to_text(audio_path: str) - str: 把本地音频文件转成文本模拟端侧或云端 ASR with open(audio_path, rb) as audio_file: response client.audio.transcriptions.create( modelwhisper-1, fileaudio_file, languagezh, ) return response.text if __name__ __main__: text speech_to_text(test_voice.wav) print(识别结果:, text)真实设备上ASR 可以在端侧完成也可以在云端完成。端侧方案延迟低、隐私好但对芯片算力要求更高云端方案精度通常更好代价是依赖网络。作为开发者你接入时只需要拿到最终的文本结果底层的 ASR 部署方式对上层业务是透明的。3.3 流式对话边生成边播报无屏设备最忌讳“全部生成完再播放”用户等不了。正确做法是用流式接口接收 token实时送给 TTS 合成器。下面是一个流式对话示例# 文件路径src/chat_stream.py from openai import OpenAI client OpenAI(api_keysk-YOUR_KEY) def ask_with_stream(user_text: str): 流式请求 LLM边生成边打印实际设备中这里会把 token 送入 TTS stream client.chat.completions.create( modelgpt-4o-mini, messages[ { role: system, content: ( 你是一个运行在无屏语音设备上的助手。\n 规则1. 回答控制在 3 句话以内2. 不使用 Markdown 格式 3. 涉及删除、付款、发送消息等操作必须先反问用户确认。 ), }, {role: user, content: user_text}, ], streamTrue, ) collected [] for chunk in stream: if chunk.choices and chunk.choices[0].delta.content: token chunk.choices[0].delta.content collected.append(token) # 真实设备这里把 token 送入 TTS 流式合成器播放 print(token, end, flushTrue) return .join(collected) if __name__ __main__: reply ask_with_stream(帮我 20 分钟后提醒我给客户回电话) print(\n完整回复:, reply)这里的关键点是streamTrue。通过流式返回用户听到“第一个字”的时间被大幅提前而不是等所有内容生成完。体感延迟从“几秒冷启动”变成“像电话对面的人正在开口说话”这对语音设备来说是天壤之别。3.4 Function Calling让设备真正“动手”无屏设备只回答问题是不够的它需要能设置提醒、发消息、控制智能家居。这就需要 Function Calling函数调用能力。LLM 在对话中先判断需要调用什么工具返回结构化参数设备端再真正执行。# 文件路径src/function_calling.py import json from openai import OpenAI client OpenAI(api_keysk-YOUR_KEY) tools [ { type: function, function: { name: set_reminder, description: 设置一个定时提醒, parameters: { type: object, properties: { time: {type: string, description: 提醒时间如 20分钟后/18:00}, content: {type: string, description: 提醒内容}, }, required: [time, content], }, }, } ] def run_device_loop(user_text: str): response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: user_text}], toolstools, tool_choiceauto, ) msg response.choices[0].message if msg.tool_calls: for tool_call in msg.tool_calls: args json.loads(tool_call.function.arguments) print(f[设备执行] 工具{tool_call.function.name}, 参数{args}) # 这里把 args 传给设备端真实函数例如写入本地提醒数据库 return args else: return msg.content if __name__ __main__: result run_device_loop(帮我 20 分钟后提醒我给客户回电话) if isinstance(result, dict): print([设备侧] 提醒已写入本地存储:, result) else: print([设备侧] 无需调用工具直接回答:, result)这个流程的核心价值在于设备本身不需要理解“20分钟后”怎么换算也不需要记住所有业务逻辑它只需要把 LLM 输出的参数交给本地执行模块。也就是说无屏设备的软件升级本质上是模型能力和工具集的升级而不是重写设备固件。这种架构让设备的能力边界可以持续扩展。3.5 从 Function Calling 到 Agent 化执行如果你关注 OpenAI 最近的动态会发现它已经把 Codex 这类产品做成了“模型能力 代码执行 工具调用”的 Agent 形态相关 harness 也已在 GitHub 上开源。搜索词里频繁出现的“OpenAI 开放 Codex harness”本质上就是把 Codex 的调度框架开放给开发者让大家基于它构建自己的 Agent。这件事对 AI 硬件意义很大。想象一下设备端的 Function Calling 如果升级成 Agent 式执行它的能力边界就从“设置提醒、发消息”扩展到“帮我订一张周五的高铁票如果没票就买后面一班并把座位偏好设为靠窗”这种多步骤长程任务。无屏设备的语音入口正好是这类 Agent 最自然的触发方式。所以给 AI 硬件做开发不要把注意力只放在“对话”上更要关注模型能不能调用工具、能不能执行多步任务、能不能在出错时自行回滚重试。这才是 OpenAI 做硬件的终局竞争力。4. 端侧 AI 硬件部署的关键技术清单4.1 模型选型能上端侧的先上端侧无屏设备的端侧模型通常需要覆盖三类能力ASR 模型比如 Whisper 的 tiny 或 base 版本或者更小的端侧语音识别模型。TTS 模型端侧 TTS 采用轻量合成方案优先保证延迟和自然度的平衡。意图分类或小对话模型参数规模通常控制在 1B 到 3B只负责意图识别和简单问答。部署原则是能离线完成的尽量不要拖到云端。这不仅是考虑断网可用更是把云端通道留给真正需要大模型推理的任务。端侧模型每多扛住一个场景云端压力就小一分用户等待时间也短一分。4.2 量化是端侧模型落地的核心手段要在低功耗芯片上跑模型量化几乎是必选项。常见的量化位宽对模型体积的影响可以参考下表量化方式权重体积精度损失适用场景FP16原始一半极小算力较强的 SoCINT8原始四分之一较小主流端侧 NPUINT4原始八分之一明显超低功耗或小内存设备以 1B 参数模型为例FP16 权重约 2GBINT8 约 1GBINT4 约 0.5GB。对于内部空间有限的甜甜圈设备0.5GB 到 1GB 的权重规模才有机会放进内存。实际工程中还需要结合模型蒸馏、剪枝等手段一起做才能在不明显损失效果的前提下把模型塞进设备。4.3 功耗、内存与散热是三个硬约束端侧硬件存在一个“性能、功耗、体积”的不可能三角功耗设备体积小电池容量有限常驻监听的唤醒词功耗必须压到极低。如果整机平均功耗压不下来用户一天一充甚至半天一充产品很难被接受。内存环形 PCB 内部空间小DDR 容量有限。模型推理、音频缓冲、系统运行要共享内存内存规划要在项目早期就定下来。散热无风扇设计下芯片持续满载会触发降频进而影响响应速度。所以设备侧的 AI 任务尽量“短平快”复杂任务交给云端。这意味着做端侧 AI 硬件部署不能只把模型跑通就完事还要建立一套“延迟、功耗、温度”的可观测体系在量产前充分测试不同场景下的功耗曲线。这几个指标任何一项不达标产品体验都会大打折扣。4.4 安全与隐私API Key 不能裸存无屏设备本质上是一个“口袋里的麦克风”隐私和安全风险比手机更高。这里特别要说一下 API Key 管理因为搜索结果里很多人都在搜 OpenAI API Key 的获取方法但拿到 Key 之后怎么安全地用才是工程关键。第一API Key 绝不能硬编码在固件里。它应该存储在 TEE可信执行环境或安全芯片中通过密钥注入方式做初始化。即使设备被拆解也不应该能直接读出 Key。第二更安全的做法是服务端代理。设备端不直接持有长期 Key而是持有一个短期设备 Token由你的服务端校验后转发请求给 OpenAI。这样即使单台设备被攻破损失也只是这一台设备而不是整个项目的 Key。# 文件路径src/proxy_server.py # 服务端代理设备端只持有短期 token服务端持有 OpenAI Key import os from openai import OpenAI from flask import Flask, request, jsonify app Flask(__name__) llm_client OpenAI(api_keyos.environ[OPENAI_API_KEY]) app.route(/v1/chat, methods[POST]) def chat(): data request.get_json() # 设备端只携带设备 token服务端校验合法性后再调用 OpenAI device_token request.headers.get(X-Device-Token) if device_token ! os.environ.get(DEVICE_TOKEN): return jsonify({error: unauthorized}), 401 resp llm_client.chat.completions.create( modelgpt-4o-mini, messagesdata[messages], ) return jsonify({reply: resp.choices[0].message.content}) if __name__ __main__: app.run(host0.0.0.0, port9000)第三语音数据建议端侧加密后再上传上传前明确告知用户。设备要支持一键静音或物理关麦避免误触发录音带来的隐私纠纷。远程配置变更必须带审计日志防止云端配置被篡改。上面只是演示思路。生产环境还需要设备证书校验、限流、全链路审计等能力。对一个随时在听的设备来说安全不是加分项是及格线。5. 同类 AI 硬件对比甜甜圈 vs Rabbit R1 vs AI Pin5.1 已验证过的市场样本2024 年有两款备受关注的 AI 硬件产品上市Rabbit R1 和 Humane AI Pin。Rabbit R1 的交互逻辑是“把 AI 塞进一个带屏幕的小盒子”它的创新点在于提出 Large Action ModelLAM试图让 AI 直接操作 App 完成任务。但大量用户实测发现执行成功率并不理想最终更多停留在“科技玩具”阶段。Humane AI Pin 走的是“无屏 激光投影”路线。它没有传统屏幕而是把界面投影到手掌上同样强调语音优先。但根据公开报道它在续航、发热、响应准确率上问题不少最终母公司 Humane 在 2025 年被惠普收购了相关资产产品也逐渐退出市场。5.2 三者的设计取向对比维度Rabbit R1Humane AI PinOpenAI 甜甜圈传闻屏幕有无激光投影替代无输入触控 语音语音 手势语音为主形态手持小盒子胸前别针环形可穿戴核心卖点大模型统一操作 App无屏随身助手深度绑定 GPT 生态已有问题执行成功率低续航、发热、延迟尚未正式发布产成品消费风险尝鲜用户尝鲜用户待观察从表里能看出前后几代硬件踩过的坑OpenAI 大概率都看到了。无屏硬件的问题从来不是“有没有屏幕”而是语音闭环是否足够快、足够准、足够稳。只要这个核心链路没有打通再好看的硬件形态都只是概念。5.3 为什么 OpenAI 仍然有机会AI Pin 失败不代表无屏路线失败它只说明第一代产品教育了市场但也消耗了用户的耐心。OpenAI 的机会在于模型能力比 2024 年更强在意图理解、多轮对话上已经有了明显进步。硬件可以深度复用 OpenAI 生态API、Function Calling、 OpenAI无屏AI硬件甜甜圈：从语音交互到端侧部署的技术拆解
最近 AI 硬件圈最热的讨论都围绕着一个奇怪的传闻OpenAI 要和苹果前首席设计师 Jony Ive 合作推出一款没有屏幕的 AI 硬件设备渲染图里它看起来像一个「甜甜圈」。说实话第一次看到这个消息我的反应和你一样为什么是这个形状为什么连屏幕都不要这篇文章不打算聊八卦而是把这件事拆成一个技术问题来看。我会从产品定位、语音交互闭环、端侧 AI 部署、开发者接入这几个维度展开说说无屏 AI 硬件到底怎么做、怎么连、怎么调试以及 OpenAI 选择「甜甜圈」形态背后的工程逻辑。如果你正在做语音产品、端侧 AI 部署或者想提前了解 AI 硬件开发的技术方向这篇文章应该对你有帮助。先说清楚一个前提目前 OpenAI 官方并没有正式发布这款产品所有形态描述都来自公开报道和供应链消息。因此下面凡是产品层面的细节我都以“公开报道 技术推理”的方式呈现不当作官方参数使用。1. 背景与产品解读OpenAI 首款 AI 硬件究竟想解决什么问题1.1 甜甜圈形态与当前公开信息综合已有的外媒报道、设计专利和供应链消息这款设备比较确定的设计倾向是没有屏幕外形接近环形或椭圆形中间有孔看起来确实像甜甜圈大概率采用可穿戴或随身携带的形态。为什么明明没有屏幕还要做成环形这里有一个很多人忽略的工程理由环形结构在空间上天然适合“穿戴”。它可以当戒指、挂脖子上、夹在背包肩带上中孔本身就是一个固定的物理作用点。相比需要握持的方形设备环形设计在“不占用注意力”的场景下明显更合理。从体验角度看这台设备的核心交互是语音。你不需要解锁手机、不需要打开 App、不需要输入文字开口说话就能完成操作。这种“环境级交互”和手机上的 App 级交互有本质区别也决定了它不能用传统硬件设计的思路来理解。1.2 模型公司为什么亲自下场做硬件OpenAI 的核心是模型和 API按道理它只需要把 GPT 能力开放出来让硬件厂商调用就够了。但它选择自己下场可以从三个层面理解第一入口焦虑。手机是超级入口但在手机上AI 助手被困在 App 里。用户和助手之间隔着解锁、打开 App、输入点按的过程。OpenAI 需要一种“不需要解锁就能对话”的入口否则再强的模型也只是别人 App 里的一个功能。第二交互数据闭环。语音交互产生的真实对话数据、环境音频、用户习惯是优化模型的宝贵资源。第三方硬件虽然也能调用 API但数据不出第三方设备OpenAI 很难拿到关键信息来迭代模型。第三定义“AI 原生交互”的标准。屏幕上的 AI 交互本质上还是 App 时代的产品逻辑。无屏语音交互才是真正意义上的 AI 原生设备体验OpenAI 想亲手定义这个标准。这和当年苹果定义触屏交互是同一个逻辑。1.3 无屏不是退步而是降低注意力成本很多人第一反应是没有屏幕怎么看消息、怎么付款、怎么刷视频这个提问预设了“设备等于屏幕”的心智模型。但无屏设备并不想替代手机它想替代的是“用户掏手机之前的那个念头”。语音设备的核心价值是降低交互成本。正常情况下从“想设置一个提醒”到“设置完成”手机上的操作路径是亮屏、解锁、打开提醒事项、新建、输入内容、确认至少五六个步骤。而无屏语音设备只需要一句话“帮我 20 分钟后提醒我给客户回电话。”从工程角度看这是交互范式的迁移两类设备的定位完全不同维度屏幕设备无屏语音设备输入方式文字、手势、触控语音、环境感知输出方式视觉文字/图像听觉TTS为主注意力占用高必须盯着看低可以边做别的事典型场景阅读、浏览、游戏提醒、查询、控制失败恢复信息可回看需要对话式确认这种设计也符合大模型的能力边界。大模型在复杂任务上的推理能力很强但“把复杂信息读出来”这件事更适合用 TTS 做成短提示而不是朗读长文本。所以无屏设备适合做短任务不适合做沉浸式内容消费。它是在需求发生的那一刻用最低成本把问题解决掉而不是把信息堆到你面前。2. 无屏硬件的核心技术拆解2.1 一条完整的语音交互闭环无屏设备的所有价值都依赖语音闭环是否好用。整个链路可以拆成下面几步用户说话 ↓ 麦克风阵列采集端侧 ↓ 唤醒词检测端侧常驻低功耗 ↓ 语音活动检测 VAD 回声消除 降噪端侧 ↓ ASR 语音转文字端侧轻量模型或云端 Whisper ↓ LLM 意图理解 / 任务执行云端配合 Function Calling 或 Agent ↓ TTS 文字转语音云端流式合成或端侧小模型 ↓ 扬声器播放每一段都有明确的工程指标要求唤醒词检测必须常驻在麦克风上功耗要极低误唤醒率要压到每天几次以内。VAD 和降噪在嘈杂环境下要把说话人声音和背景噪声分开否则后续 ASR 全是噪音。ASR中文场景下准确率要足够高人名、地名、品牌这类专有名词都要能识别。LLM响应延迟直接影响体验。用户感知到的“快”要求首字 TTS 输出在 800ms 左右出现而不是等完整回答生成完再播放。TTS要流畅自然支持流式输出不能把音频累计到最后一次性播。这里最难的是“端到端延迟”。单独看每个环节都不算慢但串起来就容易超过用户的耐心阈值。所以无屏设备的工程重点不是单点优化而是全链路协同。2.2 端侧与云侧一颗芯片和一个大脑的分工无屏设备的计算资源和电池空间都非常有限不可能在设备里跑一个完整的大参数模型。所以它的架构一定是“端侧 云侧”的混合架构端侧负责唤醒词、VAD、降噪、部分轻量 ASR、简单命令词识别、离线兜底回复。云侧负责复杂语义理解、多轮对话、工具调用、代码执行、联网搜索、高质量 TTS 合成。这个分工有几个关键设计点。第一断网要有兜底。如果断了网设备就是一块砖体验一定很差。技术上需要内置一批离线命令词比如“关灯”“打开空调”“现在几点”这些可以直接在本地执行。更复杂的问题可以缓存到网络恢复后处理。第二延迟预算要严格划分。在端侧把唤醒和 VAD 做好能帮云端争取时间。比如用户说完“嘿小O”之后设备可以先预连接云端把会话通道提前建好等 ASR 文本一出来直接丢给 LLM而不是等识别完成后再建立连接。这种“预建连”的优化能让体感延迟下降一个量级。第三端侧模型尺寸有限但可以针对场景压缩。在设备上跑一个 1B 到 3B 参数的对话模型或者只跑一个意图分类模型把“用户这句话应该理解成什么”先弄清楚再交给云侧大模型做深层推理是业界比较常见的做法。纯端侧方案和纯云端方案都各有短板混合架构是当前最稳妥的选择。2.3 环形设计的工程意义甜甜圈造型不只是为了好看它对硬件工程有实际影响。环形结构可以把麦克风阵列均匀分布在圆周上实现接近 360 度的拾音范围不用像手机那样依赖某个方向的麦克风。中孔位置可以用来固定挂绳、指环或其他佩戴结构降低设备被误触摔落的风险。中间镂空减少了外壳材料用量也让内部结构自然形成环形 PCB 布局有利于天线走线和电池排布。更重要的是环形形态在视觉上“不像手机”这可以降低用户把它当成屏幕设备的预期引导用户主动使用语音交互。产品设计上有一种做法叫“形态即引导”甜甜圈的造型本身就是最好的产品说明书。当然环形也带来不小的难题内部空间挤电池容量、扬声器尺寸、散热设计全都受限。所以这类设备的续航和音质注定没法跟手机比。如何在有限空间里平衡体验是硬件团队的第一课题。3. 开发者视角像接 API 一样接入 AI 硬件既然 OpenAI 做硬件那它对开发者一定是开放 API 的。对开发者来说真正的机会在于“把设备当成大模型的一个传感器和执行器”。下面我们用 Python 模拟一条无屏语音设备的完整交互链路。3.1 准备环境你需要一个可用的 OpenAI API Key以及安装好openaiPython SDK。如果你还没有安装 SDK先执行pip install openai本文示例环境Python 3.10 及以上版本openai SDK 1.x本地音频文件用于模拟麦克风输入注意下面代码调用的是 OpenAI 官方 API 的常规用法模型名称和接口字段在不同版本间可能有差异实际使用时请以官方文档为准。3.2 用 Whisper 把语音转成文本先写一个模拟 ASR 的函数把音频文件转成文字# 文件路径src/asr.py from openai import OpenAI client OpenAI(api_keysk-YOUR_KEY) # 实际使用请从环境变量读取 def speech_to_text(audio_path: str) - str: 把本地音频文件转成文本模拟端侧或云端 ASR with open(audio_path, rb) as audio_file: response client.audio.transcriptions.create( modelwhisper-1, fileaudio_file, languagezh, ) return response.text if __name__ __main__: text speech_to_text(test_voice.wav) print(识别结果:, text)真实设备上ASR 可以在端侧完成也可以在云端完成。端侧方案延迟低、隐私好但对芯片算力要求更高云端方案精度通常更好代价是依赖网络。作为开发者你接入时只需要拿到最终的文本结果底层的 ASR 部署方式对上层业务是透明的。3.3 流式对话边生成边播报无屏设备最忌讳“全部生成完再播放”用户等不了。正确做法是用流式接口接收 token实时送给 TTS 合成器。下面是一个流式对话示例# 文件路径src/chat_stream.py from openai import OpenAI client OpenAI(api_keysk-YOUR_KEY) def ask_with_stream(user_text: str): 流式请求 LLM边生成边打印实际设备中这里会把 token 送入 TTS stream client.chat.completions.create( modelgpt-4o-mini, messages[ { role: system, content: ( 你是一个运行在无屏语音设备上的助手。\n 规则1. 回答控制在 3 句话以内2. 不使用 Markdown 格式 3. 涉及删除、付款、发送消息等操作必须先反问用户确认。 ), }, {role: user, content: user_text}, ], streamTrue, ) collected [] for chunk in stream: if chunk.choices and chunk.choices[0].delta.content: token chunk.choices[0].delta.content collected.append(token) # 真实设备这里把 token 送入 TTS 流式合成器播放 print(token, end, flushTrue) return .join(collected) if __name__ __main__: reply ask_with_stream(帮我 20 分钟后提醒我给客户回电话) print(\n完整回复:, reply)这里的关键点是streamTrue。通过流式返回用户听到“第一个字”的时间被大幅提前而不是等所有内容生成完。体感延迟从“几秒冷启动”变成“像电话对面的人正在开口说话”这对语音设备来说是天壤之别。3.4 Function Calling让设备真正“动手”无屏设备只回答问题是不够的它需要能设置提醒、发消息、控制智能家居。这就需要 Function Calling函数调用能力。LLM 在对话中先判断需要调用什么工具返回结构化参数设备端再真正执行。# 文件路径src/function_calling.py import json from openai import OpenAI client OpenAI(api_keysk-YOUR_KEY) tools [ { type: function, function: { name: set_reminder, description: 设置一个定时提醒, parameters: { type: object, properties: { time: {type: string, description: 提醒时间如 20分钟后/18:00}, content: {type: string, description: 提醒内容}, }, required: [time, content], }, }, } ] def run_device_loop(user_text: str): response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: user_text}], toolstools, tool_choiceauto, ) msg response.choices[0].message if msg.tool_calls: for tool_call in msg.tool_calls: args json.loads(tool_call.function.arguments) print(f[设备执行] 工具{tool_call.function.name}, 参数{args}) # 这里把 args 传给设备端真实函数例如写入本地提醒数据库 return args else: return msg.content if __name__ __main__: result run_device_loop(帮我 20 分钟后提醒我给客户回电话) if isinstance(result, dict): print([设备侧] 提醒已写入本地存储:, result) else: print([设备侧] 无需调用工具直接回答:, result)这个流程的核心价值在于设备本身不需要理解“20分钟后”怎么换算也不需要记住所有业务逻辑它只需要把 LLM 输出的参数交给本地执行模块。也就是说无屏设备的软件升级本质上是模型能力和工具集的升级而不是重写设备固件。这种架构让设备的能力边界可以持续扩展。3.5 从 Function Calling 到 Agent 化执行如果你关注 OpenAI 最近的动态会发现它已经把 Codex 这类产品做成了“模型能力 代码执行 工具调用”的 Agent 形态相关 harness 也已在 GitHub 上开源。搜索词里频繁出现的“OpenAI 开放 Codex harness”本质上就是把 Codex 的调度框架开放给开发者让大家基于它构建自己的 Agent。这件事对 AI 硬件意义很大。想象一下设备端的 Function Calling 如果升级成 Agent 式执行它的能力边界就从“设置提醒、发消息”扩展到“帮我订一张周五的高铁票如果没票就买后面一班并把座位偏好设为靠窗”这种多步骤长程任务。无屏设备的语音入口正好是这类 Agent 最自然的触发方式。所以给 AI 硬件做开发不要把注意力只放在“对话”上更要关注模型能不能调用工具、能不能执行多步任务、能不能在出错时自行回滚重试。这才是 OpenAI 做硬件的终局竞争力。4. 端侧 AI 硬件部署的关键技术清单4.1 模型选型能上端侧的先上端侧无屏设备的端侧模型通常需要覆盖三类能力ASR 模型比如 Whisper 的 tiny 或 base 版本或者更小的端侧语音识别模型。TTS 模型端侧 TTS 采用轻量合成方案优先保证延迟和自然度的平衡。意图分类或小对话模型参数规模通常控制在 1B 到 3B只负责意图识别和简单问答。部署原则是能离线完成的尽量不要拖到云端。这不仅是考虑断网可用更是把云端通道留给真正需要大模型推理的任务。端侧模型每多扛住一个场景云端压力就小一分用户等待时间也短一分。4.2 量化是端侧模型落地的核心手段要在低功耗芯片上跑模型量化几乎是必选项。常见的量化位宽对模型体积的影响可以参考下表量化方式权重体积精度损失适用场景FP16原始一半极小算力较强的 SoCINT8原始四分之一较小主流端侧 NPUINT4原始八分之一明显超低功耗或小内存设备以 1B 参数模型为例FP16 权重约 2GBINT8 约 1GBINT4 约 0.5GB。对于内部空间有限的甜甜圈设备0.5GB 到 1GB 的权重规模才有机会放进内存。实际工程中还需要结合模型蒸馏、剪枝等手段一起做才能在不明显损失效果的前提下把模型塞进设备。4.3 功耗、内存与散热是三个硬约束端侧硬件存在一个“性能、功耗、体积”的不可能三角功耗设备体积小电池容量有限常驻监听的唤醒词功耗必须压到极低。如果整机平均功耗压不下来用户一天一充甚至半天一充产品很难被接受。内存环形 PCB 内部空间小DDR 容量有限。模型推理、音频缓冲、系统运行要共享内存内存规划要在项目早期就定下来。散热无风扇设计下芯片持续满载会触发降频进而影响响应速度。所以设备侧的 AI 任务尽量“短平快”复杂任务交给云端。这意味着做端侧 AI 硬件部署不能只把模型跑通就完事还要建立一套“延迟、功耗、温度”的可观测体系在量产前充分测试不同场景下的功耗曲线。这几个指标任何一项不达标产品体验都会大打折扣。4.4 安全与隐私API Key 不能裸存无屏设备本质上是一个“口袋里的麦克风”隐私和安全风险比手机更高。这里特别要说一下 API Key 管理因为搜索结果里很多人都在搜 OpenAI API Key 的获取方法但拿到 Key 之后怎么安全地用才是工程关键。第一API Key 绝不能硬编码在固件里。它应该存储在 TEE可信执行环境或安全芯片中通过密钥注入方式做初始化。即使设备被拆解也不应该能直接读出 Key。第二更安全的做法是服务端代理。设备端不直接持有长期 Key而是持有一个短期设备 Token由你的服务端校验后转发请求给 OpenAI。这样即使单台设备被攻破损失也只是这一台设备而不是整个项目的 Key。# 文件路径src/proxy_server.py # 服务端代理设备端只持有短期 token服务端持有 OpenAI Key import os from openai import OpenAI from flask import Flask, request, jsonify app Flask(__name__) llm_client OpenAI(api_keyos.environ[OPENAI_API_KEY]) app.route(/v1/chat, methods[POST]) def chat(): data request.get_json() # 设备端只携带设备 token服务端校验合法性后再调用 OpenAI device_token request.headers.get(X-Device-Token) if device_token ! os.environ.get(DEVICE_TOKEN): return jsonify({error: unauthorized}), 401 resp llm_client.chat.completions.create( modelgpt-4o-mini, messagesdata[messages], ) return jsonify({reply: resp.choices[0].message.content}) if __name__ __main__: app.run(host0.0.0.0, port9000)第三语音数据建议端侧加密后再上传上传前明确告知用户。设备要支持一键静音或物理关麦避免误触发录音带来的隐私纠纷。远程配置变更必须带审计日志防止云端配置被篡改。上面只是演示思路。生产环境还需要设备证书校验、限流、全链路审计等能力。对一个随时在听的设备来说安全不是加分项是及格线。5. 同类 AI 硬件对比甜甜圈 vs Rabbit R1 vs AI Pin5.1 已验证过的市场样本2024 年有两款备受关注的 AI 硬件产品上市Rabbit R1 和 Humane AI Pin。Rabbit R1 的交互逻辑是“把 AI 塞进一个带屏幕的小盒子”它的创新点在于提出 Large Action ModelLAM试图让 AI 直接操作 App 完成任务。但大量用户实测发现执行成功率并不理想最终更多停留在“科技玩具”阶段。Humane AI Pin 走的是“无屏 激光投影”路线。它没有传统屏幕而是把界面投影到手掌上同样强调语音优先。但根据公开报道它在续航、发热、响应准确率上问题不少最终母公司 Humane 在 2025 年被惠普收购了相关资产产品也逐渐退出市场。5.2 三者的设计取向对比维度Rabbit R1Humane AI PinOpenAI 甜甜圈传闻屏幕有无激光投影替代无输入触控 语音语音 手势语音为主形态手持小盒子胸前别针环形可穿戴核心卖点大模型统一操作 App无屏随身助手深度绑定 GPT 生态已有问题执行成功率低续航、发热、延迟尚未正式发布产成品消费风险尝鲜用户尝鲜用户待观察从表里能看出前后几代硬件踩过的坑OpenAI 大概率都看到了。无屏硬件的问题从来不是“有没有屏幕”而是语音闭环是否足够快、足够准、足够稳。只要这个核心链路没有打通再好看的硬件形态都只是概念。5.3 为什么 OpenAI 仍然有机会AI Pin 失败不代表无屏路线失败它只说明第一代产品教育了市场但也消耗了用户的耐心。OpenAI 的机会在于模型能力比 2024 年更强在意图理解、多轮对话上已经有了明显进步。硬件可以深度复用 OpenAI 生态API、Function Calling、