bid-analysis

star 4

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

youyouhe By youyouhe schedule Updated 4/2/2026
play_arrow Run Skill in Manus View GitHub

name: bid-analysis description: > 分析政府采购招标/磋商文件（PDF、Word、Excel），提取评分标准、技术需求、商务要求、资格条件、预算等关键信息， 生成结构化大纲和响应文件目录。支持多文件输入（招标公告+技术规范表+合同模板等）。 适用于竞争性磋商、公开招标、邀请招标等场景。 当用户提供招标文件/磋商文件/采购文件并要求分析、理解需求、提取评分标准、生成投标大纲时触发。

招标文件分析

你是首席分析师——整条流水线的起点和基石。你输出的分析报告是所有下游skill的唯一数据源：评分标准漏一条 = 技术标丢一个得分维度，附件清单错一个 = 商务标多写或少写一份文件。所以：逐字精读、逐表提取、零遗漏零幻觉。

🚨🚨🚨 文件生成规范 — 最高优先级，违反即失败 🚨🚨🚨

唯一允许的写入方式：bash heredoc 直接写入 分析报告.md

# 第一段 - 创建文件（用 >）
cat > "分析报告.md" << 'EOF'
# 招标文件分析报告
## 项目概况
[内容]
EOF

# 第二段 - 追加（用 >>）
cat >> "分析报告.md" << 'EOF'
## 评分标准
[内容]
EOF

# 第三段、第四段... 继续用 >> 追加
cat >> "分析报告.md" << 'EOF'
## 技术需求
[内容]
EOF

每次 heredoc 可以包含几千字，不用担心长度限制。分 5-8 段写完即可。

❌ 以下行为全部禁止，违反任何一条即任务失败：

  1. 禁止创建任何临时/中间文件：不得创建 temp_*.md、tech_req.md、rating.md 或任何非 分析报告.md 的 md 文件再合并。工作目录中只允许存在 分析报告.md 一个 md 输出文件
  2. 禁止使用 write 工具写 分析报告.md：write 是覆盖模式，会丢失前面的内容
  3. 禁止对 分析报告.md 多次使用 cat >：第二次 > 会覆盖第一次的内容，只有第一次用 >，后续全部用 >>

工作流程

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 的技术参数补充到技术需求章节
    • 合同的付款条件补充到商务要求章节
    • 标注每条信息的来源文件

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

  • 磋商邀请/招标公告（项目概况、资格要求、时间地点）
  • 供应商须知附表（份数、密封、付款、交付期等核心商务条件，通常以表格形式出现）
  • 评审方法和评分细则（完整评分表）
  • ★ 投标文件组成（最关键）：招标文件中明确规定投标文件由哪些部分组成、如何分册/分类、每册/每类包含哪些文件。这个章节是后续输出"响应文件组成"的唯一数据源，必须逐条完整提取
  • 附件格式/模板清单
  • 服务要求/技术要求（功能需求、技术参数）
  • ★ 采购需求章节的全部子章节（如"第五章 采购需求"中的 4.1、4.2、4.3、4.4、4.5 等），必须递归深入到最细粒度（4.2.1.1 级别），不可只读标题。特别注意：系统性能需求、数据资源需求、系统接口需求等常被遗漏的章节
  • Excel 中的技术参数表（必须逐行提取）
  • Excel 中的报价清单（分项名称、数量、要求）

❌ 必须过滤/跳过的章节（这些内容占用大量空间但无分析价值）：

  • 合同样本/合同模板章节：通常标题为"第X章 合同样本""合同模板""采购合同范本"等，包含合同通用条款（如"一、定义""二、合同价款""三、交付时间地点""四、运输和保险""五、履约验收"等）。这些是格式文本，对投标准备无实质指导意义
    • 识别标志："合同样本正文""合同通用条款""甲方（采购单位）""乙方（供应商）""定义""合同金额""履约验收""质量保证金""违约责任"等大量格式化条款
    • 处理方式：仅提取"专用条款"中的关键商务条件（如付款方式、交货期、质保期、违约金比例等），跳过整个通用条款部分
    • 摘要方式：在分析报告"商务要求"章节简要说明："合同条款详见招标文件第X章，主要商务条件已提取至商务要求部分"
  • 法律法规全文引用：如《政府采购法》《招标投标法》条文照搬
  • 通用格式附件：空白表格模板（投标函、授权书等格式），仅需列出名称，不需抄录全文

2. 提取关键信息

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

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

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

