招标文件分析

工作流程

0. 文档预处理（PDF 增强）

当主要数据源为 PDF 且无可用 Word 版本时，先运行预处理脚本提升 PDF 数据质量。

0.1 解析 PDF 页面

python .claude/skills/bid-analysis/scripts/parse_pdf.py <pdf路径> --output <工作目录>/pdf_pages.json

读取输出 JSON，检查 parser_used（解析器）和 is_scanned（是否扫描件）。

0.2 提取 TOC

python .claude/skills/bid-analysis/scripts/extract_pdf_toc.py <pdf路径> --pages-json <工作目录>/pdf_pages.json --output <工作目录>/pdf_toc.json

读取输出 JSON：

• 如 has_embedded_toc=true，使用 page_sections 进行定向章节读取
• 如检测到 toc_pages，读取 toc_page_text 自行分析 TOC 结构

0.3 OCR（可选，仅扫描件）

如 is_scanned=true 且 OCR_SERVICE_URL 已配置：

python .claude/skills/bid-analysis/scripts/ocr_pages.py <pdf路径> --pages 1-N --output <工作目录>/pdf_ocr.json

0.4 解析 Excel 附件（多文件场景）

如工作目录包含 Excel 文件（技术规范表、报价清单、参数对比表等），先解析为结构化数据：

python .claude/skills/bid-analysis/scripts/parse_excel.py <excel路径> --output <工作目录>/excel_data.json --format both

输出文件：

• excel_data.json：结构化数据（包含所有工作表和单元格）
• excel_data.md：Markdown 格式表格（便于 LLM 阅读）

批量处理：如有多个 Excel 文件，依次解析，输出命名为 <文件名>_data.json 和 <文件名>_data.md。

1. 读取采购文件（多文件支持）

1.1 多文件识别和格式优先级

文件类型识别：
招标文件通常包含多个文件，需全部分析：

• 主文件（磋商文件/招标公告）：Word (.docx) 或 PDF
• 技术规范：Excel (.xlsx, .xls) 或 Word 或 PDF
• 合同模板：Word (.docx) 或 PDF
• 报价清单：Excel (.xlsx)
• 参数对比表/功能清单：Excel (.xlsx)
• 其他附件：根据文件名识别

格式优先级（同一内容多格式时）：

1. 优先读取 Word (.docx) 格式（文本精确、表格结构化、无OCR误差）
2. Excel (.xlsx) 格式用于参数表、清单、对比表
3. PDF 作为补充或唯一来源时使用

多文件处理原则：

• 如用户提供多个文件，必须全部读取并分析，不可遗漏
• 主文件（磋商文件）提取评分标准、流程要求
• Excel 附件提取技术参数、功能清单、报价模板
• 合同附件提取合同条款、付款条件
• 所有内容汇总到统一的分析报告中

1.2 Word 文件读取方法

使用 python-docx 提取文本和表格：

from docx import Document
doc = Document('文件路径.docx')

# 提取段落文本
for para in doc.paragraphs:
    print(para.text)

# 提取表格（关键！评分标准、供应商须知附表等核心数据都在表格中）
for table in doc.tables:
    for row in table.rows:
        cells = [cell.text.strip() for cell in row.cells]
        print(cells)

关键原则：表格必须完整提取，不可跳过或概括。

1.3 PDF 文件读取方法

• 预处理完成时（步骤 0 已生成 pdf_pages.json 和 pdf_toc.json）：
  • 按 TOC 的 page_sections 定位章节 start_page/end_page
  • 从 pdf_pages.json 的 pages 数组中读取目标页范围的文本
  • 表格已有 [TABLE]...[/TABLE] Markdown 标记，无需额外处理
  • 如有 OCR 结果（pdf_ocr.json），用 OCR 文本替换对应页的空白文本
• 预处理未完成/失败时：回退原方案 — 使用 Read tool 读取 PDF，每次 15-20 页，分批覆盖全部内容
• PDF 图片的 OCR 精度有限，数字、金额、分值等关键数据必须反复确认

1.4 Excel 文件读取方法

预处理完成时（步骤 0.4 已生成 excel_data.json 和 excel_data.md）：

