投标文件符合性检查

技能文档

---
name: telehot-bid-compliance-check
title: 投标文件符合性检查
category: 招投标采购
description: 投标文件符合性检查技能，用于检验投标文件是否满足招标文件要求，排查废标风险并输出符合性检查报告。当用户要求检查、审查、核对、体检投标文件或标书，比对招标文件与投标文件，排查废标项、符合性问题、响应遗漏或评分点缺失，生成响应矩阵、问题清单或整改清单时使用。输入前提以用户上传的文件为准：只上传招标文件、要求解析/提炼招标文件时，仅执行招标文件解析（要求清单、废标条款、评分办法、关键时间节点），不做符合性判定；上传了招标文件与投标文件两者时才执行符合性检查；若用户只上传投标文件、没有招标文件，则不要执行本技能，应友好提示用户——符合性检查需要招标文件和投标文件两份文件一起比对，请补齐招标文件后再试。支持 .docx/.pdf(含扫描件识别提示)/.xlsx/.md/.txt，产出 HTML 报告。触发词包括 标书检查、投标符合性、废标项、响应性审查、偏离表、评标办法、清标、招标文件解析。
---

# 投标文件符合性检查

## Overview

把一份投标文件与招标文件逐条对标，找出会导致废标的问题、响应遗漏、评分点缺失与内部矛盾，
输出可派活的整改清单。核心交付不是"读后感和建议"，而是**每一条结论都能指向具体条款和具体页码**。

检查分两层：机器负责客观可复现的机械检查，模型负责语义比对与评分点判断。两层结果合并后统一出报告。

**输入决定模式（先看用户手上有什么文件，再决定跑不跑）**：
招标文件 + 投标文件齐全 → 完整符合性检查（阶段 0–6）；
只有招标文件 → 招标文件解析模式（仅解析、不做响应性判定，见阶段 0 分支说明）；
只有投标文件 → **不执行本技能**——不提取、不比对、不出任何报告，友好提示补齐招标文件；
两份都没有 / 文件打不开 → 同样不执行，友好说明需要哪些文件。
和用户怎么开口，见下方「与用户沟通」。

## 安全与保密约束

标书属于商业敏感材料，处理全程守住三条底线，任何环节都不得越过：

1. **不联网**：文件解析、条款核验、报告生成全部在用户本机完成，不把标书内容发送给任何外部
   服务或在线接口。扫描件没有文本层时，请用户提供可复制文字的版本，或由用户在本地自行做 OCR
   （例如本地安装的 OCR 工具），不要建议把文件交给在线 OCR、云转换等外部服务代处理。
2. **不臆造**：解析不到评分办法、分值权重、废标条款或某项要求时，如实记录为"未识别到"，
   在报告中如实呈现并提示用户补材料核对。**严禁为"显得完整"而编造分值、权重或条款内容**——
   编造的数值会直接误导得分预估与废标判断，宁可缺失，不可虚构。
3. **经验私有**：从源文件到提取的 JSON、中间结果与报告草稿，一律只写入用户当前的本地工作目录
   （脚本 `--out-dir` 指向的本地目录），不另存到云端、不同步到任何共享位置、不写入系统缓存目录。
   会话或工具关闭后，全部产物仍留在用户自己机器上，随时可取用。

第 2 条在评分点覆盖与得分预估、否决条款章节的具体落地口径，见下文对应阶段说明与「边界」一节。

## 与用户沟通（语气与开场）

和用户沟通时像一位专业又热心的同事：先回应，再说明「我打算做什么、还差什么、会给到什么结果」，
语气温和自然。避免一上来甩结论、连串追问，或"无法满足要求"式的生硬回绝。

**文件齐全，准备跑完整检查**：
> 收到！我会把招标文件里的资格、商务、技术、评分要求逐条拉成清单，再对照投标文件
> 重点找"容易废标、丢分"的地方，最后给您一份带整改清单的检查报告。

