bid-checker-pro v1.1.0 — 标书审核专家

路径约定：本文档中 {WORK_DIR} 表示当前工作目录（即项目根目录），{WORK_DIR}/download/ 为输出目录。模型应根据实际运行环境动态确定路径，不硬编码绝对路径。

核心理念：不是"AI替你重写标书"，而是"AI帮你审标书"——读招标文件抽要求+评分表，分段精读标书建索引，逐项核对格式合规性+评分项响应质量，输出带原文定位的Markdown审核报告。

与 bid-document-maker 的区别：maker 是"填标书"（提取模板→自动填充→缺失标黄），checker 是"查标书"（提取要求→比对实际→违规报告）。两者共享前半段（解析+模板提取+格式护栏），后半段方向相反。

⚠️ 强制执行规则（ALL MODELS MUST FOLLOW）

以下规则对本技能的所有调用者（任何模型）具有强制约束力，不得跳过、合并或并行执行多个阶段。违反以下流程将导致产出物不可用。

【全阶段强制总则 · 任何模型不得豁免】

1. 六阶段全部必做：Stage 1→2→3→4→5→6 缺一不可。严禁以"环境不可用 / 降级 / 时间紧 / 用户没要求"为由，整段跳过某一阶段或其对应报告章节。
2. 报告章节不可缺：最终报告必须包含全部 8 章（①总体概览 ②格式合规 ③评分项预估 ④OCR比对 ⑤视觉核对 ⑥价格分一致性 ⑦技术方案抄袭 ⑧改进建议）。其中 ③ 评分项预估（含报价分预估） 与 ⑦ 技术方案抄袭检测（含跨章节自重复维度② + 与公开资料相似维度③） 最易被遗漏，强制列为"高优先级必交付章节"——缺失即视为检查未完成、产出物不可用，禁止交付。
3. 降级≠跳过：若某子能力（OCR、z-ai web-search、LibreOffice 转换、LLM 评估等）在本环境不可用，必须显式标注降级原因与影响范围，并改用本 agent 的等价能力兜底（如用 WebSearch 替代 z-ai web-search、用 olefile/PyMuPDF 提取替代 LibreOffice 转换），禁止静默整段跳过。
4. 交付前自检（硬门控）：Stage 6 生成报告后、交付前，必须执行"阶段-报告对照自检"（清单见下方"自检清单"与"阶段-报告对照自检"），缺章必须返回补做，绝不允许"看起来做完了"就交付。
5. OCR 凭证强制交互（不得静默跳过）：进入 Stage 5 之前，模型必须主动向用户弹出 OCR 凭证配置交互界面（见下方"E. OCR 凭证强制交互配置"），提供「自填密钥 / 引导注册 / 降级跳过」三选项，待用户显式选择其一后方可继续。严禁假设用户已有密钥、严禁用默认值替代交互、严禁直接进入 OCR 流程。

六阶段顺序执行 + 四个强制门控点

┌─────────────────────────────────────────────────────────┐
│  Stage 1: 解析招标文件（提取格式要求+评分表）              │
│  输入: 招标文件（.docx/.doc/.pdf）                        │
│  产物: {项目名}_招标要求清单.json                         │
│  产物: {项目名}_评分表.json                               │
│  ⏸️ 门控1: 展示要求清单+评分表摘要，等待"继续"            │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  Stage 2: 解析待审核标书（建立章节索引）                  │
│  输入: 标书文件（.docx/.doc/.pdf，可上百页）              │
│  产物: {项目名}_标书章节索引.json                         │
│  产物: {项目名}_标书章节摘要.json                         │
│  无门控，自动进入 Stage 3                                 │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  Stage 3: 格式合规比对（8类检查）                         │
│  输入: 招标要求清单 + 标书章节索引                        │
│  产物: {项目名}_格式审核Plan.json                         │
│  ⏸️ 门控2: 展示格式违规清单，等待用户确认                 │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  Stage 4: 评分项响应质量评估                              │
│  输入: 评分表 + 标书章节索引+章节摘要                     │
│  产物: {项目名}_评分预估Plan.json                         │
│  ⏸️ 门控3: 展示评分预估结果，等待用户确认                 │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  Stage 5: OCR 资质详细比对 + 渲染视觉核对                 │
│  输入: 标书图片 + 资质章节                                │
│  产物: {项目名}_OCR比对报告.json                          │
│  产物: {项目名}_审核预览PNG/                              │
│  无门控，自动进入 Stage 6                                 │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  Stage 6: 生成最终审核报告                                │
│  输入: 格式审核Plan + 评分预估Plan + OCR比对 + 视觉核对   │
│  产物: {项目名}_审核报告.md（最终交付）                   │
│  ⏸️ 门控4: 报告交付确认                                   │
└─────────────────────────────────────────────────────────┘

