B2.20.3Semantic Constraint设计研究
语义约束在用户缺乏领域知识时形同不存在，不能作为唯一防线
别名: 知识缺口 · 领域知识 · 安全防线
概念解释
这条原则说的是知识条件：如果用户不理解对象在领域中的意义，语义约束（semantic constraint）就不会产生“不能这么做”的感受。它可能只剩一个被略过的标签、一个看不懂的图标，或一个没有后果感的确认框。因此语义约束适合组织界面和预防常见错误，但不能替代对高风险动作的强制校验。
机制
语义约束能起作用，前提是用户能把“患者、剂量、过敏史”“审核者、不可逆发布”“合同、生效日”这类概念连成一个因果和责任链。缺少这层知识时，用户无法从含义推出危险：他们看不出两个字段不能组合，不明白重复提交会影响库存，也可能把专业缩写当作无关信息。界面显示的只是字符和按钮；约束感必须由用户补足。压力、疲劳、交接和自动化默认值还会进一步削弱这种补足过程。
怎么研究
比较不同知识水平的参与者在高风险任务中的表现，例如新手、跨部门使用者、经过培训者和领域专家。测量语义违规率、危险选择率、确认框通过率、求助时机和错误恢复时间；再用知识前测或情境访谈区分“看不懂”与“看懂但被迫绕过”。有效的变量包括业务解释、上下文示例、角色提示、强制延迟和系统级校验。
边界
这条原则不意味着所有语义都要降级成硬规则。对低风险流程，过多弹窗和字段锁会让专家变慢，也会把可解释的例外变成流程负担。它也不是指责用户不懂：领域知识本来就需要学习，新手、临时角色和跨系统用户常常没有机会获得。设计要区分“可用语义帮助判断”的场合与“后果不允许依赖个人理解”的场合。
怎么落地
- 盘点高风险路径：删除、支付、发布、处方、权限变更和不可逆同步，逐一标注系统必须校验的数据关系、状态和权限。
- 对语义不可见的流程补充短示例、字段关系说明或预览结果，但不要把安全责任转移到一句提示上。
- 让新手任务使用受保护沙盒、模板、默认范围或受限角色，而不是要求他们先掌握全部业务规则。
- 验证时邀请缺乏领域经验的用户执行危险路径，检查错误是否被拦截、提示是否能解释后果、恢复动作是否清晰。