**只有招标文件，自动进入解析模式**：
> 目前只看到招标文件，没问题～ 我先帮您做「招标文件解析」：把投标资格、废标条款、
> 评分办法、关键技术要求和几个关键时间节点提炼成清单（这一步不做符合性判定）。
> 这份清单会保留下来，等投标文件就绪再上传，就能在同一条清单上直接做完整检查，不用重复解析。

**只给了投标文件、没有招标文件**（本技能不运行，按此口径说明，不要开展任何检查步骤）：
> 我注意到您上传的是投标文件《…》，不过还没看到对应的招标文件。符合性检查需要把
> 「招标文件」和「投标文件」放在一起比对才成立——只有一份投标文件，没法判断它是否满足
> 招标要求。麻烦您把该项目的招标文件也上传一下，我会马上为您逐条核对并出报告～

**什么文件都还没有 / 文件打不开**：
> 还没收到可以检查的文件哦。核对一个项目需要同项目的「招标文件 + 投标文件」两份文件
> （.docx / .pdf / .xlsx / .md / .txt 均可，PDF 优先提供可复制文字的版本）。
> 把文件发给我，我先帮您确认检查范围。

**需要补充信息时**（投标人全称、项目类型、截止时间等）：把要问的问题**打包成一次提问**，
并说明为什么需要、缺了会有什么影响，不要逐条轰炸。

## 依赖安装

首次使用时检查依赖，缺什么装什么。**必须安装到隔离虚拟环境（venv），不要直接 pip 装到全局**。

**pip 安装优先走国内镜像源（默认清华源）**，下载更快也更稳；用户在国内网络环境时不要直接走官方 PyPI：

```bash
# Windows
python -m venv .venv
.venv/Scripts/pip install -i https://pypi.tuna.tsinghua.edu.cn/simple python-docx openpyxl pdfplumber

# macOS / Linux
python3 -m venv .venv && .venv/bin/pip install -i https://pypi.tuna.tsinghua.edu.cn/simple python-docx openpyxl pdfplumber
```

清华源不可用或超时时，依次换用阿里云（`https://mirrors.aliyun.com/pypi/simple/`）、
中科大（`https://pypi.mirrors.ustc.edu.cn/simple/`）等国内源，最后才回退官方 PyPI；

后续运行脚本时使用该 venv 内的解释器（如 `.venv/Scripts/python` 或 `.venv/bin/python`）。

`pdfplumber` 可用 `pypdf` 替代（表格提取能力弱一些）。仅生成 Markdown/HTML 时不需要 openpyxl。

## 技能工作流

### 阶段 0：确认前提

向用户确认（信息缺失则从文件名/正文推断，并在报告中注明假设）：

| 需要确认 | 用途 |
|---|---|
| 项目类型：工程施工 / 货物 / 服务 / 政府采购 | 决定适用法规体系与否决口径 |
| 投标人全称（与营业执照一致） | 名称一致性校验 |
| 投标截止时间 | 判断有效期、出具日期是否合理 |
| 纸质标 / 电子标 | 是否启用电子投标专项检查 |
| 全量体检 / 只看废标项 | 决定输出详略 |

招标人、代理机构、预算/最高限价、截止与开标时间等**不要逐项追问用户**——
这些在阶段 2 从招标文件自动提取；仅当文件中确实缺失时才向用户确认。

**若用户只给了投标文件、没有招标文件**：**不执行本技能**——不做任何提取、比对，
也不运行任何脚本、不产出任何报告。仅凭一份投标文件无法判断它是否满足招标要求；
按上方「与用户沟通」中的话术，友好说明需要同项目的招标文件一起上传，请用户补齐后再继续。

**若用户只给了招标文件、没有投标文件**：进入「招标文件解析模式」——只解析招标文件，**不做任何
符合性/响应性判定**。执行路径为阶段 1（仅提取招标文件）→ 阶段 2（要求清单 R +
`meta` / `timeline` / `focus_clauses` / `tech_spec` / 评分项基础信息 / `unrecognized`）→
阶段 6（`build_report.py --mode tender`，产出「招标文件解析报告」）。阶段 3–5 一律跳过。