门控点的 6 个强制动作

每个门控点必须依次完成以下 6 个动作，缺一不可：

1. 产物文件存在性检查：ls -la {WORK_DIR}/{产物文件} 验证文件存在且大小 ≥1KB
2. 展示产物摘要：在对话中展示关键统计（如"共检查 8 类格式合规项，发现 5 处违规"）
3. 输出 ⏸️ 暂停话术：明确告知用户"已暂停，请回复'继续'或'下一步'进入 Stage X"
4. 真正停止：严禁在用户未回复前自动推进到下一阶段
5. 记住"继续"才推进：只有用户回复"继续/下一步/确认"才进入下一阶段
6. 交付前阶段-报告对照自检（仅 Stage 6 交付前执行）：报告必须包含全部 10 个章节（① 总体概览 ② 格式合规 ③ 评分项预估 ④ OCR 比对 ⑤ 视觉核对 ⑥ 标⭐️项检查 ⑦ 文字错误检查 ⑧ 价格分一致性 ⑨ 技术方案抄袭 ⑩ 改进建议）。缺任何一章（尤其"③ 评分项预估""⑥ 标⭐️项检查"与"⑨ 技术方案抄袭检测"）必须返回补做，禁止交付缺章报告。 对照清单见下方"阶段-报告对照自检"。

自检清单（每个门控点必问自己）

• 我是否用 ls -la 验证了产物文件存在且 ≥1KB？
• 我是否展示了产物文件的关键摘要（不是只说"已完成"）？
• 我是否输出了 ⏸️ 暂停话术？
• 我是否真的停止了（没有自动推进）？
• 我是否记住了只有用户回复"继续"才推进？
• 我是否执行了 OCR 凭证强制交互（E 节三选项），待用户显式选择后才进入 Stage 5？

阶段-报告对照自检（Stage 6 交付前硬门控 · 缺章即返回补做）

凡标注「🔴 禁止交付缺章」的章节缺失，必须返回对应 Stage 补做，绝不允许"看起来做完了"就交付。门控4 展示前必须逐行核对本表 10 行。

启动前必读

在执行 Stage 1 之前，模型必须依次完成以下准备：

A. 读取经验案例库（强制）

读取 {SKILL_DIR}/EXPERIENCES.md，理解 11 条审核规则（E1-E11）及其对应的检查项。这些规则是从真实标书踩坑案例提炼的，每一项都对应审核 Plan 中的一个检查项。

B. 读取审核规则配置（强制）

读取 {SKILL_DIR}/config/audit_rules.yaml，了解：

• 8 类格式合规检查项的具体规则
• 4 级严重度分类标准（critical/major/minor/info）
• 评分项响应质量评估的 4 级标准（完全响应/部分响应/不足/缺失）
• 必填项清单（投标函/法人信息/项目编号/日期等）

C. 启动自检

运行 python {SKILL_DIR}/scripts/ocr_selftest.py 检查 OCR 引擎当前可用性，仅作为 E. OCR 凭证强制交互配置 的输入信息（向用户呈现"已配置/未配置"）。不得据此直接决定跳过 OCR——最终方案必须由 E 节的三选项交互中用户显式选择决定。

D. 确认输入

向用户确认以下信息（缺失时主动询问）：

1. 招标文件路径（必需）：可以是 .docx/.doc/.pdf
2. 标书文件路径（必需）：可以是 .docx/.doc/.pdf
3. 项目名称（必需）：用于产物文件命名，若用户未提供，从招标文件解析后回填
4. 审核重点（可选）：默认全量审核，用户可指定"只审格式"或"只评得分"

E. OCR 凭证强制交互配置（任何模型必须执行 · 不得静默跳过）

在进入 Stage 1 之前，模型必须通过交互界面（AskUserQuestion 或等价 UI）向用户确认 OCR 凭证方案。这是强制门控：不得使用默认值、不得假设用户已有密钥、不得跳过此交互直接进入 OCR 流程。即使 ocr_selftest.py 检测到已配置密钥，仍须呈现本交互（可预选"已配置"并请用户确认）。

交互设计（3 个选项，必须让用户显式选择其一）：

