簡(jiǎn)介這是一套基于 Vue 與 SpringBoot 構(gòu)建的智慧醫(yī)院就診系統(tǒng)完整畢業(yè)設(shè)計(jì)資源包面向醫(yī)療信息化方向的高校學(xué)生、Java 全棧開發(fā)者及醫(yī)院信息系統(tǒng)技術(shù)人員。系統(tǒng)覆蓋預(yù)約掛號(hào)、智能問(wèn)診、醫(yī)生工作臺(tái)、科室排班、患者服務(wù)、系統(tǒng)日志與權(quán)限管理等核心模塊并將 DeepSeek 大語(yǔ)言模型融入診療流程創(chuàng)新實(shí)現(xiàn)癥狀自查、結(jié)構(gòu)化電子病歷生成與臨床建議輔助有助于減少醫(yī)生非臨床工作負(fù)擔(dān)。資源共 710 個(gè)文件以 Java 源碼、Vue 組件、JavaScript 腳本、CSS 樣式、SQL 數(shù)據(jù)庫(kù)腳本及說(shuō)明文檔為主另含圖片和動(dòng)態(tài)演示素材壓縮包約 10.08MB目錄結(jié)構(gòu)清晰便于按模塊閱讀和二次開發(fā)。當(dāng)前已有 243 人學(xué)習(xí)適合用于理解醫(yī)院就診業(yè)務(wù)閉環(huán)也可作為畢業(yè)設(shè)計(jì)答辯演示、功能擴(kuò)展或代碼重構(gòu)的參考基礎(chǔ)。1. 把 VueSpringBoot 就診系統(tǒng)講透DeepSeek 癥狀自查與電子病歷生成的落地方案做智慧醫(yī)院就診系統(tǒng)最難的不是掛號(hào)、排隊(duì)叫號(hào)那些常規(guī)模塊而是“怎么讓系統(tǒng)看起來(lái)真的懂醫(yī)療”。大部分畢業(yè)設(shè)計(jì)開源項(xiàng)目止步于 CRUD 增刪改查界面再華麗業(yè)務(wù)邏輯還是“查表 狀態(tài)機(jī)”。這套基于 Vue 3 SpringBoot 3 的就診系統(tǒng)源碼真正不一樣的地方在于接入了 DeepSeek 大語(yǔ)言模型把癥狀自查、結(jié)構(gòu)化電子病歷生成、臨床建議輔助這三件事做成了可運(yùn)行的功能而不是 PPT 上的概念。我拆完整個(gè)前后端代碼和數(shù)據(jù)庫(kù)腳本后確認(rèn)它適合兩類人一類是正在做畢設(shè)但不想只交“管理系統(tǒng)”的學(xué)生另一類是準(zhǔn)備把 LLM 塞進(jìn)傳統(tǒng)業(yè)務(wù)系統(tǒng)、想少走彎路的 Java 工程師。你能直接看到模型接口怎么封裝、業(yè)務(wù)層怎么兜底、前端流式輸出怎么接這比從頭讀文檔高效太多。整套系統(tǒng)覆蓋了患者端、醫(yī)生端和管理員端三個(gè)角色核心鏈路是“患者描述癥狀 → DeepSeek 返回候選疾病和問(wèn)診建議 → 醫(yī)生選擇生成結(jié)構(gòu)化電子病歷 → 系統(tǒng)給出臨床建議”。源碼里帶有完整數(shù)據(jù)庫(kù)建表腳本MySQL包含用戶表、預(yù)約表、病歷表、藥品表、科室表等視圖和存儲(chǔ)過(guò)程也有幾個(gè)能直接跑通預(yù)約掛號(hào)、門診就診、病歷歸檔的閉環(huán)。我前后花了一個(gè)多星期把每個(gè)模塊從“能跑”調(diào)試到“能講”下面這篇筆記按資源是什么、結(jié)構(gòu)怎么拆、DeepSeek 怎么接、病歷和癥狀自查怎么落地、坑在哪、怎么把系統(tǒng)做亮這幾個(gè)順序把這份資源徹底講清楚。2. 系統(tǒng)架構(gòu)與代碼包結(jié)構(gòu)先看清前后端邊界和 LLM 的介入位置2.1 三層架構(gòu)里的模型調(diào)用設(shè)計(jì)為什么是 Vue3 SpringBoot 而不是單體模板引擎?zhèn)鹘y(tǒng)就診系統(tǒng)常做在 JSP Servlet 或 Thymeleaf 模板里頁(yè)面跳來(lái)跳去前后端耦合嚴(yán)重。這套源碼采用前后端分離SpringBoot 提供 RESTful APIVue 3 通過(guò) axios 發(fā)起請(qǐng)求。這樣設(shè)計(jì)不是圖“時(shí)髦”而是因?yàn)榻尤?DeepSeek 后前端需要處理流式輸出和異步狀態(tài)模板引擎在這種交互下會(huì)非常別扭。后端模塊我拆開看主要分這幾塊authentication基于 JWT 的登錄鑒權(quán)醫(yī)生和患者走不同角色攔截器business掛號(hào)預(yù)約、分診、收費(fèi)、藥房等傳統(tǒng)模塊aiDeepSeek 調(diào)用封裝包括 prompt 構(gòu)建、響應(yīng)解析、異常兜底medical病歷管理、診斷建議、檢驗(yàn)報(bào)告的結(jié)構(gòu)化存儲(chǔ)單看模塊劃分不稀奇關(guān)鍵在于 ai 模塊的“隔離性”。項(xiàng)目把大模型調(diào)用單獨(dú)放在一個(gè) service 里前端所有 AI 功能都經(jīng)由/api/ai/*統(tǒng)一入口進(jìn)入不進(jìn)業(yè)務(wù)表直接寫數(shù)據(jù)庫(kù)。這樣做有實(shí)際意義模型輸出是不可控的萬(wàn)一某次返回了非 JSON 內(nèi)容你不會(huì)把臟數(shù)據(jù)污染到病歷表里前端也可以根據(jù)接口狀態(tài)單獨(dú)展示“AI 生成中”的 Loading而不會(huì)拖慢掛號(hào)接口。前端項(xiàng)目結(jié)構(gòu)里重點(diǎn)看src/api和src/views/ai兩個(gè)目錄。前者是接口統(tǒng)一封裝層后者是癥狀自查和病歷生成的前端交互頁(yè)面。Vue 3 用組合式 API 寫邏輯狀態(tài)管理只用了一個(gè)極簡(jiǎn)的 pinia store 來(lái)存用戶信息和 JWT沒(méi)有過(guò)度設(shè)計(jì)。提示資源里自帶的 README 有早期版本說(shuō)明里面“引入 DeepSeek”這幾個(gè)字實(shí)際實(shí)現(xiàn)比說(shuō)明文檔多了不少細(xì)節(jié)建議以源碼實(shí)際行為為準(zhǔn)。2.2 數(shù)據(jù)庫(kù)表設(shè)計(jì)病歷表、用戶表、癥狀表如何支撐“結(jié)構(gòu)化”需求結(jié)構(gòu)化電子病歷的“結(jié)構(gòu)化”不是指前端把文本塞進(jìn)textarea就叫結(jié)構(gòu)化而是數(shù)據(jù)庫(kù)里要有明確的字段承接不同粒度的醫(yī)療數(shù)據(jù)。打開sql目錄里的建表腳本核心表有這么幾張user患者和醫(yī)生共用一張表用role字段區(qū)分存姓名、手機(jī)號(hào)、加密后的登錄密碼department科室表關(guān)聯(lián)醫(yī)生排班appointment預(yù)約掛號(hào)表包含時(shí)間槽和就診狀態(tài)medical_record病歷主表涵蓋主訴、現(xiàn)病史、既往史、初步診斷、處理建議和開藥信息symptom_check癥狀自查記錄表存用戶輸入的自然語(yǔ)言癥狀文本和模型返回的結(jié)構(gòu)化結(jié)果JSON 字段ai_logAI 調(diào)用日志表記每次請(qǐng)求的輸入 token、輸出 token 和耗時(shí)這里的symptom_check和ai_log兩張表是這套資源區(qū)別于普通管理系統(tǒng)的地方。symptom_check表里有一個(gè)result_json字段類型用了TEXT專門承接 DeepSeek 返回的嵌套 JSON 數(shù)據(jù)——包括候選疾病列表、匹配度評(píng)分、建議就診科室。這不是偷懶的做法因?yàn)槟Ｐ洼敵鼋Y(jié)構(gòu)不固定用TEXT存 JSON 比強(qiáng)行拆幾十個(gè)字段更現(xiàn)實(shí)讀取后再用 Jackson 解析成 Java 對(duì)象。ai_log表值得一提查問(wèn)題的時(shí)候你能回看每一次模型調(diào)用哪些 prompt 導(dǎo)致了 token 浪費(fèi)、哪些輸入讓模型回復(fù)了非預(yù)期內(nèi)容一目了然。這是從業(yè)者的習(xí)慣很多畢設(shè)根本沒(méi)有這個(gè)表。2.3 核心參數(shù)配置application.yml 里的模型與數(shù)據(jù)庫(kù)連接解讀后端src/main/resources/application.yml里除了常規(guī)的 MySQL 數(shù)據(jù)源、Redis 配置、JWT 密鑰還有一個(gè)獨(dú)立的deepseek配置段deepseek: api-key: ${DEEPSEEK_API_KEY:your-key-here} base-url: https://api.deepseek.com model: deepseek-chat max-tokens: 2048 temperature: 0.3 timeout: 60這段配置的意思是API Key 通過(guò)環(huán)境變量DEEPSEEK_API_KEY注入避免把密鑰寫死在代碼里base-url是 DeepSeek 官方接口地址model指定使用deepseek-chat這是 DeepSeek 對(duì)外提供的通用對(duì)話模型支持顯式上下文max-tokens控制單次返回的最大 token 數(shù)temperature0.3是為了讓輸出更穩(wěn)定、更少隨機(jī)。醫(yī)療場(chǎng)景不像寫詩(shī)不需要高溫度值溫度調(diào)低一點(diǎn)模型輸出的可預(yù)測(cè)性高很多timeout設(shè)成 60 秒是考慮到長(zhǎng)文本病歷生成時(shí)模型推理時(shí)間可能超過(guò)普通 HTTP 請(qǐng)求的默認(rèn)超時(shí)。數(shù)據(jù)庫(kù)連接部分你根據(jù)自己的 MySQL 版本改url、username、password就行。資源自帶的是 MySQL 5.7 適用的建表語(yǔ)句如果要跑在 MySQL 8.0注意默認(rèn)密碼插件不同驅(qū)動(dòng)版本選對(duì)即可。3. DeepSeek 接入實(shí)戰(zhàn)從 HTTP 封裝到流式輸出的完整鏈路3.1 AI 接口封裝用 WebClient 調(diào) DeepSeek Chat Completion 接口后端 AI 模塊核心代碼是封裝了 DeepSeek 的 Chat Completion 接口。這里不用 RestTemplate因?yàn)樗峭阶枞Ｐ透卟l(fā)場(chǎng)景下容易吃滿 Tomcat 線程。SpringBoot 3 自帶的 WebClient 走響應(yīng)式鏈路單次調(diào)用不阻塞業(yè)務(wù)線程。下面這段是資源里DeepSeekClient.java的核心邏輯精簡(jiǎn)版Service public class DeepSeekClient { private final WebClient webClient; private final DeepSeekProperties properties; public DeepSeekClient(DeepSeekProperties properties) { this.properties properties; this.webClient WebClient.builder() .baseUrl(properties.getBaseUrl()) .defaultHeader(Authorization, Bearer properties.getApiKey()) .defaultHeader(Content-Type, application/json) .codecs(configurer - configurer.defaultCodecs().maxInMemorySize(10 * 1024 * 1024)) .build(); } public String chatCompletion(ListChatMessage messages) { MapString, Object requestBody new HashMap(); requestBody.put(model, properties.getModel()); requestBody.put(messages, messages); requestBody.put(temperature, properties.getTemperature()); requestBody.put(max_tokens, properties.getMaxTokens()); requestBody.put(stream, false); return webClient.post() .uri(/chat/completions) .bodyValue(requestBody) .retrieve() .bodyToMono(String.class) .timeout(Duration.ofSeconds(properties.getTimeout())) .block(); } }邏輯說(shuō)明WebClient在構(gòu)造時(shí)讀配置里的地址和 Key每次調(diào)用走POST /chat/completions。關(guān)鍵參數(shù)messages是數(shù)組每個(gè)數(shù)組元素帶rolesystem / user和content這是 DeepSeek 接口識(shí)別對(duì)話角色的標(biāo)準(zhǔn)方式。system角色用于設(shè)定 AI 行為user角色用于傳用戶輸入。streamfalse表示非流式返回整體把模型回答一次性拿回來(lái)適合后期解析 JSON如果做前端打字機(jī)效果需要改用流式streamtrue返回 SSE并在前端用fetch讀ReadableStream。參數(shù)說(shuō)明maxInMemorySize別小看不配的話默認(rèn) 256KB病歷生成動(dòng)輒幾千 token 很容易超限報(bào)錯(cuò)這也是一個(gè)典型坑。block()方法在 WebClient 里是同步等待好在timeout兜底了最長(zhǎng)等待時(shí)間。3.2 Prompt 構(gòu)建與業(yè)務(wù)解析讓模型按 JSON Schema 返回調(diào)通接口只是第一步真正難的是讓模型輸出“可解析的”結(jié)構(gòu)化內(nèi)容。源碼里的PromptBuilder.java把整個(gè) prompt 模板和 JSON Schema 固定下來(lái)我看完之后強(qiáng)烈建議你直接抄這份模板而不是自己現(xiàn)造。public String buildSymptomCheckPrompt(String userInput) { return 你是一名具有豐富臨床經(jīng)驗(yàn)的導(dǎo)診醫(yī)生。 用戶的癥狀描述如下 userInput 請(qǐng)嚴(yán)格按以下 JSON 格式回復(fù)不要輸出任何多余文字 {\candidate_diseases\: [{\disease_name\: \疾病名稱\, \probability\: 0.85, \department\: \建議就診科室\}], \questions\: [\為確認(rèn)診斷你需要追問(wèn)患者的問(wèn)題1\, \追問(wèn)問(wèn)題2\], \urgent\: false}; }邏輯說(shuō)明system提示詞固定了“醫(yī)生”角色user內(nèi)容是對(duì)用戶輸入的封裝。JSON Schema在 prompt 里的作用是告訴模型輸出結(jié)構(gòu)——候選疾病數(shù)組帶疾病名、概率、科室追問(wèn)問(wèn)題數(shù)組以及一個(gè)urgent布爾值表示是否需要立即急診。這個(gè)結(jié)構(gòu)要和前端 Vue 頁(yè)面里的v-for列表相對(duì)應(yīng)。參數(shù)說(shuō)明probability用 0-1 小數(shù)方便前端渲染百分比urgent字段直接驅(qū)動(dòng)分診邏輯——為 true 時(shí)界面跳出紅色警示條。candidate_diseases數(shù)組長(zhǎng)度最好限制 3 到 5 個(gè)太多會(huì)讓患者焦慮太少參考價(jià)值低。解析端用 Jackson 把模型返回字符串反序列化成SymptomCheckResult對(duì)象如果解析失敗則走兜底邏輯。兜底邏輯很重要模型偶爾會(huì)輸出純文本或 Markdown直接轉(zhuǎn)對(duì)象會(huì)拋異常項(xiàng)目里專門寫了一個(gè)fallbackParse()把文本按回車拆成臨時(shí)疾病描述保證用戶永遠(yuǎn)看得到反饋而不是報(bào)錯(cuò)白屏。3.3 流式輸出的可選實(shí)現(xiàn)SSE 讓病歷生成像“打字機(jī)”一樣展示資源里的非流式實(shí)現(xiàn)已經(jīng)夠完成畢設(shè)但如果你想拔高亮點(diǎn)可以把病歷生成改成走 SSEServer-Sent Events。很多現(xiàn)場(chǎng)演示翻車就是因?yàn)辄c(diǎn)擊“生成病歷”后界面白等 10 秒沒(méi)反饋評(píng)委以為系統(tǒng)死掉了。改成流式以后用戶能實(shí)時(shí)看到模型吐字體驗(yàn)完全不同。后端在DeepSeekClient里加一個(gè)流式方法走WebClient的retrieve().bodyToFlux(String.class)響應(yīng)體是text/event-stream格式前端用原生EventSource或fetch讀流。核心改動(dòng)就兩點(diǎn)請(qǐng)求體里streamtrue以及前端不再等完整 JSON而是每收到一個(gè)data:塊就 append 到頁(yè)面。但這有個(gè)代價(jià)——流式輸出沒(méi)法保證一次返回完整 JSON所以自動(dòng)生成結(jié)構(gòu)化病歷不能直接用流式結(jié)果入庫(kù)比較合理的做法是“流式展示 完整返回入庫(kù)”雙通道前端展示用流式接口落庫(kù)用非流式接口二次調(diào)用。資源里非流式版本已經(jīng)能跑通全流程我建議先跑通再去改流式。4. 癥狀自查與結(jié)構(gòu)化電子病歷生成把模型輸出變成業(yè)務(wù)資產(chǎn)4.1 癥狀自查模塊前端輸入與后端結(jié)果剪裁前端頁(yè)面SymptomCheck.vue的思路很簡(jiǎn)單一個(gè)多行文本輸入框用戶用自然語(yǔ)言描述癥狀比如“最近三天頭暈、頭痛、惡心伴隨腹瀉”提交后后端把這段文本連同病歷上下文拼進(jìn) prompt發(fā)給 DeepSeek返回候選疾病概率列表和追問(wèn)問(wèn)題。頁(yè)面核心代碼如下template div classsymptom-check el-input typetextarea v-modelsymptomText placeholder請(qǐng)描述你的癥狀比如頭痛、發(fā)燒、咳嗽持續(xù)兩天 :rows4 / el-button typeprimary :loadingloading clicksubmitSymptom {{ loading ? AI 分析中… : 開始自查 }} /el-button div v-ifcheckResult classresult-panel div v-fordisease in checkResult.candidate_diseases :keydisease.disease_name span{{ disease.disease_name }}/span span{{ Math.round(disease.probability * 100) }}%/span el-tag{{ disease.department }}/el-tag /div /div /div /template script setup import { ref } from vue import { checkSymptom } from /api/ai const symptomText ref() const loading ref(false) const checkResult ref(null) async function submitSymptom() { loading.value true try { const res await checkSymptom({ text: symptomText.value }) checkResult.value res.data } finally { loading.value false } } /script邏輯說(shuō)明checkSymptom調(diào)用后端/api/ai/symptom-check后端返回的對(duì)象里有candidate_diseases、questions、urgent三個(gè)字段。模板里用v-for循環(huán)候選疾病并展示概率和科室如果urgent為 true再加一條el-alert提示緊急情況。這個(gè)頁(yè)面在演示時(shí)非常出效果尤其是概率數(shù)字滾動(dòng)出現(xiàn)的時(shí)候。參數(shù)說(shuō)明:loading在請(qǐng)求期間鎖住按鈕防止重復(fù)提交接口層要加錯(cuò)誤處理因?yàn)?DeepSeek 偶爾超時(shí)超時(shí)后給用戶提示“網(wǎng)絡(luò)不穩(wěn)定請(qǐng)重試”。千萬(wàn)不要把模型超時(shí)錯(cuò)誤直接透?jìng)鞯浇缑婵雌饋?lái)很不專業(yè)。4.2 結(jié)構(gòu)化電子病歷從聽(tīng)診記錄到字段落庫(kù)醫(yī)生端“生成病歷”功能的核心價(jià)值是在醫(yī)生填完主訴和現(xiàn)病史后系統(tǒng)能幫他把這些自然語(yǔ)言文本自動(dòng)擴(kuò)展成一份可查詢的病歷草稿。源碼里AutoGenerateMedicalRecord()這個(gè)服務(wù)的邏輯是拼一個(gè)要求模型“生成結(jié)構(gòu)化 SOAP 格式病歷”的 prompt然后把模型輸出按{subjective: 主訴, objective: 體格檢查, assessment: 診斷依據(jù), plan: 治療建議}的 JSON 結(jié)構(gòu)拆開落到medical_record表對(duì)應(yīng)的字段里。需要注意模型生成的內(nèi)容再完整也不能直接蓋過(guò)醫(yī)生手寫結(jié)論。資源設(shè)計(jì)里有個(gè)很聰明的點(diǎn)AI 生成的內(nèi)容只作為“草稿”預(yù)填到表單醫(yī)生最終要點(diǎn)擊“確認(rèn)保存”后才會(huì)落庫(kù)。這避免了“AI 寫的診斷被當(dāng)成醫(yī)生確診”這種在醫(yī)療場(chǎng)景里不可接受的錯(cuò)誤。如果你在答辯時(shí)被問(wèn)到“AI 出錯(cuò)怎么辦”這個(gè)設(shè)計(jì)就是你最好的回答模型只是輔助錄入權(quán)威性在醫(yī)生手里。落庫(kù)后病歷數(shù)據(jù)會(huì)被整理成record_view視圖關(guān)聯(lián)患者檔案、處方、檢查單前端“歷史病歷”頁(yè)面直接查這些關(guān)聯(lián)表還能做關(guān)鍵詞搜索。這套數(shù)據(jù)模型雖然不是國(guó)標(biāo)級(jí)別的結(jié)構(gòu)化但足以支撐完整的業(yè)務(wù)演示。4.3 AI 日志與 token 成本控制別讓演示崩在余額上面一次癥狀自查平均消耗 300-500 token一次完整病歷生成可能消耗 1000-2000 token。如果你把 demo 演示沓三五次賬戶余額就肉眼可見(jiàn)地往下掉。項(xiàng)目里的ai_log表除了記內(nèi)容還記錄每次調(diào)用消耗的 token 數(shù)和耗時(shí)。我建議在調(diào)通后把max-tokens從 2048 降到 1024并給 prompt 里加一句“控制在 300 字以內(nèi)”對(duì)畢設(shè)演示完全夠用成本直接砍半。另外要警惕循環(huán)調(diào)用。后端接口沒(méi)有做 Redis 限流如果被頻繁刷請(qǐng)求AI 費(fèi)用會(huì)瘋漲。準(zhǔn)備在公網(wǎng)演示時(shí)一定要在網(wǎng)關(guān)或過(guò)濾器層做一個(gè)基于用戶 ID 的簡(jiǎn)單限流同一個(gè)用戶一分鐘最多調(diào)用 10 次 AI 接口。代碼量不大但能防止你演示現(xiàn)場(chǎng)被無(wú)意識(shí) F5 刷爆。5. 三個(gè)必踩的坑和我的排查記錄從接口 401 到 JSON 解析失敗5.1 現(xiàn)象一DeepSeek 接口一直返回 401 認(rèn)證失敗第一次啟動(dòng)項(xiàng)目ai_log表里出現(xiàn)一堆 401 錯(cuò)誤。排查后發(fā)現(xiàn)是application.yml里${DEEPSEEK_API_KEY:your-key-here}這個(gè)配置的問(wèn)題——本地環(huán)境變量沒(méi)設(shè)配置直接讀成了字面量your-key-here密鑰當(dāng)然無(wú)效。解決方法是確保啟動(dòng)腳本中export DEEPSEEK_API_KEYsk-xxxx或者用 IDE 環(huán)境變量面板注入。血淚經(jīng)驗(yàn)寫配置時(shí)別把假 Key 放在默認(rèn)值位置寧可留空并在啟動(dòng)時(shí)校驗(yàn)。5.2 現(xiàn)象二病歷生成偶爾出現(xiàn)“半截 JSON”導(dǎo)致前端白屏有一次演示點(diǎn)擊生成病歷后前端一直轉(zhuǎn)圈控制臺(tái)報(bào)JSON parse error。原因是請(qǐng)求超時(shí)設(shè)置太短模型生成到一半被timeout掐斷返回了不完整的 JSON。解決方法是把timeout從 30 秒提高到 60 秒并在后端加一個(gè)“解析失敗→返回友好提示”的兜底。從那以后我每次改 prompt 模板都強(qiáng)制跑一遍“長(zhǎng)文本 短超時(shí)”兩個(gè)邊界用例。5.3 現(xiàn)象三前端 axios 拿不到 AI 接口的響應(yīng)頭頁(yè)面可以通過(guò)api/ai/*正常拿數(shù)據(jù)但用CrossOrigin配的 CORS 攔不住自定義 header。排查發(fā)現(xiàn)是網(wǎng)關(guān)層沒(méi)有把Authorization頭透?jìng)鹘o前端跨域預(yù)檢請(qǐng)求。解決方式是使用 Spring 官方CorsFilter配置顯式允許Authorization和Content-Type兩個(gè)請(qǐng)求頭。如果你用的是網(wǎng)關(guān)記得在路由配置里把這兩個(gè)頭加入 allowedHeaders。5.4 現(xiàn)象四JWT 在 Redis 里過(guò)期后用戶下次操作仍顯示“登錄過(guò)期”因?yàn)橘Y源里 JWT 沒(méi)有接 Redis 統(tǒng)一校驗(yàn)。用戶已登錄期間如果 Redis 重啟token 驗(yàn)證照樣通過(guò)因?yàn)?JWT 是無(wú)狀態(tài)簽名服務(wù)端不存儲(chǔ)會(huì)話。解決方法是把 Redis 緩存放進(jìn) JWT 攔截器里做二次校驗(yàn)——查user_session表token 對(duì)應(yīng)記錄為空直接返回 401。這是一個(gè)在答辯演示時(shí)非常容易出丑的坑務(wù)必提前處理。5.5 現(xiàn)象五MySQL 5.7 建 SQL 跑在 MySQL 8.0 時(shí)報(bào)時(shí)區(qū)錯(cuò)誤這個(gè)問(wèn)題是環(huán)境差異不是代碼問(wèn)題。MySQL 8.0 默認(rèn)時(shí)區(qū)與 5.7 不同啟動(dòng)報(bào)The server time zone value xxx is unrecognized。解決方法是連接串加上serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue。也就是每次拆這種帶數(shù)據(jù)庫(kù)的源碼第一件事先看 MySQL 版本和驅(qū)動(dòng)版本是否匹配。6. 把這個(gè)系統(tǒng)做亮的三個(gè)進(jìn)階技巧答辯演示的臨門一腳6.1 用“追問(wèn)閉環(huán)”讓癥狀自查更有醫(yī)療邏輯原始資源的癥狀自查是單輪問(wèn)答輸入癥狀 → 返回結(jié)果。我后來(lái)自己加了一個(gè)追問(wèn)閉環(huán)每當(dāng)返回候選疾病時(shí)同時(shí)把questions數(shù)組展示在界面底部讓用戶再回答一輪“頭痛持續(xù)多久了有沒(méi)有嘔吐”把第二次問(wèn)答的結(jié)果拼進(jìn)初始文本再次調(diào)用模型。這樣一來(lái)交互深度明顯提升答辯時(shí)你能現(xiàn)場(chǎng)演示“AI 主動(dòng)向用戶提問(wèn)”這比一次輸?shù)降椎姆桨父荏w現(xiàn)業(yè)務(wù)思考。實(shí)現(xiàn)起來(lái)不難前端維護(hù)一個(gè)conversationHistory用數(shù)組存{role: user | assistant, content}提交時(shí)把所有聊天記錄一起傳給后端后端全部塞進(jìn)messages。模型會(huì)基于上下文修正診斷比每次只傳一句話準(zhǔn)確得多。6.2 通過(guò)ai_log做“費(fèi)用看板”展示系統(tǒng)可觀測(cè)性把a(bǔ)i_log表里的token_count和cost_estimate聚合統(tǒng)計(jì)在管理員頁(yè)面做一個(gè)簡(jiǎn)單的折線圖——按天展示 AI 調(diào)用次數(shù)和 token 消耗。這一步代碼量不大但答辯時(shí)你告訴評(píng)委“系統(tǒng)能定量觀測(cè) AI 資源消耗”瞬間拉開和普通管理系統(tǒng)的差距。具體做法很直接后端寫一個(gè)/api/ai/dashboard接口SQL 里GROUP BY DATE(create_time)并按 token 求和前端用 ECharts 畫折線。既然資源里已經(jīng)存了日志這個(gè)功能只是三小時(shí)工作量。6.3 用 SSE 把病歷生成的“打字機(jī)”效果做出來(lái)前面提過(guò)流式輸出的價(jià)值。具體落地時(shí)前端不要用EventSource因?yàn)?DeepSeek 接口需要自定義 Header。用原生fetch發(fā) POST 請(qǐng)求讀取response.body.getReader()每次讀到一段字符就 append 到目標(biāo)div。核心代碼段如下const response await fetch(/api/ai/medical-record/stream, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ caseId }) }) const reader response.body.getReader() const decoder new TextDecoder() while (true) { const { done, value } await reader.read() if (done) break contentText.value decoder.decode(value, { stream: true }) }邏輯說(shuō)明reader.read()每次返回一個(gè) chunk用TextDecoder轉(zhuǎn)成字符串后直接追加。這樣頁(yè)面會(huì)看到逐字輸出雖然不是逐 token 平滑打字但也有明顯的流式效果。后端在流式接口里要注意關(guān)閉響應(yīng)緩沖否則前置的壓縮或緩沖組件會(huì)讓流式失效這是一個(gè)反復(fù)出現(xiàn)的坑。每當(dāng)我拆到類似的 AI 業(yè)務(wù)系統(tǒng)我最先確認(rèn)的就是三件事模型輸出有沒(méi)有留痕日志表、失敗時(shí)用戶看到什么兜底文案、以及數(shù)據(jù)是否被不可控內(nèi)容污染。從那以后我跑這套系統(tǒng)第一件事是拿“長(zhǎng)文本癥狀 短超時(shí)”和“空輸入”兩個(gè)用例把 AI 接口打一遍確認(rèn)不會(huì)白屏然后才敢正式演示。這份資源最大的價(jià)值不只是能跑通的代碼而是把大模型怎么融入傳統(tǒng)業(yè)務(wù)系統(tǒng)的工程思路完整演示了一遍。希望這套源碼和你照著做的過(guò)程能幫你順利通關(guān)畢業(yè)答辯也能讓你以后做類似功能時(shí)少踩我踩過(guò)的那些坑——用它當(dāng)骨架把業(yè)務(wù)細(xì)節(jié)補(bǔ)成你自己的作品祝你好運(yùn)。本文還有配套的精品資源點(diǎn)擊獲取