Files
leaudit-platform-backend/docs/内部公文模块/内部公文模块迁移方案.md

8.6 KiB
Raw Permalink Blame History

内部公文模块迁移方案

1. 目标定位

govdoc-audit 不应作为独立系统继续外挂,而应正式收口为当前 leaudit-platform 中的一个一等业务模块。

建议模块名:

  • govdoc
  • 中文显示名:内部公文处理

它在当前项目中的定位应为:

  • 一个“公文处理与格式审查模块”
  • 共享当前平台的用户、权限、文档、OSS、任务系统
  • 拥有自己独立的规则、运行、结果、报告模型

2. 总体迁移原则

一句话原则:

  • 迁“引擎”
  • 不迁“壳子”

应迁入当前项目的内容:

  • 公文解析器
  • 段落角色识别
  • 语义实体提取
  • YAML DSL
  • 规则执行器
  • HTML / DOCX / JSON 报告生成

不建议直接迁入的内容:

  • FastAPI API 层
  • SQLite 存储层
  • web 前端
  • 原本地 var/documents 落盘模式

原因是当前平台已经具备更成熟的基础设施:

  • 统一 FastAPI 应用
  • JWT / RBAC
  • 地区隔离
  • 文档主档与文件版本
  • MinIO / OSS
  • Celery 异步任务
  • bridge 执行链

因此正确方案不是再造第二个平台,而是把 govdoc-audit 变成当前平台中的一个能力模块。


3. 模块化后的目标形态

3.1 后端模块职责

该模块应负责:

  • 公文上传
  • 公文格式审查
  • 审查结果查询
  • 规则查看
  • 报告下载
  • 审查过程留痕

不负责:

  • 通用 RAG
  • 合同评审
  • 交叉评查

3.2 前端模块职责

前端中应新增一个独立入口模块,页面建议包括:

  • 公文上传页
  • 审查列表页
  • 审查详情页
  • 规则查看页
  • 报告下载入口
  • 模块配置页(可选)

路由建议:

  • /govdoc
  • /govdoc/upload
  • /govdoc/list
  • /govdoc/detail/:documentId

4. 推荐架构分层

建议按 6 层拆分:

  1. 接口层
  2. 服务层
  3. 执行桥接层
  4. 引擎内核层
  5. 持久化层
  6. 展示层

4.1 接口层

建议新增:

  • fastapi_modules/fastapi_leaudit/controllers/govdocController.py

职责:

  • 上传公文
  • 查询公文列表
  • 发起审查
  • 查询运行状态
  • 查询结果详情
  • 下载 HTML / DOCX / 原文
  • 查询规则清单

控制器只做:

  • JWT 鉴权
  • DTO 收参
  • 调 service
  • 统一返回 Result

4.2 服务层

建议新增:

  • fastapi_modules/fastapi_leaudit/services/govdocService.py
  • fastapi_modules/fastapi_leaudit/services/impl/govdocServiceImpl.py

职责:

  • 复用当前文档服务做上传与元数据管理
  • 创建公文审查 run
  • 调度异步任务
  • 聚合查询结果
  • 组织前端详情数据

4.3 执行桥接层

建议新增目录:

fastapi_modules/fastapi_leaudit/govdoc_bridge/
  __init__.py
  tasks.py
  runner.py
  input_resolver.py
  rules_resolver.py
  storage_adapter.py
  result_adapter.py
  report_adapter.py
  context_builder.py
  security_guard.py

职责:

  • 从当前平台读取文档与文件元数据
  • 从 OSS 下载文档到本地临时文件
  • 解析规则版本并准备本地规则文件
  • 调用 govdoc 引擎执行
  • 将结果适配回当前平台数据库和 OSS

这是整个模块接入的关键层。

4.4 引擎内核层

建议把 govdoc-audit 裁剪后并入当前仓库:

fastapi_modules/fastapi_leaudit/govdoc_engine/
  __init__.py
  models.py
  pipeline.py
  parser/
  dsl/
  engine/
  reporter/
  llm/

建议迁入:

  • parser/
  • dsl/
  • engine/
  • reporter/
  • llm/
  • models.py
  • pipeline.py

明确不迁:

  • api/
  • storage/
  • services/storage_service.py
  • web/

4.5 持久化层

不建议继续使用原项目自己的 SQLite + var/documents 模式。

应基于当前平台数据库新增公文模块结果域表。

4.6 展示层

不迁原 govdoc-audit/web

应直接在当前前端项目中新增 govdoc 模块页面,复用现有:

  • 登录态
  • 权限体系
  • 侧边栏菜单
  • UI 样式体系

5. 数据模型建议

5.1 应复用的平台公共表

建议直接复用:

  • sso_users
  • roles
  • user_role
  • permissions
  • role_permissions
  • sys_routes
  • role_route
  • leaudit_documents
  • leaudit_document_files

这些表负责:

  • 用户身份
  • 权限控制
  • 地区隔离
  • 文档主档
  • 文件版本
  • OSS 关联

