逛 IFA 有个很有意思的规律越是人头攒动的展台越容易看到两类东西一类是铺满整面墙的巨屏一类是形态各异的 AI 硬件小玩意。今年我在几个展馆之间来回穿梭停留时间最久的反而不是那些电视墙而是一条挂在脖子上、乍看不太起眼的小项链——ODYSS。它想干的事说起来很朴素你吃饭的时候胸前这枚小小的摄像头看一眼餐盘AI 就能告诉你刚才吃进去的大概是什么、热量几何、蛋白质和碳水各自占了多少。不用掏手机拍照不用在 App 里一条条搜食物库更不用拿厨房秤去称。这念头听着挺美但我第一反应其实是打问号。饮食记录这件事过去十年里被反复做过手动记账式、条码扫描式、拍照识别式几乎每一代都有人尝试最后能让人长期坚持下来的产品屈指可数。所以真正值得聊的不是AI 项链这个噱头本身而是它背后的技术链路到底撑不撑得住这个使用场景以及如果换我来做类似的方向我会在哪个环节上打问号、在哪个环节上花时间。这篇就沿着这条线索拆开说包括视觉识别怎么落地、份量估算为什么是最深的坑、端侧算力怎么权衡还有一些我自己踩过、或者看别人踩过的坑。不管你是想买个设备尝鲜还是琢磨着做类似的产品应该都能捞到点能直接用的东西。1. 从记不住吃了啥到AI 帮你盯着这个需求到底真不真1.1 饮食记录为什么总是三分钟热度先说实话饮食记录是健康类 App 里留存率最难看的一类。原因不复杂就是摩擦太大。你得先想起要记再掏手机打开 App搜索食物选份量然后还得琢磨这一勺大概是 15 克还是 25 克。一顿饭下来光录入就能花掉五六分钟。人在饿的时候是最没耐心的等他吃饱了又懒得回头补录。行业里一个被反复验证的现象是绝大多数人记录饮食坚持不过两三周掉队的高峰通常出现在第一周周末——因为周末在外吃饭食物条目搜不到直接放弃。更麻烦的是估算精度。一份家常炒青菜油放多放少热量能差出一倍。一碗米饭是小碗还是大碗很多人自己都说不清。所以过去这些产品遇到的困境是双重的录入门槛高录进去的数据又不够准。准确性不够反馈就没有说服力反馈没有说服力用户就更不愿意继续录。这个循环一旦形成产品基本就凉了。1.2 ODYSS 想卡住的正是录入这一环把摄像头挂在胸前本质上是在干掉掏出手机、对准食物、按下快门这一整套动作。你坐下吃饭设备自己感知到场景自动拍几张剩下的交给模型。从产品逻辑上讲这个切入点是聪明的它没有去解决估算不准这个硬骨头而是先把录入摩擦压到接近零。只要录入成本足够低哪怕精度只有七八成用户也愿意容忍因为他几乎没付出什么。这跟当年手环把手动记步数变成自动计步是一个道理——精度没提升多少但门槛降下来了行为就变了。当然代价是把难题从用户手动输入转移到了算法自动推断。摄像头拍到的画面跟用户脑子里那个我知道我吃了什么的认知之间隔着一条相当长的技术链路。这条链路能不能走通决定了这东西是刚需还是玩具。1.3 谁是真的目标用户我倒不觉得这是个人人必备的设备它更可能先在一些特定人群里站住脚。第一类是正在做体重管理的人他们对摄入量的敏感度高又确实需要持续记录愿意为少花点力气买单。第二类是健身增肌人群他们关心蛋白质摄入是否达标需求量化的正反馈。第三类是单纯想了解自己饮食结构的人——不为了减重就是想知道自己是不是长期蔬菜吃太少、外卖吃太多。这里要划清一条线这类设备做的是饮食行为的记录与呈现属于健康管理的辅助工具不是医疗设备不能拿来做任何诊断或者替代医嘱。把它当成一面照出你吃了什么的镜子这个定位才是稳的。用户预期一旦被拉高到能治病的程度后面全是麻烦。2. 让 AI 看懂食物这条链路到底怎么走2.1 第一关先得拿到一张看得清的图很多人一听胸前挂个摄像头第一反应是这角度能拍全吗。这确实是最先要过的工程关。摄像头挂在锁骨下方镜头大致是俯视餐桌的视角这个角度其实比举着手机拍更稳——因为人的身体本身就是一个三脚架。但问题也有坐姿一变俯仰角跟着变穿外套的时候挂坠容易被挡住在光线暗的餐厅画面噪点会明显上升。所以这类设备在硬件上通常要处理几件事。一是广角与畸变的平衡视场角太小装不下一整张餐桌太大则边缘畸变严重、中心分辨率被稀释。二是有没有辅助传感器比如部分方案会加一颗低功耗的接近传感器或者 IMU用来判断用户是不是坐下了、面朝桌子从而决定什么时候唤醒摄像头。这比一直开着录像要省电得多也是这类产品能不能做到一天一充的关键。提示判断一个可穿戴记录类设备是否成熟先看它的触发策略。如果它需要你手动按一下才开始记录那本质上还是老一套只是把手机换成了挂件真正省事的是那种能在你坐下、餐盘进入视野时自动触发的方案。2.2 第二关从像素到这是什么菜图像拍到了接下来是识别。这里的技术路线选择差别很大我按复杂度从低到高捋一遍。最轻的是图像分类整张图丢进去输出一个标签比如牛肉面。优点是模型小、跑得快缺点是信息量太少——一碗牛肉面里有面条、牛肉、汤、青菜分类模型给不出这些细分。往上一档是目标检测在图上画框标出这块是米饭、这块是红烧肉、这块是青菜。这已经实用多了因为不同食材的热量密度差得远必须拆开算。但检测模型需要标注数据而食物检测的标注尤其麻烦——一盘麻婆豆腐该怎么框汤汁算不算重叠的食材怎么分割这些都是标注规范里要吵很久的问题。再往上一档是多模态大模型。把图片丢给视觉语言模型直接让它输出结构化的食材列表和大致份量。这条路门槛最低起步最快但有两个现实约束一是推理成本一顿饭拍三张图就是三次调用二是稳定性同一盘菜不同角度拍模型给出的答案可能飘。实际产品里比较务实的做法是分层端侧跑一个轻量检测模型负责常见食物识别置信度低的再走云端大模型兜底。还有一点特别值得说中餐是这个领域的地狱难度。西餐的食材边界清晰一块牛排就是一整块沙拉里几片叶子分得开。中餐是复合菜鱼香肉丝里可能同时有猪肉、木耳、胡萝卜、青椒、笋丝而且全都切成丝混在一起肉眼都难分更别说模型。市面上的公开食物数据集绝大多数是西餐视角的中餐品类覆盖很有限。想做这块自采数据几乎绕不开。2.3 第三关份量估算真正的深水区识别出这是米饭只完成了一半另一半是有多少克。而这后一半才是整个链条里最容易崩的地方。单目摄像头没有深度信息怎么知道那碗米饭离镜头多远、有多大常见的补偿手段有这么几种。一是引入参照物比如餐盘边缘、筷子、标准尺寸的餐具通过已知尺寸反推画面尺度。二是用深度传感器比如结构光或者 ToF直接拿到距离图再结合分割出的区域估算体积。三是多帧融合趁着吃饭过程中角度变化用运动恢复结构的方法粗略估计立体形状。听起来都有道理但误差会一路累积。我拿一个具体例子算一遍你就明白了假设模型识别出这是一碗米饭识别本身准确率 90%份量估算的体积误差是正负 25%从体积换算到克重还要假设一个密度值米饭的松散程度不同这个值上下浮动 15%最后从克重换算热量又有一个换算系数误差。这几项误差不是简单相加但方向一致时会叠加最终落到热量上的误差很容易到正负 30% 以上。这意味着什么意味着如果用户真实摄入了 600 千卡设备报出来可能是 420 到 780 千卡之间。对想控制总摄入的人来说这个区间还勉强能用作趋势参考——你至少知道今天是不是吃多了。但如果用它做精细的宏量营养素配比比如今天蛋白质必须吃够 120 克那这点精度就不够看了。所以我在看这类产品的时候会特别关注一个问题它有没有做餐前校准或者用户校正的入口。比如让用户第一次用的时候拍一张标准餐盘做尺度标定或者在 App 里允许用户手动修正份量。愿意留这个入口的产品说明团队清楚自己的边界在哪一个入口都不留、宣称全自动高精度的反而要小心。3. 硬件上的取舍为什么是项链不是眼镜或手环3.1 佩戴位置直接决定数据质量形态选择不是审美问题是数据质量问题。智能眼镜视角最好几乎就是第一人称但电池空间小、散热困难连续拍摄撑不了多久而且戴着眼镜对着人吃饭社交场合的接受度是个大问题。手环和手表角度完全不对手腕朝下的时候镜头拍到的是桌面而且吃饭时手在动画面全是糊的。项链或者胸针的位置恰好落在一个舒服的中间地带俯视角够用能拍到餐桌全貌佩戴不算突兀至少比眼镜自然最关键的是锁骨附近这块空间足以塞下一块中等容量的电池和一颗带 NPU 的芯片。这不是巧合而是被物理条件筛出来的结果。3.2 功耗、发热与续航的三角博弈这是所有可穿戴设备的宿命难题三者只能取其二。摄像头连续工作是耗电大户一颗几百万像素的传感器全速运行功耗大概在几十毫瓦到上百毫瓦量级再加上 NPU 跑推理、蓝牙或 Wi-Fi 传输数据整机功耗很容易上去。而项链形态的电池容量通常也就一两百毫安时这是物理天花板不是设计偷懒。所以真正能做出续航的产品一定在什么时候不工作上下了功夫。常见的策略是分级唤醒平时摄像头断电只留一颗微瓦级的运动传感器或者环境光传感器监听检测到坐下且静止这个组合信号唤醒低分辨率摄像头做一次快速判断确认画面里有餐盘特征再唤醒主摄和 NPU 做正式拍摄。整个流程走完拍三五张图然后立刻回到低功耗状态。这样一天三顿饭下来实际工作时间可能只有几分钟续航自然就撑得住了。发热也得提一句。贴近皮肤的金属挂坠一旦温升超过体感阈值佩戴者会立刻摘下来这比电量耗尽更致命。所以芯片选型上往往要牺牲一点峰值算力换取更好的能效比——这也是为什么这类产品通常只做拍摄 轻量推理重活儿都扔给手机或云端。3.3 隐私这件事设计阶段就得想清楚胸前挂个摄像头拍到的绝对不只是食物。餐桌对面坐着谁、桌上摆着什么东西、背景里有什么全在画面里。这不是小问题是能不能上市的问题。比较稳妥的做法有几层。第一层是拍摄范围限制通过镜头焦段和安装角度把有效成像区域约束在餐桌附近尽量不拍到人脸高度。第二层是端侧处理优先能本地跑完的绝不上传只把结构化的结果——食材名、克重、热量——传出去原始图像用完即删。第三层是物理遮挡给一个明确的机械开关或者可滑动的盖板让用户能确信此刻它没在看。第四层是数据留存策略透明化用户能查到自己的图存在哪、存多久、怎么删。这四层里我认为第三层最被低估。用户对一个摄像头设备建立信任靠的不是隐私政策写了多少字而是他能不能用手指确认它关掉了。这个动作的心理价值远高于任何技术承诺。4. 从看懂到用得上数据闭环怎么设计才不鸡肋4.1 反馈时机比反馈内容更重要我见过太多健康类产品把数据做得漂漂亮亮报表一堆结果用户看两次就再也不打开了。问题往往不在数据本身而在给的时机不对。饭后两小时给你推送一份详细的营养分析这时候你既改不了这顿饭也早就忘了当时吃了什么这份报告的价值就趋近于零。更有效的设计是把反馈拆成三段。餐前给一个轻提醒比如你今天蛋白质还差不少这个提示有可能影响你点什么菜——这是唯一能真正改变行为的窗口。餐中给即时提示比如检测到连续上了三道油炸食物轻轻震一下不弹窗、不说教只是提醒。餐后则不给即时反馈攒到晚上做一次简洁的日汇总一两句话概括比如今天蔬菜偏少晚餐补一份凉拌菜就差不多了。提示判断一个记录类产品的设计水平看它的通知频率。一天推八条消息的产品用户第三天就会把通知关掉之后这个产品在他手机里就等同于不存在了。4.2 数据攒起来之后真正的价值在哪单次识别的价值有限真正有意思的是长期序列。连续记录几周之后你会看到一些自己完全没意识到的东西比如你的蔬菜摄入其实高度集中在周末比如工作日的午餐热量比晚餐高出很多比如每次加班那几天糖的摄入量都会跳一个台阶。这些模式靠回忆是想不出来的靠零散的手动记录也拼不出来。我个人的经验是这类数据最有用的地方不在于某一天吃了多少卡而在于发现自己的惯性。人对自己饮食的认知偏差很大很多人以为自己吃得挺清淡记录的第三周才会发现原来清淡的那几顿之外还有那么多没被记住的零食和饮料。这种认知冲击本身往往比任何精确数值都更能推动改变。当然这里必须再强调一次边界这些分析属于个人饮食行为的观察和呈现不构成任何健康或医疗建议。设备能做的是把事实摆出来怎么解读、要不要调整那是每个人自己的事需要专业意见时应该去问专业的人。4.3 商业化路径的几种可能硬件加订阅是这类产品最常见的组合。硬件本身赚不了太多研发成本摊在销量上定价太高压根卖不动订阅则是为持续的模型更新、云服务、数据存储买单。这里的关键是订阅得提供看得见的价值比如更细的营养分析、更长的数据历史、家人共享而不是把基础功能锁起来。另一条路是跟健身和健康平台打通。用户已经在别的 App 里记录体重、训练、睡眠如果饮食数据能自动流过去形成一个完整的生活画像黏性会强很多。但这条路的前提是接口开放和数据格式统一做起来谈判成本不低。还有一条是面向特定场景的定制比如健身房、健康管理机构、企业健康项目。这些场景里硬件成本可以被机构消化用户不需要自己掏钱接受度反而更高。这可能是这类产品比较现实的早期出路。5. 如果你也想做一套类似的方案怎么起步5.1 第一步先用手机把核心假设验证掉别一上来就开模做硬件。这个方向最核心的不确定性是识别精度够不够用而这个问题用一部手机加几个现成工具两周就能得到初步答案。具体做法是拿手机固定在一个胸前高度模拟未来设备的视角拍一百顿饭的照片涵盖家常菜、外卖、食堂、聚餐几种场景。然后把图片批量丢给视觉模型做识别让它输出食材列表和估算重量你自己用厨房秤把真实重量称出来做对照。做完这一百组对比你会得到两个关键数字食材类别识别对了多少份量估算误差有多大。这两个数字基本上就决定了这个产品能不能往下做。如果份量误差稳定在正负 30% 以内说明这条路能走如果误差是正负 60% 而且飘忽不定那多半是数据或者方法有问题得先解决这个再说硬件。5.2 数据集和标注成本会被严重低估几乎每个做这个方向的团队都在数据标注上栽过跟头。食物数据的标注比通用物体检测难得多难在边界定义。一盘西红柿炒蛋蛋和西红柿混在一起边界在哪一碗汤干货和汤水怎么分一份盖浇饭米饭被菜盖住了一半怎么估总量我的建议是一开始就把标注规范写死而且写细。比如明确规定混合菜按主要成分拆三到五类占比小于 10% 的不单独标注被遮挡超过一半的食材标注为不可见不计入总量之类的规则。规范越细后期返工越少。另外份量的真值必须靠称重获取这一步没有捷径——想省这个事后面所有精度指标都是空中楼阁。还有一点容易被忽略拍摄设备的一致性。训练数据是用手机拍的未来部署在项链上镜头焦距、视角、白平衡都不一样模型迁移过去会掉点。所以做验证阶段最好就用目标硬件的等效参数去拍或者至少在训练时做充分的视角和色彩增强。5.3 端侧部署的现实约束如果打算把推理放在设备上得先接受一个现实项链里能塞的算力非常有限。常见的做法是模型量化把浮点参数压到 8 位甚至 4 位整数模型体积能小好几倍速度也快代价是精度会掉一点通常掉一两个百分点可以接受掉太多就得重新训练。更实际的策略是任务拆分。把判断有没有餐盘这种简单任务放在端侧用一个几百 KB 的小模型就能搞定把识别具体是什么菜、有多少克这种复杂任务放到手机或者云端。这样端侧只需要极低的算力电池压力小整体体验也流畅。代价是依赖连接如果用户在没网的地方吃饭功能就降级了。折中方案是端侧跑一个精简版识别最常见的几十种主食和菜品精度低一点但离线可用联网后再补充细化。6. 常见问题与避坑清单6.1 典型问题速查下面这张表是我在梳理这类方案时整理出的几个高频问题以及对应的排查方向。做产品的可以当检查清单用普通用户也可以拿它来判断一款设备值不值得买。现象可能的根因排查与处理方向漏拍某顿饭触发条件太严坐姿变化未命中检查触发逻辑是否依赖单一传感器考虑加入手动补拍入口识别结果反复跳变单帧推理不稳定缺乏时序融合引入多帧投票机制对同一餐的多张图做结果聚合份量普遍偏大或偏小尺度标定缺失参照物假设错误加入首次使用的餐盘标定流程或提供份量微调入口续航明显短于预期摄像头或 NPU 未及时休眠检查唤醒后的回睡逻辑确认异常场景下不会一直挂着暗光环境识别率骤降无补光图像噪声大增加低亮度下的曝光策略或提示用户在光线好的位置就餐混合菜识别成一整类训练数据缺少复合菜样本补充切丝、混炒类菜品的标注数据调整拆分规则6.2 几条我自己的实操心得第一别指望算法一步到位把用户校正做成产品的一部分。我见过太多团队想在算法上死磕到 95% 精度再上线结果错过窗口。实际上允许用户在结果上顺手改一下——比如把米饭 200 克拖到 150 克——这件事的成本极低但对体验的提升非常明显。而且这些校正数据本身就是后续迭代最宝贵的训练样本。用户改得越多模型进步越快这是个正向循环。第二警惕识别准和有用之间的鸿沟。我见过识别准确率做得很高的原型食材认得八九不离十但用户用了一周就丢了。原因很简单数据准确不等于有用。用户想要的不是一份精确的营养报表而是我今天是不是该少喝一杯奶茶这种立刻能行动的判断。把精力从提高小数点的精度转移到把结论说得更直白回报率高得多。第三隐私设计要在第一版就做不要留到后面补。补隐私设计往往意味着改结构、改流程成本是初期的好几倍而且用户一旦对摄像类设备形成不信任后面很难扭转。宁可第一版功能少一点也要把拍摄范围、本地处理、物理遮挡这三件事做扎实。第四别忽略社交场合这个变量。一个人在家吃饭和跟同事聚餐佩戴意愿完全不同。我观察下来很多人第一次尝试这类设备最尴尬的场景就是饭局——你胸前挂着个摄像头对面的人会问你在录我吗。产品如果能设计一个明确的公共场合模式比如只做粗略估算、不拍照只靠手动输入反而更让人觉得这个团队想清楚了。第五硬件形态不要过早锁死。项链只是当前工程条件下的一种解。随着低功耗芯片进步、柔性电池成熟未来可能是领口夹、可能是眼镜腿、也可能是完全无感贴在衣领内侧的小贴片。做这个方向的人如果第一版就把所有资源押在一个模具上后面路线切换会很痛苦。留一点架构上的抽象层把采集—识别—反馈三段解耦换形态的时候只改第一段这是很划算的投入。说到底ODYSS 这类产品真正值得关注的不是它现在能识别多少种菜、误差多少个百分点而是它选择了一个正确的切入点把记录的门槛降到接近零让数据先流动起来。精度可以慢慢迭代数据积累是一次性的机会。谁能先让足够多的人愿意戴着它吃上三个月饭谁就拿到了别人拿不到的数据资产。至于这条项链最终会不会成为那个答案我的判断是形态未必是项链但这个思路大概率是对的。
