错误消息应该道歉吗？（2013）

错误消息是否应该道歉

• 许多人认为“抱歉”通常是不必要的冗余。它很少能帮助用户恢复，而且常常显得不真诚或像是假的，因为在故障发生的那一刻，软件和工程师并不真正“在场”或有情绪。
• 有些人认为，道歉只适用于严重或不可恢复的问题（例如数据丢失、长时间故障），或者组织已经明显失职并正在修复时。
• 另一些人则把礼貌性的道歉视为良好客户服务的一部分：如果用户被卡住了，那就是产品让他们失望了，即使是他们“误用”了它。

语气：拟人化 vs 机器化

• 很多人强烈反感过于俏皮、幼稚化或过度乐观的消息（“oopsie”、吉祥物、笑脸/哭脸）。这类表达被认为居高临下、不专业，尤其在用户本已很焦虑时更令人恼火。
• 相当一部分人更喜欢简短、非人格化、带有“机器感”的错误提示（Unix 风格），避免拟人化和虚假的共情。
• 也有人喜欢带一点人味的语气（“我们很抱歉，你的邮件发送失败了”），这样不会让软件听起来像是在冲着用户大喊，只要它简短而且尊重用户即可。

清晰度、可操作性与细节

• 大家普遍认同核心要求是：
  • 简洁且具体地说明出了什么问题。
  • 面向终端用户时避免术语，或对术语加以解释。
  • 指明用户下一步可以做什么（重试、等待、修改输入、联系某人、点击链接）。
  • 提供可搜索或可交给支持人员的标识符或错误码。
• 含糊的“出了点问题。抱歉。”之类的信息受到强烈批评；它们会阻塞用户，并隐藏有用的诊断信息。

受众、责任与主体性

• 区分：
  • 面向用户的消息（礼貌、高层次、以行动为导向）。
  • 面向开发者/管理员的消息（更技术化，可能包含堆栈跟踪、配置路径等）。
• 一个很长的分支讨论了“是谁在说话”：是用户的工具、供应商，还是管理员。在自由/开源场景中，道歉可能暗示一种控制关系，而有些人认为这并不可取；而在专有/由供应商控制的软件中，代表公司道歉则更合适。

文化与语言

• 一些英语方言使用“sorry”来表达同情，而不是承认过错；另一些人则把它理解为认错，这会影响人们如何看待错误中的道歉。
• 几位非美国用户指出，本地化界面往往会完全省略“please/sorry”，因为这在文化上并不必要，甚至不匹配。

幽默与冒犯

• 在风险较低的场景中，轻微的幽默或彩蛋可能会受到欢迎。
• 在严重故障中，过度可爱或开玩笑的语气通常会被普遍反感。
• 少数人喜欢在小众场景或游戏中故意使用刻薄或攻击性的错误提示，但也承认这不适合通用软件。