落地实现方案 · 食光机 FoodTime

01

总体架构

五层分层：端侧层只做唤醒、编码与播放，绝不做业务判断；接入层是唯一的信任边界； 服务层按领域拆分，AI 编排单独成服务以便随时切换供应商；数据层按访问特征分库； 三方能力层全部通过统一适配层调用，任何一家挂掉都能在 30 秒内切走。

← 左右滑动查看完整架构图 →

图 1｜端云一体总体架构。绿色高亮为本项目自研核心（设备网关、保质期推理引擎、AI 编排层）；橙色为外购三方能力，全部经统一适配层调用，单一供应商故障可切换；紫色为数据存储。 刻意的架构约束：端侧不缓存任何业务逻辑——冰箱贴只是一个「带屏幕和喇叭的麦克风」，所有保质期计算、菜谱推荐都在云端，好处是固件可以两年不大改，坏处是断网体验降级（见 §2 离线旁路）。

单一信任边界

设备一律走双向 TLS（每台出厂烧录唯一证书，私钥存 ESP32-S3 eFuse 不可读出）。 App 走 OAuth2 + 短期 JWT。服务层内网不做二次鉴权但强制携带 family_id 上下文，由网关注入且服务层不信任客户端传入的 family_id——这是防越权取数的关键一道。

AI 编排层单独成服务

所有大模型调用收敛到一个 LLM 网关：统一做模型路由（Lite/Pro 分流）、上下文裁剪、 Prompt 版本管理、多供应商熔断、Token 计量与配额扣减。换供应商是改一份路由配置，不是改二十处业务代码。这一层的存在直接决定 §7 的成本能不能压下来。

按访问特征分库

健康指标与设备温湿度是典型高写入低更新时序数据，放 MySQL 会在 10 万台时把主库写爆—— 单台设备 15 分钟上报一次温湿度 = 每天 96 条 × 10 万台 = 960 万行/天。用 TDengine 后压缩比约 1:12（估算），成本与查询性能都可控。

02

端云语音链路时序

语音是这个产品的命门。用户不会容忍「你好小食」之后等两秒—— 消费级语音硬件的心理死线是首声出音 1.2 秒，超过就会被判定为「反应慢」。下图逐段拆解延迟预算，并给出离线旁路：断网或命中本地命令词时完全不上云。

← 左右滑动查看完整时序图 →

图 2｜语音链路时序与延迟预算（全部为目标值，非实测值，待 DVT 阶段验证）。关键工程手段有三个：①流式贯穿全链路（ASR、LLM、TTS 三段全部流式，不等任何一段完整）； ②首句抢跑（LLM 输出到第一个句号就立刻送 TTS，不等整段生成完）； ③边收边播（设备端 ring buffer 收到 200ms 音频就起播）。三者叠加把体感延迟从串行的 ~2.6s 压到 ~1.15s。

离线旁路：50% 的交互根本不该上云

ESP-SR 的 MultiNet 支持在设备端离线识别 50–100 条自定义命令词。我们把最高频的交互全部下沉：

「今天有什么要过期」→ 端侧读取上次同步的临期清单，播放预合成音频片段 + 拼接数字
「存食材」「音量大一点」「关掉」「几点了」「明天天气」→ 纯本地执行
敲一下贴面（加速度计）→ 免语音唤醒，直接播报临期提醒。油烟机开着时这是最可靠的交互方式
断网时屏幕显示离线态图标，本地功能全部保留，恢复网络后自动补同步

这不只是体验优化——本地兜底命中 50% 的交互，就等于直接砍掉 50% 的 ASR + LLM + TTS 成本。§7 的单台 AI 成本能压到 ¥0.66，一半功劳在这里。

延迟预算的三个不确定项（说实话）

家庭 Wi-Fi 质量差异极大。预算里的 60ms RTT 是理想值，实测中国家庭宽带上行到公有云的 P95 可能到 120–180ms；若用户路由器在客厅、冰箱贴在厨房隔墙，2.4G 信号衰减还会引入重传。对策：设备端做网络质量分级，弱网时自动降级为「只出字幕不出声」或直接走本地兜底。
三方 API 的 P99 不受我们控制。LLM 首 token 的 P50 可能 450ms，但 P99 可能 2.5s+。对策：编排层设 800ms 软超时——超时立即插播一句预合成的「让我想想」过渡音频，把等待感填掉，这是行业通行做法。
Opus 编解码在 ESP32-S3 上的实际开销待测。16kHz/24kbps 编码理论上单核占用 <15%，但叠加 WakeNet 常驻推理后是否还有余量，必须在 EVT 阶段实测。兜底方案：退回 ADPCM（带宽翻 3 倍但几乎零 CPU），代价是流量从 3KB/s 涨到 8KB/s，可接受。

03

关键技术选型

选型的唯一准则是轻资产：能买 API 就不自研模型，能用公版就不开新模，能开源自托管就不锁定云厂。每一行都写清备选与风险——没有无风险的选型，只有想清楚了的选型。

价格与周期均为估算 / 待商务谈判验证

