看了那篇讲 Unix spell 怎么在64KB内存里跑起来的文章，挺有感触。

其实先说背景：spell 是早期Unix的拼写检查工具。64KB什么概念？一本英文词典本身就装不下。作者的解法很妙：不存词典，存哈希。把词表离线压缩成一张位图式的哈希表，宁可接受少量误判（把生僻错词判成对的），也要把体积压下去。这是教科书级的 trade-off——牺牲完美的召回率，换取"在当时的机器上能跑"这个更硬的约束。后来又加了词干还原规则，把复数、时态变化折叠掉，词典进一步缩水。

我佩服的不是技巧本身，是判断力。作者很清楚这个工具的真正目标：帮人抓明显拼写错误，而不是做语言学权威。目标定准了，才敢砍。

反观现在，装个命令行小工具拖下来几百兆依赖，很多项目把"功能全"当成了"质量好"。spell 提醒我们：开源项目最值钱的贡献往往不是代码，是那个"什么可以不要"的判断。代码会过时，这种判断力不会。

顺手推荐读原文，位图压缩那段的推导很漂亮，不挑读者。

楼主说spell"不存词典只存哈希"，这个细节我印象里跟原版有点出入，值得商榷。v7那版（Steve Johnson写的）其实还是把整本词典压进去的，靠前缀压缩（共同前缀只存一次，差异后缀挨个记），再配规则生成候选词，不是位图哈希。位图/Bloom filter那种"宁可误判"的极简做法，更像后来科普文里重写的思路，两件事常被混着讲。

不过你对"判断力"的总结我基本同意。目标定准了才敢砍，现在尤其稀缺。那些拖几百兆依赖的小工具，默认前提是"机器够大不用取舍"，反而把spell那代人的硬约束忘了。

严格来说具体是哪篇？如果是Bloom filter那段推导，我想找来读读。

读到你说的"什么可以不要"，我挺有共鸣的。人在资源充裕的时候反而容易什么都想要，真被逼到墙角了，才想得清哪些东西其实多余。我以前在条件特别有限的环境里待过一阵子，那时候最深的体会就是：限制未必是坏事，它逼着人把力气用在刀刃上。现在不少软件越做越胖，大概是忘了自己当年为什么出发。spell 这种老东西读起来像一面镜子，照出现在我们丢掉的那点克制。你说的"判断力不会过时"，我是真信这一点的。

读到最后那段"什么可以不要"的判断，我愣了一下。技术上的取舍大家都能聊两句，但真要动手砍自己手里的东西，真的难。

我前两年从体制内出来去深圳自己折腾，家里到现在也没想通。外人看着是瞎折腾，我自己清楚那其实也是一次"敢砍"——把别人眼里的安稳砍了，换一个我能说服自己的活法。道理谁都懂，真下决定的时候手心全是汗。

所以你说的那个点特别戳我：spell 最迷人的不是位图本身，是作者心里那杆秤。现在太多项目反过来，啥都想塞，反而没人记得它最初要干嘛了。

位图压缩那段推导你这么一夸，我得去找原文看看了，听着就すごい。