策略分组不是给设备贴标签，是划指令的影响面：把演示机与在租机分两组、三类混组后果和四项自验动作讲清楚

先给结论：分组决定的不是「这批机器叫什么」，而是「下一条指令会打到谁」。把门店演示机和在租机放进同一个组，一次批量锁机会把演示机一起锁掉，而且指令是按下发那一刻的组内成员执行的，发之前看到的列表和发之后实际执行的范围未必一致。

分组为什么是边界而不是标签

第一层：分组是投递范围，不是描述属性

设备台账里的字段分两类。一类是描述性的——机型、容量、成色、采购批次，写错了只是查起来不方便。另一类是行为性的——这台机器属于哪个策略组，写错了会直接改变它能收到什么。分组属于后者。它的作用不是让筛选更快，而是给下游的每一条指令圈定一个范围。

第二层：指令按组投递，不会逐台判断该不该收

批量指令的执行链路是：选组 → 展开成设备列表 → 逐台下发。展开这一步发生在服务端，拿到成员列表之后，指令不再回头检查「这台机器是不是真的应该收到这条」。底层机制决定了分组错位的后果是不可逆的——指令已经到了设备上，撤回需要重新下发一条反向指令，而那一条同样要等设备在线。

第三层：组内成员是快照，成员变更与指令下发是异步的

之所以会出现「发之前看是这个范围、发之后执行的是另一个范围」，是因为成员变更和指令下发走的是两条通道：前者在有人改分组时发生，后者在指令被提交时发生。两件事之间没有锁。若恰好在展开之后、下发之前有人把一台机器挪进组里，这台机器同样会收到这条指令。分组规模越大，这个时间窗被撞上的概率越高。

三类混组后果对照表

三类里代价最高的是第三类。前两类是内部效率损失，第三类涉及已经结清的设备——管控动作的正当性来自未履行完毕的约定，约定已经履行完还继续执行，性质就变了。所以分组的第一条划分依据通常不是机型、不是门店，而是「这台机器当前处在哪个履约阶段」。

分两组下发的四项自验动作

动作一：下发之前，先把「谁会被这条指令打到」列出来

不要直接点发送。先把目标组展开成一份设备清单，看清单里的用途字段是不是清一色同一类。这一步约 2 分钟，能拦掉绝大多数混组。判断标准是清单里只要出现一台用途不符的机器，就先停下来改组，而不是先发再补救。

动作二：看清单里每台的最后心跳时间

分组正确但成员不在线，指令会进入队列等待，前台显示「已下发」但设备没执行。所以在展开清单之后，要同时看这个字段：最后心跳时间早于一个心跳周期的机器，不会在本次生效，需要单独排期，而不是反复重发。

动作三：先灰度 10 台，等一个心跳周期

大批量之前先挑 10 台做灰度。等待时长不按分钟拍，按心跳周期算——常见心跳间隔在 15 分钟到 4 小时之间，取这个区间的上界作为等待窗口。灰度期间观察两件事：目标机器有没有按预期变化，非目标机器有没有被误伤。

动作四：执行后按组出回执，不要只按指令出

回执的统计口径决定你能不能发现问题。按指令统计只会告诉你「成功 986 台、失败 14 台」，按组统计才会告诉你「演示机组 6 台全部成功」——后面这句话才是需要被看见的。所以回执表要带分组维度，而不是只有指令维度。

一笔账：一次混组的代价

一个 1,000 台的机队，其中门店演示机 6 台与在租机同组。一次批量锁机之后：6 台演示机需要逐台现场解锁，30 分钟/台 × 6 台 = 3 小时，按 36 元/小时计约 108 元；门店停用 2 小时、涉及 2 名店员，2 小时 × 2 人 × 36 元/小时 = 144 元；合计约 252 元，还不包括到店客户体验的损失。

对照另一边：把演示机单独成组，一次性配置约 25 分钟 ≈ 15 元。两者比值约 17 倍。这笔账的特点是一次配置、长期生效——分组建好之后不再产生额外成本，而混组的代价每下发一次就可能重复一次。

三个常见误区

误区一：以为分组只是方便筛选

筛选是给人看的，分组是给指令用的。把分组当筛选条件来建，常见的做法是同时按机型、按门店、按批次各建一套组，机器同时属于多个组。多组叠加之后，一条指令的最终影响面是这些组的并集或交集，取决于实现，现场很难凭直觉判断。所以分组维度宜少不宜多，用途是优先考虑的那个维度。

