总体架构熟悉与预先构想：AI健康助手的后端支撑与智能模块设计

实训项目：基于人工智能的健康日志与智能建议系统
角色定位：AI模块与全栈协助

一、写在前面

本次实训项目选题为“通用人工智能应用开发”，我们团队选择构建一款基于人工智能的健康日志与智能建议系统。作为团队中负责 AI 模块与全栈协助的成员，我最在项目之初决定宏观层面理解整个后端架构的设计思路，并围绕 AI 能力的接入与扩展做出清晰的预先构想。同时对前端内容也要有足够的了解和掌握。

本文将基于项目已经确定的技术栈和分层结构，梳理后端整体架构的特点，并结合任务书中对 AI 模块的定位，阐述我对大模型调用、提示词工程、自动化报告生成等关键环节的初步设计思考。希望能为后续开发打下扎实的认知基础。

二、项目技术栈与整体架构概览

2.1 核心技术选型

我们的后端采用经典的Spring Boot 3.2.0 + Spring Data JPA + MySQL组合，辅以Spring Security + JWT实现无状态认证，Spring Cache + Ehcache提升热点数据访问性能，SpringDoc OpenAPI自动生成 API 文档。这些技术选型保证了后端服务的稳定性、可扩展性和开发效率。

2.2 三层架构的现代化实践

从项目目录结构来看，后端严格遵循表现层（Controller）→ 业务逻辑层（Service）→ 数据访问层（Repository）的三层架构，同时通过DTO（数据传输对象）隔离内部实体与外部交互，通过全局异常处理器统一错误响应格式，整体设计非常清晰。下图宏观架构视角展示了项目的分层结构，并特别标注了 AI 模块在其中的位置与协作关系。

值得关注的是，项目在经典三层之上还做了以下增强：

• Config 层集中管理：JWT 工具、安全配置、Swagger 配置等均独立为配置类，便于维护和替换。
• Summary 服务的独立抽象：针对饮食、运动、睡眠等核心维度，除了基础的 CRUD 服务外，还单独设计了SummaryService层，专门负责数据的聚合统计与分析——这恰好为 AI 模块提供了高质量的结构化数据来源。
• Util 工具类的沉淀：PhotoConverter、ResponseBuilder等工具类封装了通用操作，减少了业务代码中的重复逻辑。

这种架构的好处是：业务逻辑内聚、横向扩展方便、对 AI 模块的接入非常友好。我可以专注于在 Service 层封装与大模型的交互，而无需关心数据如何存储、请求如何拦截。

三、AI 模块在整体架构中的定位

3.1 我的职责边界

根据任务书分工，我主要负责：

1. 设计提示词工程，调用大模型 API 生成健康分析与建议；
2. 封装与大模型交互的服务，解析返回内容，生成结构化报告；
3. 集成定时任务，实现每日健康日报、周报/月报的自动生成与推送；
4. 协助前后端对接，确保 AI 生成内容能正确展示在前端界面；
5. 探索图片识别功能（如食物照片识别、可穿戴设备截图分析）。

这些任务贯穿了后端服务的业务逻辑层和定时调度层，因此我需要深入理解 Service 层的设计模式，并合理规划 AI 相关服务的接口定义。

3.2 AI 模块与现有服务的协作关系

从项目架构中可以看到，AiHealthAnalysisController和AiHealthAnalysisService已经预留了位置。我的工作不是另起炉灶，而是填充这些接口的具体实现，并与已有的FoodRecordService、SleepRecordService、WorkoutService等基础服务进行协作。

协作流程图（预想）如下：

用户请求生成分析报告 ↓ AiHealthAnalysisController 接收请求 ↓ AiHealthAnalysisService.generateAnalysis(userId) ↓ 调用各 SummaryService 获取聚合数据（近7天饮食/运动/睡眠） ↓ 将结构化数据 + 提示词模板 → 发送给大模型 API ↓ 解析大模型返回的自然语言文本 ↓ 构建 HealthAnalysisRecord 实体并持久化 ↓ 返回分析报告给前端展示

更具体一点，可以画成这样的图片：

