2025易智瑞GIS开发竞赛获奖作品：融合GeoSceneMCP与RAG图谱的个性化旅游规划平台

KnowWander 知游智能助手系统的定位，是一个融合 GIS、AI 与多源数据的全流程旅游决策平台。它既是普通用户的个性化出行助手，也可以成为专业旅游规划师的智能工作台。通过“灵感 → 规划 → 感知 → 选址”的功能闭环，系统覆盖了旅游活动的完整生命周期，从用户的初始想法，到行程的生成与执行，再到后期的优化与目的地开发支持。

其目标不仅是为单个用户提供贴心的旅游方案，更是推动智慧文旅产业的升级。通过 GeoScene REST API 的 MCP 封装，系统能够让 AI 与地理服务深度协作，真正实现“数据理解 → 决策生成 → 路径验证 → 反馈迭代”的闭环。这种模式既降低了使用门槛，也为行业提供了一条标准化、可扩展的技术路径。

2 系统架构

（一）用户层

1.Web 端

前端智能交互层：采用 Vue.js 3.x Composition API 架构，实现类型安全开发，Vite 5.x 构建工具实现毫秒级热重载；集成 GeoScene Maps SDK 4.29，通过 SceneView 与 MapView 组件实现 2D/3D 场景无缝切换；基于 Web Speech API、File API 与 Drag & Drop API 构建多模态交互体系，支持语音实时转写、图像 Base64 编码优化；采用 CSS Grid 与 Flexbox 响应式布局，适配多终端场景。

核心能力集成：接入阿里云百炼双 AI 引擎，主 AI（灵感）部署于 /api/bailian 端点，负责创意咨询与自然语言交互；规划AI（规划）部署于 /api/bailian/planner 端点，专注结构化行程生成；采用 SSE协议实现流式响应；调用 GeoScene POI 要素定位器实现地址 - 坐标精准转换，集成和风天气 API获取实时气象数据。

2.小程序端

前端展示与交互层：基于微信原生框架（WXML/WXSS/JS），Less 预处理样式，TDesign 组件库 + 自定义组件（行程卡片、AI 对话弹窗）构建界面；通过 behaviors、事件总线（utils/eventBus.js）管理状态；wx.request/wx.cloud.callFunction 实现通信，mock 目录模拟本地 REST 请求。

核心能力集成：云函数（aiPlanner/aiChat）调用阿里百炼流式服务，memoryManager 云函数管理用户记忆，weather 云函数（可扩展第三方气象 API）查询天气；集成腾讯位置服务（REST WebService），封装地理编码、POI 工具（tencentGeocode.js 等），后续计划迁移至云函数隐藏密钥。

（二）管理层（后端 + 数据库）

1.后端微服务层（Web 端 + 小程序端通用）

Web 端：基于 Node.js 18 + 环境构建网关，通过 cluster 模块实现多进程负载均衡；集成 CORS 跨域中间件、morgan 请求日志中间件、express-validator 参数校验中间件；设计 AI 代理服务与地理服务代理双层架构，AI 代理通过 axios 库转发阿里云百炼请求，实现流式响应透传与错误重试；地理服务代理整合 GeoScene 服务与和风天气 API，基于 MCP 协议实现服务调用标准化；采用 JWT实现无状态身份认证，token 有效期设为 7 天，结合 bcrypt 算法实现密码哈希加密，支持 RBAC（基于角色的访问控制）权限模型。

小程序端：基于微信云开发平台，采用云函数按功能域拆分架构，aiChat/aiPlanner 云函数负责 AI 交互与行程生成，memoryManager 云函数管理用户偏好记忆，weather 云函数处理气象数据查询；云函数采用 Node.js+Axios 技术栈，实现 SSE 流式数据解析与增量存储；通过云函数预热机制降低冷启动耗时，敏感配置（API Key、服务地址）计划迁移至云函数环境变量与微信云托管配置中心，解决密钥硬编码风险。

2.数据存储层

