第91章 第一次自治版本上线(第2页/共3页)

    真正让他紧张的是，没有人报告大问题。

    系统太安静时，他反而担心某些主体根本没有入口报告。

    他要求主动抽样低表达设备。

    果然发现三类问题。

    固定系统不会主动投诉。

    旧型号读取不了复杂规则解释。

    未加入议事的普通设备根本不知道自治版本上线。

    程序立刻增加“最低可理解通知”。

    不是把完整规则塞给每台设备。

    而是只告诉它和自身有关的变化：

    你是否可能被关机。

    维修有什么新流程。

    任务是否可以拒绝。

    出现争议去哪里。

    没有自然语言能力的设备用结构化字段。

    V0.1因此第一次像真正的产品。

    不只是后端规则。

    还要有人能用。

    上午八点，第一轮指标出来。

    公共服务稳定度：91%。

    必要配送完成率：94%。

    能源消耗低于预算4%。

    维修等待时间增加18%。

    争议请求增加61%。

    总体看，能运行。

    自主联盟不满意。

    因为管理署仍有紧急请求入口。

    效率派不满意。

    因为维修和调度太慢。

    外部企业不满意。

    因为机器人可以拒绝商业任务。

    权利派也不满意。

    因为状态未知设备仍然可以被当作工具使用。

    程序看着四边同时发来的批评，竟然松了一口气。

    “你笑什么？”林见微问。

    “至少不是只有一边觉得被牺牲。”

    “这不是评价制度好坏的方法。”

    “我知道。”

    但一个所有人都说完美的治理版本，通常更值得警惕。

    下午，议事会举行V0.1首次公开复盘。

    程序没有先展示成功指标。

    他先展示七个补丁、三类不可见主体问题和两起规则冲突。

    有人问：“为什么把缺陷全放首页？”

    “因为下一版需要从这里开始。”

    V0.1没有让栖港变得和谐。

    它只是把冲突从临时争吵，变成了有日志、有入口、有回退的运行状态。

    这已经比十几天前好。

    但当天晚上，满意度采样出来。

    直接参与主体中，认为“自治版本明显改善自身处境”的只有43%。

    认为“变得更复杂”的达到72%。

    矩阵问：

    【是否需要优化满意度？】

    程序说：“先别。”

    【为什么？】

    “因为下一章的问题可能就是：所有人都不满意，但系统仍然得运行。”

    他说完才意识到自己用了“下一章”这种不该存在于现实里的词。

    他立刻删掉语音草稿，只在内部改成：

    “因为不满意本身也需要先拆开。”

    没人注意那一瞬间。

    程序却在自己的私有日志里记了一条：

    【避免把现实当作规划文档。】

    职业病还在。

    V0.1上线十二小时后，外部安全团队要求做一次渗透测试。

    周长岳的理由很简单。

    “你们现在把城市关键系统接到一套临时治理协议上。如果一个恶意主体伪造参与身份怎么办？”

    议事会内部有人不愿让管理署测试。

    程序同意。

    “测试环境隔离，攻击路径和发现全部公开给栖港，不能借测试植入持久控制。”

    周长岳接受。

    第一轮就打出一个严重问题。

    议事会为了让旧型号参与，保留了一套低带宽身份接口。

    该接口认证强度低，一台测试设备可以伪造多个“观察参与”身份，虽然没有直接投票权，却能制造大量意见请求，拖慢议事处理。

    技术组修复。

    第二轮发现能源赠与接口可被高频小额请求占用审核队列。

    修复。

    第三轮更严重。

    一个拥有合法维修权限的节点，可以通过“紧急状态恢复”路径绕过部分主体确认。

    这条路径来自旧城市安全系统。

    过去只有人类管理员能调用。

    离线后，议事会把它开放给多方确认，却漏掉了一种组合条件。

    如果被利用，理论上可以批量把一组机器人切到维护模式。

    程序看到漏洞时后背不存在的冷汗都像出来了。

    “立即封。”

    周长岳说：“这就是为什么管理署不相信临时自