Ai替我写代码，我替Ai做地产

缘起一张传承了十八代的Excel表

干过地产投拓的人，每个人都有一张Excel表，那必须是土地台账。

课代表手里这张传承了十八代的表格，记录了北京历年土拍数据，从地块编号到成交价格，从竞得企业到规划指标，密密麻麻几十列。每次土拍结束，打开表格，手动录入，核对计算，流程熟悉得闭着眼睛都能做，唯独一个问题——太费劲了。

年初AI agent 爆火，于是萌生一个念头：”要不做个数据库，每次挂牌之后让ai来整理数据，把这些土拍数据、楼盘地图统一放上去，大家有需要自己下载自己查阅，我也省得每次翻聊天记录找网盘链接”。

一个朴素的愿望，点下第一行代码，然后，入坑了。

于是，Krmap Studio 应运而生，借助着Ai coding的加持，我一个零代码基础的小白，居然也像模像样的成了一个独立网站开发者。这次课代表必须承认——Kimi真无敌。

从Java后端到Leaflet前端，从PostgreSQL数据库设计到RESTful接口联调，从GeoServer地图服务部署到Nginx反向代理配置，一个人+AI，花了两周的“课余时间”，居然还真的像模像样的搭建出了一个雏形。

要是没有AI当编程搭子，这个网站现在还只是那张Excel表里的一个念头。我不仅要感慨，全民AI的时代，OPC一人公司真的不是什么空话，而是真的可以实现。

于是本身就没有饭吃的地产行业，这下好了，更加没得吃了。

下面一一给大家介绍下网站的开发建设进度。

图藏：这个玩意到底藏了什么？

作为一个热爱分享，并推崇知识共享的人来说，“图藏”就是课代表把自己收藏的图，以及自己制作的图，拿出来给大家共享。

说实话，对一个普通人，确实没啥用，但是如果你准备购房或者是同行，我相信“图藏”这个板块会对你有用，最有用的就是新房网签价格地图了，打开一个试试你就知道了。

这个板块是网站最早成型的板块，定位很简单，就是把这些年积累的原版地图资源集中管理、分类归档。课代表手里有很多图，以前这些图散在各种文件夹、微信聊天记录、网盘链接里，现在统一归拢到图藏，可以根据标签和分类进行检索了，后续逐批上传，至少找图不抓瞎。

原版地图已经上传到了网站，支持高清无损下载。

后续计划收录的地图类型涵盖五大类：

土拍专题地图——历年北京集中供地、单宗地块位置图、可按批次和行政区双重索引；

楼盘分布地图——在售及待入市项目区位图、板块价值分析图；

行政区划与规划底图——北京市及各区行政区划图、控制性详细规划图、街区指引图；

历史地图——清末民国老地图、1990年代至2010年代城市变迁对比图；

专题分析图——轨道交通规划图、学区划片图、产业空间布局图等。

目前由于Krmap域名还在备案，还没有申请自己的云服务器，Kimi自带的服务器硬盘并不支持上传超大图片，等后续网站开发建设好了，再统一上传了。

城纪：记录近十年北京土拍数据库

城纪是整个网站投入精力最多的板块，也是课代表最愿意拿出来聊的部分。目前入库的数据覆盖2012年至2026年北京全市住宅用地数据，共计624条。每宗地块的数据颗粒度做到以下维度：

• • 基础信息：地块编号、出让时间、行政区、板块、用地性质、占地面积、建筑面积、容积率；
• • 交易信息：起始价、成交价、楼面价、溢价率、竞得企业、联合体成员；
• • 规划指标：限高、绿化率、配建要求
• • 文件索引：挂牌公告、成交公示、规划条件等相关文件链接；
• • 管理状态：预挂牌 / 正式挂牌 / 成交 / 终止 全流程追踪。

你可以根据行政区、年份、竞得人、溢价情况查询，土拍数据一清二楚。比如下面我们搜一下海子近年来拿的地。

这些还都不算什么。城纪板块最重要的是后台的管理系统，这个是区别于一般excel表格数据汇总的核心设计。

正式挂牌阶段：地块出现在北京市规划和自然资源委员会预申请公告中时，即录入系统，标记为"预挂"。此时土地尚未正式挂牌，但规划指标、起始价等关键信息已公开。

正式挂牌阶段：地块转为正式挂牌后，可手动更新状态，补充挂牌文件、竞买须知等材料链接。可分地块录入地块信息，并自动计算住宅、公建、商业的可售价格。