主数据库：采用 PostgreSQL 15 + 作为主数据库，集成 PostGIS 3.3 空间扩展，支持复杂空间数据类型与空间分析操作；通过 pg 连接池管理数据库连接，保障高并发场景下的连接稳定性；数据库连接字符串支持 SSL 加密传输；基于 GiST（Generalized Search Tree）索引优化空间查询，存储湖北省景点 GeoJSON 数据（WGS84 坐标系）、用户画像（JSONB 格式）、行程结构化数据等核心业务数据。

缓存与辅助存储：采用 Redis Cluster 集群模式构建缓存系统，配置 LRU（Least Recently Used）淘汰策略与 2GB 内存限制，缓存高频访问的地理数据、气象数据与用户会话信息；小程序端依赖微信云开发数据库，现有 Users、itineraryPlans、Itineraries、ai_streams 等集合，分别存储用户信息、行程请求、结构化行程、AI 流式数据，当前行程与 AI 流式中间态暂存内存，后续计划迁移至数据库实现持久化；Web 端与小程序端均设计定时聚合脚本，将用户行为数据聚合为日度统计数据，支撑数据中心可视化展示。

（三）决策层（AI+MCP + 知识图谱）

1.AI 智能决策层：采用双 AI 引擎并行架构，Web 端灵感 AI（qwen-max）聚焦创意启发与自然语言交互，具备多轮对话理解与场景化咨询能力；规划 AI（qwen-plus）通过提示工程优化，专注结构化行程生成，支持行程逻辑校验与空间合理性分析；双引擎通过消息队列实现状态同步，支持同一会话内的服务无缝切换；小程序端 AI 能力通过云函数封装，实现行程需求解析、POI 匹配、时段规划的端到端处理，同时支持用户偏好记忆的动态调用。

2.MCP 服务调用层：基于 Model Context Protocol 标准构建地理服务调用框架，实现 Geocode_GeoscAAK（地理编码）、Route_Hubei（路径分析）工具的标准化封装，包含服务元数据定义、输入参数校验规则、输出结果格式化模板；设计多层错误处理机制，支持网络超时重试、参数错误自动修正、服务降级预案，保障服务调用可靠性；通过智能缓存与预测性调用优化性能，将地理服务响应时间控制在 500ms 以内，为 AI 决策提供实时空间数据支撑。

3.知识图谱与个性化引擎：构建旅游领域专业知识图谱，整合地理百科、旅游攻略、用户评价、政策法规等多源知识，定义景点、路线、活动、文化等核心实体与关联关系；设计语义推理引擎，基于知识图谱的实体关联关系实现复杂场景推理（如 “文化偏好用户 - 历史遗迹景点 - 周边文化体验活动” 关联推荐）；个性化引擎融合协同过与深度学习（MLP 神经网络）算法，基于 Web 端 人格测试标签与小程序端用户记忆数据，实现景点推荐的精准度与多样性平衡。

图1 系统架构图

3 总体设计

（一）功能设计

1.KnowWander 灵感模块

灵感模块是系统用户旅程的起点，它承担着“激发动机、聚合兴趣、形成初步方案”的任务。对于普通旅游者来说，出行决策往往从一个模糊的念头开始：“我想去南方看看”“我想体验不同的文化”。传统的旅游产品很难捕捉到这种模糊需求，而 KnowWander 的灵感模块正是为此而设计。

图2 旅行偏好测试与用户画像评估

其核心是基于 AI 对话驱动的灵感探索。用户在小程序或 Web 端输入模糊的意图，灵感 AI 引擎（qwen-max）会结合知识库与历史行为生成候选方案，并通过流式交互逐步细化。例如，当用户提出“想在云南玩五天”，AI 会先给出以昆明、大理、丽江为核心的粗粒度行程主题；随后用户继续追问“有没有徒步线路”，AI 会调用地理数据库和推荐算法，将内容缩小到适合徒步的线路与景点，并自动提示注意事项。这一过程不仅帮助用户缩小选择范围，还让他们逐渐形成清晰的出行目标。

图3 AI灵感交互问答

