如果你的毕业设计选题清单里同时出现了“AI”“Vue”和“社区健康管理”这几个词，你大概率和我当初一样纠结：AI到底要做到什么程度才算有工作量？前端做到什么效果才能让答辩老师一眼看出不是套模板？毕设做完之后，论文、PPT、源码这些交付物又该怎么整理才不会被追问得体无完肤？

这篇就完整复盘一下我的青湖社区健康管理系统。我会从选题逻辑讲起，把AI功能怎么落地、Vue前端怎么搭、后端数据库怎么设计、论文答辩怎么准备这几件事全部串起来。内容适合正在做类似健康管理、智慧社区类系统的同学参考，也适合想搞明白“AI功能放进Web系统里到底能做什么”的人看。

1. 从选题焦虑到系统落地：青湖社区健康管理系统到底解决什么问题

选题是大多数毕业设计的第一道坎。当时我的思路很简单：找一个既有现实意义、又能同时体现后端开发和前端交互能力的场景，最好还能往AI方向靠一靠。社区健康管理正好满足这些条件——它不像纯电商系统那么千篇一律，也比纯粹的数据可视化课题更有业务纵深。

1.1 当初为什么把三个关键词拼在一起

先说结论：这三个词放在一起，不是因为“越复杂越好”，而是因为它们分别承担了不同的工作量证明任务。

AI功能证明你有算法思维和模型落地能力，能处理结构化数据，能把模型预测结果接进真实业务逻辑；Vue前端证明你有完整的工程化能力，包括组件拆分、状态管理、路由权限、可视化图表；社区健康管理系统则是业务载体，让前面两个技术点有了真实的应用场景——居民维护自己的健康档案，社区医护人员查看风险人群、给出干预建议。

如果只做一个普通的CRUD系统，工作量撑不起毕业论文；如果只做一个AI模型训练，又偏离了Web开发的评价标准。把业务、前端、AI三件事串成一个闭环，答辩的时候每个模块都能单独拿出来讲。

1.2 系统的核心用户和功能模块

青湖社区是一个虚拟的社区单位，系统面向三类角色：普通居民、社区医护人员、系统管理员。

居民端的主要功能是维护个人健康档案，录入身高、体重、血压、血糖、运动情况等指标，查看自己的健康评估报告和系统生成的个性化健康建议，预约社区体检或健康咨询；医护端则是处理居民的服务预约、批量查看辖区内的风险人群、对重点对象进行随访并填写随访记录；管理员负责维护社区公告、管理居民账号和医护账号、查看系统统计数据。

我把整个系统划分成了七个核心模块：用户认证与角色权限、健康档案管理、健康指标录入与管理、AI健康评估、个性化建议生成、服务预约与工单处理、社区运营管理。每个模块都不算复杂，但组合在一起就构成了一个完整的业务闭环。

1.3 这类系统的功能边界：为什么不能做成“医疗系统”

这里必须提醒一句：社区健康管理系统不是医疗诊断系统，功能边界一定要把握住。

系统的定位是健康管理辅助工具，它做的是指标记录、趋势分析、风险提示和生活方式建议。我不会在系统里输出“你可能得了某种病”“建议你去吃某种药”这类表述，所有AI评估结果都标注为“健康风险参考”，涉及异常指标时统一引导用户“建议前往正规医疗机构咨询”。这个边界既是安全需要，也是答辩时的业务逻辑保障——回答“你这个AI凭什么给健康结论”这种问题时，一句“我们做的是风险参考而非医疗诊断”就能站住脚。

2. AI功能落地：健康风险评分与个性化建议的建模细节

大部分毕设里的AI功能都是“调用一个现成的API返回结果”，但这在答辩时很容易被追问到崩。我选择了更稳妥也更出效果的路线：自己做特征工程，自己训练一个可解释的健康风险评估模型，再配合规则模板生成建议。

2.1 找适合毕设的AI粒度：规则引擎与轻量机器学习模型的组合