领域	选型	备选	决策理由	风险与对策
MCU 主控	乐鑫 ESP32-S3-WROOM-1-N16R8 双核 240MHz / 16MB Flash / 8MB PSRAM	全志 R128 炬芯 ATS3609D	8MB PSRAM 是跑 ESP-SR 唤醒 + Opus 编码 + 240×280 屏幕 framebuffer 的下限，N8R2 不够用。Wi-Fi + BLE 二合一省掉一颗蓝牙芯片（约 ¥6 BOM）。乐鑫代工链在深圳极成熟，方案商一抓一大把，不需要我们养射频团队。	中晶圆周期波动导致涨价/交期拉长。对策：EVT 阶段同步验证 -1U 天线版本与 pin 兼容替代型号，备 6 周安全库存。
本地唤醒	乐鑫 ESP-SR WakeNet9 唤醒 + MultiNet7 命令词	云知声离线 SDK 思必驰 DUI	与 S3 深度适配、免 per-unit 授权费（第三方方案通常 ¥3–8/台，10 万台就是 ¥30–80 万）。自定义唤醒词「你好小食」由乐鑫定制训练，一次性约 ¥2–5 万（估算）。MultiNet 支持 50–100 条本地命令词，是 §2 离线旁路的基础。	中定制唤醒词交付 4–6 周，需在 T0.5 就下单。厨房油烟环境远场唤醒率待实测。对策：训练集加入抽油烟机/流水/电视噪声。
流式 ASR	火山引擎流式 ASR 按小时计费 · 支持热词表	阿里云智能语音科大讯飞	首包 ≤200ms，支持动态热词——把用户家里的食材名、菜名、家庭成员昵称注入热词表，「莴笋」「藠头」「折耳根」这类西南方言食材识别率显著提升。按小时计费在低频场景比按次便宜。	中单一供应商。对策：ASR 适配层同时接入阿里，做健康检查 + 自动切换，切换阈值 3 次连续超时。
LLM 对话	豆包 Lite（端侧对话）豆包 Pro / Qwen-Max（App 深度）	DeepSeek Kimi / GLM	双模型分流是成本控制的核心：设备端「今天吃什么」这类问题用 Lite（¥0.3/¥0.6 每百万 token）完全够用；只有 App 里的营养方案生成、体检报告解读才上 Pro（¥0.8/¥2.0）。两者差价 3–4 倍。所选模型均已完成国内生成式 AI 备案，可商用。	高模型版本迭代导致 Prompt 行为漂移。对策：建回归测试集（300 条黄金问答），每次供应商版本更新前跑一轮；Prompt 做版本号管理与灰度。
VLM 食材识别	豆包 Vision / Qwen-VL-Plus 通用视觉大模型，零训练	自建 YOLOv8 + 分类头（起量后替代）	通用 VLM 开箱即可覆盖 2,000+ 食材长尾（包括包装食品的品牌识别），自建检测模型至少要标 5 万张图 + 2 个 CV 工程师 3 个月，严重违背轻资产原则。单张 ¥0.012 在当前量级完全可承受。	高散装堆叠、塑料袋反光、相似品类（青椒/柿子椒）准确率待验证。目标 Top-1 ≥85%（估算）。对策：识别结果一律进「待确认」态，把纠错做成 3 秒交互；纠错数据回流，累计 10 万张后评估自建。
TTS 语音合成	火山流式 TTS + 声音复刻「小食」专属音色	微软 Azure Neural 魔音工坊	流式首包 ≤150ms 是 §2 延迟预算的前提。声音复刻让「小食」有可识别的人格声线，这是文创联名的延伸点（未来可出「重庆言子版小食」音色包，做付费 SKU）。	中复刻音色需声优书面授权 + 合规声明（防伪造语音风险）。对策：与声优签断买 + 在 App 内声明「本音色为 AI 合成」。
设备接入	EMQX 5（自托管） MQTT 5.0 over TLS 1.2	腾讯云 IoT Hub 阿里云 IoT 平台	开源可私有化，避免云厂设备连接数按台计费（云 IoT 平台通常 ¥0.3–1/台/月，10 万台就是 ¥3–10 万/月，比我们全部基础设施还贵）。单节点可撑 10 万连接，内置设备影子与规则引擎。	中自运维需要 SRE 投入，设备证书轮转是长期负担。对策：证书有效期 3 年，OTA 通道内置轮转能力；早期用托管版 EMQX Cloud 降低运维压力。
消息队列	Apache Kafka 1 万台阶段先用 RocketMQ 单机	RocketMQ Pulsar	设备上报的温湿度、食材变更、健康数据都是典型事件流，Kafka 与后续 Flink 做临期批计算天然衔接。但 1 万台阶段 3 节点 Kafka 是浪费，先用 RocketMQ 单机，10 万台再迁。	低迁移成本。对策：业务侧只用最基础的 pub/sub 语义，不依赖任何厂商特有特性。
关系数据库	MySQL 8.0（云 RDS 高可用）	PostgreSQL TiDB	用户 / 家庭 / 设备 / 食材批次 / 订单是标准 OLTP，MySQL 生态最成熟、招人最容易、云上高可用最便宜。不为了「未来可能的规模」提前上分布式数据库。	中 50 万台后 `food_batch` 表会到十亿行级。对策：一期就按 `family_id` 做逻辑分片键设计（所有查询强制带 family_id），到量时直接上 ShardingSphere 水平拆分，不改业务代码。
时序数据库	TDengine 3.x	InfluxDB 云 TSDB	健康指标（步数/心率/睡眠/体重）+ 设备温湿度是典型时序，TDengine 对「一设备一表」模型压缩比高（约 1:12，估算），且国产可控、私有化部署无授权费。	低周边生态工具少于 Influx。对策：查询层自己封装，不依赖第三方可视化。
向量检索	pgvector（一期）→ Milvus（二期）	Qdrant 云托管向量库	一期数据量为菜谱 3 万条 + 营养知识 8 万段，pgvector 复用现有 PG 实例即可，省掉一整套组件的运维与成本。百万级再迁 Milvus。	低迁移风险。对策：检索层抽象成统一 `VectorStore` 接口，迁移只换实现。
对象存储	腾讯云 COS SSE 服务端加密 + 生命周期分层	阿里云 OSS MinIO 自建	食材照片与语音片段量大且冷热分明：30 天后自动转低频存储，90 天转归档，语音 7 天后硬删除（合规要求，见 §6）。生命周期规则直接省掉 60%+ 存储费。	中含个人信息，泄露即重大事故。对策：强制服务端加密 + 私有读写 + 临时签名 URL（有效期 5 分钟）+ 防盗链。
后端语言	Go（设备网关 / 高并发） Node.js（AI 编排 / BFF）	全 Java 全 Go	Go 扛 10 万级长连接与低延迟转发；Node 的生态与各家 LLM SDK、SSE 流式响应贴合度最好，AI 编排层迭代最频繁，用 Node 开发效率高 2 倍。分工明确：Go 管连接与吞吐，Node 管编排与流式。	中双语言栈增加维护面与招聘面。对策：服务间统一 Protobuf 契约；限定只有这两种语言，不再引入第三种。
App 跨端框架	Flutter 3.x 主 App（iOS / Android） + uni-app（微信小程序轻量版）	React Native 纯 uni-app 原生双端	选 Flutter 的三个硬理由：① 需要 BLE 深度能力（连食光贴下发语音指令、连手环解析 GATT 特征），Flutter 的 platform channel 比 uni-app 的插件体系可控得多；② 需要相机实时取景 + AI 框选叠加渲染（拍照识别录入），自绘引擎能稳定 60fps，uni-app 的 webview 方案做不到；③ 需要流式录音上传，对音频 buffer 有精细控制。小程序端只做「查看食材 + 浏览菜谱 + 分享采购清单」的只读轻量版，不碰 BLE，用 uni-app 单独出，成本可控。	中 Flutter 首包体积约 28MB（含引擎），比原生大；小程序需二次开发（估算 +1.5 人月）。对策：用 `--split-debug-info` + 按 ABI 分包，Android 可压到 ~18MB；小程序功能刻意做窄，只做拉新与分享入口。
云平台	腾讯云（基础设施） + 火山引擎（AI 能力）	阿里云单云华为云	基础设施放腾讯云，因为微信支付、微信小程序、微信生态的打通成本最低（订阅扣款、分账、消息推送）；AI 能力走火山引擎，因为豆包同源、价格最优。混合部署是当前性价比最高的组合。	中跨云调用增加 3–8ms 延迟且走公网。对策：AI 调用全部在服务端发起（不经用户网络），走加密公网即可；若延迟成瓶颈，再评估云联网专线（约 ¥2,000/月）。

表 1｜关键技术选型决策表。贯穿全表的一条线：所有外部依赖都在我们自己的适配层之后。 模型、ASR、TTS、向量库、消息队列都可替换，替换成本控制在 3 人日以内。对一个要靠外购 AI 能力活下去的轻资产项目，这不是过度设计，是活命的保险。

3.1　功耗预算：10–14 天是怎么算出来的

电池扩容至 2000mAh 后，按「DTIM10 modem-sleep + 事件驱动唤醒 + 光感息屏」策略，日均功耗账如下（估算 / 待 EVT 实测校准）：

功耗项	日均消耗	说明
Wi-Fi DTIM10 待机	≈ 48 mAh	平均 2mA × 24h
屏幕点亮	≈ 20 mAh	日均 15–20 分钟，背光约 55mA
语音交互	≈ 10 mAh	10 次/天，唤醒 + 上行 + TTS 播放
传感器轮询 + 系统开销	≈ 5 mAh	SHT30 + 光感 + RTOS
合计	≈ 83 mAh/天	2000mAh ÷ 83 ≈ 24 天理论值

扣除电池老化、低温衰减与重度使用余量后，对外标称 典型 10–14 天（估算 / 待 EVT 实测校准）。该口径已写入硬件规格，与 §9 风险登记 R1（续航）的闭环措施一一对应。

04

核心数据模型

十张核心表。这个产品的数据模型有两个坑，绝大多数同类竞品（包括海外的 Fridgely、Kitche）都踩了： 一是把食材挂在用户身上而不是家庭身上，二是把保质期存成一个字段而不是批次。 第一个坑导致家庭协同做不了，第二个坑导致临期提醒永远不准。下面先给表，再讲这两个坑怎么绕。