灵感模块还包括 灵感流与灵感夹机制。首页灵感流展示主题化的卡片，涵盖季节推荐、热门城市、文化活动等；而灵感夹则是用户的“兴趣仓库”，可以在对话或浏览中一键收藏候选景点与活动。这些收藏在进入规划环节时会被直接调用，从而形成真正的数据闭环。更重要的是，AI 会在对话中自动提取用户的偏好，例如“喜欢美食”“预算有限”“倾向徒步”，并以标签形式写入用户画像。这种“隐性建模”机制让系统在不增加用户操作负担的情况下，逐步构建出个性化的推荐体系。

图4 旅游知识图谱关联推荐

总体而言，灵感模块的价值在于把模糊想法转化为明确方向，同时积累画像数据，为后续规划和推荐打下基础。它既满足了用户对“被启发”的心理需求，也通过 AI 与知识库结合，解决了传统灵感获取途径同质化、缺乏个性化的局限。

2.KnowWander 规划模块

规划模块是整个系统的核心承载，负责将灵感与偏好转化为可执行的行程。不同于传统的“模板行程”或“固定线路”，本模块通过 AI 行程生成、流式展示、结构化存储、可编辑迭代 等机制，形成了动态化与个性化并重的解决方案。

其第一大特征是 流式生成与展示。用户输入出发城市、出行天数、主题偏好后，规划 AI 引擎（qwen-plus）会调用 MCP 封装的地理服务和知识库，分阶段生成行程。从整体框架（每日主题）到细节（POI、时间段、活动安排），都通过 SSE 协议实时返回。用户在等待过程中就能看到部分结果，从而感受到规划的“过程感”，而不是被动等待最终结果。

第二个特征是 结构化存储与可编辑性。生成的行程会被解析为 itinerary → days → items 的多层结构，存入数据库 Itineraries 集合中。这样做的好处是用户可以对单个活动进行修改，而无需重写整个行程。例如，用户可以将“第二天上午游览大理古城”替换为“苍山徒步”，系统会重新校验时间与交通可行性并更新结果。同时，系统支持版本管理，用户每次修改都可以保存为新版本，形成清晰的历史演变链条。

图5 行程规划与卡片展示

第三个特征是 路径与地理校验。规划模块并不只停留在文本层面，而是与 GeoScene 的 Route_Hubei 工具或小程序端的腾讯位置服务结合，对行程的空间可行性进行验证。例如，若用户安排了两个不相邻的景点在同一时间段，系统会自动计算行车时间并提示冲突。这样的机制避免了“纸面行程不落地”的问题，使规划结果更加科学与现实。

图6 智能体链式思考与GeoScene地理服务自主调用

图7 路线规划与沿途推荐

从用户体验角度看，规划模块既提供了 AI 的高效与智能，又保留了用户的主动性与控制感。它不仅是一个“行程生成器”，更是一个“行程共创平台”，让 AI 与用户共同完成旅行方案的构建。

3.KnowWander 感知模块

感知模块的设计理念是“让系统不断学习与优化”，通过持续收集用户数据和外部环境数据，实现规划与推荐的动态迭代。它包括用户行为感知、用户画像记忆与外部环境监测三个层面。

用户行为感知：系统在小程序和 Web 端埋点，采集用户的页面停留时间、点击偏好、行程生成耗时等行为数据。这些数据通过 metrics_events 集合存储，并定期聚合为统计指标，形成数据中心。后台可以直观看到用户活跃度、互动频次和行程完成率，不仅便于运营监控，也能作为推荐优化的依据。例如，当某一类景点被大量用户收藏或搜索，系统会自动提升该景点在灵感流中的权重。

图8 即时意图推理

用户画像记忆：感知模块与 memoryManager 云函数结合，在对话中提取偏好标签并存储到用户画像中。这些标签包括预算、旅行风格、饮食喜好、社交倾向等。随着用户使用次数的增加，画像会不断完善，推荐结果也会越来越精准。这种“记忆驱动”机制让系统具备了自学习能力，从而实现个性化的持续优化。

图9 云端用户长期记忆回溯

