# 财报图表项目数据架构改造方案

> 状态：建议实施
>
> 目标：保持静态图表站点的低复杂度，同时建立可追溯、可重复生成的数据链路。

## 1. 决策

当前不建设在线数据库和后端 API。

本项目目前是静态数据展示工具：浏览器按需读取 CSV，数据量很小，没有多人并发写入、权限控制、运行时查询或服务端计算的需求。此时引入 Postgres、API、鉴权和迁移机制会增加运维成本，但不能解决当前的数据正确性与可维护性问题。

CSV 保留为图表的运行时交付格式；需要改造的是 CSV 之前的数据生产链路。

## 2. 当前问题

### 2.1 权威数据源不一致

设计文档和 `data/ppmt/rawData/README.md` 将 `财报分析底稿.xlsx` 定义为唯一维护入口，但 `scripts/normalize_ppmt_financials.mjs` 实际读取的是 `data/ppmt/raw/*.csv`。底稿更新不会稳定地传递到图表。

### 2.2 派生产物被当作输入

归一化脚本的一部分通过 `readRuntimeRows()` 读取 `data/ppmt/*.csv`，再生成年度、半年等视图。IP、品类、资产等数据不能完全从上游重新构建；运行时 CSV 被删除、手改或过期时，会影响后续结果。

### 2.3 数据更新不完整

已出现底稿含有新期间、但相应图表 CSV 尚未更新的情况。问题不在某个数值，而在于链路没有可重复的全量构建保证。

### 2.4 发布边界不清晰

Vite 目前递归复制 `data/` 下的全部 CSV，因此原始披露 CSV 也会进入 `dist/`。原始证据、维护输入和公开运行时数据应有物理边界。

### 2.5 现有测试只验证展示

`pnpm test` 已能验证 manifest、CSV 可读性、图表渲染和部分视觉规范；还没有验证期间、单位、勾稽、同比口径、来源定位或派生逻辑。

## 3. 目标架构

```text
原始披露文件（PDF / XLSX / 原始导出 CSV，只读证据）
        │
        ▼
人工录入与复核的规范化基础事实层（唯一权威）
        │  数据构建：映射、同比、期间拆分、勾稽、图表数据整形
        ▼
图表运行时 CSV（完全可重建，不允许手工修改）
        │
        ▼
静态站点：manifest + Vanilla JS + ECharts
```

### 3.1 各层职责

| 层 | 内容 | 是否人工编辑 | 发布到网站 |
| --- | --- | --- | --- |
| 原始证据 | 财报 PDF、公司 XLSX、原始导出 CSV、截图 | 否 | 否 |
| 基础事实层 | 直接披露的数值、期间、单位、来源定位、科目映射 | 是，受控编辑 | 否 |
| 派生层 | H2、同比、利润率、分类汇总、年度/半年视图 | 否，脚本生成 | 否 |
| 图表 CSV | 仅包含图表需要的字段和布局 | 否，脚本生成 | 是 |

## 4. 基础事实层如何维护

基础事实层需要人工维护，但人工只编辑直接披露且可追溯的事实。

允许人工编辑的内容：

- 原始财报直接披露的金额、门店数等基础数值；
- 期间、币种、单位、合并口径；
- 来源文件、页码、表格、行号或单元格定位；
- 科目映射与分类规则，例如“类现金”“投资资产”“经营资产”。

禁止人工编辑的内容：

- 同比、环比、占比、利润率；
- `H2 = FY - H1` 等期间拆分；
- 分析分类小计；
- 任何图表运行时 CSV。

现有 `财报分析底稿.xlsx` 可以继续作为人工录入界面。改造后的要求是：构建脚本必须从这份工作簿或其一次性导出的规范化输入文件读取，不再并行从其他位置读取同一事实。工作簿是编辑器，不是与其他 CSV 并列的第二权威来源。

基础事实建议采用“长表”结构，便于复用、校验和未来接入多家公司：

| company_id | metric_id | period_end | period_type | value | unit | source_file | source_locator | revision |
| --- | --- | --- | --- | ---: | --- | --- | --- | --- |
| ppmt | revenue | 2026-06-30 | H1_YTD | 171.73 | CNY_100M | 2026H1.pdf | p.12 / 利润表 / 营业收入 | 1 |