表	关键字段	说明
`family` 家庭	`family_id` PK · `name` · `city_code` · `timezone` · `plan_tier` · `owner_user_id` · `created_at`	数据主权边界。所有食材、菜谱收藏、采购清单一律挂 `family_id`，不挂 `user_id`。`city_code` 用于节气食谱与地方菜系偏好。
`member` 家庭成员	`member_id` PK · `family_id` · `user_id`(可空) · `role` · `nickname` · `birth_date` · `gender` · `height_cm` · `weight_kg` · `allergy_tags` JSON · `chronic_tags` JSON · `diet_pref` JSON · `permission_mask`	`role` ∈ {owner, adult, child, elder, guest}。`user_id` 可空——3 岁小孩没有手机账号但必须有营养档案。`allergy_tags`（花生/海鲜/麸质）与 `chronic_tags`（糖尿病/高血压/痛风）直接注入菜谱过滤与 LLM Prompt 硬约束。
`device` 设备	`device_id` PK(SN) · `family_id` · `type` · `mac` · `fw_version` · `hw_rev` · `last_online_at` · `shadow_ver` · `bind_member_id` · `mute_state` · `cert_fingerprint`	`type` ∈ {tag, label, band, scale}。`mute_state` 记录物理静音键状态（只读上报，云端不可远程解除，见 §6）。`shadow_ver` 用于设备影子增量同步。
`food_catalog` 品类基线库（全局）	`catalog_id` PK · `name` · `aliases` JSON · `category` · `shelf_life_fridge_d` · `shelf_life_freezer_d` · `shelf_life_pantry_d` · `after_open_d` · `temp_sensitivity_k` · `humidity_sensitive` · `nutrition_per_100g` JSON	全局共享的知识库，不属于任何家庭。一期覆盖 1,200 个品类（估算/待验证）。`aliases` 存方言别名（折耳根=鱼腥草=侧耳根），是语音录入识别率的关键。`temp_sensitivity_k` 是 §5 温度修正的品类系数。
`food_item` 食材（逻辑品种）	`item_id` PK · `family_id` · `catalog_id` FK · `name` · `storage_zone` · `unit` · `cover_url` · `created_by` · `source`	回答「这个家里有没有牛奶」。`storage_zone` ∈ {fridge, freezer, pantry}。`source` ∈ {photo, voice, manual, receipt} 用于后续分析各录入方式的留存贡献。
`food_batch` 食材批次 ★	`batch_id` PK · `item_id` FK · `qty` · `qty_unit` · `produced_at` · `purchased_at` · `expire_at_declared` · `expire_at_inferred` · `opened_at` · `storage_zone` · `confidence` · `label_printed` · `status`	本方案最重要的一张表。回答「这个家里的牛奶，哪一盒最先坏」。`expire_at_declared` 是用户/包装标注的，`expire_at_inferred` 是引擎推理的，两者同时保留，UI 取更保守的一个。`confidence`(0–1) 决定 UI 是否显示「约」字。`status` ∈ {fresh, near, expired, consumed, discarded}。
`recipe` / `recipe_ingredient` 菜谱	`recipe_id` PK · `title` · `cuisine` · `difficulty` · `cook_min` · `steps` JSON · `nutrition` JSON · `tags` · `embedding` vector(1024) · `source` 关联表：`recipe_id` · `catalog_id` · `qty` · `unit` · `optional`	菜谱与食材通过 `catalog_id` 关联（不是字符串匹配）——这是「清冰箱菜谱」能算准匹配度的前提。`optional` 标记可省略配料，用于计算「缺 2 样也能做」。`embedding` 支持「想吃点清淡的」这类模糊语义检索。
`meal_log` 饮食记录	`log_id` PK · `family_id` · `member_id` · `meal_type` · `eaten_at` · `items` JSON(batch_id+qty) · `kcal` · `macro` JSON · `source`	`items` 直接引用 `batch_id`——吃掉即扣减对应批次库存，形成「买入→存储→消耗」闭环。这是与纯记账类 App 的本质区别：我们知道你实际吃掉了哪一批食材。
`health_metric` 健康指标（时序）	`ts` · `member_id` · `metric` · `value` · `source` · `device_id`	存 TDengine，按 `member_id` 建超级表子表。`metric` ∈ {steps, hr, sleep_min, weight, bfp, bp_sys, bp_dia, glucose}。`source` ∈ {band, scale, manual, third_party_sdk}。饮食-运动-睡眠闭环的数据底座。
`order` / `subscription` 交易	`order_id` · `family_id` · `sku_type` · `amount` · `channel` · `status` `sub_id` · `family_id` · `tier` · `start_at` · `end_at` · `auto_renew` · `quota_json` · `payment_ref`	`sku_type` ∈ {hardware, consumable, mall, service}，对应七层盈利中的实物类。`quota_json` 存该档位的 AI 调用月度配额（免费档 30 次/月云端对话），由 AI 编排层实时扣减——这是 §7 成本可控的硬闸门。
`health_share` 健康数据授权	`member_id` · `grantee_member_id` · `scope` · `granted_at` · `revoked_at`	解决「我不想让老公看到我的体重」。健康数据默认只有本人 + owner 可见，其余成员需显式授权，可随时撤回。看似小功能，实则决定家庭产品能否被成年女性用户接受。

表 2｜核心数据模型。琥珀色高亮行 food_batch 是整个系统的枢纽表。

难点一：家庭多人共享 + 权限

family 是数据主权边界，不是 user。食材、采购清单、菜谱收藏全部挂 family_id。妈妈买的菜，儿子在超市打开 App 也能看到已有库存——这是硬件能带来的核心价值，如果数据挂在个人身上就全废了。
用户与家庭是多对多。user_family 关联表支持一个人同时属于「自己小家」和「父母家」（异地养老场景是重要用例：给爸妈买一个食光贴，自己在千里之外能看到他们冰箱里的临期食材）。App 顶部切换家庭上下文，所有请求携带当前 family_id。
权限用位掩码而非角色枚举。permission_mask：bit0 查看食材 / bit1 增删食材 / bit2 查看他人健康档案 / bit3 设备管理 / bit4 支付与会员 / bit5 邀请成员 / bit6 导出数据。原因是家庭权限组合极其零碎（保姆要能录入食材但不能看健康数据、老人要能看食材但不能支付），枚举角色会迅速爆炸成十几种。
儿童与老人默认降权。child / elder 角色默认清空 bit2 与 bit4——防止老人被 AI 引导消费、防止儿童数据被兄弟姐妹翻看。
成员退出时不删数据，只匿名化。删除成员会导致历史 meal_log 与 food_item.created_by 悬空。做法是把 created_by 置为墓碑 ID，保留家庭维度的统计连续性，同时满足 PIPL 的删除权（个人可识别信息已移除）。

难点二：食材批次（同种食材多批不同保质期）

item 与 batch 二层拆分。food_item 是「这个家有牛奶」，food_batch 是「3 月 2 日买的 2 盒（3/9 到期）、3 月 8 日买的 1 盒（3/15 到期）」。UI 聚合显示「牛奶 ×3」，但过期判定永远取 min(batch.expire)。不这么做的结果就是：用户看到「牛奶还剩 7 天」，实际上有一盒明天就坏了。
消耗按 FEFO 自动扣减。First Expired First Out——做菜/记录饮食时默认扣最早到期的批次。这也符合真实的厨房行为（人本来就会先喝快过期的那盒）。
批次码承载 batch_id。每个批次在 App 内都生成一个唯一 batch_id（可显示为二维码供家人手机扫码查看），编码的是批次而非食材名——扫一下就精确定位到物理批次，可以精确扣减、精确查询、精确记录开封时间。批次模型因此能把物理世界和数据模型真正对上，无需依赖额外硬件。
自动合并防批次爆炸。规则：同 item_id + 到期日相差 ≤1 天 + 同储存区 → 自动合并为一个批次并累加数量。否则一个爱囤货的家庭三个月就能攒出几百条批次记录，UI 和查询都会崩。
批次状态机而非布尔字段。fresh → near → expired → consumed / discarded。区分 consumed 与 discarded 极其关键——discarded（丢弃）是我们最核心的价值度量指标：「本月帮你少扔了 ¥86 的食材」这句话，全靠这个字段算出来。

