一年半的等待，只为换来一张“1.0”证书
独立开发者 Simon Willison 在个人博客上宣布，他维护的小工具 condense-json 正式发布 1.0 版本。这个库已经存在一年半，这次更新只做了几处“合理且无破坏性”的修复——真正变了的不是代码，而是作者终于愿意在版本号上贴“1.0”这三个字。放在大多数科技新闻的雷达里，这种发布几乎不会激起任何波澜，但它背后其实藏着一个更值得琢磨的问题：一个人为什么要为一个具体又狭窄的工程麻烦专门造轮子，还要等一年半才敢说“这算稳定版了”。
condense-json 要解决的问题很具体：JSON 里经常出现大段重复的字符串，比如日志系统反复记录同一段 prompt 文本。Willison 自己就把它用在 LLM（他维护的命令行工具）生成的 SQLite 日志里，具体接入方式能在 GitHub 的 PR #1586 里看到。
$r 语法怎么把重复字符串“摘”出来
原理不复杂。condense_json() 接收一段 JSON 和一份替换表，比如把反复出现的“with foxes in it”映射成编号“1”。函数扫描整个结构，把匹配到的字符串或子串替换成 {"$r": [...]} 这种标记，原文被拆成片段和引用编号的组合。uncondense_json() 负责反向操作，能把标记按需还原成原始文本。
这套机制真正要去重的，不是同一份 JSON 内部的重复结构，而是跨记录、跨字段的重复内容——今天这条日志和昨天那条用了同一段系统提示词，condense-json 就能把这部分摘出来单独存一份。
它不是压缩，是给“可读性”留了后门
行业里处理 JSON 体积膨胀，常见路数无非几种：换成 CBOR、MessagePack、BSON 这类二进制格式，或者用 JSON Reference/JSON Pointer 做结构复用，再或者干脆丢给 gzip、Brotli 这类通用压缩算法。condense-json 选的是最“笨”的一条路：应用层字符串替换，输出仍然是纯文本 JSON，人眼能直接读。
这个取舍的代价很直接：它换不来通用压缩算法的体积压缩率，也换不来二进制格式的解析速度。它换来的是——数据库里存的日志条目，不用解压就能被 SQL 语句直接查询。对 Willison 的场景来说，这可能比“体积更小”更重要：他要的是随时打开 SQLite 文件，肉眼或一条 SQL 就能看懂里面存了什么。
省的不是磁盘，是排查日志时不用先解压这一步。
这类判断只能来自常识和 README 给出的示例——目前找不到任何第三方对 condense-json 做过的实测数据，也没有和 gzip、CBOR 之类方案的横向压测，关于“到底省了多少空间”的具体数字，眼下无从验证，也不该被当成事实来引用。
敢发1.0，比“怎么发”更值得琢磨
Willison 在博文里提到自己正“更勇于发布1.0版本”，这句话看似随口一提，其实是理解这次发布的关键。condense-json 早就能用，晚发1.0晚了一年半，不是代码不成熟，而是作者过去对“正式版”这三个字更谨慎。这种心态如果延续到他维护的其他小工具上——Datasette 生态里还有不少类似的长尾项目——会是一个比 condense-json 本身更值得盯住的信号。
- 风险.这类长尾开源小工具的信息核实成本很高，除了作者本人的博客和仓库，几乎拿不到独立验证的实测数据。
对普通开发者来说，condense-json 目前的价值边界很清楚：用 LLM 命令行工具、需要长期攒 SQLite 日志、又不想让重复的 prompt 文本把数据库撑大的人，可以直接去看 PR #1586 里的实际接入方式；如果只是单纯想给 JSON 文件减肥，大概率还是 gzip 更省心。