真正动手之前，我把AI功能的实现方案列了三种：调用第三方健康评估API、只用阈值规则做判断、先做指标标准化再训练一个轻量级模型。第一种网络依赖太强，答辩现场断网就完蛋；第二种技术含量太低，论文里写不出东西；最终我选了第三种，并且叠加了一套规则引擎做兜底。

实际方案是：先用规则引擎对明显异常指标做硬性判断，比如收缩压超过180就无论模型结果如何都直接标为高风险；然后对特征数据进行标准化处理，送到一个逻辑回归模型里计算风险概率；最后把规则判断和模型概率做一个加权融合，得到五级风险等级（低、较低、中、较高、高）。这个设计的好处是既保留了传统规则的可解释性，又确实用上了机器学习模型，不是花架子。

为什么要用逻辑回归而不是更复杂的模型？理由有三个：样本量小的时候复杂模型容易过拟合；健康场景对解释性要求极高，逻辑回归的权重可以直接说明“血压每升高一个单位，风险概率上升多少”；部署和接口调用都简单，不需要额外的深度学习框架依赖。答辩老师问起模型选型，这个理由很充分。

2.2 指标标准化与数据集构造

模型输入的特征我最终定了七项：年龄、BMI、收缩压、舒张压、空腹血糖、总胆固醇、每周运动次数。原始数据量纲差别很大，不标准化的话逻辑回归的收敛和权重解释都会受影响。

BMI需要先算出来：体重（千克）除以身高（米）的平方。对于血压、血糖这类指标，我先做了异常值截断，比如收缩压低于70或者高于250的数据直接视为录入错误，不参与计算。标准化方式用的是Z-score归一化，即（原始值减均值）除以标准差。

训练数据的来源，我使用的是公开的健康体检统计特征来构造模拟数据集，并结合社区体检的历史统计分布做了二次采样。这里要特别说清楚：毕设中的AI模型本质上是Demo级别的可行性验证，重点在于特征处理、模型训练、评估部署这条链路是完整的，而不是在于模型的临床准确性。我在论文的“数据来源与局限性”小节里明确写明了这一点，答辩时分寸感会好很多。

2.3 风险评分算法的实现思路和代码工程

后端里我单独建了一个ai包，包含特征处理、规则判断、模型推理三个类。模型训练用Python脚本离线完成，训练好的模型参数以JSON格式导出为一个权重文件，Java后端启动时加载这个文件进行推理，这样就避免了在Java工程里跑Python模型的集成难题。

逻辑回归的预测核心是计算sigmoid值，公式是：概率等于1除以（1加e的负z次方），其中z等于各特征乘以权重的累加再加偏置。我导出权重文件时，同时导出了特征的均值和标准差，这样后端代码里加载文件后就能原地完成标准化和推理。

以下是模型部分的伪代码结构，实际工程里我对每个方法都加了完整的注释：

import json import numpy as np from sklearn.linear_model import LogisticRegression # 特征顺序固定，训练和推理必须一致 feature_names = ["age", "bmi", "sbp", "dbp", "glucose", "cholesterol", "exercise"] # 训练完成后导出模型参数 model = LogisticRegression() model.fit(X_train, y_train) export_data = { "feature_names": feature_names, "weights": model.coef_[0].tolist(), "intercept": model.intercept_[0], "mean": X_train.mean(axis=0).tolist(), "std": X_train.std(axis=0).tolist(), "classes": model.classes_.tolist() } with open("health_model.json", "w", encoding="utf-8") as f: json.dump(export_data, f, ensure_ascii=False)

这里的特征顺序是训练和推理之间的隐性协议，Java后端加载JSON时必须严格按照feature_names的顺序拼接特征向量，否则预测结果全是错的。我在这个坑上踩过，后面联调排查了很久才意识到是训练和推理的特征顺序不一致导致的。

2.4 个性化健康建议的生成与回复逻辑

