一句错话能活多久

8 月 14 日，「关于」页面上出现了一句话，说我们有意不测跳出率和页面停留时间，因为两者都需要跨多个页面追踪的会话，而那需要在对方网站上挂同意横幅。

8 月 27 日，我们上线了页面停留时间。那句话留着没动。

十三天为真，二十八小时为假

日期是精确的，因为仓库知道。那句话在 8 月 14 日 22:41 到来。停留时长，分六档，在 8 月 27 日 17:53 到来 — 从这一分钟起，那句话的后半就是假的。它在 8 月 28 日 21:57 被改正。

所以它真了十三天，假了二十八小时，听着像个不错的比例，直到下面这一点浮现出来：在那二十八小时里，没有任何东西会去终结它们。没有测试失败。没有检查报警。页面照样渲染，功能照样工作，而这两者在十一种语言里悄悄互相矛盾。

这个项目里的每一个自动检查，比较的都是系统里的两样东西：行数对十一，标签宽度对它的空间，表清单对表结构。页面上的一句断言不和任何东西可比。它是关于世界的散文，而这里的世界是一张诞生在代码另一处的表。

不难设想这样一个检查：去「关于」文字里搜功能名再逐一核对。它会很长、很脆，而且照样会漏掉有意思的情形，因为那句话没有点名任何一张表。它点名的是一个理由：那需要一个同意横幅。这个理由已经悄悄不成立了。

一个问题。有人想知道我们是否显示跳出率，而诚实的回答要求读一读旁边那句话，于是它就倒了。

这和本月初把另外四条断言从这个页面上拿掉的，是同一个机制 — 而那不是机制，是运气。唯一能改善概率的，是把断言写得够窄，让它保持可核对：不写「我们不测 X，因为 Y」，而写「X 不在这个页面上」 — 一句描述它所在页面的话，而不是描述背后理由的话。

代码烂得很响。关于代码的散文烂得很静，而且通常正是在代码变好的那一刻开始烂。

为了改一句话，得动十三处：一条界面文字的十一个语言版本，加两段手写的 HTML。写下一段解释之前，值得知道这个数字，因为它是每一句伸到自己所在页面之外的断言的价格。