Files
bid-doctor/docs/analysis/04-domain-model.md
YANG JIANKUAN e29c40ec41 docs: 新增 PRD v0.9.1、决策记录与 MVP 需求分析
- PRD v0.9.1:补充政府采购体系依据(87 号令),异常低价口径按体系分层
- decisions.md:D1 首发 IT 集成、A1 需求分析 G1–G10、T1 国产云端模型路由
- docs/analysis:范围与角色、用户旅程、功能需求、领域模型、
  IT 集成领域知识、缺口清单、苏采云样本分析

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-02 18:23:05 +08:00

118 lines
6.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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)时一个部署就是一个租户,模型不需要改。