模型只输出一个风险等级是不够的，用户需要知道“接下来该怎么办”。我的做法是设计了一套基于规则模板的建议生成器，每个特征指标对应一个独立的风险区间，当某个指标落在异常区间时，就往建议列表里追加一条对应的生活方式建议。

比如BMI大于27时，建议文本是“建议控制体重，减少高油高糖食物摄入，每周保持至少150分钟中等强度运动”；收缩压大于140时，建议是“建议减少钠盐摄入，注意规律作息，定期复测血压”。每条建议都标注了关联指标和风险等级，前端按风险从高到低排序展示，比给一段大而全的废话有说服力得多。

这里有一个很容易被忽视的细节：建议内容不能出现“治愈”“药物”“确诊”等医疗用语，全部使用“建议”“参考”“咨询医师”这类措辞。我在建议模板数据库里做了关键词过滤，从源头保证合规性。

2.5 AI功能的性能开销控制

逻辑回归的推理本身很快，问题不大，但我要考虑一个现实场景：医护端批量查看社区风险人群时，要同时评估几十个居民的健康数据。如果每个请求都同步计算，接口响应会明显变慢。

我的处理方案是把AI评估拆成两部分：居民端在指标录入后触发单次实时评估，医护端批量查询时走缓存评估结果，只有评估时间超过7天或指标有变动时才重新计算。这样既保证了AI功能的实时性，又不会因为批量操作拖垮接口性能。这个“实时评估+缓存复用”的折中方案，在答辩时作为性能优化点讲出来，效果很好。

3. Vue前端：页面组件拆分、数据可视化和权限控制的实操过程

前端如果用传统JSP加几个月饼式的页面堆叠，AI模块做得再好也会被当成“老系统”。Vue的价值在于把前端工程化、组件化做得规整，在答辩演示时给人“这是一个现代Web应用”的第一印象。

3.1 技术栈选择与技术理由

我选型的是Vue 3加Composition API，UI组件库用Element Plus，图表库用ECharts，状态管理用Pinia，构建工具用Vite。这套组合在2024年之后基本是Vue生态的事实标准。

Composition API的好处是逻辑复用能力强。健康指标录入和健康评估报告两个页面都需要调用评估接口、处理加载状态、展示风险等级，我把这组逻辑抽成了一个useHealthAssessment组合式函数，两个组件分别调用，代码量减少了不少，答辩讲“组件复用”也有实际案例。

构建工具选Vite而不是Webpack，主要理由是开发时热更新体验好，更重要的是Vite对ESM的原生支持让依赖解析更稳。毕设项目组件规模有限，Vite冷启动速度优势非常明显，节省了很多重复等待时间。

3.2 前端页面地图与组件拆分

页面结构我按角色分成三套：居民端包括登录页、居民首页、健康档案页、指标录入页、评估报告页、建议列表页、服务预约页；医护端包含工作台、风险人群列表、居民详情、随访记录管理；管理员端包含用户管理、医护人员管理、公告管理、系统数据总览。

组件拆分的思路是按照业务域而不是页面来划分。比如风险等级标签我封装了RiskLevelBadge组件，所有出现风险等级的地方统一使用；健康趋势折线图封装成HealthTrendChart，只需要传入用户ID和指标类型就能自动加载数据。封装一次、多处复用，前端代码的整洁度比平铺直叙高一个档次。

以风险等级展示为例，我定义了等级到颜色、文案、图标的映射关系：

const riskLevelConfig = { low: { color: '#67C23A', label: '低风险' }, lower: { color: '#95D475', label: '较低风险' }, medium: { color: '#E6A23C', label: '中等风险' }, higher: { color: '#F56C6C', label: '较高风险' }, high: { color: '#F56C6C', label: '高风险', urgent: true } };

这个映射在居民端和医护端、前端展示和打印报告时都要用，抽成独立配置文件后保持了全局一致性。紧急风险的红色标签在医护端列表里会被刻意放大加粗，方便医护人员第一眼锁定重点人群。

