直接说重点这是一个真正能跑起来、能拿来写的课设/毕设级别项目技术栈以 SpringBoot 为主、通过接口接入 GPT 大模型能力、实现个人健康数据的管理与分析。我在本地完整把它搭过一遍整体分成后端服务、接口对接、前端可视化和系统文档四层结构下面这篇就完整拆给你看为什么这么设计、数据表怎么建、GPT 接口怎么接、哪些地方特别容易踩坑以及那些网上教程不会明说的细节。1. 项目整体设计与技术选型思路1.1 个人健康管理系统到底要解决什么问题健康管理不是只记一个体重数字它是一连串动作的闭环记录健康数据 → 统计分析变化趋势 → 生成健康建议 → 指导用户调整生活习惯。市面上的智能手表、体脂秤都会给你原始数据但很少告诉你这些数据加起来意味着什么。这个系统的核心价值就是把散落的健康指标收拢起来再用大量模型能力把它们翻译成人话。我从需求设计初就把系统拆成六大模块用户模块、健康档案模块、数据记录模块、统计分析模块、AI 建议模块、系统管理模块。其中 AI 建议是整个系统的灵魂没有 GPT 接入它只是一个普通的数据录入工具接入了以后它就变成一个能跟你对话的私人健康助理。另一个关键设计决定是前后端分离。虽然标题里没有明确说前端用什么但既然 SpringBoot 只承担后端职责前端采用 Vue3 Element Plus 就很自然。有人可能问为什么不用 Thymeleaf 直接做服务端渲染我的理由是健康管理场景天然需要图表和动态交互分离式架构对可视化、异步加载、后续扩展都友好得多。1.2 技术栈选型的深度分析SpringBoot 3.x 现在很流行但我实际开发时依然锁定 SpringBoot 2.7.x。原因很简单GPT 相关的 Java SDK 生态、MyBatis-Plus 对 SpringBoot 3 的适配虽然已经跟进但很多第三方 starter 还停留在 2.x 时代比如一些图形验证码、日志增强组件。用 2.7.x 版本兼容性和稳定性是最稳的这个判断在实际开发中帮我避免了不少麻烦。整套系统核心依赖如下SpringBoot 2.7.18应用主框架MyBatis-Plus 3.5.x数据持久层避免写一堆 JDBC 模板代码MySQL 8.0主数据库Redis 2.6.x 对应版本管理 Token 会话和热点数据缓存SpringDoc / knife4j自动生成接口文档Hutool 工具库处理日期、加密、HTTP 请求ECharts 5.x前端健康趋势图表对于 GPT 接入这一环我最后没有选择任何封装好的 Java SDK而是直接用 Hutool 的 HttpUtil 调用老模型的 Chat Completions 接口。这么做的原因是SDK 版本迭代太快经常出现接口签名变化导致编译报错而纯 HTTP 调用只依赖一个稳定的 REST API出问题也好排查。核心逻辑只有几十行代码可控性强后续想换其他模型也只需要改配置。分批去裁。项目里的健康状况评分、运动建议、饮食建议、指标异常分析都是通过构造特定 prompt 模板实现的这一点在后面我会给出具体模板。2. 核心数据模型与健康指标设计拆解2.1 数据库表结构设计这 7 张表缺一不可健康管理系统最怕的就是数据建模混乱。我当时把整个数据模型画了三遍才定下来核心原则是用户中心 指标维度 建议结果三向分离。第一张表是用户表。它跟标准用户表不太一样的地方是多加了几个体质相关字段身高、基础体重、出生日期用于计算年龄、性别这些是后续大模型生成建议的基础参数单独建表字段比每次都传要好。第二张表是核心业务表——健康指标记录表。我设计它时采用了纵向存储方案每一条记录包含指标类型如血压、血糖、心率、睡眠时长、指标数值、单位、记录时间外加用户的备注。这种纵向表结构对动态增加新指标特别友好不用因为以后要加一个血氧字段而改表结构。第三张表是饮食记录表字段包括食物名称、估算热量kcal、碳水/蛋白质/脂肪克数、餐次类型早/午/晚/加餐、记录日期。食物营养成分的数据前期可以先写死后端常量库不必接第三方食物数据库避免增加项目复杂度。第四张表是运动记录表记录运动类型跑步/骑行/力量训练等、时长分钟、消耗估算、运动日期。消耗热量可以用基础代谢和运动当量的简化公式计算在服务端完成。第五张表是健康建议表存 GPT 返回的文本内容、建议类型、关联的健康指标批次号、创建时间。有个易错点一条建议可能要关联多个指标记录所以我单独用一个 batch_id 字段标识是哪一批数据触发的建议避免多对多关联表过于复杂。第六张表是提醒配置表存提醒类型、提醒时间用 cron 表达式、是否开启。第七张表是系统日志表记录关键操作审计日志。数据库字符集统一使用 utf8mb4排序规则 utf8mb4_unicode_ci。这是中文内容存储的基础配置我看到过很多项目忘记设置结果存汉字变成问号。表名统一预防针加t_前缀比如t_user、t_health_record这个习惯在多人协作时能省不少沟通成本。2.2 健康指标的计算逻辑健康指标里最基础的 BMI 计算反而要注意细节。公式很简单体重kg除以身高m的平方。但如果你不做任何校验用户把身高误填成 172cm而不是 1.72m算出来的 BMI 会是 0.58系统直接给出严重偏瘦的可笑结论。所以服务端必须做单位归一化身高统一存厘米计算时再转米。代谢当量和基础代谢的计算我采用的是经典 Mifflin-St Jeor 公式男性基础代谢 10 × 体重(kg) 6.25 × 身高(cm) - 5 × 年龄 5 女性基础代谢 10 × 体重(kg) 6.25 × 身高(cm) - 5 × 年龄 - 161这个公式比旧版 Harris-Benedict 公式更贴近现代人群在很多健康 App 中使用。年龄直接根据birthday字段动态计算避免用户每年要手动改年龄这也是一个容易被忽略但体验感很强的细节。对于血压数据系统需要做等级判定。比如收缩压 ≥ 140mmHg 或舒张压 ≥ 90mmHg 时处于偏高水平心率 60~100 次/分为正常区间。这些阈值判断代码很简单但跟 GPT 建议结合就有价值了系统先做规则判断给出风险等级再把这个等级和原始数据一起传给大模型大模型就能在一个明确的语境下生成建议应答质量明显更高。2.3 接口设计上的几个核心约定我设计了统一返回结构ResultT包含code、message、data三个字段。code 为 200 表示成功401 表示未认证500 表示服务端错误。有人会觉得没必要但当前端要频繁处理错误状态时统一结构能减少很多 if-else 判断。接口路径按照 RESTful 风格设计例如POST /api/auth/register用户注册POST /api/auth/login用户登录GET /api/health/record/list分页查询健康记录POST /api/health/record新增健康记录GET /api/statistics/trend获取多项指标趋势POST /api/ai/advice获取 AI 健康建议GET /api/reminder/list查询提醒配置认证方案用的是 JWT 而不是 Session。JWT 天然适合前后端分离场景后端只需要在拦截器里校验 Token 合法性不必管理 Session 存储。为了避免 Token 被泄露后长期有效我设置了 24 小时过期时间同时 Redis 里存一份黑名单用户修改密码或主动退出时加入黑名单立即失效。3. 核心功能模块的实操实现细节3.1 用户注册登录与 JWT 认证落地方案注册接口看起来简单但业务细节不少。密码不能明文存储我用 BCrypt 加密。BCrypt 每次加密生成的哈希值都不同但校验时不要求哈希一致——它会把 salt 一起编码进结果里需要校验时自动提取。这一点经常有新手困惑为什么两次注册同一密码存的是不同字符串那是正常的不用改逻辑。注册时还需要做唯一性校验用户名和手机号都不可重复。这个判断放在 Service 层做先用 lambda 查询判断count 0有就直接抛出业务异常由全局异常处理器统一捕获并返回友好提示。JWT 生成我采用的是 jjwt 库。生成 Token 时把用户 ID、用户名塞进 claims设置签发时间和过期时间最后用 HS256 算法签名签名密钥从application.yml读取。需要注意密钥长度必须 ≥ 32 字节否则某些版本会报弱密钥错误这也是网上资料很少提的细节点。拦截器是登录态校验的关键我创建一个JwtInterceptor实现HandlerInterceptor接口在preHandle里从请求头Authorization取出 Bearer Token解析成功就把用户信息放入 ThreadLocal 上下文后续业务代码用UserContext.getUserId()就能拿到当前登录人。3.2 健康记录模块的增删改查与参数校验新增健康记录时前端提交的数据包括指标类型、数值、记录时间等。后端除了做常规非空校验还做了数值范围校验。比如心率范围如果不在 20~250 之间说明是误录入直接拒绝。这里用 JSR 303 注解比如NotNull、DecimalMin、DecimalMax配一个全局Valid校验几行注解就能完成入口防护。查询列表需要支持分页。MyBatis-Plus 提供了一个分页插件配置一个MybatisPlusInterceptor注册PaginationInnerInterceptor即可。使用时调用PageUserHealthRecord作为第一个参数插件自动生成 count 查询和 limit 查询十分方便。列表接口还支持多种筛选条件按指标类型、按时间范围、按关键字。MyBatis-Plus 的LambdaQueryWrapper可以链式拼接条件例如LambdaQueryWrapperHealthRecord wrapper Wrappers.lambdaQuery(); wrapper.eq(HealthRecord::getType, type) .ge(startTime ! null, HealthRecord::getRecordTime, startTime) .le(endTime ! null, HealthRecord::getRecordTime, endTime) .orderByDesc(HealthRecord::getRecordTime);注意.ge和.le前面的条件判断当参数为空时自动跳过避免查询时间范围时传空导致查不到数据的问题。修改和删除接口要实现数据归属校验记录的主键对应的userId必须等于当前登录用户 ID否则返回 403。我见过不少项目在删除操作上只校验记录存在性不校验归属导致用户能删别人的数据这是严重的越权漏洞。3.3 统计分析模块ECharts 多指标趋势图统计接口返回的数据结构直接影响前端图表渲染。我设计的趋势接口返回格式是一个数组每个元素包含日期、指标类型、对应数值。前端拿到后按指标类型分组分别传给 ECharts 的 series。指标趋势查询实现的关键是时间段聚合。MySQL 的DATE_FORMAT(record_time, %Y-%m-%d)可以按天格式化时间。如果想按周聚合可以用YEARWEEK(record_time, 1)需要注意这个函数默认周一还是周日作为一周开始不同场景要求不同。为了统计模块的查询性能我给(user_id, type, record_time)加了组合索引这在数据量几百条时看不出差别但到了几万条就会明显感觉到差异。顺手还可以加一个指标占比统计接口比如近 30 天各类运动时长占比前端用饼图展示这部分工作量不大但能让系统的完整度上一个台阶。3.4 定时提醒模块Quartz 与 cron 表达式的坑提醒模块我采用的是 Spring 自带的Scheduled注解没有引入 Quartz因为任务简单、不涉及分布式调度。关键点在于 cron 表达式写法比如每天 8 点提醒喝水写成0 0 8 * * ?每周一、三、五晚上 7 点半提醒运动写成0 30 19 ? * MON,WED,FRI。这里有个实际经验Scheduled注解默认是单线程串行执行的。如果任务执行时间较长多个任务会互相阻塞。所以我在启动类里加了一个TaskScheduler配置设置线程池大小为 5Bean public TaskScheduler taskScheduler() { ThreadPoolTaskScheduler scheduler new ThreadPoolTaskScheduler(); scheduler.setPoolSize(5); scheduler.setThreadNamePrefix(schedule-task-); return scheduler; }提醒任务的核心逻辑是每天固定时间扫描提醒配置表中开启状态的记录把到期的提醒消息封装后通过 WebSocket 或站内信推送给用户。WebSocket 做实时推送体验最好但需要一个额外配置类如果时间紧改成用户登录后拉取未读提醒列表也是一种性价比更高的方案。4. GPT 能力集成从 API 调用到提示词工程4.1 SpringBoot 调用大模型接口的实际实现GPT 能力是这个项目最有技术含量的部分也是答辩时最容易被追问的部分。我从接口调用到提示词设计完整讲一遍。我选择直接通过 HTTP 调用大模型标准的 Chat Completions 接口。请求协议是 POST请求体是 JSON包含model、messages、temperature等参数。用 Hutool 的HttpUtil封装请求非常简单public String chatCompletion(String systemPrompt, String userContent) { String url https://api.openai.com/v1/chat/completions; MapString, Object body new HashMap(); body.put(model, gpt-3.5-turbo); ListMapString, String messages new ArrayList(); messages.add(Map.of(role, system, content, systemPrompt)); messages.add(Map.of(role, user, content, userContent)); body.put(messages, messages); body.put(temperature, 0.7); String json JSONUtil.toJsonStr(body); HttpResponse response HttpRequest.post(url) .header(Authorization, Bearer apiKey) .body(json) .timeout(30000) .execute(); // 解析返回的 choices[0].message.content }注意几个点超时时间至少设置为 30 秒因为大模型接口响应通常需要 3~10 秒如果设置 5 秒超时大概率会频繁失败。接口的temperature参数是控制随机性的健康建议场景我设置为 0.7既能保证回答稳定又不至于太死板。还有要求调用频率限制的问题QPS 不要超过 3否则容易返回 429 限流错误。调用前做幂等设计也很重要用户在页面上点一次获取建议可能因为网络抖动重复提交。我在前端做按钮 loading 禁用在后端用 Redis 做 5 秒内重复请求拦截双保险。4.2 提示词工程健康建议质量的分水岭很多人接入大模型后就只是简单拼一句请给我健康建议效果当然非常差。真正有工程价值的做法是把用户健康数据组装成结构化上下文再配合一个角色设定提示词。我的系统提示词基本是这样写的你是一名资深健康管理师拥有临床营养学和运动医学背景。请基于用户的健康数据给出专业、具体、可执行的生活建议。要求 1. 分析当前数据的异常项指出潜在健康风险 2. 针对饮食、运动、睡眠三个维度分别给出建议 3. 建议必须具体可执行不要泛泛而谈比如写明具体食物、运动时长、频率 4. 如果数据全部正常也请给出维持健康的建议 5. 语气亲和专业篇幅控制在200字左右用户消息则把数据全部序列化用户基本信息男性28岁身高175cm体重80kg 近期健康数据BMI 26.1超重连续7天平均睡眠6.2小时血压测量值 132/85mmHg静息心率 78次/分 请基于以上数据分析健康风险并给出建议。这样组合出来的回答质量跟随便丢一句话进去的结果完全是两个水平。我实际测试下来模型的回答已经能够识别出BMI 超重且睡眠不足可能增加心血管负担这样的关联分析这在传统规则引擎里需要写几十条 if-else 才能实现。提示词工程还有一个进阶技巧在一次请求里让模型返回 JSON 结构而不是纯文本。比如要求以 JSON 格式返回包含风险等级、饮食建议、运动建议、睡眠建议四个字段。这样后端解析结果就不再依赖正则匹配或者人工判断可以直接结构化入库。实现方式是系统提示词里写明 JSON 格式样例并把response_format参数设为{type: json_object}代码里用JSONUtil.parseObj(content)解析。4.3 接入大模型的降级与容错机制大模型接口不能保证 100% 可用。网络抖动、限流、服务端过载都会导致调用失败。所以我在 AI 建议服务里设计了三级降级策略第一级调用失败自动重试一次重试时间间隔 1 秒。这是最简单有效的策略很多瞬时错误一次重试就能解决。第二级重试仍失败则走本地规则引擎。我把健康指标判定规则用 Java 实现了比如血压偏高则提示注意低盐饮食、规律监测等模板化文本。这部分是保底方案保证功能始终可用。第三级规则引擎仍无法覆盖的场景比如异常组合返回一个通用提示暂时无法生成个性化建议请咨询专业医生并记录失败日志后续人工检查。我在实际开发中把RestTemplate的请求日志单独拉了一份记录了每次调用的请求参数和响应耗时。分析后发现响应耗时在 4~12 秒之间波动所以前端请求超时时间也相应设置为 30 秒UI 层会有一个AI 正在思考中的等待状态体验上避免用户以为系统卡死了。5. 安全加固、性能优化与文档整合实战5.1 接口安全性越权防护、SQL 注入与 XSS 过滤安全这块如果只在答辩 PPT 里提一句用了 JWT是远远不够的。一个健康系统涉及用户体重、血压、既往病史等隐私数据必须认真防护。越权防护方面我设计了数据权限注解RequireOwner在修改、删除、查询详情的接口加上该注解后切面自动校验资源归属权。这种做法比在每个业务方法里手动判断userId要统一得多也不容易遗漏。SQL 注入方面MyBatis-Plus 的LambdaQueryWrapper本身使用预编译参数自带防注入能力。容易出问题的是手写的 SQL比如统计报表里的复杂查询我用${ew.customSqlSegment}时一定确保使用的是参数占位符#{}而不是${}这个细节在使用Select注解时要格外小心。XSS 过滤我用了一个XssFilter对请求 body 里的script标签和javascript:协议进行转义。实现方式很简单注册一个 Filter通过XssRequestWrapper重写getParameter和getInputStream方法将所有输入内容过一遍白名单清洗函数。个人健康管理系统的用户输入字段不少比如饮食记录里的备注、健康建议里的自定义问题不做过滤容易被存储型 XSS 钉上。5.2 性能优化从查询到缓存的实操细节几百个用户量级的系统没必要上分库分表但基本的性能习惯要有。第一个优化点健康记录列表查询接口。原始实现直接从 MySQL 查询全量再内存分页效率很低。优化后先用 MyBatis-Plus 分页插件配合(user_id, type, record_time)索引单次查询量级控制在 20 条以内响应时间稳定在 50ms 以内。第二个优化点首页仪表盘需要显示多项汇总数据总记录数、近 7 天趋势、最新指标值。这些数据都属于读多写少类型我加了 Redis 缓存。用户修改健康记录时用先更新数据库、再删除对应缓存键的策略避免缓存与数据库不一致的问题。关于缓存还有一个容易踩的坑Redis 的 key 设计不要直接用裸 ID要加业务前缀比如health:user:123:recent。否则后续项目里 Redis 键多了以后很难一眼看出这个键是干什么的排障非常痛苦。5.3 项目文档与 PPT 的结构设计标题里提到的含文档PPT源码说明这类项目的交付物不只是代码还有配套材料。文档部分我分成了三份需求分析说明书、数据库设计文档、系统部署手册。毕业论文场景里这三份基本就是核心交付物。文档最大的问题是写不够细。需求说明书只写用户可以记录健康数据这种写法等于没写。有分量的写法是给出用户用例、业务流程、数据字典甚至包含原型图。数据库设计文档里每个表都附上字段说明、类型、约束和设计理由让答辩老师看出数据建模的思考过程。PPT 的核心逻辑是问题导入 → 方案设计 → 技术实现 → 成果演示→ 总结展望页数控制在 15~20 页。技术实现部分要放系统架构图、数据库 ER 图、核心代码片段和效果截图。演示环节建议提前录制一段 2 分钟的视频嵌入 PPT因为现场演示经常出幺蛾子比如网络波动导致 GPT 调用失败有备用视频会从容很多。5.4 本地部署与 Docker 打包的完整步骤本地部署其实很简单前提是环境齐全。我当时用的开发环境是 JDK 1.8、Maven 3.8、MySQL 8.0、Redis。项目里提供一个sql/init.sql脚本初始化所有表结构并插入一个测试账号新建用户后第一步应该是登录健康数据可以先通过页面手动录入测试 AI 建议等核心链路。后台部署的话用 Docker 会更顺手。我写了一个Dockerfile从maven:3.8-jdk8构建到openjdk:8-jre运行多阶段构建可以把最终镜像控制在 200MB 以内。另外用docker-compose.yml把 MySQL、Redis 和 Java 应用编排在一起启动命令就一条docker-compose up -d有两点经验值得分享第一Java 应用容器里时区默认是 UTC健康记录的时间显示会差 8 小时必须在启动参数里加-Duser.timezoneAsia/Shanghai或者环境变量TZAsia/Shanghai。第二大模型 API Key 不要写死在application.yml里通过环境变量传递防止代码提交到公开仓库后密钥泄露这个习惯从项目开始就要养成。6. 常见问题与排查技巧实录6.1 SpringBoot 项目启动失败问题很多人在本地跑这种项目遇到的第一个报错是Failed to configure a DataSource。这个错误的核心含义是应用启动时自动配置去寻找数据源但没找到连接信息。常规解法是检查application.yml里 spring.datasource 配置是否正确url、username、password 是否齐全MySQL 服务是否启动库名和账号是否存在。还有一个坑如果你的.yml文件里中文注释没有转 UTF-8 编码启动时会报Caused by: java.nio.charset.MalformedInputException这类问题是编码问题不是语法问题。另外一个启动阶段常见的问题是高版本 JDK 编译报错。如果你机器上是 JDK 17用 SpringBoot 2.7 加 JDK 1.8 目标编译会有版本冲突。解法是统一用 JDK 8 跑或者在 pom.xml 里改java.version为 17并升级相关依赖版本。在学校机房的机器上遇到过好几次这种环境问题建议直接把 JDK 8 配置写进 README能省很多人力。6.2 GPT 接口调用失败的完整排查记录这是整个项目里让我花时间最多的问题。症状是接口偶尔成功偶尔超时返回 500。我对失败日志做了一段时间的统计发现 80% 的失败集中在两种状况请求超时和限流。超时问题的根源是上面提到的 HTTP 客户端默认超时太短设置到 30 秒后基本解决。限流问题则麻烦一些需要看响应体里的错误码。429 表示请求过于频繁需要增加指数退避策略如果出现 401 则检查 API Key 是否失效或账户余额是否不足这一步经常被忽略尤其是用到一些中转服务时特别容易出问题。我还遇到过一种特殊状况返回 200但choices数组为空。这种情况通常是因为敏感词过滤或内容策略拦截。排查方法是打印完整响应 JSON如果finish_reason是content_filter说明内容触发了策略需要调整提示词措辞。6.3 数据统计接口常见的问题与慢查询优化细节统计模块在数据量过千条后出现了一次明显的响应变慢从最初的 30ms 涨到了 1.2 秒。用EXPLAIN看了执行计划发现全表扫描、没有走索引。原因是我建的复合索引顺序是(type, user_id)但查询条件里最常用的是user_id和时间范围所以索引没有命中。调整顺序为(user_id, type, record_time)后响应恢复到 40ms 以内。这个案例的通用经验是复合索引的字段顺序要按查询条件的选择性来排。选择性最高的字段放最左MySQL 里user_id唯一值多、选择性高放左侧能最大化索引命中率。另一个统计接口易错点是动态查询条件拼接时排序字段若来自前端传入的字符串不能直接拼接进ORDER BY会造成 SQL 注入。我做了白名单校验排序字段只允许在白名单数组内取值比如包含record_time、type、create_time其余一律走默认排序。6.4 前端调用后端接口的典型问题我在联调过程中遇到最多的是跨域问题。SpringBoot 需要在配置类中注册跨域映射Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns是 SpringBoot 2.4 之后的写法以前用allowedOrigins(*)在携带凭证时会有兼容性问题。allowCredentials 为 true 时allowedOrigins 不能用*这是浏览器规范限制用 pattern 可以解决。另外一个联调问题是日期格式。Java 后端默认返回的 LocalDateTime 格式是2025-01-15T10:30:00前端如果直接展示会有个 T 字母。我在项目里配置了全局 Jackson 日期格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样前端拿到的就是正常的中文时间格式省去前端转换的麻烦。7. 实测体验与总结思考我完整跑通这个项目大概花了一个完整开发周的时间其中真正写代码的时间其实只占了一半另一半全花在跟 GPT 接口打交道和各种环境问题上。把这个过程回头梳理有几点强烈建议给准备做类似主题的人。第一接大模型的系统不超过早接。先把功能验证做通了再去完善界面和文档避免最后发现模型调用链路的坑要改底层设计。我是先写了 20 行代码直接调接口拿到返回确认可行后才开始搭提示词模板和降级逻辑。第二提示词的迭代要建立记录。我在本地建了一个 prompt 记录文档每次改动都记下来改了哪个要求、模型回答质量是否提升、失败案例是什么。这个方法虽然土但对回答质量的提升极其显著远比凭感觉瞎调有效。第三答辩时重点讲设计取舍。比如为什么用 JWT 不用 Session前后端分离、为什么用 HTTP 直接调用而不用 SDK可控性和排障、为什么提示词要结构化输出方便入库——这些为什么正是普通项目报告里缺失的东西也是拉开评分差距的地方。最后说一句实际经验这个项目做下来收获最大的不是学会了 SpringBoot 的某个注解或 GPT 的调用方法而是完整走了一遍需求梳理 → 数据建模 → 接口设计 → 集成第三方能力 → 部署上线的全流程。如果你们在做类似的选题遇到某个环节卡住了按我前面写到的流程逐步排查大部分问题都能在半小时内定位。祝顺利。