• 选项 A｜我有密钥，现在填入

  • 用户提供百度 OCR 的 API Key 与 Secret Key（可经交互框的自由文本区填写，或口头给出）。
  • 模型将其写入 {SKILL_DIR}/config.json 的 ocr.baidu_ocr.api_key / secret_key（替换占位符 YOUR_API_KEY / YOUR_SECRET_KEY），使后续所有运行自动读取。
  • 写完后运行 python {SKILL_DIR}/scripts/ocr_selftest.py 验证可用；对话中仅回显密钥前 6 位供核对，不明文展示完整密钥。

• 选项 B｜我没有，引导我去注册

  • 模型必须主动、分步引导用户完成百度 OCR 注册并复制密钥，不得只甩一个链接了事：
    1. 打开浏览器访问 https://cloud.baidu.com/product/ocr
    2. 登录 / 注册百度账号
    3. 进入「控制台 → 文字识别 → 创建应用」，应用名称填 bid-checker-ocr，获得 API Key 与 Secret Key
    4. 请用户复制这两个值返回，模型收录后回到选项 A 写入 config
  • 多轮引导直至用户拿到密钥并填入；若用户中途放弃注册，则回退到 选项 C。

• 选项 C｜跳过 OCR，使用降级策略

  • 不配置百度 OCR，标记 ocr_mode = "degraded"。
  • Stage 5 的资质图片 OCR 详细比对降级为「规则 / 关键词 / 人工标注」兜底；最终报告 ④ OCR 比对 章节须显式标注「OCR 未配置，资质图片文字未自动核验，相关结论以'须人工确认'呈现」。
  • 若本机已安装 PaddleOCR，可自动降级到本地模型（无需密钥）；否则纯规则兜底，不得因降级而整段跳过 OCR 比对章节（章节仍须存在并说明降级范围）。

强制要求：

• 三选项必须让用户显式选择其一；未获选择前，不得进入 Stage 1 之后的任何 OCR 相关环节。
• 选择 B 时模型须逐步引导并在每步确认用户是否完成，禁止一次性丢出注册链接后等待。
• 选择 A 后写入的密钥仅存于本地 config.json，不得在报告中明文回显完整密钥。

文档格式转换策略（多引擎高保真 · 严禁静默降级）

标书多为 .doc（老版 Word）格式。转换质量直接决定后续所有检查的准确性——一旦落入 「仅文本」提取，报价表、技术参数表、签字位等结构会丢失，价格核对等结论将不可信。 绝不允许"只有 LibreOffice 才能转、没有就降级"的思路：用户电脑普遍装有 Office / WPS，沙箱也能装 Aspose，可选项远不止 LibreOffice。

引擎优先级（保真度从高到低，模型按序尝试）

实现见 bid_checker/utils/doc_to_docx.py：convert_doc_to_docx() 按上表顺序尝试， 返回 (docx_path, was_converted, fidelity)，其中 fidelity ∈ {'high','text_only'}。

铁律（对标书严谨性负责）

• 高保真优先：先试 1~4，任一成功即用，绝不在有高保真引擎可用时跳到仅文本兜底。
• 自动安装兜底（AI 在沙箱主动安装）：若 1~4 全不可用，模型应先执行自动安装 （try_auto_install() 即 pip install aspose-words）并重试；仍失败再提示用户安装 MS Office / WPS / LibreOffice 之一。严禁在"可安装高保真引擎"时直接宣布"无法转换"。
• 禁止静默降级：仅当 1~4 全部失败才落入 5/6 仅文本兜底，此时函数返回 fidelity='text_only'，模型须：
  1. 在进度摘要与最终报告中显式标注「本次转换为仅文本兜底，结构有损」；
  2. 凡涉及表格（报价、技术参数、资质清单）的结论，提示「须逐页人工复核」；
  3. 强烈建议用户用 Word/WPS 另存为 .docx 后重新运行。
• 自检命令：python {SKILL_DIR}/scripts/convert_to_docx.py --selftest 列出各引擎 可用性及将使用的保真度，Stage 1 前建议先跑一次。

Stage 1: 解析招标文件

1.1 目标

从招标文件中提取两类信息：

1. 格式要求清单：章节结构要求、必填项清单、签字盖章规则、字体字号要求、页码要求等
2. 评分表：评分项、分值、评分标准、客观/主观分类

1.2 执行步骤

# Step 1: 统一格式为 .docx
python {SKILL_DIR}/scripts/convert_to_docx.py 
  --input "{招标文件路径}" 
  --output "{WORK_DIR}/{项目名}_招标文件.docx"

# Step 2: 解析招标文件，提取结构化信息
python {SKILL_DIR}/scripts/parse_bid_document.py 
  --input "{WORK_DIR}/{项目名}_招标文件.docx" 
  --output-json "{WORK_DIR}/{项目名}_招标解析数据.json" 
  --output-md "{WORK_DIR}/{项目名}_招标解析报告.md"