05

保质期推理与临期提醒

绝大多数「冰箱管理 App」死在这一步：让用户手动输入保质期。没有人会为一把菠菜手动填日期。 我们的做法是——用户什么都不填也能给出一个可用的推理值，并且诚实地告诉用户这个值有多可信。

推理公式

// 剩余货架期推理（单位：天） expire_inferred = purchased_at + BaseShelfLife(catalog_id, storage_zone) // 品类基线库 × OpenFactor(opened_at, after_open_d) // 开封状态 × TempFactor(T_avg, temp_sensitivity_k) // 温度修正 × HumidityFactor(RH_avg, humidity_flag) // 湿度修正 × QualityFactor(purchase_channel) // 渠道品质 // 最终展示值取更保守者 expire_shown = min(expire_declared, expire_inferred)

BaseShelfLife —— 品类基线库。一期 1,200 个品类（估算/待验证），数据来源：《GB 7718 预包装食品标签通则》、《食品安全国家标准》系列、国家食品安全风险评估中心公开资料、商超实测抽样。例：菠菜冷藏 5d / 常温 1d；猪里脊冷藏 3d / 冷冻 90d；巴氏奶冷藏 7d，开封后 2d。
OpenFactor —— 开封覆盖。开封后直接取 min(剩余天数, after_open_d)。开封通过两种方式感知：语音说「我开了牛奶」/ App 点「已开封」，贴合日常拿取动作。
TempFactor —— Q10 简化模型。参考食品微生物学 Q10≈2–3 的经验值，做线性化近似：冷藏区实测均温每高于 4℃ 一度，腐败速率约 ×1.15，剩余货架期 ÷1.15。temp_sensitivity_k 按品类调节（叶菜敏感、根茎不敏感）。
HumidityFactor —— 失水修正。叶菜类在 RH<50% 的干燥环境失水加速，货架期缩短约 20%（估算）。
QualityFactor —— 渠道系数。冷链生鲜电商 1.0 / 商超 0.95 / 菜市场散装 0.85（估算/待验证）。用户设置默认采购渠道即可。

置信度机制：把不确定性摊开讲

推理必然有误差。与其假装精确，不如明确标注可信度，并把纠错做成一秒钟的事。 每个批次带 confidence（0–1）：

录入方式	置信度	UI 呈现
用户手填生产/到期日	0.95	直接显示「3月9日到期」
扫描包装条码 / OCR 日期	0.90	直接显示
VLM 拍照识别品类 + 基线	0.60	显示「约 3月9日到期」+ 校正入口
纯语音录入，无日期信息	0.50	显示「约 5 天」+ 主动询问一次

纠错数据回流。confidence < 0.7 的批次在 UI 上一键可改，用户每一次校正都写入基线库校准队列。10 万台设备一年能积累的真实家庭食材货架期数据，本身就是护城河——这也是七层盈利中「脱敏数据报告」的数据源头（合规前提见 §6.7）。

必须说清的一个物理事实：食光贴测的是冰箱门外的环境温湿度，不是箱内温度。 SHT30 贴在冰箱门外，读到的是厨房环境值。所以一期的 TempFactor 只能做间接修正—— 用环境温度（判断季节与厨房热负荷）+ 加速度计感知的开门震动频次（开门越频繁箱内回温越多）做估计，精度有限。二期方案：出一个 ¥29 的 BLE 箱内温感子设备（纽扣电池 + 广播模式，续航 1 年），放进冷藏室即可拿到真实箱温。在此之前，所有温度修正结论都标注为估算，不做过度承诺。

三级提醒策略：越临近越强，但绝不唠叨

入户语音硬件最大的死法不是不好用，是太吵。用户拔掉电源那一刻，所有商业模型全部归零。所以提醒策略的设计原则是：渐进升级 + 硬性配额 + 无响应自动降级。

D-3

App 推送 —— 每日 18:00 聚合，一天最多 1 条

「3 样食材 3 天内到期，点开看清冰箱菜谱」。聚合是关键：绝不为每样食材单独推一条。18:00 是下班买菜决策点，推送转化率最高。设备端屏幕同步显示琥珀色临期数字。

D-1

食光贴主动语音播报 + 屏幕琥珀卡片

「明天到期：菠菜、巴氏奶。要给你推荐个做法吗？」三个硬性前置条件缺一不可： ① 环境光传感 + 声音活动检测判定厨房有人；② 时间在 07:00–21:00 之间；③ 当日主动播报次数 < 2。条件不满足则降级为纯屏幕显示，不出声。

D0

降级为「今日必吃」菜谱 —— 不主动出声

屏幕转红色，App 的灶台 Tab 自动把用掉这些食材的菜谱置顶，标注「用掉 3 样临期 · 省 ¥18」。 刻意不在 D0 播报——到期当天再喊一遍是纯粹的负面情绪输出，用户只会觉得被指责。把它变成一个「今晚吃这个正好」的建议，而不是一句「你又浪费了」。

D+2

静默回收：一次性询问「已吃掉 / 已丢弃？」

仅 App 内弹一次，不推送不播报。用户的回答同时完成三件事：更新批次状态、校准基线库、累计「本月帮你省下 ¥XX」这个核心留存指标。丢弃数据是这个产品价值证明的唯一来源，必须不惜代价拿到。

写死在固件里的防打扰硬规则（产品经理无权在后台调高）： 设备主动语音播报 ≤ 2 次/天；22:00–07:00 全静音（含屏幕息屏）；同一类提醒连续 3 次无用户响应，自动永久降级为仅屏幕显示；用户说一句「别再提醒了」即当场关闭该品类提醒。把这些规则写进固件而非云端配置，是为了让运营同学无法为了短期 DAU 去调它。

06

隐私与合规

这一节不是走流程。一个放在厨房、带麦克风、记录全家吃什么和健康数据的硬件，合规是它的生死线，不是它的成本项。一次数据事故足以让品牌当场死亡，而这类产品的信任一旦崩塌不可修复。以下七条是我们认为必须在 T0 就设计进架构、而不是上线前补的东西。

前置设计项，非上线前补丁

6.1

语音数据的三级处理边界

唤醒词检测 100% 在设备本地。WakeNet9 在 ESP32-S3 上推理，音频永不出设备、永不落盘。未唤醒状态下麦克风数据仅存在于一个 512ms 的 RAM 环形缓冲区，掉电即失，固件中没有任何将其写入 Flash 或上传的代码路径。
唤醒后才开始上行。上行起点是唤醒词检出时刻，且回溯不超过 300ms（用于捕捉紧跟唤醒词的指令）。
VAD 判定静音 800ms 立即停止上传并断开音频流，不做「多录一会儿以防万一」。
上行期间屏幕强制显示聆听态动效 + LED 呼吸灯。用户必须能一眼看出「它现在在听」。没有任何隐蔽录音的可能性，这是设计约束而非策略。

6.2

物理静音键 —— 硬件级，非软件 mute

机身侧面拨动开关，物理断开 MEMS 麦克风的供电回路，而不是在软件里设一个 flag。拨到静音位时：屏幕常显红色麦克风禁用图标、LED 红点常亮、 MCU 固件无法通过任何指令覆盖此状态，云端更不可能远程解除（device.mute_state 只上报不下发）。

这个开关会增加约 ¥1.2 的 BOM 和一道结构工序。但它是入户语音硬件取得用户信任的最低门槛——所有在这件事上省钱的品牌，最终都在舆情上付出了十倍代价。这笔钱不能省。

6.3

数据留存与用户权利

