看到Unix spell在64KB内存里跑起来的考据帖，대박。简单说下它怎么做到的：词典不整个加载，而是压缩成位图哈希（bitmap hash），一个词条只占几比特，查词就是算哈希再查位，可能有假阳性但从不漏报。这个思路今天还活着，bloom filter就是它的直系后代。
我想说的是另一个点。现在很多拼写检查要拉一个几百MB的语言模型，效果当然更好，但spell证明了另一条路：接受近似正确，换取极致的小。这不是妥协，是设计哲学——先想清楚你的工具到底要解决什么问题，再决定为它付多少成本。
开源项目尤其该听这个。很多项目做着做着就变成功能的堆积，依赖越拉越长，装个CLI工具先下载半个node_modules。spell的思路反过来：约束不是敌人，约束帮你砍掉了所有"顺便做一下"的东西。词典和算法分离、纯文本格式、谁都能改，这些都不是规划出来的，是被64KB逼出来的，结果恰好成了最适合社区接手的形态。
有时候我会想，如果我们给自己的side project也设一个硬限制，比如依赖不超过五个、二进制不超过10MB，会逼出什么不一样的东西？值得试试。
