bid-analysis

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 文件读取方法

方式 A（优先）：DocScan 转换服务

先检查服务是否在线：

curl -s http://localhost:8800/api/health

若返回正常（HTTP 200），使用服务转换：

# 上传 .docx，获取 fid（返回 JSON 字符串，如 "abc123"）
FID=$(curl -s -X POST http://localhost:8800/api/convert \
  -F "file=@文件路径.docx" | python -c "import sys,json; print(json.load(sys.stdin))")

# 获取全部页面的 Markdown（含文本和表格），同时保存到本地以备核实
curl -s "http://localhost:8800/api/md/$FID" | tee docscan_output.md

服务返回的 Markdown 已完整包含文档的所有段落和表格，直接作为分析输入使用。

方式 B（服务离线时回退）：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章 合同样本""合同通用条款""合同专用条款""合同模板""采购合同范本"等的章节，整章完全跳过，不提取任何内容。包括通用条款和专用条款均不提取。
  • 识别标志："合同样本正文""合同通用条款""合同专用条款""甲方（采购单位）""乙方（供应商）""违约责任""争议解决""合同生效"等
  • 处理方式：整章跳过，不写入分析报告
  • 商务要求（交付期、付款方式、质保期、履约保证金等）应从"采购项目商务要求"章节或"须知前附表"中提取，而非合同章节
• 法律法规全文引用：如《政府采购法》《招标投标法》条文照搬
• 通用格式附件：空白表格模板（投标函、授权书等格式），仅需列出名称，不需抄录全文

2. 提取关键信息

核心原则：引用原文 + 标注精确来源，不得概括或推断。

分析报告里的每一条数据都来自采购文件的具体位置，因此每一条数据都应该能被回溯验证。所有章节的所有字段必须标注精确来源（Table{N} Row{M} 或 段落{N}），来源缺失 = 该条数据存在幻觉风险。

特别是：

• 资格条件：如原文写"无"就是"无"，绝不可编造条件
• 金额/分值/时间/月数/份数等数字：必须逐字核对，来源必须精确到行
• 评分标准：必须提取完整评分规则文字，不可概括

多文件场景的特殊要求：

• 标注来源：每条关键信息后标注来源文件，格式 （来源：文件名）
• Excel 数据处理：
  • 技术参数表：逐行提取参数名称、要求、响应
  • 报价清单：提取分项名称、数量、单位、要求
  • 评分标准表：如Excel与主文件均有评分表，以主文件为准，Excel作补充
• 信息冲突处理（先裁决，后质询）：发现多处描述不一致时，不得一律标注"存疑/建议向代理确认"——先判定类型，能自裁决的自裁决，不能的才质询。详见下文"冲突与不一致的处理原则"。
• 信息补充：
  • 主文件的概要性描述可用 Excel 的详细数据补充
  • 例：主文件"需满足技术规范要求" + Excel技术规范表 → 输出详细参数清单

按以下结构输出（所有节均需标注精确来源，格式统一为 Table{N} Row{M} 或 段落{N}）：

## 项目概况

| 字段 | 内容（原文） | 精确来源 |
|------|------------|---------|
| 项目名称 | （原文） | 段落N 或 Table N Row M |
| 采购编号 | （原文） | |
| 采购人 | （原文） | |
| 采购代理 | （原文） | |
| 预算金额 | （原文，含单位） | |
| 最高限价 | （原文，或"与预算相同"） | |
| 采购方式 | （原文） | |
| 报价截止时间 | （原文，精确到时分） | |
| 递交地点 | （原文，完整地址） | |
| 联合体 | （原文："接受"/"不接受"） | |
| 进口产品 | （原文："接受"/"不接受"） | |
| 响应文件有效期 | （原文，含起算说明） | |

## 资格要求

### 一般资格条件

| 序号 | 条件（逐字引用原文） | 精确来源 |
|------|-------------------|---------|
| 1 | （原文） | 段落N 或 Table N Row M |
| 2 | （原文） | |

### 特定资格条件

| 序号 | 条件（逐字引用原文） | 精确来源 |
|------|-------------------|---------|
| 1 | （原文；**如原文明确"无"，此处必须写"无"**） | |

### 负面清单

| 序号 | 条件（逐字引用原文） | 精确来源 |
|------|-------------------|---------|
| 1 | （原文） | |