# Step 3: 提取格式要求清单（基于解析数据 + LLM 二次抽取）
python {SKILL_DIR}/scripts/extract_format_requirements.py 
  --input "{WORK_DIR}/{项目名}_招标解析数据.json" 
  --output "{WORK_DIR}/{项目名}_招标要求清单.json"

# Step 4: 提取评分表（LLM 抽取，结构化输出）
python {SKILL_DIR}/scripts/extract_scoring_table.py 
  --input "{WORK_DIR}/{项目名}_招标解析数据.json" 
  --output "{WORK_DIR}/{项目名}_评分表.json"

1.3 产物文件

1. {项目名}_招标要求清单.json — 格式合规要求清单，结构：

{
  "project_info": {
    "项目名称": "...",
    "项目编号": "...",
    "采购人": "...",
    "采购方式": "公开招标/竞争性谈判/..."
  },
  "chapter_requirements": [
    {
      "chapter_id": "ch01",
      "title": "投标函",
      "required": true,
      "must_be_present": true,
      "must_page_break_before": true,
      "evidence_keywords": ["投标函", "致："]
    }
  ],
  "required_fields": [
    {
      "field_id": "f001",
      "label": "项目名称",
      "appears_in": ["投标函", "投标一览表", "封面"],
      "must_be_consistent": true
    }
  ],
  "signature_rules": [
    {
      "rule_id": "s001",
      "context": "投标函",
      "type": "法人签字+公章",
      "must_be_empty": true,
      "warning_if_filled": false
    }
  ],
  "format_rules": [
    {
      "rule_id": "fmt001",
      "type": "font",
      "description": "正文宋体小四",
      "scope": "正文"
    }
  ]
}

2. {项目名}_评分表.json — 评分表，结构：

{
  "total_score": 100,
  "scoring_items": [
    {
      "item_id": "sc001",
      "category": "商务分",
      "title": "投标函格式",
      "max_score": 5,
      "criteria": "投标函格式符合招标文件要求",
      "type": "objective",
      "evidence_keywords": ["投标函"],
      "weight": 1.0
    },
    {
      "item_id": "sc002",
      "category": "技术分",
      "title": "技术方案完整性",
      "max_score": 15,
      "criteria": "方案覆盖招标要求的所有技术点，包括应急响应流程",
      "type": "subjective",
      "evidence_keywords": ["技术方案", "应急响应", "实施方案"],
      "sub_criteria": [
        {"desc": "技术路线清晰", "score": 5},
        {"desc": "实施步骤完整", "score": 5},
        {"desc": "应急响应流程", "score": 5}
      ],
      "weight": 1.0
    }
  ]
}

1.4 门控1

展示内容：

• 项目基本信息（名称、编号、采购人、采购方式）
• 章节要求清单摘要：共 X 个章节，其中 Y 个为必需章节
• 评分表摘要：总分 X 分，共 Y 个评分项（客观分 Z 项 + 主观分 W 项）
• 任何 LLM 抽取过程中的低置信项（需用户确认）

暂停话术模板：

✅ Stage 1 完成

📋 招标文件解析结果：
- 项目名称：{xxx}
- 项目编号：{xxx}
- 采购方式：{xxx}
- 必需章节数：{X} 个
- 评分项数：{Y} 个（客观分 {Z} 项 + 主观分 {W} 项）
- 总分：{total} 分

⚠️ 需确认项：
- {低置信项1}
- {低置信项2}

⏸️ 已暂停，请回复"继续"或"下一步"进入 Stage 2（解析标书+建立章节索引）

Stage 2: 解析待审核标书 + 建立章节索引

2.1 目标

对待审核的标书（可能上百页）做以下处理：

1. 统一格式为 .docx
2. 扫描章节树：识别所有标题段落，建立"标题→起止页/字数/正文"映射
3. 生成章节摘要：每章节用 LLM 生成 200 字内的摘要（用于后续评分项驱动的精读）
4. 建立关键词倒排索引：所有章节正文建立关键词倒排表（用于精筛）

2.2 大文档分段读取策略（核心）

标书可能上百页，模型上下文有限，必须用"评分项驱动的检索增强"策略：

全文档（N页，可能 300+）
    ↓
[Step 1] 章节切片（用 python-docx 扫描所有 Heading 段落）
    ↓
章节列表（M个章节，每个 5-30 页）
    ↓
[Step 2] 章节摘要（一次 LLM 调用，所有章节标题+前500字 → 200字摘要）
    ↓
章节摘要表（M 条摘要，每条 200 字）
    ↓
