从事门店选址工作的人，几乎都经历过那种信息过载带来的混乱感。摊开地图，搜索框中填满了各类关键词——办公楼、地铁站、商场、竞品门店……这些信息点如潮水般涌来，但脑海中的判断却越来越零散。地图固然将世界呈现在你眼前，可真正的难题始终未变：你该如何将这些碎片化的信息，拼凑成一个能够落地的决策？

MapSite AI 正是为了解决这一痛点而生的。它的目标十分明确：打造一款面向真实选址场景的 AI 地图应用。用户只需描述需求，系统会自行理解，随后调用腾讯位置服务完成地点检索、候选区域筛选、地图展示与报告生成，最终交付一份可读、可比较、可导出的初筛结果。

在这套流程中，地图负责组织空间证据，AI 负责理解与解释，而最终的判断权则交还给决策者。三者缺一不可。

体验地址：https://mapsite-ai.kaminono.com/

演示视频：

MapSite AI 演示

一、选址场景：AI 与地图结合的最佳实践

许多地图类项目起步时，通常倾向于选择一些容易展示的方向，例如自然语言搜索周边、对话式导览或多人路线规划。这些方向确实能体现 AI 与地图结合后的交互变化，但坦白说，如果我们将目光聚焦于更贴近真实业务逻辑的领域，你会发现商业选址这一场景的潜力要大得多。

为什么？因为商业选址本质上是一个“判断”问题。用户真正关心的并非“附近有什么”，而是“哪里更值得看”、“为什么值得看”、“与另外两个区域相比，差距究竟在哪里”。

单靠地图页面很难解决这一问题。地图可以展示信息，但无法自动帮你整理判断依据。同样，仅依靠大模型也不行——它能组织语言，却无法脱离真实的、带有经纬度的空间数据凭空下结论。只有当地图能力与 AI 理解真正“握手”时，项目才能成为一个可实际应用于具体业务决策的产品。

在产品落地过程中，我选择了“咖啡店选址初筛”作为主场景来跑通整条链路。这一选择基于两个现实因素。第一，咖啡店的需求足够常见且典型——办公人群密度、地铁可达性、商业配套成熟度、竞品压力等要素，大家都易于理解。第二，这类空间要素与腾讯位置服务的地点搜索、地图展示、行政区划、可视化能力的整合非常紧密，产品更容易构建完整的业务闭环。

image-20260415221303968

用户输入一段类似“面向白领、靠近办公楼、交通方便、竞争压力适中”的自然语言需求，系统便能将其拆解为可执行的空间条件。分析完数据后，会生成候选区域、地图呈现以及一份详尽的评分分析报告。

当然，这个项目的能力边界并不局限于咖啡店。这套方法同样可以延伸至轻食店、茶饮店、社区烘焙店、便利零售甚至小型宠物门店。不同业态关注的侧重点或许不同——有的更看重办公客群，有的更关注社区密度，有的更在意交通可达性——但底层的逻辑是相通的：先将自然语言需求翻译为结构化条件，再利用腾讯位置服务提供的空间数据进行筛选与结果解释。

归根结底，地图一旦进入真实业务场景，其最重要的价值就在于它开始参与判断过程。而 AI 进入这一场景后，最重要的价值则在于它能够将模糊输入翻译为结构化条件，再将结果解释得让普通人一目了然。

二、腾讯位置服务：稳固的工程底座

MapSite AI 能真正落地，并非依赖某个大模型突然“开窍”，而是基于腾讯位置服务将地图前端、LBS 服务与 WebService 能力打造为一条可无缝拼接的工程链。

平时说“接入地图”，很容易将这件事想得简单。实际进入产品开发阶段后，你会很快发现：地图并非只是放个底图就完事了。地图实例如何初始化？候选区域如何绘制？多边形与点位如何联动？图层如何切换？行政区划如何接入首页的城市选择？地点搜索如何引入分析流程？这些具体问题，都必须逐一解决。

腾讯位置服务的 Map Skills 在此发挥了关键作用。在前端地图分析页的搭建阶段，我使用了 TencentMap_jsapi_skills 对应的能力。地图初始化、覆盖物绘制、图层管理、事件系统与可视化渲染，这些能力让地图页从一开始就拥有了清晰的开发路径。它并未替我自动完成产品设计，但确实大幅减少了前端地图集成阶段的试错成本。最终，地图分析页能够实现候选区域高亮、点位联动、图层切换与区域详情同步，很大程度上正是因为这层能力足够扎实。