数据类型	留存期	用途
原始语音音频	≤ 7 天	仅 ASR 纠错与投诉回溯，到期硬删除（非软删）
ASR 转写文本	90 天	对话上下文与体验优化
食材照片	180 天	识别纠错，30 天后转低频存储
食材/饮食结构化记录	账户存续期	核心业务数据
健康指标	账户存续期	加密存储，成员级授权访问

App 内设「隐私中心」一级入口，提供：一键删除全部语音记录、导出个人数据（JSON + CSV）、注销账户并清除全部数据（PIPL 第 45、47 条的可携带权与删除权）。
数据不出境。全部存储于境内节点；三方 AI API 一律选用境内区域。
与所有 AI 供应商签订《个人信息委托处理协议》，并在合同中明确约定其不得将我方数据用于模型训练。——多数 API 的默认条款是允许的，必须逐条谈掉。这是极易被忽略的一条。

6.4

儿童与老人数据

14 岁以下成员档案须由 owner（监护人）单独勾选同意，独立于总协议之外的单独弹窗（《未成年人个人信息网络保护规定》+ PIPL 第 31 条）。
儿童成员默认不开启声纹识别、不进入任何 B 端脱敏数据集、不参与个性化广告或商城推荐。
老人模式下所有付费引导默认关闭：不弹会员升级、不推商城、AI 对话中禁止出现购买建议。防止诱导消费是产品伦理，也是舆情风险控制。
儿童营养建议走独立的高约束模板，严禁涉及减重、控糖等成人减脂话术。

6.5

等级保护与生成式 AI 备案

网络安全等级保护 2.0 三级。面向公众提供服务且承载个人健康信息，按三级建设：堡垒机、操作审计、日志留存 ≥180 天、WAF、数据库审计、双因素认证、数据传输与存储加密。测评费用估算 ¥8–12 万，周期 2–3 个月，须在 T3 启动（见 §8 排期）。
生成式 AI 服务备案 —— 这是最容易被低估的一项。采购已备案的大模型 API 不等于我们的应用免于备案：依据《生成式人工智能服务管理暂行办法》，我们作为「面向公众提供生成式服务」的应用方，仍需自行完成算法备案与安全评估。周期 60–90 天（估算），法务与测评预算 ¥8–15 万（估算）。
排期对策：T1 立即启动备案，不等产品做完。若备案未通过而硬件已到货，首发版本降级为「检索式问答 + 规则推荐」形态（不调用生成式模型，因而不属于生成式服务），备案通过后再通过 OTA 与 App 更新开放自由对话。这条备用路径必须在架构上预留，不能事到临头再改。
其余：ICP 备案、《网络安全法》数据分类分级、App 隐私政策与权限申请合规（工信部专项检测）、SDK 合规清单。

6.6

医疗边界 —— 我们不做诊断

产品定位明确为 非医疗器械的膳食营养信息服务，不申报、不宣称、不暗示任何医疗功能。

所有营养输出的依据必须可追溯至《中国居民膳食指南（2022）》与《中国食物成分表（第 6 版）》，AI 回答中带出处标注。
三条红线（Prompt 硬约束 + 输出侧二次拦截）：禁止输出诊断结论、禁止推荐任何处方药或保健品疗效、禁止给出剂量化治疗建议（如「每天吃 X 克可以降血糖」）。
慢病场景走独立高约束链路。涉及糖尿病/高血压/痛风/肾病/孕产时，强制注入免责前缀「以下为一般膳食参考，不替代临床诊疗，请遵医嘱」，并走规则黑名单 + 小模型审核双重拦截；UI 常驻声明条。
真人营养师资质硬性要求：须持有注册营养师（RD）或注册营养技师（DTR）资质，证书在 App 内可查验；服务协议中明确不得开具处方、不得诊断，超出范围一律建议转诊。
配套购买产品责任险与医疗职业责任险（真人服务部分），建议保额 ¥500 万（估算/待保险经纪核价）。

6.7

B 端脱敏数据（第七层盈利）的三个不可让步前提

「真实家庭食材消费数据卖给商超和品牌方」是 BP 里想象空间最大的一层，也是风险最大、最容易把公司做没的一层。必须同时满足以下三条才能做：

前提 A · 单独同意

必须是独立弹窗的单独同意，不能打包在用户总协议或隐私政策里勾选（PIPL 第 14、23 条）。默认不勾选，用户可随时在隐私中心一键撤回，撤回后其数据立即退出后续所有数据集。可给予激励（如赠 1 个月会员），但不得以「不同意就不能用」作为条件——那是捆绑同意，直接违法。

前提 B · 只输出群体聚合

对外交付物只能是群体级统计结论，绝不输出任何个体级或家庭级记录，哪怕已去标识化。硬性阈值：最小统计单元 ≥1,000 户，满足 k-匿名 k≥50，敏感指标叠加差分隐私噪声。例：可以说「重庆主城 3 月叶菜类家庭浪费率 12.4%」，绝不能说「某小区某户」。

前提 C · 字段与合同双重限制

输出字段中不含姓名、手机号、精确出生日期、设备 ID，地理精度不高于地级市（不到区县、不到小区）。数据合同中明确禁止接收方进行重识别、禁止与其自有数据做个体级关联，并约定违约赔偿与审计权。

如果这三条中有任何一条做不到，第七层盈利宁可不做。这层收入在模型里占比不足 5%（估算），但一次数据合规事故对一个入户硬件品牌是终结性的——不是罚款问题，是用户再也不会把带麦克风的东西放进厨房。 建议：前两年完全不碰 B 端数据变现，先把 C 端信任建立起来，第三年再评估。

07

部署与成本

本节要回答投资人一定会问的那个问题：「你们每卖一台设备，每个月要给云厂和 AI 厂交多少钱？会不会卖得越多亏得越多？」 下面把 AI 调用量拆到每一次请求，把云资源拆到每一台机器，最后算出单台单月成本，并与会员定价做对比。

全部为估算 / 待实际用量与商务报价验证

7.1　AI 调用单价与分档用量假设

能力	计费口径	单价（估算）
流式 ASR	按音频时长	¥2.00 / 小时
LLM-Lite（端侧对话）	输入 / 输出 token	¥0.30 / ¥0.60 每百万
LLM-Pro（深度方案）	输入 / 输出 token	¥0.80 / ¥2.00 每百万
流式 TTS（复刻音色）	按合成字数	¥1.50 / 万字
VLM 食材识别	按图片张数	¥0.012 / 张
向量检索	按查询次数	¥0.20 / 千次

核心用量假设（每户每月）

一台食光贴 = 一个家庭（平均 3 人）
设备语音交互总次数：免费档 60 / 基础 150 / AI 膳养 260 / 真人 330 次
本地命令词兜底命中 50% → 实际上云对话数减半（免费档另受 30 次/月配额硬限）
单次上云语音平均 3.5 秒；LLM 输入约 1,100 token（已裁剪）、输出约 220 token
TTS 回复平均 55–65 字，预合成缓存命中 30–35%
用户结构假设：免费 68% / 基础会员 20% / AI 膳养 9% / AI+真人 3%（合计付费率 32%，估算/待 PVT 内测验证）

AI 能力（每户每月）	免费用户占 68%	基础会员 ¥98/年占 20%	AI 膳养 ¥398/年占 9%	AI+真人 ¥3000/年占 3%
流式 ASR	¥0.06	¥0.15	¥0.25	¥0.32
LLM-Lite（端侧对话）	¥0.014	¥0.035	¥0.066	¥0.084
LLM-Pro（方案/周食谱/报告解读）	—	¥0.03	¥0.27	¥0.42
流式 TTS（扣除缓存命中）	¥0.16	¥0.40	¥0.89	¥1.10
VLM 食材识别	¥0.10	¥0.17	¥0.46	¥0.54
向量检索	¥0.01	¥0.02	¥0.06	¥0.08
分档 AI 成本 / 户 / 月	¥0.35	¥0.81	¥2.00	¥2.55
按用户结构加权平均 AI 成本　= 0.68×0.35 + 0.20×0.81 + 0.09×2.00 + 0.03×2.55				¥0.66