## 评分标准

### 总分结构

| 大类 | 分值 | 精确来源 |
|------|------|---------|
| （原文大类名） | N分 | Table N Row M |

### 评分细则（完整表格）

| 评审因素 | 分值 | 评审标准（逐字引用原文） | 精确来源 |
|---------|------|----------------------|---------|
| （原文） | N分 | （原文规则全文） | Table N Row M |

- 必须提取评分表每一行的完整内容，不可跳行
- 必须验证子项分值之和等于大类分值，如有矛盾必须标注

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

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

政府采购招标文件的功能需求通常嵌入在"采购需求"章节的正文中（如"第五章 采购需求"），以多级子章节形式组织（如 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"）

商务要求

条目	内容（逐字引用原文）	精确来源
交付期	（原文，含起算点）	Table N Row M
付款方式	（原文，含各阶段比例和节点）
质保期/维护期	（原文，含期限数字）
售后服务	（原文）
份数	（原文，正本N份+副本N份）
密封要求	（原文，是否分别密封）
电子版要求	（原文，载体/格式/是否单独密封）
保证金	（原文，金额/账户/到账截止时间；或"不收取"原文）
履约保证金	（原文，比例/缴纳时限；或"不要求"）
分包转包	（原文）
知识产权	（原文，归属方）
公开唱价	（原文）

格式文件与封面格式

⚠️ 本节是下游 bid-commercial-proposal / bid-tech-proposal 正确复现格式的唯一依据。必须逐字提取，任何字段名改写均会导致封面和格式表错误。

封面格式（每册逐行逐字提取）

招标文件的"报价文件内容及格式"（或同名章节）通常包含每册的封面模板，必须逐字引用原文每一行，不得概括或用通用模板替代。

关键注意事项：

• 采购类型决定术语：军队采购全程使用"报价文件""报价供应商"，政府/地方采购使用"投标文件""投标人"。封面字段名必须与原文一致，严禁混用。
• 日期格式：原文是留白手写格式（"年 月 日"）还是预填日期，按原文执行，不可提前填写。
• 册别编号：提取原文册别名称及编号（如"一、价格文件""二、商务技术文件""三、资格证明文件"），下游 skill 复现封面时使用原文编号。

输出格式：

### 封面格式

| 册别 | 封面各行内容（按行序逐行列出，与原文完全一致） |
|------|----------------------------------------------|
| 一、价格文件 | 第1行: 军队服务类项目竞争性谈判 / 第2行: 报 价 文 件 / 第3行: 一、价格文件 / 第4行: 项目名称：{名称} / 第5行: 项目编号：{编号} / 第6行: 报价供应商：（盖章） / 第7行: 　　年　　月　　日 |
| 二、商务技术文件 | （同上，册别行改为"二、商务技术文件"） |
| 三、资格证明文件 | （同上，册别行改为"三、资格证明文件"） |

格式文件清单（附件表格模板列结构）

招标文件"报价文件内容及格式"章节提供的所有格式表格，必须逐一提取完整列名和特殊禁止条款。下游 skill 复现这些表格时，列名、列序必须与原文完全一致。

提取内容：

1. 表格编号和名称（如"附件1 服务报价单"）
2. 完整列名称，按原文顺序列出
3. 哪些列由采购机构预填写，哪些列由供应商填写
4. 表格下方的"说明"或特殊禁止条款（尤其重要：如技术要求响应表常见"原文完全复制招标文件技术要求，作无效投标处理"此类废标风险条款）

输出格式：

### 格式文件清单

