玻利维亚几乎每一间教堂的地下室里，都堆着这样一只纸箱。箱中塞满了旧册子，有些被几十年的潮气浸得发软，上面手写着成千上万人的洗礼、婚礼与坚振记录。你的曾外祖母1923年出生，需要一份证明？就得有人钻进地下室，一页一页翻出那行褪色的字迹。整个国家登记在册的这类圣事记录超过10万条，却全锁在纸质本子里，没有连通、没有检索，每一次查询都像一场考古发掘。

这就是我们动手搭建 Sacra-360 的起点。问题真实得近乎朴素：玻利维亚天主教会至今管理着体量庞大的纯纸质历史档案。当有人急需一张洗礼证书时，标准流程是——先打电话给堂区，找到对应的登记册，翻开正确的那一页，再手工抄录，最后把这张纸寄出去。如果本子没受潮、没遗失，且堂区当天恰好有人值守，那就算幸运。事实上，我们需要直接啃下的硬骨头包括：10万余条记录需要快速检索；实体纸张正随着时间持续劣化；各堂区之间零互通，信息像孤岛；不少堂区已把旧册子拍成照片或扫描件，但缺乏可查询的手段，那些扫描件等于一堆占空间的像素。

技术层面最让我们兴奋的一个决定，是刻意避开“全用无服务器”或“全走传统架构”的教条，而是选了一条折中的混合路线。Sacra-360 的核心搭载在 EC2 上，后端主服务用 Node.js 写成，常驻进程统一处理认证、用户管理，以及圣事、人员、堂区等核心业务。与它并列运行着一个独立微服务，专门负责生成 PDF 与 Excel 报表。我们之所以没把所有逻辑塞进 Lambda，是因为这里的业务需要持久的数据库连接、集中式业务规则，以及多个模块同时处于活跃状态。如果把它拆成一堆离散的函数，维护复杂度会急剧上升，却换不来与场景匹配的好处。

数据库部分反而平淡得让人安心——RDS 上的 PostgreSQL。没有炫技，也不需要炫技。托管版的 Postgres 已经给了我们关系完整性、自动备份，加上团队本身对它有足够经验，在 MVP 阶段跑在 db.t4g.micro 上完全够用，后续扩展只需垂直或水平一调即可。

真正让我们乐在其中的是 OCR 管线。用户把一页圣事册的扫描图传上来，文件直接进入 S3，接着后端将它发给 AWS Textract，由 Textract 自动提取文字内容；提取结果再被解析成结构化数据——姓名、日期、堂区、登记号、册页编号，一目了然。我们拿一份真实的洗礼记录做过测试，系统自动给出了这样的输出：

{
"datosDetectados": {
"fecha_sacramento": "12/04/2020",
"foja": "45",
"numero": "123",
"nombre": "Juan Diego Pérez Lopez",
"parroquia": "SAN JUAN BAUTISTA"
}
}

这份结果完全是从扫描图像里自动抓出来的。过去那种逐字手工誊写的流程，现在被压缩成了几秒钟的机器运算。整套搭配让原本尘封在纸箱里的两个世纪记录，第一次有了可查询、可连接的数字化生命。能亲眼看到历史档案从物理态的脆弱中挣脱出来，这种感觉，真的很让人振奋。