1. 读取 Markdown 格式（推荐）：

   # 使用 Read tool 读取生成的 Markdown 文件
   Read <工作目录>/<文件名>_data.md

2. 读取 JSON 格式（备选）：

   # 如需程序化处理，读取 JSON
   Read <工作目录>/<文件名>_data.json

预处理未完成时：

• 直接使用 Read tool 读取 Excel 文件
• Claude 可以直接解析 Excel 内容并提取表格数据

Excel 文件的典型内容：

• 技术规范表：功能参数、性能指标、技术要求
• 报价清单：分项报价、单价、数量、金额
• 功能对比表：投标人功能 vs 采购人要求
• 评分标准表：评分维度、分值、评分细则
• 资格条件表：供应商资格要求清单

关键原则：

• Excel 表格必须完整提取所有行和列，不可跳过或概括
• 特别注意数字精度（金额、分值、数量）
• 识别表头行和数据行
• 多工作表文件需逐个读取

1.5 多文件读取策略

单文件场景：

• 如果 TOC 可用（pdf_toc.json 的 page_sections 非空），先读 TOC JSON 确定整体结构和页码范围，按章节定向读取
• 采购文件可能分多册（第一册：通用部分/磋商文件，第二册：项目专用部分/采购需求），全部读取
• 先读目录页确定整体结构，再按章节深入

多文件场景：

1. 识别文件角色：根据文件名和内容判断每个文件的作用

   • 主文件（磋商文件.docx、招标公告.pdf）→ 评分标准、流程要求
   • 技术规范.xlsx → 技术参数、功能清单
   • 报价清单.xlsx → 分项报价、预算
   • 合同模板.docx → 合同条款、付款方式

2. 按优先级读取：

   • 第一步：读取主文件（磋商文件），建立整体框架
   • 第二步：读取技术规范 Excel，提取详细参数
   • 第三步：读取其他附件（合同、报价清单等）
   • 第四步：交叉验证，确保信息一致

3. 信息合并原则：

   • 主文件的评分标准为准
   • Excel 的技术参数补充到技术需求章节
   • 合同的付款条件补充到商务要求章节
   • 标注每条信息的来源文件

必须完整读取以下关键部分（可能分布在多个文件中）：

• 磋商邀请/招标公告（项目概况、资格要求、时间地点）
• 供应商须知附表（份数、密封、付款、交付期等核心商务条件，通常以表格形式出现）
• 评审方法和评分细则（完整评分表）
• 响应文件格式（文件组成要求）
• 附件格式（模板清单）
• 服务要求/技术要求（功能需求、技术参数）
• Excel 中的技术参数表（必须逐行提取）
• Excel 中的报价清单（分项名称、数量、要求）

2. 提取关键信息

核心原则：引用原文，不得概括或推断。

关键数据必须直接从文档中提取原文，不可根据经验推测。特别是：

• 资格条件：如原文写"无"就是"无"，绝不可编造条件
• 金额/分值：必须逐字核对，不可四舍五入或估算
• 评分标准：必须提取完整评分规则文字，不可概括

多文件场景的特殊要求：

• 标注来源：每条关键信息后标注来源文件，格式 （来源：文件名）
• Excel 数据处理：
  • 技术参数表：逐行提取参数名称、要求、响应
  • 报价清单：提取分项名称、数量、单位、要求
  • 评分标准表：如Excel与主文件均有评分表，以主文件为准，Excel作补充
• 信息冲突处理：
  • 如多个文件出现冲突信息，以主文件（磋商文件/招标公告）为准
  • 标注冲突："存在冲突：文件A称XXX，文件B称YYY，以文件A为准"
• 信息补充：
  • 主文件的概要性描述可用 Excel 的详细数据补充
  • 例：主文件"需满足技术规范要求" + Excel技术规范表 → 输出详细参数清单

按以下结构输出：

## 项目概况
- 项目名称 / 采购编号 / 采购人 / 采购代理 / 预算金额 / 最高限价
- 采购方式 / 截止时间 / 递交地点 / 联合体 / 进口产品
- 响应文件有效期

## 资格要求
### 一般资格条件
- 逐条列出（引用原文）
### 特定资格条件
- 逐条列出，**如原文明确"无"，必须写"无"**
### 负面清单
- 逐条列出

