[开源] 月底绩效核算改了十几版Excel,为什么事后复盘总是找不到第一处断链?基于追加式事件链与见证包独立验真的回放机制

本项目面向医院绩效办、运营与财务复核、临床科主任以及内审人员的月频对账场景。过去，绩效核算的调整过程往往散落在多个版本的表格文件、邮件和聊天记录中，一旦数据出现争议，人工拼凑调整过程极其耗时且容易出错。我们把这种找文件、翻记录、问经办的混乱过程，压缩为选月份、选科室、回放并验真的标准化动作。系统只读接收HIS、财务与绩效系统导出的脱敏文件，不直写生产核算结果。所有调整以追加式事件入链，最终封账版本可下载见证包，在独立进程内重算根并定位首个断链事件。底层采用Go语言开发，结合SQLite作为追加式存储，前端使用React与TypeScript构建单页应用，支持本地裸跑与Docker容器化部署。

适用场景与目标岗位

我们在设计之初，梳理了医院内部参与绩效核算的各个角色。每个角色在月末对账时面临的痛点不同，我们针对这些具体时刻提供了对应的能力支撑。

通过这种角色视角的拆解，我们确保系统不仅是一个数据记录器，而是能够融入医院现有管理流程的对账基础设施。

核心能力与链式账本设计

绩效核算最核心的诉求在于可追溯与防篡改。为了实现这一点，我们摒弃了传统的关系型数据库直接覆盖更新的做法，转而采用链式账本的设计思路。

所有调整以追加式事件入链，旧事件不可原地覆盖。如果发现之前的调整有误，纠错必须走更正事件。这种设计保证了历史操作的完整性，任何一次修改都会在账本上留下清晰的痕迹。

在数据投影方面，我们实现了确定性投影。相同的基线与事件序列，在任意进程内均能重算到相同的事件根、状态根、来源根与审批回执根。这四类根分别代表了操作序列的哈希、最终数值的哈希、原始文件指纹的哈希以及签字状态的哈希。将它们分开计算，可以让我们在验真时快速定位到底是数据算错了、源文件被改了，还是审批流程出了问题。

独立验真是我们非常看重的一项能力。导出冻结版本的见证包后，内审人员可以在另一台电脑的独立进程内重算四根。如果数据被篡改，系统能够精准定位首个断链事件，并输出期望根与实际根的对比。这种机制不依赖中心化的信任，而是通过密码学哈希来保证数据的自洽性。

在双人确认与异议留痕方面，封账需要经办与独立复核人共同确认。科主任如果对某项绩效有异议，可以将其作为事件留痕，但这不会直接修改当前的绩效值。经办人收到提示后，可以通过追加更正事件来进行修订，旧版本依然可以完整重现。

典型业务场景回放

为了让大家更直观地理解系统是如何运作的，我们列举了三个最典型的业务场景。

场景一是月初导入与两次调整。绩效办经办把本月HIS与财务脱敏数据上传到导入接口，系统生成来源清单与基线快照。随后，经办提交两次调整，每次提交时系统都会自动校验前序哈希、序号、字段映射版本与附件摘要。月末经办发起封账请求，系统检查四根一致且隔离区为空。经办与复核人各自确认后，封账生效并写入签名检查点。

场景二是科主任月结答疑与异议。科主任在列表中点选本月本室，进入版本时间线，可以清晰看到从初始版本到最新版本的源行、前后值、调整理由与四根状态。如果主任对某次调整有异议，点击提出异议并填写理由码。这个异议会作为事件留痕，不会改变当前数值。经办人后续可以通过更正事件追加修订，整个过程公开透明。

场景三是内审抽查与独立验真。内审人员下载某月封账版本的见证包，在一台只读、可离线、无生产凭据的电脑上运行验真命令。如果数据完好，输出验证通过与四根摘要。如果有人改动了任意附件摘要或调整事件，再次运行会直接输出首个断链事件ID、期望根与实际根，并给出具体的诊断信息。

$ perfverify witness-202508-002.zipverified         : trueperiod_id        : 202508version          : 002event_root       : 5f8c...b9d2state_root       : a01e...7c44source_manifest  : 1b62...d8e0approval_receipt : 4d77...3fa1checkpoint       : signed (local_consistent)first_bad_event  : -stable_exit_code : 0

被篡改后再次运行，输出结果会发生明显变化：

$ perfverify witness-202508-002-tampered.zipverified         : falseperiod_id        : 202508version          : 002first_bad_event  : evt-014 (sequence=14, reason_code=metric_update)expected_root    : 5f8c...b9d2actual_root      : 71ab...09cfdiagnostics      : [error] event_hash_mismatch @ event[14].changes[2].value_scaledstable_exit_code : 2

部署与运行方式

我们提供了多种部署方式，以适应医院内部不同的网络环境和运维习惯。

方式一是本地裸跑，适合开发与冒烟测试。你需要准备Go 1.23以上、Node 18以上、Python 3.10以上以及sqlite3命令行工具。拉取依赖后，复制环境变量样例，启动REST服务。服务默认监听本地回环地址的8080端口。你可以运行健康检查接口，并执行端到端演示脚本来验证基线导入、调整、封账到见证导出的完整流程。