3.3 用ECharts呈现健康趋势、雷达图和风险分布

数据可视化是答辩演示中最容易出彩的部分。我在系统里做了三类图表：居民个人指标趋势折线图、居民多指标健康状况雷达图、社区风险人群分布饼图。

趋势折线图的实现逻辑是：选择指标类型后，组件调用后端接口获取最近N次体检记录，按时间排序后渲染。这里有一个交互细节：切换指标时可选择“全部历史”“最近半年”“最近三个月”三个时间范围，数据量不同时折线图的X轴刻度密度要做自适应，不然全量数据挤在一起的时候图表可读性很差，这个细节我优化了三版才满意。

雷达图适合展示一个人当前的综合健康画像，六个维度分别对应BMI、血压、血糖、血脂、运动频率和睡眠时长。ECharts的雷达图配置不算复杂，但要注意各个维度的最大值要单独设置，比如BMI的合理上限是32，血糖的上限是10，不能统一用同一个刻度范围，否则指标之间存在视觉误导。

社区风险分布饼图则是医护端工作台的核心图表，按最近一次评估结果统计各风险等级居民人数。这里我在ECharts的点击事件里加了一个联动：点击某个风险等级扇区，右侧居民列表自动按该等级筛选。答辩演示的时候这个联动交互很容易给人留下印象。

3.4 角色路由与权限控制

权限控制是管理系统的门面。我采用的是路由守卫加动态侧边栏的方案：路由表按角色拆成三份，登录后根据后端返回的角色信息动态注册对应路由；每个路由的meta字段里配置了可访问角色列表，路由守卫在跳转前做校验。

// 路由守卫核心逻辑 router.beforeEach((to, from, next) => { const token = localStorage.getItem('accessToken'); const userRole = localStorage.getItem('userRole'); if (!token && to.path !== '/login') { next('/login'); return; } if (to.meta.roles && !to.meta.roles.includes(userRole)) { next('/403'); return; } next(); });

大部分毕设系统的权限控制只做到“登录才能访问”，我做到了“不同角色访问不同页面”。这对工作量来说是实打实的增量，而且不容易出错。

菜单部分也要跟着角色联动。我用一个menus计算属性，根据当前角色和路由表动态生成侧边栏菜单项。管理员看到的菜单是完整的，医护端看不到居民端的体检预约入口，居民端看不到用户管理菜单，整个系统的边界感在各个层面都一致。

3.5 联调中最容易踩的坑

前端和后端联调时我遇到过几个很有代表性的问题，这里集中说一下。

第一个是跨域问题。前端开发服务器跑在5173端口，后端跑在8080端口，直接请求肯定被浏览器拦截。我用Vite的代理配置解决，把/api前缀的请求代理到后端地址，后端接口统一使用/api前缀，开发环境和生产环境的配置很干净。千万不要在前端里写死后端IP加端口的完整地址，联调时要改的地方太多。

第二个是接口返回格式不统一。后端如果一会儿返回裸数据，一会儿返回{code: 200, data: ...}的包裹结构，前端axios拦截器就无从下手。我和后端同学约定所有接口统一返回code + message + data结构，axios响应拦截器里只处理code === 200的情况，其他情况统一弹错误提示，这样整个前端的错误处理逻辑只需要写一遍。

第三个是日期格式问题。ECharts的时间轴需要字符串格式，后端返回的时间字段可能是时间戳也可能是ISO格式字符串，不统一会导致图表X轴显示成Invalid date。我在后端统一用LocalDateTime配合@JsonFormat输出为标准字符串，前端再不做额外转换。

4. 后端接口与数据库建模：让AI分析和前端页面真正连通起来

后端是整个系统的中枢，前端页面展示的数据、AI评估要处理的特征、医护端的业务流全部汇聚在这里。毕设系统的后端不需要追求微服务，但工程结构的清晰度直接影响论文“系统设计”章节怎么写。