表 3｜AI 调用成本分档明细（估算）。注意 TTS 是最大单项成本（占 AI 成本约 55%），远超 LLM——这与大多数人的直觉相反，也决定了压降手段的优先级（见 7.4）。

7.2　云资源清单与三档规模月度成本

资源项	1 万台在网	10 万台在网	50 万台在网	说明
MQTT 接入集群 EMQX	¥2,200	¥6,600	¥26,400	8C16G 节点，单节点承载 2 万长连接（留 50% 余量）
业务服务 K8s 集群	¥4,400	¥13,200	¥52,800	8C16G 节点 ×4 / ×12 / ×48
MySQL RDS 高可用	¥1,600	¥4,800	¥19,200	4C16G → 8C32G+只读 → 16C64G 分片×2
Redis 集群	¥700	¥2,100	¥8,400	会话、临期看板缓存、AI 结果缓存
TDengine 时序库	¥900	¥1,800	¥7,200	健康指标 + 设备温湿度
消息队列	¥1,200	¥2,400	¥7,200	RocketMQ 单机 → Kafka 3 节点 → 6 节点
向量库	¥0	¥1,600	¥6,400	一期复用 PG（pgvector），二期迁 Milvus
对象存储 COS	¥600	¥4,400	¥21,000	照片+语音，含生命周期分层与 7 天语音删除
CDN / 公网带宽	¥1,200	¥5,000	¥22,000	TTS 音频下行 + OTA 分发 + 图片回源
日志 / 监控 / APM	¥900	¥2,200	¥6,800	等保要求日志留存 ≥180 天
短信 / 推送	¥300	¥1,500	¥6,500	登录验证码 + 关键提醒兜底
等保三级安全组件	¥2,600	¥2,600	¥4,600	WAF / 堡垒机 / 数据库审计（基本固定成本）
基础设施小计 / 月	¥16,600	¥48,200	¥188,500	折合每台 ¥1.66 / ¥0.48 / ¥0.38
AI 调用小计 / 月	¥6,600	¥66,000	¥285,000	50 万台享年度用量包阶梯折扣 −12%
合计 / 月	¥23,200	¥114,200	¥473,500
★ 每台设备每月成本	¥2.32	¥1.13	¥0.95	年化 ¥27.8 / ¥13.6 / ¥11.4

表 4｜三档规模云成本（估算）。值得注意的是 1 万台阶段单台成本高达 ¥2.32——因为等保安全组件、K8s 底座、数据库高可用这些是阶梯式固定成本，摊不薄。这意味着早期规模不足时云成本会显著吃掉毛利，必须在业务规划中承认这一点，而不是拿 50 万台的边际成本去说服自己。

7.3　单位经济模型：每 100 台在网设备的年度损益

软件侧收入（每 100 台 / 年）	金额
基础会员　20 户 × ¥98	¥1,960
AI 膳养方案　9 户 × ¥398	¥3,582
AI+真人营养师　3 户 × ¥3,000	¥9,000
保鲜配件复购　30 户 × 4 件	¥796
商城佣金　22 户 × ¥260 × 8%	¥458
收入合计	¥15,796 = ¥158 / 台 / 年

软件侧成本（每 100 台 / 年）	金额
云成本（AI + 基础设施）　100 × ¥1.13 × 12	¥1,356
真人营养师人力　3 户 × ¥1,200	¥3,600
客服（1 人服务 8,000 户）	¥1,350
保鲜配件成本（45%）	¥358
支付通道 0.6%	¥95
成本合计	¥6,759 = ¥68 / 台 / 年

单位经济结论

¥1.13

每台每月综合云成本
（10 万台规模，估算）

8.6%

云成本 / 软件收入
（¥13.6 ÷ ¥158）

¥90

软件侧年毛利 / 台
毛利率 57%

¥187

首年综合贡献 / 台
（硬件毛利 ¥97 + 软件 ¥90）

¥294

2.5 年 LTV（估算，
假设次年续费率 70%）

< ¥98

CAC 上限（LTV/CAC ≥ 3）
渠道扣点 30% ≈ ¥60，可接受

模型成立，但请注意成立的支点在哪里。
AI 推理成本只占软件收入的 8.6%，且随规模还会下降—— 「AI 太贵所以做不起来」在 2026 年已经是一个伪命题，本项目的成本风险不在这里。真正的两个杠杆是：

杠杆一：付费转化率 32%（假设值）。若实际只有 12%，软件年收入从 ¥158/台跌到约 ¥62/台，虽然仍能覆盖 ¥13.6 的云成本，但无法覆盖获客与研发摊销，整个模型从赚钱变成不亏钱。 这个数字必须在 T5 的 500 户内测阶段真实测出来，然后再决定量产规模——不能拿 PPT 上的假设去下 10 万台的单。

杠杆二：真人营养师人效。¥3,000/年这档看似高价，实则是全表毛利率最低的一档：人力成本 ¥1,200/户/年直接吃掉 40%。模型里假设 1 名营养师服务 120 户，若实际只能做到 60 户，这档就从盈利变成亏损。对策是「AI 起草 + 人工审核」——让 AI 完成 80% 的常规问答与方案初稿，营养师只做审核与月度复盘（详见 §9 风险 R14）。

7.4　成本压降手段（已计入上表，按贡献度排序）

节省 ≈ 45%

① 本地命令词兜底

ESP-SR MultiNet 内置 50–100 条高频命令词，「临期提醒」「存食材」「音量大点」「几点了」全程不上云，直接砍掉 50% 交互的 ASR+LLM+TTS 三项成本。单项贡献最大。

节省 ≈ 30% TTS

② TTS 预合成缓存

唤醒应答、临期播报模板、错误提示等固定话术离线预合成，存设备 Flash 与 CDN；模板句只合成变量部分（「明天到期：[菠菜、牛奶]」）。TTS 是最大单项成本，这里省的是真金白银。

节省 ≈ 85% 菜谱

③ 菜谱预生成 + 检索

不为每个用户实时生成菜谱。离线批量生成 3 万条结构化菜谱入库，运行时走「向量召回 → 规则过滤（忌口/临期）→ 轻量 rerank」，只在需要个性化改写时才调一次 LLM。

节省 ≈ 20%

④ 上下文裁剪

设备端对话只带最近 3 轮 + 结构化食材摘要（而非全量食材 JSON），把输入从约 4,000 token 压到 1,100 token。同样的回答质量，输入成本降 70%。

节省 ≈ 15%

⑤ 小模型分流

意图分类、食材实体抽取、敏感词拦截用自部署 1.5B 小模型（单卡即可跑数千 QPS），只有开放式对话才上大模型。同时降低延迟 100ms+。

节省 ≈ 10%

⑥ 语义结果缓存

同一家庭 15 分钟内语义相近（embedding 余弦 > 0.95）的重复提问直接复用上次答案。家庭场景重复率高（一家人分别问「今天吃什么」），实测命中率预计 8–12%（待验证）。

结构性

⑦ 分级模型路由 + 配额

按会员档位与问题复杂度自动选 Lite / Pro；免费档强制 Lite 且月度配额 30 次云端对话（subscription.quota_json 硬扣减）。这是防止免费用户把成本打穿的唯一闸门。

节省 10–20%

⑧ 年度用量包锁价

与 AI 供应商签年度承诺用量包换阶梯折扣，同时锁定 12 个月单价——既降本，又对冲 §9 R5 的供应商调价风险。50 万台档的 −12% 即来自于此。

08

研发排期与里程碑

