1.

哎呀，被你撞见我在忙别的。我正想在 Google Docs 里给朋友列一份 Windows 版本清单——居然用它来做。

本来应该很简单。我已经从维基百科上扒了一份，稍微整理了一下，但还是有点丑：

这里的内边距太挤了，我不太喜欢。试试大一点的，比如 0.08 英寸？我只要选中第一列，把数字输进去，然后……

见鬼！！！

天哪，怎么回事？好吧，按一下 ⌘Z 试试能不能退出……

哦，不行。也许按 Esc 能行……

糟了。

2.

好吧，下面是精确的来龙去脉：

• 我按 Backspace 删掉了一个已有的 0：

• 我开始输入“.08”。按下“.”时还没问题，虽然弹出了一个相当急切的提示：

• 加上“0”之后，Docs 把“.”删掉了，所以输出就只剩下“0”：

• 再加上“8”之后，Docs 又去掉了开头的 0，最后就只剩下“8”：

• 页面识别到最后的“8”，就套用了 8 英寸的内边距（足足是我想要的一百倍！），并且实时展示了出来，结果表格变得面目全非，看起来就像出了什么大故障，
• 按 ⌘Z 毫无反应，
• 按 Esc 也只是让输入框失去了焦点。

我觉得我可以准确解释这里的一整条逻辑链和 bug：

• 首先，输入的任何数字都会立刻在左侧预览。这种体验总体来说还不错！
• 输入的内容不是在确认（按回车）时才修正，而是在我打字的过程中就被实时改写了。这不是我会推荐的做法，但我能理解这个设计决定。
• 如果我只输入“08”，它会被改写成“8”。这还算说得通，毕竟是为了规范数字、保持一致。
• 如果我输入“.1”，它会被改写成“0.1”。行吧，没问题，思路也差不多。
• 然而，输入“.0”却会被改写成单独的“0”。我认为这是个 bug，或者说是考虑不周——它本应该被改写成“0.0”。
• ⌘Z 不起作用。我觉得这是个 bug，系统对数字的改写没有被放进撤销栈。（事实上，情况似乎更糟——再多按几次 ⌘Z，居然把我的数字改成了“80”，那只会让情况更糟！）

所以，实际上，我输入的“.08”被篡改成了“8”，被立刻应用了，而且还不容易撤销。

3.

这感觉正是瑞士奶酪模型在现实中上演的绝佳例子：

下面这些要点里，只要有一项表现得不一样，我就不会陷入这种境地：

• 如果数字不是在输入时就被实时改写，就不会有问题，
• 如果“.”没有被那么急着改写成“0.”，也不会有问题，
• 如果没有实时预览，本可以在改写后手动发现并修正，而不是在屏幕上看到翻天覆地的变化、以为数据都丢了而惊慌失措，
• 如果输入框的撤销功能完全正常，那一瞬间的慌乱本可以一键撤销，
• 如果按 Esc 是取消而不是确认，也是如此。

这些决定单看每一个都合情合理，似乎也不危险、不重要。但合在一起，奶酪上的孔洞恰好对齐了，于是就造成了一次相当吓人的体验。

感谢 Ezra Spier 与我分享这个案例。