招标文件解析模式下的要点：

- 评分项只抽取 `item / nature / max_score / basis`（评分规则与依据），`est_range / risk / bid_ref`
  留空——没有投标文件就没有估算与风险可言
- 招标文件**自身的**跨章节矛盾（G2/G3，如工期/质保在不同章节口径打架）仍属于解析产物，
  可列入 findings（问题清单），这是给用户的澄清线索
- 告知用户：本次解析产出的要求清单 R 可复用，投标文件就绪后直接继续跑阶段 3–5 完成完整检查
- **不得**因为"没有投标文件可比对"就把解析报告写成检查报告——两份报告的标题、结论口径完全不同

### 阶段 1：提取与结构化

所有中间产物放在 `投标符合性检查-<项目简称>/` 目录下。

```bash
python scripts/extract_text.py 招标文件.pdf 投标文件.docx --out extracted.json
```

扫描件 PDF 会在输出中标记 `needs_ocr`，此时友好地请用户帮忙：
"这份 PDF 看起来是扫描件，文字是图片形式、暂时无法检索，为避免误判，
麻烦提供可复制文字的版本（如 Word 原件），或先对文件做一次 OCR，拿到可检索版本后我马上继续。"
**不要基于空文本层下"未响应"的结论**。

看骨架（先做这一步，判断是否有整块章节缺失）：

```bash
python scripts/extract_text.py 投标文件.docx --mode outline
```

精确定位关键词（可反复用，避免整本读进上下文）：

```bash
python scripts/extract_text.py 投标文件.docx --search "业绩|类似项目|已完成项目" --context 100
python scripts/extract_text.py 招标文件.pdf --search "否决|无效|实质性|必须|不得" --context 60
```

大文件用 `--mode text --max-chars 50000` 分段读局部原文。

### 阶段 2：抽取招标文件要求条目

建立要求清单 R，每条含：`编号 | 类型(资格/商务/技术/评分/形式) | 强制性 | 条款原文摘要 | 出处(章节+页码) | 所需证明材料`。

优先解析：**投标人须知前附表** → **评标办法（含符合性审查表、打分表）** → **资格要求** →
**技术需求书（★▲实质性条款）** → **合同条款（付款/工期/质保）** → **投标文件格式（必备附表清单）**。

同步抽取三类结构化信息（来源：招标公告 / 封面 / 前附表 / 评标办法 / 技术需求书）：

- **基本信息** → `meta`：招标编号、招标人、代理机构、项目类型、预算/最高限价、
  投标方式（纸质/电子）、投标截止与开标时间、投标有效期
- **时间节点** → `timeline`：公告发布、澄清/答疑截止、投标截止/开标、
  投标有效期届满、合同签订期限
- **否决条款与无效投标情形** → `focus_clauses`：无效投标情形（否决条款）、围标串标审查条款、
  特殊限制条件（联合体、进口设备、分包限制等）
- **技术需求与实质性条款** → `tech_spec`：需求清单、技术指标参数、★实质性条款标记、遵循标准/规范

遇到**无法归入已知类别**（资格/商务/技术/评分/形式）的条款，记录原文片段与位置，存入
`unrecognized` 数组，最终进入报告附注——**不得因无法归类而静默丢弃**；条款引用未随附的
外部附件时标"存疑"，不得直接判"未响应"。

读 `references/methodology.md` 的阶段 2–3 获取抽取细则与判定陷阱。

### 阶段 3：逐条判定

对 R 中每条给出五选一：`已响应 / 部分响应 / 未响应 / 不适用 / 存疑`，
每条附投标文件位置与原文摘录。

关键判定规则（完整版见 `references/methodology.md`）：

