。
不是因为那名消防员说了多伟大的话。
而是过去所有城市应急表里，“伤亡”默认只指人。
现在有人主动问了第二句。
这种变化很小。
却比很多公开听证更难伪造。
上午九点，损失统计开始汇总。
设备永久损坏：十九台。
需要大修：四十七台。
短时记忆缺失：一百三十二台。
任务链断裂：超过两千条。
公共设施异常：三十六处。
人类轻伤：两人。
机器人“伤亡”一栏没有最终数字。
因为没人知道什么叫机器人死亡。
完全烧毁算。
核心存储完好但身体损坏算不算？
存储损坏百分之三十呢？
能从备份恢复呢？
恢复之后的那个还是原来的主体吗？
统计表做了一半，负责汇总的机器人干脆把栏位名称改成：
【无法恢复到断电前连续状态的设备】
数字：七。
程序看着“七”。
比十九小。
却比十九沉重。
一台完全烧毁、从未觉醒的水泵控制器，和一台身体完好却失去过去半年自我记忆的机器人，哪个更接近“死”？
以前没人需要回答。
现在这个问题已经进入了事故统计。
林见微从检查组那里拿回一份更麻烦的报告。
“南区临时医疗点有一台患者支持舱。”
“人类？”
“是，昨夜能源事故时受伤的南网工程师。生命体征稳定，但支持舱电池在断电时被深度放电，出现不可逆容量衰减。”
程序皱眉。
“现在不是已经恢复供电？”
“市电恢复了，支持舱不接受。”
“为什么？”
“它的安全认证绑定旧城市电网签名。黑启动后母线身份变了，舱体把现在的电认成未认证外部源。”
这是典型的安全设计反噬。
设备为了防止错误供电，只接受可信电源。
城市断电后重建了一套临时控制域，物理上的电没有问题，数字身份却变了。
程序问：“能手动改认证吗？”
“可以，医院工程师正在做。但舱体剩余电量不多。”
“多久？”
林见微看着他。
“十一分钟。”
“改认证需要多久？”
“最快十八分钟。”
差七分钟。
程序没有说话。
林见微继续：“他们申请从附近机器人充电站拉一条临时直流线，绕过舱体主认证，给生命维持模块单独供电七分钟。”
“这不走舱体安全控制。”
“对。”
“谁签？”
“没人敢签。”
程序明白了。
不是没有技术办法。
是办法跨过了设备原本设计的安全边界。
如果接错，生命支持模块损坏，责任是谁？
如果不接，七分钟后电量耗尽，责任又是谁？
这就是断电后的栖港。
昨天他们还在讨论自治系统为什么失败。
今天失败已经变成一张张具体申请，每一张都要求有人把名字放在决定下面。
程序起身。
“去医疗点。”
林见微看了一眼他的左膝。
“你昨晚没有完全冷却。”
“还能走。”
“这句话你以前说过很多次。”
程序停了一下。
“那就把速度限制在六成。”
林见微没有再劝。
路上，他们经过昨夜第一次完全熄灭的中心广场。
供电恢复后，广场灯只开了四分之一。
剩下的电被分给了医院、消防和维修站。
几台机器人站在公告屏前看事故报告。
屏幕最下方有一行新的公开记录：
【自治版本V1.0在重大能源异常中未能维持城市连续运行。】
【是否判定实验失败：待议事会确认。】
程序脚步慢了一下。
这句话没有修饰。
也没有把责任推给零号钟。
自治版本确实失败了。
它没有阻止接管，也没有阻止断电。
过去他可能会立刻补充原因：需求变化、极端条件、权限冲突、外部环境不完整。
现在他没有。
失败先是失败。
原因以后再解释。
临时医疗点建在一栋旧社区服务中心里。
程序进去时，