## 评分标准
### 总分结构
| 大类 | 分值 |

### 评分细则（完整表格）
| 评审因素 | 分值 | 评审标准（引用原文） |
- 必须提取评分表每一行的完整内容
- 必须验证子项分值之和等于大类分值，如有矛盾必须标注

## 技术需求
### 功能需求
- 功能模块逐条（标注▲等特殊标记）
- 逐条列出功能点，保持原文编号

### 技术参数（如有Excel技术规范表，必须逐行提取）
**格式1：叙述性参数**
- 参数1：要求内容（来源：文件名）
- 参数2：要求内容（来源：文件名）

**格式2：Excel 参数表（推荐）**
| 序号 | 参数名称 | 技术要求 | 备注 | 来源 |
|------|----------|----------|------|------|
| 1 | CPU | ≥8核 | ▲ | 技术规范.xlsx |
| 2 | 内存 | ≥32GB | | 技术规范.xlsx |

**格式3：对比表（投标人响应 vs 采购人要求）**
| 序号 | 功能/参数 | 采购人要求 | 投标人响应 | 偏离说明 | 来源 |
|------|-----------|------------|------------|----------|------|
| 1 | 并发用户数 | ≥500 | （待填写） | | 技术规范.xlsx |

**注意事项：**
- Excel 表格必须**逐行完整提取**，不可概括为"详见附件"
- 特别标注 ▲★ 等重要参数标记
- 数字精度保持一致（如"≥500"不可写成"不少于500"）

## 商务要求
- 交付期 / 付款方式（具体比例）/ 质保期/维护期 / 售后
- 份数 / 密封要求 / 电子版要求 / 保证金
- 分包转包 / 知识产权 / 公开唱价

## 响应文件组成
- 附件编号 + 名称清单
- ★标注必须提供的文件

3. 输出合规注意事项表

从采购文件中提取所有涉及合规、形式审查的要求，输出为表格。如文件中未明确提及某项，标注"未提及（建议XXX）"给出推荐做法。

## 合规注意事项

| 类别 | 要求 | 来源 | 备注 |
|------|------|------|------|
| **封面** | 是否要求指定封面格式/内容 | 第N页 | 通常需含：项目名称、采购编号、供应商名称、日期 |
| **目录** | 是否要求编页码和目录 | | |
| **装订** | 胶装/活页/侧脊标注要求 | | |
| **密封** | 密封方式/是否分别单独密封/封条要求 | | 注意是否要求多个独立密封包 |
| **包装** | 内外包装/标注要求 | | 外包装标注项目名称+编号，勿标供应商名 |
| **签署** | 法人签字/授权代表签字/逐页签章 | | 注意"逐页小签"要求 |
| **盖章** | 公章/骑缝章位置和范围 | | 报价单、技术方案、资格证明、功能截图是否需单独盖章 |
| **电子版** | 是否需同时提交U盘/光盘/电子文件 | | 格式要求（PDF/Word/加密），是否单独密封 |
| **报价格式** | 大写金额/含税/分项报价/总价/份数 | | 报价一览表是否需单独密封/一式几份 |
| **有效期** | 响应文件有效期要求 | | 通常为提交截止日起90天 |
| **保证金** | 金额/账户/到账截止时间 | | 不收取也要明确标注"不收取" |
| **递交方式** | 现场递交/邮寄/电子平台 | | 迟到=拒收，注意地址和截止时分 |
| **份数** | 正本/副本数量/不一致时以谁为准 | | 精确数量（如正本1+副本5） |
| **偏离** | 是否允许偏离/负偏离扣分规则 | | 实质性条款偏离=废标，▲标注负偏离扣分更重 |
| **联合体** | 是否允许联合体投标 | | |
| **分包** | 是否允许分包/转包 | | |
| **演示** | 是否需要现场演示/演示设备要求 | | 演示形式（系统实操/PPT/视频）、时长限制 |
| **人员社保** | 是否要求提供人员社保证明 | | 社保时间范围、缴纳单位一致性要求 |

逐项检查要点：