腾讯位置服务的 WebService 能力更是整条选址分析链路的基石。地点搜索负责提供候选区域分析所需的核心空间数据，行政区划接口则负责支撑首页的城市选择与城市级分析范围的确定。一旦两者衔接顺畅，产品的搜索边界、交互方式与结果输出就能自然统一到同一套逻辑中。地点搜索更适合城市级、圆形区域与矩形区域分析，这确保了选址结果能稳定落在明确的空间范围内。而行政区划接口天然适合生成城市列表控件，因此首页交互最终收敛为对核心城市的快速选择。

还有一个常被低估的要点，是地图的可视化能力。JavaScript API GL 提供的点标记、信息窗体、多边形以及更丰富的可视化能力，使地图分析页不仅看起来像张地图，更能真正承载判断过程。左侧的候选区域列表与右侧的地图主视图协同工作。当用户查看分数时，地图上的区域高亮、竞品分布、办公点位与地铁站位置会同步提供空间证据。这样一来，腾讯位置服务在这个项目中的存在感，无需通过反复强调来获得，因为每一层能力都直接参与了产品结果的生成。

三、如何用 AI 串联出可用流程

用户输入的永远是“人话”，而系统需要的却是结构化的条件。在这之间，若没有一个可靠的转换层，地图分析必然会出现巨大误差。项目中 AI 的第一个职责，就是把自然语言需求拆解为城市、业态、目标客群、交通偏好、竞争容忍度与配套偏好等字段。

结构化意图生成后，服务端将基于腾讯位置服务检索办公点位、地铁站、商场、餐饮与竞品门店，再围绕这些空间要素生成候选区域。这里，我并未采用那种看起来很高级、实际却难以解释的“全城网格”，而是将候选区域收拢为几类空间特征更明显的方向：办公导向型区域、交通导向型区域、商业配套导向型区域。这样处理后，地图上的差异、左侧候选区域卡片的内容以及后续的报告解释才能真正对应起来，用户不易产生疑惑。

评分模型也是项目中反复重写的一个模块。最初版本虽能计算出分数，但区分度很差。多个区域的综合得分相同，子项分数则常为满分或低分，看起来就像一个硬阈值判断。后来我将其改为连续值评分：客群匹配度与办公点位数量、密度、分布共同相关；交通便利度与地铁站数量、最近距离共同相关；竞争压力由竞品数量、密度与最近竞品距离共同影响；设施成熟度则依据商场、餐饮与便利设施分布来估算。这一调整完成后，左侧的候选区域列表终于有了层次感，地图上的区域差异也开始真正服务于用户的判断。

AI 在这条链路中的第二个职责，是对结果的增强解释。系统不会凭空推荐区域，解释总是发生在腾讯位置服务检索结果与评分结果之后。项目进行到中后期，我还将增强链路改为了渐进式处理：基础分析先返回，让页面先可用，增强解释在后台继续运行。这一调整十分务实——真实项目中，模型响应速度、网络波动、配置问题都会影响链路的稳定性。改为渐进式后，用户先能看到地图与候选区域，再等待系统自动增强分析说明，整体体验变得流畅了许多。

这里还有一个值得单独提及的点。在开发过程中，技能调用并非可有可无的点缀，而是真实存在的工作流。前端地图分析页的搭建、交互与图层处理，我都配合 TencentMap_jsapi_skills 进行过实际使用，这极大降低了我的开发工作量。

四、项目结构与核心代码展示

整体流程从首页输入开始。前端先完成城市选择与本地配置校验，再将需求提交至服务端分析入口。服务端一方面通过规则兜底，快速生成首版分析结果；另一方面结合 AI 意图解析能力，将模糊需求拆解为目标客群、竞争容忍度、交通偏好等结构化条件。随后，系统调用腾讯位置服务的地理编码、POI 检索与空间数据能力，生成多个候选区域，并基于客群匹配、交通便利、竞争压力、设施成熟度等维度完成综合评分。最终，分析结果会同时落入地图分析页与报告页。前者突出候选区域、竞品点位与交通设施的空间分布，后者则以更适合阅读与交付的方式输出结论，并支持打印版与 PDF 导出。

我们详细分析一下其中的地图分析页初始化与候选区域绘制页面。以下核心代码的作用是：负责加载腾讯地图 SDK、初始化地图实例、绘制候选区域多边形，以及叠加竞品、办公、地铁等 POI 图层。

代码语言：javascript

复制

