team_and_architecture.md 5.2 KB
投标书智能生成系统 — 团队分工与技术方案
一、团队组成与职责
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"}