# 04 · 领域模型草案

> 这是需求层面的概念模型，不是数据库设计。字段只列出决定业务规则的那些，物理建模留到技术架构阶段。
> 核心是 PRD 第 5 章说的「**项目检查清单**」：M2 产出它，M3 拿它做核对，V1 的 M4 拿它做生成约束，M5 也挂在它上面。

## 1. 实体关系

```mermaid
erDiagram
    Tenant ||--o{ User : "成员"
    Tenant ||--o{ Subscription : "订阅"
    Tenant ||--|| QuotaAccount : "额度账户"
    QuotaAccount ||--o{ QuotaEntry : "流水"
    Tenant ||--o{ Qualification : "资质库"
    Tenant ||--o{ Project : "投标项目"

    Project ||--o{ Lot : "包/标段"
    Project ||--o{ SourceDocument : "招标文件/补遗/投标文件"
    SourceDocument ||--o{ ParseJob : "解析任务"
    SourceDocument ||--o{ Citation : "被引用"
    Project ||--|| Checklist : "项目检查清单"
    Checklist ||--o{ ChecklistItem : "清单项"
    ChecklistItem }o--o{ Citation : "出处"
    ChecklistItem }o--o| Lot : "所属包(空=通用)"

    Project ||--o{ CheckRun : "检查批次"
    CheckRun ||--o{ Finding : "问题"
    Finding }o--|| ChecklistItem : "对应清单项"
    Finding }o--o{ Citation : "双方出处"
    Finding |o--o| Finding : "沿用自上次"
    CheckRun ||--o| Report : "检查报告"

    QuotaEntry }o--o| ParseJob : "关联任务"
    QuotaEntry }o--o| CheckRun : "关联任务"
```

所有业务实体都带 `tenant_id`，按租户隔离（PRD 7）。

## 2. 实体说明

| 实体 | 关键字段 | 说明 |
|---|---|---|
| **Tenant** 企业主体 | 名称、统一社会信用代码（可空）、当前套餐 | 额度和数据的归属单位（PRD 4.3：额度绑定企业主体） |
| **User** 用户 | 手机号、所属租户、角色 | MVP 一个租户一个成员；角色字段先留着，给 V1 用 |
| **Subscription** 订阅 | 套餐、起止日期、来源（注册赠送 / 人工开通 / 线上支付） | |
| **QuotaAccount / QuotaEntry** 额度 | 单位（解析 / 检查 / 生成 / 查重）、类型（发放 / 预扣 / 结算 / 退回 / 过期 / 调整 / 免扣）、数量、关联任务、原因 | 只追加、不修改；余额由流水算出来 |
| **Qualification** 资质 | 名称、类型、等级、证书号、发证机构、有效期、附件 | MVP 最小资质库 |
| **Project** 投标项目 | 名称、编号、采购人、代理机构、采购方式、**法律体系**、截止时间、状态、所投包 | 基本信息来自 FR-M2-03，用户可以改 |
| **Lot** 包 / 标段 | 包号、名称、预算、最高限价、是否投标 | 没有分包时只有一个默认包 |
| **SourceDocument** 文档 | 角色（招标文件 / 补遗 / 澄清 / 投标分册）、分册名、版本号、原始文件、规范化 PDF、页数、解析状态 | 所有文件都转成规范化 PDF，作为出处页码的唯一依据 |
| **ParseJob** 解析任务 | 状态、阶段、模型与提示词版本、耗时、失败原因 | 一份文档可以有多次任务（重试） |
| **Citation** 出处 | 文档、页码、原句、坐标范围 | 「可复核」的载体；清单项和问题共用 |
| **Checklist** 检查清单 | 状态（草稿 / 已确认）、版本号、确认人、确认时间 | 每个项目一份；每次确认生成新版本 |
| **ChecklistItem** 清单项 | 类别标签（可以多个）、标题、要求原文、重要性（★ / ▲ / 一般）、所属包、证明材料要求、比较方式与要求值（参数类）、来源（AI / 人工 / 补遗 N）、状态（待确认区 / 正式 / 已删除）、置信度 | 见 05 §3 |
| **CheckRun** 检查批次 | 清单版本、投标文件版本集合、规则版本、状态、是否扣点 | 可以复现「当时根据什么做的判断」 |
| **Finding** 问题 | 类型（未响应 / 负偏离未说明 / 疑似不满足 / 形式 / 资质 / 报价形式 / 人工核对）、级别、说明、出处、处理状态、忽略原因、处理人、处理时间、沿用来源 | |
| **Report** 报告 | 文件、生成时间、生成人 | 生成后不再改动；重新导出就生成新报告 |
| **AuditEvent** 审计事件 | 操作人、动作、对象、修改前、修改后、时间 | 不在上图中，所有实体都会写 |
| **Feedback** 反馈 | 对象（问题 / 清单）、类型（误报 / 漏报）、说明、处理状态 | 进运营后台 |

## 3. 状态机

### 3.1 项目

```mermaid
stateDiagram-v2
    [*] --> 跟进中: 新建
    跟进中 --> 编制中: 首份招标文件解析成功
    编制中 --> 已检查: 完成首次检查
    已检查 --> 已检查: 复查
    已检查 --> 已递交: 用户标记
    已递交 --> 已检查: 撤销递交(留痕)
    已检查 --> 已归档: 用户归档
    已递交 --> 已归档: 用户归档
    已归档 --> 已检查: 撤销归档
    已归档 --> 已递交: 撤销归档(原状态为已递交)
```

「就绪 / 未就绪」是项目上单独的一个标记，不是状态：只要最近一次检查批次里还有「待处理」的致命问题，就是未就绪。

### 3.2 解析任务

```mermaid
stateDiagram-v2
    [*] --> 排队中: 发起(预扣1次)
    排队中 --> 解析中
    排队中 --> 已取消: 用户取消(退回)
    解析中 --> 成功: 结算
    解析中 --> 失败: 退回
    解析中 --> 已取消: 用户取消(退回)
    失败 --> 排队中: 重试(重新预扣)
```

### 3.3 问题（Finding）

```mermaid
stateDiagram-v2
    [*] --> 待处理
    待处理 --> 已确认无误
    待处理 --> 已修改
    待处理 --> 已忽略: 必填原因
    已确认无误 --> 待处理: 撤销
    已修改 --> 待处理: 撤销
    已忽略 --> 待处理: 撤销
    note right of 待处理
      复查时：问题仍在 → 沿用状态(已修改改回待处理)
      问题消失 → 本次已解决
    end note
```

## 4. 关键设计约束

1. **出处统一用规范化 PDF 的页码**：Word 没有稳定的页码，必须先转成 PDF。转换结果存下来，以后不要重新生成，否则老的出处会对不上。
2. **清单有版本**：检查批次引用的是清单的某个版本，后面再改清单，不影响历史报告。
3. **额度流水只追加**：账户余额由流水算出来，所以「失败不扣点」可以从流水验证。
4. **AI 产出记录模型和提示词版本**：解析任务、检查批次都要记，这样漏报复盘时能知道是哪个版本出的问题。
5. **租户隔离**：所有查询都必须带租户条件；私有化（P2）时一个部署就是一个租户，模型不需要改。