【腾讯位置服务开发者征文大赛】我用腾讯位置服务做了一个会思考的选址地图

文章目录前言一、选址场景最适合把 AI 和地图真正接起来二、腾讯位置服务是工程底座三、如何使用 AI 串联为可用流程四、在开发过程中不断提升用户体验总结前言做门店选址的人几乎都会遇到同一种混乱。地图开着搜索框里塞满了关键词办公楼看一圈地铁站看一圈商场看一圈竞品门店再看一圈页面上的信息越来越多脑子里的判断却越来越散。地图把很多内容放到了你面前可真正麻烦的地方一直没变那就是这些内容怎么拼成一个可以落下来的结论。MapSite AI 就是从这里长出来的我想做一个面向真实选址场景的 AI 地图应用。用户描述需求系统去理解需求再调用腾讯位置服务完成地点检索、候选区域筛选、地图展示和报告生成最后给出一份可读、可比较、可导出的初筛结果。地图在这里承担的是空间证据组织的工作AI 负责理解和解释最后交给决策者去判断。体验地址https://mapsite-ai.kaminono.com/演示视频MapSite AI 演示一、选址场景最适合把 AI 和地图真正接起来很多地图类项目一开始都会选择更容易展示的方向比如自然语言搜周边、对话式导览、多人路线规划。这些方向都不错也确实能体现 AI 和地图结合后的交互变化。可一旦把问题收得更贴近真实业务你会发现商业选址这个场景的张力更强。因为商业选址天生就是一个判断问题。用户关心的不是附近有什么而是哪里更值得看为什么值得看和另外两个区域相比差距到底在哪。这件事单靠地图页面很难跑通。地图可以展示信息但不会自动帮你整理判断。单靠大模型也不行。大模型可以组织语言却不能脱离真实空间数据凭空下结论。只有当地图能力和 AI 理解真正接起来项目才会开始像一个产品可以实际应用到具体的业务决策。我在产品落地时先拿咖啡店选址初筛作为主场景去跑通整条链路。这样做有两个现实原因。一个是咖啡店的需求足够常见办公人群密度、地铁可达性、商业配套成熟度、竞品压力这些要素是很容易被理解的。另一个是这类空间要素和腾讯位置服务的地点搜索、地图展示、行政区划、可视化能力的整合非常密切产品更容易形成完整闭环。用户输入一段像面向白领、靠近办公楼、交通方便、竞争压力适中这样的自然语言需求系统就能把它拆成可以执行的空间条件分析数据之后会生成候选区域、地图呈现和详细的评分分析。不过这个项目的能力边界并没有被限制在咖啡店上这套方法同样可以延伸到轻食店、茶饮店、社区烘焙店、便利零售、小型宠物门店这类业态。它们关注的重点可能不同有的更看重办公客群有的更看重社区密度有的更在意交通可达性和配套成熟度但底层逻辑是一致的都是先把自然语言需求翻译成结构化条件再用腾讯位置服务提供的空间数据去完成候选区域筛选和结果解释。地图进入真实业务场景以后最重要的价值在于它开始参与判断过程。AI 进入这个场景以后最重要的价值在于它能把模糊输入翻译成结构化条件再把结果解释得更容易理解。二、腾讯位置服务是工程底座MapSite AI 能真正成立靠的不是某一个大模型突然很聪明而是腾讯位置服务把地图前端、LBS 服务和 WebService 能力做成了一整套可以拼起来的工程链。平时说接地图很容易把这件事想简单。真到产品开发阶段你很快就会发现地图不是放一个底图就结束了。地图实例怎么初始化候选区域怎么画多边形和点位怎么联动图层怎么切行政区划怎么接入首页城市选择地点搜索怎么进入分析流程这些事情全都要落下去。腾讯位置服务的 Map Skills 在这里给了我很大的帮助。前端地图分析页搭建阶段我用到了 TencentMap_jsapi_skills 对应的能力面。地图初始化、覆盖物绘制、图层管理、事件系统和可视化渲染这些能力让地图页从一开始就有了比较清晰的开发路径。它没有替我自动完成产品设计但明显减少了前端地图集成阶段的试错成本。地图分析页最后能做成候选区域高亮、点位联动、图层切换和区域详情同步很大程度上就是因为这层能力足够扎实。腾讯位置服务的 WebService 能力是整条选址分析链路的基础。地点搜索负责提供候选区域分析所需的核心空间数据行政区划接口负责支撑首页城市选择与城市级分析范围的确定。两者进行衔接产品的搜索边界、交互方式和结果输出就能自然统一到同一套逻辑里。地点搜索更适合城市级、圆形区域和矩形区域分析这让选址结果能够稳定落在明确的空间范围内。行政区划接口又天然适合生成城市列表控件因此首页交互最终收敛为核心城市快速选择。还有一个很容易被低估的点是地图可视化。JavaScript API GL 提供的点标记、信息窗体、多边形和更丰富的可视化能力让地图分析页不只是看起来像个地图而是真正能承载判断过程。左侧候选区域列表和右侧地图主视图是一起工作的。用户看分数的时候地图上的区域高亮、竞品分布、办公点位和地铁站位置会同时给出空间证据。这样一来腾讯位置服务在这个项目里的存在感就不需要靠反复强调来获得因为每一层能力都直接参与了产品结果。三、如何使用 AI 串联为可用流程用户输入的永远是人话。系统需要的却是结构化条件。这中间如果没有一个可靠的转换层地图分析一定会出现很大误差。项目里 AI 的第一个职责就是把自然语言需求拆成城市、业态、目标客群、交通偏好、竞争容忍度和配套偏好这些字段。结构化意图出来以后服务端会基于腾讯位置服务检索办公点位、地铁站、商场、餐饮和竞品门店再围绕这些空间要素生成候选区域。这里我没有做那种看起来很高级、实际很难解释的全城网格而是把候选区域收成几类空间特征更明显的方向。办公导向型区域、交通导向型区域、商业配套导向型区域。这样处理以后地图上的差异、左侧候选区域卡片和后面的报告解释才能真正对应起来。评分模型也是项目里一个反复重写的部分。最早的版本分数虽然能算出来但区分度很差。多个区域综合分一样子项分数经常是满分或者低分看起来更像硬阈值判断。后面我把这一层改成了连续值评分。客群匹配度和办公点位数量、密度、分布共同相关交通便利度和地铁站数量、最近距离共同相关竞争压力由竞品数量、密度和最近竞品距离共同影响设施成熟度则围绕商场、餐饮和便利设施分布来估算。这个变化一出来左侧候选区域列表终于有了层次地图上的区域差异也开始真正服务于判断。AI 在这条链路里的第二个职责是结果增强解释。系统不会凭空推荐区域解释总是在腾讯位置服务检索结果和评分结果之后出现。项目做到中后期我还把增强链路改成了渐进式处理。基础分析先返回让页面先可用增强解释在后台继续跑。这个调整特别现实。因为真实项目里模型响应速度、网络波动、配置问题都会影响链路稳定性。改成渐进式以后用户先能看到地图和候选区域再等待系统自动增强分析说明整体体验会平顺很多。这里还有一个很值得单独提出来说的地方。开发过程里技能调用不是一个点缀而是真实存在的工作流。前端地图分析页的搭建、交互和图层处理我都配合 TencentMap_jsapi_skills 做过实际使用大幅度降低了开发的工作量。四、在开发过程中不断提升用户体验作为一名从开发一路走过来的产品经理我充分理解能跑通和能上线是两回事。一个页面能展示结果不代表它已经像一个产品。这个项目往前推进的时候我越来越在意一个问题用户第一次打开以后能不能很顺地理解整个流程。也正因为这样后面的很多交互都做了进一步优化。城市选择器从全量搜索一路收回到核心城市快速选择原因很现实。产品现在的目标是让用户尽快进入分析而不是先在首页做复杂筛选。右上角的本地连接设置也做了专门优化。地图和 AI 配置都由用户自己提供配置只保存在当前浏览器中这样项目上线以后不会默认消耗绑定账号用户都也可以直接拿自己的应用的 Key 来体验。这个取舍对产品上线很重要。它决定了项目到底是一个只能本地演示的工程稿还是一个别人能真正点开试用的产品原型。报告页是另一个让我觉得项目终于成形的地方。地图页负责空间判断报告页负责把结论沉淀下来。需求摘要、候选区域总览、首推区域分析、评分方法说明、风险提示、下一步建议再加上打印版和 PDF 导出这一整套内容出现以后产品就不再只是一个有地图的分析页面而开始有了可交付结果。对选址这类场景来说这一步特别关键。因为很多判断最后都要回到讨论和决策上报告把地图里的空间证据沉成了人能带走、能复盘的东西。项目走到这里以后腾讯位置服务的价值也会变得更清楚。它在这个产品里提供的从来都不只是地图底图。首页城市选择要靠行政区划能力收住交互地图分析页要靠 JSAPI GL 把区域、图层和点位联动起来候选区域分析要靠地点搜索拿到空间要素报告里的判断也都建立在这些结果之上。总结MapSite AI 做下来我最清楚的一点就是地图一旦进入真实业务场景价值是巨大的。它不再只是把信息放到页面上而是开始参与理解、筛选和判断。腾讯位置服务给了这个项目一个非常扎实的底座。Map Skills 让前端地图页在开发过程中更容易执行地点搜索、行政区划和地图可视化能力让选址分析真正有了空间依据。AI 把自然语言理解和结果解释接了上来最后从输入到报告形成了一个完整闭环。MapSite AI 现在已经是一个可以体验、也可以继续迭代的产品原型。对这种项目来说真正有说服力的地方永远都在那些上线以后用户能马上感受到的细节里。腾讯位置服务在这里的意义也正是在这些细节里被一步一步放大出来的。