【腾讯位置服务开发者征文大赛】基于 Spring Boot + 腾讯地图 + AI 的自然语言地图推荐与轻行程规划助手

张开发
2026/6/1 2:27:59 15 分钟阅读
【腾讯位置服务开发者征文大赛】基于 Spring Boot + 腾讯地图 + AI 的自然语言地图推荐与轻行程规划助手
项目目标把“自然语言输入 → 地点推荐 → 推荐理由 → 地图展示 → 轻行程规划”这条最小闭环跑通。技术栈Java 8、Spring Boot、Thymeleaf、原生 HTML/CSS/JS、腾讯地图 JavaScript API。有时候我会觉得地图产品其实已经很强了但还有一个地方始终不太顺手它很会找点但不一定真的懂人。真实生活里的需求往往不是“搜咖啡馆”“搜公园”这么简单而是“我想找一个适合独自办公两小时、离地铁近一点的咖啡馆”或者“周末想和朋友吃饭再散步帮我安排一个轻松点的路线”。基于这个想法我做了一个自然语言地图推荐与轻行程规划助手用 Spring Boot 组织后端链路结合 AI 的自然语言理解能力与腾讯地图的空间展示能力把一句更像人话的需求落成一个可视化、可理解、可执行的结果页。一、为什么想做这个项目最近这段时间我一直在想一件事地图搜索能不能更懂“场景”一点。平时我们用地图大多数时候还是在输入关键词。比如搜“咖啡馆”“火锅”“公园”“地铁站”。但真实生活里的需求很少这么短平快。我们更常说的是• 我在望京附近想找一个适合独自办公两小时的咖啡馆最好离地铁近一点。• 周末想在国贸附近和朋友吃饭再散步时间大概下午到晚上人均 150 左右帮我规划一个轻松点的路线。你会发现用户真正表达的是一个完整场景而不是一个孤立关键词。所以这次我做的不是“更强的关键词搜索”而是一个更像真实生活的地图助手。二、项目想解决什么问题这个 Demo 的目标很克制不追求做成大而全的平台而是先把最小闭环跑通自然语言输入 → AI 解析需求 → 推荐地点 → 生成推荐理由 → 腾讯地图展示 → 输出轻量行程建议我更看重的不是把功能堆得多复杂而是验证这件事一句更像人话的需求能不能被系统接住并落成一个真正可用的结果页。三、整体技术方案整个系统我大致拆成五层1. 输入层接收用户自然语言需求。2. 解析层把一句话拆成结构化意图如位置、类别、场景、偏好、预算等。3. 候选地点层根据意图拿到候选地点。4. 推荐生成层生成推荐理由和轻行程建议。5. 展示层把结果组织成页面并在腾讯地图上做真实点位展示。项目技术栈并不复杂Java 8、Spring Boot、Thymeleaf、原生 HTML/CSS/JS再加上腾讯地图 JavaScript API。这里我没有上复杂前端框架主要是想尽快做出一个能跑通的 demo。四、两个真实演示场景为了让 Demo 更像真实项目我固定了两个最容易让人代入的场景。场景 A望京咖啡馆办公推荐用户输入“我在望京附近想找一个适合独自办公两小时的咖啡馆最好离地铁近一点。”系统会解析出城市北京、位置望京、类别咖啡馆、场景独自办公、偏好安静/离地铁近然后返回几个候选地点并补一段推荐理由告诉用户为什么推荐这些点。场景 B国贸吃饭 散步轻行程用户输入“周末想在国贸附近和朋友吃饭再散步时间大概下午到晚上人均 150 左右帮我规划一个轻松点的路线。”这个场景更接近日常生活因为它不是找一个点而是找一个顺下来的安排。系统会先解析组合需求再返回餐饮点、散步点、推荐顺序并用地图把空间关系表达出来。五、页面效果预览及演示 Demo下面这几张图是当前版本已经跑通后的真实页面效果。第一张是首页空态第二张是场景 A 的结果页第三张是场景 B 的结果页。从页面上能看到输入区、解析结果、推荐地点、推荐理由、腾讯地图展示以及轻行程规划。图 1 项目首页空态用户可以直接输入自然语言需求或点击两个示例场景按钮快速体验。图 2 场景 A 结果页望京咖啡馆办公推荐页面展示了解析结果、推荐地点卡片以及真实腾讯地图底图。图 3 场景 B 结果页国贸吃饭 散步轻行程系统给出地点组合、推荐理由以及更接近真实生活的路线表达。演示 demo六、开发过程里最有代表性的几个坑1Java 8 兼容性问题AI 生成 Java 代码时经常会顺手写出 var、Map.of()、List.of()、readAllBytes() 这些写法但项目环境还是 Java 8这一块一开始就修了不少。2资源文件读取问题Prompt 模板放在 resources 下面本地开发时不一定暴露问题但一打包成 JAR读取方式如果偷懒很容易失效。后面这里也专门修过一轮。3Thymeleaf 模板和 JSON 注入看起来是个轻页面实际上模板变量注入、前端 JSON 输出、条件渲染这些地方特别容易踩坑。页面没完全崩但地图初始化、交互逻辑都可能被带坏。4腾讯地图接入时 API 版本混用这是最典型的坑。一开始地图区域一直空白最后排查发现根因不是后端不是数据而是前端把地图 SDK 和 API 写法混用了。统一成匹配版本后底图和 Marker 才真正正常显示出来。七、为什么最后一定要接入真实腾讯地图其实一开始我用的是一个“模拟地图展示区”来跑通逻辑。那一版也能演示也能截图但总感觉差一点意思。因为这个项目本身就是“AI 地图”如果地图部分只是静态模拟面板说服力始终不够。后面补上腾讯地图真实接入之后差别非常明显页面更像产品结果更有空间表达能力录屏时也更容易让人理解这不是概念图而是真正跑起来的 Demo。对这个项目来说真实地图底图和 Marker 的价值远大于再加几层页面装饰。八、总结这次我做的这个“自然语言地图推荐与轻行程规划助手”本质上是一个小而完整的实战 Demo。它做的事情并不夸张但我觉得很有意思用自然语言接住真实需求用 AI 做意图理解用推荐结果承接场景用腾讯地图做空间表达再用轻量行程规划把结果串起来。从工程复杂度上看它不是最难的项目但从方向验证的角度我反而觉得它挺有价值。至少它说明了一件事地图体验不一定非要从关键词开始完全可以从一句更像人话的需求开始。后续优化方向接入更真实的地点搜索与筛选能力补强路线规划表达而不仅是简单顺序连线增加更多生活化场景如约会、遛弯、临时办公、带娃等继续优化 AI 输出让推荐理由更像一个真正会沟通的助手欢迎在评论区聊聊你觉得“自然语言地图助手”最适合落地到哪些场景比如约会路线、探店、遛娃、周末短途、出差临时规划或者你觉得更有意思的方向。

更多文章