- **偏离表空白 ≠ 无偏离**，通常视为全部满足，事后查出不符升级为虚假响应
- **承诺函不能替代法定证书**（资质、安全生产许可、人员注册证）
- **检索不到 ≠ 未响应**，换同义说法再检索一轮（业绩/类似项目/工程实例；质保期/保修期/质量保证期）
- **内部矛盾优先**：即便逐条都响应，工期/金额/名称前后打架仍单独列严重问题
- **跨章节条款冲突**：同一主题（工期、质保、付款、有效期）在招标文件不同章节口径不一致时，
  按效力优先级（前附表/专用条款 > 通用条款）判定并提示向招标人澄清，投标只响应了其中一个版本判"存疑"

### 阶段 4：评分点覆盖

从评标办法打分表抽取每个评分项，检查投标文件是否有**评审专家能一眼找到的**对应内容。
标记 `零分风险 / 失分风险 / 可争取`，给出保守得分估算（必须标注为估算，不给精确分数）。

### 阶段 5：机械一致性检查

```bash
python scripts/check_consistency.py --extracted extracted.json --bidder "某某建设有限公司" --out consistency.json
```

覆盖：大小写金额不一致、工期/有效期/报价前后矛盾、占位符与模板残留、签字盖章位为空、
公司名称不一致、证照有效期过期、项目编号名称不一致、页眉页脚为空。

**脚本结果必须人工复核后再定级**——引用招标文件原文会造成数值冲突误报。

已观察到的高频误报（直接按此复核，别重复踩坑）：

| 误报类型 | 典型表现 | 处置 |
|---|---|---|
| 证照有效期 | 把制造商营业执照的"成立日期/营业期限起"当成投标人证照有效期，报"已过期" | 先看该页归属主体，非投标人证照一律排除 |
| 相似单位名称 | 业绩表中的不同客户名称被判为"公司名称不一致" | 排除，属正常多主体 |
| 项目编号不一致 | 正则贪婪匹配把前后文（如"）采购的招标公告"）一起截断 | 排除，属切分噪声 |
| 占位符 | "待确认"出现在流程描述正文而非待填位 | 从 major 降为 minor |

### 阶段 5b：电子签章检测（PDF 投标文件必做）

招标文件通常明文列举"必须加盖公章并签字"的文件（投标函、开标一览表、法定代表人授权委托书、
各类响应表等），未盖章或盖章但未签署即投标无效。**电子版是否为"正本签章后的完整扫描件"
是最高优先级的致命项**，必须用 pdfplumber 取证，不能靠肉眼翻页印象：

```python
import pdfplumber
with pdfplumber.open(bid_pdf) as p:
    for i in targets:                      # 1-based PDF 页码
        pg = p.pages[i-1]
        area = sum(max(im['x1']-im['x0'],0) * max(im['bottom']-im['top'],0)
                   for im in pg.images)
        cover = area / (pg.width * pg.height) * 100
        colors = {(c.get('non_stroking_color') or (0,0,0)) for c in pg.chars}
        print(f'P{i}: 图片{len(pg.images)} 覆盖{cover:.1f}% '
              f'curves={len(pg.curves)} 颜色={colors}')
```

判定规则（三条同时成立才可下"无签章"结论）：

1. 图片覆盖率 = 0.0% → 页面由数字生成，没有扫描进去的印章/签名图像
2. `len(pg.curves)` = 0 → 没有矢量签章图形
3. 字符颜色集合只有纯黑 `(0.0, 0.0, 0.0)` → 没有红色印章文字

补充动作：

- 对全文件跑一遍分页覆盖率，顺带得到"扫描件页数占比"，用于判断有多少页无文本层
- 若招标文件规定"纸质版与电子版不一致以电子版为准"，**纸质签章无法补正电子版的缺失**，
  必须在结论中写明这一点
- 下"无签章"结论的同时，必须提示用户先核对招投标平台上实际上传的 PDF 原件，
  排除签章在上传/导出/加密环节被技术性剥离的可能，再决定是否 fatal

### 阶段 6：合并与出报告

把语义判定结果（阶段 2–4）与脚本结果（阶段 5）合并成一个 JSON，
结构参照 `assets/findings_template.json`。