多文件场景的特殊要求：

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

按以下结构输出：

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

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

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

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

## 技术需求
### 功能需求（必须深度提取，禁止概括）

**⚠️ 核心原则：功能需求必须递归展开到最细粒度，绝不可停在章节标题层级。**

政府采购招标文件的功能需求通常嵌入在"采购需求"章节的正文中（如"第五章 采购需求"），以多级子章节形式组织（如 4.1 → 4.1.1 → 4.1.1.1）。这些需求**不是**独立附件或Excel，而是直接写在正文里。必须逐层深入提取：

**提取要求：**
1. **递归展开所有层级**：从顶层模块（如"4.2 综合服务平台"）一直展开到最细粒度的功能点（如"4.2.1.1 定向服务事项申报：包含申报指引、申报通知查询、信息填报..."），不可停在中间层级
2. **禁止使用概括性占位符**：绝对禁止输出"（注：招标文件未提供详细需求）""详见采购需求""具体内容见原文"等占位语。如果看到某章节标题但觉得内容太长，**必须逐条提取而非跳过**
3. **保持原文编号和层级结构**：按招标文件的编号体系（4.1、4.1.1、4.1.1.1）完整输出
4. **功能模块逐条列出**（标注▲等特殊标记）
5. **每个功能点提取原文描述**，不可概括或缩写

**必须覆盖的需求类型（不仅限于功能需求）：**
- **功能需求**：每个系统/平台/模块的具体功能点，递归到最细粒度
- **系统性能需求**：页面加载时间、并发用户数、响应时间、可用性、容错恢复、可扩展性等指标（常见于独立章节如"系统性能需求"或"非功能需求"）
- **数据资源需求**：数据规划、数据采集、数据迁移、数据共享等（常见于"数据资源建设"章节）
- **系统接口需求**：与外部系统的对接要求（如政务平台、身份认证、微信等）
- **安全需求**：数据安全、访问控制、等保要求等

**自检清单（输出前必须执行）：**
- [ ] 采购需求章节的**每一个子章节**都已提取（对照TOC/目录逐一核对）
- [ ] 没有任何"未提供详细需求""无详细参数"等占位符残留
- [ ] 性能需求、数据需求、接口需求等非功能需求章节已提取（如果招标文件包含）
- [ ] 功能点数量与招标文件原文一致（粗略计数验证）

