(Thinking)

显式协议优于启发式

当两端都归你定义时,不要让机器去猜作者的意图。

Date:

这个站点里有两套正文协议,它们的差别值得单独写一篇。

案例页的模板是从原站爬下来的数据反推出来的。爬虫只能拿到一串扁平的文本行,它不知道哪一行是小节标题、哪一行是正文段落。所以模板只能猜:一个短行,如果后面紧跟着一个长段落,那它多半是标题。这个猜测在英文原站上工作得不错,因为英文的标题和正文长度差异明显。

猜测是要还债的

问题在于,这条规则一旦落到中文内容上就变得脆弱。七十二个字符的门槛对英文是一句话,对中文是一整段。作者写一个短一点的段落,就可能被渲染成标题;写一个长标题,又会被当成正文。

更糟的是,这种错位不会报错。页面照样构建成功,只是版式悄悄错了,要到人眼看到才发现。所以编译器里专门加了告警,在作者违反这些隐性条件时提醒他——本质上是在为一个不该存在的猜测打补丁。

论证层不欠这笔债

而你正在读的这个页面用的是另一套协议:小节标题必须以井号加空格开头,插图必须写成独立一行的图片语法。没有猜测,没有长度门槛,没有告警。

差别的来源不是技术水平,而是**谁定义了数据的两端**。案例页的数据形状是原站定的,我们只能反推;论证层的数据形状是我们自己定的,那就没有任何理由再让机器去猜。

这条经验可以推广:凡是你同时掌握生产端和消费端的地方,都应该用显式标记而不是启发式。启发式只在你无法改变输入格式时才是合理的妥协。