鸿蒙双AI饮食App横评：豆包与DeepSeek协同表现

在试过几十款饮食记录App后，不少人都会觉得：准确记下每一餐，比坚持健身本身更折腾。更扎心的是，记下来的不过是一串数字——热量、蛋白质、碳水——然后呢？下一步该怎么做，绝大多数工具都给不出实质指引。

这正是「食刻」采用双AI引擎架构的底层逻辑。不是为了炫技，而是为了破解一个真实且反复被验证的痛点：记录太慢、反馈太浅、建议过于模板化。

一、为什么需要双 AI 引擎？

传统饮食 App 的痛点

用过Keep、薄荷健康、MyFitnessPal的用户都有体会：记录一顿饭需要多久？从搜索食物名称，到手动筛选匹配项，再到确认份量、归类餐段，整个过程起码2到5分钟。而且记完后，App只告诉你：今天摄入1450千卡，蛋白质45克。然后——没了。碳水比例偏高怎么调？蛋白质缺口怎么补？App给不出答案。

我们的解法：双引擎分工

食刻的解决方案是引入两个AI引擎，各司其职，不走全能型路线。

🧠 豆包 doubao-seed-2-0-pro

专注多模态识别。无论是文字描述还是拍照上传，它都能快速返回结构化营养数据。一句「今天中午吃了鸡腿饭」，它能瞬间识别出具体食物种类及对应营养信息。

🔮 DeepSeek v4-pro

负责推理与对话。它不处理图片，但擅长生成个性化饮食计划、分析用户健康数据、预测体重趋势，甚至产出智能报告。简单说，豆包把「吃了什么」翻译为数据，DeepSeek回答「接下来吃什么」「怎么吃更好」。

二、架构设计：统一抽象层

核心思路

两个引擎彼此独立，通过一个统一的DoubaoApiService抽象层管理。API Key、Endpoint、Model各自配置，互不干扰。这套设计的优势在于：日后替换某个AI引擎，只需修改三处配置，核心业务逻辑几乎无需改动。

从用户输入开始，系统按场景自动分流：食物识别任务走豆包，智能对话任务走DeepSeek。两个引擎的调用接口、参数结构、响应解析完全不同，但上层业务无需感知这些差异。

关键代码层面，DoubaoApiService核心结构清晰：豆包端提供identifyFood方法，支持文字和图片两种输入；DeepSeek端提供generateDietPlan等方法，走纯文本推理路线。

关键设计决策：为什么不共用一个 API 方法？

这里有一个工程层面的严谨判断。端点和鉴权：豆包走火山引擎的ark.cn-beijing.volces.com，DeepSeek走api.deepseek.com，鉴权方式略有差异——前者用火山引擎Bearer Token，后者用DeepSeek自己的Bearer Token。请求格式上，豆包是自定义JSON结构，DeepSeek则兼容OpenAI格式。响应解析更是天差地别：豆包需要提取foodName、calories等字段，DeepSeek直接返回Markdown文本。更不用提超时设置：识别场景要求10秒内出结果，推理场景可放宽到30秒。

结论很清晰：强行合并只会让代码陷入无尽的if-else分支，维护成本远高于分而治之。

三、AI 对话数据流：历史记录如何持久化？

问题场景

想象一个典型场景：用户在「饮食计划」页面和DeepSeek聊了10轮，然后临时切到首页看一眼热量环，再回来时——对话上下文还在吗？

答案是肯定的。食刻借助Preferences组件，在本地持久化了每一轮对话。流程如下：页面加载时，先从本地磁盘读取历史消息；用户发送新消息时，系统携带完整上下文向DeepSeek发起请求；收到回复后，连同所有历史一起写回磁盘。

每个 AI 场景独立存储

这里有一个值得关注的细节：不同页面的AI对话使用不同的Preferences Key。DietPlanPage用chat_diet_plan，HealthAdvicePage用chat_health_advice，以此类推。这样做的好处是，用户在不同模块的对话互不干扰，且每次只读写当前页面数据，性能开销降到最低。

那么，为什么不选择云端存储？一个关键原因在于：饮食数据属于高度隐私的个人信息，用户大概率不希望自己的饮食习惯被上传到别人的服务器上。本地存储同时保证了零网络延迟，页面切换时几乎瞬间恢复对话上下文。

四、实际效果：3 秒 vs 3 分钟

记录效率对比

实测数据非常直观：食刻的AI文字或拍照识别，从输入到输出完整食物识别和营养估算，仅需3秒。相比之下，传统手动查库方式，光是搜索加筛选这一步，每道食物就要耗掉30到60秒。加上手动归类餐段，一顿饭的总耗时从传统的2到5分钟，直接压缩到10秒以内，时间降低了整整40倍。

随便对比一下：传统方式下，打开记录入口1秒，输入搜索食物30到60秒，营养计算自动完成，但归类餐段还得手动操作。而食刻的AI模式，同样是打开入口1秒，输入「鸡腿饭」2秒完成，营养计算由AI自动返回，餐段归类也由AI自动判断。

DeepSeek 的数据驱动建议

传统App所谓的「建议」往往是一段模板化的通用文本，比如「建议多吃蔬菜」。坦率说，这类建议有没有营养都存疑，更别说指导意义。食刻的DeepSeek会读取用户近7天的真实饮食数据，然后给出基于数据的个性化反馈。例如，「您最近三天晚餐的碳水摄入比例超过60%，建议在晚餐中用30克粗粮替代部分白米饭」。这就是数据驱动与模板化的本质区别。

五、竞品全景对比

放到市场去看，主要竞品在这方面的差距更为明显。Keep、薄荷健康、MyFitnessPal目前均未提供AI食物识别、AI饮食计划、AI健康分析等功能，而食刻通过双引擎补全了这些空白。桌面Widget方面，竞品提供基础版本，食刻则做了3张卡片式的丰富展示。视觉效果上，保持2D和扁平化风格的竞品，与食刻的Neumorphism 3D风格形成了明显分层。

六、总结与下篇预告

核心要点再回顾一下：双引擎不是技术炫技，而是基于真实场景驱动的工程选择——识别场景追求速度，用豆包；推理场景追求深度，用DeepSeek。统一抽象层的设计让替换AI引擎只需改动三处配置，工程上极其轻量。对话数据通过Preferences做本地持久化，用户离开再回来不会丢失上下文，且所有饮食数据始终留在设备上，不离开本地。

下一篇将换个视角，从视觉层面切入：《纯 ArkUI 实现 7 层拟物 3D 环形进度图：零依赖的视觉革命》。届时会拆解食刻首页那个令人印象深刻的环形进度图，看看它是如何用纯ArkUI组件，在无Canvas、无3D引擎、无第三方依赖的前提下，靠7层组件的创意叠加手工打造出来的。