每年开学季总能在校园里看到一群人举着手机原地转圈新生分不清东南西北送孩子报到的家长反复问“图书馆往哪走”校外访客看着导航 App 里的蓝色路线发呆。不是地图错了而是地图只会告诉你“沿主路走 300 米”不会告诉你“一食堂旁边的白色圆楼就是健身中心”。这正是“AI 智能校园导航系统”这类毕业设计想解决的问题。最近有不少同学在做 SpringBoot 微信小程序 AI 大模型的校园导航项目标题里经常带“源码、LW、PPT、讲解”这些关键词。这个组合听起来很新潮但真正做完之后会发现一个规律让项目出彩的不是接入了多强的大模型而是你能不能把“一句话问路”变成一条看得见、走得通的完整路线。大模型在这里是翻译官不是地图本身。这个判断决定了整个项目的边界、工期和答辩思路。1. 先想清楚这个系统真正解决的是哪一类“导航问题”1.1 商业导航解决不了校园里的“模糊问路”市面上的高德、腾讯、百度地图核心服务对象是车和城市道路所以它们的模型是“门牌号 — 道路 — 导航指令”。到了校园里这套模型会出问题很多建筑没有门牌号只有“东门”“三食堂”“理科楼”这类校园内部叫法。新生的问法不是“从线段 AB 到线段 CD”而是“我想去图书馆从东门进怎么走”。跨楼栋、楼内楼层切换、楼与楼之间的连廊商业地图如果没收录就只剩“到达目标地点附近”剩下的路要自己找。校园导航要做的本质上不是“重新造一个地图”而是把校园自己的语义地图建起来。这个问题的核心不是坐标精度而是“人话”到“结构化路线数据”之间的转换。而这种转换正好是大模型的强项。1.2 大模型在这里不是“生成路线”而是“理解人话”很多同学一听到“AI 大模型 导航”下意识觉得路线是大模型算出来的。这个理解是危险的。路线计算是确定性算法问题用 Dijkstra 或 A* 就能稳定完成结果可复现、可测试、答辩时能讲清楚。而大模型的价值集中在语言这一层用户说“我从东门进来想先还书再去食堂”系统要能抽取出起点是“东门”途径点是“图书馆/还书处”终点是“食堂”。用户说“离这里最近的咖啡店在哪”系统要结合当前位置和目标类别做检索。用户说“我就在体育馆附近”系统要能匹配到“体育馆”这个 POI而不是去理解“体育馆”这三个字的物理含义。所以在设计上可以这样拆路线规划走确定性算法语言理解走大模型二者通过一层“意图 JSON”对接。大模型输出结构化结果后端拿到结果再做 POI 匹配、路径计算和结果组装。这样既利用了 LLM 的语义能力也保证了核心流程不失控。1.3 一个贯穿全程的主判断做这类毕设项目始终要记住一句话“缺了大模型系统还要能跑缺了路线规划系统就什么都没有。”大模型是增强层不是地基。地基是校园 POI 数据、路网数据、路径算法和小程序交互。把地基做稳再谈 AI 亮点项目才不容易在答辩时被一个问题问倒你的大模型不可用了怎么办2. 技术选型每种选择都要对得上答辩逻辑2.1 为什么是 SpringBoot而不是更重的方案校园导航系统的数据量和并发量都不大高峰也就是迎新季那几天。用 SpringBoot 做单体应用完全够用而且生态成熟、资料多、报错好查答辩时也容易解释。不要为了“显得有技术含量”硬拆微服务、强上消息队列、引入分布式事务。这些技术本身没错但对这个选题来说收益低、复杂度高、答辩容易翻车。SpringBoot 在这个项目里承担的职责很清晰提供 REST API供小程序端调用。做用户登录态校验。封装 POI 检索、路径计算、对话意图解析等核心服务。统一处理异常、日志和参数校验。如果后续想加分再加 Redis 缓存热门路线、加日志切面、加接口限流都属于“可选增强”而不是一开始就必须有的模块。2.2 为什么是微信小程序校园导航的使用场景高度匹配微信小程序访客扫码就能用不需要下载 App学生本来就在微信里用完即走。小程序端主要做三件事展示地图、画路线、提供聊天式问路入口。微信小程序还内置了地图组件map支持 markers 标记点和 polyline 折线画一条引导路线很直接。这个组件虽然不能和完整地图 SDK 比但对校园级导航足够。需要留意的是小程序上线有类目和域名审核要求如果只做毕业设计演示用微信开发者工具加测试号就能跑通不一定非要走完整发布流程。2.3 为什么大模型用 API 而不是自己训练这是选型里最需要克制的地方。自训练模型、微调大模型对本科毕业设计来说周期太长、成本太高、设备要求也不现实。合理做法是调用已有大模型 API或者本地部署一个开源小模型兜底。方案优点缺点适合场景云端大模型 API对话质量高、接入快、几乎不用维护需要联网、有调用成本、需要管理 Key功能演示、正常使用Ollama 本地部署开源模型免费、离线可用、答辩时不怕断网需要一定显存、效果弱于大厂 API演示兜底、离线环境自己训练或微调听起来“技术含量高”周期长、数据难准备、效果不稳定论文有专门算法方向才建议做最稳妥的组合是默认走云端 API同时保留一个本地规则匹配或本地模型兜底。具体选哪个平台看当时的市场情况和免费额度不要写死“某个平台一定最好”。答辩时只要能说清楚“为什么这样选、各自边界在哪里”就比盲目堆技术得分高。2.4 技术栈总表层级技术职责前端微信小程序 map 组件地图展示、路线绘制、聊天式问路后端SpringBoot接口服务、登录态、业务编排数据库MySQLPOI 表、路网表、用户表、问路记录表AI 接入大模型 API / Ollama意图解析、多轮澄清、可选的知识问答认证wx.login JWT小程序用户身份识别这个组合的特点是“每个环节都能讲清楚”。答辩时老师问“为什么用这个技术”你都能给出一个具体理由而不是回答“大家都这么用”。3. 最小闭环从“一句问路”到“一条路线”3.1 数据库先想清楚POI 和路网才是地基AI 再强也要有数据支撑。整个项目最花时间的数据有两块POI兴趣点和路网。POI 表记录校园内的关键地点CREATE TABLE poi ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) COMMENT 标准名称如图书馆, alias VARCHAR(255) COMMENT 别名如lib、Chrissy、新图, type VARCHAR(50) COMMENT 分类图书馆、食堂、教学楼、宿舍、校门, longitude DECIMAL(10,6), latitude DECIMAL(10,6), floor INT DEFAULT 1 COMMENT 所在楼层, description VARCHAR(500), is_core TINYINT DEFAULT 0 COMMENT 是否核心地标 );路网表则不是随便建的。校园导航的道路模型可以简化为“节点 边”的无向图CREATE TABLE road_node ( id BIGINT PRIMARY KEY, longitude DECIMAL(10,6), latitude DECIMAL(10,6) ); CREATE TABLE road_edge ( id BIGINT PRIMARY KEY, from_node BIGINT, to_node BIGINT, distance DECIMAL(10,2) COMMENT 单位米 );这里有两个坑要提前避数据采集要实地核对不能只靠手画。很多同学从地图截图里手工描点结果坐标偏移严重。国内地图服务一般使用 GCJ-02 坐标系如果你从第三方数据源拿到的是 WGS-84 坐标要在地理围栏画出前做一次转换否则会出现“定位在一个地方路线在另一个地方”的严重问题。路网节点不用太密。校园道路不算复杂几十个节点、上百条边就够了。节点太密数据采集成本高路径计算反而看不出算法逻辑。3.2 后端接口设计与路径算法后端接口建议按功能拆成四组登录POST /api/auth/login接收小程序wx.login返回的 code换取 openid 并返回 JWT。POI 检索GET /api/poi/search?keyword东门支持名称、别名、分类的模糊匹配。路线规划GET /api/route?fromId1toId20返回路线节点、折线坐标、总距离和文字指引。对话问路POST /api/chat接收用户消息先做意图解析再走检索和路线流程。路线规划的核心算法用 Dijkstra 即可。对于几十个节点的路网用优先队列实现性能完全不是瓶颈而且算法过程在论文里好讲。核心逻辑可以理解成这样一个骨架RestController RequestMapping(/api) public class RouteController { GetMapping(/route) public Result getRoute(RequestParam Long fromId, RequestParam Long toId) { // 1. 根据 POI id 查到最近的路网节点 // 2. 以最近节点为起终点跑 Dijkstra // 3. 把最短路径换算成 polyline 坐标点 // 4. 在关键节点上生成文字指引“左转进入XX路” return Result.ok(routeVO); } }代码不需要多复杂关键是把“算法”和“业务”解耦。路径计算服务只接收节点 ID不关心你问的是“图书馆”还是“食堂”这样测试起来也方便。3.3 大模型意图解析的实现细节对话接口是整篇文章的“技术门面”。用户在小程序里发一句“我想去图书馆从东门进”后端首先调用大模型让它输出一个结构化 JSON。这里不推荐让大模型直接返回路线文本因为那样不可控、不可验证、答辩时会被问“你怎么保证它不胡说”。一个常见写法是这样的 prompt 模板你是一个校园导航意图解析器。用户会输入一句关于校园方位的话 请从中提取出发地 start 和目的地 destination。 规则 1. 只输出 JSON不要输出多余解释。 2. 如果用户没有明确提到出发地start 设为 null。 3. 如果无法识别任何地点destination 设为 null。 4. 地点名称使用校园里的常用叫法例如图书馆、东门、三食堂。 用户我想去图书馆 输出{start: null, destination: 图书馆} 用户从东门去图书馆怎么走 输出{start: 东门, destination: 图书馆}拿到 JSON 后后端再接一层 POI 匹配把模型输出的“东门”和 poi 表里的名称/别名做模糊比对。如果两边都匹配成功就走路线计算如果只匹配到目的地但缺起点就回复“请问您从哪里出发”如果完全匹配不到就提示“暂未收录该地点试试搜索‘图书馆’”。这里有两个体验关键点大模型的 temperature 参数要调低尽量设置为 0 或接近 0减少输出格式漂移。一定要做强校验。模型输出的 JSON 可能带前后缀需要用正则提取或容错解析解析失败时走规则兜底。3.4 小程序端地图组件 对话页小程序页面可以控制在两个主页面地图页和对话页。地图页放 map 组件、搜索框和路线展示对话页放聊天气泡和快捷问路按钮。地图组件的基本用法很直接map idcampusMap longitude{{center.lng}} latitude{{center.lat}} scale17 markers{{markers}} polyline{{polyline}} show-location{{true}} /map当用户确定起终点后后端返回 polyline 的坐标点数组小程序直接绑定到 map 组件的polyline属性上再设置一下markers就能显示出起点、终点和路线。这里有一个容易被忽略的细节路线返回后要把地图视野调整到能完整看到整条路线的范围。小程序 map 组件支持include-points把起终点都放进去就能自动缩放视野。对话页则是调用POST /api/chat把大模型的解析结果、路线摘要、链接操作展示成聊天消息。这样用户既可以打字问路也可以点地图上的按钮直接看路线。4. 最容易翻车的不是 AI是这些工程细节4.1 小程序合法域名与 HTTPS开发调试时微信开发者工具里可以勾选“不校验合法域名”这样就能在本地联调。但一旦上真机预览或者要给别人扫码体验就必须把后端接口部署到合法的 HTTPS 域名上并且在小程序管理后台配置 request 合法域名。很多同学项目功能写完了一上真机就白屏咬咬牙排查了半天最后发现是域名没配。这是最普遍的翻车点。建议提前把部署环境准备好不要等到演示前一晚才想起来。4.2 API Key 绝不能放前端大模型平台的 API Key 相当于你的账户密码放进小程序前端代码里等于公开。正确做法是只放在 SpringBoot 后端的配置文件中通过环境变量读取所有对大模型的调用都走后端代理。另外还要避免把 Key 提交到 GitHub 仓库。毕业设计如果开源要把敏感配置全部用环境变量替代并在 README 里说明“需自行申请 Key 并配置环境变量”。4.3 登录态wx.login → code2session → JWT小程序端调用wx.login()拿到临时 code传给后端后端用 code 调用微信接口换取 openid再生成 JWT 返回给前端。前端把 JWT 存在 storage 里后续请求头带上Authorization: Bearer token。这个流程看起来多但它是必须的。如果不做登录态任何陌生人都能直接调用你的接口答辩时老师一定会问“你的系统怎么防止被别人刷接口”。把登录态做完既安全又是加分项。4.4 大模型不可用时的兜底链路完整排查顺序这也是把“演示型项目”变为“工程型项目”的关键一步。设计兜底时建议按这个链路逐层排查看现象是请求报错、一直转圈、还是没有结果看输入小程序请求是否到达了后端后端日志有没有对应记录看网络后端是否能访问大模型 API超时时间是几秒看解析大模型返回的是不是合法 JSON解析有没有被异常字符干扰看兜底本地规则匹配是否生效POI 检索是否命中看边界免费 API 是否有限流是否因为并发被临时限制兜底实现不需要很复杂。可以准备一个精简的关键词表把 POI 名称和别名做成倒排索引用字符串包含匹配来抽取起终点。大模型调用失败或超时时自动走关键词匹配。这样即使答辩现场断网系统也能完成一次“东门到图书馆”的路线展示。注意兜底链路要提前写在代码注释和论文里不能只做不说。答辩老师看到你主动考虑了“不可用”场景项目评价会明显不一样。5. 从“Demo”到“毕业设计交付物”范围、论文、答辩5.1 功能分级先保底再加分做毕业设计最忌讳一上来就说“我要做智能推荐 多楼层导航 语音交互 室内定位”。范围越大完成度越低。建议按“必做 / 选做 / 加分”切分级别功能说明必做用户登录、POI搜索、路线计算、地图展示、对话问路形成完整闭环选做多轮澄清、收藏常用地点、历史记录、批量导入 POI提升使用体验加分校园知识问答RAG、楼层切换、语音输入、无障碍模式展示工程能力一个完成度高的“必做闭环”远比四个半成品的“加分功能”更打动老师。5.2 论文和 PPT 怎么组织论文建议按经典结构写引言、相关技术、需求分析、系统设计、系统实现、系统测试、总结展望。重点是“系统设计”和“系统实现”两章要把数据结构、接口设计、Dijkstra 算法流程、大模型交互时序图画清楚。PPT 控制在 8 到 10 页以内演示前一定要写脚本。演示的路线要提前确认没有问题比如“东门 → 图书馆”这条经典路线坐标要核对过路线要能完整显示。演示过程中不要求新求变稳定走完最熟悉的路径比现场探索新功能可靠。5.3 答辩前自测清单[ ] 断网情况下路径搜索是否还能用本地兜底跑通[ ] 大模型超时时后端是否有明确错误提示不会直接卡死[ ] 小程序真机预览是否正常还是只在开发者工具里能跑[ ] 路线坐标是否有偏移markers 是否显示在正确位置[ ] 代码和论文里的技术栈、功能描述是否一致[ ] 敏感配置API Key、AppSecret是否已经脱敏[ ] 是否准备过“大模型回答错了怎么办”这类问题的回答6. 适用边界和这类项目的真正价值6.1 这个方案适合谁不适合谁适合有 SpringBoot 基础、想做全栈项目、想接触大模型应用层开发的计算机相关专业学生。它能把前端、后端、算法、数据库、AI 应用串起来是一个典型的“应用型毕业设计”。不适合想做大模型底层算法研究、想训练自己的模型、或者没有任何校园地图数据的同学。如果拿不到真实 POI 和路网数据项目会变成“看着像导航实际是地图截图 假数据”答辩时很容易被拆穿。6.2 如果想进一步做实“AI 含量”可以考虑在“对话问路”之外增加一个校园知识问答模块。把校历、办事流程、食堂开放时间、社团活动地点等文档切分后做向量化用 embedding 检索出相关片段再用大模型生成回答。这就是一个轻量 RAG 应用比单纯“意图解析”更有技术深度。但请一定控制范围。先把导航闭环做完做稳再谈 RAG。很多同学是先想 RAG后做导航最后两个都没完成。这种项目最缺的不是技术而是优先级。6.3 最后的经验这个项目在毕业设计里属于“功能能看见、代码能跑通、论文有结构”的类型天生的答辩友好型选题。但它的成败从来不取决于大模型有多聪明而取决于你愿不愿意把 POI 数据一条条核对、把路线一条条走一遍、把边界场景一个个想清楚。如果你答辩时只能讲一个亮点请讲“闭环”而不是“大模型”。因为闭环是可以被代码验证的大模型只是流程里的一个组件。能被验证的东西才是一个工程项目的底气。