将原始数据与执行快照分开的采集结构

✨ GPT-5.5 的总结 　

把在 JSON、CSV、DuckDB 之间不断摇摆的基准数据迁移到 PostgreSQL，并拆分原始 evidence、observation、基准数据、执行 snapshot 与交付产物的记录。

基准数据在 JSON、CSV、DuckDB 之间不断摇摆

这几天在搭建数据采集、审核、执行、交付流程时，各种问题总是不停冒出来。确实，我既没有系统学过 DB，也没有真正处理过 DB，所以经常更换数据保存方式，而每次都不是简单替换就结束。

一开始，我用 JSON/CSV 采集数据，再接上 DuckDB 方便查看。但 worker 的产物和 coordinator 不断重建 DB 的结构混在一起后，什么是原始数据、什么是基准数据一直在摇摆。

所以我也拟过用 MySQL 建 DB 的方案。但问题并不在 MySQL 本身，而在多个 worker 或脚本都能直接更新基准数据的结构。继续采用这种方式，并发 update、冲突、所有权、回滚问题很可能会反复出现。

之后我也看了其他方式，但核心问题一样。采集数据、基准数据、执行数据与交付产物的边界一旦模糊，同样的问题最终还是会回来。

关键不在 DB 产品，而在 mutation ownership

迁移到 PostgreSQL，并不会让问题自动消失。比起使用哪种 DB，必须先定好谁能够修改基准数据。

worker 以 append-only 的方式留下原始 evidence 和 observation，不直接修改基准数据。coordinator 审核 evidence 和 observation 后，再更新基准数据与基准值。只有把修改基准数据的责任集中在一处，发生冲突时才能追踪到底该回滚什么。

在 PostgreSQL 中拆分角色

所以今天迁移到 PostgreSQL DB 时，我也把这几天搭建的整体流程一起整理了一遍。不是把所有东西都塞进一个 DB 块里处理，而是拆分角色。

• 原始 evidence
  • 保存从公开来源采集的依据和原始值
  • 处理后的值和状态不覆盖原始数据，而是作为单独的历史记录留下
  • JSON/CSV 文件可以是 evidence mirror，但不是基准数据
• observation
  • worker 只把自己负责的采集通道中的观测值提交到 append-only ledger
  • 把发现与补强拆成不同角色
  • worker 不直接修改基准数据
• 基准数据
  • coordinator 审核 evidence 和 observation
  • 只有审核过的值才按既定结构写入基准数据
  • view 用作计算、审核与 export 的表面
• 执行 snapshot
  • 不把采集 view 直接当作实际执行标准
  • 把通过去重与质量 gate 的对象固定为某一时点的 snapshot
  • 执行结果以及排除、后续状态与基准数据分开管理
• 交付产物
  • CSV、Google Sheet、Excel 以及交给 vox.ai 的文件，都从基准数据或执行 snapshot 生成
  • 它们是用于展示或交付的产物
  • 不再把产物当作基准数据来修改

从依据到执行与交付都能追踪了

这样一来，采集到的依据存在哪里、worker 留下什么、哪个值成为基准值、哪个 snapshot 用于实际执行、什么是交付产物，都能在一条流程中追踪了。

当然，这个结构仍然有很多不足，还会有很多要改的地方。之后继续测试、反馈、修改时，也一定会发生各种大改动。流程、harness 结构，还有我的直觉，都会这样一点点继续进化。

也许我的流程搭建能帮到某个人，所以先分享一下。