| name | bid-analysis |
| description | 分析政府采购招标/磋商文件（PDF或Word），提取评分标准、技术需求、商务要求、资格条件、预算等关键信息， 生成结构化大纲和响应文件目录。适用于竞争性磋商、公开招标、邀请招标等场景。 当用户提供招标文件/磋商文件/采购文件并要求分析、理解需求、提取评分标准、生成投标大纲时触发。
|
招标文件分析
工作流程
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
1. 读取采购文件
1.1 格式优先级
- 优先读取 Word (.docx) 格式（文本精确、表格结构化、无OCR误差）
- PDF 作为补充或唯一来源时使用
- 如果用户同时提供了 PDF 和 Word 版本，必须以 Word 为主要数据源
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 读取策略
- 如果 TOC 可用（
pdf_toc.json 的 page_sections 非空），先读 TOC JSON 确定整体结构和页码范围，按章节定向读取
- 采购文件可能分多册（第一册：通用部分/磋商文件，第二册：项目专用部分/采购需求），全部读取
- 先读目录页确定整体结构，再按章节深入
- 必须完整读取以下关键部分：
- 磋商邀请/招标公告（项目概况、资格要求、时间地点）
- 供应商须知附表（份数、密封、付款、交付期等核心商务条件，通常以表格形式出现）
- 评审方法和评分细则（完整评分表）
- 响应文件格式（文件组成要求）
- 附件格式（模板清单）
- 服务要求/技术要求（功能需求、技术参数）
2. 提取关键信息
核心原则：引用原文，不得概括或推断。
关键数据必须直接从文档中提取原文，不可根据经验推测。特别是：
- 资格条件：如原文写"无"就是"无"，绝不可编造条件
- 金额/分值：必须逐字核对，不可四舍五入或估算
- 评分标准：必须提取完整评分规则文字，不可概括
按以下结构输出：
## 项目概况
- 项目名称 / 采购编号 / 采购人 / 采购代理 / 预算金额 / 最高限价
- 采购方式 / 截止时间 / 递交地点 / 联合体 / 进口产品
- 响应文件有效期
## 资格要求
### 一般资格条件
- 逐条列出（引用原文）
### 特定资格条件
- 逐条列出，**如原文明确"无"，必须写"无"**
### 负面清单
- 逐条列出
## 评分标准
### 总分结构
| 大类 | 分值 |
### 评分细则（完整表格）
| 评审因素 | 分值 | 评审标准（引用原文） |
- 必须提取评分表每一行的完整内容
- 必须验证子项分值之和等于大类分值，如有矛盾必须标注
## 技术需求
- 功能模块逐条（标注▲等特殊标记）
- 技术参数/性能指标
## 商务要求
- 交付期 / 付款方式（具体比例）/ 质保期/维护期 / 售后
- 份数 / 密封要求 / 电子版要求 / 保证金
- 分包转包 / 知识产权 / 公开唱价
## 响应文件组成
- 附件编号 + 名称清单
- ★标注必须提供的文件
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 ---
