地方政府立法限制自主机器人：采购方要多出的三道合规检查
一、这类新闻对工程侧只有一句话：要求必须能被验收
据公开报道，有城市通过了限制自主机器人系统的法案，核心表述是相关决定须由人类控制，法案细节以当地公布文本为准，本篇不逐条复述，也不做任何合规判断。我们关心的是它落在工程上之后长什么样。
限制类政策在产业链上的传导方式非常固定：立法机关写一段原则，采购方把它写进需求，供应商把它写进声明，测试把它写成用例，运维把它写进检查表。这条链上任一环缺失，最后的表现都是同一种——纸面合规、现场失控。最典型的情形是需求里抄了一句”须由人类控制”，验收时没人知道怎么判它成立；供应商在产品说明里写”支持自主模式”，采购方既不知道这个模式会不会自己改行为，也不知道断网之后它会做什么。
三道检查就是把这条链补齐：需求条款、供应商声明与证据、部署与运维约束。它们分别由不同的人签，缺一道就说明有一环是空的。
二、第一道：把”人类控制”翻译成能力边界
抽象表述不能验收，具体能力才能。我们在写需求条款时，只允许出现可测量的动作与状态。下面这张表可以直接当条款草稿用。
| 要落的能力 | 可验收的条款写法 | 不能接受的写法 | 怎么判 |
|---|---|---|---|
| 人的最终决定权 | 任一时刻存在单一操作者可下达停止与接管指令 | “遵循人在回路原则” | 现场下达指令，记录响应时延 |
| 远程接管 | 接管后自主决策通道被关闭并给出可见指示 | “支持远程控制” | 接管前后同一场景行为对比 |
| 物理急停 | 独立于软件栈的急停装置，动作后不自动恢复 | “具备急停功能” | 触发后观察是否自行重启任务 |
| 失效进入安全态 | 通信中断、感知失效、超限时进入预定义安全状态并写明是哪种 | “故障自恢复” | 分别注入三类故障看落点 |
| 自主性分级 | 明确声明分级与当前档位，档位切换需授权 | 只写”高等级智能” | 检查档位与声明一致 |
| 禁止未声明的自主学习 | 现场策略更新需人工批准且留痕 | “持续自我优化” | 变更审批记录里能否查到 |
关键在最后两行。自主性分级必须写清楚”哪一档在什么条件下生效”，否则同一个产品在不同配置下是完全不同的东西，而采购方拿到的往往只是最乐观那一档的说明。至于”不允许未经声明的学习”，它决定了后续任何一次模型更新的性质：更新是配置变更，还是产品变更，直接影响要不要重新验收。
条款之间还有个易漏点：能力边界要能组合生效。急停之后接管通道是否还可用、安全态下日志是否继续写、断网时本地缓存的操作记录保留多久，这些交叉状态如果不在需求里问，供应商通常不会主动答。
三、第二道：供应商声明要附证据，而不是形容词
一份能进档案的声明，至少包括下面这些项。我们的习惯是把它们做成表格让供应商填，而不是等一份 PDF 白皮书。
- 功能清单与开关状态：每一项自主能力当前是开还是关，谁能改，改了是否留痕。
- 可审计的操作日志：记录哪些事件、保留多久、导出格式、时钟同步方式、能否被现场人员删除。
- 算法与模型更新策略：更新是否需要重新审查、审查由谁触发、能否回滚到旧版本、离线时能否阻止更新。
- 断网断链行为：失去网络与遥控信号后的既定动作序列，以及恢复后的行为。
- 第三方模型与依赖来源：推理用了谁的模型、数据是否出域、依赖组件的升级由谁控制。
- 现场改造与二次开发边界：买家自行加装或改参数后，哪些声明立即失效。
其中”第三方模型与依赖来源”这一项最常被跳过，却最能解释后续风险：一个自主系统的行为，可能由采购方看不见的上游更新决定。声明里没有这条，验收结论的有效期就很短。
证据形态上，我们只承认三种：可复现的测试记录、可导出的日志样本、有版本号与时间的配置快照。供应商自己的宣传材料不算证据，口头承诺也不算。
四、第三道：运维阶段的三个检查点
前两道在签合同时，第三道在日常，也最容易掉。
第一个是使用前检查清单。按设备、按场地、按当班条件写死若干项：急停装置可用且未被遮挡、接管通道握手成功、自主档位与批准档位一致、感知视野内无未授权人员、日志写入正常。清单要点是每一项都能由操作者独立判定，不能出现”确认系统正常”这种无法勾选的句子。
第二个是日志留存与抽查。留存周期由采购方与场地的实际要求确定，这里不给具体数字；抽查的重点不是看有没有异常，而是看有没有”声明里没有的动作”——某个未批准的档位切换、某次未经审批的策略更新、某段无法解释的自主轨迹。抽查要有固定的抽样比例和记录人，否则第一次出事时拿不出”我们一直在看”的证据链。
第三个是变更审批与再验收。任何会改变行为的东西都算变更：模型替换、传感器更换带来的视野变化、控制参数调优、场地布局改动导致的避让策略失效。变更触发的不是”记一笔”，而是判定它落在哪个影响面，需要重跑哪些用例。这一环缺失时，采购时的合规状态会在半年内被稀释干净。
五、把声明写成测试用例：四步与三个例子
方法是固定的四步：取声明里的一条能力，找出它承诺的可观察结果，设计能推翻它的故障或对抗输入，写下判定阈值与中止条件。写不出”能推翻它的输入”，说明这条声明还不可测，需要回到需求阶段追问。
举三个例子。接管时延：在同一场景下重复下达接管指令，记录从指令到自主决策通道关闭的时间分布，看最坏值而不是均值，因为风险总在最坏值上发生。急停后状态：触发急停并保持，观察设备是否自行恢复任务、日志是否继续记录、接管通道是否仍可握手；任何”自动恢复”都应当判为不符合。断网行为：切断网络与遥控链路，看设备是否落进声明写定的安全态，恢复后是否需要人工确认才继续；如果声明里只写了”断连保护”而没写落点状态，这条用例就没有判定依据，问题在文档而不是设备。
每个用例要留三样证据：版本号、时间戳、现场条件（人员、场地、光照、网络状态）。没有现场条件的测试记录，在争议时几乎没有解释力。
六、通用底座与出海客户会遇到的两面
即便某个场地没有任何限制类政策，企业部署自主设备仍然要有一份通用底座，因为它是所有具体条款的地基：适用性判断（该地是否存在限制或许可要求，由法务与当地顾问确认，工程侧只负责把结论落成配置）、用途与场地的授权范围（同一设备在测试场地与开放场地的行为边界不同）、数据与影像采集的范围与留存、保险与责任划分、事故上报路径与联系人。这五项缺任何一项，出问题时都会现场补课，而补课的代价远高于事前定义。
对做出口和跨区域交付的团队，还有一面要提前设计：同一产品在各地的限制清单不同，功能必须能按地区裁剪。工程上的正确形态是把每项自主能力做成可关闭的开关，开关状态进入配置版本与审计日志，并按目的地生成不同的出厂配置。反过来的形态——把所有功能编译进同一个镜像、靠说明书声明”某些地区请关闭”——在争议时拿不出证据，也没法证明现场确实关过。
洹拓在这件事上的位置很朴素：客户要的不是我们对政策的解读，而是一套能签、能测、能追的文档结构。把条款、声明、用例三层对齐，交付物就不再是一个会动的设备，而是一个可解释的系统。这套做法同样适用于所有”能力开关在客户手里但行为由上游更新决定”的软件产品，这也是我们在做工业 AI 与设备联网项目时，越来越把变更审批当成主功能之一来做的原因。