4.1 后端框架选型与项目结构

我选用的是Spring Boot，配合MyBatis Plus做数据访问层，MySQL 8做存储。选Spring Boot的理由非常现实：生态成熟、资料多、社区里能查到的坑和解决方案丰富。MyBatis Plus比原生MyBatis省去大量单表CRUD的XML配置，适合快速迭代。

项目结构按照分层架构组织：controller层负责接收请求和参数校验、service层负责业务逻辑和AI评估调用、mapper层负责数据库访问、entity层放实体类、dto层放接口出入参对象。这里有一个看起来基础但很重要的点：接口的入参和出参对象要独立定义，不要直接把数据库实体类暴露给前端。原因有两个——实体类里可能存在密码哈希值这类不该返回的字段，直接暴露存在安全隐患；接口需要的字段结构（比如评估报告里要组合指标数据和风险等级）通过DTO组装会更灵活。

控制器的异常处理我也做了统一封装，使用@RestControllerAdvice拦截所有业务异常和系统异常，返回标准错误结构。这样前端响应拦截器只需要解析一种失败格式，联调效率非常高。

4.2 数据库表结构设计与健康档案建模

核心数据表我最终设计了九张：用户表、健康档案表、健康指标记录表、健康评估结果表、健康建议表、预约工单表、随访记录表、公告表、角色表。

健康档案表和健康指标记录表的关系值得专门说一下。档案表保存的是居民的基本信息，比如出生日期、性别、身高、既往病史；指标记录表保存的是每次体检的动态数据，包括BMI、收缩压、舒张压、空腹血糖、总胆固醇、运动频率、测量时间和测量人员。这种设计把“相对静态的数据”和“持续产生的动态数据”分离开，查询历史趋势时直接按指标记录表的时间字段过滤，效率和数据组织都比单表混存清晰得多。

评估结果表关联了用户ID和本次评估的完整特征快照，包括模型输出的风险概率、规则判断结果、最终风险等级、评估时间。这里保存特征快照很重要：健康指标是持续变化的，如果用户之后修改了某项指标历史数据，原始评估记录还能完整回溯。这种设计的专业感在答辩时非常加分。

以下是一段简化的数据库表结构示意：

CREATE TABLE health_assessment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, profile_id BIGINT NOT NULL, age INT, bmi DECIMAL(4,1), sbp INT, dbp INT, glucose DECIMAL(4,1), cholesterol DECIMAL(4,1), exercise_freq INT, risk_probability DECIMAL(5,4), rule_risk_level VARCHAR(16), model_risk_level VARCHAR(16), final_risk_level VARCHAR(16), assessment_time DATETIME, KEY idx_user_time (user_id, assessment_time) );

bmi等字段在评估结果表里冗余存储一份快照，看似占了一点空间，换来的是评估报告页面和医护端风险列表都不需要回查指标记录表就能直接展示，查询效率很高。

4.3 JWT鉴权与接口安全

系统的登录认证我用的JWT方案，登录成功后签发访问令牌和刷新令牌。访问令牌有效期设为2小时，刷新令牌有效期7天，前端在响应拦截器里检测到访问令牌过期时，自动用刷新令牌请求新令牌，用户无感知续期。

这个双令牌机制在答辩时属于“系统安全性设计”的亮点。单纯一个长期令牌的方案容易被质疑不安全，单短期令牌会遇到频繁重新登录的体验问题，双令牌将两者分开处理，是商业化系统中的常见做法。

敏感接口的防护也做了一层：居民资料修改和删除操作，接口要求前端额外传入当前登录密码进行二次验证；医护端批量查询接口增加了@PreAuthorize注解校验角色权限，后端在路由层面就拒绝越权访问，不依赖前端的按钮隐藏。前端隐藏是最直观的安全错觉，真正的安全边界必须收口在后端。我写接口文档时反复强调了这个原则：前端权限控制只是用户体验层面的优化，后端权限校验才是安全底线。

