Trevor Vick是软件开发与基础设施身份资产公司UMIP的首席执行官。本文观点仅代表作者个人。

今年7月，曼哈顿一个建筑改造项目的第21层发生两根钢柱屈曲事件，建筑安全行业目睹了熟悉的连锁反应。该项目为一座37层塔楼，当时正从办公空间改造为超过1600套公寓。

调查人员和工程师迅速着手重建事故经过。检查失效部件的工程师被提醒，不能假定可见损坏就是问题的全部范围，因为主要结构构件相互关联，某一区域的失效往往预示着其他区域存在应力。

早期报道指向一块缺失的钢筋加固板。据《The Real Deal》援引的工程师说法，该细节本应出现在项目工程图纸中，但从未与钢柱本身连接。这看似是文档管理失误，实则不然——塔楼的文档并未失效，而是缺乏连续性。

每一次翻新、每一个规范周期、每一次材料变更，都依附于当时负责追踪的系统、承包商或个人。一旦链条断裂，资产历史的连接线索也随之断裂。缺失的并非另一个文档库，而是一种持续的建筑历史记录，能够将每份记录、检查、许可、翻新、业主、工程师和软件平台与同一物理资产在其整个生命周期内关联起来。

文档回答的是错误的问题

这一问题远不止于单一事件，因为即使文档管理严谨的组织也会遇到。文档库能回答“档案中有哪些记录”，却无法回答“某一物理资产在其运营期内发生了什么”。

随着资深设施管理人员退休、跳槽或离任，数十年的非文档化建筑知识往往随之流失。换言之，建筑运营历史常被锁在个人头脑中，而非系统中——这一观点来自《Continuity Insights》管理会议近期发布的设施连续性行业分析。

同一分析援引国际设施管理协会的预测：未来十年内，全球超过45%的设施管理专业人士将退休，这一浪潮将考验机构记忆在人员更替中的存续能力。这正是同一种失败，以两种方式呈现。

无论损失表现为退休工程师带走非文档化知识，还是文档库无法说明结构在数十年改造后的承载能力，根源相同：这些系统中没有任何部分持续跟随物理资产本身。记录存在于软件、供应商或员工手中，而非基础设施本身。

应急响应真正需要什么

在事故后场景中，结构工程师、调查人员和保险公司需要的不仅是图纸文件夹，而是对结构每一次材料变更的可靠、连续监管链，可追溯至变更人、变更时间及当时适用的规范周期。交接时的活页夹无法提供这一点。

应急响应真正需要的，类似于物理基础设施的车辆识别码——一个持久标识符，使每个承包商、工程师、许可办公室和软件平台在数十年间都能引用，无论数据归谁所有或由哪个系统创建。可将其视为建筑的Carfax车辆历史报告。

行业从未标准化的层面

过去几十年，建筑环境已系统性地标准化了基础设施建造和管理的各个层面：CAD标准化了设计，BIM标准化了信息，GIS标准化了位置，IFC标准化了互操作性，数字孪生标准化了表征，人工智能正开始标准化智能。

然而，这些层面均未标准化结构的历史与身份——一个持久、可移植的参考，能跟随基础设施跨越所有这些系统并贯穿其生命周期。每一代新平台都改善了资产信息的捕获方式，但都未解决当平台、供应商或理解该信息的员工离开后，信息会如何的问题。

如果数字孪生所代表的物理资产身份不连续，数字孪生本身也无法保持连续。这一区别值得明确：互操作性告诉系统如何交换信息，身份则告诉系统交换的是关于什么的信息。行业花了50年完善前者，却基本未解决后者。

一个不同的问题

曼哈顿改造项目之所以有启示意义，并非因为文档在单一点上失效，而是因为其文档和身份的连续性可能在整个变更历史中失效。更有建设性的问题不是基础设施被记录得有多详尽，而是为何如此少的基础设施在所有权变更、翻新和软件迁移中缺乏持久身份。

建筑世界已标准化了信息创建、交换和分析的几乎所有方式。下一个标准不会是另一种数据格式，而是对结构身份与历史的持续追踪。