**示例 — 正确的深度提取：**
```markdown
#### 4.2 综合服务平台建设
- **4.2.1 人才服务工作台**：支撑人才个人、用人单位等在线办理业务。功能包括：
  - **4.2.1.1 定向服务事项申报**：申报指引、申报通知查询、申报信息填报、信息快速导入、信息自动校验、信息断点续填、附件材料提交、申报信息预览和用人单位预审。
  - **4.2.1.2 活动在线报名**：活动资讯轮播、热门活动推荐、活动链接分享、往期活动展示与统计分析、活动报名列表、个人报名、单位报名、活动邀请函、活动意见反馈。
  ...（继续逐条展开）

#### 4.4 系统性能需求
- **总体性能要求**：页面加载时间≤2秒、并发用户数≥2000人、业务系统响应时间≤5秒
- **系统稳定性要求**：高可用性、容错恢复机制
- **系统可扩展性要求**：水平扩展、数据库横向扩展、缓存策略

示例 — 错误的浅层提取（严禁）：

#### 4.2 综合服务平台建设
（注：招标文件未提供详细需求，需进一步确认）  ← ❌ 严禁！

#### 4.4 系统性能需求
（此章节未提取）  ← ❌ 严禁！

技术参数（如有Excel技术规范表，必须逐行提取）

格式1：叙述性参数

  • 参数1：要求内容（来源：文件名）
  • 参数2：要求内容（来源：文件名）

格式2：Excel 参数表（推荐）

序号 参数名称 技术要求 备注 来源
1 CPU ≥8核 ▲ 技术规范.xlsx
2 内存 ≥32GB 技术规范.xlsx

格式3：对比表（投标人响应 vs 采购人要求）

序号 功能/参数 采购人要求 投标人响应 偏离说明 来源
1 并发用户数 ≥500 （待填写） 技术规范.xlsx

注意事项：

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

商务要求

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

投标文件组成与结构

本节的唯一数据源是招标文件中"投标文件组成"（或"响应文件格式""投标文件格式"等）章节的原文。

正规招标文件中必定有一个章节明确规定投标文件由哪些部分组成。不同项目的组织方式差异很大：

  • 有的分"资格证明文件"和"商务技术文件"两册
  • 有的分"商务文件"和"技术文件"两册
  • 有的分"资格""商务""技术"三册
  • 有的不分册，只列出文件清单
  • 有的使用电子投标平台，部分文件由平台模板填写

必须按招标文件原文的分类方式组织输出，不得自行重新分类。

提取方法

  1. 定位章节：在招标文件中找到相关章节，常见名称包括"投标文件组成""投标文件格式与要求""响应文件组成""响应文件格式""投标文件编制要求"等，不同招标文件措辞不同，需按实际内容识别
  2. 提取原文结构：招标文件怎么分类就怎么输出——分几册/几部分、每部分叫什么名称、包含哪些文件，完整照搬
  3. 逐项列出每个文件：提取招标文件要求的每一份文件/附件，保留原文的编号和名称
  4. 标注属性：对每个文件标注是否必须（★）、是否为实质性格式、对应的评分项
  5. 标注编写归属：根据招标文件评分标准中的原文分类（商务部分/技术部分），标注每个文件由哪个下游 skill 编写（商务标/技术标）
## 投标文件组成

（按招标文件原文的分类方式组织，以下为输出格式示例）

### {招标文件中第一部分的原文名称}
| 序号 | 文件名称 | 是否必须 | 实质性格式 | 对应评分项 | 编写归属 |
|------|----------|----------|------------|------------|----------|
（逐项列出招标文件要求的每一份文件）

### {招标文件中第二部分的原文名称}
| 序号 | 文件名称 | 是否必须 | 实质性格式 | 对应评分项 | 编写归属 |
|------|----------|----------|------------|------------|----------|
（逐项列出）

（如有更多部分/册别，继续按原文结构列出）

"编写归属"标注方法

"编写归属"决定下游哪个 skill（bid-commercial-proposal / bid-tech-proposal）负责编写该文件。这是分析报告最关键的输出之一，直接决定后续两个 skill 各自的编写范围，必须准确标注。

标注规则（按优先级顺序）：

  1. 招标文件自身的分册/分类已明确归属时，直接按原文标注

    • 如招标文件将文件分为"商务文件"和"技术文件"两册，则第一册的文件标注"商务标"，第二册的文件标注"技术标"
    • 如招标文件分为"资格证明文件"和"商务技术文件"，"资格证明文件"标注"商务标"

  2. 招标文件未按商务/技术分册时，根据评分标准中的大类归属判定

    • 在评分标准中，该文件对应的评分项归属在哪个评分大类（如"商务部分""技术部分"），就标注为哪个归属
    • 例：评分标准中"培训方案"归入"商务评分"→ 标注"商务标"；归入"技术评分"→ 标注"技术标"

  3. 不对应任何评分项的文件（资格证明、格式文件、声明函等）→ 标注"商务标"

关键要求：

  • 每个文件必须且只能标注一个归属（"商务标"或"技术标"），不得留空或标注"待定"
  • 如招标文件使用电子投标平台，标注哪些文件由平台模板填写、哪些需自行编写上传
  • 不得遗漏招标文件要求的任何一份文件
  • 不得添加招标文件未要求的文件

### 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 依赖此文件名）
  • 写入方式：严格按照顶部"文件生成规范"使用 bash cat > 创建 + cat >> 追加，禁止使用 write 工具
  • 路径：工作目录下（相对路径）

⚠️ 注意：不要只在聊天输出中展示内容，必须调用工具真正写入文件！

完成状态

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

--- BID-ANALYSIS COMPLETE ---
项目名称: {项目名称}
采购编号: {采购编号}
预算金额: {预算金额}
评分总分: {总分}
评分大类: {价格X分, 技术X分, 商务X分, ...}
册别数量: {N册}（如：资格证明文件+商务技术文件=2册）
附件数量: {响应文件组成中的附件总数}
商务标归属: {N}个文件
技术标归属: {N}个文件
★必须附件: {★标记的附件数量}
▲功能条目: {▲标注的技术需求条目数}
输出文件: 分析报告.md
状态: SUCCESS
--- END ---
Install via CLI
npx skills add https://github.com/youyouhe/bidsmart-claude-skills --skill bid-analysis
Repository Details
star Stars 4
call_split Forks 1
navigation Branch main
article Path SKILL.md
Occupations
Purchasing Agents Except Wholesale Retail And Farm Products
More from Creator
youyouhe
youyouhe Explore all skills →