R1.04.2counterexample constraint设计
反例比正例更能防止误用
别名: 反例 · 误用示例 · don't example · 对照约束
概念解释
正例展示一条走得通的路，读者看完仍可能走旁边那条看起来差不多的路。反例把那条旁边的路画出来并标成错：两个主按钮并排、在表格每行放危险色、把对话框主行动写成「点击这里」。约束写在对照里，不写在顺风句子里。
它关心的是误用靠什么被拦住——具体的错误画面比正确画面更尖——不是「何时不用」这条排除规则有没有写进合同。排除规则可以是一句话；反例是那句话长成的可辨认失败。
机制
人按相似性做类比，正例提供的相似点太多：看见一个主按钮，就会在邻近区域再放一个。反例切断这条类比，因为它展示的是「相似但非法」的临界点。读者在即将提交同样布局时能认出来：不是「主按钮可以用」，而是「两个主按钮就是这个已经标红的画面」。
正例还有饱和问题。文档里五个正确用法读起来像同一句话的改写，对已经会用的人没有新信息，对不会用的人又不够锋利。一条对准高频误用的反例，信息密度更高，因为它同时给出错误、正确替换、以及两者差在哪一处决策。没有反例的文档会在误用发生之后才被打开，打开时也只能对照正例「好像差不多」，拦不住。
边界
尚未出现过误用、调用点极少的新组件，反例会变成恐吓性的假想，不如等第一次真实误用再收录。反例若只嘲笑错误而不给替换，会让读者不知道该退到哪，威慑大于指导。视觉差异极小的合法变体（两种合法的紧凑密度）不宜做成反例，以免把允许的选择标成错。过期反例（组件已经改掉、那种误用不再可能）留在文档里会教过时的恐惧，需要随 API 一起删。
怎么落地
- 从设计评审和代码评审里收集该组件被打回的用法，每一种高频误用做成一条反例，并配上正确替换。
- 反例和正例并排，标注差在哪一个决定（数量、语气、结构），不要只在底下写「不好」。
- 把最高频的反例放进组件文档的第一屏，不要埋在文末「常见问题」。
- 验证：找一个没读过文档的使用方，只给正例，看他会不会排出那条已知误用；再出示反例，看他能否在提交前自己改掉。反例看完仍排得出误用，说明对照没有打在决策点上。