| 附件编号 | 表格名称 | 列结构（按顺序，与原文一致） | 特殊说明/禁止条款 |
|---------|---------|----------------------------|-----------------|
| 附件1 | 服务报价单 | 序号 \| 服务名称 \| 计量单位 \| 数量 \| 单价（含税） \| 金额（含税） \| 交付时间/服务期限 \| 交付（服务）地点 | 金额=单价×数量；报价总价=金额之和 |
| 附件2 | 符合性审查索引表 | 序号 \| 符合性审查项目 \| 文件名称/页码 | 按《符合性审查表》编制；未填写视为无效报价 |
| 附件3 | 商务评审索引表 | 序号 \| 评审项目（采购机构填）\| 计分模型（采购机构填）\| 标准分值（采购机构填）\| 指标值或评分项（供应商填）\| 文件名称/页码（供应商填） | 按《商务评审标准表》编制 |
| 附件4 | 技术评审索引表 | （同附件3列结构）| 按《技术评审标准表》编制 |
| 附件5 | 商务要求响应表 | 序号 \| 商务要求 \| 商务响应 \| 偏离度 \| 报价文件位置页码 \| 备注 | ★号条款负偏离=无效报价 |
| 附件6 | 技术要求响应表 | 序号 \| 技术要求 \| 技术要求响应 \| 偏离度 \| 报价文件位置页码 \| 备注 | ⚠️ **原文完全复制技术要求=无效报价**（如有此条款必须加粗标注） |
| 附件7 | 服务交付内容表 | 序号 \| 交付内容 \| 交付时间 \| 交付地点 \| 交付方式 \| 数量 \| 备注 | 可根据项目实际调整内容 |
| 附件8 | 企业同类业绩表 | 序号 \| 用户名称 \| 项目名称 \| 服务内容 \| 合同有效金额（万元）\| 签订日期 \| 用户联系人及电话 \| 页码 | 合同缔约方存在控股/管理关系无效 |
| 附件9 | 财务社保数据统计表 | 年度数据项目 \| 23年度 \| 24年度 \| 25年度 \| 3年平均数 \| 文件名称/页码 | 与审计报告不一致以证明材料为准 |
| 附件10 | 项目团队配备表 | 项目组成员姓名 \| 年龄 \| 在项目组中的岗位 \| 学历 \| 从事本行业年限 \| 职业资格证书等级 \| 其他证书 \| 联系方式 | — |
| 附件11 | 资格证明文件索引表 | 序号 \| 资格性审查项目 \| 资格证明文件位置页码 | 按《资格性审查表》编制；未填写视为无效报价 |

注：以上为通用文件的标准格式，实际项目专用文件可能有增减。必须以当前招标文件实际表格为准，不得套用经验值。

投标文件组成与结构

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

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

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

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

提取方法

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

## 投标文件组成

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

### {招标文件中第一部分的原文名称}

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

### {招标文件中第二部分的原文名称}

| 序号 | 文件名称（原文） | 是否必须 | 实质性格式 | 对应评分项 | 编写归属 | 精确来源 |
|------|---------------|----------|------------|------------|----------|---------|
（逐项列出）

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

"编写归属"标注方法

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

---

被引用原文（格式模板数据源）

⚠️ 本节是整条流水线防止"精简失真"的关键防火墙。下游 skill 填写索引表、评审表时，"审查项目"和"评审项目"列必须且只能使用本节的逐字原文，不得使用其他章节中可能已被概括或改写的版本。

原理说明

招标文件的格式模板（如符合性审查索引表、商务/技术评审索引表、资格证明文件索引表）中，凡出现以下措辞，即表示该表的某列需要从招标文件另一处原样照搬：

• "按《XXX》编制"
• "按谈判文件表N（XXX）编制"
• "依据XXX填写"
• "参照XXX表"

典型被引用关系（军队采购）：

格式附件	引用说明	应原样照搬的内容
附件2-1 符合性审查索引表	按《资格性审查表》/按谈判文件表1编制	资格性审查表（表1）每条审查项目
附件2-2 商务评审索引表	按《商务评审标准表》编制	商务评审标准表每条评审项目、计分模型、标准分值
附件2-3 技术评审索引表	按《技术评审标准表》编制	技术评审标准表每条评审项目、计分模型、标准分值
附件3-1 资格证明文件索引表	按《资格性审查表》编制	同资格性审查表（表1）

政府采购/其他采购类型的附件编号和表名称以实际文件为准，原理相同。

提取原则

1. 一字不差：从招标文件原文逐字照抄，包括括号内的附加说明、"代缴社保不予认可"等限制条件、标点符号，全部保留
2. 包含全部附加说明：审查项目后的括号说明、表格备注列、下方"说明"文字，一并原文输出
3. 保持原文序号体系：原文用"1/2/3"或"一/二/三"或"六-①/六-②"等，按原文保留
4. 绝不概括：即使某条内容很长，也必须完整提取；即使某条内容与其他章节重复，也必须在本节完整重复输出

输出格式

对每一处被引用的内容，分别输出如下结构（以资格性审查表为例）：

### 资格性审查表（表1）原文

