一个从 0 到 1 建设、持续迭代 2-3 年的房地产大数据决策系统。项目覆盖产品框架、数据体系、指标口径、GIS 地图、图表分析、市场查询、客户定制和长期运营维护，是我在澜思阶段最完整的数据产品案例之一。
城市地图 / 澜城 CityMap 是面向 房地产开发商、经纪公司、市场研究人员和内部业务团队的城市房地产数据分析与决策系统。
它的核心目标是把上海房地产市场中 分散、复杂、难以直接使用的数据，整理成 可查询、可比较、可分析、可复盘 的产品能力，帮助客户在拿地研判、区域研究、市场监测、竞品分析、项目跟踪和经营复盘中做出更高效的判断。
项目关键词：2-3 年从 0-1 到长期维护、6 大核心模块、房地产全生命周期数据链路、B 端客户交付。
CityMap 的价值集中在两件事：一是把 房地产一级、二级、三级市场 组织成统一产品框架；二是把 土地、新房、二手房数据串成资产全生命周期链路，让系统可以 从土地成本追踪到新房成交，再延伸到二手房流通表现。
CityMap 属于 B 端业务系统，核心价值体现在产品框架、数据体系、功能模块、客户场景和长期交付能力上。
左侧是上海新房供应热力地图，右侧同步呈现年度走势和区域结构。CityMap 将楼盘、区域、时间和指标放在同一个分析界面里，让客户可以从城市空间中理解市场变化。
公开介绍可参考澜城数据官网的城图产品页：城市地图数据分析决策系统。项目重点在于产品规划、数据体系建设和长期迭代工作。
公开侧可以作为业务背书的是一房一万 / RealtyNavi 官网展示的合作伙伴体系，包括 华润置地、龙湖、金地集团、大华地产、万科、华发股份上海公司、绿地控股、保利地产、中海地产、上海地产集团、招商蛇口 等房企和地产相关客户。这类客户背书说明澜思的数据产品能力服务过真实的房地产行业客户，而 CityMap 正是这套 B 端数据能力中的重要系统化产品。
这个项目的前身是 RES 房地产数据分析系统。RES 已经积累了较长周期的房地产数据能力，但随着客户需求从“查数据”逐渐升级到“用数据做决策”，原系统需要完成一次产品化升级：从数据查询工具，升级为围绕城市、区域、土地、新房、二手房、地图和图表组织的综合决策系统。
因此，CityMap 的建设重点是一轮 完整的数据产品重构：
房地产行业的决策高度依赖数据，但数据本身非常复杂。
一线业务人员和开发商客户在做市场判断时，通常需要同时回答很多问题：
在 CityMap 之前，这些判断往往依赖多个系统、人工表格、行业经验和临时数据整理。问题主要集中在四个方面：
| 问题 | 具体表现 | 对业务的影响 |
|---|---|---|
| 数据分散 | 土地、新房、二手房、宏观经济、人口、政策、楼盘资料分布在不同来源 | 研究人员需要反复收集和拼接数据 |
| 口径不统一 | 时间、区域、物业类型、面积段、价格段、成交口径不一致 | 同一问题在不同报表中可能得出不同结论 |
| 分析链路长 | 从查询、筛选、统计、画图到解释结论，需要大量人工操作 | 客户很难快速形成稳定判断 |
| 客户需求差异大 | 开发商、经纪公司、区域用户、研究人员关注的指标和颗粒度不同 | 标准产品必须支持一定程度的自定义和定制 |
CityMap 解决的是房地产数据从“被动查询”到“主动决策”的产品化问题。
项目目标可以拆成三层。
第一层是 数据整合：把土地、新房、二手房、宏观经济、人口、政策、市场资讯、区域板块、项目个案等数据放入统一的数据分析框架中。
第二层是 产品表达：把复杂数据转化为用户可理解的功能模块，包括地图、图表、榜单、查询、资料库和自定义方案。
第三层是 业务决策：让开发商、经纪公司和市场研究人员能围绕城市、区域、项目和竞品形成判断，支持拿地、营销、竞品分析、市场复盘和客户沟通。
对应到产品建设上，我把目标拆成了几个更具体的方向：
在这个项目中，我承担 核心数据产品角色，需要在业务理解、数据结构、产品架构、功能设计、前后端实现讨论和客户落地之间反复拉通。技术方案由开发团队主导确定，我主要参与方案讨论，把复杂的 产品逻辑、数据关系、筛选规则、地图交互和客户使用场景 讲清楚，帮助前端、后端更准确地拆解 实现边界。
我的工作主要包括：
| 工作方向 | 我负责的内容 |
|---|---|
| 产品框架设计 | 梳理 CityMap 的一级模块、二级功能、用户路径和系统结构，将 RES 能力重新组织为新的产品体系 |
| 竞品与业务研究 | 研究中指、克而瑞、天朗等房地产数据产品，判断哪些框架适合澜城已有数据，哪些地方需要结合自身优势重构 |
| 数据体系梳理 | 梳理土地、新房、二手房、宏观经济、政策资料、市场资讯、开发商、项目公司、楼盘等数据对象及关系 |
| 指标口径设计 | 拆解成交套数、成交面积、成交均价、成交金额、供应、存量、去化、楼面价、溢价率等指标在不同模块中的使用方式 |
| 功能原型设计 | 设计宏观观察、超级图表、超级地图、土地市场、新房市场、二手房市场、数据资料库、自定义功能等核心模块 |
| 技术方案协同 | 参与前端、后端关于 1.0 版本技术方案的讨论，协助梳理页面加载、地图展示、筛选组合、图表渲染、数据接口和复杂交互边界 |
| 客户需求对接 | 和开发商及业务团队沟通个性化需求，将客户固定分析口径沉淀为楼盘组、方案组、自定义分段等产品能力 |
| 长期维护迭代 | 持续维护数据口径、产品内容、功能调整和客户反馈，让系统在多年周期中保持可用、可讲、可交付 |
这个项目持续时间较长。前期仅梳理产品框架、数据结构和系统方向就花了较长时间；1.0 版本开发过程中，前后端技术方案和产品交互方案经历了多轮讨论与迭代；上线后还持续围绕数据口径、模块内容和客户个性化需求进行维护。
CityMap 的建设是一项长期产品工程，覆盖前期调研、框架设计、1.0 版本落地和后续多年迭代。
项目早期，我先对房地产数据产品和开发商版本的系统框架做了研究，包括中指、克而瑞、天朗，以及部分定制化数据产品。
这一步的关键在于判断：
当时的判断是：CityMap 应该把宏观市场、微观项目、地图空间关系和客户自定义分析放到同一个系统框架中，形成可持续迭代的城市级数据产品。
在产品框架上，CityMap 最终形成了六大核心模块：
| 一级模块 | 核心能力 | 解决的问题 |
|---|---|---|
| 宏观观察 | 市场走势、区域分布、数据资料库 | 帮用户快速理解房地产市场整体趋势 |
| 超级图表 | 土地、新房、二手房的综合分析和个案查询 | 支持多维筛选后的量化分析 |
| 超级地图 | 土地、新房、二手房的地图化展示和区域研究 | 把市场表现放到真实空间位置中理解 |
| 土地市场 | 动态监测、宗地查询、排行榜、企业分析 | 支持拿地、竞买和土地储备研究 |
| 新房市场 | 市场总览、楼盘查询、排行榜、项目分析 | 支持新房供应、成交、存量和竞品研究 |
| 二手房市场 | 市场总览、小区查询、排行榜、机构分析 | 支持二手房成交、挂牌和区域热度判断 |
这套结构背后有一个重要逻辑：房地产市场由一级市场土地、二级市场新房、三级市场二手房共同构成。CityMap 需要让用户在这三个市场之间切换，并在同一个产品语言中理解它们。
根据项目中的“房地产全生命周期”设计，一个住宅资产会经历 规划、土地出让、土地开工、预售、新房成交、竣工、入住、二手房换手交易 等阶段。CityMap 的数据难点之一，是把这些阶段串成一套信息关联机制，让客户既能从一个新房项目回看土地成本，也能从土地视角追踪后续新房成交和二手房流通表现。
围绕产品交付，我沉淀了 产品说明、接入文档、功能演示体系 和 全生命周期数据模型，让复杂的 B 端系统可以被客户理解、被销售讲清楚、被开发持续迭代。
这一组演示覆盖宏观趋势、土地监测、新房查询、新房排行和二手房查询，体现 CityMap 从市场总览到项目个案、从数据查询到业务决策的完整产品能力。
CityMap 最重的部分是 数据。
页面可以改，图表可以换，但如果底层数据对象、指标口径和关联关系没有整理好，系统就无法长期维护，也无法支撑客户的真实决策。
在数据体系上，我重点梳理了几类对象：
| 数据对象 | 典型字段 / 维度 | 产品用途 |
|---|---|---|
| 土地 | 宗地名称、地址、区域、环线、用途、出让方式、成交日期、楼面价、溢价率、竞得企业 | 支持土地监测、宗地查询、土地排行、企业拿地分析 |
| 新房 | 楼盘名称、地址、开发商、预售证、供应套数、供应面积、成交套数、成交金额、成交均价、存量 | 支持新房市场总览、楼盘查询、排行榜、竞品研究 |
| 二手房 | 小区名称、地址、成交时间、面积、户型、总价、单价、房屋属性、机构信息 | 支持二手房市场分析、小区查询、挂牌/成交研究 |
| 区域板块 | 行政区、环线、热点板块、自定义区域 | 支持空间分析、区域对比和地图筛选 |
| 宏观指标 | GDP、CPI、PPI、固定资产投资、人口、收入、消费、房地产开发投资 | 支持宏观趋势判断和关联指标分析 |
| 开发商 / 项目公司 | 开发商、项目公司、项目归属关系 | 支持企业查询、开发商排行和客户定制分析 |
| 资料库 | 政策法规、发展规划、专业地产资料、房地产金融资料、市场资讯 | 支持客户研究和报告型使用场景 |
其中，开发商和项目公司的对应关系 非常关键。很多房地产项目在公开数据中呈现的是项目公司、子公司或不同主体名称，如果不建立开发商与项目公司的映射，系统就无法准确回答“某个房企在某区域有哪些项目、拿过哪些地、供应和成交表现如何”这类问题。
这类数据关系看起来细，但会直接影响产品能否从“查项目”升级到“看企业”。
另一个更重的数据关系，是 土地、新房楼盘和二手房楼盘之间的生命周期关联。
在房地产数据里，同一个资产在不同阶段会以不同名称、不同主体、不同数据颗粒度出现。项目早期为此单独梳理过“房地产全生命周期 & 信息关联机制”，把各阶段可采集的信息、入库时点和后续使用方式拆开：
| 阶段 | 关键数据 | 数据价值 |
|---|---|---|
| 规划阶段 | 规划图、地块位置、地块编号、地块用途 | 为后续土地和楼盘建立空间位置与规划背景 |
| 土地出让 | 出让公告、挂牌信息、成交信息、占地面积、建筑面积、楼面价、竞得企业 | 记录土地成本、开发主体和后续供应基础 |
| 开工建设 | 建设工程施工许可证、开工日期、工期、承包单位、建设规模 | 明确项目建设进度和开工规模 |
| 新房预售 | 预售证、一房一价表、室号、价格、房型、小区布局、销售进度 | 建立房源级供应、价格和销售记录 |
| 竣工入住 | 竣工验收备案、竣工日期、验收楼号、竣工面积 | 校验项目完成情况，补充小区基础信息 |
| 二手流通 | 二手挂牌、二手成交、房源面积、成交总价、成交单价、换手率 | 追踪项目从新房销售进入存量市场后的真实流通表现 |
这些数据分别存放时，用户只能看到三个割裂的市场。完成关联后，系统可以回答更深的问题：
这条链路还有一个更具体的业务价值：新房阶段沉淀下来的 地址、房型、室号和成交价，可以反过来校正二手房案例地址、补充二手房案例房型，并为小区内 二手房参考基价系数 提供依据。CityMap 的数据由此沉淀为 物业估价、市场判断和小区研究 可复用的基础数据。
因此，CityMap 的底层能力是 资产生命周期链路。这个链路让产品从单点查询升级为 跨阶段分析，也让客户能够从城市、板块、宗地、楼盘、房源多个层级理解房地产市场。
CityMap 的另一个核心工作，是把房地产行业复杂的指标转成稳定的产品口径。
比如同样是“成交”，在不同场景下可能需要看：
同样是“价格”，也可能涉及：
在产品设计时，我把筛选项、指标项和展示方式做成相对统一的产品语言，减少不同模块之间的理解成本。
典型筛选维度包括：
这套口径的价值在于：用户在不同模块之间切换时，不需要重新理解一套新的系统规则；开发和数据团队也可以用更稳定的方式维护接口和报表。
宏观观察主要解决“先看大盘”的问题。
用户进入系统后，可以通过趋势和分布快速理解房地产市场的整体变化，包括土地走势、新房成交走势、二手房成交走势、新房新增供应、新房存量、二手房挂牌和成交分布等。
这个模块的设计重点是把复杂数据变成可解释的市场语言：
宏观观察承担市场研究入口的角色。用户先从宏观趋势判断市场状态，再进入地图、图表、土地、新房或二手房模块做进一步分析。
超级图表面向研究分析场景，核心是让用户通过多条件筛选，快速得到可比较、可解释的数据图表。
它覆盖土地、新房和二手房三个市场：
超级图表把研究人员过去需要手工筛选、导表、统计、制图的步骤产品化。用户可以通过选择统计时间、区域、环线、板块、用途、价格、面积等条件，快速形成分析结果。
超级地图是 CityMap 最能体现产品差异化的模块。
房地产数据天然带有空间属性。楼盘在哪里、土地在哪里、板块之间距离如何、地铁和商圈如何影响项目、不同区域的供应和成交如何分布，这些问题很难只靠表格回答。
超级地图把土地、新房、二手房放在统一的地图视角下：
这个模块的产品价值，是把房地产市场从“数据列表”变成 城市空间。对房企和研究人员来说，这比单纯看报表更接近真实决策过程。
土地市场模块服务开发商拿地、市场监测和企业研究场景。
它包括：
土地模块的难点在于 时效性和口径。公告、预申请、成交、竞价等状态会不断变化，且不同状态对应不同数据字段。产品既要让客户快速看到“最近发生了什么”，也要支持历史复盘和排行分析。
新房市场模块是开发商和市场研究人员高频使用的部分。
它围绕供应、成交、存量和项目查询展开：
对开发商来说，新房市场需要回答区域进入、产品定位、竞品表现和项目位置判断等问题。
因此，这个模块需要同时支持 市场总览、个案追踪和竞品对比。
二手房市场模块用于观察真实交易热度、区域成熟度和客户需求变化。
相比新房，二手房数据颗粒度更细，字段也更复杂。用户需要按小区、房屋属性、户型、面积、总价、单价、建筑年代、成交时间、机构等维度进行筛选。
模块包括：
二手房数据对新房和土地判断也有 反向价值。判断一个板块的新房供应表现时，还需要结合周边二手房价格、成交活跃度、挂牌结构和客户接受度。
CityMap 后续迭代中，一个重要方向是支持客户的个性化分析需求。
标准模块解决的是通用问题，但开发商、区域用户和研究人员往往会有固定分析口径，比如：
因此，产品中增加了面积、单价、总价的自定义分段，以及楼盘分组、项目组、方案组等能力。
这类功能的价值，是把“每次都重新筛选”变成 长期可复用的分析方案。对 B 端客户来说，这会显著降低重复操作成本，也更贴近他们真实的工作方式。
CityMap 的底层逻辑可以概括为：
城市空间 + 土地出让 + 新房供应成交 + 二手房挂牌成交 + 宏观指标 + 客户自定义口径
= 可复用的房地产决策系统
在这个项目里，数据就是产品本体。
CityMap 的关键能力来自三层沉淀：稳定的数据口径、可追溯的数据来源、跨市场的对象关联。界面只是入口，真正支撑客户决策的是底层数据资产。
CityMap 的一级模块由房地产市场的数据层级决定：
这让 产品结构和行业逻辑保持一致，用户理解成本更低。
如果只展示成交套数，用户只能看到表面结果；如果同时展示成交面积、成交金额、成交均价、套均总价、套均面积、存量、供应和供求比，用户才能判断市场背后的结构变化。
CityMap 把指标组织成分析路径：
B 端数据产品最怕的是 同一个指标在不同页面出现不同结果。
所以 CityMap 需要持续维护指标口径和数据来源，包括统计时间、区域划分、物业分类、价格类型、成交类型、项目归属、企业映射等。
这也是项目需要多年维护的原因：房地产数据不断变化，客户需求不断变化，底层口径也需要随着业务理解 持续校准。
CityMap 最难、也最有价值的部分，是把 土地、新房和二手房串成一条可追踪的数据链路。这个工作本质上是在构建一套 房地产资产全生命周期数据库。
这条链路大致是：
规划图 -> 土地出让 -> 开工许可 -> 新房楼盘 -> 预售证 / 一房一价 -> 新房成交 -> 竣工入住 -> 二手挂牌 / 二手成交
这个过程看起来像一条自然链路，但在数据建设中非常复杂。因为每个阶段的数据来源、名称、颗粒度和统计口径都不一样：
缺少统一的 地址、项目、楼盘、开发主体和空间位置映射 时，系统很难判断“这块地后来变成了哪个新房项目”，也很难判断“这个新房项目沉淀多年后，在二手房市场表现如何”。
我在项目中参与梳理的重点，是把这些 跨阶段对象 尽可能串起来，让用户看到房地产资产从规划、土地、建设、销售到二手流通的完整过程。
这套链路在数据库层面也有具体承载，拆到了 规划图、土地、楼盘、小区、预售证、楼盘地址、楼栋室号、新房开盘表、二手房成交案例 等表结构和维护方式，例如 plate_plan、landinfo、property、propertyexpand、newdisk、newdiskreadysale、newdiskaddress、buildings、layerroom、opennewdiskdata、bargainon 等。CityMap 的复杂度最终落到了 数据库对象、采集流程、自动关联和人工审核机制 上。
这也是 CityMap 相比普通看板更有壁垒的地方：三类数据在同一套产品逻辑下互相解释。
开发商客户往往有自己的市场划分、竞品集合、面积段、价格段和项目组。
CityMap 通过 自定义分段、楼盘分组、项目组和方案组，把客户的个性化研究方法沉淀到系统中，让产品从“通用工具”进一步变成 客户可持续使用的决策平台。
这个项目的成果可以从产品、数据、客户和个人能力四个角度看。
这个项目对我最大的价值，是让我完整经历了一个大型 B 端数据产品从 0 到 1，再到长期维护迭代的全过程。
我在项目中沉淀了几类能力：
这个项目让我非常直接地体会到 数据资产 的价值。数据经过 持续采集、清洗、校验、关联 之后，会从一次性报表变成长期复用的判断依据。
用户愿意相信系统，关键在于 稳定的数据口径、可追溯的来源、持续更新的记录，以及能够解释现实问题的分析链路。
这个认知也影响了我后来的项目选择。后来我学习传统文化和紫微斗数解读时，很自然地想到：如果一个领域的判断高度依赖经验、语境和解释能力，就更需要把知识、案例、规则、反馈和准确性沉淀成数据系统。解读结果能够被结构化记录、持续验证、不断校正，用户才会逐步建立信任。
所以我后来做紫微斗数数据化解读系统时，本质上延续的是同一套产品方法：先建立 结构化知识和数据资产，再用 可解释、可验证 的方式输出结果，通过准确性和一致性获得用户信任。
CityMap 最能体现我的地方，是我能把一个行业里非常复杂、非常重的数据问题，拆成可建设、可交付、可迭代的产品系统。
这个项目同时体现了几个能力层级：
| 能力层级 | 在 CityMap 中的体现 |
|---|---|
| 行业理解 | 理解房地产一级、二级、三级市场，以及开发商、经纪公司、研究人员的不同决策场景 |
| 数据理解 | 能识别土地、新房、二手房、宏观、人口、政策等数据之间的关系和口径差异 |
| 产品抽象 | 能把复杂数据拆成模块、路径、筛选项、指标和交互方式 |
| 业务落地 | 能把产品能力包装成客户可理解、销售可讲、交付可用的材料 |
| 长期维护 | 能接受一个系统的持续演进，长期调整数据、口径、客户需求和产品边界 |
如果用一句话总结这个项目：我把澜思多年积累的房地产数据能力，重新组织成一个面向 B 端客户的城市级数据决策系统，并在 2-3 年的建设和维护过程中，持续推动它从产品框架、数据口径、功能模块到客户交付逐步成熟。