可步行性评分：计算方法与实际用法

可步行性评分回答一个问题：从这扇门出发，步行范围内覆盖了多少日常生活？超市、药店、学校、公园，以及一个能吃饭的地方。它把这一切压缩成 0 到 100 之间的一个数值，所以房产门户、搬迁服务网站和 AI 助手都采用了它。

这个数值很容易展示，也值得算准，因为同一座城市里的两个地址可能位于完全不同的街区。本文先讲方法，再把方法用在真实数据上。我们用 MapAtlas POI API 为 20 座欧洲城市的 40 个地址计算了可步行性指数，结果说明了为什么这个分数属于地址而不属于城市。

可步行性评分衡量什么

可步行性评分是一个邻近度指标。它统计从某一个坐标出发步行可达的日常目的地，再按重要程度和距离远近加权。

这个定义直接带来三个结论，三条都值得写在任何发布该数值的位置。

它是地址的属性，不是城市的属性。 相距三公里的两套公寓通常会差 30 分以上，这一点现在可以用数据展示，而不只是断言。

它衡量存在，不衡量质量。 分数知道 300 米外有一家超市，但不知道这家超市货品是否齐全、价格是否偏高、周日是否关门。

它衡量距离，不衡量费力程度。 一公里平路和一公里上坡都算作一公里。地形、路口和人行道质量完全不在计算之内。

这些是单个数值所能承载的边界，而不是方法上的缺陷。

如何计算可步行性评分

任何实现都可以归结为同样三步。

第 1 步：把地址解析为坐标

先对地址做地理编码，得到经纬度。匹配精度决定了后续所有环节的上限。屋顶级匹配把原点落在建筑本身上，而邮编级匹配可能偏离几百米，在步行尺度上这会改变结论。

如果 geocoder 返回匹配精度字段，就用上它，并把任何基于粗于街道级精度算出的分数标注为近似值。

第 2 步：收集步行覆盖范围内的内容

接着确定什么算步行距离。有两个选项，选择的影响比表面看起来更大。

半径取坐标 1 公里内的全部内容。它快速、便宜、可复现，但完全忽略路网。一家在 400 米外、隔着一条没有桥的河的商店，仍然被算作近在咫尺。

isochrone 取的是沿真实路径 15 分钟内确实可达的多边形范围。每次请求成本更高，作为交换，它能正确处理河流、铁路、高速公路和断头路。

下面的指数使用 1 公里半径，因为公开的基准需要让任何想核对的人都能复现。若是房源上的实时功能，就用 isochrone。

第 3 步：先按曲线为各类打分，再加权

最后把统计数量转换成分数。原始数量在这里行不通：有 40 家餐厅的街区并不比有 10 家的可步行性高四倍，而第一家超市的意义远大于第二十家。因此每一类都按带边际递减的曲线打分。

// One category, scored 0..1. `target` is the count that earns full marks.
const componentScore = (count, target) =>
  Math.min(1, Math.log(1 + count) / Math.log(1 + target));

// Weighted sum across categories gives the headline 0..100 number.
const score = components.reduce(
  (total, c) => total + componentScore(counts[c.key], c.target) * c.weight,
  0,
);

起作用的是对数。从零家到一家超市，组件分数会大幅上升；从 30 家到 31 家几乎没有变化，这大致符合人们对一个街区的实际感受。

然后套用权重。以下是我们的权重，以及每一项背后的理由：

权重是判断而非事实，所以我们把自己的权重公开，供你核对和调整。面向家庭的门户可能会提高学校的权重，面向学生的租房网站则可能提高交通和餐饮的权重。公开权重正是让这个数值在别人的产品里也可复现的前提。

什么样的分数算好

把分数放进区间来看，更容易据此行动。这些区间是按下面的欧洲样本校准的，因此处于中段的数值描述的是真实的欧洲街区。

要记住，这些区间描述的是地址周边的设施供给，而不是走过去的体验。

MapAtlas Walk Index：20 座欧洲城市

我们对 20 座欧洲城市各取两个地址运行了这套方法：中心广场，以及大约 5 到 8 公里外的一个外围居住区。所有数量均来自 MapAtlas POI API 的 1 公里半径查询，采集日期为 2026 年 7 月 28 日。

两个点之间的差距比排名重要得多。中心地址平均 94 分，同一批城市的外围居住地址平均 73 分。蓝点密集贴近上限，是因为欧洲城市中心几乎天然高密度，所以真正的差异体现在绿点上。

表格里有三个结论值得注意。

罗马是样本中内部差距最大的城市，达到 53 分。 Piazza Venezia 得 93 分，仍在城市范围内的 Ponte Mammolo 只有 40 分。在那个外围坐标 1 公里内，API 找到 4 家超市、19 家餐饮场所和 6 处绿地，而市中心对应的数字是 85、1129 和 149。

