在老龄化日益加剧的今天，如何利用 AI 技术填补老年人健康管理的“数字鸿沟”？本文将简要介绍如何使用 Flutter 构建一个无后端、去中心化的智能健康管家 App。项目采用简单架构，通过直连火山引擎大模型与高德天气 API，结合本地 SQLite 数据库，实现了一个能够“感知环境、记忆身体状态”的 AI Agent 系统。

一、 项目背景与痛点分析

随着独居老人数量的增加，传统的健康管理 App 往往存在以下问题：

1. 操作复杂：层级深，字体小，老人看不懂。

2. 数据孤岛：记录了血压却不知道意味着什么，天气变冷了却没人提醒加衣。

老人健康助手App 旨在通过大模型（LLM）的推理能力，将环境数据（天气）、生理数据（血压/血糖）与专业知识动态聚合，为老人提供像私人医生一样的自然语言服务。

二、 系统架构：端侧 MCP + Serverless

为了保障数据隐私并降低部署成本，本项目放弃了传统的 Python 中间件后端，采用了 Client-Side MCP（端侧模型上下文协议） 架构。

2.1 架构设计图

• UI 交互层：Flutter 构建，Material 3 设计风格。

• 记忆层：SQLite 本地数据库，存储健康档案和对话历史。

• 能力层：

  • 感知环境：调用高德地图 API。

  • 推理大脑：调用火山引擎 API (DeepSeek/Doubao/kimi)。

三、 核心功能实现

3.1 动态上下文注入 (The Brain)

这是本项目的核心。传统的 AI 聊天是“无状态”的，而我们需要 AI 知道用户当前的处境。

实现逻辑：
在用户发送问题的瞬间，App 做了以下动作：

1. 从 SQLite 读取最新一条健康记录（血压、血糖、心率）。

2. 根据记录中的城市，请求高德 API 获取实时天气。

3. 动态拼接 System Prompt。

核心代码 (api_service.dart)：

static Future<Map<String, String>> chat({
  required String query,
  required String rolePrompt, // 传入角色：营养师/教练/医生
  required int sys, required int dia, required String loc, ...
}) async {
  
  // 1. 获取环境上下文 (API调用)
  String weatherInfo = await _getWeather(loc);

  // 2. 逻辑判断健康状态
  String healthStatus = (sys > 140 || dia > 90) ? "高血压风险" : "正常";

  // 3. 构建 MCP Prompt
  String systemPrompt = """
  $rolePrompt
  【当前环境】位置：$loc，天气：$weatherInfo
  【用户指标】血压：$sys/$dia mmHg ($healthStatus)
  【指令】请结合环境和身体指标回答用户问题。如天气恶劣或指标异常，请给予温和警示。
  """;

  // 4. 直连大模型
  final response = await http.post(
    Uri.parse(_arkUrl),
    body: jsonEncode({
      "model": "deepseek-v3-2-251201",
      "messages": [
        {"role": "system", "content": systemPrompt},
        {"role": "user", "content": query}
      ]
    }),
    // ... headers & timeout
  );
}

3.2 垂直领域的 AI Agent 分身

为了降低老人的认知负荷，我们将 AI 拆分为三个独立的功能入口，每个入口拥有独立的“记忆槽”：

• 🥗 饮食顾问 (Diet Agent)：

  • 人设：资深营养师。

  • 场景：结合血糖值和天气推荐食谱。例如下雨天推荐温热去湿的食物。

• 🏃 运动教练 (Sport Agent)：

  • 人设：康复专家。

  • 场景：结合心率和血压评估运动风险。

• 🤖 智能问诊 (General Agent)：

  • 人设：全科医生。

  • 特色：支持在 DeepSeek（深度思考）、Kimi（长文本）、豆包（极速）之间切换。

3.3 数据持久化与隐私

使用 sqflite 创建两张表：

1. records：存储生理指标，用于构建上下文。

2. chats：存储聊天记录，字段包含 category（分类），确保饮食和运动的聊天记录互不干扰。

// 数据库建表语句示例
d.execute('CREATE TABLE chats(id INTEGER PRIMARY KEY, category TEXT, role TEXT, content TEXT, time TEXT)');

四、 项目亮点与实现效果

4.1 效果展示

4.2 关键特性

1. 即时反馈机制：

   • 为了解决大模型生成慢（尤其是 DeepSeek R1 类模型）的问题，采用了异步上屏策略：用户发送后立即显示气泡，并显示“AI 正在思考...”的加载状态，超时时间设置为 60s。

2. 适老化设计：

   • 字体字号 ≥ 18sp。

   • 色彩语义明确：红色代表紧急/异常，绿色代表饮食/健康，橙色代表运动。

3. 去后端化（原本设计有后端但是响应太慢了就直接调用了API接口）：

   • App 可以在无服务器的情况下独立运行，只要手机有网即可，极大地降低了维护成本。

五、 项目复盘：不足与改进方向

虽然本项目完成了 最小可行性产品的核心功能，但在实际工程化落地中，仍存在以下显著的不足，这也是后续迭代的重点：

1. 安全性问题 (Security)

• 现状：API Key（火山引擎、高德）直接硬编码在 Flutter 前端代码中。

• 风险：一旦 App 被反编译，Key 极易泄露，导致额度被盗刷。

• 改进方案：虽然我们追求“无后端”，但在生产环境中，必须搭建一个极其轻量的 Token 转发服务 (Gateway)，或者利用云厂商的 API Gateway 进行鉴权转发，前端只存储短期 Token。

2. 数据同步问题 (Data Sync)

• 现状：所有数据存储在本地 SQLite。

• 风险：如果老人更换手机或误删 App，所有健康档案和聊天记录将永久丢失。

• 改进方案：引入云端备份功能（如 Firebase 或阿里云 OSS），支持账号登录后的数据云同步。

3. 硬件连接能力 (IoT)

• 现状：完全依赖老人手动录入血压、血糖。

• 痛点：老人视力不好或手指不灵活，手动录入容易出错且繁琐。

• 改进方案：集成 flutter_blue_plus 库，对接标准的蓝牙血压计和手环协议，实现数据自动采集。

4. 流式传输体验 (Streaming)

• 现状：采用 HTTP 短连接，等待 AI 生成全部文本后一次性返回。

• 痛点：对于长回答，用户等待时间较长（空白期）。

• 改进方案：利用 Server-Sent Events (SSE) 实现流式打字机效果，让用户能实时看到 AI 生成的一个个字，大幅提升交互体验。

六、 结语

该项目为学习过中的探索与尝试，用了一种轻量级、低成本的老年健康解决方案。通过将 AI 的推理能力下沉到端侧，并结合环境感知，我们让冰冷的数据变成了有温度的关怀。

希望这篇文章能给正在探索 Flutter + AI 应用开发的同学带来一些灵感！同时欢迎大家相互交流学习。感谢！

---