外部环境监测：感知模块还接入天气、交通、人流等实时数据，提供动态调整能力。例如，当检测到恶劣天气时，系统会自动减少户外活动推荐；当路径出现拥堵时，会推荐替代方案。这种动态调整让行程更加贴合实际，也提升了用户的安全感与满意度。

图10 环境感知与个性化推荐

感知模块的最大意义在于构建了一个“持续优化的闭环”。它不仅让系统随着时间推移而越来越懂用户，也使规划结果能够随环境变化而不断更新，真正实现了智能旅游的动态适应性。

4.KnowWander 选址模块

选址模块是系统面向专业规划师和目的地开发者的核心功能，目标是利用 GIS 与 AI 的结合，为旅游资源开发与线路策划提供科学依据。

在数据层面，选址模块能够读取 GIS 工程中的资源点图层和空间数据，并结合 AI 对其进行分类、分级和卖点提炼。例如，规划师可以选择一批候选景点，让系统给出“资源价值评估与分级标准”，AI 会结合知识库与地理数据生成初步建议，显著降低人工分析成本。

图11 GeoScene Pro工程环境感知与自适应代码生成

在功能层面，选址模块支持生成 Python 脚本并直接运行，实现空间分析的自动化。例如，用户可以请求“统计不同线路覆盖的景点数量和总评分”，系统会自动生成代码并执行，将结果回显在 Dockpane 中。这种“从对话到执行”的闭环能力，大幅提升了工作效率。

图12 GeoScene Pro自动化空间分析

在路径分析层面，选址模块通过 MCP 封装的 Route_Hubei 工具，自动计算候选点之间的最短路径，并在无路径时尝试调整坐标。这种智能化机制保证了选址分析的稳定性和实用性。

此外，选址模块还支持三维模型的引入。通过 CC 建模生成的高精度三维模型可以直接作为数据源，导入 GeoScene 平台进行展示和分析。规划师可以在真实的三维环境中评估景点分布和线路可行性，从而在决策过程中更有说服力。

（二）数据库设计

数据库设计在 KnowWander 系统中扮演着至关重要的角色。它不仅仅是简单的数据存储工具，更是支撑 AI 生成结果、用户交互行为、空间分析运算和实时推荐的核心中枢。系统采用了 PostgreSQL + PostGIS、Redis 缓存、微信云数据库 的多层结构，这种组合兼顾了空间分析的专业性、高并发场景下的效率以及轻量级前端的便捷性。

1.PostgreSQL + PostGIS：核心空间数据库

在整个系统架构中，PostgreSQL 是主数据库，主要承担大规模结构化与空间数据的存储与管理任务。借助 PostGIS 扩展，它能够支持完整的空间分析能力，例如缓冲区生成（ST_Buffer）、空间关系判断（ST_Contains、ST_Intersects）、距离计算（ST_Distance）、K近邻查询等。这些功能对旅游行程的空间校验和选址分析至关重要。例如：

-行程空间验证：当 AI 规划生成一条线路时，系统会调用 ST_Distance 来计算相邻景点之间的距离，并与交通数据对比，从而确认是否可行。

-区域覆盖分析：在规划主题旅游线路时，可以通过 ST_Contains 判断某条线路是否覆盖特定文化遗产区或生态保护区。

-服务区计算：通过 ST_Buffer，对景点或交通枢纽生成一定半径的缓冲区，分析其服务范围，辅助选址模块进行可达性分析。

此外，PostGIS 提供了 GiST 与 R-Tree/Quad-Tree 混合索引机制，使大规模空间查询的性能提升超过 80%。这对于实时路径验证和大数据规模的 POI 检索尤为关键。

在数据组织上，PostgreSQL 统一采用 WGS84（EPSG:4326）坐标系，兼容性高，便于在 WebGIS、小程序和桌面端多终端共享。部分数据在渲染层会转换为 Web Mercator 投影，以满足 Web 端快速加载的需求。

2.Redis 缓存：高并发优化引擎

在系统运行过程中，Redis 主要用作高速缓存和数据加速层。其部署为集群模式，采用 LRU（Least Recently Used）淘汰机制，确保在有限内存下保持高效运行。Redis 在以下几个方面发挥了关键作用：

