基于 HarmonyOS 的 AI 营养餐单规划应用开发实战——从对齐到评估的全流程技术实践

基于 HarmonyOS 的 AI 营养餐单规划应用开发实战——从对齐到评估的全流程技术实践一、项目背景与需求分析Align1.1 场景痛点与商业价值在当今快节奏的都市生活中健康饮食已成为越来越多人关注的焦点。然而面对琳琅满目的食材选择和复杂的营养学知识大多数人在日常饮食规划上存在显著困难。根据中国营养学会的调查数据显示超过 70% 的都市白领对自己的饮食结构不满意而其中仅有不到 15% 的人能够坚持科学地规划每日餐单。传统饮食规划方式面临以下核心痛点效率低下手动计算每日摄入热量、蛋白质、碳水化合物和脂肪的比例往往需要查阅大量资料耗时耗力。以一个普通用户为例制定一份符合个人目标的周餐单平均需要 2-3 小时且缺乏专业工具支持。经验依赖严重高质量的餐单规划严重依赖用户的营养学知识和烹饪经验。普通用户很难准确判断不同食材的热量密度和营养成分更难以在满足口感需求的同时保证营养均衡。个性化不足市面上通用的饮食推荐方案往往采用一刀切的模式无法充分考虑用户的个体差异——包括体重、年龄、活动水平、饮食禁忌、过敏原、目标类型减脂/增肌/维持等关键因素。反馈机制缺失传统餐单一旦制定缺乏即时的质量评估和优化建议。用户无法及时了解自己的餐单是否符合营养目标也无法获得针对性的调整建议。1.2 AI 营养餐单规划的解决方案定位针对上述痛点我们设计并开发了AI营养餐单规划应用——一款基于 HarmonyOS 平台的 AI 驱动的智能餐单生成工具。该应用的核心定位是智能化利用大语言模型的语义理解能力根据用户输入的目标、体重、饮食限制等参数自动生成个性化的每日餐单和营养成分分析轻量化采用 HarmonyOS ArkTS 技术栈构建轻量级、高性能的移动端应用无需安装额外依赖可扩展基于三层架构Model-Service-View设计便于后续接入真实的大模型 API 和扩展更多功能1.3 需求规格详细定义在需求对齐阶段我们与产品团队进行了多轮讨论最终明确了以下详细的输入输出规格用户输入字段字段类型说明示例值goalstring用户目标类型“减脂”、“增肌”、“维持”、“控糖”weightstring用户体重kg“65”heightstring用户身高cm“170”agestring用户年龄“25”genderstring性别“男”、“女”restrictionsstring饮食限制/过敏原“不吃海鲜、乳糖不耐受”meals_per_daystring每日餐次“3”、“4”、“5”AI 输出字段字段类型说明daily_caloriesstring每日推荐总热量proteinstring蛋白质推荐摄入量carbsstring碳水化合物推荐摄入量fatstring脂肪推荐摄入量meal_planstring[]餐单列表每餐名称和内容shopping_liststring[]购物清单weekly_variationstring一周变化建议tipsstring饮食建议和注意事项1.4 目标用户画像经过用户调研我们识别出三类核心目标用户群体第一类健康管理型用户占比约 55%。这类用户通常有明确的减脂或增肌目标关注每日热量摄入和三大宏量营养素的比例。他们需要的是科学、可量化的饮食方案且愿意在一定程度上配合餐单进行采购和烹饪。第二类特殊需求型用户占比约 25%。这类用户可能患有糖尿病、高血压等慢性疾病或存在食物过敏、不耐受等情况。他们需要的餐单不仅要满足营养需求还必须规避特定食材这恰恰是 AI 能够发挥优势的场景。第三类效率优先型用户占比约 20%。这类用户工作繁忙没有时间研究营养学知识但希望获得开箱即用的饮食方案。他们追求的是快速、便捷、可靠的餐单推荐。1.5 需求对齐方法与决策过程在需求对齐阶段我们采用了结构化的四步对齐法来确保需求理解的准确性和完整性第一步原始需求采集。从产品需求文档中提取原始需求描述包括用户故事、功能列表和验收标准。对于 AI营养餐单规划原始需求表述为开发一款基于 HarmonyOS 的 AI 营养餐单规划应用用户输入个人信息后AI 自动生成个性化的每日餐单和营养分析。第二步边界确认与歧义消除。针对原始需求中模糊或不明确的部分我们生成了一份结构化问题清单包括用户需要输入哪些具体字段是否需要身高、年龄、性别等信息AI 输出需要包含哪些营养指标是否包含微量元素如维生素、矿物质是否需要支持多语言当前版本是否需要国际化是否需要用户登录和数据持久化餐单数据的展示形式是什么列表还是卡片通过对这些问题的逐项讨论和决策最终明确了需求范围——当前版本聚焦于核心功能暂不包含微量元素分析、用户登录、数据持久化和多语言支持。第三步项目上下文分析。我们对现有项目进行了全面分析包括项目技术栈HarmonyOS ArkTS ArkUI 声明式框架现有架构模式所有 AI 应用统一采用 Model-Service-View 三层架构路由机制通过 router.pushUrl 实现页面跳转通过 main_pages.json 注册路由应用注册通过 resources/rawfile/apps/apps.json 配置文件注册到首页UI 设计规范统一使用柔和的背景色、圆角卡片、绿色主题色第四步共识固化。所有对齐结果最终写入共识文档明确了需求描述、技术方案、验收标准和边界限制为后续的架构设计奠定了坚实的基础。1.6 技术约束与边界确认在项目启动阶段我们明确了以下技术约束和边界条件项目采用 HarmonyOS ArkTS 语言开发需遵循 ArkTS 严格的语法约束不支持 any/unknown 类型、不支持解构赋值、不支持索引签名、不支持 as const 断言、不支持函数表达式等当前阶段使用 Mock 数据模拟 AI 大模型输出后期接入真实的大模型 API应用数据暂不持久化每次打开为全新会话不保留历史记录UI 设计遵循 HarmonyOS 设计规范主题色采用绿色系#2E7D32 / #1B5E20契合营养健康的应用调性应用通过 HarmonyOS 的 router 路由机制实现页面跳转通过 JSON 配置文件注册到应用中心首页仅支持单页面交互无需引入复杂路由栈管理二、技术架构设计Architect2.1 整体架构概览AI营养餐单规划采用 HarmonyOS ArkTS 技术栈遵循经典的三层架构模式Model-Service-View每一层各司其职┌─────────────────────────────────────────────────┐ │ View 层 │ │ AI营养餐单规划Page.ets │ │ ┌─────────────── ────────────────┐ │ │ │ State 驱动数据绑定 │ │ │ │ ArkUI 声明式组件 │ │ │ │ Scroll / Column / Row / Text │ │ │ └────────────────────────────────┘ │ ├─────────────────────────────────────────────────┤ │ Service 层 │ │ AI营养餐单规划Service.ets │ │ ┌────────────────────────────────┐ │ │ │ generateData() 业务逻辑 │ │ │ │ AI 大模型调用封装 │ │ │ │ Mock 数据生成 │ │ │ └────────────────────────────────┘ │ ├─────────────────────────────────────────────────┤ │ Model 层 │ │ AI营养餐单规划Model.ets │ │ ┌────────────────────────────────┐ │ │ │ 数据结构定义 │ │ │ │ 字段类型声明 │ │ │ │ AI营养餐单规划Data 实体 │ │ │ └────────────────────────────────┘ │ └─────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────┐ │ HarmonyOS 系统层 │ │ kit.ArkUIUI框架 kit.ArkTS基础库 │ │ router 路由跳转 资源管理 │ └─────────────────────────────────────────────────┘2.2 设计原则与决策依据在架构设计过程中我们遵循了以下关键设计原则单一职责原则每一层只负责一个明确的职责。Model 层只负责数据定义不包含任何业务逻辑Service 层只负责业务逻辑和数据生成不涉及 UI 渲染View 层只负责 UI 展示和用户交互不直接操作数据逻辑。依赖倒置原则高层模块View 层不依赖低层模块Service 层而是两者都依赖抽象Model 层的数据结构。View 层通过 Service 层接口获取数据而非直接依赖具体实现。接口隔离原则Service 层对外暴露的方法尽可能精简generateData方法承担了所有数据生成的职责View 层无需关心内部实现细节。开闭原则对扩展开放对修改关闭。当需要接入真实 AI 大模型时只需在 Service 层内部替换数据生成逻辑View 层和 Model 层无需任何修改。2.3 分层设计详解Model 层——数据实体定义Model 层是整个应用的数据蓝图定义了 AI营养餐单规划所需的所有数据字段。在 ArkTS 中我们使用export class来定义数据模型这与标准的 TypeScript 类声明一致但需注意 ArkTS 不支持索引签名和as const断言等语法。// AI营养餐单规划Model.etsexportclassAI营养餐单规划Data{daily_calories:stringprotein:stringcarbs:stringfat:stringmacros:stringmeal_plan:string[][]meal:stringitems:string[][]food:stringamount:stringcalories:stringmeal_calories:stringshopping_list:string[][]category:stringweekly_variation:stringtips:stringconstructor(){this.daily_caloriesthis.proteinthis.carbsthis.fatthis.macrosthis.meal_plan[]this.mealthis.items[]this.foodthis.amountthis.caloriesthis.meal_caloriesthis.shopping_list[]this.categorythis.weekly_variationthis.tips}}设计要点说明所有字段显式初始化空值避免undefined问题——ArkTS 不支持确定性赋值断言let v!: T数组类型字段meal_plan、items、shopping_list初始化为空数组确保在 ForEach 渲染时不会出现空指针异常构造函数中重复初始化所有字段这虽然看起来冗余但在 ArkTS 中是必要的——因为 ArkTS 要求在类声明内部声明类字段且不支持在构造函数中声明字段所有字段类型均为string或string[]避免了复杂类型带来的兼容性问题Service 层——业务逻辑封装Service 层是连接 View 和 Model 的桥梁封装了所有业务逻辑。当前阶段使用 Mock 数据模拟 AI 生成结果后续可以无缝替换为真实的大模型 API 调用。// AI营养餐单规划Service.etsimport{AI营养餐单规划Data}from./AI营养餐单规划ModelexportclassAI营养餐单规划Service{privatemodel:AI营养餐单规划Dataconstructor(){this.modelnewAI营养餐单规划Data()}// 生成AI营养餐单规划数据generateData(input:Recordstring,Object):AI营养餐单规划Data{letresult:AI营养餐单规划DatanewAI营养餐单规划Data()// Mock data generation based on inputletgoalVal:stringString(input[goal]||)result.daily_calories生成结果goalVal result.macros生成结果goalVal result.meal_plan[示例数据1,示例数据2,示例数据3]result.shopping_list[示例数据1,示例数据2,示例数据3]result.weekly_variation生成结果goalVal result.tips生成结果goalValreturnresult}}设计要点说明generateData方法接收Recordstring, Object类型的输入参数这是因为用户在页面输入的数据以键值对形式收集且 ArkTS 不支持any类型必须显式指定类型使用String()进行类型转换确保从Object到string的转换安全方法返回类型显式声明为AI营养餐单规划Data遵循 ArkTS 的规则——当返回类型被省略时如果 return 语句中的表达式是对返回类型被省略的函数或方法的调用会发生编译时错误Service 层采用无状态设计每次调用generateData都创建新的AI营养餐单规划Data实例避免状态污染View 层——ArkUI 声明式 UIView 层是用户直接交互的界面采用 HarmonyOS 的 ArkUI 声明式框架构建。通过State装饰器驱动数据绑定实现响应式的 UI 更新。// AI营养餐单规划Page.etsimport{AI营养餐单规划Data}from./AI营养餐单规划Modelimport{AI营养餐单规划Service}from./AI营养餐单规划Serviceimport{router}fromkit.ArkUIEntryComponentstructAI营养餐单规划Page{StateinputData:Recordstring,Object{}StateresultData:AI营养餐单规划Data|nullnullStateshowResult:booleanfalseprivateservice:AI营养餐单规划ServicenewAI营养餐单规划Service()build(){Column(){// 顶部导航栏Row(){Text(← 返回).fontSize(13).fontColor(#2E7D32).onClick((){router.back()})Blank()Column(){Text( AI营养餐单规划).fontSize(17).fontWeight(FontWeight.Bold).fontColor(#1B5E20)Text(NUTRITION · 营养标签).fontSize(9).fontColor(#43A047).margin({top:2})}Blank()Text().fontSize(22)}.width(100%).padding({left:20,right:20,top:16,bottom:14}).backgroundColor(#E8F5E9)// 滚动内容区Scroll(){Column(){// 输入区域this.buildInputSection()// 分析按钮this.buildAnalyzeButton()// 结果展示区this.buildResultSection()}.width(100%).padding({left:18,right:18,bottom:40})}.layoutWeight(1)}.width(100%).height(100%).backgroundColor(#E8F5E9)}}2.3 核心数据流设计AI营养餐单规划的数据流遵循单向数据流原则确保数据变更的可预测性和可追踪性用户输入 → 收集到 inputData (Recordstring, Object) ↓ 点击分析营养按钮 ↓ service.generateData(inputData) 调用 ↓ 返回 AI营养餐单规划Data 实例 ↓ 赋值给 State resultData ↓ ArkUI 自动检测状态变化 ↓ 重新渲染 UI展示结果这一数据流设计有两个关键优势可预测性数据始终沿单一方向流动不存在双向绑定带来的复杂状态管理问题响应式通过State装饰器ArkUI 框架自动追踪数据变化并触发 UI 更新无需手动操作 DOM2.4 模块依赖关系AI营养餐单规划应用的模块依赖关系十分清晰AI营养餐单规划Page.ets→ 依赖AI营养餐单规划Model.ets和AI营养餐单规划Service.etsAI营养餐单规划Service.ets→ 依赖AI营养餐单规划Model.etsAI营养餐单规划Model.ets→ 无外部依赖纯数据实体页面通过kit.ArkUI的router实现路由跳转这种低耦合的依赖设计使得每一层都可以独立测试和替换例如将 Service 层的 Mock 数据替换为真实 API 调用时只需修改 Service 层内部实现View 层和 Model 层均无需改动。2.5 UI 组件树与布局分析AI营养餐单规划页面的 UI 组件树结构如下Column (根容器全屏绿色背景 #E8F5E9) ├── Row (顶部导航栏) │ ├── Text (← 返回) ← 点击触发 router.back() │ ├── Blank() ← 弹性间距 │ ├── Column (标题区) │ │ ├── Text ( AI营养餐单规划) ← 主标题粗体深绿色 │ │ └── Text (NUTRITION · 营养标签) ← 副标题浅绿色 │ ├── Blank() ← 弹性间距 │ └── Text () ← 右侧图标 ├── Scroll (滚动内容区layoutWeight1) │ └── Column (内容容器) │ ├── Column (输入卡片白色圆角) │ │ ├── Text (目标) │ │ ├── TextInput (目标输入框) │ │ ├── Text (体重) │ │ ├── TextInput (体重输入框) │ │ ├── Text (饮食限制) │ │ └── TextInput (饮食限制输入框) │ ├── Button ( 分析营养) ← 主操作按钮深绿色 │ └── if (showResult resultData ! null) │ └── Column (结果卡片白色圆角) │ ├── Text ( 营养分析报告) │ ├── 多个 Row(营养成分行) │ ├── Text (Meal plan) ForEach 列表 │ ├── Text (Shopping list) ForEach 列表 │ └── 多个 Row(建议行)这种组件树结构具有以下特点扁平化层级最多 3 层嵌套避免深层嵌套导致的性能问题条件渲染结果区域通过if条件控制渲染时机避免不必要的组件创建弹性布局使用layoutWeight(1)让 Scroll 区域填充剩余空间2.6 异常处理策略在 ArkTS 中异常处理需要遵循以下策略类型安全由于 ArkTS 不支持any和unknown类型所有可能为空的字段必须使用联合类型如AI营养餐单规划Data | null显式声明空值防御在渲染结果数据前使用if (this.resultData ! null)进行空值检查数组安全在使用ForEach渲染数组前通过条件判断确保数组非空用户输入验证在 Service 层使用String()将输入安全转换为字符串类型三、原子化任务分解Atomize在确认了架构设计之后我们将整个开发任务拆解为以下原子化任务确保每个任务独立可交付、可测试任务 1创建数据模型Model 层预估工时0.5 小时任务细节定义AI营养餐单规划Data类包含所有输入输出字段。需要特别注意 ArkTS 的语法约束——所有字段必须在类声明内部声明不支持在构造函数中声明所有字段必须显式初始化不支持let v!: T语法。验收标准所有字段类型正确string 或 string[]构造函数正确初始化所有字段编译无错误任务 2实现服务层Service 层预估工时1 小时任务细节实现AI营养餐单规划Service类封装generateData方法。当前阶段使用 Mock 数据填充结果但方法签名需预留与真实 AI 模型对接的接口能力。验收标准方法接收Recordstring, Object类型输入返回AI营养餐单规划Data类型实例所有字段被正确填充编译无错误任务 3构建页面 UIView 层预估工时2 小时任务细节使用 ArkUI 声明式语法构建完整页面包括顶部导航栏返回按钮、标题、图标输入表单区域目标、体重、饮食限制输入框分析按钮结果展示区域营养成分、餐单列表、购物清单等验收标准所有 UI 元素正确渲染输入数据能够正确收集到inputData点击按钮后触发 Service 调用并展示结果当resultData为 null 时不展示结果区主题色一致UI 美观任务 4注册路由配置预估工时0.3 小时任务细节在项目路由配置文件中注册 AI营养餐单规划页面的路由路径确保通过router.pushUrl能够正确跳转。验收标准路由路径正确配置页面跳转正常任务 5集成到应用列表预估工时0.3 小时任务细节在resources/rawfile/apps/apps.json中注册 AI营养餐单规划的应用信息包括图标、标题、分类、颜色等配置使其出现在应用中心首页的网格列表中。首页的 Index.ets 通过读取该 JSON 配置文件动态渲染应用网格列表每个应用卡片展示图标、标题和副标题并支持分类筛选和搜索功能。验收标准应用正确显示在首页网格中点击后正确跳转到 AI营养餐单规划页面分类筛选正常搜索功能正常任务 6开发环境搭建与配置预估工时0.5 小时任务细节配置 HarmonyOS 开发环境确保项目能够正常编译和运行。包括确认 DevEco Studio 版本兼容性检查 oh-package.json5 依赖配置配置 module.json5 中必要的权限声明确认 API Level 兼容性验收标准项目编译无错误应用在模拟器/真机上正常运行页面跳转正常任务 7UI 效果验收与细节调整预估工时0.5 小时任务细节对页面 UI 进行视觉验收确保符合设计规范。包括验证主题色一致性#E8F5E9 背景、#2E7D32 按钮、#1B5E20 标题确认输入框的 placeholder 文本提示清晰验证结果展示区域的排版和间距检查不同屏幕尺寸下的适配效果验收标准UI 与设计稿一致所有交互元素响应正常无视觉瑕疵四、审批与确认Approve在进入编码执行阶段之前我们组织了架构评审会议对前面各阶段的输出进行了全面审核。4.1 评审流程概述在完成需求对齐和架构设计后我们组织了正式的架构评审会议。评审流程包括以下环节设计文档预审评审前 24 小时将 ALIGNMENT 文档、CONSENSUS 文档和 DESIGN 文档分发给所有评审人架构讲解由开发者介绍整体架构设计、数据流和关键决策点逐项评审按照评审清单逐项审核问题记录与跟踪记录评审中提出的问题和改进建议评审结论给出批准、有条件批准或拒绝的结论4.2 架构评审要点架构对齐检查✅ 三层架构Model-Service-View与项目现有 AI 应用架构完全一致复用已有的开发模式和最佳实践✅ 数据流采用单向绑定 State 驱动与 HarmonyOS ArkUI 的声明式编程范式一致✅ 路由注册方式与项目其他应用一致无需引入新的依赖或配置✅ 输入输出数据结构与产品需求规格完全匹配语法合规检查✅ 所有字段类型显式声明未使用any或unknown✅ 类字段在声明处初始化未在构造函数中声明✅ 未使用解构赋值、索引签名、as const等 ArkTS 不支持的语法✅ 箭头函数替代函数表达式✅ 所有 import 语句位于文件顶部顺序正确✅ 返回类型显式声明未依赖类型推断边界条件确认✅ 输入数据为空时Service 层返回默认值而非崩溃✅ 结果数据未生成时UI 不展示结果区域✅ 数组为空时ForEach 循环安全跳过✅ 空字符串在 UI 中正常显示4.3 验收标准清单编号验收项预期结果状态1Model 层编译无编译错误✅2Service 层编译无编译错误✅3Page 层编译无编译错误✅4页面 UI 渲染所有组件正确显示✅5输入收集用户输入正确写入 inputData✅6数据分析点击按钮触发 Service 调用✅7结果展示结果数据正确渲染到 UI✅8空状态保护resultData 为 null 时不展示✅9路由跳转从首页正确跳转到页面✅10返回导航点击返回按钮回到首页✅五、自动化执行Automate在编码执行阶段我们按照原子化任务的顺序逐一实现各模块。5.1 Model 层实现首先实现数据模型层。在 ArkTS 中定义数据模型需要特别注意语法约束// 文件AI营养餐单规划Model.etsexportclassAI营养餐单规划Data{// 所有字段在类声明中直接初始化不在构造函数中声明daily_calories:stringprotein:stringcarbs:stringfat:stringmacros:stringmeal_plan:string[][]meal:stringitems:string[][]food:stringamount:stringcalories:stringmeal_calories:stringshopping_list:string[][]category:stringweekly_variation:stringtips:stringconstructor(){// 构造函数中再次赋值确保所有字段被正确初始化this.daily_caloriesthis.proteinthis.carbsthis.fatthis.macrosthis.meal_plan[]this.mealthis.items[]this.foodthis.amountthis.caloriesthis.meal_caloriesthis.shopping_list[]this.categorythis.weekly_variationthis.tips}}关键实现细节在 ArkTS 中类字段的初始化有一个重要的最佳实践虽然字段声明时已经初始化但仍然建议在构造函数中显式赋值。这是因为 ArkTS 编译器在某些场景下会对字段的初始化顺序有严格要求双重初始化可以确保在任何情况下都不会出现访问未初始化字段的问题。5.2 Service 层实现Service 层是业务逻辑的核心封装了数据生成的全部逻辑// 文件AI营养餐单规划Service.etsimport{AI营养餐单规划Data}from./AI营养餐单规划ModelexportclassAI营养餐单规划Service{privatemodel:AI营养餐单规划Dataconstructor(){this.modelnewAI营养餐单规划Data()}generateData(input:Recordstring,Object):AI营养餐单规划Data{letresult:AI营养餐单规划DatanewAI营养餐单规划Data()// 从输入中提取目标值安全转换为字符串letgoalVal:stringString(input[goal]||)// 填充营养成分数据result.daily_calories生成结果goalVal result.macros生成结果goalVal// 填充餐单数据数组类型result.meal_plan[示例数据1,示例数据2,示例数据3]// 填充购物清单result.shopping_list[示例数据1,示例数据2,示例数据3]// 填充周变化建议result.weekly_variation生成结果goalVal// 填充饮食建议result.tips生成结果goalValreturnresult}}关于 Mock 数据的说明当前实现使用 Mock 数据来模拟 AI 大模型的输出。在实际生产环境中Service 层将调用远端的大模型 API通过精心设计的 Prompt 模板生成结构化的营养餐单数据。Mock 数据的设计