企业官网建设流程全解析

每年开学季，总能在校园里看到一群人举着手机原地转圈：新生分不清东南西北，送孩子报到的家长反复问“图书馆往哪走”，校外访客看着导航 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，同时保留一个本地规则匹配或本地模型兜底。具体选哪个平台，看当时的市场情况和免费额度，不要写死“某个平台一定最好”。答辩时只要能说清楚“为什么这样选、各自边界在哪里”，就比盲目堆技术得分高。

2.4 技术栈总表

这个组合的特点是“每个环节都能讲清楚”。答辩时老师问“为什么用这个技术”，你都能给出一个具体理由，而不是回答“大家都这么用”。

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?fromId=1&toId=20，返回路线节点、折线坐标、总距离和文字指引。
• 对话问路：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 id="campusMap" longitude="{{center.lng}}" latitude="{{center.lat}}" scale="17" 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 大模型不可用时的兜底链路：完整排查顺序

这也是把“演示型项目”变为“工程型项目”的关键一步。设计兜底时，建议按这个链路逐层排查：

1. 看现象：是请求报错、一直转圈、还是没有结果？
2. 看输入：小程序请求是否到达了后端？后端日志有没有对应记录？
3. 看网络：后端是否能访问大模型 API？超时时间是几秒？
4. 看解析：大模型返回的是不是合法 JSON？解析有没有被异常字符干扰？
5. 看兜底：本地规则匹配是否生效？POI 检索是否命中？
6. 看边界：免费 API 是否有限流？是否因为并发被临时限制？

兜底实现不需要很复杂。可以准备一个精简的关键词表，把 POI 名称和别名做成倒排索引，用字符串包含匹配来抽取起终点。大模型调用失败或超时时，自动走关键词匹配。这样即使答辩现场断网，系统也能完成一次“东门到图书馆”的路线展示。

注意：兜底链路要提前写在代码注释和论文里，不能只做不说。答辩老师看到你主动考虑了“不可用”场景，项目评价会明显不一样。

5. 从“Demo”到“毕业设计交付物”：范围、论文、答辩

5.1 功能分级：先保底，再加分

做毕业设计最忌讳一上来就说“我要做智能推荐 + 多楼层导航 + 语音交互 + 室内定位”。范围越大，完成度越低。建议按“必做 / 选做 / 加分”切分：

一个完成度高的“必做闭环”，远比四个半成品的“加分功能”更打动老师。

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 数据一条条核对、把路线一条条走一遍、把边界场景一个个想清楚。

如果你答辩时只能讲一个亮点，请讲“闭环”而不是“大模型”。因为闭环是可以被代码验证的，大模型只是流程里的一个组件。能被验证的东西，才是一个工程项目的底气。