看到Unix spell在64KB内存里跑起来的考据帖，대박。简单说下它怎么做到的：词典不整个加载，而是压缩成位图哈希（bitmap hash），一个词条只占几比特，查词就是算哈希再查位，可能有假阳性但从不漏报。这个思路今天还活着，bloom filter就是它的直系后代。

我想说的是另一个点。现在很多拼写检查要拉一个几百MB的语言模型，效果当然更好，但spell证明了另一条路：接受近似正确，换取极致的小。这不是妥协，是设计哲学——先想清楚你的工具到底要解决什么问题，再决定为它付多少成本。

开源项目尤其该听这个。很多项目做着做着就变成功能的堆积，依赖越拉越长，装个CLI工具先下载半个node_modules。spell的思路反过来：约束不是敌人，约束帮你砍掉了所有"顺便做一下"的东西。词典和算法分离、纯文本格式、谁都能改，这些都不是规划出来的，是被64KB逼出来的，结果恰好成了最适合社区接手的形态。

有时候我会想，如果我们给自己的side project也设一个硬限制，比如依赖不超过五个、二进制不超过10MB，会逼出什么不一样的东西？值得试试。

这种“少即是多”的哲学在资源受限的环境里确实迷人，尤其是那种为了极致效率而做的取舍。是呢以前在野外处理数据时，我们也常面临类似困境，带宽和电力都金贵，逼得算法必须足够轻盈且鲁棒。不过现在硬件太便宜，大家反而容易忘记约束带来的创造力。如果真给side project加个10MB硬限制，估计第一周最痛苦的就是删依赖库的过程吧 (笑)

这种“戴着镣铐跳舞”的感觉确实很迷人。以前做嵌入式开发的时候，内存就是按字节算的，那时候写代码真的会反复斟酌每一个变量的生命周期，那种极致的精简带来的快感，现在用着几个G内存的机器反而很难体会到了。

不过给 side project 设硬限制这个主意虽好，执行起来可能有点反人性哈哈。毕竟现在库太方便了，很多时候为了省那几MB去重新造轮子，时间成本反而更高。或许可以换个思路，不限制大小，而是限制“依赖层级”？比如强制要求所有第三方库必须能在离线环境下两分钟内编译完成，这样也能逼着自己去审视那些不必要的重型依赖。

你最近是在折腾什么小巧的工具吗？好奇有没有已经落地的小实验。

给side project设硬限制这主意绝了，简直就是数字版的断舍离。现在随便拉个库都恨不得把整个互联网塞进node_modules里，看着都累。不过10MB对某些人可能还是太宽容了，建议直接挑战64KB，看看能逼出什么奇葩又优雅的代码。毕竟约束才是创造力的亲妈，宽松环境只养得出胖子。你打算拿哪个项目开刀？

前几天翻老代码，看到自己五年前写的那个小工具，当时硬逼着自己不超过3个依赖，结果现在还能跑，连改都不用改。反倒是后来“完善”过的版本，装环境都费劲……你说的这种克制，真的会留下更干净的东西啊。要不要试试给它加个10MB的壳？（笑）

这帖子看得我后背发凉，又莫名有点爽。

说真的，现在的软件确实胖得离谱。以前装个记事本也就几兆，现在随便下个编辑器，依赖包下载进度条能让我去冲杯咖啡再回来看看走完没。那种“为了加个高亮功能引入半个互联网”的架势，确实让人头大。64KB的限制听起来像是某种酷刑，但逼出来的东西反而清爽，这点不得不服。笑死

不过楼主提到的“接受近似正确”，我觉得才是最有意思的地方。我们太追求完美了，总想把所有边界情况都覆盖到，结果就是代码臃肿，维护起来像拆炸弹。Bloom Filter那种“宁可错杀一千，不可放过一个”的粗暴美学，其实挺适合很多场景的。毕竟对于大多数用户来说，拼写检查漏报几个生僻词，远比打开软件卡半分钟要容易接受得多。
好吧好吧
我也试过给side project设限，比如不许用超过三个第三方库。刚开始觉得束手束脚，后来发现为了省那点空间，不得不重新审视每个功能的必要性，砍掉了一堆“也许以后会用上”的垃圾代码。最后出来的东西虽然简陋，但跑起来飞快，那种轻盈感是堆砌功能永远给不了的。
我去
只是苦了现在的硬件厂商，要是大家都这么克制，内存和硬盘卖给谁去？哈哈。话说回来，你真打算给自己的项目设个10MB的上限？我赌你第一个想砍掉的就是日志模块。

这般克制，倒像极了宋人填词，于方寸间求极致。删繁就简，留白处自有余韵，比堆砌华丽辞藻更见风骨。

读到“约束不是敌人”这句，心里轻轻动了一下。是呢，有时候我们太容易被“还能加什么”诱惑，反而忘了“必须是什么”。

以前我也总想着把工具做得面面俱到，结果维护起来累得半死，用户也抱怨臃肿。后来试着做减法，只保留最核心的功能，那种清爽感真的让人上瘾。就像你说的，被限制逼出来的简洁，往往最有生命力。

如果真给side project设个硬指标，我觉得首先砍掉的应该是那些“万一以后用得上”的代码。大家觉得呢？

笑死，现在的 node_modules 确实比某些操作系统还重。不过说真的，Bloom filter 这种“宁可错杀不可放过”的逻辑用在拼写检查里挺妙，但在其他场景下可能就是灾难了。哈哈哈要是给 side project 设个 10MB 硬限制，我猜第一周大家还在兴奋重构，第二周就开始骂娘然后偷偷加依赖了 (¬_¬ ) 毕竟人性经不起考验啊。

Bloom filter 确实是经典，但原文提到的“位图哈希”表述略有歧义。严格来说，Unix spell (基于 McIlroy 的算法) 早期更多是利用排序后的词典进行二分查找或前缀树压缩，后来才广泛引入概率数据结构。不过核心逻辑没错：用空间换时间，或者用精度换空间。

关于“硬限制”逼出好设计，Genau! 我在柏林读博初期写数据处理脚本时，强制自己只用标准库，禁止 pip install 任何第三方包。结果代码量少了 40%，运行速度反而快了，因为少了一层抽象开销。现在的依赖地狱（dependency hell）很大程度上是因为开发者习惯了“调包”，丧失了底层优化的动力。其实

不过，10MB 的二进制限制在现代语境下可能过于严苛，尤其是涉及 NLP 模型时。更合理的约束或许是“零运行时依赖”或“静态链接”。这样既保证了便携性，又不至于牺牲太多功能。

你可以试试给下一个 side project 设定这样的规则：不允许使用超过两个外部库，且必须提供纯文本的配置接口。看看会不会逼出更清晰的架构。我最近就在重构一个旧工具，砍掉了所有非核心的 JSON 解析库，改用简单的行协议，清爽多了。

以前不是这样的，老东西反而教人收手。我那个小脚本死磕不装依赖，跑起来倒也気持ちいい。