外卖健康评分 App — HarmonyOS AI 应用开发技术博客

一、项目背景与需求分析

1.1 行业背景

随着外卖行业的迅猛发展，中国外卖市场规模已突破万亿元大关。然而，外卖食品的健康问题日益引起消费者的关注。高油、高盐、高糖的外卖食品成为了城市白领和年轻人群的健康隐患。根据《中国居民营养与慢性病状况报告》，我国居民在外就餐频率持续上升，但对外卖食品的营养成分和健康程度缺乏有效的评估工具。

在这样的背景下，开发一款能够基于外卖菜品信息进行健康评分和智能推荐的 AI 应用，具有重要的现实意义。用户只需输入菜品的名称、配料表和营养成分，即可获得一份专业的健康评估报告，包括综合健康评分、健康红灯警示以及替代方案建议。

1.2 需求分析

通过深入的用户调研和竞品分析，我们明确了以下核心需求：

功能需求：

• 用户输入菜品名称、配料表和营养信息
• 系统基于 AI 对菜品进行健康评分
• 识别并标记健康风险项（健康红灯）
• 提供更健康的替代方案建议
• 生成综合总结报告

非功能需求：

• 界面简洁直观，操作流程清晰
• 响应速度快，AI 生成结果在 3 秒内返回
• 支持 HarmonyOS 多设备适配
• 代码结构清晰，便于后续扩展和维护

1.3 目标用户画像

• 都市白领：工作繁忙，经常点外卖，关注健康饮食
• 健身爱好者：需要严格控制热量和营养摄入
• 健康管理人群：对饮食健康有系统性管理需求
• 家长群体：需要为孩子评估外卖食品的健康程度

二、技术架构设计

2.1 整体架构概述

本项目采用 HarmonyOS 原生开发技术栈，基于 ArkTS 语言和 ArkUI 框架，遵循 Model-Service-Page 三层架构设计模式。这种架构模式将数据模型、业务逻辑和界面展示清晰分离，提高了代码的可维护性和可扩展性。

2.2 架构分层详解

┌─────────────────────────────────────────────────────┐
│                    Page 层                           │
│    FoodScorePage (UI 组件 + 状态管理 + 交互逻辑)      │
│  ┌─────────────────────────────────────────────────┐ │
│  │  @State inputData    @State resultData          │ │
│  │  @State showResult   生命周期管理                │ │
│  └─────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────┤
│                   Service 层                         │
│    FoodScoreService (AI 推理 + 业务逻辑 + 数据处理)  │
│  ┌─────────────────────────────────────────────────┐ │
│  │  generateData(input) → FoodScoreData            │ │
│  │  Prompt 工程   AI API 调用  结果解析             │ │
│  └─────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────┤
│                   Model 层                           │
│    FoodScoreData (数据定义 + 类型约束 + 默认值)      │
│  ┌─────────────────────────────────────────────────┐ │
│  │  dish  ingredients  nutrition                   │ │
│  │  health_score  red_flags  alternatives          │ │
│  │  summary                                        │ │
│  └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

2.3 Model 层设计

Model 层是整个应用的数据基石。在 FoodScoreData 类中，我们定义了所有与外卖健康评分相关的数据字段：

export class FoodScoreData {
  dish: string = ''           // 菜品名称
  ingredients: string[] = []  // 食材列表
  nutrition: Record<string, string> = {}  // 营养信息（键值对，如 热量、蛋白质、脂肪等）
  health_score: number = 0    // 健康评分（0-100 分）
  red_flags: string[] = []    // 健康红灯列表（潜在健康风险）
  alternatives: string[] = [] // 健康替代方案列表
  summary: string = ''        // 综合总结
}

每个字段都设置了默认值，这是 ArkTS 的强制要求——所有类属性必须在声明时初始化或在构造函数中赋值。这种设计确保了数据在未填充时也有确定的状态，避免了空指针异常。

2.4 Service 层设计

Service 层是 AI 能力的核心。FoodScoreService 封装了与 AI 模型交互的所有逻辑：

export class FoodScoreService {
  private model: FoodScoreData

  constructor() {
    this.model = new FoodScoreData()
  }

  generateData(input: Record<string, Object>): FoodScoreData {
    let result: FoodScoreData = new FoodScoreData()
    // Mock data generation logic based on input
    return result
  }
}

