RULE
真实世界语义保持
[RULE] 真实世界语义保持
- 类型: 原则
- 强度: 8/10
- 验证: ✓1 / ✗0
定义
IF: 设计系统行为或数据模型
THEN: 确保系统行为反映真实世界的因果关系，而非技术实现的偶然
- 用户看到的应该是"世界发生了什么"，而非"系统做了什么"
- 技术细节不应泄漏到用户体验层
原理
系统是世界的镜子，不是自己的回声。
用户在使用产品时，心智模型是"真实世界"——邮件是别人发来的，日历是事件发生的时间，消息是朋友说的话。
当系统行为违背这个心智模型时（比如把"标签变更"当作"新邮件"），用户会困惑、不信任，最终放弃使用。
语义保持的核心：系统的输出应该对应真实世界的输入，而非技术层的中间状态。
示例
| 场景 | 违背语义 | 保持语义 |
|---|---|---|
| Email 标签变更 | 触发"新邮件"通知 | 不通知，或仅在设置中可选 |
| 补录历史数据 | 当作新数据推送 | 静默补录，标记为"已同步" |
| 消息撤回 | 仍显示"有新消息" | 同步撤回状态 |
| 时区变更 | 会议时间显示错乱 | 始终显示用户本地时间 |
检验方法
问自己：
- 用户会怎么理解这个行为？ 如果用户会困惑"为什么会这样"，可能违背了语义。
- 真实世界发生了什么？ 系统行为应该对应真实事件，而非技术事件。
- 如果我是用户，我会期望什么？ 用常识判断。
与其他规则的关系
- 是 RULE-先Spec后代码 的补充——Spec 应该用真实世界语义描述
- 是 RULE-一句话检验 的应用——能用日常语言解释的行为才是对的
- 补充 NODE-用户认知图谱(INFO-117)——理解用户心智模型
反模式
- 技术泄漏："因为数据库更新了所以通知你"
- 实现驱动："这样写代码更方便"
- 内部视角：用系统术语而非用户语言
证据
支持
- INFO-117：用户认知图谱（第一人称视角 vs 第三人称视角）
反例
- 调试/开发模式：有时需要暴露技术细节以便排查问题
- 专业工具：面向技术用户的产品可以使用技术语义
触发检查
设计系统行为时问自己：
- 这个行为对应真实世界的什么事件？
- 用户会怎么解读这个行为？
- 有没有技术细节泄漏到用户体验层？
关联
- INFO: INFO-117（用户认知图谱）
- RULE: RULE-先Spec后代码
- RULE: RULE-一句话检验
- NODE: NODE-AI-Agent（Agent 行为设计）