T0 至 T6 共 6 个月，五条泳道并行。排期的最大约束不是研发，是两条不可压缩的外部路径： 硬件的 3C / SRRC 认证（约 6–8 周）与生成式 AI 备案（约 60–90 天）。这两件事必须在 T1 之前就启动，否则代码写完了也上不了市。

周期为估算，认证与备案受主管部门排期影响

← 左右滑动查看完整甘特图 →

阶段 / 月份

T0 – T1

T1 – T2

T2 – T3

T3 – T4

T4 – T5

T5 – T6

硬件

方案冻结 · 选型定点

EVT 首样 30 台

DVT 100 台（结构 + 射频调优）

PVT 小批量试产 500 台

3C + SRRC 认证（外部路径，不可压缩）

MP 量产

固件

BSP 驱动 + ESP-SR 唤醒移植

语音全链路 + Opus + OTA

功耗调优 + 稳定性（重点攻坚）

灰度发布

云服务

设备网关 + 基础服务

AI 编排 + 保质期推理引擎

会员 / 订单 / 商城

压测 + 等保三级测评

App

冰箱 / 灶台主流程

小食对话 + 健康闭环

商城 + 会员支付

500 户内测（测真实付费率）

内容与运营

菜谱库 3 万条 + 品类基线库 1,200 SKU

生成式 AI 备案（外部路径，60–90 天）

文创 IP 洽谈与授权

文旅渠道首发筹备

M1 · T1.5　EVT 首样点亮，语音链路跑通 M2 · T3.0　唤醒指标达标（≥95%@3m 安静 / 误唤醒 ≤1 次/24h，目标值） M3 · T4.5　PVT 500 台试产下线 M4 · T5.5　3C + SRRC 取证 M5 · T6.0　文旅渠道首发 + 量产爬坡

图 3｜T0–T6 研发排期甘特图（周期为估算）。灰色斜纹条为外部依赖路径——认证与备案的时长不由我们控制，只能提前启动、并行推进。两个刻意的排期安排： ①「功耗调优」独占 1.5 个月且排在固件泳道最长段——因为续航是本项目最大的技术风险（见 §9 R1），必须给足时间做实测与迭代，不能压缩； ②「500 户内测」放在 T5–T6 且明确目标是测真实付费率——量产下单规模必须等这个数字出来才能定，这是 §7 单位经济模型唯一的真实性校验点。

09

风险登记表

以下每一条都是我们认为真的会发生的事，不是走过场的风险清单。按「影响 × 概率」排序，高优先级在前。其中 R13（付费转化不及预期）、R14（营养师人效）是真正的商业生死题； R1（续航）已通过「2000mAh + DTIM10 双模 + 光感息屏」在方案内闭环，不再是未决风险。

ID	风险	影响	概率	说明与应对措施
技术风险
R1	Wi-Fi 常连续航风险已闭环	中	低	已识别并已在方案内闭环，不再是未决风险。原 BRIEF 续航口径偏乐观，本方案通过四项设计把续航做实： ① 电池扩容至 2000mAh（较初版单电芯容量翻倍）， ② Wi-Fi 采用 DTIM10 modem-sleep + 事件驱动唤醒双模——非交互态进 modem-sleep（均值约 2mA），仅在定时同步、BLE 侧触发或本地命令词命中时才唤醒射频，彻底规避 Wi-Fi 常连高耗； ③ 光感 / 接近感应唤醒，非交互态自动息屏——1.69″ 屏仅在有人靠近或交互时点亮，待机功耗趋近零； ④ 宣传口径按三档如实标注：典型使用 10–14 天 / 重度 5–7 天 / 纯待机 30 天，不做单数字虚标。残余风险（唯一剩下的）：低温环境（冰箱旁 5–10℃）下锂聚合物电池可用容量衰减约 15%，对外标称已预留余量；但北方未供暖厨房冬季极端工况下实际续航可能下探至 8–10 天，需在 EVT 阶段做 −10℃ / 5℃ / 25℃ 三温区低温实测校准，再最终锁定标称值（详见 §3.1 功耗预算）。
R2	厨房环境远场语音识别劣化	高	高	抽油烟机噪声 65–75dB、流水声、电视人声干扰、油污附着麦克风网孔导致灵敏度衰减。 3m 远场唤醒率在强噪下可能从 95% 跌到 70% 以下。应对：双麦波束成形 + AEC；唤醒词训练集加入真实厨房噪声；麦克风孔加疏油防尘网并做可清洁结构设计；提供两条兜底交互——敲击贴面唤醒（加速度计）与手机 App 遥控，明确告知用户「油烟机开着时请敲一下」。
R3	VLM 食材识别准确率不达预期	中	高	塑料袋反光、散装堆叠遮挡、相似品类混淆（青椒/柿子椒、香菜/芹菜叶）。目标 Top-1 ≥85%（估算），实际首版可能只有 70%。应对：不追求全自动——识别结果一律进「待确认」态，把纠错设计成点一下就改完的 3 秒交互（而非弹窗+搜索+选择的三步流程）。产品叙事从「AI 全自动识别」改为「AI 帮你填好，你确认一下」，预期管理到位就不算失败。累计 10 万张纠错数据后评估自建轻量模型。
R4	保质期推理误差引发用户不信任	中	中	门外传感器测不到箱内真实温度（见 §5），基线库覆盖不全，用户可能遇到「说还有 3 天，打开已经坏了」。应对：置信度机制显性化（<0.7 显示「约」字）；推理值一律向保守方向取整（宁可提前一天提醒）；二期推出 ¥29 的 BLE 箱内温感子设备；对高风险品类（生鲜肉禽、海鲜）默认采用最保守基线。
R5	三方 AI API 可用性与调价	中	中	单点依赖火山引擎，其故障即我们全站语音功能不可用；模型下线或调价我们无议价能力。应对：ASR / LLM / TTS 三类能力各接 2 家供应商，统一适配层 + 健康检查 + 自动熔断切换（切换阈值：连续 3 次超时）；签年度用量包锁定 12 个月单价；核心链路做降级预案（LLM 不可用时退回检索式问答）。
供应链风险
R6	ESP32-S3 模组交期与涨价	高	中	历史上有过 8–12 周交期与阶段性涨价。模组占 BOM 的 29%（¥28 / ¥100.3），涨 20% 就吃掉 5.6 个点毛利。应对：EVT 阶段同步验证 -1U（外置天线）与 N8R8 的 pin 兼容替代型号并一起过认证；备 6 周安全库存；与两家授权代理并行签框架协议，避免单一渠道。
R7	LSR 硅胶壳色差与批次一致性	中	高	文创色（洪崖洞夜蓝 + 金、峨眉金顶棕 + 米）跨批次 ΔE 可能 >3，肉眼可辨。「一板 N 皮」策略的成败全在硅胶壳的品质稳定性上——皮做砸了，整个文创溢价逻辑就不成立。应对：签样品色板并写入验收条款（每批 ΔE ≤ 2）；深色系优先采用包胶/双色注塑而非全透色母；量产前做 3 批次色差比对；文创款首发限量，避免大批量色差事故。
R8	PVT 到 MP 的良率断层	中	中	高发项：N52 磁铁胶合脱落（冰箱门反复开合的剪切力）、喇叭异音、Type-C 口结构疲劳、2.5D 玻璃盖板崩边。应对：PVT 500 台中抽 200 台做跌落（1.2m × 6 面）+ 温循（−10℃~55℃ × 20 次）+ 8 小时连续播放老化 + 磁吸 5,000 次开合；良率目标 ≥97% 方可放行 MP。
合规风险
R9	生成式 AI 备案周期不可控，可能卡上市	高	中	备案 60–90 天（估算）且不保证一次通过。若硬件已量产而备案未下，核心卖点「AI 营养师」无法开放。应对：① T1 立即启动，不等产品做完（已体现在 §8 排期）； ② 架构预留降级形态——首发版本可先以「检索式问答 + 规则推荐」上线（不调用生成式模型，不属于生成式服务），备案通过后通过 OTA + App 更新开放自由对话。这条路径必须在 T2 就完成技术验证，不能事到临头再改架构。
R10	文创 IP 授权成本与周期	中	高	洪崖洞、峨眉山、渝超/湘超均涉及不同授权主体，费用估算 ¥5–30 万/IP/年 + 销售分成 3–8%，谈判周期 2–4 个月（估算/待验证）。这个周期比整个硬件开发还长，很可能赶不上首发。应对：首发款优先采用无需授权的城市地标写意插画（自行原创绘制，不使用任何官方 LOGO、不使用受保护的具体形象），法务预审规避近似侵权；正式 IP 谈成后作为二批次联名款上市。体育 IP 优先谈单赛季、单区域的小范围授权降低门槛。
R11	AI 营养建议的责任边界	高	低	概率低但后果极重：用户依据 AI 建议调整饮食后出现健康问题并主张因果关系。应对：见 §6.6 全套边界设计（三条红线 + 慢病高约束链路 + 双重拦截 + 常驻免责声明）；真人营养师须持 RD/DTR 资质并签署服务边界协议；配套产品责任险与医疗职业责任险，建议保额 ¥500 万（估算）。
R12	儿童数据与家庭隐私舆情	高	低	家庭场景必然涉及儿童数据；带麦克风的入户设备天然是舆情敏感对象，一篇「你家冰箱贴在偷听」的爆款文章足以摧毁品牌。应对：见 §6.1–6.4；额外准备技术白皮书与第三方安全审计报告（上市前完成），主动公开唤醒机制与数据流向；物理静音键作为核心卖点正面宣传而非隐藏功能。
商业风险
R13	付费转化率远低于 32% 假设	高	高	整个商业模型最大的单一变量。32% 是假设值，国内工具类 App 付费率中位数普遍在 3–8%，硬件绑定用户会显著高于此，但能否到 32% 完全没有验证。若实际只有 12%，软件年收入从 ¥158/台跌到约 ¥62/台，虽仍覆盖 ¥13.6 云成本，但覆盖不了获客与研发摊销。应对：① 硬件盒内附赠 3 个月 AI 膳养方案体验（边际成本仅 ¥6/台），把付费档做成默认体验而非需要主动尝试； ② PVT 500 台内测阶段就把真实转化率测出来（已排入 §8 T5–T6），拿到数字再决定量产规模—— 绝不拿 PPT 假设去下 10 万台的采购单；③ 若转化率确实偏低，可上调硬件定价并弱化软件依赖，退回「硬件为主」模型。
R14	真人营养师供给无法规模化	高	高	全国注册营养师约 1.5 万人（估算），且优质从业者已被医院、月子中心、私教机构占据。模型假设 1 人服务 120 户，实际可能只有 60–80 户—— 那么 ¥3,000/年这档会从盈利直接变成亏损（人力成本从 ¥1,200/户升至 ¥1,800–2,400/户）。应对：① 「AI 起草 + 人工审核」模式——AI 完成 80% 的常规问答与方案初稿，营养师只做审核签字与月度复盘视频，把人效从 60 户拉到 120 户以上； ② 与营养学院校合作建立实习生梯队（在校生做初审，注册营养师终审）； ③ ¥3,000 档设置年度招募上限，做成稀缺服务而非无限供给——既保证服务质量，又把它变成品牌背书与转化钩子，而不是主要收入来源。
R15	硬件毛利被渠道扣点吃掉	中	高	文旅景区、商超、连锁渠道扣点普遍 25–40%。基础款 ¥199 × 60% = ¥119，对落地成本 ¥107 几乎无利可图，还要承担退换货与铺货占款。应对：① 渠道走文创款（¥249，落地成本约 ¥108），¥249 × 65% = ¥162，尚有 ¥54 毛利；基础款只走自营与私域； ② 把渠道重新定位为获客通道而非利润来源——用 LTV（软件侧 ¥90/年 × 2.5 年 ≈ ¥225）覆盖渠道让利，渠道每卖一台的真实价值是带来一个 LTV ¥294 的用户，而不是那 ¥54 毛利； ③ 与文旅渠道谈联合定制款分成模式替代纯扣点。
R16	冰箱贴使用衰减，沦为「死物」	高	中	智能硬件的通病：新鲜感过后三个月不再使用，设备变装饰品，会员自然不会续费—— 而整个七层盈利模型全部建立在「设备持续在网、持续产生数据」这一前提上。应对：① 把设备做成家庭信息中枢而非单一食材工具——时钟、天气、家庭留言板、儿童习惯打卡、有声书、节气提醒，语音食材管理只是其中一个高频场景；② 每月推送节气食谱语音卡与文创皮肤上新，制造内容节奏； ③ 把「D30 日均语音交互次数 ≥3 次」定为北极星指标（目标值/待验证），低于阈值的用户触发运营召回，而不是只看激活量与 GMV。

