无法归入任一条目的问题应保留，它提示当前启发式集合不完整
别名: 未分类问题 · 清单盲区 · 新启发式 · 清单滞后
概念解释
真实用户和评估者会发现清单没有命名的缺陷：算法解释不足、跨设备交接断裂、团队权限语义混乱、模型不确定性未表达等。未分类发现（unclassified finding）不应因没有标签被丢弃；它是启发式集合的盲区信号。这一条和前三条合起来构成一个完整闭环：前三条分别处理"同一问题多个标签怎么办""标签重复计数怎么办""标签太多怎么办"，这一条处理相反的情况——一个问题一个标签都套不上，这时候错的往往不是问题，而是清单本身。
机制
通用启发式清单本质上是对过去已经被反复观察、反复验证过的问题模式做的一次归纳总结，它天然滞后于技术、业务和平台的变化——一份写于图形界面时代的清单，不会天然包含"算法给出的结果为什么是这个、置信度有多高"这类只有在引入自动推荐或生成式功能之后才会出现的问题类型。一个具体问题能不能成立，取决于它有没有真实的证据和后果，而不取决于现有的分类体系是否恰好为它预留了位置——如果只因为找不到合适的标签就把问题记录删除或忽略，团队实际上是在让清单的历史局限性反过来决定"什么才算是问题"，这个因果关系是颠倒的。保留未分类项还有一个更长远的价值：如果同一类无法归类的现象在多个产品、多个任务里反复出现，这本身就是一个信号，说明现有的启发式集合已经不足以覆盖当前的交互形态，值得从这些重复出现的未分类记录里提炼出一条新的检查条目。
边界
不是每一个一次性的未分类问题都应该被提升为正式准则。在决定要不要把它写成新条目之前，需要先确认它有足够的证据、出现的频率、造成的影响，以及能否推广到当前产品之外的其他场景——如果只在某一次评审里出现过一次，很可能只是个人偏好或者一个孤立的具体缺陷，把它制度化成一条通用准则，反而会把清单不必要地拉长，制造出前一条讨论过的"条目过多"问题。还有一种情况需要单独甄别：有些问题其实已经被现有条目覆盖，只是评估者没有正确识别出这层对应关系——这种情况的根源是培训不足或者条目措辞不够清楚，解决办法是改进条目说明和培训材料，而不是误以为清单本身有缺口再去增补一条重复的新条目。
怎么落地
- 在问题记录模板里始终保留一个"其他/未分类"类别，这个类别下的记录必须填写和其他问题一样完整的事实层字段（触发情境、涉及对象、实际后果、支撑证据），只是暂时没有对应的标签。
- 定期复盘所有未分类记录，统计它们之间是否存在重复出现的触发情境或后果模式，判断这类现象是不是已经积累到值得写入检查清单的程度。
- 任何新条目在正式纳入清单之前，先作为一项试点检查在多个不同任务和产品场景里试用，验证它的发现率是否稳定、误报率是否可控，而不是一次未分类记录出现就立刻写进正式清单。
- 验证办法：新增条目上线后跟踪它的命中率与前一版清单相比是否有实质提升；同时抽查一批"被现有条目覆盖但评估者没识别出来"的历史记录，如果这类误判比例不低，说明问题出在培训和措辞，应该先修条目说明，而不是继续增补新条目掩盖真正的原因。