1. 一个具体问题
用户按下“保存”，页面却把草稿公开发布；开发者调用名为 getUser 的方法，数据库记录却被更新。这些行为可能都有说明文档，却依然容易导致错误。使用者依赖名称、位置和已有经验建立预期，设计若违背这种预期，就要付出额外学习与防错成本。
2. 一句话解释
让系统行为尽量符合目标使用者在具体情境中的合理预期，并把必要的意外提前说明。
3. 出处与原意
最小惊讶原则广泛流传于编程和交互设计，没有一个在所有领域公认的唯一提出者。Nielsen 的“一致性与标准”可用性启发式提供了相近而更具体的设计依据。两者相关，但不能据此把最小惊讶原则的全部历史归于 Nielsen。
4. 原理与机制
人不会每次操作都重新阅读说明，而是从熟悉模式推断结果。名称、默认值、视觉样式和执行时机都会构成提示。降低惊讶需要保持内部一致，也需要理解用户所属平台和专业领域的惯例；面向数据库管理员与面向初学者的界面可能具有不同预期。必要的新行为不是禁止项，但应该有清晰反馈、渐进介绍或可逆操作。惊讶也并非越少越好：如果旧习惯危险，设计应帮助用户建立更安全的新模型。
预期还会受动作顺序影响。用户在一个页面学会“回车提交”，到另一个相似页面却发现回车删除条目，即使按钮文字没有问题，也会产生危险迁移。审查时应同时看命名、快捷键、默认焦点和反馈时机。对于耗时动作，及时显示正在处理与最终状态，可以避免用户因没有反馈而重复提交；可撤销设计则为不可避免的误解提供恢复机会。
5. 一个完整案例
假设案例：一个内容工具把“保存并发布”做成默认按钮，用户常把会议笔记意外公开。团队观察五名新用户的操作，发现他们把保存理解为私有持久化。改版后，主要按钮变成“保存草稿”，发布作为独立动作显示可见范围，发布后提供撤回入口。团队继续记录误发布次数，而不是仅问用户是否喜欢新颜色。这里真正变化的是动作名称、结果和可见性之间的关系；如果只是增加一段帮助文字，原有直觉仍可能触发错误。
6. 适用条件与反例
适合命名 API、设计快捷键、设置默认值与危险操作。它不能被用来阻止一切创新，也不能假设设计者自己的习惯代表所有用户。不同人群惯例冲突时，应明确主要用户，并用真实任务测试判断哪种预期更常见、更重要。
7. 今天可以尝试的行动
选三个容易误用的动作，让一位未参与设计的人仅看名称和界面预测结果，再执行验证。记录预测与实际的差异，优先修复会改变数据、权限或公开范围的差异；为无法消除的意外加入明确提示与恢复路径。