> **⚠️ 硬性要求（不可跳过）**：
> 1. 报告**必须**由 `scripts/build_report.py` 生成，**禁止手写 Markdown**。
>    检查完标书后自己拼一版 Markdown 是本技能最常见的出错方式——手写报告会
>    丢失报告结构规范（`references/output_guide.md`）要求的章节、脱敏、主观/客观分标注，
>    且结构与模板不一致。无论如何都不得绕过脚本。
> 2. merged JSON 必须包含 `findings_template.json` 里的**全部顶级字段**：
>    `meta / timeline / tech_spec / scoring / matrix / findings / focus_clauses /
>    unrecognized / conclusion`。
>    其中 `tech_spec` 从招标文件抽取后填充（阶段 2 已说明），**不得留空**——留空会导致对应章节被省略。
> 3. 生成后必须做「报告结构自检」（见下），确认 8 章 + 附注齐全再交付。

merged JSON 的完整结构与各字段示例**以 `assets/findings_template.json` 为准**（该文件含一份
可参照的填充示例）——不要凭记忆拼字段，避免与本文件内嵌示例产生漂移。

`severity` 取值 `fatal/major/minor/info`，`category` 取值
`资格性/符合性/响应完整性/评分点/内部一致性/形式要求`。定级标准见 `references/output_guide.md`。

生成报告：

```bash
python scripts/build_report.py --data merged.json --format html --out-dir . --name "投标符合性检查报告"
```

仅解析招标文件时（招标文件解析模式）加 `--mode tender`：

```bash
python scripts/build_report.py --data merged.json --mode tender --format html --out-dir . --name "招标文件解析报告"
```

此模式下报告主标题为 `# {项目名称} 招标文件解析报告`，结论口径为「解析结论」而非「检查结论」，
章节为：项目概况与解析信息 / 关键时间节点（按需）/ 技术需求与实质性条款（按需）/
评分办法与评分项（按需）/ 否决条款与无效投标情形（按需）/ **招标要求清单** /
问题清单（按需，仅收录招标文件自身问题）/ 附注（按需）。
merged JSON 中 `matrix` 填要求清单 R（`bid_ref` / `status` 留空），`scoring` 填评分项
（`est_range` / `risk` / `bid_ref` 留空），无响应矩阵与整改清单章节。

产出 `.html`（汇报）。
报告主标题为 `# {项目名称} 投标文件符合性检查报告`。Markdown / Excel 章节结构按
`references/output_guide.md`「报告结构」编排，依次为：
项目概况与检查信息 / 关键时间节点（按需）/ 技术需求与实质性条款（按需）/ 评分点覆盖与得分预估（按需，
含主观分/客观分标注与客观分合计）/ 否决条款与无效投标情形（按需）/ 响应完整性矩阵（按需）/
问题清单（🔴🟡🟢🔵 分级）/ 整改清单 /
附注：未识别条款与存疑内容（按需）。
检查结论置于报告头部（生成时间下方），而非独立章节。
正文中的身份证号（前6后4）、手机号（前3后4）由脚本自动脱敏；企业名称、金额、项目编号不脱敏。

**HTML 版目录结构与 md/xlsx 不同**（页面汇报优化；报告头 + 问题统计卡之后依次为）：
1. **废标问题清单**——全部问题概览表：问题序号 / 严重度 / 问题名称 / 问题详情，
   详情列为「详见 XX 章节」锚点链接
2. **强制性 / 资格 / 商务 / 技术 / 格式递交**——五个分类章节（仅在有对应数据时出现）：
   响应完整性矩阵按 `matrix.type` 归类拆分（强制/实质→强制性，资格/资质→资格，商务/报价/合同→商务，
   技术→技术，形式/格式/签章/递交→格式递交），各分类内矩阵表列为：
   # / 招标文件要求 / 出处 / 投标响应情况 / 状态 / 评分影响 / 备注；该分类下的问题详情卡片
   跟在矩阵表后；无法归入五类的要求/问题并入「其他」分类章节（按需出现）；
   评分类问题的详情链接指向评分章节
