景区已经有电子地图，再接入AI导游时，最容易做成"地图旁边多一个聊天框"。游客可以提问，也能查看地图，但两套功能如果使用不同的地点名称和任务状态，回答结束后仍要重新搜索目的地，AI并没有缩短游览路径。
我们做月湖灵境时，重点不是增加一个会说话的角色，而是让一次问答能够转成可执行的地点、路线和现场服务。为此，应用层需要解决三件事：地点实体统一、游览任务持续，以及运营数据可以独立更新。
月湖灵境小程序首页与AI提问入口。来源：视+AR月湖灵境项目素材。
先把回答里的地点映射到统一实体
游客可能说"月湖边那个祠堂"，知识内容使用正式名称，地图点位又采用另一套名称。如果问答和地图各自维护字符串，即使AI识别出了游客意图，也无法稳定打开正确地点。
我们的处理思路是让知识内容、搜索词、地图点位和详情页共享同一个地点实体。正式名称用于展示，简称、旧称和常见问法作为别名；路线入口、详情内容和服务信息都通过地点ID关联，而不是依赖文本完全相同。
这样，回答中提到一个地点时，应用拿到的不只是一段文字，还能同时获得可执行动作：打开详情、在地图上定位，或者以该地点为终点启动路线。遇到同名或含义不清的问法，再让用户确认，而不是直接生成一个看似合理但无法落地的答案。
在月湖灵境AI伴游项目中，AI交互、景点详情、主题游线和地图导航位于同一个微信小程序内。它们之间能否顺畅衔接，核心就在于地点不是散落在不同页面里的几段文字，而是可被多个功能共同调用的对象。
月湖灵境的地图、景点详情与导航界面。来源：视+AR月湖灵境项目素材。
把游客问题转成一个可以继续执行的任务
"月湖有哪些景点"和"我只有四十分钟，带孩子怎么走"都包含景点需求，但任务结构不同。前者适合返回地点列表，后者还包含时间、同行人和路线范围等约束。
应用不应该只保存一轮回答文本，还需要保存当前任务：游客选择了哪条路线、已经到达哪个地点、下一站是什么，以及临时查询服务点后是否要回到原路线。地图、详情和问答页面都读取同一任务状态，页面切换才不会让游览重新开始。
在界面上，这意味着回答后要出现与当前意图匹配的动作。询问单个景点时可以打开详情；询问游览安排时应该进入路线选择；询问卫生间或服务台时则直接进入服务点导航。按钮不是聊天内容的装饰，而是把语言结果交给地图与路线模块的接口。
月湖灵境的主题路线推荐与游线地图。来源：视+AR月湖灵境项目素材。
临时查询不能破坏原来的游览状态
真实游览中，游客经常在途中插入新问题。例如正在执行主题路线时，临时询问最近的卫生间；解决之后，他仍然希望回到原来的下一站。
如果系统把每次提问都当成新任务，原路线就会被覆盖。更合适的状态组织是区分主任务和临时任务：主题游线保留当前位置和下一节点，服务点查询作为短任务插入，完成后再恢复主任务。用户主动更换路线时，才明确结束旧任务并建立新任务。
这一机制也方便处理偏航和返回。系统无需让用户重新输入问题，只要根据当前任务、当前位置和可用路线计算下一步，并在界面中明确显示"继续原路线"或"结束当前路线"。
服务点数据要与文化内容分开维护
文化讲解通常变化较慢，卫生间、出入口、活动点位和开放状态却可能随运营调整。两类数据如果混在同一批AI内容里，临时变更就可能需要重新修改大量知识文本。
因此，我们会把地点基础信息、讲解内容和运营状态分层管理。问答可以引用这些数据，但不自行决定服务点是否开放。运营人员更新状态后，搜索结果、地图和回答引用同一份有效信息，避免不同页面出现互相矛盾的答案。
月湖灵境的名士对话与书香值界面。来源：视+AR月湖灵境项目素材。
验收时要测试完整任务链，而不是单独测试聊天
AI回答通顺并不等于导览可用。我们会用一条完整路径检查系统：进入小程序，提出带时间约束的问题，选择路线，打开第一站，行进中查询服务点，再返回原任务继续游览。每一步都要确认地点是否一致、任务状态是否保留、按钮是否进入正确页面。
还要加入容易出错的问法：地点简称、同名地点、模糊方位、临时改变主意，以及服务点状态变化。测试结果应能定位到具体层级------是地点别名未匹配、任务状态被覆盖、路线不可用，还是运营信息没有及时更新。
AI导游真正的技术工作，不是让聊天更长，而是把自然语言中的目的地和约束转成应用可以执行的状态。地点实体统一、主任务可以恢复、运营数据独立更新，电子地图才会从"供游客查看"升级为"能够连续带游客完成一次游览"。