L4.11.2batch confirm needs inspectable list设计研究
批量动作的确认需给出可抽查的清单，只给数量不足以判断
别名: 批量确认要清单 · count is not inspection · 12 个文件不够
概念解释
一次动许多对象时，确认如果只报「将删除 12 个文件」「将发给 48 位客户」，人无法判断这 12 个里有没有混进不该动的。数量是规模，不是内容。批量确认要可抽查的清单（batch confirm needs inspectable list）：每一项都能被看见、被打开、被拿下，而且人不必为了抽查而一次性读完。
「12」甚至可能是对的计数配上错的集合。计数验的是长度，验不了成员。
机制
工作记忆装不下十几条名称，逐项精读会把确认变成第二个工作日。抽查是折中：清单在，人按启发式扫异常（不认识的名字、错误的域、日期不对），并能把异常项拿下来。没有清单，启发式没有落点，人只能对计数做态度判断——12 听起来合理，于是放行。实例原则在单件时够用；批量时要把实例做成可滚动、可过滤、可反选的集合，否则实例被数量摘要吃掉。
不可抽查的「查看详情」藏在二次点击之后，等于没有清单：疲劳中的人不会点。
怎么研究
批量里混入若干异常项，比较：只给计数、给截断的前三名、给完整可过滤清单、清单但默认折叠。因变量：异常项被拿下的比例、抽查耗时、是否有人打开清单。自变量：是否可搜索、异常项的位置（前/中/后）、计数是否醒目。
异常在中后段仍能被找到，才叫可抽查。只能发现前三名，是截断，不是清单。
边界
两三项还谈不上批量，直接列出即可。对象没有可区分的字段，过滤也帮不上，要先给可再认的实例。计数可以作为标题，不能替代清单。疲劳要用分级来减次数，不能用藏清单来减阅读——藏了，批量确认就废了。
怎么落地
- 批量确认默认展开清单，支持搜索和反选。计数写在标题，清单才是判断面。
- 放行前允许拿下任意项；拿下后计数必须跟着变，避免「看起来改了、集合没改」。
- 验证：把异常项放在第 8 条，看它是否被拿下。总是漏掉中后段，就还在靠前三名充数。把清单改成默认折叠再测打开率——打开率接近零，二次点击就等于取消了抽查。