> 被引用于：附件2-1（符合性审查索引表）的"符合性审查项目"列 / 附件3-1（资格证明文件索引表）的"资格性审查项目"列

| 序号 | 审查项目（原文，一字不差） | 具体要求说明（原文，完整保留括注和附加条件） | 精确来源 |
|------|------------------------|----------------------------------------|---------|
| 1 | 营业执照或事业单位法人证书满足谈判文件要求 | 企业法人应当提供"统一社会信用代码营业执照"，…；军队单位不作要求。 | Table N Row M |
| 2 | 法定代表人资格证明书 | （如原文无附加说明则填"—"） | Table N Row M |
| 3 | 法定代表人授权书（含授权代表在报价前4个月内（不含报价当月）连续3个月由报价供应商缴纳社保证明材料） | 代缴社保证明材料不予认可。 | Table N Row M |
| 4 | 至申领谈判文件截止时间，供应商成立时间不少于3年（国有企业、事业单位、军队单位除外） | （如有附加说明则完整引用） | Table N Row M |
...（全部条目，不可省略任何一条）

### 商务评审标准表原文

> 被引用于：附件2-2（商务评审索引表）的"评审项目"列、"计分模型"列、"标准分值"列

| 序号（原文） | 评审项目（原文） | 计分模型（原文） | 标准分值（原文） | 精确来源 |
|------------|--------------|---------------|---------------|---------|
| 二 | 业绩 | 每份20%，最高4分 | 0-4 | Table N Row M |
...（全部条目）

### 技术评审标准表原文

> 被引用于：附件2-3（技术评审索引表）的"评审项目"列、"计分模型"列、"标准分值"列

| 序号（原文） | 评审项目（原文） | 计分模型（原文） | 标准分值（原文） | 精确来源 |
|------------|--------------|---------------|---------------|---------|
| 六 | 技术力量 | — | 9分 | Table N Row M |
| 六-① | ISO9001/GB/T19001/GJB9001质量管理体系认证（有效期内） | 客观计分 | 1分 | Table N Row M |
...（子项全部列出，不可合并）

⚠️ 重要警告：

• 本节与"评分标准"章节对同一条目的描述如不一致，以本节为准（本节是原文，评分标准章节可能有概括）
• 商务和技术评审索引表的"评审项目""计分模型""标准分值"三列均由采购机构预填，招标文件中已写明，必须在此原文输出；供应商只填"指标值或评分项"和"文件名称/页码"列
• 如项目使用政府采购格式，附件名称、表格结构可能不同，但引用原则相同，必须同样处理

---

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

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

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

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

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

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

关键要求：

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

### 3. 输出合规注意事项表

从采购文件中提取所有涉及合规、形式审查的要求，输出为**5列表格**。

#### 列说明与填写规范

| 列名 | 说明 | 填写规范 |
|------|------|---------|
| **类别** | 合规事项分类 | 固定标签，见下方模板 |
| **要求（概括）** | 用人话概括要求，便于快速阅读 | 简洁明了，不超过50字 |
| **原文摘录** | 从采购文件中逐字引用的原始文字（**防幻觉锚点**） | 必须加引号，逐字照抄原文；如原文未规定该项，写"**原文未规定**" |
| **精确来源** | 定位到具体位置，不可只写章节名 | Word文件写 `Table{N} Row{M}` 或 `段落{N}`；PDF写 `第X页第Y段` |
| **备注** | 补充说明、风险提示 | 可空 |

#### 🚨 原文摘录填写强制规则

**以下类型的数据，"原文摘录"列必须包含对应的字面量，否则视为幻觉风险：**
- 金额数字（保证金金额、预算金额）→ 摘录中必须出现该数字原文
- 时间/日期（截止时间、到账时间）→ 摘录中必须出现该时间原文
- 天数/月数（社保月数、有效期天数、质保期）→ 摘录中必须出现该数字原文
- 份数（正本/副本数量）→ 摘录中必须出现份数原文

**如果无法在原文中找到支持该结论的字面量，禁止在"要求"列写出该结论——改为"原文未规定"。**