[Step 3] 评分项驱动精读（每个评分项独立调用）
    ↓
    对每个评分项：
      3-1. 摘要粗筛 → 选出 top-10 相关章节
      3-2. 关键词精筛 → 选出 top-3 章节
      3-3. 精读评估 → 只把这 3 个章节的全文喂给 LLM

这种策略的优点：

• 上下文可控：每个评分项只读 3-5 个章节（5-10K tokens）
• 精准定位：用关键词+摘要双层筛选，避免误读无关章节
• 可解释：每个评分项的评估都附原文引用和章节定位
• 可并行：多个评分项可以并发评估，加速处理

2.3 执行步骤

# Step 1: 统一格式为 .docx
python {SKILL_DIR}/scripts/convert_to_docx.py 
  --input "{标书文件路径}" 
  --output "{WORK_DIR}/{项目名}_标书.docx"

# Step 2: 章节切片（扫描所有 Heading 段落，建立章节树）
python {SKILL_DIR}/scripts/slice_chapters.py 
  --input "{WORK_DIR}/{项目名}_标书.docx" 
  --output "{WORK_DIR}/{项目名}_标书章节索引.json"

# Step 3: 生成章节摘要（LLM 调用）
python {SKILL_DIR}/scripts/generate_chapter_summaries.py 
  --input "{WORK_DIR}/{项目名}_标书章节索引.json" 
  --output "{WORK_DIR}/{项目名}_标书章节摘要.json"

# Step 4: 建立关键词倒排索引
python {SKILL_DIR}/scripts/build_keyword_index.py 
  --input "{WORK_DIR}/{项目名}_标书章节索引.json" 
  --output "{WORK_DIR}/{项目名}_标书关键词索引.json"

2.4 产物文件

1. {项目名}_标书章节索引.json — 章节树，结构：

{
  "doc_path": "...",
  "total_pages": 287,
  "total_words": 156800,
  "chapters": [
    {
      "chapter_id": "ch01",
      "level": 1,
      "title": "投标函",
      "para_index_start": 12,
      "para_index_end": 25,
      "page_start": 3,
      "page_end": 4,
      "word_count": 850,
      "full_text": "..."
    }
  ]
}

2. {项目名}_标书章节摘要.json — 章节摘要表，结构：

{
  "summaries": [
    {
      "chapter_id": "ch01",
      "title": "投标函",
      "summary": "本章为投标函正文，包含投标人致采购人的函件，落款含法人签字位、公章位、日期位。投标金额为人民币壹佰贰拾万元整。",
      "key_points": ["投标金额120万", "法人签字位", "公章位"]
    }
  ]
}

3. {项目名}_标书关键词索引.json — 关键词倒排索引（用于精筛），结构：

{
  "index": {
    "投标函": ["ch01"],
    "营业执照": ["ch05", "ch12"],
    "技术方案": ["ch08", "ch09", "ch10"]
  }
}

2.5 无门控，自动进入 Stage 3

Stage 2 完成后，展示进度摘要但不暂停，自动进入 Stage 3：

✅ Stage 2 完成

📚 标书索引建立结果：
- 总页数：{X} 页
- 总字数：{Y} 字
- 识别章节数：{M} 个
- 章节摘要已生成

➡️ 自动进入 Stage 3：格式合规比对

Stage 2.5: 标⭐️项（关键参数 / 废标条款）检查

2.5.1 目标

招标文件中常以 ★ / ⭐ / ☆ 标注「标星项」，或在评分办法中规定「带★指标的加分 / 减分 / 不满足即废标」政策。这类条目一旦不满足，通常是 废标 或 该模块零分，严重程度远高于一般格式 / 文字问题。故单独成章、详细核查，且 绝不静默跳过（无标星项时显式标注「无标星项」，不视为错误）。

2.5.2 机器可抽取的维度（脚本覆盖 · check_star_items.py）

抽取覆盖多种星号符号（★ ☆ ⭐ ✩ ✪ 等）以及「星号 / 标星 / 带星 / 关键参数 / 实质性要求」等文字标记；评分政策自动识别 加分 / 减分 / 废标 动作与分值。 投标响应判定：逐句匹配（取星号后要求文本在投标文中检索，仅在该句内判定 满足/不满足，避免跨条污染），policy/clause 两类直接标"需复核"交 LLM 确认。

2.5.3 执行步骤

# Step1: 机器抽取 + 初判投标响应（支持 .docx / .txt / .doc；.doc 走 olefile 提取）
python {SKILL_DIR}/scripts/check_star_items.py 
  --tender "{WORK_DIR}/{项目名}_招标文件.docx" 
  --bid "{WORK_DIR}/{项目名}_标书.docx" 
  --output "{WORK_DIR}/{项目名}_标星项检查Plan.json"

