# 评查点分组、文档类型与规则集目标结构与迁移方案

更新时间：2026-05-03

## 1. 产品确认后的最终口径

最终目标结构统一为：

- 一级分组 = 业务大类
  - 例如：`合同`、`卷宗`
  - 后续若出现新的入口业务，也允许继续新增一级分组
- 二级分组 = 该业务大类下的具体业务类型
  - 例如合同下：`建设工程合同`、`买卖合同`
  - 例如卷宗下：`处罚-一般程序`、`许可-停业办理`
- 规则集 = 挂在二级分组下
- 入口模块 = 绑定一级分组

补充关系口径：

- 文档类型 = 具体业务类型主数据
- 文档类型页 = 主数据维护与汇总展示
- 评查点分组页 = 实际运行绑定维护页

这套结构对应的运行链路是：

- 入口模块
- 一级分组（业务大类）
- 二级分组（具体业务类型）
- 规则集
- 规则版本

其中：

- 入口模块：决定当前页面进入的是哪条业务线
- 一级分组：承接该业务线的一级分类容器
- 二级分组：决定这次上传/评查具体命中的业务类型
- 规则集：决定跑哪组规则
- 规则版本：决定跑规则集的哪一版

也就是说，当前正式口径是：

`入口模块 -> 一级分组（业务大类） -> 二级分组（具体业务类型） -> 规则集 -> 规则版本`

文档类型在这条链路中的位置是：

- 作为“具体业务类型主数据”
- 通过 `document_type_id` 与二级分组形成稳定对应关系
- 用于上传页、规则页、文档列表等业务页面识别当前业务类型

## 1.1 老系统与新系统的关系

### 老系统（docauditai）

老系统更接近：

```text
DocumentType -> TopLevelGroup(s) -> ChildGroups -> EvaluationPoints
```

特点：

- `document_types.evaluation_point_groups_ids` 绑定顶层组
- `evaluation_point_groups` 是两级树
- `evaluation_points` 实际挂在子组下
- 运行时还会按 `area + document_attribute_type` 过滤

### 当前新平台（leaudit-platform）

当前新平台已经同时存在两套表达：

1. 规则执行主链
   - `DocumentType -> RuleTypeBinding -> RuleSet -> RuleVersion`
2. 分组管理主链
   - `EntryModule -> Level1Group -> Level2Group -> RuleSet`

这就是大家容易混淆的根源。

### 当前统一理解

应统一理解为：

- 文档类型是业务类型主数据
- 二级分组是运行时具体命中的业务类型节点
- 规则集挂在二级分组下
- `leaudit_rule_type_bindings` 继续承担执行链快速查找规则集的职责

也就是说：

- 文档类型页负责“主数据”
- 分组页负责“运行绑定”
- `rule_type_bindings` 负责“执行收口”

## 2. 现在系统为什么会让人混淆

当前系统的过渡态更接近：

- 一级分组 = 具体文档类型
  - 如：`建设工程合同`、`停业办理`
- 二级分组 = 该文档类型下的默认子类型
  - 如：`通用`

这与产品最新口径不一致，主要有三个问题：

1. 一级分组被错误地做成了“具体文档类型”，而不是“业务大类容器”。
2. 上传页看到的“子类型”其实只是默认二级分组，业务人员会误以为配置还没做好。
3. 入口模块与一级分组之间缺少明确绑定语义，后续无法优雅支持新入口。

## 3. 目标树形样例

### 3.1 合同类

```text
合同（一级 = 业务大类）
├── 建设工程合同（二级 = 具体业务类型）
│   ├── 规则集：建设工程合同-正文审查
│   └── 规则集：建设工程合同-签署审查
├── 买卖合同（二级 = 具体业务类型）
│   └── 规则集：买卖合同-通用审查
└── 委托合同（二级 = 具体业务类型）
    └── 规则集：委托合同-通用审查
```

### 3.2 卷宗类

```text
卷宗（一级 = 业务大类）
├── 处罚-一般程序（二级 = 具体业务类型）
│   └── 规则集：行政处罚-一般程序审查
├── 处罚-简易程序（二级 = 具体业务类型）
│   └── 规则集：行政处罚-简易程序审查
├── 许可-停业办理（二级 = 具体业务类型）
│   └── 规则集：行政许可-停业办理审查
└── 许可-新办办理（二级 = 具体业务类型）
    └── 规则集：行政许可-新办办理审查
```

### 3.3 将来新增入口

```text
内部公文（一级 = 业务大类）
├── 请示类公文（二级）
├── 通知类公文（二级）
└── 纪要类公文（二级）
```

即：

- 不需要预先写死“只有合同、卷宗”
- 后续新增业务时，直接新建一级、新建二级、挂规则集、再把一级绑定给入口模块即可

## 4. 页面职责重定义

### 4.1 评查点分组页 `/rule-groups`

这是唯一的运行绑定页，负责：

- 维护一级分组（业务大类）
- 维护二级分组（具体业务类型）
- 维护二级分组绑定的规则集
- 维护一级分组与入口模块的绑定关系