5.2 建议补充的主档字段

建议在 leaudit_documents 增加一个模块标识字段,例如:

  • engine_type

可选值:

  • leaudit
  • govdoc
  • rag

这样平台可以明确知道某份文档应走哪条处理链。

5.3 建议新增的公文模块结果域表

第一阶段建议至少新增:

  • govdoc_runs
  • govdoc_rule_results
  • govdoc_report_artifacts

后续可补:

  • govdoc_entities
  • govdoc_rule_sets
  • govdoc_rule_versions

推荐理解方式:

  • 公共主档复用
  • 领域结果隔离

不要把公文模块结果硬塞进现有 leaudit_audit_runs / leaudit_rule_results

原因:

  • 语义不完全一致
  • 结果模型不完全兼容
  • 统计口径会混乱
  • 后期拆分成本更高

6. 模块权限设计建议

建议一开始就单独定义 govdoc 模块权限键:

  • govdoc:module:read
  • govdoc:document:create
  • govdoc:document:read
  • govdoc:document:update
  • govdoc:document:delete
  • govdoc:run:create
  • govdoc:run:read
  • govdoc:report:read
  • govdoc:rule:read
  • govdoc:rule:manage

权限层继续复用当前平台:

  • JWT 鉴权
  • RBAC
  • 地区隔离

数据范围继续遵守当前平台规则:

  • 省级管理员:全量
  • 地区管理员:本地区
  • 普通用户:本人数据

7. 迁移实施步骤

建议分 5 期推进。

第一期:内核迁入

目标:

  • govdoc-audit 裁成当前项目内可调用的纯引擎内核

动作:

  • 新建 govdoc_engine/
  • 迁入 parser / dsl / engine / reporter / llm
  • 去掉原 api / storage / web 依赖
  • 改成本项目统一 import 结构
  • 规则文件暂放本地规则目录

产出:

  • 当前项目内可以本地调用一份 .docx 执行公文审查

第二期:bridge 接入

目标:

  • 接入当前 worker 执行链

动作:

  • 新建 govdoc_bridge/tasks.py
  • 新建 govdoc_bridge/storage_adapter.py
  • 新建 govdoc_bridge/result_adapter.py
  • 复用 OSS 下载到本地临时文件
  • 复用 Celery 异步执行
  • 结果回写 DB + 上传 OSS

产出:

  • 当前项目可异步跑公文审查任务

第三期:服务与接口接入

目标:

  • 正式形成后端模块 API

动作:

  • 新增 govdocController.py
  • 新增 govdocServiceImpl.py
  • 接入 JWT
  • 接入地区隔离
  • 接入上传、列表、详情、运行状态、报告下载

产出:

  • 前端可以通过当前后端 API 正式使用公文模块

第四期:前端模块接入

目标:

  • 当前平台页面可用

动作:

  • 新增侧边栏模块
  • 新增上传页、列表页、详情页
  • 详情页展示:
    • 分数
    • findings
    • entities
    • 原文段落联动
    • HTML / DOCX 报告下载
  • 接入权限控制

产出:

  • 用户可在当前平台直接使用“内部公文处理”

第五期:平台化收口

目标:

  • 进入长期可维护状态

动作:

  • 规则版本化
  • 报告产物统一 OSS
  • 文件转换 / 解析隔离执行
  • LLM / OCR 白名单与审计
  • 指标监控
  • 错误告警
  • 运行留痕

产出:

  • 模块正式生产可用

8. 推荐目录结构

fastapi_modules/fastapi_leaudit/
  controllers/
    govdocController.py

  services/
    govdocService.py
    impl/
      govdocServiceImpl.py

  govdoc_bridge/
    __init__.py
    tasks.py
    runner.py
    input_resolver.py
    rules_resolver.py
    storage_adapter.py
    result_adapter.py
    report_adapter.py
    security_guard.py

  govdoc_engine/
    __init__.py
    models.py
    pipeline.py
    parser/
    dsl/
    engine/
    reporter/
    llm/

  models/
    govdocRun.py
    govdocRuleResult.py
    govdocEntity.py
    govdocReportArtifact.py
    govdocRuleSet.py
    govdocRuleVersion.py

文档与 SQL

docs/内部公文模块/
  内部公文模块迁移方案.md
  内部公文模块数据表复用与新增建议.md

scripts/创建sql/
  schema_add_govdoc_module.sql
  seed_govdoc_permissions.sql
  seed_govdoc_entry_module.sql

9. 最终建议

最优方案不是:

  • 保留 govdoc-audit 为独立服务
  • 当前平台只做代理壳

而应该是:

  • govdoc-audit 裁成 govdoc_engine
  • 通过 govdoc_bridge + Celery + OSS + RBAC + 地区隔离
  • 正式并入 leaudit-platform

最终形成:

  • 平台共享底座
  • 模块独立结果域
  • 前后端统一接入
  • 规则、报告、运行态统一纳入当前项目

这是最稳、最适合长期维护的一条路。