总体架构熟悉与预先构想：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 我的职责边界根据任务书分工我主要负责设计提示词工程调用大模型 API 生成健康分析与建议封装与大模型交互的服务解析返回内容生成结构化报告集成定时任务实现每日健康日报、周报/月报的自动生成与推送协助前后端对接确保 AI 生成内容能正确展示在前端界面探索图片识别功能如食物照片识别、可穿戴设备截图分析。这些任务贯穿了后端服务的业务逻辑层和定时调度层因此我需要深入理解 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月