
去年帮一个做茶饮连锁的客户做新市场拓展跑了三天现场回来运营负责人对我说“我在这行做了八年哪个路口能开哪个门口是死位闻都闻得出来。”后来他的“鼻子”失灵了三次——三个凭经验敲定的点位开业后日均流水比模型测算低了四成。从那以后团队才认真考虑把腾讯地图的数据接口和AI模型放进选址流程用智能选址替代经验判断。这篇文章就把整套实施方案摊开来讲包括数据怎么取、模型怎么练、点位怎么排优先级以及那些常规文档里不会写出来的坑。我按真实项目推进的顺序来写不绕弯子。1. 想清楚一件事经验选址到底输在哪1.1 经验主义的三个盲区先说结论经验不是没用而是不可靠。我在选址项目里见过太多“老师傅”他们确实能一眼看出某个门面的气场不对但这种判断有三个绕不开的盲区。第一个人经验覆盖的样本极其有限。一个人再勤奋一辈子真正深度观察过的门店也就几百个而且大多集中在某几个商圈、某几条街。换一个城市、换一种消费层级这套经验立即失效。有个客户在沿海城市做了十年餐饮跑到内陆新一线城市开首店觉得“商业街转角”一定是好位置结果租金贵、人流杂、周边客群消费力跟不上三个月就撤了。他踩过的样本根本不足以支撑陌生市场的判断。第二经验是时点的而商圈是动态的。城市更新、地铁开通、新小区交付、大型商业体开业都会在半年内把一条街的客群结构彻底改写。经验往往是过去五年、十年的沉淀它天然滞后于变化。某社区底商两年前还是“老年一条街”周边新交付了两个写字楼之后中午外卖订单爆发式增长这种突变靠记忆是感知不到的只能靠数据捕捉。第三经验无法形成可复制的决策标准。老师说“感觉对了”但“感觉”没法拆解成指标没法让北京、上海、成都三个城市的拓展同事用同一把尺子去比较点位。结果就是公司开三五十家店之后复盘发现选址水平忽高忽低好点位靠运气坏点位交学费。这三个盲区叠加在一起本质上是把一次动辄几十万上百万的投资决策押在了一个不可量化、不可移植、不可复盘的判断系统上。这不是人的问题是方法论的问题。1.2 腾讯地图AI能改变什么把腾讯地图开放平台的数据能力接进来再加上AI模型做打分排序核心不是“取代人”而是给选址这件事装上一套可重复、可解释、可迭代的决策引擎。腾讯位置服务能提供的东西比我早期做选址时想象得多。POI兴趣点数据、行政区划边界、路径规划与距离计算、逆地理编码、客流热力相关能力这些原本分散在不同渠道的信息现在可以统一通过API拉下来变成结构化的表格。这是整个智能选址的“原料”。AI模型在这个流程里的角色是把经验变成权重。老师傅说“人流重要、竞争重要、交通重要”这句话只停留在口头。模型能做的是把网点周边的每一个变量量化之后和真实经营结果做回归拟合最后得出一个“什么因素到底起多大作用”的结论。这个结论不依赖某个人的经历而是依赖几百个门店的真实数据。我反复跟客户强调一个边界AI选址不是算命它解决的是“在同样条件下哪个候选点更值得去看”的问题实勘环节仍然必不可少。但至少你的团队出门看店之前手里已经有了一份按统一标准算出来的评分和排序不用再全城漫无目的地逛。这就是智能选址最实在的价值。2. 数据原料怎么拿腾讯位置服务取数全解析2.1 先认识你要用的几个数据维度选址模型的大部分特征都可以从腾讯地图开放平台的数据能力里找到对应来源。我把常用的数据维度和用途整理成了一张表做项目之前先把这张表过一遍思路会清晰很多。数据维度对应能力选址用途关键注意兴趣点POI地点搜索 / 周边搜索识别周边餐饮、住宅、写字楼、学校、商场等配套需要统一分类口径不同接口返回的category可能不一致商圈边界行政区划 / 地理围栏圈定候选区域生成网格底图行政区边界不等于实际商圈需要结合道路和河流做修正交通可达性路径规划 / 距离计算计算候选点到地铁站、公交站、主干道的距离与通勤时间直线距离和实际步行距离差别很大尽量用导航距离人流热力热力图相关能力判断区域全天不同时段的人流密度热力数据只能看相对趋势不能当成绝对人流量逆地理编码逆地址解析把门店坐标还原成可读地址方便实勘注意坐标系腾讯用的是GCJ-02不要混用门店标注地点检索 / 关键词筛选统计同品类竞对数量评估竞争强度线上POI不等于真实营业门店需要过滤无效点只看这张表可能觉得抽象我展开说两个最关键的点。POI数据是整个选址模型最基础的特征来源。你需要统计候选点周边一公里内有多少餐饮店、多少便利店、多少住宅小区、多少写字楼、多少学校。这些数字本身就是很强的信号如果一个区域周边POI总量很大但餐饮类占比极低说明这个区域的商业氛围可能还不成熟消费者路过但不消费进场风险偏高。反过来如果餐饮POI密度极高但同品类已经饱和说明竞争压力大新品牌进去容易被分流。另一个容易被低估的是交通可达性。很多人选址只看“离地铁多远”或者“是不是主干道”但忽略了实际步行路径。有些位置地图上看着离地铁站三百米走过去要绕一个天桥多走七八分钟这种隐性损耗会直接拉低进店率。腾讯地图路径规划能力的价值就在这里可以把坐标对坐标的猜测换成一条可计算的实际动线。2.2 从零开始调一次POI检索取数这块我给一个可以直接跑的思路用Python请求腾讯位置服务的周边搜索接口把某个候选点周边一公里内的奶茶店拉出来。import requests import time API_KEY 你的Key # 在腾讯位置服务控制台申请 BASE_URL https://apis.map.qq.com/ws/place/v1/search params { keyword: 奶茶, boundary: nearby(30.000000,120.000000,1000), # 演示坐标替换成你的候选点 page_size: 20, page_index: 1, key: API_KEY } resp requests.get(BASE_URL, paramsparams).json() if resp.get(status) 0: pois resp.get(data, []) for poi in pois: title poi.get(title) lat poi[location][lat] lng poi[location][lng] category poi.get(category, ) print(f{title} | 坐标: {lat},{lng} | 分类: {category}) else: print(请求失败, resp.get(message))注意两点。第一boundarynearby(纬度,经度,半径)里的半径单位是米我建议先用1000米做第一轮特征扫描后面再对重点候选点加密到500米因为不同业态的有效辐射半径完全不同便利店看500米咖啡店看1000米大型餐饮甚至要看3000米。第二page_size单次最多返回20条如果同品类POI超过20条要循环翻页拉全不要只取第一页就当成全部数据。讲一个我踩过的细节POI返回结果里常有“重复点”和“交叉点”。同一个商场里的奶茶店可能既出现在“购物服务”分类下又出现在“美食”分类下直接去重会导致统计口径雇ū。我的处理方式是同时保留title和location做联合去重坐标距离在50米以内且店名完全一致的才视为同一家店。还有一个所有人都容易忽略的坑POI数据是“线上标注”不等于“线下真实存在”。有些店已经关了但平台上的POI还挂着有些店是新开的POI还没收录。处理办法是尽量选平台近期的数据快照同时在实勘环节设置“POI存活率”校验项抽查一部分显示的店铺是否真实在营。2.3 配额、Key与爬取策略腾讯位置服务的接口调用不是无限免费每个Key有日配额超出要付费或提额。做选址分析这种场景一次性拉取整个目标区域的数据量很大所以要评估好你的调用规模。我的经验做法是先做一轮“全量缓存”把目标城市的重点商圈、重点城区POI一次性拉下来存到本地数据库或者数仓里后续所有分析都基于这一份快照而不是每次重新请求接口。这样既省钱也避免模型训练过程中数据前后不一致。并发控制也很关键。别为了速度快开几十个线程同时怼接口很容易触发限流。稳妥的做法是控制在每秒1到5个请求加一个重试机制遇到限流错误就退避等待。顺带提醒一句Key和签名信息不要明文提交到代码仓库之前就有团队把Key传到了内部分享平台第二天账号被刷爆损失了不少配额。放到环境变量或者独立的配置服务里权限收窄避免被误用。3. AI模型怎么搭从“地图上的点”到“可比较的分数”3.1 为什么要把城市切成网格有了地图数据和POI数据之后最自然的想法可能是客户给了几个候选点位我把这几个位置周边的数据拉出来不就行了。但在实操中这种做法有一个很大的问题候选点位是你自己预设的你只评估了“你觉得可能行”的地方那些真正的黄金位置恰恰可能在你的盲区里。所以要跳出“点评估”先把整个目标区域切成格子每个格子都算出评分再去里面找高分格子的具体店铺地址。网格大小我一般默认500米乘500米再根据业态微调。便利店、奶茶店这类小体量业态辐射范围窄300到500米合适超市、健身房这种目的性消费800到1000米合适。切得太小数据稀疏特征波动大切得太大又丢失了位置差异。网格生成可以直接用经纬度坐标做基础切分也可以用行政区边界做约束避免把一个商圈切成两半。我的习惯是“先按行政区拿边界再在边界内铺网格”这样后续汇报给业务方的时候能顺着他们熟悉的区域概念讲故事而不是抛出一堆编号。3.2 特征工程决定模型上限的动作算法再强特征拉胯也白搭。这部分的功夫远比调参重要。我通常给每个网格或候选点算以下几类特征供应密度类周边1公里内餐饮POI数、零售POI数、生活服务POI数。衡量区域商业配套的丰富程度。需求密度类周边住宅小区数、写字楼数、学校数。住宅小区代表家庭客群写字楼代表白领客群学校代表学生客群不同业态对应的人群结构完全不同。竞争强度类同品类POI的数量和密度占比。比如做奶茶就看周边奶茶店数量以及茶饮店在整体餐饮店中的占比。可达性类到最近地铁站的距离、到公交站的距离、到主干道的距离用路径规划接口拿实际距离而非直线距离。人流热力类网格范围内多个时段的热力均值以及早晚峰值差。聚集效应类周边大型商场的数量、知名连锁品牌的数量。这种“跟着大树走”的逻辑对餐饮非常管用。有一个细节值得单独说不要只算“绝对值”还要算“结构值”。举个例子一个区域周边POI总量5000另一个区域周边POI总量5500看上去差不多但前者的餐饮占比是30%后者是8%两者的商业气质完全不一样。所以我做特征工程时除了数量类特征还会算“品类占比”、“品类多样性指数”让模型能捕捉到区域的商业结构特征。特征全部算完之后一定要做标准化和异常值处理。比如某个候选点旁边正好有一个大型批发市场POI数量爆表如果不做处理模型会被这个样本带偏。3.3 标签、模型与解释性选址模型本质上是一个回归问题用候选点的特征预测它的经营表现。经营表现的标签我优先用“日均营业额”或“坪效”因为这两个指标最直接反映选址质量。标签从哪来从现有门店来。假设客户已经有80家门店每家门店的地理坐标、周边特征、真实营业额都能拿到那就是80个训练样本。把每个门店映射到对应的网格和候选点上把周边的特征数据拼上去就能得到“特征标签”的训练集。样本量不大时优先用XGBoost或者LightGBM这类树模型它们对非线性关系和小样本都相对友好。如果样本更少线性回归或者逻辑回归也可以权重更直观但表达能力有限。选模型不是越复杂越好而是要看你的样本量撑不撑得起模型复杂度。还有一个特别重要的原则不要用随机切分验证模型要用时间切分。比如用前三年开的门店做训练用最近半年新开的店做验证。因为选址模型的本质是预测“未来新开店”的表现如果用过去的数据随机抽一部分来验证模型学到的可能是历史噪音到了真实场景效果会打折扣。关于解释性我一直觉得这是项目能落地的关键。模型跑完业务负责人肯定要问“为什么这个点位分数高”“为什么那个点位不行”。我用SHAP值分析每个特征的贡献度输出类似“这个点位得分高主要是因为周边3公里内白领POI数量超过城市90%的网格且同品类竞争密度低于平均”这样的解释。业务方听得懂就能信任模型只有信任模型才能被真正用起来。4. 实操全流程某连锁茶饮品牌的选址落地4.1 先定需求再谈技术这个案例是我服务过的一个虚拟项目某连锁茶饮品牌下面叫A品牌计划在某新一线城市密集开店。项目启动后的第一件事不是拉数据而是开需求对齐会把开店逻辑彻底聊清楚。A品牌的单店模型是面积30到50平米客单价12到18元目标人群是18到28岁的年轻消费者。基于这个模型我们确定了几条硬性筛选标准候选点周边800米内必须覆盖至少一所高校或者一个大型写字楼同品类茶饮店密度不能高于区域平均值的1.5倍距离地铁站步行10分钟以内。这几条标准看起来简单但它把后续的数据分析范围缩小了一大圈。如果不先定这种规则直接对全城所有网格跑模型输出的结果一定会被跑去奇怪的位置。4.2 取数落地把三类数据一次拉齐这个项目里我做了三类数据拉取分别是POI数据、热力数据和交通路径数据。POI数据走的是腾讯位置服务的地点搜索我们按照网格中心点逐个请求每个点分别检索餐饮、购物、生活服务、教育、医疗等十几个大类拉完以后统一做去重、归一化和坐标清洗最终落到一张“网格POI特征表”里。热力数据不是直接一个接口就返回“这里人流量多少”的而是要看平台开放的具体能力。我们的处理方式是每天分早、中、晚、夜四个时段抓取网格区域的热力快照然后求均值、峰值和波动方差存成热力特征。交通路径数据是用路径规划接口批量算的。候选点POI数据有几千个不可能每个都手动查路径所以写了批处理脚本输入候选点和地铁站的坐标对批量返回实际步行距离和时间。这一阶段最花时间的其实是数据清洗不是接口调用。我们的量级大概在百万级POI原始记录清洗规则写了十几条包括坐标越界剔除、重复POI合并、异常分类修正、停业POI过滤等等。花两天多把数据洗干净后面建模就顺畅多了。4.3 候选点评分模型怎么给出Top榜单特征表拼完之后我们把A品牌已有的49家门店数据映射到网格上用XGBoost做了一个回归模型预测候选网格的“预估坪效”。模型训练完后我们给目标城区所有的候选网格打分再叠加前面定的三条业务硬性标准做过滤最终得到一份Top 20的候选点清单。我简化一下当时输出的评分表结构大概长这样网格编号综合评分预估坪效周边POI总量同品类竞对距地铁站步行距离热力峰值时段G-104292.5高621023240米午晚双峰G-087189.2较高548031510米晚峰显著G-203387.8较高469012780米午峰显著G-115684.1中高38809950米波动较大G-231082.6中352015320米夜间活跃看到这张表业务方问的第一个问题就是“G-1042是不是就直接选它”我提醒他们模型排序只能说明“从数据特征来看这个网格的综合条件更优”但高分网格里具体哪个门面能拿下来、租金是否划算、物业条件是否合适这些必须去现场看。所以我们的流程在模型评分之后永远跟着一个实勘环节。4.4 实勘复核用一份清单代替漫无目的地还是地逛街实勘清单我列了十几个经过多次迭代后留下的检查项这里挑重要的说几个第一看“门脸的实际可见性”。地图数据不会告诉你这个门面是不是被一棵大树挡住是不是在台阶下面是不是被电箱遮住了招牌。这些因素对自然进店率影响极大模型算不出来只能靠人看。第二看“动线上的真实人流”。数据热力只能告诉你这个区域人多不多但人是从哪个方向来的、会不会经过这个门面必须实地站半小时观察。我见过一个点位离地铁口很近数据分很高但实际出口在马路对面大量的客流根本不从这边走一整天都是“看得到人、进不到店”。第三看“邻居的生意状态”。周边店铺如果换手率很高说明这个位置的租金预期可能超过了实际经营承载能力要谨慎。实勘时和旁边店老板聊几句问“你们开业多久了”“平时一天大概多少单”能拿到比任何模型都鲜活的信息。实勘信息整理之后我们会把人工修正项叠加到模型分数上最后形成一个“最终建议排名”。A品牌这个项目第一批落地了8家店开业三个月后回头看7家店的日均坪效达到了预期只有1家因为新修路改道导致客流动线变化未达预期。这个结果不能说全是模型的功劳但至少比之前那“三次失灵”靠谱得多。5. 常见问题与避坑清单5.1 坐标系和数据口径的坑腾讯地图用的坐标系是GCJ-02也就是俗称的“火星坐标系”地球坐标WGS-84和它之间差了几百米。如果你拿GPS设备记录的WGS-84坐标直接去查腾讯接口或者反过来拿腾讯返回的坐标去和第三方地图数据做空间计算会出大问题。我见过有人把两套坐标系的数据混在一起算“距离最近的地铁站”结果明明在同一位置的两个点算出来距离六百多米整个可达性特征全部失真。所以项目一开始就统一约定所有进入模型的坐标都用GCJ-02接口返回什么坐标系入库前就统一转换不留隐患。另外POI分类的口径也要统一。腾讯地图的POI分类层次比较细不同行业、不同接口返回的category格式可能不一样做特征统计之前要先把分类字段做归一化。比如“餐饮服务”下面可能有中餐厅、快餐厅、甜品店、奶茶店等一堆子类你要按自己的业务口径重新归类否则统计出来的“餐饮数量”忽高忽低模型特征就废了。5.2 模型常见问题样本不均衡和时间漂移连锁品牌在做选址模型时一个特别常见的问题是样本不均衡。好门店可能只有十几家而差的门店可能有几十家模型会学成“预测大多数”的倾向对真正有价值的好点位反而不敏感。我的做法是给少数类样本加权重或者用回归问题而不是分类问题去建模让模型去拟合“经营表现连续值”而不是硬分割成好店和坏店。还有一个绕不开的问题叫“时间漂移”。商圈特征会因为地铁通车、商场开业、政策变化而剧烈波动去年训练出来的模型如果直接用于今年很可能失效。所以选址模型的迭代频率至少一个季度要重训一次每次加入新开的门店数据和最新的POI快照。迭代机制怎么做我建议在门店管理系统里加一个“选址复盘”模块每家店开业后定期回填真实营业额和客流数据每季度和模型预测值做一次对比。偏差大的网格去查数据源是不是变了、周边业态是不是变了再把变化因素补进模型。这套机制的长期价值比模型本身还大。5.3 落地环节的三个组织问题技术模型再完善落到组织里还有三个容易踩坑的地方。第一个坑是“数据有了但业务方不认”。业务方习惯用自己的经验模型结果和他们直觉不符时第一反应是推翻。处理办法不是强行争论而是打开模型解释面板把影响得分的Top特征列出来用数据告诉他“你看这里是因为周边白领密度高所以分数高”。大多数时候业务方看完就理解了。第二个坑是“业务方全盘交给模型”。反方向的问题也有有些团队觉得模型很牛就等着模型输出一个地址直接去签租约。我的态度永远是模型负责排序人负责决策。模型把一万个候选点压缩成二十个已经大幅降低了实勘成本但最终拍板必须结合租金谈判、物业条件、工程排期这些模型没刻画的因素。第三个坑是“只做一次性建模没有后续维护”。有的项目做完客户觉得“我已经有模型了就够了”然后把数据更新这件事彻底忘掉。半年以后模型预测结果和实际情况偏差越来越大团队又开始吐槽AI不靠谱。这不是AI的错是数据没有保鲜。地图数据是活数据POI在变道路在变热力在变模型必须跟着变。我个人在实际操作中最大的体会是选址模型最大的价值不是“算出一个答案”而是“让团队在同一个坐标系里说话”。以前大家讨论一个点位完全是各凭印象开发说人流好运营说租金低老板说风水好根本没法比较。有了腾讯地图的数据底座和AI评分之后所有候选点都被摆在同一条标尺上分歧从“我觉得”变成了“数据显示”。这个转变才是智能选址真正“赢在起点”的原因。最后分享一个小技巧不要一开始就期望模型给出完美结果。第一版模型哪怕只有70%的准确率只要能帮你把二十个候选点压缩到五个去实勘就已经值回投入了。把每一轮实际开店的结果回填进模型让评分标准跟着真实世界不断修正这套系统会越来越聪明。开店选址这件事从来不是一次性决策而是一条需要持续经营的数据闭环。