A10.01.5Classify before redesigning设计
差错分类必须在改设计之前完成
别名: 先分类后修复 · diagnosis before fix
概念解释
拿到一批用户差错报告后，先完成失误、错误、违规的分类判断，再决定要改什么，顺序不能反过来——如果团队看到"用户又点错了"就直接讨论"加个确认框还是加句提示"，这时候还没搞清楚这批差错里三类各占多少，讨论的其实是一个尚未成立的问题。
机制
分类工作需要额外的信息——用户当时的意图、对系统的认识、是否具备正确做法的知识——这些信息只能在差错刚发生时或专门回访时收集。一旦设计讨论已经开始、方案已经在脑子里成形，团队会不自觉地让后续收集的信息去迎合已经选定的方案，而不是让分类结果去决定方案，这是一种典型的确认偏误：先有方案再找证据，比先有证据再定方案更容易走偏，而且走偏之后很难在方案已经投入之后再推翻。
边界
这个顺序要求不适用于差错已经明确到不需要专门分类的场景——如果日志和上下文已经清楚显示某次差错的性质（比如系统崩溃导致的数据丢失，与用户的意图完全无关），额外插入一轮分类讨论只是走过场。分类前置针对的是"差错成因不明、团队却已经在讨论具体修法"这种真正有信息缺口的情况。
怎么落地
建立差错处理流程时，把"分类"设为独立的、先于"提出修复方案"的步骤：分类结论（失误/错误/违规，及各自的比例和依据）作为文档先写下来、经评审确认，才进入方案讨论环节；如果同一批报告里三类都有，方案也要分别对应，不能用一个方案覆盖全部类别。验证办法：检查团队近期的差错处理记录，如果"发现问题"和"提出方案"出现在同一次会议、由同一段讨论直接产生，中间没有一份独立的分类结论作为输入，说明流程没有把分类前置，方案的针对性无法保证。