B3.18.3Heuristic Set Size设计
条目数量过多会降低评估者实际逐条使用的比例
别名: 启发式清单 · 评估疲劳 · 条目设计 · 分层检查
概念解释
清单越长，评估者越容易从"逐条检查"退化为"凭印象找问题"。启发式集合（heuristic set）应有少量稳定主条目，配合产品专属子检查；不是条目越多越严谨——这条讨论的是清单本身的规模该怎么控制，它和前两条（归类分歧、重复计数）针对的是同一批问题记录的不同环节：那两条管评估过程中怎么记录和汇总，这一条管评估开始之前清单要设计成什么规模才不会让记录本身失真。
机制
评估者的注意力和工作记忆在一次评审会话里是有限资源，几十条抽象准则摆在面前，会造成条目之间互相重叠、彼此排序冲突，评估者很快无法维持"每条都认真核对一遍"的执行节奏，退化路径通常是两种：要么只记得住最开始或印象最深的几条，后面的条目变成机械打钩；要么干脆放弃逐条对照，转而凭第一印象找"感觉不对"的地方，再事后往清单里找一个大致匹配的标签。这两种退化都会系统性地影响结果——评审顺序靠后的界面区域，无论实际质量如何，获得的仔细检查程度天然更低，这不是评估者能力不足，而是清单长度本身超出了单次评审能维持的注意力预算，是清单设计的问题，不是执行的问题。
边界
复杂产品确实需要比通用清单更多的检查项，但解决办法不是把所有检查项塞进同一份清单一次跑完，而是分层：少量稳定的核心原则放在第一层，产品领域检查、平台专属检查、无障碍检查和具体任务剧本各自独立成层，不同评审阶段选用不同的子集，而不是每次评审都要求评估者面对全集。项目专属、针对具体业务场景写出来的检查项，往往比通用抽象条目更容易被发现真实问题——这是因为具体条目降低了评估者把抽象原则映射到当前界面所需的转译成本，而这个转译成本正是清单过长时被压垮的那部分认知资源。
怎么落地
- 把检查清单拆成核心主条目、领域子检查、平台子检查和任务剧本四类，评审开始前先按当前评审的界面类型和阶段选定要用的子集，而不是默认全跑。
- 每条检查项都写清楚"看什么可观察的证据、怎么判定"，删除那些只是在换一种说法重复其他条目的项，减少条目间的相互重叠。
- 记录每位评估者对每条条目的实际使用情况和发现率，长期使用率低、又与其他条目高度重叠的条目，考虑合并或直接从主清单降级为可选的补充项。
- 验证办法：限制单次评审的界面范围和时长，产品规模较大时拆成多轮、按模块分别评审，评审结束后统计不同评审顺序位置上的界面区域各自被发现的问题数，如果明显呈现"越靠后发现的问题越少"这个模式，说明当前清单长度已经超出单次评审能维持的注意力预算，需要精简或分层。