运营类事实可使用相同结构，或按需要增加 `dimension_type`、`dimension_value`，例如地区、渠道、IP 和品类。

## 5. 目录与构建边界

建议将数据目录拆分，避免将证据文件误发布：

```text
data/
  ppmt/
    evidence/                 # 原始披露文件，只读，不发布
    input/                    # 基础事实与映射规则，受控维护，不发布
    generated/                # 构建中间产物，可删除并重建，不发布
public/
  data/
    ppmt/                     # 仅图表运行时 CSV，发布
scripts/
  import_ppmt_facts.*         # 从 XLSX 或受控输入导入基础事实
  build_ppmt_datasets.*       # 从基础事实完整生成图表 CSV
  check_ppmt_data.*           # 质量与勾稽校验
```

Vite 仅复制 `public/`；不再以“复制整个 `data/` 再过滤扩展名”的方式发布文件。

## 6. 数据构建与校验

推荐提供三个明确命令：

```bash
pnpm data:import   # 可选：从人工维护的 XLSX 导出/读取基础事实
pnpm data:build    # 从唯一权威源全量生成 generated 与 public/data
pnpm data:check    # 校验输入、派生结果与勾稽关系
pnpm test          # 图表渲染和展示回归
pnpm build         # 静态站点构建
```

`data:build` 必须满足幂等性：在清空 `generated/` 和 `public/data/` 后，仍能只凭 `input/` 与 `evidence/` 完整生成相同的图表数据。构建脚本不得读取自身输出目录作为输入。

`data:check` 至少覆盖：

- 必填字段、数值类型、单位和币种；
- 期间格式、排序、重复与缺失；
- 流量类 `H2 = FY - H1`，时点类 H2/年末口径；
- 同比仅比较同口径上一年期间；
- 资产 = 负债 + 权益、现金流勾稽等适用检查；
- 图表字段 schema、空值约束和合理数值范围；
- 每条人工事实都有来源定位。

## 7. 分阶段实施

### P0：先恢复单一真相源

1. 决定以现有底稿 XLSX 作为人工维护入口。
2. 为底稿建立稳定导入器，输出规范化基础事实；或将其导出为版本化输入 CSV。
3. 将现有脚本中读取运行时 CSV 的逻辑改为读取基础事实。
4. 将图表 CSV 移到仅发布目录，原始证据移出发布路径。
5. 增加 `data:check` 的最小校验与全量重建测试。

完成标准：删除全部图表 CSV 后，仍能从唯一输入源重建所有图表；底稿新增期间后，数据检查能明确指出哪些图表应更新。

### P1：第二家公司接入后抽象共性

1. 固化跨公司通用的基础事实 schema、期间模型、来源定位格式和校验规则。
2. 仅在两个公司确实复用同一字段映射与口径时，抽取通用图表或数据模板。
3. 为 manifest 增加可选的数据契约版本，避免图表代码默默依赖 CSV 列名。

### P2：需要分析型查询时引入本地数据库

当需要跨公司指标筛选、较多事实数据查询、复杂聚合或批量分析时，引入 DuckDB + Parquet 作为本地构建和分析层。它可以替代或补强 `generated/`，但前端仍然发布静态 CSV 或预聚合 JSON。

### P3：满足以下条件才建设在线数据库

仅在出现多人在线录入、权限分级、审计版本、自动数据抓取、实时更新或面向用户的任意组合查询时，再建设 Postgres + 后端 API。

在线数据库只替换“基础事实层的存储与协作方式”；图表运行时仍应优先使用缓存后的静态数据集或受版本控制的 API 响应，不应让每张图直接查询底层事实表。

## 8. 数据库选择原则

“使用数据库”不是替代数据治理的方案。无论存储介质是 XLSX、CSV、DuckDB 还是 Postgres，都必须先满足：

1. 只有一个权威输入源；
2. 派生产物可从该输入源完整重建；
3. 每个数值可回溯到披露来源；
4. 口径、单位和期间语义经过自动校验；
5. 前端只消费稳定的数据契约。

在当前规模下，最优路线是“XLSX 受控人工录入 + 规范化事实 + 自动生成 CSV + 静态发布”，而不是立即迁移在线数据库。