AgentSkillsCN

bid-analysis

分析政府采购招标/磋商文件（PDF或Word），提取评分标准、技术需求、商务要求、资格条件、预算等关键信息， 生成结构化大纲和响应文件目录。适用于竞争性磋商、公开招标、邀请招标等场景。 当用户提供招标文件/磋商文件/采购文件并要求分析、理解需求、提取评分标准、生成投标大纲时触发。

中文原作
SKILL.md
--- frontmatter
name: bid-analysis
description: >
  分析政府采购招标/磋商文件（PDF或Word），提取评分标准、技术需求、商务要求、资格条件、预算等关键信息，
  生成结构化大纲和响应文件目录。适用于竞争性磋商、公开招标、邀请招标等场景。
  当用户提供招标文件/磋商文件/采购文件并要求分析、理解需求、提取评分标准、生成投标大纲时触发。

招标文件分析

工作流程

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

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

0.1 解析 PDF 页面

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

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

0.2 提取 TOC

bash
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 已配置：

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

1. 读取采购文件

1.1 格式优先级

  • •优先读取 Word (.docx) 格式（文本精确、表格结构化、无OCR误差）
  • •PDF 作为补充或唯一来源时使用
  • •如果用户同时提供了 PDF 和 Word 版本，必须以 Word 为主要数据源

1.2 Word 文件读取方法

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

python
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 读取策略

  • •如果 TOC 可用（pdf_toc.json 的 page_sections 非空），先读 TOC JSON 确定整体结构和页码范围，按章节定向读取
  • •采购文件可能分多册（第一册：通用部分/磋商文件，第二册：项目专用部分/采购需求），全部读取
  • •先读目录页确定整体结构，再按章节深入
  • •必须完整读取以下关键部分：
    • •磋商邀请/招标公告（项目概况、资格要求、时间地点）
    • •供应商须知附表（份数、密封、付款、交付期等核心商务条件，通常以表格形式出现）
    • •评审方法和评分细则（完整评分表）
    • •响应文件格式（文件组成要求）
    • •附件格式（模板清单）
    • •服务要求/技术要求（功能需求、技术参数）

2. 提取关键信息

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

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

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

按以下结构输出：

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

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

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

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

## 技术需求
- 功能模块逐条（标注▲等特殊标记）
- 技术参数/性能指标

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

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

3. 输出合规注意事项表

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

markdown
## 合规注意事项

| 类别 | 要求 | 来源 | 备注 |
|------|------|------|------|
| **封面** | 是否要求指定封面格式/内容 | 第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 读取：

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