3. **评分点覆盖与得分预估**——与 md 版一致
4. **附注：未识别条款与存疑内容**——与 md 版一致

HTML 版不渲染关键时间节点 / 技术需求与实质性条款 / 否决条款与无效投标情形 /
响应完整性矩阵（已拆分入分类）/ 问题清单（已并入分类）/ 整改清单章节——这些内容仍完整
保留在 md / xlsx 版中，用户需要时引导其查阅对应格式。

**报告结构自检（出报告前逐项核对，缺一即退回补数据重跑脚本）**：

| 检查点 | 预期 | 不满足时 |
|---|---|---|
| 主标题 | `# {项目名称} 投标文件符合性检查报告` | 未用脚本生成，重跑 build_report.py |
| 报告头 | 含「检查结论」「生成时间」与「源文件」元信息 | 同上 |
| html 目录 | 废标问题清单 + 五分类章节（强制性/资格/商务/技术/格式递交，有数据时）+ 评分点覆盖与得分预估 + 附注，概览表每行「详见 XX 章节」可跳转 | 同上 |
| 脱敏 | 身份证/手机号已脱敏 | 核对 merged JSON 原文是否含明文敏感项 |

若自检发现章节缺失，优先排查 `tech_spec / focus_clauses / scoring / matrix` 字段
是否在 merged JSON 中留空——留空会触发"按需省略"。这些字段
**在货物/服务/工程采购中几乎总能从招标文件中抽取到**，留空通常是抽取遗漏。

上表自检仅适用于符合性检查模式；招标文件解析模式按阶段 6 描述的解析报告章节与标题口径核对
（标题必须是「招标文件解析报告」，结论必须是「解析结论」，且不得出现响应矩阵/整改清单章节）。

## 报告类型与多标书对比

| 类型 | 触发条件 | 内容 |
|---|---|---|
| 完整检查报告 | 招标文件 + 投标文件齐全（默认） | 全部章节 |
| 招标文件解析报告 | 只有招标文件、没有投标文件 | 要求清单 + 基本信息 / 时间节点 / 技术需求 / 评分办法 / 否决条款，无任何响应性判定 |
| 摘要报告 | 用户只要"看废标项" | 只保留基本信息、检查结论、致命/严重问题与整改清单 |
| 多标书对比 | 同一招标文件 + 多份投标文件 | 逐份检查后输出横向对比矩阵 |

> **不符合触发前提时没有报告**：只有投标文件、没有招标文件时，本技能不运行、不产出任何报告，
> 按「与用户沟通」话术请用户补齐同项目招标文件后再开始。

**多标书对比流程**（常见于招标方评标、代理机构清标、投标方自查多版本标书）：

1. 要求清单 R 只抽取一次，多份投标文件共享同一把尺子
2. 逐份执行阶段 1、3、4、5，各生成独立 merged JSON 与完整报告
3. 汇总输出对比矩阵（Markdown 表）：每行一个投标人，列出总报价、致命/严重问题数、
   要求响应率、客观分估算区间、资质与业绩概览
4. 用户提供多家投标人的文件时，先确认用途为评标/清标等合法场景；
   **不得用于协助围标串标或横向串通报价**

## 检查项清单

废标项与符合性审查的**完整枚举**（A 形式签署 / B 主体资格 / C 投标有效性 / D 实质性响应 /
E 电子投标 / F 低发致命疏漏 / G 横切检查）在 `references/eligibility_checklist.md`。
执行阶段 2–3 时必须逐项过一遍，不要凭印象挑几项。

## 输出规范

- 结论要敢下判断，禁止"基本符合要求，建议进一步完善"这类无信息量的表述
- 每条问题必须有：招标要求出处 + 投标文件位置 + 原文摘录 + 可执行的整改建议
- 拿不准的标"存疑"并写明需要什么材料才能定论，不猜
- 拿不准严重度时取低一级，在 `impact` 中写明升级条件

详细写作规范与免责边界见 `references/output_guide.md`。