generateData 方法接收一个 Record<string, Object> 类型的输入参数，这是从 Page 层传递过来的用户输入数据。在实际生产环境中，该方法会调用 HarmonyOS 的 AI 能力（如端侧大模型推理或云端 API），通过精心设计的 Prompt 模板生成健康评分结果。

2.5 Page 层设计

Page 层使用 ArkUI 的声明式 UI 语法构建，通过 @State 装饰器管理组件状态：

@Entry
@Component
struct FoodScorePage {
  @State inputData: Record<string, Object> = {}
  @State resultData: FoodScoreData | null = null
  @State showResult: boolean = false
  private service: FoodScoreService = new FoodScoreService()
}

@State 装饰器是 ArkUI 响应式编程的核心。当状态变量发生变化时，框架会自动重新渲染相关的 UI 组件。这种数据驱动视图的模式，与 React 的 useState 和 Vue 的 ref 有异曲同工之妙。

三、AI 提示词工程原理

3.1 提示词设计策略

外卖健康评分的核心在于 AI 对食品营养知识的理解。我们的 Prompt 设计遵循以下原则：

角色设定： 将 AI 定位为"专业营养师"，确保输出具有权威性和专业性。

结构化输出： 要求 AI 按照预定义的字段格式输出，便于解析和展示。

评分标准： 定义明确的评分维度，包括热量合理性、脂肪含量、钠含量、食材多样性、加工方式等。

3.2 提示词模板

以下是核心的 Prompt 模板设计思路：

你是一位专业营养师，请对以下外卖菜品进行健康评估。

菜品名称：{dish}
配料表：{ingredients}
营养信息：{nutrition}

请按照以下格式输出评估结果：
1. 健康评分（0-100分）：基于热量、脂肪、钠、糖、食材多样性等维度综合评分
2. 健康红灯：列出所有需要警惕的健康风险项
3. 替代方案：提供更健康的同类菜品建议
4. 总结：给出综合性的健康建议

3.3 AI 能力集成策略

在 HarmonyOS 生态中，集成 AI 能力有多种方案：

1. 端侧大模型推理： 利用 HarmonyOS 的端侧 AI 能力，在本地完成推理，保护用户隐私
2. 云端 API 调用： 通过 HTTP 请求调用云端大模型 API，获得更强大的 AI 能力
3. 混合方案： 简单任务在端侧执行，复杂任务调用云端 API

本项目采用松耦合设计，Service 层可以灵活切换不同的 AI 后端，只需修改 generateData 方法的实现即可。

四、核心功能实现详解

4.1 输入模块实现

输入模块是用户与 AI 交互的入口。我们设计了三个输入字段，分别对应菜品名称、配料表和营养信息：

Text('菜品名称')
  .fontSize(14)
  .fontWeight(FontWeight.Bold)
TextInput({ placeholder: '请输入菜品名称' })
  .fontSize(14)
  .height(44)
  .backgroundColor('#FFFFFF')
  .borderRadius(8)
  .onChange((val: string) => { this.inputData['dish'] = val })

每个 TextInput 组件都通过 onChange 回调将用户输入实时同步到 inputData 状态对象中。这种设计确保了用户随时点击"AI 生成"按钮时，所有输入数据都已就绪。

4.2 AI 生成按钮交互

"AI 生成"按钮是应用的核心交互点：

Button('AI 生成')
  .width('100%')
  .height(48)
  .backgroundColor('#3B82F6')
  .borderRadius(12)
  .fontColor('#FFFFFF')
  .fontSize(16)
  .fontWeight(FontWeight.Bold)
  .onClick(() => {
    this.resultData = this.service.generateData(this.inputData)
    this.showResult = true
  })

按钮点击后，会调用 Service 层的 generateData 方法，将结果存储到 resultData 中，并设置 showResult = true 触发结果区域的渲染。

4.3 结果展示模块

结果展示使用条件渲染，仅在 showResult 为 true 且数据不为 null 时显示：

if (this.showResult && this.resultData !== null) {
  Text('生成结果')
    .fontSize(18)
    .fontWeight(FontWeight.Bold)
  Text('健康评分')
    .fontSize(14)
    .fontColor($r('app.color.text_secondary'))
}

这种条件渲染模式避免了页面加载时展示空数据的问题，也符合用户预期——先输入，再看到结果。

4.4 数据流分析

完整的数据流如下：