表 5｜风险登记表。影响与概率为团队主观评估（估算），需在项目周会上滚动更新。 R1、R13、R14 三条被单列为「生死题」的理由是：它们各自都能单独让这个项目不成立，且都无法靠技术方案彻底消除，只能靠提前实测、诚实定价、模式调整来管理。

R1

续航风险已闭环

电池扩容至 2000mAh，Wi-Fi 改 DTIM10 modem-sleep + 事件驱动唤醒 双模，屏幕光感/接近唤醒自动息屏，对外标称 典型 10–14 天 / 重度 5–7 天 / 纯待机 30 天 三档如实标注。实物级风险已闭环，唯一残余是低温（冰箱旁 5–10℃）容量衰减约 15%，留待 EVT 低温实测校准。

R13

付费转化率是商业生死题

整个模型建立在 32% 付费率的假设上，而这个数字目前零验证。必须在 PVT 500 台内测阶段拿到真实值，再决定量产规模。 AI 成本只占收入 8.6%，转化率才是那个 100% 的变量。

R14

营养师人效是模式生死题

¥3,000/年这档是唯一不可规模化的收入——它依赖稀缺人力。若人效做不到 120 户/人，这档从盈利变亏损。解法只能是「AI 起草 + 人审」，并把它定位为品牌背书而非主收入。

Engineering Verdict

工程结论：这件事能做，但要诚实地做

从纯技术视角看，「食光贴 + 食光 App」不存在任何需要突破的技术难题—— ESP32-S3 的语音方案是成熟公版，大模型能力全部外购，云架构是标准的 IoT + 微服务组合。 6 个月做到量产是现实的排期，前提是 T1 就把认证与备案两条外部路径推进起来。

成本侧完全不构成障碍。每台设备每月综合云成本约 ¥1.13（10 万台规模，估算），年化 ¥13.6，仅占软件侧收入的 8.6%。在 2026 年，「AI 调用太贵所以商业模型不成立」已经是一个过时的担忧—— 本项目 AI 成本中最大的单项甚至不是大模型，而是 TTS。

真正的风险全部在技术之外： 续航能否达到用户预期（R1，技术上有解但必须改宣传口径）、付费转化率能否验证 32% 的假设（R13，需要 500 台真实内测）、真人营养师能否规模化供给（R14，需要用 AI 重构服务交付方式）。这三件事没有一件能靠写代码解决，但每一件都能单独让项目失败。

因此本方案的核心建议是：把 PVT 500 台内测做成一次严肃的商业假设验证，而不是一次工程试产。 测续航、测唤醒率、测识别准确率，更要测付费率与留存。拿到这四个真实数字之后，再决定量产 1 万台还是 10 万台—— 这才是对投资人和对自己最负责任的做法。

6 个月

T0 → MP 量产（估算）
关键路径为认证与备案