```markdown
## 合规注意事项

| 类别 | 要求（概括） | 原文摘录 | 精确来源 | 备注 |
|------|------------|---------|----------|------|
| **封面格式** | 逐字按原文格式制作，军队采购用"报价文件/报价供应商"，政府采购用"投标文件/投标人" | （见本报告"封面格式"节，已逐行逐字提取） | 报价文件内容及格式章节（封面模板） | 字段名错误是低级废标风险，下游skill必须原文照搬 |
| **格式文件** | 所有附件表格按原文列结构复现，不增删列；注意技术响应表"原文照抄=无效报价"禁止条款 | （见本报告"格式文件清单"节） | 报价文件内容及格式章节 | 见分析报告"格式文件清单"节 |
| **目录** | （从原文提取，原文未规定则写"原文未规定"） | （原文摘录） | （来源） | |
| **装订** | （从原文提取） | （原文摘录） | （来源） | |
| **密封** | （从原文提取：是否分别单独密封、封条要求） | （原文摘录） | （来源） | 注意是否要求多个独立密封包 |
| **包装** | （从原文提取） | （原文摘录） | （来源） | 外包装标注项目名称+编号，勿标供应商名 |
| **签署** | （从原文提取：法人/授权代表/逐页签章） | （原文摘录） | （来源） | 注意"逐页小签"要求 |
| **盖章** | （从原文提取：公章/骑缝章位置和范围） | （原文摘录） | （来源） | |
| **电子版** | （从原文提取：载体/格式/是否单独密封） | （原文摘录） | （来源） | |
| **报价格式** | （从原文提取：大写/含税/分项/总价） | （原文摘录） | （来源） | |
| **有效期** | （从原文提取：具体天数） | （原文摘录，必须包含天数字面量） | （来源） | |
| **保证金** | （从原文提取：金额/账户/到账截止时间） | （原文摘录，必须包含金额数字和截止时间字面量） | （来源，精确到 Table N Row M） | 不收取也要明确标注"不收取" |
| **递交时间地点** | （从原文提取：开始时间/截止时间/地点） | （原文摘录，必须包含时间和地址字面量） | （来源，精确到 Table N Row M） | 迟到=拒收 |
| **份数** | （从原文提取：正本N份+副本N份） | （原文摘录，必须包含份数字面量） | （来源，精确到 Table N Row M） | 正副本不一致以谁为准也需摘录 |
| **偏离** | （从原文提取：是否允许/负偏离扣分规则） | （原文摘录） | （来源） | 实质性条款偏离=废标 |
| **联合体** | （从原文提取：接受/不接受） | （原文摘录，必须包含"是"/"否"原文） | （来源，精确到段落N或Table N Row M） | |
| **分包** | （从原文提取：是否允许分包/转包） | （原文摘录） | （来源） | |
| **演示** | （从原文提取，原文未规定则写"原文未规定"） | （原文摘录） | （来源） | |
| **人员社保** | （从原文提取：社保月数/适用人员/代缴是否认可） | （原文摘录，必须包含月数/天数字面量） | （来源，精确到 Table N Row M 或段落N） | 禁止套用经验值（如"6个月"），必须以原文为准 |
| **实质性条款▲** | ▲标注条款序号列表（从评审表逐行提取） | （从评审标准表逐行核实，列出每项▲的序号和内容摘要） | （Table N，逐行核实） | 序号必须与表格第一列数字完全一致，不得推算 |

逐项检查要点

• 原文摘录列不可为空：除封面格式和格式文件（已在其他节展开）外，每行原文摘录必须有实质内容
• 数字类要求的幻觉检测：完成后自查——在"原文摘录"列中搜索保证金金额、到账时间、社保月数、份数等关键数字，确认与"要求"列一致；如不一致，以原文摘录为准修正"要求"列
• 精确来源格式：Word文件用 Table{N} Row{M}（0-indexed行号）；段落文字用 段落{N}；PDF用 第{X}页
• 封面格式：必须逐字提取原文字段名，不可套用经验模板。区分采购类型：军队采购="报价文件/报价供应商"，政府采购="投标文件/投标人"
• 密封：最易忽略的废标项，注意"密封完好""封口加盖公章""骑缝章"等措辞；特别注意是否要求分别单独密封
• 保证金：如不收取必须写"不收取"而非"未提及"；到账截止时间必须引用原文字面时间，不得与递交截止时间混淆
• 人员社保：严禁套用经验值（如"6个月""3个月"），必须以原文为准填写月数并摘录原文；代缴是否认可也需摘录
• ▲实质性条款：序号必须从评审标准表第一列逐行读取，不得根据行号推算（表格可能有跳号）
• 偏离表：无偏离也要提交空表（写"无偏离"），不提交可能被判为响应不完整

---

冲突与不一致的处理原则（先裁决，后质询）{{.conflict-resolution}}

招标文件内部出现两处描述不一致时，不要一律标注"存疑/建议向代理确认"。必须先判定冲突类型，能自裁决的自裁决，不能裁决的才质询。

第一步：查找文件自带的裁决规则（优先）

正规招标文件通常在"特别提示""须知说明""算术修正"等章节预设了效力顺序或裁决规则。发现不一致时，必须主动回原文查找是否存在适用的裁决条款。常见裁决规则表述包括：

规则类型	典型原文措辞	裁决方向
文件效力顺序	"通用文件与专用文件不一致的，以专用文件为准"	专用文件 > 通用文件
附件与前附表	"前附表与正文不一致，以前附表为准"	前附表 > 正文
正副本/介质	"正本与副本不符，以正本为准"	正本 > 副本
金额修正	"大写和小写不一致，以大写为准"；"总价与单价汇总不一致，以单价汇总为准"	大写>小写；单价汇总>总价
中外文本	"以中文文本为准"	中文 > 外文
财务数据	"与审计报告不一致以证明材料实际数据为准"	原始凭证 > 汇总表
补充/澄清文件	"澄清文件为谈判文件的组成部分，与原文件不一致以澄清文件为准"	澄清文件 > 原文件

只要找到适用规则，即依规则得出确定结论，并在报告中援引规则出处（格式示例："据特别提示第一条'通用文件与专用文件不一致的，以专用文件为准'→ 以专用文件XX为准"）。此类冲突判定为已解决，不标 ⚠️、不建议质询。

第二步：无规则可依的冲突 → 质询

以下情形标注 ⚠️ 并建议向采购代理书面质询：

• 文件未提供任何可适用的效力顺序或裁决规则
• 冲突双方处于同一效力层级（同一张表内两处数字不同、正文两段互斥且无优先级），无法区分主次
• 依裁决规则处理后仍存在事实矛盾（如分值子项之和 ≠ 大类总分——可能是文件本身计算出错）

质询项须完整列出：冲突双方原文、各自精确来源、为何无法自裁决。

判定要点

1. 区分"规则性冲突"与"事实性冲突"：前者是文件预留了裁决规则（可自裁决），后者是文件真出了错（须质询）。
2. 裁决方向取文件规则，而非"取更严格者"：不得凭经验默认"从严准备"替代文件明示的效力顺序。仅在无任何规则时，才可提示"按更严格口径准备以规避风险"并同时质询。
3. 层级差异 ≠ 冲突："实质性最低门槛"与"评分加分门槛"（如"质保≥12个月"是硬性底线，"质保≥2年得分"是评分项）属不同维度，不构成冲突，分别如实列出。
4. 裁决过程留痕：报告中写明"冲突双方 → 适用规则 → 结论"，保证可回溯。

---

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

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

4.1 评分分值验证

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

4.2 关键数据交叉验证

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

4.3 完整性检查

• 供应商须知附表的每一行是否都已提取（份数、密封、付款等）
• 评分细则表的每一行是否都已提取
• 响应文件格式中的每个附件是否都已列出
• ★标注的必须提供文件是否完整列出
• 采购需求章节的每一个子章节是否都已提取（对照招标文件目录逐一核对，确保无遗漏。特别检查：系统性能需求、数据资源需求、接口需求等易遗漏章节）
• 功能需求中是否存在"未提供详细需求""无详细参数""详见原文"等占位符（如有则说明提取不完整，必须回到原文补充）
• 格式文件与封面格式是否已提取（对照以下清单）：
  • 每册封面格式已逐行提取（字段名称、行数、顺序与原文一致）
  • 已识别采购类型术语（军队/政府），封面字段名与原文一致
  • 所有格式表格已列出列结构（列名与原文一致）
  • 技术要求响应表等格式表格的特殊禁止条款已提取并加粗标注（如"原文照抄=无效报价"）
  • 4个必填索引表（资格证明文件索引表/符合性审查索引表/商务评审索引表/技术评审索引表）均已列入格式文件清单，且标注"未填写=无效报价"

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 ---