# 产品需求文档 (PRD): ProjectMoneyX 个人全景财务分析系统

| 文档属性 | 详情 |
| --- | --- |
| **项目名称** | ProjectMoneyX |
| **版本号** | v1.2 (基于开源 ETL 架构优化版) |
| **编制日期** | 2026-02-26 |
| **文档状态** | 进行中 |

## 1. 项目背景与目标

### 1.1 项目背景

随着移动支付的普及，个人财务数据分散在支付宝、微信、各家银行及电商平台中。用户面临“账单碎片化”、“流水重复记录”等痛点。传统的记账软件通常依赖手动记录或单一的账单导入，缺乏灵活的规则引擎来处理复杂的跨账户对账。

### 1.2 项目目标

构建一套自动化、高精度的个人财务分析系统。借鉴开源社区成熟的双轨制记账流转架构，通过引入 `Provider` 解析器与 `Translate` 规则引擎，实现多源数据的标准化转换（IR），并利用算法解决跨账户流水重复问题，提供多维度的收支分析与预算管理功能。

---

## 2. 核心系统架构：ETL 数据工作流

参考业内成熟方案，系统底层采用高度解耦的管道架构，确保后续极强的可扩展性：

**数据流转路径：** `原始账单 (Raw Files) -> 提供方解析 (Provider) -> 中间表示 (IR) -> 规则转换 (Translate) -> 数据库标准账单`

* **Provider 层：** 专注于“读”。屏蔽不同账单格式（CSV, PDF, Excel）的差异。
* **IR 层 (Intermediate Representation)：** 统一的数据结构协议，作为 Provider 和 Translate 的桥梁。
* **Translate 层：** 专注于“洗”。基于 YAML/JSON 规则配置，执行分类映射、时间标准化与账户归属。

---

## 3. 数据采集与 Provider 模块 (Data Ingestion)

针对不同来源的账单，建立独立的 Provider 适配器。当某银行账单格式更新时，仅需修改或新增对应的 Provider，不影响系统核心逻辑。

| 提供方 (Provider) | 原始格式 | 核心提取字段 | 数据权重 | 提取说明 |
| --- | --- | --- | --- | --- |
| **Alipay (支付宝)** | CSV | 订单号、商户、商品明细、金额 | **L1 (最高)** | 标准 CSV 解析，作为消费类主数据。 |
| **WeChat (微信支付)** | CSV | 交易单号、交易对方、交易类型 | **L2** | 预处理跳过表头，提取转账与红包标记。 |
| **Banks (招商/工行等)** | PDF/XLS | 交易日、交易摘要、收支金额 | **L3** | 作为资金实际扣款核对依据 (Reconciliation)。 |
| **JD/Meituan (电商)** | PDF/CSV | 订单明细、支付通道 | **L3** | 重点关注白条/月付等信用支付记录。 |

---

## 4. 数据转换与清洗逻辑 (Translate & Cleaning)

Translate 层是数据质量的核心把控者，负责将 IR 数据转换为最终的财务记录，并解决数据冲突。

### 4.1 Translate 规则引擎

建立基于配置文件的映射规则，实现自动化数据归位：

* **时间与时区标准化：** 统一转换为 ISO 8601 格式，所有国内交易归一化为东八区时间。
* **账户路由 (Account Routing)：** * *规则示例：* 当 Provider 为 `Alipay`，且原始数据中的支付方式为“招商银行信用卡”时，资金来源（Funding Source）自动映射至用户的“招行信用卡”实体账户。
* **智能分类映射 (Category Mapping)：**
* 根据交易对方 (Peer) 或 商品说明 (Item) 进行正则匹配。
* *规则示例：* `Peer` 包含“星巴克”或“瑞幸” -> 映射分类为 [餐饮-咖啡]。



### 4.2 交易链路合并与去重算法 (De-duplication)

同一笔交易会在支付平台（如微信）和资金源（如银行卡）各产生一条流水。系统通过**时间窗与金额双重校验**进行链路合并，而非粗暴删除。

**核心算法逻辑：**
设高权重账单记录为 $T_{primary}$（如支付宝），低权重账单记录为 $T_{secondary}$（如银行卡）。
当同时满足以下条件时，判定为同一条交易链路：

$$| Time(T_{primary}) - Time(T_{secondary}) | \le \Delta t \quad (\text{建议 } \Delta t = 120s)$$

$$Amount(T_{primary}) = Amount(T_{secondary})$$

**处理策略：**

1. 将两条记录在底层数据库建立关联（Parent-Child 或 LinkID）。
2. 前端展示时，**合并为一笔记录**。保留 $T_{primary}$ 的丰富消费明细（如分类、商户名），将 $T_{secondary}$ 的账户信息作为该笔消费的资金出处。

---

## 5. 核心功能模块详述

### 5.1 全景仪表盘 (Dashboard)

* **资产负债表：** 实时聚合各账户总资产、总负债（信用卡/白条），计算净资产。
* **现金流概览：** 本月总收入 vs 总支出，环比上月 (MoM) 增减百分比。

### 5.2 账单查询与多维分析

* **组合漏斗筛选：** 支持时间范围、金额区间、支付渠道、资金账户、交易分类的多条件交叉查询。
* **可视化图表：**
* **消费结构：** 饼图展示各大类的支出占比。
* **资金流向 (Sankey Diagram)：** 桑基图直观展示“收入源 -> 资金池 (账户) -> 支出分类”的完整链路。


### 5.3 预算管理

* **精细化限额：** 支持全局预算和分类预算（例如：设定“交通”每月额度 1000 元）。
* **阈值预警：** 当分类支出进度达到 80% 和 100% 时，系统触发视觉高亮预警。

---

## 6. 非功能需求 (NFR)

* **数据隐私 (Local-First)：** 财务数据极其敏感，系统解析 (Provider) 和转换 (Translate) 过程应优先在客户端（本地环境）执行，拒绝未经加密的云端明文传输。