这种设计将数据聚合逻辑与AI 生成逻辑解耦，即使未来更换大模型提供商或调整提示词策略，也只需要修改AiHealthAnalysisServiceImpl内部的实现，对外部服务无影响。

四、AI 模块的预先构想

4.1 提示词工程的设计思路

大模型的输出质量高度依赖提示词的设计。结合任务书中提到的分析目标（营养均衡评估、运动消耗计算、睡眠质量关联分析），我计划采用结构化提示词模板，通过这种方式，大模型能够接收到充分且结构化的上下文，生成的报告既具有数据支撑，又能以自然语言呈现，符合用户阅读习惯。

4.2 大模型 API 的封装策略

考虑到不同大模型提供商的 API 规范存在差异，我计划设计一个统一的 AIService 接口，内部封装具体的 HTTP 调用逻辑。初期可以先对接一个主流模型（如 OpenAI GPT 系列或国内智谱 GLM 系列），后期可根据效果灵活切换。

在 Service 实现中，通过特定函数发送 HTTP 请求，并处理好超时、重试、异常降级等边缘情况。由于大模型调用可能耗时较长，对于非实时要求的场景（如周报生成），可以通过异步任务或消息队列来提升用户体验。

4.3 定时报告生成的实现方案

任务书要求每日推送健康日报，每周/每月自动生成结构化报告。这部分可以借助 Spring 的@Scheduled注解实现定时任务。

初步计划：

• 每日凌晨：扫描所有活跃用户，聚合昨日数据，调用 AI 生成简短日报，并存储到 表中（标记类型为DAILY）。
• 每周一凌晨：聚合过去7天数据，生成周报（类型WEEKLY）。
• 每月1日凌晨：生成月报（类型MONTHLY）。

报告内容既可以直接以 HTML 富文本形式存储，也可以生成 PDF 文件并保存路径。前端从HealthAnalysisRecord表中查询后展示即可。

4.4 图片识别功能的可行性探索

任务书中提到了两个亮点功能：食物拍照识别和运动/睡眠截图分析。这两个功能都依赖于大模型的多模态能力（视觉理解）。

技术实现上，可以：

• 前端将图片转为 Base64 编码传递给后端；
• 后端调用支持视觉输入的大模型 API（如 GPT-4V、GLM-4V），将图片与特定提示词一同发送；
• 解析返回的 JSON 结构，提取关键信息（如食物名称、热量、运动类型、睡眠时长等），并自动填充到记录表单中。

这一功能的挑战在于识别准确率的保证和API 调用成本的控制。前期可以作为一个可选增强项，待核心流程稳定后再深入优化。

五、对全栈协助角色的思考

除了 AI 模块，我还承担全栈协助的职责。这意味着我需要：

• 熟悉前端 Vue 与 ECharts 的数据交互方式，确保 AI 生成的报告能够在前端正确渲染；
• 协助后端同事设计合理的 API 返回格式，比如分析报告是返回纯文本还是 Markdown 格式；
• 参与数据库表结构的设计评审，特别是HealthAnalysisRecord表需要预留足够的字段来存储分析类型、生成时间、报告内容等。

通过对整体架构的熟悉，我已经能够快速定位到需要协作的关键点，避免在后期联调时出现大的返工。

六、总结与展望

通过本次对项目总体架构的梳理和对 AI 模块的预先构想，我对整个系统的技术脉络有了更清晰的认识：

• 后端分层架构为 AI 接入提供了稳定的数据基础，我可以专注于业务逻辑与模型交互；
• 提示词工程是大模型应用的核心，需要结合健康领域知识反复打磨；
• 定时任务与异步处理是保证用户体验的关键设计；
• 多模态能力是项目的加分项，值得在后期投入精力探索。

接下来的实训过程中，我将按照既定分工，逐步完成 AI 模块的接口封装、提示词优化、报告生成逻辑实现，并与前后端同学紧密配合，确保项目按期高质量交付。

“通用人工智能应用开发”的本质不是从零训练模型，而是将成熟的大模型能力与垂直领域的需求深度结合。健康管理正是这样一个充满想象空间的赛道，期待我们的作品能为用户的健康生活带来一点微小的改变。

—— 写于项目启动阶段，2026年4月