华沙是唯一外围地址胜出的城市。 Ursynów 得 84 分，老城区 82 分，因为 Ursynów 是规划建设的居住区，超市、学校、诊所和公园从设计阶段就纳入其中。历史中心和适合过日子的地方并不是一回事。

巴塞罗那和雅典几乎没有下降，分别只差 2 分和 7 分。这两座城市连续的中层高密度把设施供给延伸到了游客核心区之外。

为什么城市均值是错误的数字

把一座城市拆开看，机制就很清楚了。

所有组成部分同时下滑。生鲜杂货从 93 降到 34，餐饮从 96 降到 41，学校从 93 降到 39。这不是某一类设施缺失把一个本来相当的街区拖了下去，而是完全不同性质的地方。

设想一下，如果门户网站把这两个地址都标成罗马、可步行性 93 分会怎样。去看外围公寓的买家带着对市中心的预期到场，实地看房纠正了房源页面。按每套房产自身的坐标计算分数可以避免这种落差，也让买家有理由信任页面上的其余内容。

这个分数没有告诉你什么

有四条局限值得和数值一起发布。

存在不等于质量。 1 公里内的六家餐厅，无论出色还是糟糕，得分都一样，因为分数只衡量可获得性。

平地和陡坡得分相同。 邻近度计算看不到地形，所以在里斯本或苏黎世这样的城市，分数读起来偏乐观。

数据覆盖度因国家而异。 我们的数据集记录公共交通节点但不为其打分，因为各国站点级标注密度差异太大，无法公平比较。苏黎世就是例子：查询在 Paradeplatz 1 公里内只返回一个交通节点，这是标注造成的假象，而不是关于瑞士有轨电车的事实。为它打分只会得到一个自信而错误的数值，所以我们把它排除在外并说明了原因。

快照不是趋势。 这些数字来自 2026 年 7 月 28 日，设施会开业也会关门，所以发布任何你计算出的分数时都要附上日期。

如何给房源加上可步行性评分

买家在问房子之前先问街区。能在页面上回答这些问题的房源可以留住访客，而不是把他们推向搜索引擎去别处找答案。

具体实现归结为四步。

1. 在入库时对房源地址做一次地理编码，把坐标连同匹配精度一起存下来。不要在每次页面访问时都做地理编码。
2. 请求该坐标的步行覆盖范围：先取 15 分钟步行 isochrone，再取其中的设施数量。
3. 套用你的权重并缓存结果。街区的变化以月为单位而不是以天为单位，每月或每季度刷新一次就够了。
4. 同时呈现数值和依据。 展示分数、各组成部分的拆解，以及背后有名有姓的具体地点。

最后一步还有第二重收益。当有人询问某个地址周边有什么时，AI 搜索引擎可以引用一段列出真实地点名称的内容，而一个孤零零的数字没有任何可引用之处。用结构化数据标记这块内容，还能让它可被机器读取：

{
  "@context": "https://schema.org",
  "@type": "Residence",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via dei Fori Imperiali 1",
    "addressLocality": "Rome",
    "addressCountry": "IT"
  },
  "additionalProperty": {
    "@type": "PropertyValue",
    "name": "Walkability score",
    "value": 93,
    "maxValue": 100,
    "measurementTechnique": "Weighted amenity density within a 15 minute walking isochrone",
    "valueReference": "Computed 2026-07-28"
  },
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Supermarkets within a 15 minute walk", "value": 12 },
    { "@type": "LocationFeatureSpecification", "name": "Primary schools within a 15 minute walk", "value": 4 }
  ]
}

其中有两个字段承载了来源信息。measurementTechnique 说明这个数值是怎么得出的，计算日期随数值一起传递，答案引擎因此可以毫不含糊地把两者一并复述。

这些分数用在哪里

有三个场景，按商业价值大致排序。房源列表，分数直接在页面上回答街区问题。搬迁与租房搜索，用户先按生活方式筛选，再按建筑筛选。以及 AI 助手，它们越来越多地直接回答某个区域是否适合步行，完全不必把人送到房源页面。

第三个场景变化最快。一个标注了日期、连同方法和背后具体地点一起发布的分数，能给答案引擎可以引用的实在内容。

底层数据方面，GeoEnrich API 一次调用即可返回某个坐标周边的设施数量和地点名称，Isochrone API 则生成这些数量所依据的步行覆盖范围。把评分权重留在你自己的产品里，让它反映你的特定受众真正在意的东西。

小结

可步行性评分是对某一坐标附近日常目的地的加权、随距离衰减的统计。先把地址地理编码，收集其步行覆盖范围内的内容，再按曲线为每一类打分并套用你的权重。

按地址计算，而不是按城市。我们 20 座城市的样本中心平均 94 分，外围平均 73 分，仅罗马内部就有 53 分的差距。

然后把方法和数值一起发布：权重、覆盖范围、采集日期，以及这个分数刻意不衡量的东西。