-地理编码结果缓存：用户频繁调用地址解析（Geocode_GeoscAAK），而许多输入重复率高。Redis 可以缓存结果，减少对 GeoScene API 的调用频次。

-热门搜索与推荐缓存：对于高频的景点检索和灵感推荐，Redis 提前存储结果，保证用户在短时间内获得快速响应。

-会话数据缓存：在 AI 流式对话中，Redis 临时缓存部分 SSE 输出，保证数据在前端轮询时能够即时获取。

通过缓存层，系统能够在高并发环境下保持稳定运行，既降低了外部服务调用成本，也提升了用户体验的流畅性。

3.微信云数据库：轻量交互存储

针对微信小程序场景，系统采用微信云数据库来存储用户相关数据和 AI 交互结果。这部分数据库设计具有轻量化、易集成的特点。

-Users 集合：存储用户的基本资料（昵称、性别、联系方式）、偏好标签、记忆 ID 等。当前问题是 password 字段采用明文存储，phone 与 userPhone 冗余，存在严重的安全风险。优化方向是采用哈希加密（如 bcrypt）存储密码，并通过字段统一减少冗余。

-ItineraryPlans 集合：用于保存 AI 生成的初步行程概要。但该表结构半规范化，planItems 将多日数据混合存储，不利于后续局部编辑与优化。改进方向是将其拆分为日程表与活动表，保证数据的细粒度操作。

-Itineraries 集合：存储用户确认的正式行程，支持版本控制（versionCurrent）、状态管理（draft/active/archived）等，形成完整的行程生命周期。通过这种结构，用户能够在不同版本间切换，保持灵活性。

-ai_streams 与 ai_chat_streams 集合：存储 AI 交互的流式结果和思考过程。问题在于 fullText 与 thoughts 混合存储，且缺乏分片机制，导致并发场景下的编辑困难。优化方向是采用增量分片存储，每一片流式数据单独存储，并通过 sessionId 聚合，既保证并发性，又支持回溯。

4.总体分析

通过三层数据库结构，系统实现了“空间数据归 PostgreSQL、实时缓存归 Redis、轻量交互归微信云数据库”的原则。这样既能保障空间分析的专业性，又能在高并发下保证性能，同时满足小程序端的灵活性。未来，数据库设计还将进一步优化安全性（如全面引入加密与脱敏）、一致性（字段统一化）、扩展性（行程分表设计）和智能性（推荐索引与数据驱动的预测分析）。

（三）关键技术

1.MCP 协议实现：完整实现 Model Context Protocol 标准的地理服务调用框架，包括服务元数据定义（工具名称、输入输出参数、描述）、参数校验逻辑（类型校验、范围校验、格式校验）、错误处理机制、结果标准化解析；通过代理服务实现 MCP 工具的统一注册与管理，支持工具链式调用（如 “地理编码→POI 检索→路径规划”），为 AI 智能体提供标准化的地理服务调用接口，该技术的创新点在于解决 GIS 服务与 AI 智能体交互的 “接口异构” 问题，为行业提供可复用的技术范式。

2.地理信息处理 API 接口：Web 端集成 GeoScene 地理编码 API（支持模糊地址匹配、多候选结果排序）、路径分析 API（支持多途经点、约束条件（如避开高速）、路径几何优化）、空间查询 API（基于 PostGIS 的缓冲区分析、叠加分析、网络分析）；小程序端封装腾讯位置服务 API（地理编码、逆地理编码、POI 检索（按分类 / 周边）、路径规划（步行 / 驾车 / 公交））；API 接口设计支持参数自定义（如路径规划中的 “偏好类型”）、结果格式定制（JSON/GeoJSON），为行程规划、空间分析提供精准的地理数据支撑，接口响应时间控制在 500ms 以内，可用性达 99.9% 以上。

