大量个体状态需要聚合为概览而非逐一罗列
别名: 多机概览 · fleet dashboard · 舰队级聚合
概念解释
当需要监督的机器人数量较大时，界面应该把大量个体状态聚合（aggregate）为一个概览，而不是逐一罗列每台机器人的详细状态、让监督者自己扫描寻找问题。聚合的单位应该对应任务、区域或依赖关系，而不只是简单统计机器总数——按什么维度聚合，直接决定了这份概览能回答哪些问题。
机制
这个设计原则的依据是人类视觉工作记忆和扫描能力的容量限制：当个体数量超过人能够同时保持关注和比较的范围，逐一罗列的列表或面板会迫使监督者用顺序扫描的方式检查每一项，这个过程既慢又容易遗漏。聚合表达的作用是把大量原始数据点用统计摘要或可视化编码——比如按状态类别着色的分布图、整体健康度指标——压缩成人眼能一次性把握的少数几个视觉单元，用感知层面的模式识别代替认知层面的逐项核对，这与管理领域"例外管理"的原理是同一类思路在视觉呈现上的具体实现。但压缩是有代价的：每一种聚合方式在暴露宏观结构的同时，也必然丢失个体差异，这个代价本身就是后面几条边界和落地建议要处理的问题。聚合单位的选择还会反过来塑造监督者能提出的问题——按机器人型号聚合和按作业区域聚合，暴露的是完全不同的宏观结构，前者适合发现"某一批次设备普遍故障率偏高"这类问题，后者适合发现"某个区域协作效率偏低"这类问题，选错聚合维度，概览本身就答不出监督者真正关心的问题，这比"信息不够细"是更根本的失效。
怎么研究
验证聚合设计是否有效，常见做法是让监督者分别用"逐一列表"和"聚合概览"两种界面完成同一个"找出编队里有问题的个体"任务，比较完成时间和准确率随编队规模增大时的变化趋势——预期聚合界面的表现会随规模增大保持相对稳定，而列表界面的表现会随规模增大明显下降。这类研究还应该纳入"均值相同但分布不同"的场景，例如同样的平均电量，一种情况是所有机器人电量均匀偏低，另一种是大多数正常但少数几台严重耗尽，用来检验聚合呈现方式本身会不会掩盖后一种更危险的情况。
边界
聚合表达的优势只在个体数量确实较多、且监督任务是"发现整体模式或异常"而非"逐一核对每个个体细节"时才成立。在编队规模很小——比如几台以内——或任务本身就要求对每个个体做逐一确认（比如逐台验收、精细协作作业）的场景，聚合反而增加了不必要的抽象层，直接列表可能更合适；过度聚合还会把少数但高后果的异常掩盖在整体正常的表象之下。规模的边界也不是一个固定数字，而是取决于个体之间差异有多大——如果编队里所有机器人执行完全相同的任务、状态高度同质，即便数量不小，逐一列表也不会造成太大的扫描负担；反过来，即便数量不多，一旦个体承担的任务、所处环境差异很大，聚合就已经开始有用了。概览的作用是给监督者一个注意力的入口，不能替代真正需要核查的原始证据。
怎么落地
聚合概览的具体形式——数量统计、状态分布图、地理位置热力图——要根据监督任务实际关心的决策维度设计，比如按作业区域、任务类型和风险等级分簇呈现总量、分布、趋势和数据覆盖情况，而不能只是把详细数据换个图表样式；筛选条件和时间范围应该保持稳定，避免监督者每次查看都要重新设定。验证办法是用前述的任务完成时间和准确率测试，在目标编队规模下比较聚合界面和列表界面的实际表现差异，并专门用"均值相同、尾部不同"的场景确认操作者能不能借助聚合视图识别出真正的风险并进一步下钻，而不是被平均数字安抚。在正式上线前，还应该用同一批历史数据分别按不同维度（型号、区域、任务类型）聚合，请实际监督者判断哪种维度下的概览最贴近他们日常要回答的问题，避免设计者凭直觉替监督者选定聚合维度。