启发式条目不是互斥集合，按条目累计问题数会重复计数
别名: 重复计数 · 问题聚合 · 启发式集合 · 情境-后果对
概念解释
启发式条目（heuristic entries）是检查视角，不是互斥分类法。同一缺陷在不同评估者笔下可能落在反馈、错误预防、用户控制或帮助；如果按"每条启发式发现多少问题"相加，会得到虚高总数并误判某个领域的质量。这一条建立在前一条"归类分歧不影响问题本身成立"之上：如果说前一条解决的是"一个问题被贴上不同标签算不算错"，这一条解决的是紧接着出现的下一个问题——一旦允许多标签，怎么汇总才不会把同一个缺陷算成好几个。
机制
问题数量应该按"独特的触发情境加实际后果"这个组合来统计，而不是按标签出现的次数统计——这是两种完全不同的计数单位，混用是错误的根源。同一次上传失败，如果三名评估者分别把它标记为"状态可见性问题""反馈不足问题"和"错误恢复问题"，这依然是同一个底层缺陷的三个观察角度，不是三个独立的缺陷；如果按标签数相加，团队会得到"发现了三个问题"这个虚假结论，进而在排期时把它当成三份工作量来分配，实际修复一次触发点就能同时解决全部三个标签下的记录。这种虚高不只是数字好看难看的问题，它还会系统性地扭曲"哪个领域质量更差"这类跨模块比较：一个真正问题较少、但每个问题都容易触发多重标签的模块，会在按标签计数的报告里显得比实际问题更多、质量更差，团队的资源可能因此被错误地导向本不该优先修的地方。
边界
不是所有相似问题都应该被合并。触发对象、路径或权限不同的两个问题，即使表面症状相似（都表现为"按钮点了没反应"），背后可能是完全不同的两个底层原因，强行合并会丢失各自的真实频率和影响范围，导致其中一个真正高频的问题被稀释进一个看起来发生率不高的合并记录里。合并的前提是证据链已经足够确认两者是同一个底层原因，而不是仅仅表面症状相似就动手合并；证据不足时，更安全的做法是保留彼此关联但各自独立的记录，而不是急于删除其中一份。按界面模块统计问题数也要小心：模块本身的大小和复杂度不同，问题数的绝对值天然不可比，一个大模块问题多可能只是因为它承担的功能更多，不一定说明它质量更差。
怎么落地
- 给每个问题分配唯一 ID，记录字段包括触发情境、涉及对象、实际后果、支撑证据和适用的标签集合，标签允许多个但 ID 只有一个。
- 汇总报告时先按"情境-后果"组合去重合并，同一底层原因下的多个标签记录合并为一条主记录，选一个主标签用于分配修复方向，其余标签作为关联信息保留。
- 报告呈现去重后的问题总数、标签分布和标签共现矩阵，绝不把各标签下的计数直接相加当作总问题数。
- 验证办法：定期抽查高标签共现的记录，人工确认它们是不是真的指向同一个底层原因；如果是，说明当前汇总流程有效；如果发现被合并的记录其实来自不同触发路径，要拆回去，而不是让错误的合并沉淀下来影响后续统计。