3.流式处理技术：Web 端采用 SSE 协议实现 AI 响应的实时流式传输，前端通监听数据 chunk，结合增量渲染技术，降低用户感知延迟；小程序端采用 “云函数 SSE 解析→增量存储→前端轮询（200ms 间隔）” 模式，实现流式文本的分段获取与展示，同时支持 “思考过程（thoughts）” 与 “结果文本（fullText）” 分离展示（可配置显隐）；流式处理过程中设计断点续传机制，避免网络中断导致的数据丢失，该技术提升 AI 交互的实时性与透明度。

4 作品亮点

4.1 基于 GeoScene REST API 的 MCP 服务

系统在国内率先实现了基于 Model Context Protocol (MCP) 标准的地理服务封装，这是 KnowWander 的首要亮点。传统的 GIS 服务调用往往面临接口复杂、调用成本高、错误处理不完善等问题。用户必须熟悉复杂的 REST 参数、字段规范和坐标系统，否则极易出错。更为重要的是，这类接口几乎完全不具备“容错与自愈能力”，一旦参数输入不当便会导致调用失败。

图13 GeoScene地理服务的MCP标准化封装配置（开源地址：https://github.com/AAKandGLZ/GeoSceneMCP）

KnowWander 的创新点在于通过 MCP 框架对 GeoScene REST API 进行深度封装，将复杂的 地理编码（Geocode_GeoscAAK） 与 路径分析（Route_Hubei） 转化为智能化、标准化的工具。用户只需输入自然语言地址，系统便会自动解析、校验参数并返回统一格式的 JSON 输出。这一过程中，如果出现错误，例如输入地址模糊或经纬度异常，MCP 会自动提供改写建议或进行坐标微调，再次尝试调用，直至得到最优解。

这一亮点的意义在于：首先，它显著降低了地理信息服务的使用门槛，让没有 GIS 专业背景的普通用户也能直接调用地理工具。其次，它大幅提升了地理服务的鲁棒性和稳定性，通过自动错误处理和结构化输出，使得 AI 智能体能够直接利用结果进行决策，而无需用户反复人工干预。最后，MCP 服务的实现为行业提供了标准化的范例，在智慧旅游、智慧城市等领域具有广泛的推广价值。

4.2 GIS 与 AI 的闭环集成

KnowWander 并不仅仅是一个“推荐系统”，而是真正实现了 GIS 与 AI 的深度闭环集成。这一闭环体现在“从空间数据 → AI 理解 → 行程生成 → 路径验证 → 场景展示”的全过程。

在传统模式下，用户往往需要在不同的软件与工具之间切换：先在 GIS 平台获取数据，再在文档中撰写规划报告，最后还需要人工校验路径和可达性。这种分散的工作流不仅耗时，而且容易出错。KnowWander 打破了这种割裂，通过将 AI 与地理服务紧密结合，实现了完整的工作流一体化。例如，AI 可以根据用户输入生成初步行程，同时调用 GeoScene API 进行空间验证，确保行程可执行；用户若需要定量结果，AI 还可以生成 Python 脚本并直接在桌面端执行，将分析结果回显至 Dockpane。

这种闭环设计的价值在于：它不仅提高了效率，更提升了结果的科学性与可信度。对普通用户而言，这意味着“生成的行程可以真正落地”；对专业规划师而言，这意味着“AI 不再是泛泛之谈，而是能真正结合空间数据进行科学推演”。KnowWander 在这一点上实现了旅游系统的质变。

4.3 灵感—规划—感知的三层闭环体验

KnowWander 的另一个显著亮点在于 灵感、规划、感知的三层闭环。这一设计理念源自对用户行为路径的深入分析：旅游者的决策过程往往不是线性的，而是一个不断循环、逐步明确的过程。

灵感模块帮助用户从模糊的想法出发，逐渐形成兴趣方向；规划模块将这些兴趣转化为结构化、可执行的行程；感知模块则不断采集用户的偏好与环境数据，反过来优化灵感推荐与规划结果。三者结合形成了一个自我迭代的循环，使系统能够“越用越懂你”。

