买多少 · 录入体验迭代：把记录搬到称重那一刻

痛点现场

做饭前称了一堆东西：鸡胸肉、米饭、西兰花、橄榄油。称完想着「等会儿一起记」，然后——就没有然后了。过半小时只剩下「好像有个二百多克的」。

更烦的是拍照识别。付费用过 YAZIO，拍一盘菜，它给出的名称经常不对，克重更是离谱。花钱买的识别，还不如我自己瞄一眼秤面准确。

为什么拍照识别救不了这件事

我一开始以为是「AI 不够准」，换个更贵的 App 就好了。想清楚之后发现，这条路的天花板是物理性的。

关键在于：拍照 AI 要从一张 2D 照片里同时猜两个值——这是什么、有多少克。

「是什么」：单一食材的识别准确率大概 60%-85%，混合菜和中餐再往下掉一大截
「是多少克」：2D 图像推 3D 体积，本身就是病态问题。油、糖、酱汁在照片里几乎不可见，而它们恰恰是热量大头

但真正的问题不在这里。真正的问题是：这两个值我本来就已经知道了。

食物是我自己买的、自己做的，名字我百分百确定；克重是我刚从秤上读出来的，精确到克。也就是说，拍照 AI 在费力地重新猜两个我已经掌握的数据，而且其中一个它根本猜不准。

所以痛点不是「识别不准」，是数据搬运断裂：信息在称重那一刻是完整的，几分钟后就蒸发了。

换了个问法

既然信息只在称重那一秒完整，那结论就很直接——把录入动作搬到秤旁边、搬到称重那一秒。不是「事后补记」，而是「边称边录」。

顺着这个思路，录入路径重排了一次。

三条捕获路径

路径	做法	成本	准确率	判断
语音速记	边称边念「鸡胸肉两百三，米饭一百五」，自动拆成结构化数据	零成本，本周可做	高（念的是自己刚读的数字）	先做这个
蓝牙智能秤	秤通过蓝牙把重量直接推给小程序	硬件 ¥50-150 + 对接成本	最高	排到第二期
拍照降级	AI 只认名字，不估克重；重量由我瞄一眼填进去	已有功能改造	中（一个值对，一个值准）	保留但不主推

语音速记是这次的核心。技术上走微信同声传译插件（WechatSI），或者录音 + 云 ASR。拿到文本后分两层处理：先用自己的历史食物表做本地匹配，命中就直接用，零延迟零成本；没命中再丢给大模型，用固定 prompt 输出结构化结果。一句话能录四五样，全程五秒。

蓝牙秤听起来最美，但有两个坑：多数秤的 BLE 服务 UUID 和数据格式不公开，得反协议；而且做饭现场多一步「先连蓝牙」的动作，反而可能成为新的摩擦点。等语音路径跑通、确认自己真会长期记录之后再上硬件也不迟。

拍照不砍，但改职责：从「猜两个值且两个都可能错」变成「猜一个值且大概率对，另一个值我一秒填完」。

两个高杠杆功能

除了换录入方式，还有两个功能能直接把工作量砍掉一个数量级。

常吃组合一键复用。 人的饮食是高度重复循环的，但这市面上几乎所有饮食 App 都让你每一顿逐项重录一遍。做成就餐时段分组（早/午/晚），每个 tab 下列出历史出现频率最高的组合，一键整体复用，克重可微调。粗略算了一下：一周 21 顿、每顿 4 项，原本 84 次录入操作，压到大约 10 次。这是杠杆最高的一个功能。

连续批量录入模式。 专门针对「称了一堆食物」这个具体场景：进页面后一直在录入态，加完一样直接加下一样，不保存、不返回、不跳页，最后一次性确认。再加一道保险——允许存无名条目，手忙脚乱时哪怕只敲了个「230」，也先存成「未命名 230g」，回头补名字。绝不让数据丢。

三周路线

时间	做什么	目的
第 1 周	语音速记 + 批量录入模式	让数据进得来
第 2 周	常吃组合一键复用	把重复劳动压掉 90%
第 3 周	采购反推：周消耗量 → 采购建议量	兑现「吃多少买多少」

第三步才是这个产品真正值钱的地方，也是「买多少」这个名字的兑现点。有了连续准确的消耗数据，就能算出「上周鸡胸肉消耗 1150g、米饭 2100g」，自动生成下周采购清单并给出建议购买量（消耗量 × 1.05 缓冲），再叠加保质期提醒把容易坏的排前面。

这一步别的 App 做不了，因为它们的数据源头是脏的。前面两步做好，才有资格做第三步。

这次决定不做什么

不再为拍照识别花钱。 不准不是供应商不行，是这条路的天花板就在那。预算和开发时间挪到语音和组合复用上。
先不买蓝牙秤。 理由上面说了。
不做社交、不做食谱推荐、不做营养评分。 地基没打好之前，任何上层功能都是空转。

录入体验是这个产品的地基。数据进不来，后面所有功能都是零。

记于 2026.09.29。下次迭代会补上真实的录入耗时对比和使用两周后的留存数据。