# Step2: 【LLM 逐条复核】（模型必做，不可跳过）
#   机器仅做抽取与"满足/不满足/需复核"初判；技术规格是否真正满足、
#   废标条款是否被触发、评分政策是否已在得分预估中落实，必须模型通读
#   招标文件与投标响应后逐条确认，将结论写回 Plan 的 bid_response.status
#   与 issues，并置 llm_review_needed=false。此步骤不能用脚本替代。

2.5.4 产物

{项目名}_标星项检查Plan.json：has_star_items + summary（参数/废标/政策计数 + 投标响应分布 + 关键风险等级）+ star_items 明细（id / type / text / location / policy / bid_response{status,evidence} / severity / llm_review_needed）。

• 若 has_star_items=false：报告第六章显式标注「无标星项」，不视为错误（如梦桃小学项目）。

2.5.5 展示与门控

展示标星项概览（按类型计数）与 critical 级 / 不满足项明细，不暂停，自动进入 Stage 2.6。最终报告须含「六、标⭐️项（关键参数/废标条款）检查」章节（见报告模板）。凡存在不满足或被触发风险的标星项，须在核心结论中升级为高危提示。

Stage 2.6: 文字错误（错别字）检查

2.6.1 目标

对标书全文做文字质量核查，捕获机器可判定的错误，并补充模型语境复核（捕捉语境相关错误）。标书里的错别字（尤其金额、公司名、废标敏感词）可能改变法律含义，属高风险。

2.6.2 可机器判定的维度（脚本覆盖）

2.6.3 执行步骤

# Step 1: 机器检查（支持 .docx / .txt / .doc）
python {SKILL_DIR}/scripts/check_typos.py 
  --input "{WORK_DIR}/{项目名}_标书.docx" 
  --output "{WORK_DIR}/{项目名}_错别字检查Plan.json"

# Step 2: 【LLM 语境复核】（模型必做，不可跳过）
#   模型通读标书全文，重点核对语境相关错误：的/地/得、做/作、截止/截至、
#   语义反转、废标敏感词误写等，将发现以追加条目写入同一 JSON 的 issues，
#   并置 llm_review_needed=false。此步骤不能用脚本替代。

2.6.4 产物

{项目名}_错别字检查Plan.json：按类型统计 + issues 明细（id / type / severity / original / suggestion / context / location / confidence）。

2.6.5 展示与门控

展示错别字概览（按类型计数）与 critical 级明细，不暂停，自动进入 Stage 3。最终报告须含「七、文字错误（错别字）检查」章节（见报告模板）。

Stage 3: 格式合规比对（8 类检查）

3.1 8 类格式合规检查

3.2 执行步骤

# 综合执行 8 类检查，输出机器可读 Plan
python {SKILL_DIR}/scripts/audit_format_compliance.py 
  --requirements "{WORK_DIR}/{项目名}_招标要求清单.json" 
  --docx "{WORK_DIR}/{项目名}_标书.docx" 
  --chapter-index "{WORK_DIR}/{项目名}_标书章节索引.json" 
  --output "{WORK_DIR}/{项目名}_格式审核Plan.json"

3.3 产物文件

{项目名}_格式审核Plan.json — 机器可读审核 Plan，结构：

{
  "audit_id": "audit_20260716_xxx",
  "audit_time": "2026-07-16T12:00:00",
  "total_checks": 156,
  "passed": 142,
  "failed": 14,
  "failures_by_severity": {
    "critical": 3,
    "major": 5,
    "minor": 4,
    "info": 2
  },
  "items": [
    {
      "check_id": "chk_001",
      "category": "章节完整性",
      "severity": "critical",
      "rule_id": "rule_ch01",
      "requirement": "投标函章节必须存在",
      "actual": "已存在，位于第3-4页",
      "status": "compliant",
      "evidence": "章节索引 ch01",
      "suggestion": null,
      "page_ref": "3-4"
    },
    {
      "check_id": "chk_002",
      "category": "签字盖章位",
      "severity": "critical",
      "rule_id": "rule_s001",
      "requirement": "投标函法人签字位必须留空（待现场签字）",
      "actual": "签字位被填入文字'张三'",
      "status": "non_compliant",
      "evidence": "原文：'法定代表人（签字）：张三'",
      "suggestion": "删除签字位的'张三'，签字位应留空",
      "page_ref": "3"
    }
  ]
}

3.4 4 级严重度分类

3.5 门控2

展示内容：