• 封面：部分采购文件附有封面模板（固定格式），必须按模板制作；无模板时至少包含项目名称、编号、供应商全称+公章、日期
• 密封：最易忽略的废标项，注意"密封完好""封口加盖公章""骑缝章"等措辞；特别注意是否要求分别单独密封（正副本/报价表/电子版各自独立密封）
• 签署盖章：注意区分"法定代表人签字"和"授权代表签字"（后者需附授权书）；"逐页小签"指每页右下角签字或盖章
• 报价：大小写金额不一致以大写为准是行业惯例，但部分采购文件规定以小写为准，需确认
• 保证金：如不收取必须写"不收取"而非"未提及"；电汇到账有延迟，建议提前2个工作日转账
• 电子版：注意格式（PDF/Word）、是否需要与纸质版一致、是否需要单独密封
• 偏离表：无偏离也要提交空表（写"无偏离"），不提交可能被判为响应不完整
• 人员社保：近年评分中经常要求提供社保证明，必须确认社保缴纳时间范围和单位一致性

4. 数据验证（关键步骤）

在输出分析报告前，必须进行以下验证：

4.1 评分分值验证

• 计算各大类子项分值之和，与大类总分对比
• 计算所有大类分值之和，与总分对比
• 如有差异，必须明确标注差异并建议向采购代理确认

4.2 关键数据交叉验证

• 预算金额：在磋商邀请和报价要求中是否一致
• 采购编号：在封面、磋商邀请、附件模板中是否一致
• 资格条件：磋商邀请中的条件与供应商须知附表中是否一致
• 截止时间：磋商邀请与供应商须知中是否一致

4.3 完整性检查

• 供应商须知附表的每一行是否都已提取（份数、密封、付款等）
• 评分细则表的每一行是否都已提取
• 响应文件格式中的每个附件是否都已列出
• ★标注的必须提供文件是否完整列出

5. 分析评分策略

• 识别分值最高的评分项，标注重点方向
• 映射评分点到具体需要准备的材料（业绩合同、资质证书、人员简历+社保、功能截图等）
• 区分客观分（有即满分/扣分制）和主观分（需质量竞争），提示各类得分策略
• 标注需要提前准备的硬性材料（证书、社保、合同等不可临时编造的文件）

6. 输出响应文件大纲

按采购文件要求的附件格式，生成完整的响应文件目录，每个附件标注：

• 内容类型（文字/表格/扫描件/图片占位符）
• 对应的评分项（如有）
• 是否为★必须提供项

脚本依赖

• pdfplumber: pip install pdfplumber（PDF 表格检测）
• PyMuPDF: 已安装（PDF 基础解析）
• requests: 已安装（OCR 客户端，可选）

注意事项

数据准确性（最高优先级）

• 绝对禁止：根据经验推测或编造采购文件中不存在的内容（如虚构资格条件）
• 资格要求和负面清单必须逐条完整提取，遗漏可能导致废标
• 评分标准必须引用原文而非概括，避免理解偏差
• 金额、分值、日期等数字必须逐字核对

文档来源标注

• 多册文件需标注来源（第N册第M页 或 Word文件表格N）
• PDF 和 Word 内容不一致时以 Word 为准（PDF可能有排版问题）

文件格式识别

• Word (.docx)：用 python-docx 提取，重点提取所有表格
• PDF：优先使用预处理脚本（parse_pdf.py + extract_pdf_toc.py），回退用 Read tool 分批读取，注意OCR精度问题
• 如同时存在两种格式，明确告知用户以 Word 为准

评分矛盾处理

• 如发现评分表子项之和与总分不符，必须明确标注并建议向采购代理确认
• 不可自行"修正"或"合理推测"文件中的矛盾，原文怎么写就怎么报告

输出文件

分析报告固定输出到工作目录下的 分析报告.md（文件名不可更改，后续 skill 依赖此文件名）。

完成状态

分析完成后，输出以下结构化状态摘要，供 bid-manager 等上游 skill 读取：

--- BID-ANALYSIS COMPLETE ---
项目名称: {项目名称}
采购编号: {采购编号}
预算金额: {预算金额}
评分总分: {总分}
评分大类: {价格X分, 技术X分, 商务X分, ...}
附件数量: {响应文件组成中的附件总数}
★必须附件: {★标记的附件数量}
▲功能条目: {▲标注的技术需求条目数}
输出文件: 分析报告.md
状态: SUCCESS
--- END ---