A7.08.2Inconsistent system image设计
系统映像内部若相互矛盾，用户会形成不一致甚至自相矛盾的模型
别名: image contradiction · 映像矛盾 · 拼接模型
概念解释
界面暗示一种行为、文档写着另一种说法、错误提示又给出第三种解释——当系统映像的不同碎片彼此矛盾时，用户不会自动挑出"正确的那一份"再形成一个统一的理解。用户完全可能同时持有两套互不兼容的信念，在不同场景下各自触发其中一套，自己却毫无察觉——这和"用户的模型自洽但整体判断错了"是两回事，这里说的是模型内部本身就不自洽。
机制
用户接触系统映像的各个碎片，通常不是在同一时刻、同一场景下一起看到的：今天在设置页看到一句说明，几周后遇到一次报错又得到一个不同的说法，两者从未被放在一起比对过。模型的构建是零散、逐次发生的——每次遇到一个新碎片，用户倾向于就当下这个情境把它纳入理解，而不会主动回头检索"我以前是不是见过相反的说法"，因为大多数人根本没有这样一份记录可查，也没有动机为一个尚未造成麻烦的细节去做这种核对。
结果是模型呈现出局部一致、整体不一致的形态：面对场景 A，用户按碎片 A 给出的规则行动，一切顺利；面对场景 B，用户按碎片 B 给出的相反规则行动，同样顺利——直到某一次两个场景的边界被打破，用户才第一次意识到自己脑子里装着两套互相打架的规则，而这个矛盾在此之前的每一次单独使用中都从未暴露过。
边界
- 矛盾只有在用户真的先后接触到两个相冲突的碎片时才会体现为模型内部不一致；如果使用路径始终只触及矛盾的一侧，矛盾会停留在系统映像层面，从未传导进用户的模型里，用户体验不到任何异常。
- 矛盾潜伏的时间可能很长——只要触发条件（两个场景同时相关）没有出现，一个内部不一致的模型可以稳定支撑正常使用很久，直到某个边缘操作、某次故障排查、或者换用新设备第一次把两侧同时摆到用户面前。
- 这条描述的是矛盾传导到用户模型之后产生了什么后果（不一致甚至自相矛盾），不涉及矛盾在系统映像内部具体从哪里产生——碎片本身的来源与构成是另一层问题。
怎么落地
- 挑出产品里几个核心概念（一次操作是否可撤销、数据存在本地还是云端、某个状态是否会被同步），沿着用户可能接触到的每一个触点——界面文案、帮助文档、错误提示、引导流程——逐条核对对同一个概念的说法是否一致，而不是只检查界面内部是否自洽。
- 优先排查团队交接处最容易出问题的地方：设计稿更新后文档没跟着改，工程实现调整后错误提示文案还留着旧逻辑的措辞，这些交接缝隙是矛盾最常滋生的地方。
- 验证办法：设计一个会让用户先后经过两个相关触点的任务路径（例如先看提示文案，再触发一次报错），观察用户在两次接触之间的说法或行为是否出现前后不一致；出现不一致，说明系统映像里确实存在尚未被发现的矛盾源。