企业官网建设流程全解析

国庆长假要来了，商场和地铁站的扶梯即将迎来一年里最忙的几天。我顺手把香港机电署公开的电梯扶梯数据扒了一遍——四个 CSV 文件，事故、年龄、承建商评级各一份。先说读完的第一观感：14 年 23,057 起扶梯通报事故里，官方归因给「设备故障」的只有 89 起，占 0.39%；而全港 73,393 台升降机里，31 年以上的老设备占四成。这两个数字放在一起，比任何一篇电梯安全的文章都耐人寻味。

一、机电署的 97 个数据集，我抽了四份

机电署在资料一线通上有 97 个数据集，升降机、扶梯、游乐设施、气瓶……全部零鉴权。我抽了四份与电梯安全直接相关的：扶梯事故记录（按主因）、升降机年龄分布、扶梯年龄分布、承建商表现评级。每份抓两轮，四份字节数与指纹全部一致；其中事故表只有 1,439 字节——最小的一份，装着 14 年的事故。

有一个坑先记下：「升降机」（lift）和「扶梯」（escalator）在官方数据里是两套设备、两张表。我一开始想算事故率，拿着升降机的 73,393 台做分母——错了 6.9 倍。事故表统计的是扶梯，扶梯存量在另一张表里：10,601 台。分母错表，是这份公开数据里最容易踩的坑。

二、归因口径：93% 到 98% 都写着「乘客行为」

importcsvfromcollectionsimportdefaultdictwithopen("原始返回/emsd/reported_escalator_incidents_r0.csv",encoding="utf-8-sig")asfh:rows=[rforrincsv.reader(fh)ifrandany(x.strip()forxinr)][1:]tot,by=defaultdict(int),defaultdict(dict)forrinrows:tot[r[0]]+=int(r[2])by[r[0]][r[1]]=int(r[2])years=sorted(tot)pb={y:by[y]["Passenger Behavior"]/tot[y]*100foryinyears}ef={y:by[y]["Equipment Fault"]foryinyears}print(round(min(pb.values()),1),round(max(pb.values()),1))print(sum(ef.values()),sum(tot.values()),round(sum(ef.values())/sum(tot.values())*100,2))print([yforyinyearsifef[y]==0])# 92.5 98.1# 89 23057 0.39# ['2014']

2011 到 2024 年，每年归因给「乘客行为」（Passenger Behavior）的事故占比在92.5% 到 98.1%之间；「设备故障」（Equipment Fault）14 年加起来 89 起，2014 年甚至是一年零起。峰值在 2023 年（2,765 起，疫情后出行恢复），最新 2024 年回落到 1,340 起。

怎么解读这个 0.39%？数据本身给不出答案，它至少有三种可能：设备真的可靠（法定定期检验在起作用）；「乘客行为」是个很宽的归因筐——携带超大行李、没扶扶手、在梯上逗留，都可能记进去；也可能存在通报口径的差异。三种解释我都无法用这份 CSV 证实或证伪，所以我只把数字摆在这。能确定的是：如果你想在官方通报数据里找「设备故障」的规律，这份表的信噪比低到几乎不可能——14 年 89 起，年均 6 起。

三、年龄分布：四成升降机超过 31 岁

第二张表是设备年龄。按 18 区 × 8 个年龄段切：

rows=[rforrincsv.reader(open("原始返回/emsd/age_distribution_lift_r0.csv",encoding="utf-8-sig"))ifrandany(x.strip()forxinr)][1:]total=sum(int(r[3])forrinrows)old=sum(int(r[3])forrinrowsifr[2].startswith(("06.","07.","08.")))print(f"{total:,}",old,round(old/total*100,1))# 73,393 29937 40.8

全港73,393 台升降机里，31 年以上的有 29,937 台（40.8%）；41 年以上的占 22.0%。分区看更悬殊：湾仔 61.3% 的升降机超过 31 岁（老城旧楼密集），离岛只有 6.2%；油尖旺的绝对数量第一（6,593 台）。扶梯这边总量 10,601 台，31 年以上占 27.3%，东区最老（52.3%）。

