本地数据工具也是一种小型基础设施

很多工具刚开始都不像一个“项目”。

它可能只是为了把一份数据清洗干净，或者为了让一个地址、行政区划、文档片段、表格文件变得更容易被程序读取。需求很小，边界也很窄，看起来不值得认真写。但这种小工具如果反复出现，就会慢慢变成个人工作流里的基础设施。

2026 年初我做 cpca-rs、cpca-linch 这一类东西时，感受就很明显。表面上它们只是和中文地址、行政区划解析有关的本地工具，但背后其实是同一个问题：真实世界的数据从来不是天然结构化的，尤其是中文资料、业务材料和个人知识库里的内容，很多时候都处在“人能看懂，机器勉强能猜”的状态。

工具要解决一个具体断点

以前做数据清洗，很多时候是为了给数据库入库、给报表统计、给某个业务流程打补丁。现在我更愿意把它看成一个更朴素的问题：把重复出现的断点变成稳定工具。

地址、组织名称、时间、金额、枚举值、状态、文档版本，这些东西如果每次都临时靠人判断，结果一定会漂。漂一次可能没关系，漂多了就会变成系统里很难追的误差。

所以我不太愿意把这种工具只看成“脚本”。它们更像是一些很小的接口层：把现实里的含糊资料转成系统可以检查、可以复用、可以继续处理的材料。

小工具的质量要求不应该太低

个人工具很容易写成一次性的。能跑就行，结果对一次就行，异常先不管，后面再说。

但只要它进入日常工作流，就不能再用临时脚本的标准要求它。至少要能回答几个问题：输入边界是什么？错误怎么暴露？结果能不能复现？以后换语言、换数据源、换调用方，是否还能保持清楚的接口？

这也是我后来更愿意把一些小工具做成明确仓库的原因。不是为了把事情做大，而是为了让它有一个可维护的位置。

一个小工具如果承载的是稳定资料、结构化数据或者后续自动化的入口，它就不只是一个小工具。它是个人工作流里的一块基础设施。