# 投标书智能生成系统 — 团队分工与技术方案

## 一、团队组成与职责

### 1. 产品经理（PM）
**职责：**
- 理解招标业务需求，编写产品需求文档（PRD）
- 与用户（投标公司）沟通，明确信息补充清单
- 评审技术方案是否满足业务要求
- 定义验收标准，确认最终输出效果

**关键产出：**
- 投标公司信息收集表（JSON Schema）
- 投标文件目录结构规范
- 产品验收清单

---

### 2. 技术负责人（Tech Lead）
**职责：**
- 拆分产品需求为可执行的技术模块
- 编写总体技术方案和各模块接口定义
- 整合各独立模块为完整 pipeline
- 把控技术架构的扩展性（多标项、多招标类型）

**关键产出：**
- 系统技术架构图
- 模块接口定义（API / 数据流）
- Pipeline 编排脚本

---

### 3. 算法开发人员（Algorithm Developer）
**职责：**
- 实现各算法模块：
  - 招标文件解析模块（PDF 文本/表格提取）
  - 投标文件结构生成模块（LLM 分析 + 大纲构建）
  - 公司信息填充模块（LLM + 模板引擎）
  - 评分标准一致性校验模块
- 使用 DeepSeek API 进行信息分析和填充
- 确保输出内容准确、格式规范

**关键产出：**
- `pdf_table_to_docx/` — PDF 表格提取与还原
- `llm/llm_utils.py` — LLM 调用封装（分析、抽取、填充）
- 投标文件生成 Pipeline 各阶段脚本

---

### 4. 测试人员（Tester）
**职责：**
- 根据产品需求和招标文件要求编制测试用例
- 功能测试：验证生成的投标文件是否包含所有必需内容
- 一致性测试：附件编号与正文引用是否一致
- 表格完整性测试：招标文件表格是否原样呈现在投标文件中
- 多标项测试：不同包件组合的生成逻辑

**关键产出：**
- 测试用例集
- 缺陷报告
- 验收测试报告

---

## 二、整体 Pipeline 设计

```
Phase 1: 招标文件解析
  │
  ├── PDF 文本提取 (PyMuPDF)
  ├── PDF 表格提取 → docx 表格 (pdf_table_to_docx)
  └── 结构化存储 (JSON)
  
Phase 2: 投标大纲构建
  │
  ├── LLM 分析招标文件需求
  ├── 参考历史投标文件结构
  └── 输出：投标目录大纲 + 需补充信息清单

Phase 3: 公司信息收集
  │
  ├── 根据 Phase 2 的信息清单生成 JSON 模板
  ├── 投标公司填写/上传材料（文本 + 图片）
  └── 输出：已填充的 bid_fill_draft.json
  
Phase 4: 内容填充
  │
  ├── 招标表格原样还原（保留格式、合并单元格等）
  ├── LLM 填充正文内容（参考历史投标文件）
  ├── 图片/扫描件嵌入
  └── 一致性校验（附件编号、名称对应）

Phase 5: 投标文件生成
  │
  ├── JSON → DOCX 渲染
  ├── 表格、图片、签章占位符还原
  └── 输出：最终投标文件.docx

Phase 6: 测试验证
  │
  ├── 表格完整性检查
  ├── 附件引用一致性检查
  ├── 评分标准覆盖检查
  └── 输出：测试报告
```

---

## 三、第一优先级：信息清单生成已完成

基于本次分析，已生成 `output/company_info_template.json`，包含：

| 分类 | 字段数 | 必需字段 | 支持图片 |
|------|--------|----------|----------|
| 公司基本信息 | 20 | 8 | 0 |
| 法定代表人及授权委托人信息 | 14 | 11 | 7 |
| 资质证书 | 9 | 8 | 9 |
| 财务状况 | 4 | 4 | 4 |
| 企业声明函 | 5 | 4 | 5 |
| 团队人员信息 | 16 | 13 | 2 |
| 历史业绩 | 4 | 3 | 3 |
| 报价信息 | 7 | 6 | 5 |
| 设备资源 | 2 | 1 | 1 |
| 服务方案参考 | 3 | 0 | 1 |
| **合计** | **84** | **58** | **35** |

### 特别优化：授权委托人信息
- 法定代表人信息独立为子分类（6个字段）
- **授权委托人信息独立为子分类**（6个字段，含身份证正反面照片）—— 这是大多数投标实际使用的经办人
- **授权委托书本身作为独立子分类**（签字盖章扫描件 + 文字内容）—— 投标无效的关键项，不可遗漏

---

## 四、关键设计决策

### 1. 表格处理策略
- 招标文件中的表格，通过 `pdf_table_to_docx` 提取为 docx 格式
- 在投标文件中**原样保留**表格结构（列数、合并单元格、表头）
- 投标公司仅填充表格数据内容，不改变表格结构

### 2. 附件编号一致性
- 维护一个 `attachment_registry`（附件注册表）
- 正文中引用附件时，自动从注册表中获取编号和名称
- 输出前自动校验：无错引、漏引

### 3. 多标项支持
- 招标文件中多个标项 → 在投标文件中分别处理
- 根据招标文件判断是否可全做/只能承接一个
- 支持包件间内容复用的同时保持独立性

### 4. 图片存储方案
- JSON 中支持 `image_path`（本地路径）或 `image_base64`（Base64 编码）
- 建议小图片（身份证、证书）用 base64 嵌入 JSON
- 大图片（合同扫描件）用文件路径引用

### 5. LLM 提示词策略
- `llm_utils.py` 封装了三种场景：analyze / extract / fill
- 不同功能使用不同 system prompt 和 temperature 参数
- 结构化输出统一使用 `response_format={"type": "json_object"}`