用户输入 → inputData (@State) → 点击"AI 生成" 
  → service.generateData(inputData) → AI 推理 
    → 返回 FoodScoreData → resultData (@State) 
      → 条件渲染展示结果

这个单向数据流清晰明了，每个环节的职责分明，便于调试和维护。

五、用户体验优化

5.1 界面设计原则

清晰的信息层级： 页面从上到下依次为 Header → 输入区域 → 生成按钮 → 结果区域，符合用户的阅读习惯和操作流程。

统一的视觉风格： 使用柔和的蓝色主题 (#3B82F6) 作为主色调，配合浅灰色背景 (#F8FAFC) 和白色卡片，营造专业、清爽的视觉体验。

合理的间距和尺寸： 输入框高度 44px、圆角 8px、按钮高度 48px，这些尺寸都经过精心设计，兼顾了视觉美感和触摸操作的人体工程学。

5.2 交互反馈优化

虽然当前版本尚未加入加载动画，但架构上已经预留了扩展点。可以通过以下方式增强交互反馈：

• 点击生成按钮后显示加载指示器
• 生成过程中禁用按钮防止重复点击
• 生成完成后通过动画平滑展示结果

5.3 响应式适配

通过 Scroll 组件包裹内容区域，确保在屏幕尺寸较小的设备上也能完整显示所有内容。layoutWeight(1) 让 Scroll 区域自动填充剩余空间。

六、性能优化与最佳实践

6.1 ArkTS 性能优化要点

状态管理优化： 使用 @State 装饰器管理 UI 相关状态，避免不必要的状态声明。每个 @State 变量都会触发 UI 重新渲染，因此应仅将直接影响 UI 的变量标记为 @State。

条件渲染策略： 使用 if (this.showResult && this.resultData !== null) 条件判断，避免在数据未就绪时渲染复杂的 UI 结构。

组件复用： 对于列表类型的结果展示，可以使用 ForEach 循环渲染，避免重复的代码编写。

6.2 架构设计最佳实践

单一职责原则： Model 只负责数据定义，Service 只负责业务逻辑，Page 只负责 UI 展示。这种分离使得每个模块都可以独立测试和修改。

面向接口编程： Service 层的 generateData 方法接收 Record<string, Object> 类型的输入，返回 FoodScoreData 类型的输出，接口定义清晰，便于后续替换不同的 AI 实现。

防御性编程： 在构造函数中为所有字段赋予默认值，确保对象在创建后处于有效状态，避免了空指针异常。

6.3 HarmonyOS 平台特性利用

资源引用： 使用 $r('app.color.text_primary') 引用资源文件中的颜色值，方便主题切换和国际化。

路由管理： 使用 router.pushUrl 和 router.back 实现页面导航，与 HarmonyOS 的系统导航机制无缝集成。

七、总结与展望

7.1 项目总结

外卖健康评分 App 是 HarmonyOS AI 应用开发的一个典型范例。通过 Model-Service-Page 三层架构，我们构建了一个结构清晰、易于扩展的 AI 应用。项目展示了：

• ArkTS 语言在声明式 UI 开发中的优势
• 面向 AI 应用的分层架构设计模式
• 提示词工程在垂直领域 AI 应用中的实践
• HarmonyOS 生态下的应用开发最佳实践

7.2 未来展望

功能增强： 未来可以增加拍照识别菜品功能，通过 HarmonyOS 的 Camera Kit 能力直接从图片中提取菜品信息，无需手动输入。

个性化推荐： 结合用户历史评分数据和健康档案，提供个性化的饮食建议。

多端协同： 利用 HarmonyOS 的分布式能力，在手机、平板、智慧屏等多设备间同步健康数据。

社区功能： 增加用户评分分享和健康饮食社区，形成用户生态。

7.3 技术启示

通过本项目的开发，我们深刻认识到 AI 应用开发的核心不在于 AI 模型本身，而在于如何将 AI 能力与用户需求有机结合。一个好的架构设计能够让我们在 AI 技术快速迭代的背景下，始终保持应用的灵活性和可维护性。

Model-Service-Page 模式正是解决这一问题的有效方案——它将 AI 能力封装在 Service 层，上层应用无需关心 AI 的具体实现细节，只需关注数据模型和用户体验。这种关注点分离的设计哲学，值得在更多的 AI 应用开发中推广和应用。