统一文案：

- 一级：业务大类
- 二级：具体业务类型
- 规则集：实际运行绑定
- 入口模块：一级分组归属入口

### 4.2 文档类型页 `/document-types`

文档类型页保留为“类型主数据页”，职责调整为：

- 维护具体文档类型名称、编码、描述
- 展示该类型的汇总规则集
- 不再承担一级/二级分组结构维护职责

统一文案：

- “汇总规则集”
- “仅用于总览，实际运行绑定请在评查点分组页维护”

补充说明：

- 当前文档类型与规则集之间仍可保留“汇总绑定 / 快速绑定”能力
- 但最终运行时应以“二级分组绑定规则集”为准
- 因此文档类型页更适合做：
  - 主数据编辑
  - 入口模块归属展示
  - 汇总规则集总览

### 4.3 上传页 `/files/upload`

上传页统一交互为：

1. 先根据入口模块确定可用的一级分组
2. 再根据一级分组或文档类型加载二级分组
3. 用户选择本次上传实际命中的二级分组
4. 最终上传时携带 `groupId`

## 5. 数据模型建议

## 5.1 继续复用 `leaudit_evaluation_point_groups`

当前表不必推倒重建，建议继续复用，并明确字段语义：

- `pid = 0`
  - 表示一级分组（业务大类）
- `pid != 0`
  - 表示二级分组（具体业务类型）

字段语义建议：

- 一级分组：
  - `document_type_id` 可为空
  - `entry_module_id` 可为空，但新模型建议填写
  - `name` = 业务大类名称，如 `合同` / `卷宗`
- 二级分组：
  - `document_type_id` 建议必填，对应实际具体文档类型
  - `pid` 指向对应一级分组
  - `entry_module_id` 通常从一级继承，不需要单独维护

## 5.2 新增或正式启用 `entry_module_id`

为支撑“一级分组绑定入口模块”，分组表需要显式支持：

- `entry_module_id`

用途：

- 绑定一级分组与入口模块的归属关系
- 后续上传页、首页导航、入口权限控制都可以围绕该关系展开

## 5.3 与 `leaudit_rule_type_bindings` 的关系

当前不建议粗暴删除 `leaudit_rule_type_bindings`。

更合理的口径是：

- 分组树负责表达“业务结构”和“规则集挂载关系”
- `leaudit_rule_type_bindings` 负责表达“执行时文档类型如何快速命中规则集”

可以把它理解为：

- 分组树 = 业务真相源
- `rule_type_bindings` = 执行加速索引 / 收口层

## 6. 迁移原则

### 6.1 旧“一级=具体文档类型”是过渡态

当前数据库里已经有一批：

- 一级 = `建设工程合同`
- 二级 = `通用`

这些不是最终结构，只是为了先把运行链路跑通。

### 6.2 未来迁移目标

应逐步迁成：

- 一级 = `合同`
- 二级 = `建设工程合同`
- 规则集继续挂二级

也就是说，未来需要把“当前一级里的具体文档类型”下沉成真正的二级。

## 7. 推荐迁移步骤

### 步骤 1：冻结语义

先统一团队口径：

- 一级 = 业务大类
- 二级 = 具体业务类型
- 规则集 = 只挂二级
- 一级 = 入口模块绑定对象

### 步骤 2：后端先支持双语义兼容

后端接口先支持：

- 一级可绑定 `entry_module_id`
- 二级继续绑定 `document_type_id`
- `/by-document-types` 允许从“二级文档类型”反查所属一级

这样即使数据库还没完全迁，也能先把接口语义准备好。

### 步骤 3：前端页面改口径

`/rule-groups` 需逐步改为：

- 一级显示业务大类
- 二级显示具体业务类型
- 页面突出一级与入口模块关系

### 步骤 4：测试库迁移旧树

建议先在测试库按以下思路演练：

1. 建立一级：`合同`
2. 建立一级：`卷宗`
3. 将现有“建设工程合同 / 买卖合同 / 停业办理 ...”迁成各自二级
4. 把原二级下规则集保留在新二级
5. 清理旧默认 `通用` 子类型，仅在确实没有继续细分的情况下保留

### 步骤 5：再落正式库

正式库迁移必须在测试通过后执行，避免规则命中错位。

## 8. 运行时唯一正确规则

迁移完成后，唯一正确的运行规则应为：

1. 用户进入某入口模块
2. 系统确定该入口可见的一级分组
3. 用户选择具体二级分组
4. 后端按 `groupId` 查询 `leaudit_rule_group_bindings`
5. 找到对应规则集
6. 取规则集可执行版本执行评查

即：

- 文档类型页：总览
- 分组页：运行绑定
- 上传页：按二级分组命中

## 9. 当前开发阶段结论

截至当前：

- “规则集挂二级”这部分方向是对的
- “一级=具体文档类型”这部分已被产品新口径推翻
- 后续开发应转向“一级=业务大类、一级绑定入口、二级=具体业务类型”

因此接下来所有实现都应围绕这条新口径继续推进，而不是再沿旧过渡模型加深。