这种闭环体验的优势在于，它不仅解决了用户“从哪里开始”的困境，也解决了“如何持续优化”的问题。与传统一次性生成方案的工具不同，KnowWander 具备持久学习与动态适应能力，真正做到了“用户使用越久，推荐越精准，规划越贴合”。这不仅提升了用户满意度，也为系统积累了宝贵的数据资产，为后续的推荐算法与模型优化提供了坚实基础。

4.4 高精度三维建模与沉浸式场景还原

在本项目中，团队引入了 CC（CloudCompare）三维建模 技术，对实地采集的点云与遥感数据进行处理，生成高精度三维模型，并将其无缝接入 GeoScene 三维引擎进行展示。这一设计极大丰富了系统的空间可视化能力，是区别于传统旅游助手系统的独特亮点。

图14 三维场景实时渲染

通过 CC 建模，系统能够在 WebGIS 或桌面端展示真实还原的三维场景，包括地形起伏、建筑立面、道路走向和植被覆盖。这种沉浸式体验不仅让普通用户能够直观感受到目的地的空间特征，还让规划师能够在真实场景下验证行程的合理性。例如，在进行徒步线路设计时，三维模型可以直观显示坡度与高差，帮助判断线路是否适合不同年龄群体；在评估观景点位置时，可以通过模型模拟视野开阔度，从而为景区设计提供科学依据。

更进一步，三维建模还在成果展示中发挥了重要作用。在投标汇报、政府审批或公众宣传环节，二维地图往往缺乏直观冲击力，而三维模型能够以近乎真实的场景效果展示规划成果，显著提升了说服力与感染力。这种“从数据到场景”的跨越，不仅增强了系统的专业性，也提升了其应用价值和社会影响力。

4.5 个性化推荐与人格建模

KnowWander 在个性化方面的突破，主要体现在 人格建模与推荐算法的深度融合。系统基于心理学理论和大数据分析，设计了涵盖探索性、舒适性、文化性、自然性等十二个维度的旅游人格测试模型。通过这一模型，系统能够为用户建立细致入微的画像标签，真正实现“因人而异”的推荐。

推荐引擎采用了协同过滤、内容过滤与深度学习混合算法，推荐准确率达到 85% 以上。更重要的是，随着感知模块不断采集用户的行为与环境数据，这些推荐结果会实时迭代优化。例如，当某用户在灵感对话中多次表现出“徒步”偏好，系统会在后续推荐中增加徒步类景点的权重；当检测到用户预算有限时，系统会优先推荐经济型路线与住宿。

这一亮点的意义在于，它解决了传统推荐“千人一面”的痛点，让用户真正感受到“这是为我量身定制的行程”。同时，个性化建模也为旅游业的精准营销和产品创新提供了新的思路。

4.6 跨终端与多源融合

KnowWander 系统同时覆盖桌面扩展、Web 端与微信小程序，实现了真正的 跨终端应用。这种多端布局的优势在于，它既满足了专业用户的深度需求（桌面端 GIS 分析与代码执行），又满足了普通用户的便捷需求（小程序灵感探索与快速行程生成），同时通过 Web 端提供沉浸式三维可视化与多平台兼容。

更重要的是，三端共享同一套数据与服务接口。用户在小程序中生成的行程，可以在 Web 端进行三维展示，也可以在桌面端直接运行空间分析脚本。这种统一性不仅提升了用户体验，也降低了开发与维护成本。

在数据层面，系统整合了 GeoScene 地理服务、腾讯位置服务、和风天气 API 等多源数据，使得行程规划能够动态适应外部环境。例如，当天气变化时，系统会自动调整推荐内容；当交通数据更新时，路径规划会进行智能重算。这种多源融合保证了系统结果的科学性与实时性。

4.7 社会与产业价值

KnowWander 通过个性化推荐与动态感知，提升了旅游体验的多样性与安全性。例如，系统会不断调整推荐，减少安全风险；在预算有限时推荐性价比更高的路线，提升旅游的可及性。这不仅提升了个体用户的满意度，也有助于推动旅游资源的均衡利用和可持续发展。

此外，本系统作为地理信息科学专业的综合实践作品，同时也展示了 GIS、AI 与大数据融合的前沿方向。

相

关

内

容返回搜狐，查看更多