필사 모드: 查询成本决定你能读什么 —— 从两千年前的文本到代码导航

• 需要查两百次词典的文本，是读不了的
• Ancient Library 做的事
• 这些东西从哪儿来的，占了一半
• 把形态分析自动化的选择，以及它的代价
• 查询成本归零时会变的东西
• 我们早就知道的同一个故事
• 于是出现的新失败方式
• 这周可以试的一件事
• 小结与出处

需要查两百次词典的文本，是读不了的

学过古典语言的人都懂这种感觉。语法大致会了，词汇也攒了一些，可原典读一页要花两个小时。原因不是难，而是总被打断。

一个词卡住了。它是屈折形式，词典里查不到原样，得先猜词元。猜对了就翻词典，条目很长的话还要从里面挑出符合当前语境的义项。就算这一路花了 30 秒。等你回到句子里，前半句已经忘了。再读一遍。

一页上这种事发生两百次，总和就不再是时间问题了。因为工作记忆每一次都被清空，句子拼不成句子。到那个份上，这篇文本就不是难读的文本，而是读不了的文本。

Ancient Library 做的事

Ancient Library 就是一个只消除这一个问题的网站。它把古希腊语与拉丁语原典收在一起，点文本里的任何一个词，就当场给你词元、形态分析和整条词典条目。

规模网站上直接写着。著作 1,060 篇，其中拉丁语 293 篇、希腊语 767 篇，作者 140 位。按体裁整理成拉丁语 14 类、希腊语 16 类。

词典用的是古典学里两部标准工具书。拉丁语是 Lewis and Short 1879 年的拉丁语词典，希腊语是 Liddell-Scott-Jones 1940 年第九版的希英词典。网站自称是 Worth Media 的公益项目。

这些东西从哪儿来的，占了一半

看这个网站时最容易漏掉的部分是出处。文本来自塔夫茨大学的 Perseus Digital Library，以知识共享署名-相同方式共享 4.0 提供。两部词典也是 Perseus 数字化的。

也就是说，这个网站新造出来的东西既不是文本也不是词典。它做的是把几十年来陆续公开的资源，在一块屏幕上用一次点击连起来。

这个结构有一层含义。消除查询成本的工具，通常不生产新数据。它缩短的是既有数据之间的距离。而那段距离几乎就是成本的全部。词典一百年前就有，文本两千年前就有。缺的是把两者接起来的那条 0.2 秒的路径。

把形态分析自动化的选择，以及它的代价

词元和形态分析不是人能手工标注的量。这个网站说明，它把这项工作交给了用古典语言训练的语言模型。文中写着古希腊语用 odyCy，拉丁语用 LatinCy。

而且网站自己把这个选择的代价写明了：自动分析并不完美，罕见形式可能被标上错误的词元或错误的分析。

我认为这一句是这个网站最重要的部分，因为自动分析的失败是无声的。错误的分析不会弹出问号，它会给你一个看着挺像回事的格与数。初学者察觉不到它错了，而能察觉的人本来就不太需要这个工具。这个结构意味着：从工具中获益最大的用户，恰恰对工具的错误最脆弱。网站有没有把这件事先写下来，对用户来说是完全不同的处境。

查询成本归零时会变的东西

成本下降和成本归零是两回事。这里变的不是速度，而是可做之事的种类。

查词典要 30 秒时，我们只查真正卡住的词。含糊但能糊弄过去的词就糊弄过去。可当查询变成 0.2 秒，含糊的也会顺手确认，一确认就会发现自己原来哪里理解错了。也就是说，成本一消失，读的方式本身就变了。

第二个变化是连贯性。像前面看到的，真正的损失不是那 30 秒，而是那 30 秒里丢掉的前半句。答案在同一块屏幕里出现，连贯性就不断，长句子也就还能是长句子。

第三点稍微不那么明显，但在实务里最大。查询变便宜之后，不确认就略过的习惯会减少。面对昂贵的查询，我们实际做的不是确认而是猜测，而猜测大体上是对的，所以没有机会知道自己错了。这样固化下来的误解，几个月后会在完全不相干的地方冒出来。消除成本的工具所带来的好处，相当一部分正落在这里 —— 挡住错误认知的固化。

我们早就知道的同一个故事

如果觉得这个结构很眼熟，那是对的。因为我们在代码里已经经历过一模一样的事。

想想还没有「从标识符跳到定义」的年代是怎么读代码的。看到一个函数名要找它在哪，只能翻文件树或者全局搜索。这么一折腾，刚才读到的位置就丢了。所以我们只查真正卡住的东西，其余的靠名字猜。

等到跳转定义能即时生效，读代码的方式就变了。面对陌生的代码库，不必再从上往下通读，而是可以抓住一处一路往下挖。我们如今能在一天之内给从没见过的仓库画出个大概的地图，不是因为我们变聪明了，而是因为查询变免费了。

于是出现的新失败方式

同样的好处会带来同样的代价。代码导航工具也会无声地出错。

在动态语言里，候选有多个时，跳转定义会替你挑一个。就算挑错了，编辑器也不会弹问号，它会打开某个文件。打开的文件看着像那么回事，我们就把它当成正确答案，并在它之上继续堆判断。接口与实现有多个、存在猴子补丁、混入了生成代码的场合，尤其容易错位。

由此得到一个实务结论。依赖自动分析的工具，必须让用户看见它可能出错这件事。 就像 Ancient Library 把局限写进了文档，编辑器的导航功能也不该藏起「候选不止一个」这个事实。挑一个悄悄打开确实省事，但省下的这点事，要用「出错时发现得晚」来偿还。

这周可以试的一件事

把这个视角搬到自己团队，该问的问题不是用哪个工具，而是我们的代码库里还有哪些查询是昂贵的。通常是下面四种之一。

• 这个配置值实际上在哪里被读取。用字符串键访问，跳转定义就够不着。
• 这个 API 响应字段是哪段代码生成的。跨过服务边界，导航就断了。
• 这条错误信息从哪儿冒出来的。字符串是拼出来的，搜索就找不到。
• 这个表字段谁在用。ORM 一转换命名，关联就看不见了。

这四种的共同点，是自动导航断裂的位置。数一数一周里团队成员为了找什么而在 Slack 上发问，清单自然就出来了。只针对其中排在前两位的做成可检索的形式 —— 把字符串键换成常量、把拼装的消息收拢到一处 —— 这一次改动，就消掉了此后成百上千次查询。

小结与出处

工具做的事，不是造出原本不存在的知识，而是缩短既有事物之间的距离。可是那段距离一缩短，我们能做的事的种类就变了，于是工具常常看起来像是能力问题。

• Ancient Library —— 著作篇数与语言分布、点击时提供的信息、两部词典的版本
• Ancient Library 介绍页 —— 文本来自 Perseus Digital Library、知识共享署名-相同方式共享 4.0 的条款、形态分析使用 odyCy 与 LatinCy、以及自动分析并不完美这一明示的局限
• 正文后半段关于代码导航的内容不在上述资料的范围内，那是我把同一套逻辑搬到开发工作上的结果。