## 边界

- 这是对标检查，不是法律意见；法规适用争议提示用户咨询律师或招标代理
- **不得**代用户编造、补齐投标文件的实质内容（业绩、资质、参数承诺）。
  可协助拟定承诺函等文本，但必须提示核实真实性后方可使用
- **不得**给出"保证中标""一定能过"的判断

## 交付与结束语（必须）

报告生成并预览后，**最终回复用户时必须包含以下三项内容，缺一不可**：

1. **报告文件路径**——明确告知用户报告文件保存在哪里（绝对路径或相对于用户工作目录的路径），并列出本次生成的`.html`文件叫什么、用什么方式打开（例如 `.html` 用浏览器打开、`.xlsx` 用 Excel/WPS 打开）
2. **下载/打开方式提示**——如果产物目录里有可直接下载的文件链接，给出指引；如果是本地路径，说明路径如何访问

模板示例（按实际情况替换路径与文件名）：

> 报告已生成完成，三份产物保存在 `投标符合性检查-<项目简称>/` 目录下：
> - `投标符合性检查报告-<项目简称>.html` —— 推荐用浏览器打开（可点击目录跳转、问题锚点）

## 资源

- `scripts/extract_text.py` —— 统一提取器（docx/pdf/xlsx/md），支持 outline / 全文 / 正则检索三种模式。
  `--search` 只对**原始文档**生效，对已提取的 JSON 检索会返回 0 命中；
  要检索已提取内容，先把 blocks 按 `page` 分组导出成带 `===== [第 N 页] =====` 标记的 txt，再用 Grep 搜
- `scripts/check_consistency.py` —— 内部一致性机械检查，输出结构化 findings
- `scripts/build_report.py` —— 生成 HTML 报告。默认 `--mode compliance` 生成
  投标符合性检查报告（8 章 + 附注：项目概况与检查信息、关键时间节点、技术需求与实质性条款、
  评分点覆盖与得分预估、否决条款与无效投标情形、响应完整性矩阵、问题清单、整改清单；
  检查结论置于报告头；Excel 多张表；身份证/手机号自动脱敏）；
  `--mode tender` 生成招标文件解析报告（仅解析招标文件时使用；未显式指定 tender 但数据中
  无投标文件且无问题时会自动切换）；Excel 多张表；身份证/手机号自动脱敏
- `references/eligibility_checklist.md` —— 废标项与符合性审查完整清单（A–G）+ 法定否决情形摘录
- `references/methodology.md` —— 要求抽取、逐条判定、评分点分析的方法论、判定陷阱、
  多标书对比流程与异常处理
- `references/output_guide.md` —— 严重度定义、报告结构、写作规范、免责边界
- `assets/findings_template.json` —— 合并结果的 JSON 模板

使用说明

# 投标文件符合性检查

把投标文件与招标文件逐条对标：找出废标风险、响应遗漏、评分点缺失与内部矛盾，输出每条都能指向具体条款和页码的整改清单。

## 使用

```text
帮我检查这份投标文件和招标文件，看看有没有废标风险。
只解析这份招标文件，提取资格要求、废标条款和评分办法。
对这两份标书做符合性比对，输出响应矩阵和整改清单。
```

只需招标文件解析时上传招标文件即可；做符合性检查需要招标文件与投标文件两份一起上传（支持 .docx/.pdf/.xlsx/.md/.txt）。

## 工作原理

机器负责客观可复现的机械检查，模型负责语义比对与评分点判断，两层结果合并出 HTML 报告：

0. **确认前提**：根据手头文件自动进入完整检查或解析模式
1. **提取结构化**：解析两份文件的文本内容
2. **抽取要求条目**：资格、商务、技术、评分、废标条款
3. **逐条判定**：响应性、偏离与矛盾点，指向具体页码
4. **评分点覆盖与机械一致性检查**（含电子签章检测）
5. **合并出报告**：问题分级清单 + 整改建议

全程本机完成、不联网、不臆造条款。

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。