# 智能 AI 对账平台 — 产品需求文档（PRD）

> **版本：** v1.5 | **日期：** 2026-07-13 | **作者：** AI 对账产品团队
>
> **v1.5 更新：** 新增「自定义对账-自然语言创建」功能，用户可用中文描述需求，AI 自动生成对账方案配置
> **v1.4 更新：** 新增「自定义对账」模块；新增国内大模型接入（DeepSeek / 通义千问 / Kimi 等）
> **v1.3 更新：** 新增预测模型 vs LLM 分层架构设计
> **v1.2 更新：** 新增行业痛点数据（10 项全球调研）
>
> 基于 AI/LLM 技术能力，设计一套适用大多数企业的智能对账平台。

---

## 目录

1. [产品概述与定位](#一产品概述与定位)
2. [用户角色与核心场景](#二用户角色与核心场景)
4. [功能需求](#四功能需求)
5. [AI 能力矩阵](#五ai-能力矩阵)
6. [技术架构要求](#六技术架构要求)
7. [数据模型设计](#七数据模型设计)
8. [非功能性需求](#八非功能性需求)
9. [实施路线图](#九实施路线图)
10. [附录：核心算法说明](#十附录核心算法说明)

---

## 一、产品概述与定位

### 1.1 产品愿景

打造一款 **"会思考的对账引擎"**——不仅自动化执行对账任务，更能像资深财务主管一样理解数据语义、识别异常模式、解释差异原因、建议处理方案。

### 1.2 产品定位

| 维度 | 定位 |
|------|------|
| **目标市场** | 中大型企业（年营收 5000 万以上），财务团队 5 人以上 |
| **核心价值** | 将对账效率提升 80%+，差异发现率提升 50%+，月末结账周期缩短 60%+ |
| **技术壁垒** | LLM 驱动的模糊匹配 + 多维度异常检测 + 可解释的差异分析 |
| **商业模式** | SaaS 订阅（按对接账户数/数据量计费）+ 私有化部署 |

### 1.3 与传统对账的差异

| 传统对账 | 智能 AI 对账 |
|----------|-------------|
| 基于规则精确匹配（金额必须相等） | LLM 语义理解 + 模糊匹配（容忍小数点、汇率、时差等差异） |
| 差异靠人工逐条排查 | AI 自动归类差异 + 给出根因分析 |
| 模板固定，新场景需开发 | 自然语言描述规则，AI 自动生成匹配逻辑 |
| 被动响应，问题事后发现 | 主动预警，识别趋势性异常 |
| 只有 "匹配/不匹配" 二元结果 | 置信度评分 + 多候选推荐 + 处理建议 |

### 1.4 行业痛点：为什么市场需要智能对账

以下数据来源于对全球 300+ 财务团队的调查研究（SixthFin/Odoxa 2026、AutoRek 2024、BlackLine/FSN、Deloitte、LiveFlow 2025、Gartner 2023 等）：

#### 手工依赖症：电子表格仍是主流

| 数据 | 来源 |
|------|------|
| **67%** 的英国 250 人以上企业仍用 Excel 做账务核对 | SixthFin/Odoxa (2026) |
| **84%** 的支付公司严重依赖手工任务和电子表格 | AutoRek (2024) |
| **57%** 的金融公司通过电子表格或混合方式管理对账 | AutoRek |
| **40%** 的企业最多一半的财务数据靠手工处理 | bluQube (2025) |

#### 时间黑洞：月末关账周期过长

| 数据 | 来源 |
|------|------|
| **50%** 的财务团队需要 6 个工作日以上才能关账 | CFO.com / Ledge (2025) |
| 仅 **16%** 的团队能在 3 天内完成关账 | LiveFlow / CFO Dive (2025) |
| 千人规模企业每年消耗约 **10 万人时** 在对账上，直接人力成本 **$300-500 万** | aurum.solutions |
| 财务团队 **41%** 的时间花在收集和处理数据上，而非分析数据 | Deloitte |
| 平均现金对账每月耗时 **20-50 小时** | 多来源综合 |

#### 错误率惊人：手工流程的隐性代价

| 数据 | 来源 |
|------|------|
| **59%** 的会计师每月犯多次财务错误；**18%** 每天犯错 | Gartner (2023) |
| 复杂操作中手工对账错误率可达 **45%** | NetSuite |
| 手工数据录入每笔交易 **1.6%** 的错误率（每万笔 160 个错误） | Institute of Finance & Management |
| **~94%** 的业务电子表格包含错误 | 多来源研究 |
| **1/3** 的财务领导不信任自己关账数据的可靠性 | SixthFin/Odoxa (2026) |
| **~70%** 的财务领导曾基于不准确的财务数据做出重大决策 | BlackLine/Censuswide |

#### 数据孤岛：系统碎片化

| 数据 | 来源 |
|------|------|
| **~80%** 的财务人员将月末关账延迟归咎于等待其他系统/部门的数据 | LiveFlow / CFO Dive (2025) |
| 英国企业平均管理 **8-25** 个互不连接的系统 | Accountancy Age |
| **61%** 的组织认为总账系统过多导致混乱 | FSN/BlackLine |
| **83%** 的组织被最后一个业务单元的数据提交卡住 | FSN/BlackLine |

#### 人才流失：对账工作的隐性人力成本

| 数据 | 来源 |
|------|------|
| **74%** 的会计师承受工作相关压力 | CABA (2026) |
| **77%** 的财务专业人士经历过职业倦怠 | Deloitte |
| 美国过去 2 年约 **30 万** 会计师离职（从业人数减少 17%） | 多来源综合 |
| **97%** 的财务领导承认关账对工作负荷有负面影响；**93%** 表示影响员工积极性 | SixthFin (2026) |
| 替换一名熟练会计师的成本高达其年薪的 **30%** | 美国劳工部 |

#### 合规风险与欺诈敞口

| 数据 | 来源 |
|------|------|
| 存在实质性内控缺陷的组织欺诈发生率高出 **80-90%**，通常与手工对账相关 | ACFE |
| **80%** 的支付公司预计合规成本将继续上升 | AutoRek |
| **~80%** 的公司经常错过报告截止日期 | AutoRek |
| **79%** 的公司表示对账流程无法处理当前数据量 | AutoRek |
| Macy's 在 2024 年 12 月因对账漏洞发现 **$1.51 亿** 虚假账目（真实案例） | SEC Filing |

#### 痛点一句话总结

> **手工对账每年浪费企业百万美元级成本，消耗财务团队 40%+ 时间，产出 45% 错误率，导致 30 万美国会计师离职——而全球主流对账软件在 AI 能力上几乎全部空白。**

---

## 二、市场对标分析

### 2.1 厂商分层与定价

全球对账软件市场可分为三个梯队：

| 梯队 | 代表厂商 | 年费区间 | 目标客户 | 实施周期 | 核心卖点 |
|------|---------|---------|---------|---------|---------|
| **企业级** (Enterprise) | BlackLine、Oracle ARCS、SAP ICMR、Trintech Cadency | $30K-$340K+ | 年营收 1 亿以上、多实体跨国企业 | 3-12 月 | 合规控制、SOX 审计、全流程关账 |
| **中端市场** (Mid-Market) | FloQast、Trintech Adra | $30K-$120K/年 | 年营收 5000 万-5 亿企业 | 1-6 周 | 快速部署、Excel 友好、性价比 |
| **小企业** (SMB) / 国内 | Xero、QuickBooks、用友 NCC、金蝶云星空 | $240-$1000/年 | 中小企业、国内企业 | 即时-8 周 | 易用性、本地化、与核心财务系统集成 |

#### 企业级厂商详细分析

| 厂商 | 价格 | 核心优势 | 核心短板 |
|------|------|---------|---------|
| **BlackLine** | $77K-$340K/yr | 关账全流程管理全球第一；最完善的 SOX 合规审计追踪 | 价格昂贵；无深度 AI 语义匹配；实施 3-6 月 |
| **Oracle ARCS** | 按 Oracle 生态定价 | 与 Oracle ERP 原生集成；交易级自动对账 | 仅适合 Oracle 体系；学习曲线极陡（4-8 月实施） |
| **SAP ICMR** (Intercompany Matching & Reconciliation) | $40K+/yr | 嵌入 S/4HANA；实时集团内部往来匹配 | SAP 绑定；非 SAP 场景几乎不可用 |
| **Trintech Cadency** | $60K+/yr | 对账+关账+风险监控一体化；适合超大型跨国企业 | 部署复杂；需专业实施团队（4-8 月） |

#### 中端及国内厂商

| 厂商 | 价格 | 核心优势 | 核心短板 |
|------|------|---------|---------|
| **FloQast** | $30K-$120K/yr | G2 评分最高；Excel 原生体验；4-6 周上线 | 无 AI 能力；偏重任务管理而非对账引擎 |
| **Trintech Adra** | ~$33K 一次性 | 性价比高；Workday 用户友好 | 功能深度有限 |
| **Xero** | $20-$90/mo | 最佳 UX；全球银行 Feed 支持最广 | 仅基础银行对账；无企业级功能 |
| **用友 NCC** | 按模块定价 | 深度适配中国企业会计制度；银企直联成熟；RPA+基础 AI | 跨系统对接困难；国际化弱 |
| **金蝶云星空** | 按模块定价 | 中端中国企业定位；阿米巴核算特色 | AI 能力弱；无跨系统对账 |

> **注：** 2025-2026 年，Agentic AI 已成为对账领域的主导趋势。BlackLine 推出 Verity AI + WiseLayer、Trintech 嵌入平台级 Agent、AutoRek 发布 ARIA 智能 Agent、JustPerform 的 Isaac Agent 实现 95% 自主对账、Digits 的 AI 会计 Agent 24/7 运行。头部厂商自动匹配率已收敛到 95-99.99%。**但关键空白仍然存在：**（1）所有厂商的匹配引擎依赖预测模型/规则，非 LLM 语义理解；（2）自然语言交互仅 Digits "Ask Digits" 一家尝试；（3）智能根因分析（CoT 推理链）无人实现；（4）中国市场深度适配完全空白。

### 2.2 全球主流对账产品功能矩阵（更新至 2025-2026）

#### 传统企业级 & 中端厂商

| 功能模块 | BlackLine | Oracle ARCS | SAP ICMR | Trintech Cadency | FloQast | Xero | 用友 BIP | 金蝶云星空 |
|----------|-----------|-------------|----------|------------------|---------|------|----------|------------|
| **银行对账** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| **总账对账** | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| **应收/应付对账** | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ |
| **跨系统对账** | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | 部分 | ❌ |
| **三方支付对账** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
| **多币种对账** | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ |
| **AI 自动匹配** | ✅ Verity | 基础 | 基础 | ✅ | ❌ | ❌ | ✅ | ✅ |
| **AI 异常检测** | ✅ JRA | ❌ | ❌ | ✅ | ❌ | ❌ | 基础 | ❌ |
| **AI 预测分析** | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
| **自然语言查询** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| **LLM 语义匹配** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| **智能根因分析** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| **Agentic AI** | ✅ WiseLayer | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ | ❌ |
| **工作流审批** | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| **审计追踪** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| **中国市场适配** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |

#### AI-Native 新兴厂商（2023-2025 年涌现）

| 功能模块 | AutoRek ARIA | HighRadius | Digits | JustPerform (insightsoftware) | Simetrik | Xelix | Docyt | Microsoft Finance Agents |
|----------|-------------|------------|--------|-------------------------------|----------|-------|-------|--------------------------|
| **银行对账** | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| **总账对账** | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| **应收/应付对账** | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
| **跨系统对账** | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ |
| **三方支付对账** | ✅ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| **多币种对账** | ✅ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
| **AI 自动匹配** | ✅ 99.99% | ✅ 90%+ | ✅ 95%+ | ✅ 95% | ✅ 99% | ✅ | ✅ | ✅ |
| **AI 异常检测** | ✅ | ✅ 80% 自动解决 | ✅ | ✅ | ✅ 欺诈检测 | ✅ | ✅ | ✅ |
| **AI 预测分析** | ❌ | ✅ | ✅ 24/7 方差分析 | ❌ | ❌ | ❌ | ✅ | ✅ |
| **自然语言查询** | ❌ | ❌ | ✅ "Ask Digits" | ❌ | ❌ | ❌ | ✅ GARY | ❌ |
| **LLM 语义匹配** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| **智能根因分析** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| **Agentic AI** | ✅ ARIA | ✅ | ✅ 会计 Agent | ✅ Isaac | ✅ | ✅ | ✅ | ✅ 后台自主运行 |
| **中国市场适配** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |

> **核心发现：** 2025-2026 年，AI 自动匹配和 Agentic AI 已从差异化能力变为**标配**。头部厂商自动匹配率收敛到 95-99.99%。但存在 **两个结构性空白**：（1）所有厂商（含 AI-Native）的匹配引擎均基于预测模型/统计算法，**无人使用 LLM 做语义级对账匹配**；（2）**无任何厂商覆盖中国市场**（CAS 合规、银企直联、全电发票、微信/支付宝）。

### 2.3 各厂商核心能力拆解（2025-2026 更新）

#### BlackLine（全球市场领导者 | Gartner 4.7/5 | 年费 $77K-$340K）

- **2025-2026 重大更新：** 收购 WiseLayer（2025.12）扩展 Agentic AI；推出 Verity AI 平台（Verity Match、Verity Prepare）；Journals Risk Analyzer 做 ML 异常检测
- **对账引擎：** 规则驱动 + ML 置信度评分，日处理 2 亿+ 交易；**未使用 LLM 做语义匹配**
- **Agentic AI：** WiseLayer 专项 Agent（Angela 做应计/收入、Payton 做薪酬）；Verity Prepare 自动编写对账说明
- **预测分析：** 集团内部预测指导 + AR 付款预测
- **不足：** 无 LLM 语义匹配；无自然语言查询；无中国市场适配；价格昂贵；实施 3-6 月
- **借鉴点：** 工作流引擎设计、审计追踪完整度、多实体管理架构、SOX 合规控制

#### Trintech Cadency（企业级对账专业厂商 | Gartner 4.4/5 | 年费 $60K+）

- **2025-2026 重大更新：** 平台级 Agentic AI 嵌入所有模块（Match、Balance、Journal）；95% 异常处理时间缩减
- **对账引擎：** 智能规则 + AI 多向匹配（1:1/1:N/N:N），匹配率 99%+；日处理数百万笔交易
- **AI 异常检测：** ML 预测异常，主动路由到引导工作流
- **不足：** 无 LLM 语义匹配；无自然语言查询；部署复杂（4-8 月实施）
- **借鉴点：** 风险评分矩阵、自动认证流程、高吞吐交易匹配

#### AutoRek ARIA（金融服务业专业厂商 | 2025 年推出 AI Agent）

- **2025-2026 重大更新：** 推出 ARIA（多技能 AI Agent），动态学习对账模式；自动规则生成（快 90-95%）
- **对账引擎：** 匹配率 99.99%；智能异常管理 + 升级协议；专注资本市场（T+1 结算）、支付（FCA 监管）、保险（56 天结算期）
- **技术架构：** 基于 Microsoft Azure；30 年金融对账数据积累
- **不足：** 仅覆盖金融服务细分市场；无中国市场
- **借鉴点：** 规则自动生成、异常升级协议、监管合规深度

#### HighRadius（AI-Native 记录到报告 | 2026 Gartner MQ Challenger 首次入选）

- **2025-2026：** 自主 AI Agent 用于银行对账、收入对账、集团内部管理；90%+ 自动匹配，99% 准确率
- **差异化：** 自学习 Agent 从历史数据自动发现匹配规则；实时异常监控；30% 关账天数缩减
- **不足：** 无 LLM 语义匹配；无中国市场适配
- **借鉴点：** 自学习规则发现、触摸式执行、实时监控仪表盘

#### Digits（AI 会计 Agent | 2025.11 推出 AI 银行对账）

- **2025-2026：** 24/7 运行的 AI Agent：银行对账单采集+对账、交易分类、薪酬记账、工作底稿管理、方差分析
- **技术架构差异化：** **预测模型做数学（不能幻觉），LLM 仅做 Agent 编排和结果沟通**。18 个定制模型。基准测试比 GPT-4o 分类准确率高 54%。LLM 在财务分类上准确率天花板约 70%，Digits 达 mid-90%
- **自然语言：** "Ask Digits" — 自然语言发起对账、查询财务数据
- **处理速度：** 40ms/笔交易
- **不足：** SMB 定位；无企业级多实体/多币种；无中国市场
- **借鉴点：** 预测模型 vs LLM 的架构分离、40ms 级处理速度、自然语言查询

#### JustPerform / insightsoftware（Isaac AI Agent | 2025 年推出）

- **2025-2026：** Isaac AI Agent 自主完成 95% 对账任务；置信度评分（1-3 级）；无需规则配置即交付完整对账结果
- **不足：** 新产品（2025 推出），验证案例有限；无中国市场
- **借鉴点：** 零配置对账、置信度评分体系

#### Simetrik（支付/电商对账专业 | 拉美市场领导者）

- **2025-2026：** 99% 流程自动化，94% 手工任务消除；无代码连接器；AI 建议字段映射；多向交易匹配+自动外汇处理
- **三方支付：** 覆盖支付处理器、卡网络、银行合作伙伴
- **案例：** Monnet 消除每日 22 人时，SLA 缩减 86%
- **不足：** 拉美市场为主；无中国支付渠道（微信/支付宝）
- **借鉴点：** 无代码连接器、AI 字段映射建议、支付生态覆盖

#### Xelix（AP 对账 AI | Insight Partners 投资）

- **2025-2026：** AI 发票异常检测（重复发票、输入错误、可疑模式）；训练数据覆盖 7 年 + $200B+ 年发票流
- **LLM 应用：** Vendor Helpdesk 模块 — LLM 驱动的供应商沟通（对账单审核、缺失发票跟进、信用识别）
- **案例：** 客户即发现 $8-9M 重复付款；客户含 AstraZeneca、GSK、Virgin Atlantic
- **借鉴点：** LLM 在供应商沟通中的应用、异常检测的训练数据规模

#### Microsoft Finance Agents（2025.10 GA | Copilot Studio）

- **2025-2026：** 财务对账 Agent 后台自主运行，Teams/邮件通知；方差分析 Agent 自动创建评论；可在 Copilot Studio 构建自定义 Agent
- **不足：** 依赖 Microsoft 生态（Dynamics 365/Power Platform）；非独立对账产品
- **借鉴点：** 后台自主运行模式、多 Agent 协作、自然语言配置

### 2.4 2025-2026 AI 对账竞争格局总结

#### AI 能力成熟度对比

| AI 能力 | 传统厂商 (2024前) | AI-Native 厂商 (2025-2026) | 本产品定位 |
|---------|-----------------|--------------------------|-----------|
| **规则引擎匹配** | ✅ 普遍成熟 | ✅ | ✅ |
| **ML 自动匹配 (95%+)** | 部分 (BlackLine/Trintech) | ✅ 标配 | ✅ |
| **AI 异常检测** | 部分 (BlackLine/Trintech) | ✅ 标配 | ✅ |
| **Agentic AI** | 起步 (BlackLine/Trintech) | ✅ 核心卖点 | ✅ |
| **预测分析** | 部分 | ✅ (Digits/HighRadius) | ✅ |
| **自然语言查询** | ❌ 全无 | 仅 Digits "Ask Digits" | ✅ **核心差异** |
| **LLM 语义匹配** | ❌ 全无 | ❌ **全无** | ✅ **核心差异** |
| **智能根因分析 (CoT)** | ❌ 全无 | ❌ **全无** | ✅ **核心差异** |
| **自然语言规则生成** | ❌ 全无 | ❌ **全无** | ✅ **核心差异** |
| **中国市场深度适配** | ❌ 全无 | ❌ **全无** | ✅ **核心壁垒** |

#### 行业最佳实践共识

从 Deloitte、Forrester、ISG、Gartner 的 2025-2026 报告中提取的关键共识：

1. **持续对账替代批量关账：** 不再月末集中赶工，日常/实时对账成为标准
2. **95%+ 自动匹配率已达可实现水平：** 差异化从匹配率转向异常处理智能度
3. **人机协同 (Human-in-the-loop)：** AI 做匹配和推荐，人做审核和决策。AI Agent 承担 95% 常规工作
4. **Crawl-Walk-Run 实施路径：** 先银行对账 → 再跨系统 → 最后智能分析，逐步扩展
5. **GenAI 需要护栏：** 成功案例将 LLM 用于解释生成和自然语言接口，而非核心计算

#### 本产品的差异化定位

```
                        AI 深度 →
                  规则自动化    预测模型/ML    LLM 语义理解
              ┌────────────┬─────────────┬─────────────┐
        全球化 │  传统厂商   │ AI-Native   │             │
              │ (SAP/Oracle │ (Digits/    │  ★ 本产品   │
              │  /用友/金蝶) │ HighRadius/ │  智能AI     │
              ├─────────────┤ JustPerform)│  对账平台   │
        中国化 │  国内厂商   │             │             │
              │ (浪潮/元年/  │    🟢 蓝海   │   🟢 蓝海   │
              │  鼎捷/远光)  │             │             │
              └─────────────┴─────────────┴─────────────┘
```

> **一句话定位：** 在对账领域，全球首次将 LLM 语义理解引入匹配引擎 + 中国首个全场景 AI 对账平台。差异化窗口期 12-18 个月。

#### 国内厂商全景

中国对账软件市场 2024 年规模占亚太区 **28.9%**，预计 2032 年达 **$4.27 亿**，CAGR 13.5%。2025 年，国内主流厂商正集体向 AI Agent 方向转型。

| 厂商 | 核心产品 | 目标市场 | AI 对账能力亮点 | 局限性 |
|------|---------|---------|----------------|--------|
| **用友** | BIP 收入云 8.0 + 银账通 | 大型企业/集团 | 逐笔级 AI 对账；全渠道数据聚合（天猫/京东/抖音 + 2500+ 银行）；差异滚动递延；自动凭证生成；错误率从 3-5% 降到 0.1% 以下 | 生态绑定用友体系；国际化能力弱 |
| **金蝶** | 云星空·对账中心 | 中大型企业 | 内部交易对账；1:1/1:N/N:M 匹配；RPA 对账机器人；银企云直联；关联交易自动抵销 | 偏 ERP 模块化（非独立产品）；AI 深度不足 |
| **浪潮** | GS Cloud + 司库云 | 大型央企/集团 | 40+ AI 财务 Agent；OCR+RPA+大模型驱动自动对账；100M+ 年交易处理能力 | 政务/央企绑定较深；市场化程度待验证 |
| **元年** | E7 智能财务共享 + C1 合并报表 | 大型企业（500+） | AI 认领核销池；方舟 GPT（DeepSeek/Qwen/GLM/ERNIE）；3 单匹配+容差控制；99.9% 数据准确率 | 定制化程度高；标准化产品化不足 |
| **鼎捷** | T100 / E10 | 中大型制造企业 | PO-发票-付款 3 单匹配；银企直联自动对账；应收应付自动核销 | 制造业垂直定位；对账非核心卖点 |
| **远光** | 内部交易 + 供应链协同 + AI 结算 Agent（2025） | 电力/能源行业 | 电网-电厂购电结算对账（行业特化）；RPA 银行对账（1 分钟内完成）；2025 上线大模型结算 Agent | 电力行业定制；通用性差 |

> **关键判断：** 国内厂商的对账能力在"规则自动化"层面已相当成熟（银企直联、RPA、多维度匹配），部分厂商（用友、浪潮、元年）已开始布局 AI Agent。但**所有国内厂商的 AI 能力均停留在规则推荐和 RPA 自动化层面，尚未进入 LLM 语义理解、自然语言交互、智能根因分析的深水区**。这意味着本产品在国内市场的差异化窗口期约为 12-18 个月。

### 2.3 市场空白与本产品机会

```
                          AI 能力 →
                    低              高
              ┌─────────────────────────┐
        全球化 │  BlackLine          │  ★ 本产品     │
              │  Oracle ARCS        │  智能AI对账平台 │
              │  SAP RC             │               │
              ├─────────────────────┤               │
        本地化 │  用友 NCC           │               │
              │  金蝶云星空          │               │
              └─────────────────────────┘
```

**空白机会（按竞争壁垒排序）：**

| 机会 | 当前状态 | 差异化窗口期 | 技术壁垒 |
|------|---------|------------|---------|
| **LLM 语义匹配** | 所有厂商仅停留在规则/阈值匹配 | 18-24 个月 | Embedding + LLM 多维度打分 |
| **智能根因分析** | 无厂商做到自动归因（汇率/手续费/时差/人为错误） | 24+ 个月 | LLM Chain-of-Thought |
| **自然语言对账** | 无厂商支持 NL-to-SQL 对账查询 | 12-18 个月 | Text-to-SQL + RAG |
| **三方支付对账** | 用友已起步（微信/支付宝），国际厂商空白 | 6-12 个月 | 支付 API 适配层 |
| **跨系统智能映射** | 所有厂商依赖手工字段映射 | 12-18 个月 | LLM 语义理解 |
| **自然语言规则生成** | 所有厂商依赖可视化/代码配置 | 18-24 个月 | LLM + 约束解码 |
| **异常趋势预警** | 用友/浪潮有基础告警；无智能预测 | 12-18 个月 | 时序模型 + LLM 解释 |

> **核心洞察：** 国内厂商（用友、浪潮、元年）已从"无 AI"进入"规则 AI"阶段，但尚未跨越"语义 AI"鸿沟。本产品的定位不是"比用友多做一点 AI"，而是**在对账领域完成从"规则匹配"到"语义理解"的范式跃迁**。时间窗口 12-18 个月。

---

## 三、用户角色与核心场景

### 3.1 用户角色

| 角色 | 职责 | 核心关注 |
|------|------|----------|
| **出纳/会计** | 日常对账执行者 | 效率、准确度、减少手工操作 |
| **财务主管** | 审核、异常处理决策 | 差异可视化、风险提示、审批效率 |
| **财务总监/CFO** | 整体风险把控 | 对账健康度仪表盘、合规性、结账进度 |
| **IT/系统管理员** | 系统对接与维护 | 数据源配置、规则配置、权限管理 |
| **审计师（外部）** | 审计验证 | 审计追踪、数据完整性、可追溯性 |

### 3.2 核心业务场景

```
场景一：银行对账（月度/日频）
  企业 ERP 银行日记账 ↔ 银行对账单
  渠道：银企直联 API / 网银下载文件 / SWIFT MT940

场景二：三方支付对账（日频）
  业务系统交易流水 ↔ 微信/支付宝/PayPal 结算单
  渠道：支付平台 API / 结算文件

场景三：应收应付对账（月频/季频）
  我方账套数据 ↔ 客户/供应商确认数据
  渠道：邮件/EDI/供应商门户

场景四：跨系统内部对账（日频/实时）
  ERP 总账 ↔ 业务系统（OMS/WMS/CRM）子账
  渠道：数据库直连 / API

场景五：月末结账多维度核对（月频）
  总账 ↔ 明细账 ↔ 辅助账 ↔ 业务台账
  渠道：ERP 数据导出 / 数据仓库

场景六：集团内部往来对账（月频）
  母公司 ↔ 子公司 A ↔ 子公司 B 的关联交易核对
  渠道：各实体 ERP 系统
```

### 3.3 用户旅程

```
┌─────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ 连接     │───▶│ 配置      │───▶│ 自动      │───▶│ 审核      │───▶│ 处理      │
│ 数据源   │    │ 对账规则   │    │ 执行对账   │    │ 差异结果   │    │ 差异      │
└─────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
  1 小时          30 分钟          5 分钟         15 分钟         10 分钟
  (传统: 2h)     (传统: 2h)      (传统: 4h)     (传统: 4h)     (传统: 2h)

                        结账周期：传统 14 小时 → AI 对账 2 小时
```

---

## 四、功能需求

### 4.1 功能全景图

```
智能 AI 对账平台
├── 1. 数据源管理
│   ├── 1.1 多源连接器
│   ├── 1.2 智能字段映射
│   ├── 1.3 数据预览与清洗
│   └── 1.4 定时同步策略
├── 2. 对账规则引擎
│   ├── 2.1 预置规则模板
│   ├── 2.2 可视化规则编排
│   ├── 2.3 自然语言规则生成（AI）
│   └── 2.4 规则推荐与优化（AI）
├── 2.5 自定义对账（新增）
│   ├── 2.5.1 自定义对账方案定义
│   ├── 2.5.2 多数据源组合配置
│   ├── 2.5.3 规则绑定与匹配层选择
│   ├── 2.5.4 方案预检与一键执行
│   └── 2.5.5 执行结果跳转审核
├── 3. 智能匹配引擎
│   ├── 3.1 精确匹配（金额+日期+流水号）
│   ├── 3.2 模糊匹配（AI 语义匹配）
│   ├── 3.3 一对多/多对一拆单匹配
│   └── 3.4 匹配置信度评分
├── 4. 差异管理中心
│   ├── 4.1 差异自动分类（AI）
│   ├── 4.2 根因分析（AI）
│   ├── 4.3 差异处理建议（AI）
│   └── 4.4 差异处理工作流
├── 5. 对账工作台
│   ├── 5.1 对账任务调度
│   ├── 5.2 实时对账进度
│   ├── 5.3 批量处理操作
│   └── 5.4 手工调整与冲销
├── 6. 智能分析
│   ├── 6.1 对账健康度仪表盘
│   ├── 6.2 异常趋势预警（AI）
│   ├── 6.3 自然语言查询（AI）
│   └── 6.4 对账报告自动生成（AI）
├── 7. 审批与工作流
│   ├── 7.1 可配置审批流程
│   ├── 7.2 任务分配与提醒
│   ├── 7.3 审批意见记录
│   └── 7.4 SLA 监控
├── 8. 系统管理
│   ├── 8.1 多组织/多账套
│   ├── 8.2 角色权限（RBAC）
│   ├── 8.3 审计日志（不可篡改）
│   ├── 8.4 国际化（多币种/多语言/多时区）
│   └── 8.5 大模型配置（国内 LLM 接入）
└── 9. 开放平台
    ├── 9.1 RESTful API
    ├── 9.2 Webhook 事件推送
    ├── 9.3 自定义插件机制
    └── 9.4 标准数据交换格式
```

### 4.2 详细功能规格

---

#### 模块 1：数据源管理

##### 1.1 多源连接器

**支持的数据源类型：**

| 类别 | 具体来源 | 对接方式 |
|------|---------|----------|
| **银行** | 工商银行、建设银行、农业银行、中国银行、招商银行等 50+ 国内银行 | 银企直联 API / SFTP 文件 / SWIFT MT940/MT942 |
| **国际银行** | HSBC、Citi、JPMorgan、Deutsche Bank、DBS 等 | SWIFT / ISO 20022 / API |
| **三方支付** | 微信支付、支付宝、PayPal、Stripe、Square、Adyen | REST API / 结算文件(CSV/Excel) |
| **ERP 系统** | SAP S/4HANA、Oracle EBS/Netsuite、用友 NCC/U8/T+、金蝶云星空/精斗云、Microsoft Dynamics 365 | 数据库直连 / API / Excel 导出 |
| **业务系统** | OMS、WMS、POS、电商平台（淘宝/京东/Amazon/Shopify） | API / 中间表 |
| **文件导入** | Excel、CSV、XML、JSON、OFX/QFX、PDF（银行对账单扫描件） | 上传 / SFTP / 邮件附件自动采集 |

**功能要点：**
- 连接器热插拔架构：新增数据源无需升级主系统
- 连接测试与健康监控：连接失败自动告警
- 数据源凭据加密存储（AES-256）
- 增量/全量同步策略可配置

##### 1.2 智能字段映射（AI 驱动）

这是本产品的核心差异化能力之一。

**传统方式痛点：** 不同来源的字段命名千差万别 —— "交易金额" vs "Transaction Amount" vs "TXN_AMT" vs "金额(元)" —— 手工映射耗时且易错。

**AI 方案：**

```
输入：源字段列表 + 目标字段列表

┌─────────────────────────────────────────────────┐
│ AI 字段语义映射引擎                              │
│                                                 │
│ 源字段: "TXN_AMT"                               │
│   ↓ 语义理解（LLM）                              │
│   → "这是一个交易金额字段"                        │
│   → 字段类型推断: Decimal(18,2)                  │
│   → 建议映射: "交易金额" (置信度: 98%)            │
│   → 数据格式识别: "1000.00" → 有小数点, 2 位小数  │
│                                                 │
│ 源字段: "VALUE_DATE"                            │
│   ↓ 语义理解（LLM）                              │
│   → "这是一个起息日/入账日期字段"                  │
│   → 建议映射: "入账日期" (置信度: 95%)            │
│   → 日期格式识别: "20240115" → yyyyMMdd          │
└─────────────────────────────────────────────────┘
```

**功能要点：**
- LLM 语义分析自动识别字段含义
- 支持 20+ 语言字段名映射
- 字段格式自动识别与转换规则推荐
- 人工确认/修正界面（一键接受所有推荐）
- 映射方案保存为模板，同类数据源复用

##### 1.3 数据预览与清洗

- 数据源连接后即时预览（前 100 行）
- 自动数据质量检查：
  - 必填字段缺失率
  - 金额字段格式异常
  - 日期范围异常
  - 重复行检测
  - 金额汇总与源系统校验
- 一键数据清洗：
  - 去除空白行/特殊字符
  - 金额格式化（"1,000.00" → 1000.00）
  - 日期标准化
  - 负号/借貸方向统一

##### 1.4 定时同步策略

- Cron 表达式调度
- 事件驱动同步（接收到新文件 / Webhook 触发）
- 同步失败自动重试 + 告警
- 同步历史与耗时监控

---

#### 模块 2：对账规则引擎

##### 2.1 预置规则模板

| 规则模板 | 适用场景 | 匹配逻辑 |
|----------|---------|----------|
| 银行对账-标准 | 银行流水 vs ERP 日记账 | 金额+日期(±1天)+摘要模糊匹配 |
| 银行对账-严格 | 高风险账户 | 金额+日期+流水号精确匹配 |
| 三方支付对账 | 支付流水 vs 结算单 | 金额+手续费拆解+订单号匹配 |
| 应收对账 | 我方应收 vs 客户确认 | 发票号+金额+客户名称 |
| 应付对账 | 供应商账单 vs 我方采购 | PO号+发票号+金额 |
| 跨系统核对 | 总账 vs 子账 | 科目+期间+金额 |
| 集团内部往来 | 关联交易双方 | 交易编号+金额+方向 |

##### 2.2 可视化规则编排

- 拖拽式规则构建器（类似决策表编辑器）
- 匹配条件组合：AND/OR/NOT 逻辑
- 支持的条件类型：
  - 精确匹配 / 范围匹配 / 包含匹配 / 正则匹配
  - 金额容差（绝对值/百分比）
  - 日期偏移（±N 天/工作日）
  - 金额汇总匹配（一对多）
- 规则优先级排序
- 规则测试沙箱：使用历史数据验证规则效果

##### 2.3 自然语言规则生成（AI 驱动）

**传统方式痛点：** 财务人员无法直接配置规则，必须依赖 IT 人员翻译。

**AI 方案：**

```
用户输入（自然语言）：
"把金额相差不超过5块钱，日期在前后2个工作日内，
且摘要里有相同供应商名称的记录自动匹配上。
如果有手续费差异，单独标记为'手续费差异'。"

  ↓ LLM 解析 + 规则生成

生成的规则（结构化）：
{
  "name": "供应商付款对账-含手续费容差",
  "conditions": [
    { "field": "amount_diff_abs", "operator": "lte", "value": 5 },
    { "field": "date_diff_business_days", "operator": "lte", "value": 2 },
    { "field": "supplier_name_similarity", "operator": "gte", "value": 0.8 }
  ],
  "exceptions": [
    { "condition": "fee_identified", "tag": "手续费差异" }
  ]
}
```

**功能要点：**
- 自然语言输入 → 结构化规则输出
- LLM 转译过程可视化（用户可审查每一步）
- 规则冲突检测（新规则与已有规则是否有逻辑冲突）
- 规则有效性模拟（AI 预测新规则的匹配率和误匹配率）

##### 2.4 规则推荐与优化（AI 驱动）

- 基于历史对账结果，AI 推荐：
  - "这类未匹配记录如果将日期容差从 1 天放宽到 2 天，可自动匹配 87%"
  - "摘要中包含品牌名的记录，建议增加供应商名称匹配规则"
- 规则效果持续监控 → 建议优化/废弃低效规则

---

#### 模块 2.5：自定义对账（新增）

面向「非标准场景」与「多源组合对账」需求，用户可自行组合数据来源与匹配规则，保存为可复用方案并一键执行，无需依赖固定任务模板。

##### 2.5.1 自定义对账方案定义

| 字段 | 说明 |
|------|------|
| 方案名称 / 编码 | 组织内唯一编码，便于复用与审计 |
| 期间类型 | 日 / 月 / 自定义期间 |
| 默认期间 | 如 `2026-07`，执行时可覆盖 |
| 状态 | 草稿 / 启用 / 停用 |
| 描述 | 业务说明 |

##### 2.5.2 多数据源组合配置

- **主数据源 A**：一条（通常为 ERP / 本方账）
- **对账方 B**：可多选，支持同时对多个来源
- **数据源类型不限于**：银行 API、HTTP 接口、三方支付、ERP、文件导入、数据库直连、手工录入等
- 多 B 源场景：系统为每个 B 源创建独立 `CUSTOM` 类型对账任务（A vs Bᵢ），统一归属本方案

##### 2.5.3 规则绑定与匹配层选择

- 可勾选本方案专用规则 ID 列表；不选则使用组织下全部启用规则
- 匹配引擎按任务 `ruleIds` **精确过滤**，避免「自定义」仍套用全部组织规则
- 可配置启用层：精确匹配 / 规则匹配 / AI 语义 / 拆单匹配

##### 2.5.4 方案预检与一键执行

**预检内容：**
- 数据源是否存在且启用
- A/B 是否冲突（同一源不能同时作 A 与 B）
- 待对账 `PENDING` 记录数量提示
- 所选规则是否存在/启用

**执行：**
- 支持同步 / 异步
- 可覆盖期间、临时规则、临时 B 源列表
- 记录 `last_run_task_id` / `last_run_at`，草稿方案首次执行后自动启用

##### 2.5.5 向导式配置与结果跳转

四步向导：**基本信息 → 选择数据源 → 配置规则 → 确认保存**
执行后跳转匹配审核页，差异进入差异管理中心，复用现有审核与处理链路。

##### 2.5.6 自然语言创建方案（AI 驱动）

用户无需手动填写四步向导，可直接用自然语言描述对账需求，AI 自动解析并生成方案配置：

| 能力 | 说明 |
|------|------|
| 自然语言输入 | 例如：「对账工商银行流水和SAP系统数据，按金额精确匹配，日期允许1天差异」 |
| AI 解析 | 调用 LLM 将自然语言转化为结构化方案（名称、A/B 源、规则、期间、匹配层） |
| 名称→ID 解析 | 后端将 AI 返回的数据源/规则名称，通过模糊匹配映射到数据库实际 ID |
| 预填向导 | 解析结果通过四步向导展示，用户可确认或修改后保存 |
| 未匹配提示 | 无法匹配的数据源/规则名称显式警告，引导用户手动选择 |

**处理流程：**
```
用户输入自然语言 → POST /nl-parse → AI 解析为方案 JSON
→ 后端名称→ID 模糊匹配 → 返回预填方案
→ sessionStorage 传递 → 跳转四步向导（表单已预填）
→ 用户确认/修改 → 保存方案
```

**API：** `POST /api/v1/custom-recon/definition/nl-parse`
- 请求：`{ "description": "...", "orgId": 1 }`
- 响应：`{ definition: { ...预填方案 }, unresolvedSources: [], unresolvedRules: [], aiExplanation: "..." }`

**模糊匹配策略（3 步 fallback）：**
1. 精确匹配（忽略大小写和空格）
2. 子串包含匹配
3. 中文关键词匹配（至少 2 个关键词命中）

**API 前缀：** `/api/v1/custom-recon/definition`（分页 / CRUD / 启用停用 / validate / run）

---

#### 模块 3：智能匹配引擎

##### 3.1 分层匹配架构

```
                    第 1 层：精确匹配
        金额 = 金额 AND 流水号 = 流水号 AND 日期 = 日期
                    匹配率目标: 60-70%
                         ↓ 未匹配
                    第 2 层：规则匹配
        金额容差 ≤ 阈值 AND 日期偏移 ≤ N天 AND 摘要相似度 ≥ 80%
                    匹配率目标: 15-25%
                         ↓ 未匹配
                    第 3 层：AI 语义匹配
        LLM 理解交易语义 + 向量相似度 + 上下文推理
                    匹配率目标: 5-10%
                         ↓ 未匹配
                    第 4 层：差异管理
                自动分类 + 根因分析 + 处理建议
```

##### 3.2 AI 语义匹配详解

这是本产品的核心技术壁垒。

**传统匹配失败的原因：**
- 同一笔交易的描述文本完全不同：ERP 记"采购付款-甲公司 2024Q1"，银行显示"跨行转账 甲科技有限公司 CN20240115-005"
- 一笔对多笔的拆单场景：ERP 一次付款 100 万，银行分 3 笔（50万+30万+20万）扣款
- 手续费拆分：交易金额 = 本金 + 手续费，两边记录金额不同
- 汇率差异：外币交易的记账汇率与实际结算汇率不同
- 时间差异：ERP 按交易日期记账，银行按清算日期（T+1/T+2）

**AI 语义匹配流程：**

```
┌─────────────────────────────────────────────────────┐
│              AI 语义匹配引擎                          │
│                                                     │
│  输入: 未匹配记录 A (ERP) + 候选记录 B1..Bn (银行)    │
│                                                     │
│  Step 1: 语义向量化                                  │
│    将交易摘要、对方户名、用途等文本用 Embedding        │
│    模型向量化 → cosine_similarity 计算语义距离        │
│                                                     │
│  Step 2: 多维度打分 (LLM)                            │
│    ┌───────────────────────────────────────┐        │
│    │ 维度           │ 权重  │ A↔B1 │ A↔B2  │        │
│    ├────────────────┼───────┼──────┼───────┤        │
│    │ 金额匹配度       │ 30%  │ 0.95 │ 0.70  │        │
│    │ 日期匹配度       │ 20%  │ 0.90 │ 0.90  │        │
│    │ 交易方语义相似度  │ 25%  │ 0.88 │ 0.40  │        │
│    │ 用途语义相似度    │ 15%  │ 0.92 │ 0.30  │        │
│    │ 流水号模糊匹配    │ 10%  │ 0.50 │ 0.60  │        │
│    │ 综合加权得分      │      │ 0.89 │ 0.60  │        │
│    └───────────────────────────────────────┘        │
│                                                     │
│  Step 3: 最佳匹配决策                                │
│    综合得分 ≥ 0.85 → 自动匹配                        │
│    综合得分 0.70-0.85 → 推荐匹配（人工确认）          │
│    综合得分 < 0.70 → 标记为差异                      │
│                                                     │
│  Step 4: 匹配解释（可解释 AI）                        │
│    "A 与 B1 匹配得分 0.89：金额相等(0.95)、            │
│     日期相差1天(0.90)、对方户名语义高度相关(0.88)..."  │
└─────────────────────────────────────────────────────┘
```

##### 3.3 一对多/多对一拆单匹配

**场景：**
- ERP 付款 10,000 元 → 银行分 6,000 + 4,000 两次扣款（跨日）
- 电商日汇总收款 50,000 元 → 对应的 300 笔订单明细

**算法：**
- 子集和问题（Subset Sum）优化：在候选记录中搜索金额组合
- AI 辅助：LLM 分析拆单原因（是否有手续费、是否跨境分笔），缩小搜索空间
- 性能：100 条候选记录内，30 秒内完成组合搜索

##### 3.4 匹配置信度评分

- 每对匹配记录附带置信度评分（0-100%）
- 匹配质量仪表盘：按置信度区间分布展示
- 低置信度匹配自动提交人工审核
- 连续低置信度的数据源自动触发规则优化建议

---

#### 模块 4：差异管理中心

##### 4.1 差异自动分类（AI 驱动）

AI 将差异自动归入以下类别，无需人工逐条判断：

| 差异类别 | 典型表现 | AI 识别依据 |
|----------|---------|------------|
| **时间差** | 金额相同但日期跨月 | 金额精确匹配 + 日期差异 + 跨月 |
| **手续费差异** | 金额差几元/几十元 | 差值在常见手续费范围内（0.1%-1%） |
| **汇率差异** | 外币交易金额不同 | 币种字段 + 差异比例接近汇率波动范围 |
| **人为录入错误** | 金额数字颠倒/错位 | 数字相似度分析（如 "1234" vs "1243"） |
| **未达账项** | 一方有记录一方无 | 单边存在 + 时近期末 |
| **重复记账** | 同金额同日期出现两次 | 完全重复检测 + 大概率是重复 |
| **对方未入账** | 仅我方有记录 | 单边 + 非期末时间点 |
| **未知差异** | 无法自动归类 | 提交人工判断并学习 |

##### 4.2 根因分析（AI 驱动）

**AI 不仅告诉你"有差异"，还告诉"为什么"：**

```
差异编号: #D20240715-0032
金额差异: ¥1,200.00

AI 根因分析结果:
┌─────────────────────────────────────────────┐
│ 🔍 差异根因: 汇率结算差                       │
│                                             │
│ 📋 分析过程:                                  │
│ 1. 该交易为USD结算 (ERP记录汇率 7.1000)       │
│ 2. 银行实际结算汇率 7.0824                    │
│ 3. 折算差异: $10,000 × (7.1000-7.0824)      │
│    = ¥176.00 (汇率差)                        │
│ 4. 另含 ¥24.00 跨境手续费                     │
│ 5. 剩余 ¥1,000.00 未匹配 → 可能是对方手续费    │
│                                             │
│ 💡 建议:                                      │
│ • 将 ¥176.00 计入"汇兑损益"科目               │
│ • 将 ¥24.00 计入"手续费"科目                  │
│ • ¥1,000.00 联系对方银行确认                  │
│                                             │
│ ⚠️ 风险等级: 🟡 中等 (涉及外币, 需财务主管审核)  │
└─────────────────────────────────────────────┘
```

##### 4.3 差异处理建议（AI 驱动）

- 基于差异类别 + 历史处理记录，AI 给出处理方案
- 常见差异一键生成调整分录
- 调整分录可预览 → 确认 → 自动写入 ERP
- AI 学习用户处理模式，建议越来越精准

##### 4.4 差异处理工作流

- 差异分配：指定处理人 / 自动按规则分配
- 处理状态：待处理 → 处理中 → 待审核 → 已完成 → 已关闭
- 处理时限：SLA 配置 + 超时自动升级
- 批量处理：同类差异可一键批量操作
- 处理记录完整留痕（操作人、时间、处理方式、调整分录）

---

#### 模块 5：对账工作台

##### 5.1 对账任务调度

- 任务类型：日对账（银行/支付）、周对账（库存）、月对账（总账/往来）
- 依赖关系：子账对账 → 总账对账（前序任务未完成，后续任务自动等待）
- 对账日历视图：展示本月所有对账任务及状态
- 月末结账倒计时 + 完成度进度条

##### 5.2 实时对账进度

- 大型对账任务（百万级记录）实时进度展示
- 匹配率实时统计
- 吞吐量监控（条/秒）
- 预计完成时间

##### 5.3 批量处理操作

- 批量确认匹配（一键确认所有 ≥95% 置信度的匹配）
- 批量标记差异类别
- 批量导出差异清单（Excel/PDF）
- 批量生成调整凭证

##### 5.4 手工调整与冲销

- 手动创建匹配关系（拖拽方式）
- 手工差异调整分录录入
- 冲销凭证生成与关联
- 调整记录自动纳入 AI 训练数据

---

#### 模块 6：智能分析

##### 6.1 对账健康度仪表盘

```
┌────────────────────────────────────────────────┐
│  📊 对账健康度仪表盘                  2024年7月  │
│                                                │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐       │
│  │ 自动匹配率 │ │ 差异解决率 │ │ 平均结账  │       │
│  │  92.5%   │ │  97.3%   │ │  1.8 天  │       │
│  │  ↑ 3.2%  │ │  ↑ 1.1%  │ │  ↓ 0.5天 │       │
│  └──────────┘ └──────────┘ └──────────┘       │
│                                                │
│  差异趋势图（近12个月）▁▂▃▂▁▅▃▂▁▂▁▂             │
│  差异分类占比饼图                                │
│  各账户/实体对账健康度雷达图                       │
│  Top 10 差异金额排行                            │
│  月末结账进度甘特图                              │
└────────────────────────────────────────────────┘
```

##### 6.2 异常趋势预警（AI 驱动）

- 基于时间序列分析，检测异常模式：
  - 某账户差异率突然上升（环比/同比）
  - 某业务线重复差异频繁出现
  - 某供应商对账延迟率持续恶化
  - 月末差异集中爆发预警
- 告警渠道：系统内通知 / 邮件 / 企业微信/钉钉/Slack

##### 6.3 自然语言查询（AI 驱动）

用户可以用自然语言直接与数据对话：

```
用户: "上个月建设银行对账差异最大的5笔是什么原因？"

AI: "2024年6月建行对账共有23笔差异，金额最大的5笔：
1. ¥128,500 - 供应商'华东科技'付款延迟（银行端6/3, ERP端6/5）
2. ¥86,200 - 跨境汇款汇率差异（合同汇率 vs 结算汇率）
3. ¥52,000 - 手续费分摊差异
4. ¥31,500 - 对方账户信息变更导致退款重付
5. ¥18,300 - 未达账项（7/2已到账，属时间差）
需要我详细分析其中任何一笔吗？"

用户: "对比一下今年Q1和Q2的对账效率"

AI: "Q1 vs Q2 对账效率对比：
• 自动匹配率: 89.3% → 92.5% (↑3.2pp)
• 平均结账天数: 2.3天 → 1.8天 (↓0.5天)
• 差异处理平均时长: 1.5天 → 0.8天 (↓0.7天)
• 人工干预比例: 18% → 11% (↓7pp)
其中银行对账改善最明显，已实现95%+自动匹配。
建议关注：支付宝对账自动匹配率偏低(78%)，需要优化匹配规则。"
```

##### 6.4 对账报告自动生成（AI 驱动）

- 周期报告：
  - 每日对账简报（自动推送）
  - 月度对账报告（含差异明细和趋势分析）
  - 季度对账分析报告（含效率统计和改进建议）
- 报告内容 AI 自动撰写（文字分析 + 数据图表）
- 报告模板可定制（企业品牌/格式）
- 多格式导出：PDF、Excel、在线链接

---

#### 模块 7：审批与工作流

##### 7.1 可配置审批流程

- 可视化流程设计器（BPMN 风格）
- 审批节点类型：会签、或签、条件分支、自动审批
- 审批条件：按金额阈值、差异类型、账户类型等动态路由
- 审批超时自动升级/转交

##### 7.2 任务分配与提醒

- 自动分配规则（按账户/实体/业务线）
- 待办事项列表（支持筛选/排序/批量操作）
- 多渠道提醒：系统通知 + 邮件 + IM（企微/钉钉/飞书）
- 提醒策略：每日汇总 / 实时通知 / 截止前催办

##### 7.3 审批意见记录

- 结构化审批意见（同意/拒绝/退回修改 + 备注）
- 调整分录附件
- 审批历史时间线

##### 7.4 SLA 监控

- 对账完成 SLA、差异处理 SLA、审批 SLA 三级监控
- 超时预警（黄/橙/红三级）
- SLA 达成率统计报表

---

#### 模块 8：系统管理

##### 8.1 多组织/多账套

- 集团-子公司-部门三级组织架构
- 多账套管理（不同会计准则/币种）
- 组织间数据隔离 + 集团视角汇总

##### 8.2 角色权限（RBAC）

- 预置角色：超级管理员、财务总监、财务主管、会计、审计师（只读）
- 自定义角色：功能级 + 数据级权限
- 敏感操作二次确认

##### 8.3 审计日志

- 所有操作记录不可篡改（区块链存证可选）
- 日志范围：登录、数据修改、对账操作、审批操作、配置变更
- 审计查询：按时间/操作人/操作类型/对象检索
- 审计报告导出（符合 SOX/CSA 合规要求）

##### 8.4 国际化

- 多币种：160+ 币种，自动汇率换算（接入实时汇率源）
- 多语言：中文/英文/日文/繁体中文（界面 + AI 分析结果）
- 多时区：全球分支机构统一时区展示
- 多会计准则：CAS/IFRS/GAAP 差异处理

##### 8.5 大模型配置（国内 LLM 接入）

平台 AI 能力统一通过 `AIService` 抽象，支持 **OpenAI 兼容协议** 接入国内外大模型，运维可通过配置切换，无需改业务代码。

**支持的提供商：**

| 提供商 | 配置值 `ai.llm.provider` | 默认 Base URL | 典型模型 | API Key 环境变量 |
|--------|--------------------------|---------------|----------|------------------|
| 本地 Mock | `mock` | — | mock-ai-v1.0 | 无需 |
| DeepSeek | `deepseek` | `https://api.deepseek.com/v1` | deepseek-chat / deepseek-reasoner | `DEEPSEEK_API_KEY` |
| 通义千问 | `qwen` | `https://dashscope.aliyuncs.com/compatible-mode/v1` | qwen-turbo / qwen-plus / qwen-max | `DASHSCOPE_API_KEY` |
| Kimi | `kimi` | `https://api.moonshot.cn/v1` | moonshot-v1-8k / moonshot-v1-32k | `MOONSHOT_API_KEY` |
| OpenAI | `openai` | `https://api.openai.com/v1` | gpt-4o / gpt-4o-mini | `OPENAI_API_KEY` / `AI_API_KEY` |
| 自定义兼容网关 | `custom` | 自行配置 | 自行配置 | `AI_CUSTOM_API_KEY` |

**功能要点：**
- 系统管理界面「大模型配置」：查看当前提供商、模型档位、Key 是否配置、连通性测试
- 任务模型分档：`simple`（分类/映射）/ `default`（规则生成/报告）/ `reasoning`（语义匹配/根因/NL 查询）
- `provider=mock` 时使用 MockAIService；非 mock 时自动注册 `productionAIService`（LlmAIService）
- 支持私有化 / 中转网关：`custom` + `AI_CUSTOM_BASE_URL`
- 修改配置后重启后端生效

**API：**
- `GET /api/v1/ai/config` — 当前配置状态
- `GET /api/v1/ai/providers` — 支持的提供商列表
- `POST /api/v1/ai/test` — 连通性测试

---

#### 模块 9：开放平台

##### 9.1 RESTful API

- 完整的 REST API（对标 BlackLine/Stripe API 设计水准）
- API 版本管理（向后兼容）
- API Key + OAuth 2.0 认证
- 速率限制 + 用量分析

##### 9.2 Webhook 事件推送

- 事件类型：对账完成、差异发现、审批完成、SLA 超时
- 重试机制 + 投递状态追踪
- 支持发送到第三方系统（ERP/CRM/OA）

##### 9.3 自定义插件机制

- 插件类型：数据源连接器 / 匹配算法 / 差异处理器 / 通知渠道
- 插件市场（类似 VS Code Extension）
- SDK 与开发文档

##### 9.4 标准数据交换格式

- 支持 Accounting Data Standard (ADS)
- 支持 ISO 20022 金融信息交换标准
- 支持 XBRL GL（全球通用账簿分类标准）

---

## 五、AI 能力矩阵

### 5.0 架构原则：预测模型 vs LLM 的分层设计

在深入 AI 能力矩阵之前，一个关键的架构决策需要明确。基于对 Digits（预测模型 + LLM）、Docyt（融合架构）和传统厂商（纯规则/ML）的深入分析，**业界最佳实践已收敛到以下范式：**

```
┌─────────────────────────────────────────────────────┐
│              AI 能力分层架构                          │
│                                                     │
│  第 3 层：LLM 层（沟通 & 推理）                       │
│  ┌─────────────────────────────────────────────┐    │
│  │ • 自然语言查询/规则生成                        │    │
│  │ • 语义匹配（多维度打分 + 解释）                 │    │
│  │ • 根因分析 (Chain-of-Thought)                │    │
│  │ • 报告生成 / 处理建议解释                      │    │
│  │ ⚠️ LLM 在财务分类上准确率天花板约 70%           │    │
│  │    → 仅用于理解、解释、推理，不用于计算          │    │
│  └─────────────────────────────────────────────┘    │
│                        ↑                            │
│  第 2 层：预测模型层（计算 & 分类）                    │
│  ┌─────────────────────────────────────────────┐    │
│  │ • 金额匹配度计算 (数值比较)                     │    │
│  │ • 差异分类 (微调模型，准确率 mid-90%)           │    │
│  │ • 异常检测 (Isolation Forest / Prophet)       │    │
│  │ • 置信度评分 (规则 + 统计)                     │    │
│  │ ✅ 数学计算 → 不能幻觉 → 预测模型/统计算法       │    │
│  └─────────────────────────────────────────────┘    │
│                        ↑                            │
│  第 1 层：规则引擎层（确定性匹配）                      │
│  ┌─────────────────────────────────────────────┐    │
│  │ • 精确匹配 (金额 + 日期 + 流水号)               │    │
│  │ • 规则匹配 (金额容差 + 日期偏移 + 正则)          │    │
│  │ • 拆单组合搜索 (Subset Sum)                   │    │
│  │ ✅ 确定性逻辑 → 零幻觉 → 传统代码实现            │    │
│  └─────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘
```

> **核心原则：** 数学计算交给预测模型/规则引擎（不能出错），语义理解和推理交给 LLM（不能计算）。这一架构在 Digits 的实战中获得验证——预测模型比 GPT-4o 在财务分类上准确率高 54%。

### 5.1 AI 能力全景（含竞争对标）

| AI 能力 | 技术方案 | 应用模块 | 成熟度 | 差异化程度 | 是否有竞品实现 |
|---------|---------|---------|--------|-----------|--------------|
| **智能字段映射** | LLM 语义理解 + Embedding | 数据源管理 | ⭐⭐⭐ | 🟢 高 | Simetrik 有 AI 建议映射 |
| **自然语言规则生成** | LLM + 约束解码 | 规则引擎 | ⭐⭐⭐ | 🟢 极高 | ❌ 无竞品 |
| **LLM 语义匹配** | Embedding + LLM 多维度打分 | 匹配引擎 | ⭐⭐⭐⭐ | 🟢 极高 | ❌ 无竞品（所有厂商用 ML/规则） |
| **拆单组合匹配** | 子集和算法 + LLM 辅助 | 匹配引擎 | ⭐⭐⭐ | 🟡 中高 | 多家有 1:N 匹配（非 LLM） |
| **差异自动分类** | 微调小模型 + Few-shot LLM | 差异管理 | ⭐⭐⭐⭐ | 🟢 高 | Digits/Trintech 有 ML 分类 |
| **根因分析 (CoT)** | LLM 推理链 | 差异管理 | ⭐⭐⭐ | 🟢 极高 | ❌ 无竞品 |
| **处理建议推荐** | LLM + 历史模式学习 | 差异管理 | ⭐⭐⭐ | 🟢 高 | AutomationEdge 有 GenAI 建议 |
| **异常趋势检测** | 时序模型 + LLM 解释 | 智能分析 | ⭐⭐⭐ | 🟡 中 | 多家有 ML 异常检测 |
| **自然语言查询** | LLM + Text-to-SQL + RAG | 智能分析 | ⭐⭐⭐⭐ | 🟢 高 | 仅 Digits "Ask Digits" |
| **报告自动生成** | LLM 文本生成 + 模板 | 智能分析 | ⭐⭐⭐⭐ | 🟡 中 | 多家有基础报告 |
| **规则优化推荐** | 历史数据分析 + LLM | 规则引擎 | ⭐⭐ | 🟢 高 | AutoRek 有自动规则生成 |
| **持续学习优化** | 人工反馈 → 模型微调 | 全局 | ⭐⭐ | 🟡 中高 | Trintech/HighRadius 有自学习 |

### 5.2 AI 模型选型建议

| 场景 | 推荐模型（国内优先） | 备选 | 原因 |
|------|---------------------|------|------|
| **字段语义映射** | Qwen-Turbo / DeepSeek-Chat | GPT-4o mini | 高精度文本理解，成本可控 |
| **语义匹配打分** | 本地 Embedding (BGE-M3) + DeepSeek-Reasoner / Qwen-Max | Claude Sonnet | Embedding 粗排，LLM 精排 |
| **自然语言规则解析** | Qwen-Plus / DeepSeek-Chat | Claude Sonnet / GPT-4o | 需要严格的结构化输出 |
| **根因分析 (CoT)** | DeepSeek-Reasoner / Qwen-Max / Kimi-32k | Claude Opus / GPT-4o | 需要深度推理链 |
| **自然语言查询** | Qwen-Plus / DeepSeek-Chat | Claude Sonnet + Text-to-SQL | 平衡准确性与延迟 |
| **差异分类** | Qwen-Turbo / DeepSeek-Chat | 微调小模型 | 高频调用，需低成本低延迟 |
| **异常检测** | 统计模型 (Prophet/Isolation Forest) | — | 数值分析优于 LLM |
| **报告生成** | Qwen-Plus / Moonshot-v1-8k | GPT-4o mini | 结构化中文文本生成 |

> **部署说明：** 平台默认 `ai.llm.provider=mock`；生产环境推荐优先选用 DeepSeek / 通义千问 / Kimi 等国内大模型，满足数据合规与中文场景；亦可通过 `custom` 接入企业私有化 OpenAI 兼容网关。

### 5.3 AI 可靠性与安全

- **可解释性：** 所有 AI 决策附带可读的解释文本
- **人机协同：** AI 做推荐，人类做决策（Human-in-the-loop）
- **置信度阈值：** 低于阈值自动转人工
- **幻觉防控：** 金额相关输出二次校验；结构化约束输出
- **数据隐私：** 支持本地化部署 LLM，敏感数据不出企业网络
- **审计可追溯：** 所有 AI 推荐/决策记录完整日志

---

## 六、技术架构要求

### 6.1 总体架构

```
┌─────────────────────────────────────────────────────────┐
│                      前端层                              │
│  React/Next.js • 响应式 Web • 移动端适配                  │
│  仪表盘 • 工作台 • 规则编辑器 • 审批中心                    │
└───────────────────────┬─────────────────────────────────┘
                        │ REST API / WebSocket
┌───────────────────────┴─────────────────────────────────┐
│                      API 网关层                          │
│  Kong/APISIX • 认证鉴权 • 限流 • 路由 • 日志              │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────┴─────────────────────────────────┐
│                     业务服务层                            │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│  │数据源服务  │ │对账引擎   │ │差异管理   │ │工作流引擎 │  │
│  │• 连接管理 │ │• 规则执行 │ │• 差异分类 │ │• 流程编排 │  │
│  │• 字段映射 │ │• 匹配打分 │ │• 根因分析 │ │• 任务调度 │  │
│  │• 数据清洗 │ │• 拆单匹配 │ │• 处理建议 │ │• 审批管理 │  │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘  │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│  │智能分析   │ │开放平台   │ │系统管理   │ │通知服务   │  │
│  │• NL查询  │ │• REST API│ │• 多租户   │ │• 邮件    │  │
│  │• 趋势预警 │ │• Webhook │ │• RBAC    │ │• IM      │  │
│  │• 报告生成 │ │• 插件系统 │ │• 审计     │ │• 短信    │  │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘  │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────┴─────────────────────────────────┐
│                     AI 服务层                            │
│  ┌──────────────────────────────────────────────────┐  │
│  │              AI 编排引擎 (LangGraph)               │  │
│  │  ┌────────┐ ┌────────┐ ┌────────┐ ┌──────────┐  │  │
│  │  │ LLM    │ │Embedding│ │ 时序   │ │ 规则引擎  │  │  │
│  │  │ 推理   │ │ 向量化  │ │ 异常   │ │ (约束解码) │  │  │
│  │  └────────┘ └────────┘ └────────┘ └──────────┘  │  │
│  └──────────────────────────────────────────────────┘  │
│  • 模型路由 • 提示词管理 • 输出校验 • 缓存优化             │
└───────────────────────┬─────────────────────────────────┘
                        │
┌───────────────────────┴─────────────────────────────────┐
│                     数据层                               │
│  PostgreSQL (业务) • Redis (缓存) • Elasticsearch (搜索)  │
│  Milvus/Qdrant (向量库) • MinIO (文件) • ClickHouse (分析)│
│  Kafka (消息队列) • 区块链存证 (可选)                     │
└─────────────────────────────────────────────────────────┘
```

### 6.2 关键技术决策

| 决策点 | 选择 | 理由 |
|--------|------|------|
| **后端语言** | Java (Spring Boot) + Python (AI 服务) | Java 做业务核心（企业级成熟度），Python 做 AI（生态最佳） |
| **对账引擎** | 自研（Java 流式计算 + Python AI） | 市面无满足需求的现成引擎 |
| **工作流引擎** | Camunda / Temporal | 已大规模验证的开源工作流引擎 |
| **AI 编排** | LangGraph / Dify | 灵活的多步骤 AI 工作流编排 |
| **向量数据库** | Milvus (生产) / Qdrant (轻量部署) | 语义匹配场景的核心基础设施 |
| **消息队列** | Kafka | 高吞吐数据同步 + 事件驱动架构 |
| **部署方式** | Kubernetes + Helm | 支持公有云/私有云/混合部署 |

### 6.3 性能指标

| 指标 | 目标值 | 说明 |
|------|--------|------|
| **对账吞吐量** | ≥ 100万条/分钟 | 单实例处理能力 |
| **AI 匹配延迟** | ≤ 500ms/条 | 第 3 层语义匹配单条耗时 |
| **API 响应时间** | P95 ≤ 200ms | 非 AI 类 API |
| **自然语言查询** | ≤ 5 秒 | 端到端查询返回 |
| **系统可用性** | ≥ 99.9% (SaaS) | 年度宕机时间 ≤ 8.76 小时 |
| **数据一致性** | 最终一致性 ≤ 5 秒 | 跨系统数据同步延迟 |

---

## 七、数据模型设计

### 7.1 核心实体关系

```
┌──────────┐    1:N    ┌──────────┐    1:N    ┌──────────┐
│  Organization │◄────────│  Ledger   │◄────────│  Account  │
│  (组织/公司)   │         │  (账套)    │         │  (账户)    │
└──────────┘              └──────────┘              └──────────┘
                                                         │
                                                         │ 1:N
                              ┌──────────────────────────┤
                              │                          │
                              ▼                          ▼
                        ┌──────────┐              ┌──────────┐
                        │DataSource│              │ReconTask │
                        │(数据源)   │              │(对账任务)  │
                        └────┬─────┘              └────┬─────┘
                             │                         │
                             │ 1:N                     │ 1:N
                             ▼                         ▼
                        ┌──────────┐              ┌──────────┐
                        │RawRecord │              │ReconMatch│
                        │(原始记录) │              │(对账匹配)  │
                        └──────────┘              └────┬─────┘
                                                       │
                              ┌─────────────┬──────────┤
                              │             │          │
                              ▼             ▼          ▼
                        ┌──────────┐ ┌──────────┐ ┌──────────┐
                        │ Matched  │ │Unmatched │ │Adjustment│
                        │ (已匹配)  │ │ (差异)    │ │ (调整分录)│
                        └──────────┘ └────┬─────┘ └──────────┘
                                          │
                                          ▼
                                    ┌──────────┐
                                    │Approval  │
                                    │(审批记录) │
                                    └──────────┘
```

### 7.2 核心表结构概要

```sql
-- 对账任务
CREATE TABLE recon_task (
    id UUID PRIMARY KEY,
    org_id UUID NOT NULL,
    name VARCHAR(200),
    source_a_id UUID NOT NULL,       -- 数据源 A
    source_b_id UUID NOT NULL,       -- 数据源 B
    rule_config JSONB,               -- 规则配置
    period VARCHAR(20),              -- 对账期间 (2024-07)
    status VARCHAR(20),              -- pending/running/completed/error
    match_summary JSONB,             -- 匹配汇总统计
    started_at TIMESTAMP,
    completed_at TIMESTAMP,
    created_at TIMESTAMP DEFAULT NOW()
);

-- 对账匹配结果
CREATE TABLE recon_match (
    id UUID PRIMARY KEY,
    task_id UUID REFERENCES recon_task(id),
    record_a_id UUID,                -- 数据源 A 的记录
    record_b_id UUID,                -- 数据源 B 的记录
    match_type VARCHAR(30),          -- exact/rule/ai_semantic/ai_split/manual
    confidence DECIMAL(5,2),         -- 置信度 0.00-100.00
    match_dimensions JSONB,          -- 各维度打分详情
    ai_explanation TEXT,             -- AI 匹配解释
    status VARCHAR(20),              -- auto_confirmed/pending_review/manual_confirmed
    created_at TIMESTAMP DEFAULT NOW()
);

-- 差异记录
CREATE TABLE recon_discrepancy (
    id UUID PRIMARY KEY,
    task_id UUID REFERENCES recon_task(id),
    record_id UUID,                  -- 未匹配的记录
    side VARCHAR(10),                -- source_a / source_b
    category VARCHAR(50),            -- 差异类别 (AI分类)
    ai_root_cause TEXT,              -- AI 根因分析
    ai_suggestion JSONB,             -- AI 处理建议
    amount_diff DECIMAL(18,2),
    risk_level VARCHAR(10),          -- low/medium/high/critical
    handler_id UUID,                 -- 指定处理人
    status VARCHAR(20),              -- pending/processing/resolved/closed
    resolved_at TIMESTAMP,
    created_at TIMESTAMP DEFAULT NOW()
);

-- 数据源原始记录
CREATE TABLE raw_record (
    id UUID PRIMARY KEY,
    source_id UUID REFERENCES data_source(id),
    batch_id VARCHAR(100),
    raw_data JSONB,                  -- 原始数据
    normalized_data JSONB,           -- 标准化后数据
    amount DECIMAL(18,2),
    currency VARCHAR(3),
    transaction_date DATE,
    transaction_ref VARCHAR(500),    -- 交易参考号/流水号
    description TEXT,                -- 摘要/描述
    counter_party VARCHAR(300),      -- 对方名称
    direction VARCHAR(10),           -- debit/credit
    hash_value VARCHAR(64),          -- 数据指纹（去重用）
    created_at TIMESTAMP DEFAULT NOW()
);

-- AI 推理日志（审计用）
CREATE TABLE ai_inference_log (
    id UUID PRIMARY KEY,
    module VARCHAR(50),              -- field_mapping/semantic_match/root_cause/...
    input_data JSONB,
    output_data JSONB,
    model_used VARCHAR(100),
    tokens_used INT,
    latency_ms INT,
    confidence DECIMAL(5,2),
    user_feedback VARCHAR(20),       -- accepted/rejected/modified
    created_at TIMESTAMP DEFAULT NOW()
);
```

---

## 八、非功能性需求

### 8.1 安全性

| 要求 | 实现方式 |
|------|---------|
| 传输加密 | TLS 1.3 强制 |
| 数据加密 | AES-256 静态加密 + 字段级加密（银行账号等） |
| 认证 | OAuth 2.0 + MFA（多因素认证） |
| 授权 | RBAC + ABAC（基于属性的访问控制） |
| 数据脱敏 | 对账单敏感字段展示脱敏 |
| 渗透测试 | 每季度第三方安全审计 |
| 合规认证 | SOC 2 Type II / ISO 27001 / 等保三级 |

### 8.2 可扩展性

- 水平扩展：所有服务无状态设计，支持 K8s HPA
- 多租户：数据库级隔离（大客户）/ Schema 级隔离（中小企业）
- 插件架构：数据源连接器、匹配算法、差异处理器均可热插拔
- 国际化：i18n 框架 + 配置化

### 8.3 可靠性

- 服务容错：断路器 + 重试 + 降级
- 数据备份：每日全量 + 实时增量备份（RPO ≤ 1 分钟）
- 灾难恢复：跨 AZ 部署，RTO ≤ 30 分钟
- 消息幂等：所有数据同步操作幂等设计

### 8.4 可观测性

- 日志：结构化日志（JSON）+ ELK 集中存储
- 指标：Prometheus + Grafana（业务指标 + 技术指标）
- 追踪：分布式链路追踪（OpenTelemetry）
- 告警：分级告警 + 值班轮转

---

## 九、实施路线图

### Phase 1：MVP（3 个月）

**目标：** 验证核心价值——AI 匹配优于传统规则

```
范围：
✅ 数据源管理：Excel/CSV 导入 + 银企直联（2 家银行）
✅ 智能字段映射（AI 驱动）
✅ 对账规则引擎：预置模板 + 可视化编排
✅ 自定义对账：多数据源组合 + 规则绑定 + 预检执行
✅ 智能匹配引擎：精确匹配 + 规则匹配 + AI 语义匹配
✅ 差异管理：AI 自动分类 + 根因分析 + 处理建议
✅ 基础工作台：手工调整 + 批量操作
✅ 大模型接入：Mock + DeepSeek / 通义千问 / Kimi（OpenAI 兼容）
✅ 结果导出：Excel/PDF

不包含：
❌ 审批工作流
❌ 自然语言查询
❌ 开放 API
❌ 多组织架构
❌ 三方支付对接
```

### Phase 2：增强版（3 个月）

**目标：** 完善企业级能力，支持付费客户上线

```
新增：
✅ 审批工作流（Camunda）
✅ 自然语言查询（Text-to-SQL + RAG）
✅ 三方支付对接（微信/支付宝/PayPal）
✅ 多银行银企直联（10+ 银行）
✅ REST API v1
✅ 对账健康度仪表盘
✅ 定时调度 + 自动执行
✅ 多组织/多账套支持
```

### Phase 3：完整版（3 个月）

**目标：** 构建生态壁垒，全面超越传统厂商

```
新增：
✅ 自然语言规则生成
✅ 异常趋势预警
✅ 对账报告自动生成
✅ 插件市场 + SDK
✅ Webhook 事件推送
✅ 区块链审计存证
✅ 移动端适配
✅ 国际化（英文/日文）
✅ 30+ 银行 + 5+ 支付渠道
```

### Phase 4：智能化（持续）

**目标：** 从工具演进为智能财务助手

```
✅ 持续学习：从用户反馈中自动优化匹配模型
✅ 预判式对账：在差异发生前预测风险
✅ 跨企业对标：行业对账效率基准分析
✅ 财务大模型微调：专用领域小模型替代通用 LLM
✅ 多 Agent 协作：对账 Agent + 税务 Agent + 分析 Agent
```

---

## 十、附录：核心算法说明

### 10.1 AI 语义匹配算法

```
算法：多阶段语义匹配

输入：
  - 未匹配记录集合 U = {u₁, u₂, ..., uₙ}（来自数据源 A）
  - 候选记录集合 C = {c₁, c₂, ..., cₘ}（来自数据源 B）
  - 日期窗口 W（默认 ±7 天）
  - 金额容差 T（默认 ±1%）

输出：
  - 匹配对列表 M = {(uᵢ, cⱼ, score, explanation)}

流程：
  Stage 1: 候选筛选（倒排索引）
    对每条 uᵢ:
      1. 按日期窗口 W 筛选 → 候选集 C'
      2. 按金额容差 T 筛选 → 候选集 C''
      3. 按交易方哈希索引粗排 → Top K 候选

  Stage 2: 向量相似度粗排（Embedding）
    对每条 uᵢ 的 Top K 候选:
      1. 拼接文本: "[交易方] [摘要] [金额] [日期]"
      2. BGE-M3 → 向量 v(uᵢ), v(cⱼ)
      3. cosine_similarity(v(uᵢ), v(cⱼ)) → 排序
      4. 保留 Top 3 进入精排

  Stage 3: LLM 多维度精排
    对每条 uᵢ 的 Top 3 候选:
      Prompt:
        "你是一个财务对账专家。请评估以下两条记录是否为同一笔交易，
        从以下维度打分（0-1）：
        - 金额匹配度
        - 日期匹配度
        - 交易方名称语义相似度
        - 交易摘要语义相似度
        - 交易参考号匹配度
        
        记录 A: {uᵢ 的 JSON}
        记录 B: {cⱼ 的 JSON}
        
        返回 JSON 格式的评分和判断理由。"

      解析 LLM 返回的评分 → 加权综合得分
      Weight = [0.30, 0.20, 0.25, 0.15, 0.10]

  Stage 4: 决策
    综合得分 ≥ 0.85 → 自动匹配
    综合得分 0.70-0.85 → 推荐匹配
    综合得分 < 0.70 → 标记差异

  Stage 5: 拆单补充（可选）
    对仍未匹配的 uᵢ，尝试在 C 中搜索子集和组合：
      subset_sum(target=uᵢ.amount, candidates=C.amounts, tolerance=T)
      若有解 → 标记为"一笔对多笔"匹配
```

### 10.2 差异根因分析算法

```
算法：基于 LLM 思维链的差异根因分析

输入：
  - 差异记录 d（含源记录和目标候选）
  - 上下文：账户类型、交易历史、行业类型

流程：
  1. 特征提取：
     - 金额差异的数值特征（绝对值、百分比、是否整数）
     - 日期差异特征（日历日/工作日、是否跨月/季/年）
     - 文本相似度特征（编辑距离、语义相似度）
     - 结构性特征（币种、账户类型、交易类型）

  2. LLM 推理链 (Chain-of-Thought):
     Prompt:
     "你是一个资深财务审计师。请分析以下对账差异的根因：

     差异信息：
     - ERP记录: {json}
     - 银行记录: {json}
     - 账户类型: {account_type}
     
     请按以下步骤推理：
     Step 1: 金额差异的数值特征是什么？
     Step 2: 这些特征可能对应什么类型的差异？
     Step 3: 结合交易上下文，最可能的根因是什么？
     Step 4: 需要哪些额外信息来确认？
     Step 5: 给出处理建议。
     
     以 JSON 格式输出完整分析。"

  3. 结果校验：
     - 差异类别是否在已知类别中
     - 建议是否可操作
     - 置信度是否合理

  4. 反馈闭环：
     - 用户确认/修正 → 存入标注数据
     - 定期微调分类模型
```

### 10.3 自然语言查询执行流程

```
用户: "上个月与工商银行的差异中，金额超过1万且未解决的有多少？"

Step 1: LLM 意图理解 + 实体识别
  → intent: "统计查询"
  → entities: { bank: "工商银行", period: "上个月", amount: ">10000", status: "未解决" }

Step 2: Text-to-SQL 生成
  → SELECT COUNT(*) FROM recon_discrepancy d
    JOIN recon_task t ON d.task_id = t.id
    JOIN account a ON t.account_id = a.id
    WHERE a.bank_name = '工商银行'
      AND t.period = '2024-06'
      AND ABS(d.amount_diff) > 10000
      AND d.status IN ('pending', 'processing')

Step 3: SQL 校验与执行
  → 语法校验 → 权限校验 → 执行 → 结果: 8 笔

Step 4: LLM 结果润色
  → "2024年6月与工商银行的对账中，金额超过1万元且尚未解决的差异共 8 笔，
     合计金额 ¥156,200.00。其中金额最大的一笔为 ¥52,000.00（供应商付款延迟）。
     需要我列出这 8 笔的详细信息吗？"
```

---

## 附录 B：竞品功能对比详细表

| 功能 | BlackLine | Oracle ARCS | SAP RC | Trintech | 本产品 |
|------|-----------|-------------|--------|----------|--------|
| **部署方式** | 纯 SaaS | Cloud | On-prem/Cloud | Cloud | SaaS + 私有化 |
| **起售价** | ~$50K/年 | ~$30K/年 | ~$40K/年 | ~$60K/年 | 待定 |
| **实施周期** | 3-6 月 | 4-8 月 | 6-12 月 | 4-8 月 | 1-4 周 |
| **AI 语义匹配** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **自然语言查询** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **智能根因分析** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **三方支付对账** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **自然语言规则** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **中文支持** | 有限 | 有限 | 有限 | ❌ | ✅ 原生 |
| **中国银行适配** | ❌ | ❌ | ❌ | ❌ | ✅ |
| **字段智能映射** | ❌ | ❌ | ❌ | ❌ | ✅ |

---

> 📌 **本文档为 v1.0 版本，后续迭代方向：**
> 1. 根据实际客户验证调整 AI 功能优先级
> 2. 细化各模块的 UI/UX 交互设计
> 3. 补充性能压测基准与数据安全白皮书
> 4. 制定定价策略与 SaaS 套餐设计
>
> 🤖 Generated with [Claude Code](https://claude.com/claude-code)