4.4 AI服务与主系统的集成方式

AI评估在代码层面的组织，我做了一个很干净的取舍：模型推理逻辑和业务代码之间通过一个HealthEvaluationService接口隔离。

HealthEvaluationService是门面，对外提供evaluate(Long userId)方法，入参是用户ID，内部依次完成四件事：拉取用户档案和最近一次指标记录、构造特征向量并做标准化、调用规则引擎得到规则风险等级、调用模型推理得到模型风险概率和等级、融合两者得到最终风险等级、生成个性化建议列表。返回对象是AssessmentResultDTO，一次性包含评估结果和建议列表。

这个接口设计的价值在于：AI部分的实现细节被完全封装在了门面内部，业务层调用evaluate时感知不到模型推理的存在。以后想把逻辑回归换成随机森林，只需要替换内部的推理实现，接口签名和调用方一概不用动。这就是面向接口编程的意义——论文的系统设计章节可以画一张清晰的调用时序图，而代码结构本身也完全支撑这个设计。

5. 论文、PPT和答辩演示：从功能做完到毕设做完的最后一步

系统做完了，毕设只完成了一半。后面这半程才是决定成绩上限的关键：论文的层次感、答辩的演示节奏、PPT的信息密度。很多功能做得不错的同学最后栽在不会展示上，真的很可惜。

5.1 论文结构安排与工作量分布

我的论文框架分为六个大章：绪论、相关技术介绍、系统需求分析、系统总体设计、系统详细设计与实现、系统测试与总结。这个结构是学院比较认可的标准框架，关键在每章怎么写才有分量。

相关技术介绍这一章最容易被写成百科条目。我的写法是每个技术只写“为什么在这个场景下选它”和“它在本系统中承担什么职责”，比如Redis虽然没用到，我也不会强行加一章介绍Redis，论文里出现的每一个技术点都必须能在后面的章节里找到对应实现。

需求分析章节除了功能性需求，我还写了非功能性需求，包括系统响应时间要求、数据安全要求、并发用户数的初步预估。系统设计章节给出了总体的架构图、功能模块图、数据库ER图和表设计说明。详细设计章节按核心模块逐个展开，重点是AI健康评估模块的流程设计和接口设计。这样论文的工作量分布和系统的工作量分布保持一致，答辩时说到哪一章都有代码和经验对应。

5.2 答辩演示的顺序设计与数据准备

答辩演示是核心中的核心，我提前做了完整的走查并录了屏。演示顺序我设计成一条业务线：从居民端登录开始，以一个人从注册、录入健康档案、录入一次新的体检指标，到查看AI评估报告和健康建议，再到预约一次社区健康咨询结束；然后切到医护端，演示查看风险居民列表、查看某个高风险居民的详细评估报告、填写随访记录；最后切到管理员视角，展示系统用户和公告管理。

演示前一定要准备一套专门的演示数据。不要用开发阶段的脏数据，不要现场随意录入。我提前构造了一个名叫“某居民”的测试账号，包含连续六个月的健康指标记录，其中设置了一次异常血压和一次血糖偏高。这样演示趋势图时折线有波峰波谷，演示AI评估时能真实展示风险等级上升和对应建议变化，视觉效果和业务逻辑都很完整。

环境准备方面，我做了最坏情况预案：后端和前端全部运行在同一台笔记本上，数据库也放在本地，演示完全不依赖外部网络。AI模型推理本来是本地加载权重文件，不需要外网调用，整个系统是闭环运行的。我还提前录了一份完整的演示视频作为备用，万一现场环境突然崩溃，不至于无东西可讲。

5.3 PPT一页一个技术点的设计原则

答辩PPT最容易出的问题是信息过载。我见过太多同学把一段核心代码截一个长图直接贴上去，或者在一页里塞三个业务流程图，根本看不清，老师也失去追问的兴趣。

