Files
ProjectAGiPrompt/16-ProjectMoneyM-转FireFlyIII/1-原始需求/2-1-优化产品需求文档PRD.md
2026-03-18 16:16:47 +08:00

5.5 KiB
Raw Blame History

产品需求文档 (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) 过程应优先在客户端(本地环境)执行,拒绝未经加密的云端明文传输。