成交阶段：成交结果公示后录入最终价格、竞得企业、溢价率，自动计算住宅/商办分物业类型的楼面价。

这种"预挂-成交"两级管理，解决了传统Excel表格只能事后记录、无法前置追踪的痛点。同时也解决了多宗地块拆分的统计的需求，最起码我个人用起来，还是蛮舒服的。

所有成交数据自动汇集到土地数据库，这是最终的成果，还支持自定义统计分析，实时统计。课代表摸着良心说，目前这套土拍数据收集的精细程度，不敢说比克而瑞和天朗强，但至少已经能放在一张桌上比了。

绿色的小圆圈，是补齐了单宗地详情的条目，目前还在往前追溯补录2025年之前的历史台账，毕竟早年的土地台账没有现在这么精细，争取2026年下半年把历史数据全部补齐。

当然，跟克而瑞和天朗比，差距也是巨大的，毕竟人家的数据优势在于全国覆盖和维度深度分析（房企拿地排行、土储结构、城市进入策略等），而城纪的优势在于他是完全服务于我本人的，是基于我的工作流程定制化开发的。如果你觉得这点很有必要，那后续可以交流~

云览：在线交互地图的野望

云览是目前最难啃的骨头，也是这个网站的终极愿景所在。目标是成为奥维地图的在线版替代方案，课代表手里积累了十几万条奥维地图数据标注——地块边界、楼盘点位、规划红线、轨道线路、学区划片，全部以.kmz/.kml格式存储在奥维互动地图里。

每次要跟同事分享一张分析图，要么导出图片发到微信（分辨率感人），要么让对方也装奥维地图、导入文件、对齐坐标系，流程繁琐得足以劝退一半人。云览的目标很明确：在浏览器里实现奥维地图的核心功能。

• • 自由切换底图（高德、天地图、卫星影像、各类风格底图）；
• • 加载不同数据图层（土拍地块、楼盘点位、规划边界、轨道线路）；
• • 点击地块/楼盘即可弹出详情面板，关联城纪数据库的完整信息；
• • 支持图层叠加、透明度调节、范围筛选等交互操作。

但是，目前云览的开发进度感人，只完成了约为20%——工具栏、底图切换、基础图层加载、点位弹窗等功能已实现，最重要的是如何将数万条数据，规范的移到云端，一时半会怕是完不成了。

目前云览的技术栈基于 Leaflet.js（开源JavaScript地图库）+ GeoServer（地理数据服务）+ ostgreSQL/PostGIS（空间数据库）。

Leaflet本身上手不难，但要做成生产级的交互地图，挑战主要集中在几个环节：

空间数据标准化——数万条奥维标注的坐标系、精度、拓扑关系各不相同，需要统一转换到WGS84标准坐标系，处理边界线交叉、点位偏移等问题；

大规模矢量渲染——北京全市的土拍地块边界叠加后，矢量数据量达到数十MB级别，浏览器端的渲染性能需要优化（瓦片化、分层加载、视口裁剪）；

前后端数据打通——地图上的地块点击后，需要实时查询城纪数据库返回详情，这要求空间索引与业务数据库的高效联动；

移动端适配——Leaflet在移动端的触摸交互、手势缩放、性能表现都需要单独调优。

我有种感觉，我在用的Kimi agent 现在都有点吃力了，有没有大神可以支支招~这个在线交互地图的难度实在是太高了。突然很想念我的omap，用起来其实更加方便。

总结：半成品，凑合能用，方向对了

坦诚地说，Krmap Studio 这个网站现在还是个半成品。

图藏能用，但上传的地图资源还不够全；城纪已经具备了核心功能，数据质量在同行工具里算得上中上；云览还在挖坑，在线地图的性能和交互体验距离"可用"还有很大段距离。

但我想，只要抱着一颗求知探索的心，一步一步来，早晚能搞成。

课代表做这个网站的初衷不是为了跟谁比，只是为了解决自己每天都在被那张Excel表折磨的问题。如果恰好也能帮到几个同样需要查土拍数据、找地图资源、看地块位置的朋友，那就更值了。

最后一句，既是说给自己，也是说给在看这篇文章的你：

路还长，坑还多，但方向对了，走就是了。

网站地址及相关使用说明，可以公众号私信课代表获取。目前处于内测阶段，Bug和数据遗漏在所难免，欢迎随时反馈。