• 总检查项数 + 通过/失败统计
• 按 4 级严重度分组的失败项摘要（每项含检查项+严重度+位置+建议）
• critical 项必须高亮提示用户优先处理

暂停话术模板：

✅ Stage 3 完成

🔍 格式合规审核结果：
- 总检查项：{X} 项
- ✅ 通过：{Y} 项
- ❌ 不合规：{Z} 项
  - 🔴 critical（致命）：{a} 项
  - 🟡 major（重大）：{b} 项
  - 🔵 minor（轻微）：{c} 项
  - ⚪ info（提示）：{d} 项

🔴 critical 违规项（必须修复）：
1. {检查项1} — {位置} — {建议}
2. {检查项2} — {位置} — {建议}
...

🟡 major 违规项（强烈建议修复）：
1. {检查项1} — {位置} — {建议}
...

⏸️ 已暂停，请回复"继续"或"下一步"进入 Stage 4（评分项响应质量评估）

Stage 4: 评分项响应质量评估

4.1 目标

针对评分表中的每一个评分项，评估标书的响应质量，给出预估得分。区分两类：

1. 客观分项（type=objective）：核对是否响应（如"提供营业执照"→是/否）
2. 主观分项（type=subjective）：评估响应质量（如"技术方案完整性"→预估得分+理由）

4.2 评分项驱动精读流程

对每个评分项独立执行：

评分项 X
  ↓
[Step 4-1] 摘要粗筛
  从章节摘要表中筛选 top-10 相关章节
  （用评分项的 evidence_keywords 匹配章节摘要）
  ↓
[Step 4-2] 关键词精筛
  从 top-10 章节中筛出 top-3 章节
  （用关键词倒排索引 + TF-IDF 排序）
  ↓
[Step 4-3] 精读评估（LLM 调用）
  输入：评分项 + 评分标准 + top-3 章节全文
  输出：是否响应 + 响应质量 + 预估得分 + 扣分理由 + 改进建议
  ↓
[Step 4-4] 客观分项特殊处理
  对资质类客观分项，标记需要 Stage 5 OCR 详细比对的图片

4.2.1 价格分基准价交互确认（强制 · 不可跳过）

规则：Stage 4 计算"报价分/价格分"之前，必须用 AskUserQuestion 工具与用户交互，询问本项目其他投标人（竞争对手）的最低报价大约是多少，以此作为"基准价"计算价格分。禁止在不询问用户的情况下，直接用本投标报价或最高限价自行假设基准价。

交互脚本（每次检查必须执行一次）：

• 问题：「您预估本项目其他投标人（除我方外）的最低报价大约为多少？该数值将作为价格分计算的基准价（满足招标文件要求的最低报价）。」
• 选项（6 选 1，用户可自选"其他"填写任意金额）：
  • A：最高限价的 90%
  • B：最高限价的 80%
  • C：最高限价的 70%
  • D：最高限价的 60%
  • E：最高限价的 50%
  • F：自定义——用户直接填写预估的其他家最低报价金额（元）
• 用户选择后计算 baseline_price：
  • 选 A–E：baseline_price = 最高限价 × 对应比例
  • 选 F：baseline_price = 用户填写的金额
• 用户拒绝回答 / 未提供：保守按 baseline_price = 最高限价 × 90% 计算，并在报告中将该价格分的 confidence 标注为 low，confidence_reason 注明「基准价为保守假设（限价 90%），未获用户确认」。

价格分计算公式（与政府采购通用规则一致）：

报价分 = (baseline_price / 本投标报价) × 报价满分

• 当 本投标报价 ≤ baseline_price（我方即最低价）时，报价分 = 满分。
• baseline_price 必须写入 {项目名}_评分预估Plan.json 的顶层字段 baseline_price 与 price_score_confidence，供 Stage 6 报告引用与复核。

4.3 执行步骤

# 评分项响应质量评估
python {SKILL_DIR}/scripts/evaluate_scoring_items.py 
  --scoring-table "{WORK_DIR}/{项目名}_评分表.json" 
  --chapter-index "{WORK_DIR}/{项目名}_标书章节索引.json" 
  --chapter-summaries "{WORK_DIR}/{项目名}_标书章节摘要.json" 
  --keyword-index "{WORK_DIR}/{项目名}_标书关键词索引.json" 
  --baseline-price {baseline_price} 
  --bid-price {bid_total} 
  --price-confidence {medium_or_low} 
  --baseline-source {user_A..F 或 conservative_default} 
  --output "{WORK_DIR}/{项目名}_评分预估Plan.json"

注意：