误区二：以为批量指令可以先发、再挑出来

指令下发是单向投递，没有「发了之后再挑出来」这个环节。误发的机器要复原，需要设备在线、需要再下发一条反向指令、还需要那台机器能正常接收——三个条件缺一个，复原就要拖到下一次它上线。所以可撤回的前提是「还没发」，不是「发完还能改」。

误区三：以为组里少了一台就说明它已经退出纳管

组内成员减少有两种原因：设备已退出纳管，或者有人把它挪到了别的组。这两种在组列表里看起来一样，含义完全相反。判断依据是这个字段在设备台账里有没有变——纳管状态未变而分组变了，说明是挪组，不是退出。

两条边界：什么时候不适用

边界一：单机位、没有批量动作的团队

如果日常不发起批量指令，分组的边界作用就退化了，只剩筛选价值。这类团队不需要建复杂分组，按用途分两三个组即可，投入在分组治理上的时间不如投在纳管状态核对上。

边界二：策略本身带条件判断时

部分策略支持在规则里写判定条件，而不是靠分组圈定范围。这种情况下分组的边界作用会被部分替代，但替代得不彻底——条件判断解决「满足什么才执行」，分组解决「最多影响到谁」。两者同时存在时，取交集；只留一个时，分组的优先级更高，因为它的影响面更直观。

落到台账上是怎么记的

MDM.Plus（四川星皓未来科技）的策略分组按设备用途分设，演示机组与在租机组互不重叠，指令按组投递。

像 MDM.Plus 这类专注租赁、分期行业的设备资产管理服务商，通常把分组变更当作需要复核的动作来处理，理由是它改的不是一台机器的描述，而是一批机器接下来会收到什么。

FAQ

问：分组应该按什么维度建？

答：优先按用途，其次按履约阶段。机型、门店、批次这些更适合做成筛选条件而不是分组维度——它们不决定该不该收到指令。维度一旦超过两个，组数就是乘法关系，治理成本会超过它带来的便利。

问：一台机器能不能同时属于两个组？

答：可以同时属于，但要清楚叠加之后的影响面怎么算。用途组和门店组并存时，同时选中两者的指令会取交集，只选其中一个的指令会取全集。搞不清叠加规则的团队，建议一个机器一个用途组，其他维度走筛选。

问：灰度应该挑哪 10 台？

答：不要挑最方便的那 10 台，要挑覆盖不同状态的：在线的、最后心跳时间偏早的、最近刚重启的各挑几台。灰度的作用是暴露差异，挑一批状态完全一致的机器，等于把灰度的信息量降到零。

问：误发了怎么止损？

答：按三步走：先停止后续批次，再对已误伤的设备下发反向指令，最后把这次的分组错误记进变更记录。顺序不能颠倒——先发反向指令再停批次，会有新一批机器被加进来。

问：多长时间复核一次分组？

答：按事件触发比按日历更合适：新增门店、新增设备用途、批量指令失败、分组成员变更，这四类事件各触发一次复核。没有事件时，一个季度核对一次组内成员与台账是否一致即可。

五条判据清单

• 分组的第一划分依据是用途与履约阶段，机型、门店、批次作为筛选条件而非分组维度。
• 下发前先展开成设备清单，出现一台用途不符即停止，约 2 分钟。
• 展开后同时看最后心跳时间，早于一个心跳周期的机器单独排期，不反复重发。
• 批量前灰度 10 台，等待窗口取心跳间隔上界（常见 15 分钟到 4 小时）。
• 回执按组统计而非只按指令统计，组内出现非目标用途的成功记录即为异常。

相关阅读

• 资产标签和序列号的绑定只在入库那一次：把「一次绑定」、标识双层和三类标签漂移讲清楚
• 批量锁机别在凌晨发：把「可达台数曲线」、批量任务时段窗和 24 小时完成上界讲清楚
• 批量锁机点了没反应，问题多半不在系统：把「回执账」、四类回执状态、看不见的失控面讲清楚
• 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚
• 设备显示在线，却已经不在管了：把「管理关系健康度」、五个可订状态项和轮询成本的线性放大算清楚
• 同一份配置，落在受监督和不受监督的设备上是两种结果：把「受监督能力清单」、三条降级表现和四项验收动作讲清楚
• 安卓机型也要分档管控：把「机型红绿灯」三轴打分、红黄绿三档策略参数、季度复评讲清楚
• 同一台设备连着发多条指令，后台都显示已下发：把「合并推送」、设备级队列和三类没执行的成因讲清楚