把一句话变成一张能打开就演示的地图看板——这次腾讯地图想卖的不是地图，是「谁替你把地图用起来」。

一句话换来一张看板

2026 年 10 月 30 日的腾讯全球数字生态大会上，腾讯地图把桌面端 AI 地图工作台 LBSwork 正式放出来。它的用法和聊天框差不多：在输入框里写清场景，选一位专家，剩下的交给它。官方给的示例是「帮我创建一个区域人群分析的地图看板应用」，接下来它会自己规划看板结构、拉行政区划边界、叠近三十天的客流热力、算人群画像，最后生成一个能直接打开的本地预览页面。

官方放出的这个案例里，可视化专家用了 3 分 42 秒跑完，产出是一个 React 加 JSAPI GL 的工程，十四个文件。这件事的意义不在「生成了多少行代码」，而在于交付物的形态：不是一个截图、一份 PDF，而是一个可以改、可以继续迭代、也可以拿去演示的页面。想换城市、想加图表，接着说就行。

七位专家，各守一段流程

产品把能力按场景拆成七位「专家」，构成它所说的地图智囊团：地图可视化负责把点位、轨迹、区域和人群数据做成看板、大屏或足迹地图；日常出行把散落的地点排成按天走的行程；营销洞察用已授权的位置大数据看客流规模、客群画像和客源范围；零售选址把团队自己的选址标准沉淀成知识库，评新点位时直接调用，也能基于已有门店数据给新店做销量预测；网约车方向偏事后归因，拿一张反馈工单去判断到底是不是导航的问题，并给出一段能直接回给乘客的说法。人群热力和物流履约两个方向标着即将上线，前者对比多个区域的分时热度，后者整理配送地址、标出需要核对的地点并给出多点路线参考。

把场景拆到这个粒度，好处是提示词不用自己编。每一类需求背后对应的数据源、指标口径、输出格式都已经固化，用户只需要描述具体业务，不用先学会怎么跟大模型解释什么叫商圈、什么叫客流。

真正难的不是画图，是口径

时空数据最容易出事的地方从来不是可视化。三家门店的客流不能直接相加，因为很可能是同一批人；河边商铺算五百米覆盖，河对岸的人根本过不来。这类错误在人工分析里靠经验规避，换成模型就很容易一本正经地算错。

LBSwork 的应对是把管控做进流程：开工前先锁定统计口径，执行过程中由框架全程盯着，交付时不仅要给结论，还要带上支撑结论的证据。官方把这套底座叫时空 Harness，和 WorkBuddy 同源。它想解决的是「换掉底层模型，业务代码和数据契约都不用动」——对做行业方案的人来说，这比单点功能更有价值，因为模型会迭代，口径不能漂。

它面向的是谁

官网写得很清楚：零售、文旅、出行这类需要「看位置 + 看人群」一起决策的行业客户，以及地图方向的个人开发者。连锁品牌评估一个新点位、商圈做活动前的客群测算、文旅项目判断客流来源，这些活的共同点是要把空间关系和数据口径捏在一起，而这恰好是通用大模型最不擅长的部分。

桌面端的结构也能看出取向：左边是新建对话、地图智囊团、知识库、控制台，还有专家·技能·连接器。知识库这一项意味着企业可以把自己的选址标准、行业规则喂进去，让它按自家口径出结论，而不是每次都从通用常识开始。

现在还进不去

需要说清楚的一点是：官网页面上挂的按钮是「申请内测资格」，不是下载。也就是说它目前还没有对所有人开放，普通用户想试试得先申请。另外人群热力和物流履约两位专家标着即将上线，现阶段能完整体验的是前五个方向。

收费方式官网没有公布，从定位看更可能是面向企业客户的产品。对只是想在地图上标几个点的人来说，它大概率是重了；但对每周都要回答「这个位置行不行」的人来说，把重复的分析流程压成一句话，省下的是真金白银的时间。

LBSwork 的野心不在替代地图，而在把地图从「查一下」变成「算一遍」。它卖的是口径和证据，是让每一次选址、每一次投放复盘都能被追溯的那套流程——这恰好也是 AI 进入传统行业时最容易被跳过、又最不能跳过的一步。