小马哥标书检查助手（xiaomage-bid-checker）

Overview

对投标文件做递交前全面体检：输入招标文件（含技术要求、商务条款、评标办法）与投标文件，输出与既定结构一致的单文件 HTML 评估报告。全流程无需用户额外描述——识别到「招标文件 + 投标文件」组合即自动启动。

输入与输出

输入（满足其一即可启动）：
- 招标/谈判文件（PDF 或 DOCX；两者并存时以 PDF 为准——DOCX 可能与发布公告的 PDF 版本不一致）
- 投标文件（通常为一个文件夹内多份 PDF：报价表、投标函、封面、应答表、资质证照等）
- 若仅提供招标文件无投标文件：只执行招标文件解析（输出关键条款提取清单 + 检查要点预告）

输出：
- 投标文件核对评估报告-<项目简称>.html（单文件、内联样式、可离线打开，结构见 assets/report_template.html）
- 必须包含：总体结论横幅、废标风险清单（置顶）、八大维度逐项结果表、三张应答表逐参数左右对照明细、偏离清单、OCR 疑点复核清单、优化建议、核查方法局限说明

参数化配置（均可省略，有默认值）：
| 参数 | 默认值 | 说明 |
|---|---|---|
| 招标文件路径 | 工作空间内自动识别（含"招标/谈判/磋商/询价文件"字样的文件） | 以 PDF 为准 |
| 投标文件目录 | 工作空间内自动识别（含"投标文件"字样的目录） | — |
| 评标标准来源 | 招标文件第五章/评标办法章节 | 若用户另给评审细则则优先 |
| 临时目录 | <工作空间>/.workbuddy/tmp/ | Windows 无 /tmp，禁止用 /tmp |
| 报告输出目录 | 工作空间根目录 | — |

Workflow（六阶段流水线）

阶段 0：输入识别与版本裁定

1. 扫描工作空间，识别招标文件与投标文件目录（含子目录展开）。
2. 招标文件有 DOCX+PDF 两版时，全部以 PDF 版为核查基准并在报告中注明。
3. 列出投标文件清单（文件名+页数），与招标文件第六章「响应文件格式」附件清单一一对齐——缺一份即为风险项。

阶段 1：招标文件解析

1. 运行 scripts/extract_pdf_text.py <招标文件PDF> <tmp目录>/tanpan 提取全文。
2. 通读全文（分页读完，不可抽样），按 references/check_dimensions.md 第一节《关键信息提取清单》逐项提取：项目标识、预算/最高限价、采购方式与评标办法、资格条件、全部★实质性条款、符合性审查条款、格式附件清单、报价修正与异常低价规则、价格扣除政策、时间节点、保证金、核心产品等。
3. 将提取结果整理为核查基准清单（后续所有判定以此为据）。

阶段 2：投标文件提取

1. 运行 scripts/extract_pdf_text.py <投标文件目录> <tmp目录>/bid_files 批量提取。
2. 逐份通读文字层内容，记录每份文件的完整性、落款、签章栏、日期。

阶段 3：证照/图片页 OCR 核验

1. 识别文本层为空或极少的页面（证照扫描件、合同照片、证书图片）——这些页面约占证明材料的 80%，纯文本管线看不到。
2. 将待核页面写入配置 JSON（files: [{pdf, pages 或 range}]），运行：
   <venv>/python scripts/ocr_batch.py <配置JSON>
   依赖安装（首次）：pip install rapidocr_onnxruntime pymupdf 到隔离 venv C:/Users/<user>/.workbuddy/binaries/python/envs/default。
3. 逐页审阅 OCR 结果：核对证照主体名称与投标人一致、证件有效期覆盖服务期、经营范围覆盖标的需求、编号与正文引用一致。
4. OCR 识别不准的关键字段（证号/金额/日期/身份证号）列入「OCR 疑点清单」，标注文件+页码，报告中要求人工目视复核。
5. 铁律：红色印章无法通过 OCR 确认——报告中签章结论只能是"文字层落款齐全，电子签章需在投标客户端人工核对"。

阶段 4：八维度逐项核查

按 references/check_dimensions.md 第二节执行八大维度，重点：
- 报价核查：算术校验（单价×数量、合计、大小写）→ 红线校验（≤最高限价）→ 异常低价自检（对照阈值）→ 价格扣除测算（放弃扣除则量化评标价劣势）→ 竞争力评估。
- 废标专项：按 references/check_dimensions.md 第三节《无效投标情形清单》14 条逐一过，结果落入报告"废标风险清单"。
- 陷阱识别：按第四节《常见招标陷阱》扫描（"或"字条款、下限恰好响应、声明函勾选、经营范围匹配、租期短于服务期等）。
- 全程遵守 references/optimization_log.md 的优化规则（页码精确、判定前置校验、禁止印象式判断等）。

阶段 5：应答表逐项左右对照（强制，不可跳过）

1. 对产品技术参数响应表、服务要求应答表、商务要求应答表三张表，先摘录招标文件要求原文为左侧基准，再逐条对齐右侧响应。
2. 逐字段比较（数值/规格/品牌/数量），每条给出五级判定：满足 / 优于（正偏离）/ 负偏离 / 未响应 / 等于下限。
3. 排版性瑕疵（序号错位、疑似漏"≤"号）单独列出，注明"非废标级但建议修正"。

阶段 6：报告生成与交付

1. 复制 assets/report_template.html，按占位符填充实际内容，十大章节顺序固定：总体结论 → 废标风险清单 → 格式合规 → 内容完整 → 报价 → 签章 → 技术标（含逐参数对照表）→ 商务标 → 服务应答+OCR疑点 → 优化建议 + 核查方法局限。
2. 报告命名 投标文件核对评估报告-<项目简称>.html，输出到工作空间根目录。
3. 用 present_files 交付，并在最终回复中给出：总体判定一句话、风险清单（分级）、需人工确认事项。
4. 沉淀：新发现的坑/规则追加到 references/optimization_log.md；工作日志写入 <工作空间>/.workbuddy/memory/YYYY-MM-DD.md。

技术坑位备忘（环境相关，务必遵守）

1. JSON 污染：PyMuPDF 1.28+ 在 Git Bash 下 stderr 弃用警告会混入重定向后的 stdout，导致 JSON 解析失败 → 脚本一律把结果写文件，不通过 stdout 传 JSON。
2. 路径：Windows 无 /tmp，统一用 <工作空间>/.workbuddy/tmp/；工具调用传绝对路径。
3. 读图能力：当前模型不支持直接读 PNG → 用 OCR（RapidOCR + 250dpi 渲染）替代视觉核验，渲染图仅作留档。
4. Python 运行时：优先用托管 venv C:/Users/<user>/.workbuddy/binaries/python/envs/default，不污染系统环境。

Resources

• scripts/extract_pdf_text.py — PDF→JSON+TXT 批量提取（结果写文件，规避 stdout 污染）
• scripts/ocr_batch.py — 证照/图片页 OCR 批量核验（配置 JSON 驱动，输出 ocr_report.json）
• references/check_dimensions.md — 检查维度细则 + 无效投标 14 情形 + 招标陷阱 8 类 + 应答表左右对照方法（阶段 1/4/5 必读）
• references/optimization_log.md — 优化规则日志（14 条实战规则，执行前必读；执行后必须回写）
• assets/report_template.html — 报告 HTML 模板（阶段 6 复制使用，结构与样式固定）