H6.ai 如何借助 Lakebase Postgres 构建 AI 驱动的财务自动化
内容提要
H6.ai 利用 AI 自动化应付账款处理，针对客户 ERP 数据持续变动带来的回归测试难题，采用 Lakebase Postgres 为每个客户建立独立数据库，并通过写时复制分支冻结问题发生时的数据快照。测试在独立分支上运行，不写入生产库，既验证处理是否完成，也校验匹配、科目和政策是否正确，从而可靠地发现模型或逻辑变更引发的回归。
延伸解读
回归测试的难点：数据变动而非代码
文章指出，H6.ai 的客户 ERP 数据持续变动，同一张发票在不同时间处理可能得到不同结果。这使得回归测试难以判断结果变化是代码变更还是数据变化所致。传统方法需要重建问题发生时的数据状态，但数据已变，难以复现。Lakebase 的写时复制分支能冻结问题发生时的完整数据快照，包括采购订单、供应商、科目和政策设置，从而将数据状态固定下来，让测试可重复。
分支隔离如何保障生产数据安全
H6.ai 为每个客户建立独立的 Lakebase Postgres 数据库，测试时从生产库分支出一个快照，所有测试写入都发生在独立运行分支上，结束后删除。测试从不写入生产库，也不向客户 ERP 过账。分支管理使用最小权限的服务主体，并设有保护机制拒绝触碰客户生产分支。这种隔离让团队能使用真实生产数据的副本、走与生产相同的代码路径进行测试，而客户账目不受影响。
双重校验：不只确认处理完成
文章强调，仅检查发票是否被处理是不够的，因为发票可能被正确读取却匹配到错误的采购订单、分配到错误的科目或违反客户政策。因此每次测试运行都从两个维度评判：一是处理是否完成，二是匹配、科目和政策是否正确。这种双重校验能发现模型或逻辑变更引发的回归，让团队在变更模型、改进提取、降低成本或调整匹配与政策引擎时，能在真实客户案例上提前发现问题。
测试用例随客户增长而积累
H6.ai 不满足于修复问题后就结束，而是将问题发生时的数据库状态保留为快照，加入发票和预期结果，使其成为永久测试用例。随着客户、ERP 和发票格式增多，测试覆盖范围也随业务复杂度增长。每个测试用例将一张发票与一个快照及预期结果配对，测试计划可混合来自多个客户、ERP 和发票格式的用例，每个用例都在各自保留的数据库上运行，确保相同测试在不同时间得到相同起点。
Q&A
H6.ai 为什么需要为每个客户建立独立的数据库？
因为每个客户的 ERP、供应商、采购订单、会计科目表和政策都不同，独立数据库可以隔离客户数据，并允许冻结数据快照，便于调查错误和进行回归测试。
Lakebase 的分支功能如何帮助 H6.ai 进行回归测试？
分支是写时复制的数据库副本，创建时不复制数据，只存储变更。H6.ai 在发现处理错误的发票时，会为该客户数据库创建分支并保留为快照，冻结当时的采购订单、供应商、科目等状态。测试在独立分支上运行，不写入生产库，从而可靠地发现模型或逻辑变更引发的回归。
H6.ai 的测试运行包含哪些步骤？
测试运行包含四个步骤：1）从实时数据库分支一次以获取快照，且从不写入该快照；2）每个测试用例将一张发票与一个快照及预期结果配对；3）测试在独立的运行分支上执行，所有写入都留在该分支上并在结束后删除；4）测试从不向客户 ERP 过账，实时数据库也从不被写入。
H6.ai 如何判断一张发票处理得是否正确？
每次运行从两方面评判：一是验证处理是否完成，二是校验匹配、科目和政策是否正确。仅检查发票是否被处理是不够的，因为发票可能被完美读取但仍匹配到错误的采购订单、分配到错误的科目或违反客户政策。
Lakebase Postgres 的写时复制分支有什么特点？
分支是数据库在某个时间点的即时隔离副本，类似 Git 分支。它使用写时复制：新分支与父分支共享存储，只单独写入变更的数据。因此无论数据库多大，分支都瞬间出现，且创建分支不会拖慢生产环境。
H6.ai 未来计划如何利用 Lakebase 的 Lakehouse//RT 查询？
H6.ai 计划利用 Lakebase 表上的 Lakehouse//RT 查询，在无需复制数据的情况下对 Lakebase 运行只读分析查询，从而无需管道即可获得新鲜的分析数据。