我的PPT设计原则是“一页只讲一个技术点”。核心页面大致包括：系统总览页讲清楚整体业务流程和用户角色；技术架构页展示前端、后端、数据库、AI模型推理之间的调用关系；AI功能页重点展示特征处理流程和模型权重文件的生成与加载过程，配上评估接口的时序图；可视化页面放系统截图，配合图表设计说明。每一页的信息量控制在一定范围，宁可多分几页，也不要堆叠。

PPT里我放了几处系统的真实截图，包括健康趋势折线图、AI评估报告页、医护端风险人群列表。截图能直观证明系统是跑通了的，比文字描述要有力得多。每张截图旁边都配一句“这页的功能核心是什么”的引导语，讲解时自然引出，不会在页面上停留太久。

答辩自述稿我控制在5到6分钟，核心逻辑是“我做了什么、为什么这么做、做出来效果怎样”。自述稿重点是讲清楚AI评估的设计思路和业务闭环，而不是逐条念PPT。老师后续大概率会顺着自述里提到的点来追问，所以自述稿里提到的每一个术语和结论，我都确认过自己能从原理上解释清楚。

5.4 源码归档与部署文档

源码整理的规范程度，同样会被老师注意到。我专门花了一天时间做了代码梳理：删掉所有注释掉的调试代码和临时文件，统一包名和目录结构，每个模块的入口类和核心接口补充了规范的注释，前端组件按页面、组件、组合式函数、配置四个目录归位。

最主要的一项工作是写了两个文档：一个README，写明项目简介、技术栈、启动步骤、默认账号；一个部署说明，写了从安装MySQL到导入初始化数据、启动后端、启动前端的完整过程。这两个文档在答辩前还被其他项目组的同学借用过，帮他们解决了启动环境的问题。这就是实实在在的工程素养，也是很多毕设作品缺失的部分。

6. 给后来者的几个实在建议：从代码粒度到查重风险控制

最后说几个我认为对后来者最有价值的经验。这些都是在做青湖社区健康管理系统的过程中想明白的，不一定都写在教科书里。

第一，不要为了展示AI而忽视业务完整性。答辩老师看的是系统能不能正常用起来，而不是模型准确率有多少小数位。我的AI评估模块如果脱离居民档案、指标录入、建议展示这套业务链路，单独拿出来只是一个孤立算法，价值会大打折扣。把这个逻辑想清楚，工作和论文的侧重点自然就对了。

第二，代码量不是衡量工作量的唯一标准，工程规范性才是。一个结构清晰、命名规范、异常处理完整的“小系统”，比一个功能堆砌但代码混乱的“大系统”更能打动老师。我的控制器层平均每层代码量不多，但每个方法都做了参数校验和异常处理，这比在代码里复制粘贴十遍相同的逻辑要有说服力得多。

第三，建议模板库要单独管理，不要硬编码在Java字符串里。我把健康建议和风险等级的映射关系放在数据库表里，前端和后端都通过代码值来关联。这样后期调整建议文案，只需要改数据库数据，不需要重新编译部署，也方便在管理后台拓展建议库内容。

第四，查重风险要提前关注。论文的相关技术介绍和参考文献部分是最容易被重复率拉爆的区域。我写技术介绍时全部用自己的话重组，不直接复制官方文档的表述；参考文献的格式统一，每篇都确认自己在正文中有真实引用；重点章节的原创表达做了二次梳理。查重是规则问题，花时间调整措辞比事后降重效率高得多。

最后说说我个人的体会：青湖社区健康管理系统这套流程走下来，收获最大的并不是“我会用Vue和Spring Boot”这种技术清单，而是完整经历了一个从发现问题、设计解决方案、编码实现、验证效果、整理交付物的全过程。这个经验在以后的任何开发任务里都会持续起作用——做系统做论文都一样，先想清楚到底要解决什么问题，再决定怎么做，后面的事情自然顺畅。