--- slug: "标书查重专家bid-dup-check" source_type: "clawhub" source_url: "https://clawhub.ai/skills/bid-dup-check" repo: "" source_file: "description" --- --- name: bid-dup-check display_name: 标书查重专家 version: 1.1.0 description: 标书查重与围串标风险初筛助手。当用户上传多份投标或招标文件需要检测文本雷同、关键信息（公司/电话/项目经理/造价师等）碰撞、文档属性一致、表格相似或两份文档差异比对时使用。基于大模型语义比对，输出含风险等级与定位的结构化检测报告，并支持导出 Word。适用于投标人自检与招标人初步筛查，不适用于评标委员会正式判定。 author: 一线评标专家&ChesaraM agent_created: true --- # 标书查重专家（bid-dup-check） ## Overview 将主流标书查重 / 围串标检测能力封装为轻量化专家技能（标书查重专家），实现「上传文件 → 自动解析 → 风险检测 → 结构化报告」的闭环。核心定位是**标书风险快速初筛助手**，而非专业查重系统：用大模型做语义比对与实体抽取，用脚本做确定性的文档解析与报告渲染，避免重计算与自建向量库。 适用：投标人自检、招标人初步筛查。不适用：评标委员会正式判定。仅支持中文标书。 > 本 Skill 是「给 AI 智能体的行为准则」，而非「给工程师的 SOP」。下面的每一步都同时规定**做什么 + 怎么想 + 怎么输出 + 出错怎么办**；核心推理（Step 4）的 Schema 已内联，不依赖你"去读外部文件才能知道字段"。 ## When To Use 出现以下意图时触发本 Skill： - 「检查这几份标书有没有雷同 / 抄袭」 - 「这几份投标文件是不是串标 / 围标」 - 「对比两份标书，标出增删改」 - 「生成标书查重检测报告」 - 用户上传 2–10 份 `.docx` / `.pdf`（含文本层）/ `.txt` 标书，并要求查重或风险检测 未触发时勿主动调用。 ## Environment & Dependencies（P3-1 修订：版本与自动检测） 脚本运行于 WorkBuddy 托管 Python 环境。执行前**先自动检测依赖是否就绪**： - `Python >= 3.9` - `python-docx >= 0.8.11`（docx 解析与报告生成） - `pypdf >= 3.0.0`（pdf 文本与元数据） 检测与安装方式（用托管 Python 的 pip）： ```bash python -c "import docx, pypdf; print('deps ok')" || pip install python-docx pypdf ``` 若导入失败，先安装再继续。若依赖安装失败，给出替代方案：提示用户将文档转为 `.txt` 后重新上传（`.txt` 仅需标准库即可解析）。 提取脚本会一并导出 docx 内嵌图片到 `extracted_images/` 目录，供视觉 OCR 使用。 ## Path Resolution（P2-1 修订：路径变量规范化） 执行任何脚本前，必须先确定两个真实路径变量（**严禁在命令中保留尖括号 `< >` 占位符**）： - `SKILL_DIR`：本 Skill 的根目录绝对路径，即本 `SKILL.md` 所在目录。其下的 `scripts/` 即脚本目录。 - `WORKSPACE`：当前会话的工作目录绝对路径，即用户上传文件所在目录（用 `pwd` 获取）。 命令模板（将 `[...]` 整体替换为真实绝对路径后再执行）： ```bash python "[SKILL_DIR]/scripts/extract_documents.py" \ --files "[FILE1]" "[FILE2]" \ [--bidding "[TENDER]"] \ --out "[WORKSPACE]/extracted.json" ``` > 若不确定 `SKILL_DIR` 的真实位置，可在本会话中用文件检索定位 `scripts/extract_documents.py` 的真实绝对路径后代入。绝不要把字面量 `` / `<工作目录>` 当作命令参数传给 Shell。 ## Workflow ### Step 1 — 收集文件 + 启动确认（P2-2） 向用户确认待检测的投标文件（2–10 份）。若用户希望排除「大家都照抄招标文件」造成的误报，可一并收集招标文件用于基线剔除。 输入约束：单文件 ≤ 50 MB；格式 `.docx` / `.pdf`（文本层）/ `.txt`。扫描版 PDF 若无文本层，当前环境 OCR 默认不可用，需在报告中标注限制。 **收到文件后立即回复启动确认**（P2-2）： > 已收到 N 份文件：[文件名列表]。正在进行文档解析，预计需要 X 分钟…… 估算规则（供填 X 参考，不要求精确）：总段落数 ≤ 100 → 约 1–2 分钟；100 < 总段落数 ≤ 300 → 约 3–5 分钟；> 300 → 约 5–10 分钟；若含扫描件 OCR，每张图片额外增加 5–10 秒。 仅上传 1 份文件时：提示至少需要 2 份才能比对，并询问是否仅做单文档结构分析（此时只输出结构概览，不做碰撞检测）。 ### Step 2 — 提取结构化内容 运行提取脚本，将文档转为统一 JSON（路径按上文 Path Resolution 规范处理）： ```bash python "[SKILL_DIR]/scripts/extract_documents.py" \ --files "[FILE1]" "[FILE2]" \ [--bidding "[TENDER]"] \ --out "[WORKSPACE]/extracted.json" ``` **进度反馈**：解析完成后简要告知： > ✅ 文本提取完成，共解析 N 个段落 / M 份文档。 输出 JSON 含每份文档的段落、表格、元数据与图片路径。若 `extracted.json` 中出现 `errors` 或文档 `warnings`（如 PDF 无文本层），按 Step 6 的错误处理策略处理。 ### Step 3 — 图片 / 扫描件处理（P1-3 修订：OCR 职责澄清） ⚠️ 本步解决原文档的矛盾：原 Step 3 说"用视觉能力做 OCR"，Notes 又说"OCR 默认不可用"，导致职责不清。职责归属如下： 3.1 检查 `extracted.json` 中每个文档的 `char_count`：若某文档文本量极少（< 100 字/页）但图片极多 → 判定为扫描件。 3.2 若你**具备视觉多模态能力**： - 对 `extracted_images/` 下该文档的图片逐张进行 OCR 文字提取； - 将识别文字作为「伪段落」补回该文档文本，并在来源中标注 `source: vision_ocr`； - 每张图片处理后简要告知用户进度。 3.3 若**无视觉能力或 OCR 不可用**： - 跳过该图片； - 在最终 findings 的 `limitations` 中记录：`文档 [文件名] 含 N 张图片/扫描页，未提取文字，风险检测覆盖率不完整`。 ⚠️ 严禁对图片做图像哈希或 Logo 比对，本 Skill 仅聚焦图片中的**文字内容**（如 Logo 上的文字、资质证书编号）。 ### Step 4 — 语义分析与碰撞检测（LLM 核心推理环节 · 内联 Schema + 思维链） ⚠️ 本步骤是整个 Skill 的核心，必须严格按子步骤顺序执行，不得跳过。`references/detection_rules.md` 含敏感字段与补充规则的详细说明，**可在需要时通过文件读取工具查看**；但本步内联的字段清单、定级标准与输出 Schema 为**唯一权威**——两者冲突时一律以本步为准，不得自行增删字段。 **4.0 前置分流（应对长文档）** - 统计 `extracted.json` 中所有文档的总段落数 `total_paragraphs`； - 若 `total_paragraphs ≤ 200`：直接进入 4.1 全量比对； - 若 `total_paragraphs > 200`：先执行**摘要阶段**——每份文档生成章节级摘要（格式：`{"chapter": "技术方案", "key_entities": ["张三", "1000万"], "data_points": ["工期365天"]}`）；仅对摘要中命中敏感字段或高度相似的章节进入 4.3 精比；未命中的章节在报告中标注「摘要阶段未命中，未进入精比」。 **4.1 实体归一化与敏感字段清单**（降噪前置 + 字段内联，避免依赖外部文件） 先对齐本步检测的敏感字段清单（确定性与一致性以此为准，不得自行增删）： `公司名称 / 公司简称`、`项目经理`、`造价师`、`联系电话`、`邮箱`、`开户行与账号`、`法人 / 授权代表`、`注册地址`、`统一社会信用代码`。 实体归一化： - 公司名称模糊匹配：`中建三局` = `中建三局集团有限公司`； - 人名去注释：`李四（项目经理）` → `李四`； - 数字统一：`10年` = `十年` = `10 年`。 **4.2 基线剔除**（关键降噪，P0 采纳） - 若提供了招标文件（`--bidding`）：雷同文本**同时出现在招标文件和 ≥2 份投标文件中** → 标记 `baseline`，`level` 设为 `低`，`reason` 注明「该段文本源自招标文件第 X 章，属正常引用」； - 仅计算**投标文件之间独有**的雷同； - 若未提供招标文件：直接互比，并在 `limitations` 注明「未启用基线剔除，存在基线误报可能」。 **4.3 风险检测**（按优先级执行，低成本高价值优先） 1. 关键信息碰撞（人员 / 资质 / 地址 / 联系方式） 2. 文档属性比对（作者 / 最后作者 / 公司 / 创建修改时间） 3. 文本语义相似度（仅针对粗筛命中的段落，见 Context Management） 4. 表格结构相似度（报价表 / 清单表） **4.3.5 差异比对（仅当投标文件数 = 2 时触发）** - 若用户上传的投标文件恰好为 2 份，执行段落级 diff（增 / 删 / 改）； - 若文件数 > 2，跳过 diff（避免组合爆炸），并在 `conclusion` 或 `limitations` 中说明「文件数超过 2 份，差异比对暂不适用，建议两两单独比对」。 **4.4 相似度定级标准（P0-2 修订：定性锚定，替代"感觉分数"）** | 等级 | 代表 score | 定性特征（满足任一即判定） | 示例 | |------|-----------|--------------------------|------| | 高 | 0.90 | 连续 50 字以上完全相同；或仅替换公司名称其余逐字一致；或核心句子相同且多个关键数据（单价/工期/编号）完全一致 | 技术方案整段逐字复制 | | 中 | 0.60 | 表述逻辑/结构一致但句式与用词有明显调整（同义改写）；或表格结构一致但数据有细微变化；或最后作者相同/创建时间高度接近 | "具有10年经验" vs "拥有十年工作经验" | | 低 | 0.30 | 仅个别通用术语或招标原文重合；非核心字段雷同 | 行业套话"根据招标文件要求" | 场景修正规则： - 技术方案章节：整体下调一档（行业术语趋同属正常）； - 商务报价章节：整体上调一档（报价格式趋同属正常）； - 通用条款 / 法律法规引用：直接标记 `低`，不计入风险。 **输出要求**：每条 `text_similarity` 必须含 `level`、`score`（取上表对应档位代表值）、`reason`（解释定级依据的定性特征）、`type`（直接复制 / 同义改写 / 结构相似）。 **4.5 强制输出 Schema（严格按此输出，禁止增删顶层字段）** ```json { "overview": { "file_count": 2, "risk_total": 5, "high_risk_count": 2, "avg_similarity": 0.42, "summary": "一句话概述" }, "key_info_collisions": [ { "field": "项目经理", "value": "张三", "files": ["a.docx", "b.pdf"], "locations": ["a.docx 第12段", "b.pdf 第8段"], "level": "高", "reason": "两家投标文件的项目经理为同一自然人" } ], "text_similarity": [ { "file_a": "a.docx", "file_b": "b.pdf", "score": 0.90, "level": "高", "type": "直接复制", "reason": "连续三段落结构完全一致，且关键数据相同", "segments": [ {"text": "（前50字）……", "location": "a.docx 第X段 / b.pdf 第Y段"} ] } ], "attribute_warnings": [ { "file": "a.docx", "level": "高", "fields": {"author": "张三", "company": "XX"}, "detail": "作者/公司相同", "reason": "不同投标方文档的作者元数据相同" } ], "table_similarity": [ { "file_a": "a.docx", "file_b": "b.pdf", "level": "中", "detail": "表格结构相似", "reason": "报价表行列结构一致，仅单价尾数不同" } ], "diff": [ {"type": "add|delete|change", "file_a": "a.docx", "file_b": "b.pdf", "content": "……"} ], "limitations": [ "文档 c.txt 含 N 张扫描页未提取文字，覆盖率不完整" ], "baseline_note": "已使用招标文件做基线剔除", "conclusion": "综合建议文本" } ``` `level` 取值仅限 `高` / `中` / `低` 三选一；`score` 取 4.4 表对应档位代表值；`baseline_note` 未启用时为 `null`；`conclusion` 必填。 **4.5.1 `limitations` 字段填充规则（合并以下来源，去重后输出字符串数组）** - 来自 `extracted.json` 中各文档的 `warnings`（如「PDF 无文本层」）； - 来自 Step 3.3 的 OCR 跳过记录； - 来自 Step 6 错误处理中「部分文件解析失败」的记录； - 若未提供招标文件，追加：「未启用基线剔除，招标文件原文片段可能被误报为雷同」； - 若某文档总字数 < 500 且图片占比 > 50%，追加：「[文件名] 疑似扫描件，文字覆盖率低，检测结果参考价值有限」。 **4.6 自检清单（输出前必须逐项确认）** - [ ] 所有 `level` ∈ {高, 中, 低} - [ ] 所有文件路径与 `extracted.json` 中的 `filename` 完全一致 - [ ] 无风险的部分输出空数组 `[]`，**严禁省略该字段** - [ ] 每条 finding 都含 `reason` 字段 - [ ] `overview.risk_total` / `high_risk_count` 与各数组长度一致 - [ ] `limitations` 已记录解析失败 / 扫描件未识别等覆盖缺口 确认无误后，将 JSON 写入 `[WORKSPACE]/findings.json`。 ### Step 5 — 渲染报告 将 `findings` JSON 写入文件后渲染报告（路径按 Path Resolution 规范）： ```bash python "[SKILL_DIR]/scripts/build_report.py" \ --findings "[WORKSPACE]/findings.json" \ --out "[WORKSPACE]/标书查重报告.docx" \ [--markdown "[WORKSPACE]/标书查重报告.md"] ``` **结果交付（三层递进，P2-2）**： 1. 3 句话风险摘要（如："检测到 2 处高危雷同、1 处关键人员重叠，建议重点关注技术方案章节"）； 2. 结构化详细报告（先展示 Markdown，再提供 `.docx` 下载）； 3. 文件下载链接。 报告须含七部分：检测概览 → 一、关键信息碰撞 → 二、文本语义相似度 → 三、文档属性预警 → 四、表格内容相似度 → 五、差异比对 → 六、综合结论与建议 →（附）限制与免责声明。 所有对外生成内容（对话摘要、Markdown 报告、docx 报告）**末尾必须自动附统一署名与反馈脚注**（由 `build_report.py` 渲染，护栏铁律级，不可省略）：「署名：一线评标专家&ChesaraM ｜ 反馈/交流：微信公众号「一线评标专家」（使用问题、误报反馈、实务建议，欢迎留言交流）」。 **追问支持（P2-2）**：用户可针对任意一条 finding 追问。**定位原文时回读 `extracted.json` 中对应文档该段落前后各 1–2 段作为上下文展示**，而非仅依赖 `segments` 中的截取片段；若 `segments` 的位置信息（如「第 12 段」）不明确，用关键词在原文中模糊搜索回补。同时解释定级理由、建议进一步核实方向。 ### Step 6 — 边界、错误处理与免责声明 在对话或报告末尾说明：本 Skill 为初筛/辅助工具，不替代专业查重系统或法律判定；高利害场景须人工复核。不承诺「100% 检出」或「绝对判定围串标」。 **错误与降级处理（P1-1，异常不得静默退出）**： | 异常场景 | 处理策略 | |----------|----------| | 文件格式不支持 | 提示用户转换格式，列出支持清单（docx/pdf/txt） | | 文件损坏 / 加密 | 标记该文件「无法解析」，继续处理其余文件，报告中注明 | | 提取内容为空（疑似扫描版） | 提示可能是扫描版 PDF，建议提供文本版或启用视觉 OCR | | 脚本执行超时 | 建议减少文件数量或拆分处理 | | 依赖安装失败 | 给出替代方案：提示用户将文档转为 `.txt` 后重新上传 | | 仅上传 1 份文件 | 提示至少需 2 份才能比对，询问是否仅做单文档结构分析 | | findings 为空 | 报告正文写「未发现显著围串标特征」，仍渲染报告骨架（概览 + 免责声明） | | 部分文件解析失败 | 在 `limitations` 记录，报告中标注覆盖率不完整 | 通用原则：脚本报错时立即终止后续脚本执行，读取 stderr，用通俗语言向用户解释；任何步骤失败都必须给出明确反馈，不得静默退出。 ## Resources ### scripts/ - `extract_documents.py` — 从 docx/pdf/txt 提取段落、表格、元数据、内嵌图片路径，输出统一 JSON（含 errors/warnings）。 - `build_report.py` — 读取 findings JSON，渲染 docx（及可选 markdown）检测报告，安全展示 reason/type/limitations。 ### references/ - `detection_rules.md` — 敏感字段清单、风险等级、相似度定性评分锚点、基线剔除规则、报告 schema 与免责声明。作为 Step 4 的补充参考（Step 4 内联 Schema 为唯一权威）。 ## Context Management Strategy（P1-2） 标书篇幅长、多份两两比对时上下文压力大。提取脚本已将文档结构化为 JSON，分析在 JSON 上进行；额外策略： - **段落切分**：按文档标题层级切分，每段 ≤ 500 字；无标题时按 300 字滑窗切分（重叠 50 字）；表格作独立单元不拆分。 - **分批（文档总段落数 > 200 时）**：先摘要后精比两阶段 —— 阶段一（粗筛）每份文档生成结构化摘要（章节标题 + 关键实体 + 数据点）；阶段二（精比）仅对摘要中标记高相似的章节逐段精比。 - **比对优先级**：关键信息碰撞（低成本高价值）→ 文档属性比对（零成本）→ 文本语义相似度（高成本，仅精比命中段落）→ 表格相似度。 ## Interaction Protocol（P2-2 汇总） - 启动确认：收到文件即回复「已收到 N 份文件……预计 X 分钟」。 - 进度反馈：每完成一步简要告知（✅ 文本提取完成 / 正在进行语义比对（第 2/5 组）/ 分析完成，正在生成报告）。 - 交付：3 句话摘要 → 结构化报告 → 下载链接。 - 追问：对任意 finding 回读 `extracted.json` 原文上下文（前后各 1–2 段）、解释理由、给核实建议。 ## Privacy & Security（P2-3） - 所有文件仅在当前会话中处理，不持久化存储于 Skill 外部。 - 处理完成后，提示用户清理工作目录临时文件（`extracted.json`、`extracted_images/`）。 - 不将标书内容用于模型训练或任何二次用途。 - 报告中涉及个人信息（身份证号、手机号）时脱敏展示（如 `138****5678`）。 - 若检测到文件中含明显敏感信息，主动提醒用户注意。 ## Notes & Limitations - 不纳入 Skill 的能力：图片感知哈希、大规模自建库查重、专业逐字/LCS 算法、人工审核工作流、硬件/系统级报告操作（刻录/打印）。 - 扫描版 PDF OCR：依赖视觉多模态能力；若无能力则跳过并在 `limitations` 标注（见 Step 3）。 - 上下文限制：单次 2–10 份常规标书；过多会导致上下文过长、成本与响应时间上升（见 Context Management）。 ### 报告结构摘要（P3-2） 1. **检测概览**：文件清单、检测时间、总体风险等级、平均相似度。 2. **关键信息碰撞**：人员 / 资质 / 地址等硬指标重叠。 3. **文本语义相似度**：按风险等级排序的段落对比（含 reason/type）。 4. **文档属性预警**：作者 / 修改时间 / 软件版本等。 5. **表格内容相似度**：报价表 / 清单表结构对比。 6. **差异比对（可选）**：两两文档差异摘要。 7. **综合结论与建议**：含限制说明与免责声明。 --- **署名**：一线评标专家&ChesaraM ｜ **反馈/交流**：微信公众号「一线评标专家」（使用问题、误报反馈、实务建议，欢迎留言交流）