这段时间一直在整理一套个人健康管理系统的完整项目正好拿这个典型例子来聊聊。整套东西核心就三个字SpringBoot、GPT、源码。后端用SpringBoot搭服务健康数据做持久化管理再对接GPT大模型接口做智能问答和健康建议生成配套文档、PPT、源码全齐。这个组合拿来当毕业设计、课程设计或者自己练手学SpringBoot和大模型接入都非常合适。市面上类似的健康管理系统模板很多但大多停留在“增删改查”层面用户注册登录、维护几条健康记录、画个统计图表就完事了。这套系统的差异化在于接入了GPT让系统从“数据记录工具”变成了“能对话、能出建议”的健康助手。对于正在做项目设计或者想学技术整合的同学来说这个切入点既有亮点又不会难到做不出来。1. 项目整体设计与思路拆解1.1 为什么选SpringBootGPT这个组合先说选型逻辑。SpringBoot在Java后端领域基本是事实标准理由不需要我多讲起步依赖帮你把大量配置自动化内嵌Tomcat让你不用单独部署容器再加上Spring生态天然支持MyBatis、Redis、安全框架这些常用组件一个中小型管理系统两三下就能把骨架搭起来。个人健康管理系统属于典型的中小型Web应用用SpringBoot来做开发效率和维护成本都最优。GPT这边我更愿意把它看作一个“能力外挂”。健康管理系统的核心难点其实不在数据存储而在“如何把用户的健康数据转换成有价值的建议”。传统做法是自己写规则引擎比如“BMI大于24就提示超重”这种规则写起来简单但非常死板。用户问一句“我最近总失眠跟我的血压偏高有关系吗”规则引擎根本回答不了。接入GPT之后系统可以把用户的健康指标、生活习惯作为上下文拼接给大模型让它生成相对个性化、可读性强的分析建议体验完全不一样。这个组合的本质是SpringBoot负责“确定性”的部分用户体系、数据存取、业务流程GPT负责“开放性”的部分自然语言理解与生成。两者各司其职边界清晰也是目前AI应用落地比较实用的架构方式。1.2 系统定位与功能边界做项目之前先划清楚边界不然容易越做越散。这套系统的定位是“个人健康管理助手”核心目标用户是普通个体而不是医院或专业机构。所以功能设计围绕“记录-评估-建议”三条线展开。记录端包括基础健康档案年龄、身高、体重、慢性病史、过敏史等以及日常健康数据记录饮食、运动、睡眠、血压、血糖、体重变化。评估端基于身高体重算BMI基于基础代谢率公式算每日热量消耗结合部分指标做一个简单的健康评分。建议端就是把上述数据喂给GPT让用户以自然语言提问或者一键生成个性化的饮食、运动建议。我特别建议把“体检报告解读”也做成一个模块。用户上传体检报告里的关键指标比如血脂、血糖、尿酸系统解析后结合GPT生成通俗解读。这个功能听起来高大上实现起来也不复杂本质就是把医学参考范围给到大模型再让它针对异常项做解释演示效果非常好。1.3 技术选型与架构设计直接上这套项目用到的技术清单和选型理由层次技术选型用途说明后端框架SpringBoot 2.7.x成熟稳定资料多3.x虽然新但部分组件兼容性需要处理ORMMyBatis-Plus单表CRUD写起来极其省事内置分页插件适合快速开发数据库MySQL 5.7 / 8.0免费稳定个人项目首选缓存可选Redis存用户会话、热点健康数据有没有都不影响主流程HTTP客户端Hutool的HttpUtil或OkHttp封装调用GPT接口比手写HttpClient代码干净得多JSON处理JacksonSpringBoot内置解析大模型返回内容前端Bootstrap Thymeleaf 或 Vue简单项目直接用模板渲染想增加亮点就前后端分离大模型接口GPT系列API或兼容接口智能问答、健康建议生成架构上采用经典的三层架构Controller层接收请求Service层处理业务逻辑Mapper层与数据库交互。GPT调用单独封装在一个service类里方便统一管理API Key、超时时间、上下文拼装逻辑。前后端交互统一返回JSON前端用Ajax异步请求特别是GPT对话时要采用流式或异步方式避免页面长时间等待。这套架构一眼看过去没有花哨的微服务、分布式但对一个单体管理系统来说足够清晰也方便后面扩展。做毕设答辩的时候面试官或老师问起来你能把每个选型的理由讲明白比堆砌一堆用不上的技术要加分得多。2. 核心细节解析与实操要点2.1 数据模型设计健康管理到底要管哪些数据数据表设计是这类系统出彩的关键。很多新手上来就建一张user表一张health_record表字段堆得又宽又乱后面写着写着就崩了。我这边把表拆得稍微细一点职责分明。用户表sys_user存账号密码、昵称、角色管理员/普通用户。健康档案表health_profile跟用户是一对一关系存性别、出生日期、身高、体重、职业、既往病史、过敏史、家族病史、吸烟饮酒情况。这里注意把身高体重放在档案表而不是用户表因为这类生理指标是随时间变化的用户表里只放固定的身份信息。日常记录表再按数据形态拆开饮食记录表diet_record存每餐类型、食物名称、热量估算、摄入时间运动记录表exercise_record存运动类型、时长、消耗热量体征记录表body_metric_record存体重、血压、心率、血糖、睡眠时长这些数值型指标。为什么要拆因为不同指标的数据结构不同查询频率也不同。体征数据要做趋势图饮食和运动要做汇总统计混在一张表里SQL会越写越痛苦。体检记录独立建表medical_report_record字段包括体检日期、机构名称、指标名称、指标数值、参考范围、异常标记。设计成“指标明细行”而不是“一次体检一行”是为了方便对某个指标做历史趋势对比这个设计在答辩时非常加分。GPT调用日志表gpt_chat_log很容易被忽略但我建议一定要建。记录用户的提问、系统返回内容、token消耗、耗时、是否成功这个表既能做问题排查又能展示你考虑到了成本控制与审计属于细节上的亮点。2.2 GPT能力集成从API调用到提示词工程GPT接入在代码层面不复杂真正的门道在提示词设计和上下文管理。先说API调用。使用GPT的Chat Completions接口通过配置API Key、模型名称、消息列表发送请求返回内容在choices消息里。SpringBoot项目中用Hutool的HttpUtil.postJson即可不需要额外引入SDK这样能少踩很多坑。需要注意在GPT系列大模型接口体系中不同模型版本的上下文管理、计费方式和能力边界都有差异。接入前要仔细看官方文档确认自己用的是哪个版本、哪些参数生效尤其是max_tokens和temperature这两个参数的行为在不同版本中可能不一样。我建议固定使用一个较稳定的版本不要把版本参数做成动态可配否则上线后模型行为漂移会让你排查到崩溃。提示词设计是这套系统的灵魂。我举个实际的例子健康建议生成的系统提示词大概这样设计你是一位专业的健康管理助手。请根据用户提供的健康数据身高、体重、年龄、性别、血压、血糖、运动习惯、饮食情况等给出具体、可操作的健康建议。 要求 1. 语言通俗易懂避免过多专业术语。 2. 分点列出建议包含饮食、运动、作息三个方面。 3. 对于异常指标说明可能的健康风险和就医建议。 4. 不要给出明确的医疗诊断涉及疾病判断时建议用户咨询专业医生。这段话的核心作用是“限定输出格式划定安全边界”。个人健康管理涉及医疗敏感信息必须让模型明确知道哪些能说、哪些不能说避免给出误导性的医疗建议。安全边界这块我建议在系统提示词里明确加上“仅供参考不构成医疗诊断”这类话术这是一种负责任的设计也能在答辩时成为加分项——体现了你考虑问题不只有技术还有责任意识。上下文管理方面原则是“只传必要的数据”。不要一股脑把用户所有历史记录全部塞给模型那样既费token又容易让模型被无关信息干扰。我采用的做法是先从数据库取出用户的最近一段时间的健康指标摘要格式化成一行文本再拼接用户的提问一起发给模型。这样既保证了个性化又控制了成本。2.3 SpringBoot核心配置与模块划分SpringBoot项目结构上我习惯按业务模块分包而不是按技术层次分包。代码结构大致如下com.health.system ├── controller // Web层接口 │ ├── AuthController │ ├── HealthProfileController │ ├── RecordController │ └── AiAssistantController ├── service // 业务逻辑 │ ├── UserService │ ├── HealthProfileService │ ├── RecordService │ └── GptService ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体类 ├── dto // 前端交互对象 ├── config // 配置类跨域、拦截器、GPT参数 ├── common // 通用返回结果、异常处理、常量 └── utils // 工具类个人健康管理系统虽然不复杂但我依然强烈建议做好统一返回结构和全局异常处理。统一返回结构用Result 封装包含code、message、data三个字段前端统一判断code是否为200。全局异常处理配合RestControllerAdvice把参数校验异常、业务异常、GPT调用异常统一拦截返回友好提示。这一套做完代码整洁度直接上一个档次后面联调的时候能省大量时间。再说几个配置文件里的坑。数据库连接建议用druid连接池配置好初始连接数和最大连接数MyBatis-Plus的map-underscore-to-camel-case设为true自动把数据库下划线字段映射为驼峰属性GPT调用的相关配置放在application.yml里包括api key、模型名称、超时时间、最大token数通过ConfigurationProperties绑定到配置类不要硬编码在代码里。3. 实操过程与核心环节实现3.1 环境准备与项目初始化先说环境版本。JDK建议用1.8或11SpringBoot 2.7.x在这两个版本下都非常稳。如果你本机装的是JDK 17以上建议优先考虑SpringBoot 2.7系列的高版本或者直接上SpringBoot 3.x否则启动时可能出现依赖注入异常。这个一定要提前确认不然项目初始化阶段就被卡住会非常扫兴。数据库用MySQL即可。安装完成后创建数据库health_manage执行项目自带的SQL脚本。有同学喜欢用Navicat手动建表我不建议项目如果自带SQL脚本直接source执行确保表结构跟代码里的实体完全对得上。建好以后在application.yml里改数据库账号密码。建议建一个独立的数据库账号不要直接用root这是一个好习惯。IDEA导入项目后等待Maven下载依赖。如果下载慢把Maven镜像换成国内的阿里云镜像。第一次启动前检查一下三个地方JDK版本是否匹配、application.yml里的数据库配置是否改好、Maven是否已经成功reimport。这三个地方没问题启动基本是一次性成功。3.2 健康评估模块的实现逻辑健康评估不能只靠GPT本地规则先算出一部分硬指标这样即使大模型接口暂时不可用系统核心功能也能跑。硬指标包括BMI、基础代谢率、每日推荐热量摄入。再结合体征记录生成健康评分。BMI计算很简单体重除以身高米的平方。基础代谢率我用的公式是Mifflin-St Jeor男性10×体重(kg)6.25×身高(cm)-5×年龄5女性10×体重(kg)6.25×身高(cm)-5×年龄-161。这个公式在营养学上比较常用比Harris-Benedict更推荐答案中如果说你用了这个公式会显得专业。健康评分我这里设计了一个简单的模型将BMI、血压、血糖、运动频率、睡眠时长五个维度按权重打分各占20分合成百分制。这一步在代码里用规则实现每组数值区间对应一个分值。比如睡眠时长7-8小时得20分6-7小时得15分少于5小时得5分。这种模型虽然不是医学级的但作为演示和概念验证绰绰有余。之后把评分和用户健康数据打包作为GPT建议的输入。也就是说GPT不是完全自由发挥而是基于本地生成的结构化评估结果去做扩展和润色这样回答质量稳定得多也不太容易跑偏。3.3 GPT对话接口的接入GPT对话接口是这套系统里演示效果最炸裂的部分。前端页面设计成一个聊天窗口用户输入问题点击发送异步请求后端接口后端调用GPT接口拿到回答后返回前端展示在对话列表里。核心代码逻辑大致如下public String chatWithGpt(String userMessage, String healthContext) { String systemPrompt buildSystemPrompt(healthContext); ListMessage messages new ArrayList(); messages.add(new Message(system, systemPrompt)); messages.add(new Message(user, userMessage)); GptRequest request new GptRequest(); request.setModel(gptProperties.getModel()); request.setMessages(messages); request.setTemperature(0.7); request.setMaxTokens(800); String responseBody HttpUtil.postJson(gptProperties.getApiUrl(), JSONUtil.toJsonStr(request), createHeaders(gptProperties.getApiKey())); return parseResponse(responseBody); }这里要重点处理几个细节。超时时间建议设置30秒以上GPT接口的响应速度不稳定尤其当输入输出都比较长的时候默认的10秒超时容易误判为失败。调用前检查API Key对应的账户余额和额度是否充足避免在演示现场出现“因为余额不足导致返回鉴权错误”的尴尬。token消耗要做统计一次完整问答消耗多少token成本多少展示在后台日志里这东西做好了很体现工程意识。为了优化用户体验我建议把同步调用改成异步任务或流式返回。最简单的方案是使用Spring的WebAsyncTask或Ajax轮询前端发起请求后后端异步调用GPT完成后把结果存入数据库同时通过WebSocket推送或让前端轮询获取。如果时间紧同步调用加loading动画也能接受但体验会差一截。3.4 前端页面与演示联调前端技术栈我建议BootstrapThymeleaf原因就是快。登录注册页、首页仪表盘、健康档案页、记录管理页、AI助手聊天页、体检报告页这几个页面做下来如果你的页面功底一般用Bootstrap现成组件拼装一周内也能做完。首页仪表盘是门面担当。展示用户基本信息、最近一次BMI、今日摄入热量与消耗热量、近7天体重趋势图、健康评分。图表直接用ECharts引入CDN就行。AI助手页面采用左右分栏布局左边是用户健康数据摘要卡片右边是聊天窗口用户提问时系统自动携带健康摘要作为上下文。这个设计一定要保留因为它直观展示了“GPT不是瞎聊而是真的结合了用户数据”答辩时的演示效果极佳。联调阶段常见的问题是跨域。如果前端页面和后端接口不在同一个端口需要配置CorsFilter。Swagger或接口文档也要生成一份配合项目自带的PPT和文档演示时一边开着接口文档一边展示专业感马上出来。4. 常见问题与排查技巧实录4.1 GPT接口调用问题这是整套系统里最容易出问题的环节。我把碰到的典型问题整理成一张速查表对照排查能节省大量时间。现象可能原因解决方法返回401鉴权失败API Key错误、Key失效或格式不对检查application.yml中Key是否完整不要有空格返回429限流请求频率超过限制或账户额度不足加请求间隔检查账户使用情况降低并发请求超时默认超时时间太短或网络波动设置HTTP客户端连接和读取超时至少30秒返回结果乱码编码不一致统一使用UTF-8调用端设置Content-Type为application/json;charsetUTF-8模型参数不生效模型版本与参数不匹配查阅所用模型版本的最新文档确认参数名称和取值范围还要注意一点GPT返回的内容里可能包含一些不需要的字符比如换行符、JSON转义符解析时要做好清洗。建议把返回结果先解析成JSON对象再取choices[0].message.content字段不要直接用字符串截取的方式。4.2 SpringBoot启动与依赖问题SpringBoot版本和JDK之间的兼容问题是新手重灾区。如果你启动时看到类似“Invalid value type for attribute factoryBeanObjectType”或者“java.lang.NoClassDefFoundError”大概率是版本不匹配。我的建议是JDK 8用SpringBoot 2.3到2.7JDK 11用2.7也稳妥JDK 17直接用SpringBoot 3.x。不要盲目追新稳定压倒一切。Maven依赖冲突也常见尤其是hutool和spring-boot自带的HttpClient相关依赖冲突。解决方法是使用mvn dependency:tree查看依赖树找到冲突项后在pom.xml中排除。再有就是MyBatis-Plus版本要和SpringBoot版本匹配最新的MyBatis-Plus 3.5.x对SpringBoot 2.x支持完全没问题但如果你用了SpringBoot 3.x就要选对应的新版本。4.3 数据库与中文乱码问题数据库连接串中一定要加上characterEncodingutf8和useSSLfalse两个参数。前者解决中文写入变问号的问题后者避免MySQL 8.0以上版本对SSL的警告。表结构创建时字符集选择utf8mb4而不是utf8因为utf8mb4才完整支持中文和特殊符号。还有一个隐蔽的问题MySQL时区。如果插入数据的时间和你本地时间差8小时检查连接串是否配置了serverTimezoneAsia/Shanghai。这个问题在部署到云服务器时尤其常见本机不暴露是因为IDE的数据库连接默认配置了时区而项目里的独立连接串没有。4.4 演示前的最后检查清单如果是拿这套系统做答辩或演示我强烈建议你按这个清单提前演练一遍确认GPT API Key有效且账户余额足够支撑演示建议准备双Key备用。数据库里预置一份完整的演示数据包括最近30天的体征记录、饮食记录、运动记录让图表和统计看起来充实。提前测试AI对话功能准备3-5个典型的演示问题比如“根据我的数据给出饮食建议”、“我的血压偏高需要注意什么”、“帮我生成一份一周运动计划”。网络环境要稳定如果演示地点网络不好建议准备一个本地规则的兜底回答或者直接开手机热点。确保源码、文档、PPT都放在一个目录下命名清晰方便评审查看。5. 项目扩展思路与个人心得5.1 从课程设计到可用产品的差距这套系统如果只是做完交差那确实不难。但如果你想把它变成一个真正能用的产品差距主要体现在三个地方。第一数据安全与隐私合规。健康数据属于高度敏感的个人信息真实产品需要做数据加密存储、访问审计、用户授权管理甚至需要符合相关隐私法规的要求。第二大模型输出的可靠性。GPT虽然能生成流畅的建议但可能产生幻觉真实场景下需要增加人工审核、知识库检索增强、医学规则库兜底等多层校验。第三可扩展性。目前是单体应用如果用户量上来GPT调用需要做成独立服务并进行限流、熔断、缓存语义等治理。对于课程设计或毕业设计来说能在答辩中提到这三个扩展方向绝对是一个进阶亮点因为它说明你不仅有“写代码”的能力还有“思考产品落地方案”的意识。5.2 我踩过的坑和总结的经验最后分享几个我实际整理这套项目时最深的感触。第一GPT接入部分一定要拆得独立。把GPT相关的代码单独放在一个模块里不要让业务代码到处直接调用HTTP请求。我一开始图省事直接在Service里写了GPT调用逻辑结果后面改超时时间、加token统计、换成流式输出时改得焦头烂额。拆出来之后一切变得清晰可控。第二健康数据的关联关系从第一天就要设计好。我在第一版设计里没有把“健康档案”和“体征记录”分清楚导致体重数据既出现在档案表又出现在记录表产生了两份不一致的数据。后来痛定思痛才按“档案是一个时间快照记录是一条持续追加的时间序列”这个原则重新设计。这个理解也是答辩时的一个核心概念要讲透。第三连接大模型的成本控制一定要提前想。我的第一版测试由于忘记设置max_tokens上限有一次长对话直接消耗了远低于预期的其他接口额度注这里应理解为“超出了预期额度”。后来我做了三件事限制单次最大token数、记录每次调用的token消耗、在管理后台加了一个“今日AI调用次数与成本”的展示卡片。把这个功能展示出来老师或者面试官会觉得你考虑问题很全面。这套基于SpringBootGPT的个人健康管理系统从头到尾做下来基本上把Java Web开发的核心技能和大模型应用开发的常见套路都覆盖到了。如果你正在做类似的选题希望这篇文章能帮你少走一些弯路。项目源码、配套文档和PPT都是现成的拿到手之后先别急着跑按照文章里说的思路把数据模型看一遍再去追代码的实现细节比你直接启动项目一头雾水地乱点要有收获得多。做这种东西慢就是快。
SpringBoot整合GPT构建个人健康管理系统：从架构设计到源码实现
这段时间一直在整理一套个人健康管理系统的完整项目正好拿这个典型例子来聊聊。整套东西核心就三个字SpringBoot、GPT、源码。后端用SpringBoot搭服务健康数据做持久化管理再对接GPT大模型接口做智能问答和健康建议生成配套文档、PPT、源码全齐。这个组合拿来当毕业设计、课程设计或者自己练手学SpringBoot和大模型接入都非常合适。市面上类似的健康管理系统模板很多但大多停留在“增删改查”层面用户注册登录、维护几条健康记录、画个统计图表就完事了。这套系统的差异化在于接入了GPT让系统从“数据记录工具”变成了“能对话、能出建议”的健康助手。对于正在做项目设计或者想学技术整合的同学来说这个切入点既有亮点又不会难到做不出来。1. 项目整体设计与思路拆解1.1 为什么选SpringBootGPT这个组合先说选型逻辑。SpringBoot在Java后端领域基本是事实标准理由不需要我多讲起步依赖帮你把大量配置自动化内嵌Tomcat让你不用单独部署容器再加上Spring生态天然支持MyBatis、Redis、安全框架这些常用组件一个中小型管理系统两三下就能把骨架搭起来。个人健康管理系统属于典型的中小型Web应用用SpringBoot来做开发效率和维护成本都最优。GPT这边我更愿意把它看作一个“能力外挂”。健康管理系统的核心难点其实不在数据存储而在“如何把用户的健康数据转换成有价值的建议”。传统做法是自己写规则引擎比如“BMI大于24就提示超重”这种规则写起来简单但非常死板。用户问一句“我最近总失眠跟我的血压偏高有关系吗”规则引擎根本回答不了。接入GPT之后系统可以把用户的健康指标、生活习惯作为上下文拼接给大模型让它生成相对个性化、可读性强的分析建议体验完全不一样。这个组合的本质是SpringBoot负责“确定性”的部分用户体系、数据存取、业务流程GPT负责“开放性”的部分自然语言理解与生成。两者各司其职边界清晰也是目前AI应用落地比较实用的架构方式。1.2 系统定位与功能边界做项目之前先划清楚边界不然容易越做越散。这套系统的定位是“个人健康管理助手”核心目标用户是普通个体而不是医院或专业机构。所以功能设计围绕“记录-评估-建议”三条线展开。记录端包括基础健康档案年龄、身高、体重、慢性病史、过敏史等以及日常健康数据记录饮食、运动、睡眠、血压、血糖、体重变化。评估端基于身高体重算BMI基于基础代谢率公式算每日热量消耗结合部分指标做一个简单的健康评分。建议端就是把上述数据喂给GPT让用户以自然语言提问或者一键生成个性化的饮食、运动建议。我特别建议把“体检报告解读”也做成一个模块。用户上传体检报告里的关键指标比如血脂、血糖、尿酸系统解析后结合GPT生成通俗解读。这个功能听起来高大上实现起来也不复杂本质就是把医学参考范围给到大模型再让它针对异常项做解释演示效果非常好。1.3 技术选型与架构设计直接上这套项目用到的技术清单和选型理由层次技术选型用途说明后端框架SpringBoot 2.7.x成熟稳定资料多3.x虽然新但部分组件兼容性需要处理ORMMyBatis-Plus单表CRUD写起来极其省事内置分页插件适合快速开发数据库MySQL 5.7 / 8.0免费稳定个人项目首选缓存可选Redis存用户会话、热点健康数据有没有都不影响主流程HTTP客户端Hutool的HttpUtil或OkHttp封装调用GPT接口比手写HttpClient代码干净得多JSON处理JacksonSpringBoot内置解析大模型返回内容前端Bootstrap Thymeleaf 或 Vue简单项目直接用模板渲染想增加亮点就前后端分离大模型接口GPT系列API或兼容接口智能问答、健康建议生成架构上采用经典的三层架构Controller层接收请求Service层处理业务逻辑Mapper层与数据库交互。GPT调用单独封装在一个service类里方便统一管理API Key、超时时间、上下文拼装逻辑。前后端交互统一返回JSON前端用Ajax异步请求特别是GPT对话时要采用流式或异步方式避免页面长时间等待。这套架构一眼看过去没有花哨的微服务、分布式但对一个单体管理系统来说足够清晰也方便后面扩展。做毕设答辩的时候面试官或老师问起来你能把每个选型的理由讲明白比堆砌一堆用不上的技术要加分得多。2. 核心细节解析与实操要点2.1 数据模型设计健康管理到底要管哪些数据数据表设计是这类系统出彩的关键。很多新手上来就建一张user表一张health_record表字段堆得又宽又乱后面写着写着就崩了。我这边把表拆得稍微细一点职责分明。用户表sys_user存账号密码、昵称、角色管理员/普通用户。健康档案表health_profile跟用户是一对一关系存性别、出生日期、身高、体重、职业、既往病史、过敏史、家族病史、吸烟饮酒情况。这里注意把身高体重放在档案表而不是用户表因为这类生理指标是随时间变化的用户表里只放固定的身份信息。日常记录表再按数据形态拆开饮食记录表diet_record存每餐类型、食物名称、热量估算、摄入时间运动记录表exercise_record存运动类型、时长、消耗热量体征记录表body_metric_record存体重、血压、心率、血糖、睡眠时长这些数值型指标。为什么要拆因为不同指标的数据结构不同查询频率也不同。体征数据要做趋势图饮食和运动要做汇总统计混在一张表里SQL会越写越痛苦。体检记录独立建表medical_report_record字段包括体检日期、机构名称、指标名称、指标数值、参考范围、异常标记。设计成“指标明细行”而不是“一次体检一行”是为了方便对某个指标做历史趋势对比这个设计在答辩时非常加分。GPT调用日志表gpt_chat_log很容易被忽略但我建议一定要建。记录用户的提问、系统返回内容、token消耗、耗时、是否成功这个表既能做问题排查又能展示你考虑到了成本控制与审计属于细节上的亮点。2.2 GPT能力集成从API调用到提示词工程GPT接入在代码层面不复杂真正的门道在提示词设计和上下文管理。先说API调用。使用GPT的Chat Completions接口通过配置API Key、模型名称、消息列表发送请求返回内容在choices消息里。SpringBoot项目中用Hutool的HttpUtil.postJson即可不需要额外引入SDK这样能少踩很多坑。需要注意在GPT系列大模型接口体系中不同模型版本的上下文管理、计费方式和能力边界都有差异。接入前要仔细看官方文档确认自己用的是哪个版本、哪些参数生效尤其是max_tokens和temperature这两个参数的行为在不同版本中可能不一样。我建议固定使用一个较稳定的版本不要把版本参数做成动态可配否则上线后模型行为漂移会让你排查到崩溃。提示词设计是这套系统的灵魂。我举个实际的例子健康建议生成的系统提示词大概这样设计你是一位专业的健康管理助手。请根据用户提供的健康数据身高、体重、年龄、性别、血压、血糖、运动习惯、饮食情况等给出具体、可操作的健康建议。 要求 1. 语言通俗易懂避免过多专业术语。 2. 分点列出建议包含饮食、运动、作息三个方面。 3. 对于异常指标说明可能的健康风险和就医建议。 4. 不要给出明确的医疗诊断涉及疾病判断时建议用户咨询专业医生。这段话的核心作用是“限定输出格式划定安全边界”。个人健康管理涉及医疗敏感信息必须让模型明确知道哪些能说、哪些不能说避免给出误导性的医疗建议。安全边界这块我建议在系统提示词里明确加上“仅供参考不构成医疗诊断”这类话术这是一种负责任的设计也能在答辩时成为加分项——体现了你考虑问题不只有技术还有责任意识。上下文管理方面原则是“只传必要的数据”。不要一股脑把用户所有历史记录全部塞给模型那样既费token又容易让模型被无关信息干扰。我采用的做法是先从数据库取出用户的最近一段时间的健康指标摘要格式化成一行文本再拼接用户的提问一起发给模型。这样既保证了个性化又控制了成本。2.3 SpringBoot核心配置与模块划分SpringBoot项目结构上我习惯按业务模块分包而不是按技术层次分包。代码结构大致如下com.health.system ├── controller // Web层接口 │ ├── AuthController │ ├── HealthProfileController │ ├── RecordController │ └── AiAssistantController ├── service // 业务逻辑 │ ├── UserService │ ├── HealthProfileService │ ├── RecordService │ └── GptService ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体类 ├── dto // 前端交互对象 ├── config // 配置类跨域、拦截器、GPT参数 ├── common // 通用返回结果、异常处理、常量 └── utils // 工具类个人健康管理系统虽然不复杂但我依然强烈建议做好统一返回结构和全局异常处理。统一返回结构用Result 封装包含code、message、data三个字段前端统一判断code是否为200。全局异常处理配合RestControllerAdvice把参数校验异常、业务异常、GPT调用异常统一拦截返回友好提示。这一套做完代码整洁度直接上一个档次后面联调的时候能省大量时间。再说几个配置文件里的坑。数据库连接建议用druid连接池配置好初始连接数和最大连接数MyBatis-Plus的map-underscore-to-camel-case设为true自动把数据库下划线字段映射为驼峰属性GPT调用的相关配置放在application.yml里包括api key、模型名称、超时时间、最大token数通过ConfigurationProperties绑定到配置类不要硬编码在代码里。3. 实操过程与核心环节实现3.1 环境准备与项目初始化先说环境版本。JDK建议用1.8或11SpringBoot 2.7.x在这两个版本下都非常稳。如果你本机装的是JDK 17以上建议优先考虑SpringBoot 2.7系列的高版本或者直接上SpringBoot 3.x否则启动时可能出现依赖注入异常。这个一定要提前确认不然项目初始化阶段就被卡住会非常扫兴。数据库用MySQL即可。安装完成后创建数据库health_manage执行项目自带的SQL脚本。有同学喜欢用Navicat手动建表我不建议项目如果自带SQL脚本直接source执行确保表结构跟代码里的实体完全对得上。建好以后在application.yml里改数据库账号密码。建议建一个独立的数据库账号不要直接用root这是一个好习惯。IDEA导入项目后等待Maven下载依赖。如果下载慢把Maven镜像换成国内的阿里云镜像。第一次启动前检查一下三个地方JDK版本是否匹配、application.yml里的数据库配置是否改好、Maven是否已经成功reimport。这三个地方没问题启动基本是一次性成功。3.2 健康评估模块的实现逻辑健康评估不能只靠GPT本地规则先算出一部分硬指标这样即使大模型接口暂时不可用系统核心功能也能跑。硬指标包括BMI、基础代谢率、每日推荐热量摄入。再结合体征记录生成健康评分。BMI计算很简单体重除以身高米的平方。基础代谢率我用的公式是Mifflin-St Jeor男性10×体重(kg)6.25×身高(cm)-5×年龄5女性10×体重(kg)6.25×身高(cm)-5×年龄-161。这个公式在营养学上比较常用比Harris-Benedict更推荐答案中如果说你用了这个公式会显得专业。健康评分我这里设计了一个简单的模型将BMI、血压、血糖、运动频率、睡眠时长五个维度按权重打分各占20分合成百分制。这一步在代码里用规则实现每组数值区间对应一个分值。比如睡眠时长7-8小时得20分6-7小时得15分少于5小时得5分。这种模型虽然不是医学级的但作为演示和概念验证绰绰有余。之后把评分和用户健康数据打包作为GPT建议的输入。也就是说GPT不是完全自由发挥而是基于本地生成的结构化评估结果去做扩展和润色这样回答质量稳定得多也不太容易跑偏。3.3 GPT对话接口的接入GPT对话接口是这套系统里演示效果最炸裂的部分。前端页面设计成一个聊天窗口用户输入问题点击发送异步请求后端接口后端调用GPT接口拿到回答后返回前端展示在对话列表里。核心代码逻辑大致如下public String chatWithGpt(String userMessage, String healthContext) { String systemPrompt buildSystemPrompt(healthContext); ListMessage messages new ArrayList(); messages.add(new Message(system, systemPrompt)); messages.add(new Message(user, userMessage)); GptRequest request new GptRequest(); request.setModel(gptProperties.getModel()); request.setMessages(messages); request.setTemperature(0.7); request.setMaxTokens(800); String responseBody HttpUtil.postJson(gptProperties.getApiUrl(), JSONUtil.toJsonStr(request), createHeaders(gptProperties.getApiKey())); return parseResponse(responseBody); }这里要重点处理几个细节。超时时间建议设置30秒以上GPT接口的响应速度不稳定尤其当输入输出都比较长的时候默认的10秒超时容易误判为失败。调用前检查API Key对应的账户余额和额度是否充足避免在演示现场出现“因为余额不足导致返回鉴权错误”的尴尬。token消耗要做统计一次完整问答消耗多少token成本多少展示在后台日志里这东西做好了很体现工程意识。为了优化用户体验我建议把同步调用改成异步任务或流式返回。最简单的方案是使用Spring的WebAsyncTask或Ajax轮询前端发起请求后后端异步调用GPT完成后把结果存入数据库同时通过WebSocket推送或让前端轮询获取。如果时间紧同步调用加loading动画也能接受但体验会差一截。3.4 前端页面与演示联调前端技术栈我建议BootstrapThymeleaf原因就是快。登录注册页、首页仪表盘、健康档案页、记录管理页、AI助手聊天页、体检报告页这几个页面做下来如果你的页面功底一般用Bootstrap现成组件拼装一周内也能做完。首页仪表盘是门面担当。展示用户基本信息、最近一次BMI、今日摄入热量与消耗热量、近7天体重趋势图、健康评分。图表直接用ECharts引入CDN就行。AI助手页面采用左右分栏布局左边是用户健康数据摘要卡片右边是聊天窗口用户提问时系统自动携带健康摘要作为上下文。这个设计一定要保留因为它直观展示了“GPT不是瞎聊而是真的结合了用户数据”答辩时的演示效果极佳。联调阶段常见的问题是跨域。如果前端页面和后端接口不在同一个端口需要配置CorsFilter。Swagger或接口文档也要生成一份配合项目自带的PPT和文档演示时一边开着接口文档一边展示专业感马上出来。4. 常见问题与排查技巧实录4.1 GPT接口调用问题这是整套系统里最容易出问题的环节。我把碰到的典型问题整理成一张速查表对照排查能节省大量时间。现象可能原因解决方法返回401鉴权失败API Key错误、Key失效或格式不对检查application.yml中Key是否完整不要有空格返回429限流请求频率超过限制或账户额度不足加请求间隔检查账户使用情况降低并发请求超时默认超时时间太短或网络波动设置HTTP客户端连接和读取超时至少30秒返回结果乱码编码不一致统一使用UTF-8调用端设置Content-Type为application/json;charsetUTF-8模型参数不生效模型版本与参数不匹配查阅所用模型版本的最新文档确认参数名称和取值范围还要注意一点GPT返回的内容里可能包含一些不需要的字符比如换行符、JSON转义符解析时要做好清洗。建议把返回结果先解析成JSON对象再取choices[0].message.content字段不要直接用字符串截取的方式。4.2 SpringBoot启动与依赖问题SpringBoot版本和JDK之间的兼容问题是新手重灾区。如果你启动时看到类似“Invalid value type for attribute factoryBeanObjectType”或者“java.lang.NoClassDefFoundError”大概率是版本不匹配。我的建议是JDK 8用SpringBoot 2.3到2.7JDK 11用2.7也稳妥JDK 17直接用SpringBoot 3.x。不要盲目追新稳定压倒一切。Maven依赖冲突也常见尤其是hutool和spring-boot自带的HttpClient相关依赖冲突。解决方法是使用mvn dependency:tree查看依赖树找到冲突项后在pom.xml中排除。再有就是MyBatis-Plus版本要和SpringBoot版本匹配最新的MyBatis-Plus 3.5.x对SpringBoot 2.x支持完全没问题但如果你用了SpringBoot 3.x就要选对应的新版本。4.3 数据库与中文乱码问题数据库连接串中一定要加上characterEncodingutf8和useSSLfalse两个参数。前者解决中文写入变问号的问题后者避免MySQL 8.0以上版本对SSL的警告。表结构创建时字符集选择utf8mb4而不是utf8因为utf8mb4才完整支持中文和特殊符号。还有一个隐蔽的问题MySQL时区。如果插入数据的时间和你本地时间差8小时检查连接串是否配置了serverTimezoneAsia/Shanghai。这个问题在部署到云服务器时尤其常见本机不暴露是因为IDE的数据库连接默认配置了时区而项目里的独立连接串没有。4.4 演示前的最后检查清单如果是拿这套系统做答辩或演示我强烈建议你按这个清单提前演练一遍确认GPT API Key有效且账户余额足够支撑演示建议准备双Key备用。数据库里预置一份完整的演示数据包括最近30天的体征记录、饮食记录、运动记录让图表和统计看起来充实。提前测试AI对话功能准备3-5个典型的演示问题比如“根据我的数据给出饮食建议”、“我的血压偏高需要注意什么”、“帮我生成一份一周运动计划”。网络环境要稳定如果演示地点网络不好建议准备一个本地规则的兜底回答或者直接开手机热点。确保源码、文档、PPT都放在一个目录下命名清晰方便评审查看。5. 项目扩展思路与个人心得5.1 从课程设计到可用产品的差距这套系统如果只是做完交差那确实不难。但如果你想把它变成一个真正能用的产品差距主要体现在三个地方。第一数据安全与隐私合规。健康数据属于高度敏感的个人信息真实产品需要做数据加密存储、访问审计、用户授权管理甚至需要符合相关隐私法规的要求。第二大模型输出的可靠性。GPT虽然能生成流畅的建议但可能产生幻觉真实场景下需要增加人工审核、知识库检索增强、医学规则库兜底等多层校验。第三可扩展性。目前是单体应用如果用户量上来GPT调用需要做成独立服务并进行限流、熔断、缓存语义等治理。对于课程设计或毕业设计来说能在答辩中提到这三个扩展方向绝对是一个进阶亮点因为它说明你不仅有“写代码”的能力还有“思考产品落地方案”的意识。5.2 我踩过的坑和总结的经验最后分享几个我实际整理这套项目时最深的感触。第一GPT接入部分一定要拆得独立。把GPT相关的代码单独放在一个模块里不要让业务代码到处直接调用HTTP请求。我一开始图省事直接在Service里写了GPT调用逻辑结果后面改超时时间、加token统计、换成流式输出时改得焦头烂额。拆出来之后一切变得清晰可控。第二健康数据的关联关系从第一天就要设计好。我在第一版设计里没有把“健康档案”和“体征记录”分清楚导致体重数据既出现在档案表又出现在记录表产生了两份不一致的数据。后来痛定思痛才按“档案是一个时间快照记录是一条持续追加的时间序列”这个原则重新设计。这个理解也是答辩时的一个核心概念要讲透。第三连接大模型的成本控制一定要提前想。我的第一版测试由于忘记设置max_tokens上限有一次长对话直接消耗了远低于预期的其他接口额度注这里应理解为“超出了预期额度”。后来我做了三件事限制单次最大token数、记录每次调用的token消耗、在管理后台加了一个“今日AI调用次数与成本”的展示卡片。把这个功能展示出来老师或者面试官会觉得你考虑问题很全面。这套基于SpringBootGPT的个人健康管理系统从头到尾做下来基本上把Java Web开发的核心技能和大模型应用开发的常见套路都覆盖到了。如果你正在做类似的选题希望这篇文章能帮你少走一些弯路。项目源码、配套文档和PPT都是现成的拿到手之后先别急着跑按照文章里说的思路把数据模型看一遍再去追代码的实现细节比你直接启动项目一头雾水地乱点要有收获得多。做这种东西慢就是快。