useEffect(() => {
    if (!configLoaded) return;
    const resolvedMapKey = resolveClientMapKey(config);
    if (!resolvedMapKey.hasMapKey) {
        setMapStatus("error");
        setStatusTitle("地图 Key 缺失，请先完成地图配置");
        return;
    }
    loadTencentMapScript(resolvedMapKey.mapKey, { forceReload: false })
        .then(() => {
            const map = new window.TMap.Map(mapContainerRef.current, {
                center: new window.TMap.LatLng(centerCoord[1], centerCoord[0]),
                zoom: 13,
                viewMode: "2D",
            });
            mapRef.current = map;
            infoWindowRef.current = new window.TMap.InfoWindow({
                map,
                position: new window.TMap.LatLng(centerCoord[1], centerCoord[0]),
                offset: { x: 0, y: -32 },
            });
            infoWindowRef.current.close();
            map.once("tilesloaded", () => {
                setMapStatus("ready");
            });
        })
        .catch(() => {
            setMapStatus("error");
            setStatusTitle("腾讯地图脚本加载失败");
        });
}, [config, configLoaded, centerCoord]);

useEffect(() => {
    if (!mapRef.current || !window.TMap || mapStatus === "error") return;
    const map = mapRef.current;
    const polygonGeometries = layers.candidates
        ? regions.map((region) => ({
                id: region.id,
                styleId: region.id === activeRegionId ? "active" : "normal",
                paths: (region.bounds || []).map(
                    (coord) => new window.TMap.LatLng(coord[1], coord[0])
                ),
                properties: { name: region.name },
          }))
        : [];
    polygonsRef.current = new window.TMap.MultiPolygon({
        map,
        styles: {
            normal: new window.TMap.PolygonStyle({
                color: "rgba(59, 130, 246, 0.2)",
                showBorder: true,
                borderColor: "rgba(59, 130, 246, 0.8)",
                borderWidth: 2,
            }),
            active: new window.TMap.PolygonStyle({
                color: "rgba(239, 68, 68, 0.3)",
                showBorder: true,
                borderColor: "rgba(239, 68, 68, 1)",
                borderWidth: 3,
            }),
        },
        geometries: polygonGeometries,
    });
    polygonsRef.current.on("click", (e) => {
        if (e.geometry?.id) onRegionSelect(e.geometry.id);
    });
}, [mapStatus, regions, activeRegionId, onRegionSelect, layers]);

五、在开发过程中持续提升用户体验

作为一名从开发一线走过来的产品经理，我深知“能跑通”与“能上线”完全是两码事。一个页面能展示结果，并不意味着它已经像一个产品。在这个项目的持续推进中，我越来越在意一个问题：用户第一次打开后，能否顺畅地理解整个流程？正因如此，后面的许多交互都做了进一步优化。

例如城市选择器，最初采用全量搜索，后来逐步收紧为“核心城市快速选择”。原因很现实：当前的产品目标是让用户尽快进入分析环节，而非在首页进行复杂的筛选。右上角的本地连接设置也做了专项优化。地图与 AI 的配置均由用户自己提供，且配置仅保存在当前浏览器中。这样一来，项目上线后不会默认消耗我们的绑定账号，用户可直接使用自己应用的 Key 来体验。这一取舍对产品上线至关重要，它决定了这个项目究竟是一个只能本地演示的工程稿，还是一个他人能真正点开试用的产品原型。

报告页是另一个让我觉得项目终于“成形”的环节。地图页负责空间判断，报告页则负责将结论沉淀下来。需求摘要、候选区域总览、首推区域分析、评分方法说明、风险提示、下一步建议，再加上打印版与 PDF 导出功能——这一整套内容出现后，产品就不再只是一个带有地图的分析页面，而是开始拥有可交付的成果。对选址这类场景来说，这一步尤为关键。因为许多判断最终需要回归到讨论与决策，报告能够将地图中的空间证据，沉淀为一份他人可以带走、可以复盘的材料。

项目走到这一步，腾讯位置服务的价值也变得更加清晰。它在产品中扮演的角色，从来都不仅仅是提供一张地图底图。首页的城市选择需要依赖行政区划能力来收拢交互，地图分析页需要依靠 JSAPI GL 将区域、图层与点位联动起来，候选区域分析需要借助地点搜索获取空间要素，而报告中的判断也都建立在这些结果之上。

总结

MapSite AI 完成之后，我最深刻的体会是：地图一旦进入真实业务场景，其价值将变得巨大。它不再仅是被动地将信息堆砌到页面上，而是开始主动参与理解、筛选与判断的过程。

腾讯位置服务为这个项目提供了一个极为扎实的底座。Map Skills 使前端地图页在开发过程中更易上手；地点搜索、行政区划与地图可视化能力，让选址分析真正拥有了空间依据；AI 则将自然语言理解与结果解释衔接起来。最终，从输入到报告，形成了一个完整的闭环。

MapSite AI 目前已经是一个可以体验、也能够继续迭代的产品原型。对于这类项目而言，真正有说服力的地方，永远都体现在那些上线后用户能立刻感受到的细节中。而腾讯位置服务的意义，也正是在这些细节里，被一步一步地放大的。

* AI润色输出，仅供参考