消除出错可能优于提示
别名: 错误预防 · 合法状态约束 · poka-yoke · forcing function
概念解释
消除出错可能指在流程里根本不让非法状态被选中、被提交、被组合出来：日期用选择器而不是自由文本、互斥选项做成单选、库存为零的规格直接不可点。它优先于事后弹出「格式不对」。这条管的是路径上的合法状态集合，不是报错文案怎么写、也不是出错之后如何把损失压小。
机制
技能层动作几乎不读事后消息。人把「填完就提交」练成一条连续动作，非法输入在动作完成之后才被翻译成红字，此时工作记忆里已经没有「刚才为什么那样填」。约束把非法组合从可选集合里拿掉，错误没有发生的位置，提示也就没有工作对象。强制函数（forcing function）的代价发生在动作之前：选不到、组不成、提交键对非法组合保持关闭。这比「先做错再解释规则」省掉一轮诊断。提示仍会出现在约束覆盖不到的地方，但把提示当主策略，等于承认流程允许人走进死胡同。
怎么研究
对比「自由输入 + 提交后报错」与「控件只暴露合法值」两条路径，任务保持同一目标。
自变量：输入是自由文本还是枚举、非法组合是否可点、提交键在非法态是否可激活。 因变量：首次提交成功率、到达报错界面的次数、修正轮次、完成时长、同一规则被再次违反的次数。
实验室里被试知道规则会被考，会异常认真读报错；产品日志里同一格式错误反复出现，才更接近真实。不要把「报错文案改清楚之后成功率上升」读成预防成功——那只是诊断变好，非法状态仍然被造出来了。
边界
合法集合事先数不清时（搜索框、备注、开放问答），消不掉出错可能，只能转到降低后果。专家需要的例外路径若被永久关掉，会绕过系统或把数据填进错误字段。过度约束还会制造新错：日期选择器若不准选「昨天」，补录场景会整体失败。无障碍上，禁用控件必须说明为何不可用，否则屏幕阅读器用户只听到一堆灰掉的按钮。
怎么落地
- 把高频报错按字段列出，问每一条「能否改成选择、范围、模板或自动换算，而不是继续提示」。
- 互斥、过期、无库存、无权限的选项不要能点进下一步；关在当前步，而不是让人走完再摔。
- 提交键对当前非法组合保持不可用，并在旁边用一句任务语言说明缺什么，而不是点下去才出现整页错误。
- 验证：抽一周错误日志，统计「本可被控件消掉」的条目占比；改控件后同一错误码应接近消失，而不是文案变得更好听。