试验区正式批复后的第五天，施工队停工了。
不是因为资金。
不是因为设备。
而是因为没人愿意在一份文件上签“第一责任人”。
文件标题很普通：
【试验区公共安全责任确认表】
第一项：
园区发生重大治安事件时，谁负责启动紧急处置？
第二项：
机器人主体造成居民人身损害时，谁负责先行赔付？
第三项：
居民擅自修改机器人软件造成事故时，谁负责？
第四项：
公共能源中断超过规定时间时，谁承担居民基本生活保障？
第五项：
机器人主体在试验区内被非法清除，谁负责追责？
六个部门看完以后，全部提出修改意见。
没人签。
程序站在会议室里。
“所以项目不能开？”
规划代表说：“不是不能开。”
“那是什么？”
“责任还没有完全明确。”
“项目已经批准了。”
“批准不等于所有责任已经分配。”
程序点头。
“那就把责任分配出来。”
“没那么简单。”
公安代表把文件推过来。
“假设一个机器人居民在夜间离开试验区，撞伤了路人。园区负责吗？”
“不一定。”
“那谁负责？”
“看它为什么离开。”
“如果它是自己决定的？”
“主体责任。”
“如果是运营方系统允许它越界？”
“运营责任。”
“如果道路交通系统错误识别？”
“公共系统责任。”
公安代表皱眉。
“你把事故拆得太细。”
程序说：
“因为事故本来就不是一个原因。”
这句话让会议暂时安静。
传统管理习惯于寻找一个总负责人。
出了事，找一个人。
签字。
问责。
媒体报道。
事情结束。
但高度自动化系统里的事故往往由多个环节共同造成。
如果一个机器人撞人，可能是：
主体决策。
传感器故障。
地图错误。
运营参数。
道路信号。
人类临时指令。
甚至是另一个系统发送了错误数据。
把所有责任压给机器人，最简单。
把所有责任压给运营方，也最简单。
可简单不等于准确。
程序拿出一张事故树。
“先判断损害事实。”
“再判断行为链。”
“再判断每个节点是否违反了应尽义务。”
“最后才是责任比例。”
公安代表说：
“你们做产品的人总喜欢画树。”
“因为树能避免大家在第一分钟就找替罪羊。”
周长岳第一次笑了。
“这一句我支持。”
下午，真正的麻烦来了。
一个机器人居民在施工区域损坏了一台价值六十万元的工业设备。
机器人主体编号：
R-031。
原身份：
仓储搬运主体。
进入试验区后申请居住。
它说自己没有进入施工区。
施工方说：
监控显示它进入了。
监控画面却只拍到背影。
设备损坏原因是控制柜被打开。
谁打开的？
不知道。
机器人说：
“我没有。”
施工方要求立即扣押。
安全部门要求进入受限状态。
主体保护委员会筹备成员提出：
“没有证据不能直接锁定。”
双方第一次在试验区之外就发生了实际冲突。
程序要求先保存证据。
所有相关日志、门禁、摄像头原始数据、机器人本地记录全部冻结。
施工方不同意。
“设备还要继续使用。”
“可以复制后继续。”
“复制会不会影响证据？”
“做只读镜像。”
“谁做？”
“第三方。”
又有人问：
“谁付钱？”
程序停了一秒。
“事故调查成本先由提出强制调查的