年龄段标签长这样："01. <=5"、"06. 31-40"——前缀的两位序号是排序的唯一依据。你要是按字符串排序后再切片取「前三个年龄段」，靠字典序恰好没错；但一旦去掉序号再排序，"11-15"会排在"6-10"前面。前缀是官方留给你的排序键，别嫌它丑。

还有一个藏在区间里的问题：八段年龄加起来是<=5到>=51，没有空档也没有重叠，可以做总和无损校验——73,393 就是这么加出来的。但反过来，任何一份文件都没写这个分布的统计时点：这些电梯是哪一天数的？文件里没有日期字段，门户元数据也只能给出平台采集时间。做「老化趋势」类的时间序列分析时，这份表连自己的出生证明都没有，只能当横截面用。

四、承建商评级：门户说 2025 年更新过，数据停在 2018

第三张表最有意思的不是内容，是它的新鲜度。承建商表现评级（Performance Rating）这份文件的元数据写着的最后修改时间是 2025 年 12 月 30 日——但打开一看，期数只有一期：10/18，也就是 2018 年 10 月。

这份数据长这样：

rows=[rforrincsv.reader(open("原始返回/emsd/cpr_rlc_r0.csv",encoding="utf-8-sig"))ifrandany(x.strip()forxinr)][1:]periods=sorted({r[0]forrinrows})safety={}forrinrows:safety[r[3]]=r[4]# 承建商编号 -> 安全评级fromcollectionsimportCounterprint(periods,len(rows),Counter(safety.values()))# ['10/18'] 38 Counter({'1': 34, '0': 4})

期数只有一期：10/18——月/两位年份格式，也就是2018 年 10 月。38 家注册承建商，安全评级只有 0 和 1 两档。

这就是我之前在别的数据集里验证过的结论的极端版：门户的「更新时间」是平台重新采集的时间戳，不是数据内容的时间戳。这份评级表的内容已经 8 年没有更新了，而元数据看起来一切正常。做数据管道的人如果拿metadata_modified判断「这份数据还活着吗」，会得到一个错误的「活着」。

评级内容本身：38 家注册承建商，安全表现评级只有 0 和 1 两档——1 是正常，0 意味着备注列里有警告信或者纪律聆讯定罪记录（4 家）。Service 质素评级倒是 0–5 五档。还有一个分母陷阱：各家被巡查的升降机数量从6 台到 1,142 台，差 190 倍——同一张评级榜上，巡查 6 台拿了 1 分和巡查 1,142 台拿了 1 分，置信度不是一回事。直接按评级排序做「谁最好谁最差」，是在拿分母不同的比率排名。那 4 家 0 分的备注列里写着警告信（warning letter）或纪律聆讯定罪（Disciplinary Board conviction）——机器可读，但想引用它们就得逐条人工核对原文，官方没有给结构化的事件编码。

四个要点收尾

1. 升降机和扶梯是两张表。算事故率之前先确认分母是同一批设备——我拿 73,393 当分母时错得毫无察觉，因为两张表长得一模一样；
2. 归因统计只呈现、不推断。0.39% 的设备故障占比有三种解释，CSV 证伪不了任何一种，写进结论前先想清楚数据能回答什么；
3. 门户的更新时间不是数据的新鲜度。评级表元数据 2025 年 12 月、内容 2018 年 10 月——判断数据死活要看内容里的期数，不是元数据时间戳；
4. 年龄段的数字前缀是排序键。"01. <=5"这种丑前缀是官方留给你的，去掉它再排序就是另一套顺序。

最后照例说明：本文只讨论公开数据的口径与工程处理，不对任何承建商、任何楼宇的设备状态做评价；事故归因的解读留给你。全部数字可复现——四份文件双轮抓取的原始返回与审计脚本（13 项断言）放在仓库，取数时间 2026-09-29。

参考链接

1. https://www.emsd.gov.hk/filemanager/en/content_808/dataset/reported_escalator_incidents.csv
2. https://www.emsd.gov.hk/filemanager/en/content_808/dataset/age_distribution_lift.csv
3. https://data.gov.hk/en-data/api/3/action/package_show?id=hk-emsd-emsd1-performance-rating-of-lift-contractors