# 1. 准备环境go versionnode --versionsqlite3 -version# 2. 拉取依赖go mod tidy( cd web && npm install )# 3. 复制环境变量样例cp .env.example .env# 4. 启动 REST 服务go run ./cmd/server &SERVER_PID=$!sleep 1# 5. 验证健康检查curl -fsS http://127.0.0.1:8080/healthcurl -fsS http://127.0.0.1:8080/readycurl -fsS http://127.0.0.1:8080/metrics | head -5# 6. 运行单元测试与回归go test ./...( cd web && npm test )( cd web && npm run build )# 7. 端到端演示bash scripts/demo.sh# 8. 关停服务kill "$SERVER_PID"

方式二是Docker Compose部署，这是院内服务器推荐的方式。你需要在主机上准备持久卷，并将目录所有者对齐到非root用户。首次启动前，需要生成API Key文件，确保明文密钥不进入代码仓库。构建并启动容器后，可以通过浏览器访问前端界面。请注意，公网环境禁止直连，必须经过反向代理并配置TLS。

# 1. 准备主机持久卷sudo mkdir -p /opt/perf-ledger/{data,imports,keys,mappings}sudo chown -R 65532:65532 /opt/perf-ledgersudo chmod 750 /opt/perf-ledger/keys# 2. 进入工程目录cd /opt/perf-ledger/app# 3. 生成 API Key 文件docker run --rm -v /opt/perf-ledger:/out perf-ledger-replay:0.1.0 \  perfctl keygen --out /out/keys/checkpoint.ed25519# 4. 首次构建并启动docker compose builddocker compose up -d# 5. 验证服务状态sleep 5curl -fsS http://127.0.0.1:8080/healthcurl -fsS http://127.0.0.1:8080/ready# 6. 停止与查看日志docker compose logs -f --tail=100 perf-ledgerdocker compose down

方式三是无外网环境部署。考虑到很多院内服务器无法访问公网镜像仓库，你可以在能上网的跳板机上拉取基础镜像并保存为归档文件，然后在院内服务器上加载该归档文件，再按照方式二的步骤进行部署。

命令行与接口设计

为了方便运维人员与外部系统集成，我们设计了完善的命令行工具与REST接口。

命令行工具 perfctl 涵盖了从数据导入到独立验真的全生命周期操作。

REST接口则主要服务于前端单页应用与自动化脚本，提供了标准的HTTP方法调用。

配置入口主要集中在环境变量与YAML配置文件中。环境变量用于覆盖本地开发配置，YAML文件则用于定义路径、上传限制、字段映射、角色权限与检查点目录等核心参数。

架构设计与数据流向

系统的整体架构分为数据接入、核心处理与前端展示三个层次。外部系统导出的脱敏数据通过受控接口进入核心服务，服务内部完成事件的追加、根的計算与见证包的生成。前端单页应用通过REST接口与核心服务交互，提供可视化的版本回放与操作界面。

+-------------------+        +-------------------+        +-------------------+|  HIS / 财务 / 绩效 |  --->  |  核心回放服务      |  --->  | 前端单页应用       || (脱敏数据文件)     |  受控  |  (Go, SQLite)      |  REST  | (院内浏览器)       |+-------------------+  接入  +-------------------+        +-------------------+                                |        |        |                                v        v        v                          +-------+ +-------+ +-------+                          | 类型化| | 四类  | | 见证包|                          | 事件  | | 根    | | 导出  |                          +-------+ +-------+ +-------+                                ^                                |                          +-----+-----+        +-------------------+                          | 独立验真器 |  <---  | 内审独立电脑       |                          | (独立 CLI) |        +-------------------+                          +-----------+

在数据流设计上，基线与调整事件以规范化编码写入SQLite追加日志，前序哈希与序号在校验后落盘。投影器只依赖基线与有序事件，不读取系统时钟或随机值，确保跨进程输出同根。见证包导出前，系统会在事务内冻结周期、版本、头部与根信息，再收集基线、事件、来源清单与审批回执。独立验真器只读取见证包内的清单与数据，重算四根并比对签名，整个过程完全离线且可重复。

安全合规与边界说明

在医疗信息化领域，安全与合规是不可逾越的红线。我们在设计系统时，明确了多项边界与原则。

首先，本工具不输出诊断结论，不自动签字，更不自动回写生产系统。所有的封账与异议操作，均需由授权人员人工确认并留痕。我们提供的是辅助核对能力，而非替代人工决策。

其次，我们不宣称单机数据库绝对不可篡改。当外部检查点不可用时，前端界面会明确显示仅本机一致，未完成独立锚定。这种坦诚的设计有助于内审人员准确评估数据的可信度。

第三，我们不建立公链、代币或跨院共识。这里提到的链式账本，仅指相对独立检查点的篡改可发现与可独立验真。我们利用密码学哈希来保证数据的自洽性，而不是引入复杂的分布式共识机制。

在数据隐私方面，员工标识、姓名与联系方式一律以脱敏引用入链。通知通道默认走模拟提供者，不外发原始明细。上传路径、附件类型与大小受白名单严格约束，任何路径穿越或异常写入都会产生可观测的诊断日志。

最后，我们不会向终端用户暴露上游参考仓库名或内部开发过程材料。所有的溯源信息仅保留在开发文档中，确保生产环境的纯粹与安全。

项目地址： https://github.com/nexorin9/perf-ledger-replay

往期热门文章