• --baseline-price 的值来自 4.2.1 与用户交互得到的 baseline_price（竞争对手最低报价预估）。
• --bid-price 的值来自 Stage 1 解析出的本投标报价总额（如 1,918,289.90）。
• --price-confidence：用户交互确认填 medium，保守默认（限价90%）填 low。
• 未与用户交互、未传入 --baseline-price 不得运行本命令——价格分必须基于用户对竞争对手报价的预估。

4.4 产物文件

{项目名}_评分预估Plan.json — 评分预估 Plan，结构：

{
  "evaluation_id": "eval_20260716_xxx",
  "evaluation_time": "2026-07-16T12:00:00",
  "total_score": 100,
  "estimated_score": 78,
  "confidence": "medium",
  "confidence_reason": "主观分项预估存在 5-10 分误差",
  "baseline_price": 1731088.25,
  "price_score_confidence": "medium",
  "baseline_price_source": "user_interactive_A(限价90%)",
  "items": [
    {
      "item_id": "sc001",
      "category": "商务分",
      "title": "投标函格式",
      "max_score": 5,
      "estimated_score": 5,
      "type": "objective",
      "response_status": "fully_responded",
      "evidence_chapters": ["ch01"],
      "evidence_text": "投标函章节存在，格式符合要求",
      "page_ref": "3-4",
      "deduction_reasons": [],
      "improvement_suggestions": [],
      "needs_ocr_check": false
    },
    {
      "item_id": "sc002",
      "category": "技术分",
      "title": "技术方案完整性",
      "max_score": 15,
      "estimated_score": 12,
      "type": "subjective",
      "response_status": "partially_responded",
      "evidence_chapters": ["ch08", "ch09", "ch10"],
      "evidence_text": "技术方案章节覆盖了8个技术点中的7个，缺少应急响应流程",
      "page_ref": "45-78",
      "deduction_reasons": [
        {
          "sub_criteria": "应急响应流程",
          "max_score": 5,
          "deducted_score": 3,
          "reason": "未提供应急响应流程章节",
          "suggestion": "在第8章后新增'应急响应流程'章节"
        }
      ],
      "improvement_suggestions": [
        "补充应急响应流程章节，覆盖故障分级、响应时间、升级机制"
      ],
      "needs_ocr_check": false
    },
    {
      "item_id": "sc003",
      "category": "商务分",
      "title": "营业执照（有效期内）",
      "max_score": 5,
      "estimated_score": 5,
      "type": "objective",
      "response_status": "fully_responded",
      "evidence_chapters": ["ch05"],
      "evidence_text": "营业执照图片已插入资质章节",
      "page_ref": "12",
      "deduction_reasons": [],
      "improvement_suggestions": [],
      "needs_ocr_check": true,
      "ocr_check_target": "营业执照有效期、公司名称、统一社会信用代码"
    }
  ]
}

4.5 响应质量 4 级标准

4.6 置信度评估

4.7 门控3

展示内容：

• 预估总分 + 置信度
• 按评分项类别分组（商务分/技术分/价格分/其他）展示
• 每个 critical 扣分点高亮（如"营业执照缺失"扣 5 分）
• 标记需要 Stage 5 OCR 详细比对的评分项
• 价格分计算依据：展示 baseline_price（来源：用户交互选项 A–F / 保守假设）、计算公式与得分，提醒用户该数值依赖其对竞争对手报价的预估

暂停话术模板：

✅ Stage 4 完成

📊 评分预估结果：
- 总分：{estimated}/{total} 分
- 置信度：{confidence}（{reason}）

📋 按类别分组：
【商务分】{a}/{b} 分
  - {item1}: {score}/{max} ✅
  - {item2}: {score}/{max} ⚠️ {reason}
  ...

【技术分】{c}/{d} 分
  - {item1}: {score}/{max} ✅
  - {item2}: {score}/{max} ❌ {reason}
  ...

【价格分】{e}/{f} 分
  ...

🔍 需 Stage 5 OCR 详细比对的项：
1. {item1} — {ocr_check_target}
2. {item2} — {ocr_check_target}

⏸️ 已暂停，请回复"继续"或"下一步"进入 Stage 5（OCR 详细比对 + 视觉核对）

Stage 5: OCR 资质详细比对 + 渲染视觉核对

5.1 目标

完成两件事：

1. OCR 资质详细比对：对 Stage 4 标记为 needs_ocr_check 的评分项，OCR 出对应图片的文本，详细核对：

   • 营业执照：有效期、公司名称、统一社会信用代码（与投标人信息一致）
   • 身份证：有效期、姓名、身份证号（与法人/被授权人信息一致）
   • 资质证书：有效期、资质等级（与