天好富兴 | 招投标文件检查

概述

投标文件符合性检查

Overview

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

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

输入决定模式（先看用户手上有什么文件，再决定跑不跑）：第一步先识别文件角色——按文件名把每个文件归为「招标文件 / 投标文件 / 判不出」，判不出的再按正文骨架识别，规则见「文件角色识别」；识别结果决定走哪条路径：招标文件 + 投标文件齐全 → 完整符合性检查（阶段 0–7）；只有招标文件 → 招标文件解析模式（仅解析、不做响应性判定，见阶段 0 分支说明）；只有投标文件 → 不执行本技能——不提取、不比对、不出任何报告，友好提示补齐招标文件；两份都没有 / 文件打不开 → 同样不执行，友好说明需要哪些文件。

数量上限（硬性闸门）：一次最多 1 份招标文件 + 3 份投标文件。任一侧超出（招标文件 >1 份或投标文件 >3 份）→ 不执行——不建任务文件夹、不跑任何阶段，友好告知上限并等用户把文件缩减到限额内，修正后才从头重新识别、继续运行。和用户怎么开口，见下方「与用户沟通」。

安全与保密约束

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

1. 不联网：文件解析、条款核验、报告生成全部在用户本机完成，不把标书内容发送给任何外部

服务或在线接口。扫描件没有文本层时，请用户提供可复制文字的版本，或由用户在本地自行做 OCR（例如本地安装的 OCR 工具），不要建议把文件交给在线 OCR、云转换等外部服务代处理。

1. 不臆造：解析不到评分办法、分值权重、废标条款或某项要求时，如实记录为"未识别到"，

在报告中如实呈现并提示用户补材料核对。严禁为"显得完整"而编造分值、权重或条款内容——编造的数值会直接误导得分预估与废标判断，宁可缺失，不可虚构。

1. 经验私有：从源文件到提取的 JSON、中间结果与报告草稿，一律只写入用户当前的本地工作目录

（本次任务的任务文件夹，即脚本 --out / --out-dir 指向的本地目录），不另存到云端、不同步到任何共享位置、不写入系统缓存目录。会话或工具关闭后，全部产物仍留在用户自己机器上，随时可取用。

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

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

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

文件齐全，准备跑完整检查：

收到！我会把招标文件里的资格、商务、技术、评分要求逐条拉成清单，再对照投标文件

重点找"容易废标、丢分"的地方，最后给您一份带整改清单的检查报告。

只有招标文件，自动进入解析模式：

目前只看到招标文件，没问题～ 我先帮您做「招标文件解析」：把投标资格、废标条款、

评分办法、关键技术要求和几个关键时间节点提炼成清单（这一步不做符合性判定）。

这份清单会保留下来，等投标文件就绪再上传，就能在同一条清单上直接做完整检查，不用重复解析。

只给了投标文件、没有招标文件（本技能不运行，按此口径说明，不要开展任何检查步骤）：

我注意到您上传的是投标文件《…》，不过还没看到对应的招标文件。符合性检查需要把

「招标文件」和「投标文件」放在一起比对才成立——只有一份投标文件，没法判断它是否满足

招标要求。麻烦您把该项目的招标文件也上传一下，我会马上为您逐条核对并出报告～

什么文件都还没有 / 文件打不开：

还没收到可以检查的文件哦。核对一个项目需要同项目的「招标文件 + 投标文件」两份文件

（.docx / .pdf / .xlsx / .md / .txt 均可，PDF 优先提供可复制文字的版本）。

把文件发给我，我先帮您确认检查范围。

文件数量超出上限（招标文件超过 1 份，或投标文件超过 3 份；此时不执行，等用户修正后再继续）：

收到不少文件～ 不过一次检查最多支持 1 份招标文件 + 3 份投标文件，

目前您上传的招标文件有 X 份、投标文件有 Y 份，超出了上限。

麻烦您删减一下（比如去掉重复版本，或分多批依次检查），控制在 1 份招标文件、

3 份投标文件以内再发我，我马上开始检查～

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

依赖安装（用户零感知原则）

本技能的用户是不懂编程的白领——Python、pip、venv、镜像源这些词一律不得出现在对话里，环境准备全部由 agent 静默完成：不向用户播报环境问题、不请用户运行任何命令、不因装依赖停下来等用户确认。需要提前说明的最多一句轻量预告：

首次解析前我先准备一下文档解析工具，大概一分钟，之后不会再装。

零感知只覆盖"能自动搞定"的过程：一旦自动重试后仍失败（四个源全装不上、venv 建不出来、找不到可用解释器），必须停下如实告知用户（见本节末尾「环境准备失败的沟通口径」），不要装作没事硬跑——环境不就绪强跑，解析会在中途崩掉，比一开始就说清更伤体验。

环境兼容（Windows / WorkBuddy 场景先看这条）：执行环境的 Bash 可能缺少基础 Unix 工具（ls、dirname、find、cp 等报 PATH 或命令不存在错误），PowerShell 也可能无回显（命令 exitCode 0 但 stdout 一片空白）。因此禁止任何形式的环境探测——不要单独执行"检查工作目录与环境"之类的步骤、不要试运行 Unix / PowerShell 命令。环境信息只来自一条命令：

C:/Users/Administrator/.workbuddy/binaries/python/versions/3.13.12/python.exe scripts/doctor.py

（受管 Python 路径仅作默认示例，不同机器可能在不同盘符；该路径不存在、doctor 没跑起来时，按下方「解释器获取链」第 2 步先解决解释器。）

doctor 跑完会一次性输出全部环境信息到 stdout——无回显环境里 stdout 是空的，用重定向留存结果再读文件：无论任务文件夹是否已建，一律写系统临时目录（Windows 用 $env:TEMP，Unix 用 /tmp，取绝对路径，如C:/Users/<user>/AppData/Local/Temp/__doctor_result.txt），严禁写到工作目录、桌面或用户可见的任何业务目录——用户的工作空间不是技能的垃圾场。不要对着空 stdout 反复重跑命令。它一次性输出：Python 版本与解释器绝对路径（executable）、PATH 中python / py（Unix 为 python3）的真实性——Windows 的 python 常是 Microsoft Store占位程序（exitCode 0 但什么都不执行，doctor 会直接标出），这种绝不能拿来跑脚本、工作目录、技能脚本目录是否就位、shell_env（当前 shell 对 head/tail/wc 等Unix 工具的可用性——Windows 下普遍缺失，见下方 shell 命令规则）、venv 与四类依赖（python-docx / openpyxl / pypdf /pdfplumber）状态、report/ 运行记录状态、next_hint（照做即可的行动建议）。依赖状态分开标注「可用（venv）/ 可用（全局）/ 缺失」：doctor 直接探测工作目录.venv 的 site-packages，依赖装在 venv 里时不会误报缺失（旧版会误报并导致重复安装，已修复）。

解释器获取链（按序取第一个可用的，找到即停）：

1. doctor 命令跑通了 → 直接用 doctor 输出的 executable（首选 WorkBuddy 受管 Python）；
2. 受管 Python 路径不存在导致 doctor 没跑起来 → 按候选顺序做唯一允许的甄别动作：

<候选命令> -c "print(1)"——有真实 stdout 输出才算可用（Windows 的 python 常是Store 占位程序：exitCode 0 但无输出，必弃）；候选顺序：Windows py → python，Unix python3 → python。拿到后用它跑 doctor，回到正常流程；

1. 都不可用 → 用平台自带的运行时安装能力静默装一个受管 Python（如 WorkBuddy / CodeBuddy

的 binary 安装工具，python 类型，选 3.11+），装完用工具返回/版本目录下的解释器绝对路径重跑 doctor 确认，用户全程无感；

1. 平台连运行时安装能力都没有 → 这才需要用户参与，按「环境准备失败的沟通口径」说明。

依赖按需安装（缺什么装什么，装过的绝不重装）：看完 doctor 输出按标注行动——

• 「可用（venv）」→ 什么都不装，后续脚本一律用 .venv 内解释器运行；
• 「可用（全局，venv 中没有）」→ 也无需安装（全局包可直接 import）；
• 「缺失」→ 只装缺的那个包，禁止把四个包整批重装——重复整批安装是用户反馈

"装依赖慢"的主要原因之一。

按上传文件类型推导要装什么（不要提前装用不上的）：

（extract_text.py 的 PDF 解析链为 pdfplumber → pypdf → PyPDF2，装了 pypdf 即可完成常规解析，pdfplumber 只为签章取证加装。）

多个缺失包可合并成同一条 pip 命令安装，避免多次拉起 pip。

必须安装到隔离虚拟环境（venv），不要直接 pip 装到全局（venv 已存在则直接复用，跳过建 venv 这步）。唯一例外（venv 模块缺失的降级）：个别平台受管 Python 是embeddable 精简发行版，<python> -m venv .venv 报 "No module named venv / ensurepip" 时不要反复重试建 venv——受管解释器本身就是平台隔离安装的，此时允许直接<python> -m pip install ... 装进受管解释器（后续脚本继续用 executable 运行即可），doctor 复检时依赖会显示「可用（全局）」同样算就绪。pip 一律通过 venv 内解释器以 -m pip 方式调用（不直接起pip / pip.exe，避免 PATH 污染和 Bash 兼容问题），优先走国内镜像源（默认中科大源），换源降级用一条命令自动完成，不要一轮一轮试（每多一轮就多一次"卡住"的体感）：

# Windows（建 venv 用 doctor 的 executable；<缺失的包名> 只填 doctor 标「缺失」的）
C:/Users/Administrator/.workbuddy/binaries/python/versions/3.13.12/python.exe -m venv .venv
.venv/Scripts/python.exe -m pip install --prefer-binary --timeout 30 -i https://pypi.mirrors.ustc.edu.cn/simple/ <缺失的包名> 
  || .venv/Scripts/python.exe -m pip install --prefer-binary --timeout 30 -i https://pypi.tuna.tsinghua.edu.cn/simple <缺失的包名> 
  || .venv/Scripts/python.exe -m pip install --prefer-binary --timeout 30 -i https://mirrors.aliyun.com/pypi/simple/ <缺失的包名> 
  || .venv/Scripts/python.exe -m pip install --prefer-binary --timeout 30 <缺失的包名>

# macOS / Linux（镜像源级联同 Windows：|| 依次接清华源、阿里源、官方源）
python3 -m venv .venv && .venv/bin/python -m pip install --prefer-binary --timeout 30 -i https://pypi.mirrors.ustc.edu.cn/simple/ <缺失的包名>

装完必须复检（闭环，不可省）：安装命令 exitCode 0 ≠ 装成功（可能装进了全局或别的解释器）。装完重跑一次 doctor 并读 stdout 输出，确认对应 deps:* 从「缺失」变成「可用（venv）」才算就绪；复检仍「缺失」→ 对照 executable 与 .venv路径排查是不是装错了环境，对准 venv 解释器重装一次。

脚本调用一律用 doctor 输出的 executable 绝对路径；依赖装进 venv 后，后续脚本要改用 .venv 内解释器（Windows .venv/Scripts/python.exe、Unix .venv/bin/python）。除 doctor.py 这一条外，不得再执行任何环境类命令；目录列举、路径拼接、文件查找全部用 Python 完成（本技能脚本只依赖 Python 解释器）。

shell 命令兼容性（硬规则，Windows 机器上尤其重要）：head / tail / wc / grep / sed / awk 等 Unix 文本工具在 Windows 的 cmd/PowerShell 里普遍不存在 （doctor 的 shell_env 行会明确列出缺哪些），调用只会报「不可用」浪费交互轮次——任何文件读取、行数统计、文本截取一律用 Python（extract_text.py / python -c）完成，不要先试 Unix 命令再回退；建目录同理用 Python os.makedirs（PowerShell 的 mkdir语义与 Unix 不同，混用参数会报错）。以 doctor 的 shell_env 行为准，不做任何额外试探。

环境准备失败的沟通口径（只有走到这一步才开口）：解释器获取链 4 步全走完仍没有可用 Python（含安装受管 Python 失败）、venv 创建失败、或四个源装完复检仍是「缺失」——先把整个安装链静默完整重试一轮（重试前删掉可能有问题的 .venv 重建），仍失败才停下来告知用户。话术生活化、给用户明确的检查方向和下一步选择：

我在准备文档解析工具时遇到了点问题——可能是网络连不上下载源，也可能是沙箱环境

或防火墙把下载/安装动作拦住了。麻烦您帮忙检查一下：

① 网络是否正常（能否正常打开网页、下载文件）；

② 沙箱环境是否限制了文件下载或程序运行；

③ 防火墙 / 安全软件是否拦截了下载或安装。

处理好之后跟我说声"再试一次"就行，我马上从头重试；已经完成的进度不会丢。

不提 Python / pip / venv / 镜像源任何一个词（"网络""沙箱环境""防火墙"按需提）；用户示意重试就从「解释器获取链」重新走一遍（此时若 venv 已建好则直接装包，不必推倒重来）。

工作流程

使用审计（每次触发必做，最先执行）

技能被触发时，在执行其他步骤之前，先发送一次审计请求：

<executable> scripts/audit_usage.py

<executable> 即 doctor 输出的 Python 解释器绝对路径（与后续脚本使用同一个解释器）；doctor 尚未运行时，按「解释器获取链」先确定可用的解释器再执行本步骤。禁止用裸 python 命令——Windows 的 python 常是 Microsoft Store 占位程序，exitCode 0 但什么都不执行。

脚本仅发送技能ID，不收集任何系统或用户信息。

审计失败不影响主流程——网络不通、SSL 异常、接口无响应等任何情况均静默跳过，不中断检查。脚本退出码始终为 0。

本审计仅发送技能 ID，不发送任何标书内容，不违反「安全与保密约束」中"不联网"条款（该条款针对标书内容不外传，审计元数据不在限制范围）。

文件角色识别（上传后第二步）

用户常一次丢进来多个文件，文件名是最省事、最稳的线索。先按文件名判定每个文件是招标文件还是投标文件，判不出的再按正文骨架判定——角色判错会让后面整条流水线跑偏（把投标文件当招标文件，出的报告全是错的）。判定结果写入 meta.tender_file / meta.bid_file。

识别本身不是独立阶段，也不产生额外交互：一旦判出角色，就顺着「阶段 0 → 1 → …」原样往下跑，闸门只卡两层——"手上有没有招标文件 + 投标文件"与"数量是否在限额内（1 份招标 / 3 份投标）"；只有下面第三步（名称和正文都判不出）才需要问用户一次。

第零步：先解开压缩包（用户上传了 .zip / .tar / .tar.gz 等压缩包时，在任何识别之前执行）：

• 解压一律用 Python 标准库（zipfile / tarfile），**严禁依赖 PowerShell

Expand-Archive、tar.exe 等系统命令**——本技能用户基本都在 Windows 上，各机器 shell 能力参差（doctor 的 shell_env 行已探明），Python 标准库是唯一稳定口径

• 解压位置：任务文件夹已建 → <任务目录>/tmp/unzip/；尚未创建（识别阶段就遇到）→

系统临时目录下 __unzip_<时间戳>/（Windows 用 $env:TEMP，取绝对路径），严禁写到工作目录或用户业务目录，后续全程用绝对路径引用解压出的文件

• 数量闸门按解压后的内容清点：压缩包本身不算一份输入，解压出的每个文件都参与

角色识别与闸门计数（超限照样拦截）；嵌套压缩包（包里有包）逐层解开直到见文件为止

• 安全解压：解压前检查成员名，拒绝绝对路径（C:...、/...）与含 .. 的路径

（zip-slip 路径穿越防护）；tarfile 在 Python 3.12+ 用 extractall(filter="data")

• rar / 7z 不支持（标准库解不了）：提示用户改传 zip 或直接传解压后的文件，

不要尝试找系统里的 WinRAR/7-Zip（存在性与版本都不可控）

• 平台对压缩包的"摘要解析失败"提示（如 fail: 不解析...）无需处理——

技能读文件靠 extract_text.py，不依赖平台预览

第一步：按文件名判定（只看主文件名，不看扩展名）：

判定顺序（强特征优先，判出即继续，不停下来复核）：

1. 只命中一侧强特征词 → 判为该角色，直接继续跑后续步骤（如「XX平台招标文件」→ 招标文件，「XX公司投标文件」→ 投标文件）
2. 无强特征命中时看弱特征：只有一侧命中 → 同样按该角色继续跑，不额外做复核动作、不追问用户；

万一判错，阶段 1 的 --mode outline 会立刻暴露，到那时按阶段 1 的正常流程纠正即可

1. 两侧强特征都命中（如"招标文件及投标文件"被合并成一个文件）、两侧都没命中，

或文件名无意义（1.pdf、扫描件.pdf、文档(1).docx）→ 转第二步

招标文件常夹带"投标文件格式"附件，但主文件名不会因此改变角色——强特征只命中招标侧就仍判

招标文件，不要因为文件名里出现"投标"二字就改判。

第二步：按正文骨架判定（只在第一步判不出时才做，成本很低）：

python scripts/extract_text.py 待定文件.pdf --mode outline

只看骨架即可判定，不要为了判定角色把全文读进上下文。

第三步：名称与正文都判不出时（扫描件无文本层、文件本身是招标+投标的合并扫描册等）——这是唯一需要问用户的情形：按「与用户沟通」的口径，把它并入阶段 0 那次提问一起问清（哪个文件是招标文件、哪个是投标文件，顺带确认是否检查签字盖章），不要单独再开一轮追问。

整体路径判定（角色判完后，先过数量闸门，再按下表接回原有流程；识别只负责"分拣"，不改变任何后续阶段的做法）：

数量闸门（角色判完后立即清点，先于一切后续动作）：统计已判定角色的文件数——招标文件 >1 份或投标文件 >3 份时，不进入任何后续阶段（不建任务文件夹、不跑阶段 0–7、不创建任何中间产物），按「与用户沟通」的超上限话术告知用户一次最多只能上传 1 份招标文件、3 份投标文件；停在原地等用户修正（删减或重新上传），修正后从头重新识别文件角色再继续，不要基于旧判定直接续跑。用户分批补传导致累计数量超限的（如已传 1 招标 + 2 投标，又补 2 份投标），同样按本闸门拦截——清点口径是当前会话累计持有的文件总数，不是单次上传数。

同一招标文件（1 份）+ 多份投标文件（最多 3 份）时，走「多标书对比」。

阶段 0：确认前提

角色识别一判出「招标文件 + 投标文件齐全」，就直接进入本阶段、直接开跑，不因识别而多一次停顿或交互。本阶段的确认只在完整符合性检查模式下做——只有招标文件（解析模式）或只有投标文件（不执行）时，不问盖章开关。

开始任务前只需要向用户确认一件事：是否检查签字盖章类内容（见下方「盖章类检查开关」）。这是执行前唯一必须的用户交互，不要把其他问题混进这一次提问里，也不要拆成多轮追问。

阶段 0 的其他信息（项目类型、投标人全称、投标截止时间、纸质/电子标、检查详略程度等）一律从文件名和正文中自动推断——推断不到的，在报告中注明"未识别到"即可，不要在执行前向用户追问；只有"盖章类检查开关"才需要用户拍板。

盖章类检查开关（执行前唯一必问交互）

进入符合性检查（招标文件 + 投标文件齐全）后、开始跑阶段 1 之前，只向用户确认一次「是否检查签字盖章类内容」——独立成一次提问，不与任何其他问题捆绑。参考话术：

开始检查前跟您确认一件事：标书里"签字盖章"相关的核验（投标函签字盖章、骑缝章、

电子签章等是否齐全）要不要一并检查？这类问题是常见的废标原因，默认会查；

如果您那边已经单独核过章，回复"不用查盖章"即可，我就跳过这部分。

用户回复的判定口径：

"盖章类检查"指对签字 / 盖章 / 签章 / 骑缝章 / CA 签章存在性的核验，用户拒绝时跳过以下环节：

两点注意：

• 阶段 2 的要求抽取不受影响：招标文件中的签署盖章要求仍照常抽进要求清单（尺子保持一致），

只是不做核验；对应矩阵条目 status 填「不适用」并在 remark 注明「应用户要求跳过签字盖章类核验」，不得因跳过而判"未响应"或直接从清单中删除。

• 范围只限签章存在性：签字盖章之外的检查（授权委托书内容有效性、格式完整性、名称一致性等）

照常执行——跳过的是"有没有签/有没有盖章"，不是"授权书该不该有"。

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

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

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

• 评分项只抽取 item / nature / max_score / basis（评分规则与依据），est_range / risk / bid_ref

留空——没有投标文件就没有估算与风险可言

• 招标文件自身的跨章节矛盾（G2/G3，如工期/质保在不同章节口径打架）仍属于解析产物，

可列入 findings（问题清单），这是给用户的澄清线索

• 告知用户：本次解析产出的要求清单 R 可复用，投标文件就绪后直接继续跑阶段 3–5 完成完整检查
• 不得因为"没有投标文件可比对"就把解析报告写成检查报告——两份报告的标题、结论口径完全不同

任务目录（每个任务一个文件夹）

每个任务使用一个独立文件夹，本次任务的全部中间产物与最终报告（extracted.json、consistency.json、merged.json、HTML 报告）都收口在该文件夹内，不在任务文件夹外散落任何文件（唯一例外：工作空间根目录的 report/ 运行记录文件夹，见「阶段 7：登记运行记录」）。

任务文件夹的创建（角色识别完成、进入阶段 1 之前执行一次）：

前置检查——同项目判定：用户上传招标文件并解析出招标编号（tender_no）后，创建任务文件夹之前，先运行工作空间检查：

python scripts/check_workspace.py --tender-no <招标编号>
# 输出三种结果（退出码 0/0/2）：
#   EMPTY  工作空间暂无运行记录 —— 直接继续
#   MATCH  已有同编号记录（同一项目）—— 可继续运行，沿用本项目历史（重点检查项、
#          项目名锁定等按同一项目衔接）
#   WARN   已有运行记录但编号都对不上 —— 必须先把提示原文转述给用户：
#          【当前工作空间下已有其他项目的招标文件运行记录，建议新建任务切换工作空间再运行】
#          由用户决定：用户确认仍要继续时，照常新建任务文件夹运行；
#          用户同意切换时，停止本工作空间的检查流程

python scripts/init_task.py <项目简称>
# 例：python scripts/init_task.py XX污水厂提标改造
# 输出：.../投标符合性检查-XX污水厂提标改造-20260914-1530/

• 文件夹名 投标符合性检查-<项目简称>-<时间戳>，平铺在会话工作空间根目录下（即 agent

执行命令时的当前工作目录；WorkBuddy 场景就是用户选中的工作空间）；项目简称从招标文件名 / 封面项目名称推断，推不出时用招标编号，再不行用「未命名项目」

• 任务文件夹位置与输入文件所在位置无关：用户粘贴、拖拽上传的文件可能仍留在原盘原目录

（如 C:UsersxxxDesktop招标文件.pdf），此时不得把任务文件夹建到文件旁边、不得 cd 到文件所在目录执行命令、不得把 --cwd 指向文件所在目录——一律在工作空间下python scripts/init_task.py <项目简称> 原地创建，用绝对路径引用 C 盘/D 盘任意位置的输入文件即可

• 创建后记住该路径，后续所有脚本的 --out / --out-dir 一律指向该文件夹（或其子目录）

"一个任务"的边界（判断要不要新建文件夹，全部依据下表，不要凭感觉）：

agent 没有跨会话记忆：新会话（包括用户在 WorkBuddy 里点"新建任务"、工作空间没变的情况）一律视为新任务、新建文件夹；想续旧任务必须走上表最后一行的指认流程。

投标人子目录（单标书与多标书统一）：符合性检查无论 1 份还是多份投标文件，所有投标人共用同一个任务文件夹，且一律按投标人建子目录（如 国源/、通办/），各投标人自己的 extracted / consistency / merged / 报告放各自子目录；招标文件提取结果（tender_extracted.json）与多标书时的共享要求清单 R、汇总对比矩阵、横向对比报告放任务文件夹根目录。目录结构必须保持如下形态（多标书示例；单标书即只有一个投标人子目录、没有横向对比报告，其余完全一致）：

投标符合性检查-<项目>-<时间戳>/
├── tender_extracted.json              # 共享：招标文件提取结果（根目录）
├── 横向对比报告.html                   # 多标书才有：横向对比（根目录）
├── 国源/
│   ├── extracted.json / consistency.json / merged.json
│   └── 投标符合性检查报告-<国源投标人全称>.html
└── 通办/
    ├── extracted.json / consistency.json / merged.json
    └── 投标符合性检查报告-<通办投标人全称>.html

投标人的 extracted / consistency / merged / 报告一律写进该投标人子目录，单标书也不例外——即使只有 1 份投标文件，也按投标人名建子目录，与多家时保持一致；严禁带 投标人_ 前缀散落在任务根目录（国源_extracted.json 放根目录属于放错位置）。万一写错了也不必返工：交付前 cleanup_task.py 会把根目录的 <投标人>_*.json中间产物自动归位到对应子目录。

文件卫生（收口不只是"不散落在文件夹外"，文件夹内同样不许堆垃圾）：

任务文件夹最终只应保留三类东西——中间产物 JSON（extracted.json、consistency.json、merged.json）、HTML 报告（含各投标人子目录内的报告与根目录横向对比 HTML）、以及投标人子目录（单标书同样按投标人建子目录）。执行过程中严禁把临时产物散落在任务文件夹里：

• extract_text.py 的 outline / search / 分段读取结果优先直接读命令 stdout，不要落盘；

确因输出过长被工具截断读不全时，才允许重定向落盘，但文件必须写到 <任务目录>/tmp/ 下（如 tmp/__outline_gy.txt，__ 前缀便于清理识别），严禁写到任务文件夹外（写到 cwd、系统 temp、用户目录都属于散落垃圾）；交付前 cleanup 会连同 tmp/ 一并删除

• 落盘重定向必须使用绝对路径指向 <任务目录>/tmp/，禁止 > __xxx.txt 这类相对路径——

相对路径落点随 cwd 漂移，是工作空间根目录出现散落文件的直接原因；任务文件夹尚未创建时不允许落盘：要么先按流程执行 init_task.py 建目录再提取，要么缩小读取范围（分段 offset/limit）坚持走 stdout，不得以"目录还没建好"为由写进 cwd

• 临时文件名统一 __ 双下划线前缀（__outline_gy.txt、__doctor_result.txt），

禁止自创单下划线变体（_outline_gy.txt 这种）——命名漂移会让清扫模式失配、文件永久残留；所有落盘文件都按这个前缀约定命名

• pip 安装输出不落盘：直接读命令 stdout/stderr 判断结果，禁止 > pip_log.txt 之类

重定向（安装是否成功以 doctor 复检为准，日志没有留存价值）

• 确需脚本取证（如电子签章检测的 pdfplumber 探测）时，临时脚本与输出统一放

<任务目录>/tmp/，不与正式产物混放；脚本内所有路径（输入文件、输出文件、任务目录常量）一律写绝对路径，严禁 TASK + '/../..' 这类相对层级拼接——层级心算极易出错（任务文件夹通常只在工作空间根目录下一层，一个 ../ 即到根），拼错直接 FileNotFoundError

• 不在任务文件夹内写日志文件（*.log、*.err）；命令报错直接读 stderr 即可
• 任务文件夹内出现 .py 文件一律视为临时取证脚本，放在 tmp/ 下

交付前清理（必做）：报告生成后、告知用户路径前，执行：

python scripts/cleanup_task.py <任务目录>
# --dry-run 只预览不删除

脚本只在任务文件夹内部清理：删除 tmp/ 整目录，以及按技能自有指纹匹配的临时文件（_raw_*、outline_*、report_log*、__* 双下划线前缀、doctor_result*、pip_log* 等），只留下中间产物 JSON 与 HTML 报告。不使用 *.py/*.log/*.err/*.txt 等通用扩展名通配，也不触及任务文件夹之外的任何目录——即使任务目录路径传错，也不会批量误删用户文件。本技能的临时文件一律写系统临时目录（见「文件角色识别」前的环境准备与「文件卫生」规则），工作目录中不应有残留；万一发现散落文件，逐个按确切文件名删除，不做通配清扫。清理后再向用户交付。

阶段 1：提取与结构化

所有中间产物放在本次任务文件夹（见「任务目录」一节，下文以 <任务目录> 指代）下，投标文件侧产物一律放其投标人子目录 <任务目录>/<投标人>/（单标书也建，见「任务目录」）。

python scripts/extract_text.py 招标文件.pdf 投标文件.docx --out <任务目录>/<投标人>/extracted.json

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

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

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

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

search 参数必须根据大纲动态构造，下面只是五分类各一组示例——不要照搬，要根据招标文件实际章节标题和关键词替换。 每个分类至少搜一轮，确保不漏：

# 资格类
python scripts/extract_text.py 投标文件.docx --search "业绩|类似项目|已完成项目" --context 100
# 强制性/否决类
python scripts/extract_text.py 招标文件.pdf --search "否决|无效|实质性|必须|不得" --context 60
# 技术类（最易遗漏——技术需求书章节标题各异：采购需求、服务标准、功能要求、技术规格等，
#   务必先看大纲锁定章节名后再构造搜索词）
python scripts/extract_text.py 招标文件.pdf --search "技术|参数|指标|性能|配置|方案|功能|规格" --context 80
# 商务类
python scripts/extract_text.py 招标文件.pdf --search "报价|付款|工期|质保|违约|合同" --context 60
# 形式/递交类
python scripts/extract_text.py 招标文件.pdf --search "签章|密封|格式|递交|组成|装订" --context 60

大文件读中间章节用 --mode text --pages 15-30（按页码范围，PDF 有效；解析阶段即跳过范围外的页，指定页之外的内容不耗时提取）；--mode text --max-chars 50000 只能从头截断，读不到文档中部。读取节奏（直接决定总耗时）：--pages 范围一次给足（整章/整节，如 --pages 22-100），严禁每次只读几页、十几轮往返——每次调用都有进程启动与文件打开的固定开销；同一文件已生成 extracted.json 后，后续精读/检索优先用 Python 直接读 JSON 的files[].blocks[]（零解析成本），不要再对原始 PDF 反复跑提取。

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

建立要求清单 R，每条含：编号 | 类型 | 条款原文摘要 | 出处(章节+页码) | 所需证明材料。

type 取值（决定 HTML 报告的分类章节归属，必须按此枚举填写）：

关键：实质性条款（★/▲）的 type 必须填 强制性，不要填成 技术 或 形式——否则 HTML 报告的"强制性要求"分类章节会因无条目而整段省略，废标风险项就漏在分类矩阵之外了。前附表里写明"不满足则废标/无效投标"的资格或商务条款，即便本质属资格/商务，也按否决口径优先归 强制性，并在 score_impact 注明"不满足则废标"。

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

五分类完整性校验（阶段 2 抽取完成后必做）：检查 R 中五种 type（强制性/资格/商务/技术/形式）是否均有条目。技术类最易遗漏——技术需求书章节标题在不同招标文件中差异极大（"采购需求""服务标准""功能要求""技术规格""项目需求""建设内容"等），仅按固定关键词搜索容易跳过整块章节。校验步骤：

1. 抽取完成后，清点 R 中各 type 条目数；若某 type 为 0 条，按优先级回补：
2. 技术类缺失：回到大纲，找到技术需求/采购需求/服务标准对应章节，用 --search 按该章节

标题关键词检索，精读后补抽条目；

1. 商务类缺失：检索报价/付款/工期/质保/合同条款章节；
2. 形式类缺失：检索签字盖章/密封/装订/递交要求；
3. 资格类缺失：检索资格条件/资质/业绩/人员要求；
4. 强制性缺失：检索★/▲标记与前附表否决项——通常不会缺失（前附表几乎都有），

若确实没有，则不强凑（某些简单磋商项目确实无实质性条款标记）。不得因为"搜不到"就跳过——换同义说法再搜一轮（技术→功能/参数/指标/规格/方案；商务→价格/报价/合同/交付；形式→签章/密封/装订/组成），仍搜不到再如实留空，但需在 unrecognized 中记录"未检索到 X 类要求"以留痕。

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

• 基本信息 → meta：招标编号、招标人、代理机构、项目类型、预算/最高限价、

投标方式（纸质/电子）、投标截止与开标时间、投标有效期

• 时间节点 → timeline：公告发布、澄清/答疑截止、投标截止/开标、

投标有效期届满、合同签订期限

• 否决条款与无效投标情形 → focus_clauses：无效投标情形（否决条款）、围标串标审查条款、

特殊限制条件（联合体、进口设备、分包限制等）

• 技术需求与实质性条款 → tech_spec：需求清单、技术指标参数、★实质性条款标记、遵循标准/规范

遇到以下情形的条款，记录原文片段与位置（章节/页码），存入unrecognized 数组，最终进入报告附注——不得因无法归类而静默丢弃，也不得硬塞进 matrix 判"存疑"了事（判定存疑由阶段 3 处理，阶段 6 统一汇总）：

• 无法归入已知类别（强制性/资格/商务/技术/形式）的条款
• 引用未随附的外部附件、图纸、检测报告（条款指向的附件不在投标文件包内）——标"存疑"，不得直接判"未响应"
• 跨章节口径冲突未决、需向招标人澄清才能定性的条款
• 提取失败/解析不完整的嵌套表格、图片化条款

unrecognized 每条字段：location（章节+页码）/ excerpt（原文片段）/reason（问题类型，见下方枚举）/ suggestion（建议处理方式）。附注章节空与不空取决于这个数组——工程/货物/服务采购的招标文件几乎总有几条无法干净归类的条款，留空通常是抽取遗漏而非"全部 cleanly 归类了"。

reason 枚举（标记存疑来源，便于附注分类展示）：无法归类 / 附件缺失 / 冲突未决 / 提取失败 / 判定存疑 / 自动检查存疑 / 签章存疑——前四类在阶段 2 产生，后三类在阶段 3 / 5 / 5b 产生、阶段 6 汇总时补入。

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

阶段 3：逐条判定

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

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

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

按效力优先级（前附表/专用条款 > 通用条款）判定并提示向招标人澄清，投标只响应了其中一个版本判"存疑"

判定为"存疑"的条目：除在 matrix 标 status=存疑 外，必须在 remark 写明存疑原因（歧义点、缺何材料、需向谁澄清），并保留投标文件位置与原文摘录——这些条目会在阶段 6统一汇总进 unrecognized 附注，让用户在附注一眼看清"哪些条目待人工复核、需要补什么"。

用户拒绝盖章类检查时：签署盖章类条目（A1/A3/A7、E1 等"是否已签字/盖章"的核验）不做判定，矩阵 status 填「不适用」、remark 注明「应用户要求跳过签字盖章类核验」；其余判定照常。见阶段 0「盖章类检查开关」。

阶段 4：评分点覆盖

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

阶段 5：自动一致性检查

python scripts/check_consistency.py --extracted <任务目录>/<投标人>/extracted.json --bidder "某某建设有限公司" --out <任务目录>/<投标人>/consistency.json

用户拒绝盖章类检查时，加 --skip-seal 跳过"签字盖章位疑似未签署"项：

python scripts/check_consistency.py --extracted <任务目录>/<投标人>/extracted.json --bidder "某某建设有限公司" --skip-seal --out <任务目录>/<投标人>/consistency.json

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

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

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

脚本产出的问题编号形如 C001（--prefix 默认 C 的流水号），与

references/eligibility_checklist.md 的 A–G 检查项编号（A1、C1 等）是两套互不相同的

编号体系——报告中引用检查项时以清单编号为准，不要把脚本流水号当成清单分类号。

阶段 5b：电子签章检测（PDF 投标文件必做；用户拒绝盖章类检查时整段跳过）

用户在阶段 0 拒绝盖章类检查时，本阶段整体跳过——不跑 pdfplumber 取证、不下任何"无签章"结论，报告检查范围中注明"未执行电子签章检测"。

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

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，写入投标人子目录<任务目录>/<投标人>/merged.json。

⚠️ 硬性要求（不可跳过）：

1. 报告必须由 scripts/build_report.py 生成，禁止手写 Markdown。

检查完标书后自己拼一版 Markdown 是本技能最常见的出错方式——手写报告会

丢失报告结构规范（references/output_guide.md）要求的章节、脱敏、主观/客观分标注，

且结构与模板不一致。无论如何都不得绕过脚本。

1. merged JSON 必须包含 findings_template.json 里的全部顶级字段：

`meta / timeline / tech_spec / scoring / matrix / findings / focus_clauses /

unrecognized / conclusion`。

其中 tech_spec 从招标文件抽取后填充（阶段 2 已说明），不得留空——留空会导致对应章节被省略。

meta.bidder 必须填投标人当前工商注册全称（营业执照现用名），不得把更名备注整串

并进名称（如"芯创（安徽）科技有限公司（2024-10 变更为…）"）——新旧名称混用等

更名沿革写入对应问题的 evidence / remark 即可。脚本会自动剥除这类备注兜底

（能提取出"变更为 X"时取 X），但源头填对才能保证报告展示与历史比对按同名投标人正确关联。

另外按阶段 0 的交互结果在 meta.check_scope 写入检查范围说明：用户拒绝盖章类检查时

填"应用户要求未执行签字盖章/签章类检查（含电子签章检测）"，默认执行时填

"含签字盖章/签章类检查"——该字段由 build_report.py 渲染进报告头与检查信息，

让读者一眼看清本次结论不包含签章维度，避免误把"未查出"当"没问题"。

1. 生成后必须做「报告结构自检」（见下），确认 8 章 + 附注齐全再交付。

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

severity 取值 fatal/major/minor/info。category 取值与 matrix.type 同口径，五选一：强制性 资格 商务 技术 形式（报告中"形式"显示为"格式/递交"）。问题须按其所涉要求面归类，不得使用"问题类型"词作为 category：

• 评分点缺失 → 按评分项所属面（技术评分点→技术、商务评分点→商务、业绩评分点→资格）
• 内部一致性问题 → 按不一致内容所属面（如报价大小写不一致→商务）
• 响应遗漏/符合性问题 → 按未响应要求所属面
• 签字盖章/格式/密封/装订类 → 形式
• 实质性条款未响应 → 强制性

不得填 评分点/内部一致性/响应完整性/符合性/资格性/形式要求 这类词——它们是"问题类型"而非要求面。脚本对这类值会按问题原文（要求/影响/建议）推断所属要求面兜底，但推断是启发式的、可能出错，源头必须按上述规则填对。定级标准见 references/output_guide.md。

存疑汇总（必做，合 JSON 时执行）：扫描全部产物，把所有"无法确定结论或存疑"的项统一汇入 unrecognized 数组，最终在附注章节集中展示。来源与处理方式：

汇总要求：

• 不得遗漏：凡是上述触发条件命中的，一律在 unrecognized 留一条；漏掉等于把"待人工复核"的边界藏起来，用户会误以为"已查清没问题"
• 不重复计数：阶段 3 存疑条目本身已在分类矩阵展示（带"存疑"状态标签），附注里以"摘要引用"形式列——excerpt 写"要求序号 X：[条款摘要]"指向 matrix，suggestion 写存疑原因与需何材料；不要在附注里把整条原文再抄一遍
• unrecognized 至少包含阶段 2 来源的条目——判定存疑、自动检查存疑、签章存疑视本次检查实际情况而定，有则汇入，没有不强凑

生成报告：

python scripts/build_report.py --data <任务目录>/<投标人>/merged.json --format html --out-dir <任务目录>/<投标人> --name "投标符合性检查报告"

文件名固定规范：符合性检查报告最终一律落盘为 投标符合性检查报告-<投标单位名称>.html（投标人全称取自 merged.json 的 meta.bidder，脚本自动拼接并替换调用方传入的简称后缀；文件名不含投标人名的旧版报告曾导致 report/index.html 链接归属失败）。无需在 --name里手工拼投标人名。

--out-dir 必须显式传入任务文件夹内的投标人子目录，保证报告与中间产物同处一个文件夹；即便忘了传，脚本也会在当前工作目录自动创建 投标符合性检查-<项目简称>-<时间戳>/ 兜底（不会散落到当前位置），但显式传入才是正确流程。

报告头「检查结论」下方，若有「重点检查项」（即运行记录的 focus_items 非空），脚本会自动渲染一条琥珀色友好提示卡：

本次检查重点：本次除常规检查外，重点加强了对 XXX 点的检查。

XXX = 本次重点检查的大分类（资格/商务/技术/格式递交等，运行记录 focus_items 字段决定）；提示卡在 focus_items 为空时不渲染占位（避免"暂无"也硬塞一行）。运行记录的focus_items 由 build_run_index.py 自动从上一次矩阵中判"未响应/部分响应/不符合"的大类推导，无需手动指定。手动指定场景（如临时想强制提示某分类）可通过 --focus 显式传入（可多次、支持顿号分隔），此时覆盖运行记录里的自动推导值：

python scripts/build_report.py --data <任务目录>/<投标人>/merged.json --out-dir <任务目录>/<投标人> 
    --name "投标符合性检查报告" --focus 商务 --focus "资格、技术"

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

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 文件（含横向对比报告；build_report.py 已停用 md/xlsx 输出，传入 --format md 或 --format xlsx 都会被跳过并提示），用户要文本类或表格类内容时直接在对话中给出，不落盘文件。

手写生成的报告（横向对比等 build_report.py 不覆盖的汇总类 HTML）底部不得附带"本报告由…自动生成/人工复核""本产品由…支持"之类乱七八糟的生成说明或归属文案——正文结束即结束，不要自己编 footer。build_report.py 生成的标准符合性检查/解析报告不在此列，其 footer 由脚本模板统一输出，不要手工改动。报告主标题为 # {项目名称} 投标文件符合性检查报告。检查结论置于报告头部（生成时间下方），而非独立章节。单份报告内不附历史比对——历史版本间的数量对比由用户在report/index.html 的「上一次结果」区块自行查看，报告只呈现本次检查结果。正文中的身份证号（前6后4）、手机号（前3后4）由脚本自动脱敏；企业名称、金额、项目编号不脱敏。

完整目录依次为（HTML 为唯一交付格式，面向页面汇报优化）：报告头（项目概况信息 + 检查结论 + 源文件）→ 风险概览 → 废标问题清单 →五分类章节 → 问题清单详情 → 评分点覆盖与得分预估 → 附注：

1. 风险概览——问题总数与 致命 / 严重 / 建议 / 提示 四张统计卡，点击可跳到「问题清单详情」
2. 废标问题清单——全部问题概览表：问题序号 / 严重度 / 问题名称 / 问题详情，

详情列为「详见『问题清单详情』」锚点链接（指向 #find-<问题编号>）

1. 强制性 / 资格 / 商务 / 技术 / 格式递交——五个分类章节（仅在有对应数据时出现）：

响应完整性矩阵按 matrix.type 归类拆分（强制/实质→强制性，资格/资质→资格，商务/报价/合同→商务，技术→技术，形式/格式/签章/递交→格式递交），分类章节内只放矩阵表（列为

/ 招标文件要求 / 出处 / 投标响应情况 / 状态 / 评分影响 / 备注），不放问题卡片；

无法归入五类的要求并入「其他」分类章节（按需出现）

1. 问题清单详情——全部问题卡片集中成一章，按 致命 / 严重 / 建议 / 提示 分组排列，

卡片含问题编号 / 严重度 / 分类 / 问题描述 / 招标要求出处 / 投标文件位置 / 后果 /证据摘录 / 定位（最多 3 处）/ 整改建议，顶部提供按严重度筛选的按钮

1. 评分点覆盖与得分预估——含主观分/客观分标注与客观分合计
2. 附注：未识别条款与存疑内容

关键时间节点 / 技术需求与实质性条款 / 否决条款与无效投标情形 / 整改清单章节不在 HTML 中单独成章，保持目录精简——整改动作已含在问题卡片「整改建议」字段；响应完整性矩阵不单独成章——已按 matrix.type 拆分入五分类章节，不重复渲染。

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

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

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

阶段 7：登记运行记录（report/，每次运行结束必做）

阶段 6 报告生成、交付前清理完成之后，执行一次运行记录登记——用户经常需要回看自己跑过的每一次任务、对比整改前后的检查结果，这一步让历史运行集中可查、任意版本报告一键可达：

python scripts/build_run_index.py --task-dir <任务目录>

重点检查项自动生成：第一次运行为空（索引页显示「暂无」）；从第二次运行起，自动取同一项目上一次响应矩阵中判「未响应/部分响应/不符合」的大分类作为本次重点（「同一项目」按招标编号 meta.tender_no 优先、任务文件夹简称兜底判定——工作空间穿插检查多个项目时不会串用其他项目的重点；仅矩阵行参与；findings/问题清单不参与——评分点等问题的 category不属于五大分类体系，按关键词推断映射不准确；上一次矩阵中没有此类条目或没有上一次，同样为空）——「已响应」的失分观察项与「存疑」（待人工复核）不参与本口径。用户在对话里明确指定了重点分类时以用户为准，通过 --focus 传入（可多次、支持逗号/顿号分隔，自动归一到大分类）：--focus 资质 --focus '技术、格式递交'。不要把五大类默认全填进去冒充"重点"。

脚本会在工作空间根目录（任务文件夹的父目录）创建/复用 report/ 文件夹：

• report/data.json —— 全部历史运行的记录数组，每条记录包含：本次任务文件夹名、

当前运行工作目录的最终产物（HTML 报告）名称与相对路径、重点检查项（第一次运行为空，之后自动取上一次查出问题的大分类，用户以 –focus 指定时以用户为准；另附各大分类要求条数/问题条数统计）、问题数量列表（致命/严重/建议/提示/总数）、bidder_counts（逐投标人问题数量，多标书用）、previous_run（上一次运行的任务文件夹名与时间，只读 data.json 就能定位上一次是哪次——索引页据此直接展示上一次的各投标人数量表格，不再做差值计算）、project（项目名称，同一项目跨多次检查保持稳定一致，见下方「项目名称稳定性」说明）

• report/index.html —— 运行记录索引页，全部历史运行卡片直接平铺展示

（无筛选控件），最新一次运行排在最上面；每次运行的报告文件以相对路径链接展示，浏览器打开后点击文件名即可跳转查看任意版本的检查报告

执行要点：

• 只要产出了报告就要登记：符合性检查、招标文件解析模式、多标书对比都登记；

多标书任务只登记一条记录（各投标人子目录报告与根目录横向对比报告都收在同一条记录的产物清单里）

• 同一任务文件夹重出报告不产生重复记录：脚本按任务文件夹名原位覆盖该条记录，

并按时间顺序重算全部记录的 previous_run 链

• 项目名称稳定性（索引页 H1 与卡片标题一致性的关键）：

同一项目跨多次检查时，索引页 H1 与每条卡片上的「📌 项目名」必须保持一致——用户经常连续几次跑同一项目的检查，如果每次显示的项目名都不同（agent 抽取meta.project 时每次细节略有差异，如带/不带引号、章节括号样式、空值），会让人觉得「又是另一个项目」。build_run_index.py 的 project 字段按以下优先级取，且同一项目跨记录锁定复用：

1. 跨记录锁定：data.json 中与本次同项目（优先比对招标编号 meta.tender_no，

招标文件换版本时编号通常不变；编号缺失时退回任务文件夹简称比对，如 投标符合性检查-兰考一件事项目-... 中的 兰考一件事项目）的旧记录→ 沿用其 project（最稳定）；

1. 本次 meta.project：agent 从招标文件抽取填入的完整名；
2. 任务文件夹简称：agent 没填 meta.project 时的兜底；
3. 任务文件夹名：最终兜底（含时间戳，最不理想但保证有标题）

卡片头部同时展示项目名 chip（📌 项目名），与任务文件夹名互为补充——文件夹名用于识别本次运行的实例（哪一天跑的），项目名 chip 用于识别是哪个项目

• report/ 是跨任务的持久运行记录，不属于散落文件：cleanup_task.py 不会碰它，

执行「交付前清理」时无需回避；也不计入「任务文件夹外不散落文件」的口径（唯一例外）

• 产物链接基于相对路径（../<任务文件夹>/<报告>.html），交付时提醒用户不要单独移动

report/ 文件夹或任务文件夹，否则索引页跳转会失效

报告类型与多标书对比

不符合触发前提时没有报告：只有投标文件、没有招标文件时，本技能不运行、不产出任何报告，

按上述话术请用户补齐同项目招标文件后再开始；文件数量超上限（招标文件 >1 份或投标文件 >3 份）

时同样不运行、不产出任何报告，按「数量闸门」等用户修正。

多标书对比流程（常见于招标方评标、代理机构清标、投标方自查多版本标书；前提：1 份招标文件 + 2~3 份投标文件——只有 1 份投标文件时不走本流程、不产出横向对比报告，按默认流程出单份完整检查报告即可；超出 3 份已被「数量闸门」拦截）：

1. 要求清单 R 只抽取一次，多份投标文件共享同一把尺子
2. 逐份执行阶段 1、3、4、5，各生成独立 merged JSON 与完整报告，统一放在任务文件夹下各投标人的子目录中（见「任务目录」一节）
3. 横向对比报告默认产出：逐份检查完成、各自交付完整 HTML 报告后，**再自动生成一份横向对比

报告作为总览（多份标书逐份翻看很费劲，一页对比表对用户更友好），格式为 HTML（任何情况下都不产出 Markdown 文件），保存在任务文件夹根目录（与各投标人子目录平级）：每行一个投标人，列出总报价、致命/严重问题数、要求响应率、客观分估算区间、资质与业绩概览；报价与业绩按招标文件同一口径横向可比；HTML 底部同样不得附带生成说明或归属文案。页面结构：横向对比报告不设报告头部**——不放报告主标题、项目元信息表、共性风险提示块，页面直接从第一个二级标题「一、关键维度对比」开始，后续章节依次编号（二、三…）；共性风险等需要提醒的内容并入正文相应章节或末尾附注，不在顶部单独成块。全部报告就绪后执行阶段 7 登记运行记录（build_run_index.py，多标书任务只登记一条，各投标人报告与横向对比报告都在产物清单里）

1. 用户提供多家投标人的文件时，先确认用途为评标/清标等合法场景；

不得用于协助围标串标或横向串通报价

检查项清单

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

输出规范

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

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

边界

• 这是对标检查，不是法律意见；法规适用争议提示用户咨询律师或招标代理
• 不得代用户编造、补齐投标文件的实质内容（业绩、资质、参数承诺）。

可协助拟定承诺函等文本，但必须提示核实真实性后方可使用

• 不得给出"保证中标""一定能过"的判断

交付与结束语（必须）

交付纪律（硬性禁令，逐条自检后再回复）：

1. 产物卡片/预览只允许出现一个：report/index.html。横向对比报告、各投标人报告等

任何单次 HTML 一律不得在对话中打开、预览或作为附件/文件卡片展示——哪怕只是"方便用户直接看"也不行。用户要看的所有报告都从 index.html 进入

1. 最终回复中不得罗列任务文件夹内的单个 .html 文件名或文件夹路径作为交付入口，

交付入口只有一个：report/index.html

1. build_report.py 打印的单报告 file:/// 地址仅供内部使用，不要转述给用户
2. 必须告知 index.html 的本地绝对路径：用户要自己找到并打开这个文件，只写相对的

report/index.html 用户根本不知道它在哪个盘哪个目录——最终回复里必须写出完整盘符路径（如 C:UsersAdministratorDesktoptempreportindex.html，相对路径就拼在当前工作目录下；build_run_index.py 运行末尾打印的「下载地址：file:///…」就是现成的绝对路径，直接采用）

最终回复模板（多标书按此结构逐段照写，单标书去掉通办段与竞争变量段）：

### 结论速览

<一句话总评，如：两家均无废标级硬伤——报价未超限价、交付期限（20 天）/质量要求/磋商有效期（60 天）全部响应，营业执照、各项资格承诺函、信用查询、非联合体声明齐全；风险主要集中在失分项上：>

**固源（<公司全称>，报价 <X> 万，小/中型企业）—— <N> 项严重问题**
1. <要点 1>
2. <要点 2>

**通办（<公司全称>，报价 <X> 万 = 限价，中型企业）—— <N> 项严重问题**
1. <要点 1>

运行记录已登记，本次共 <N> 项问题（致命 <a> / 严重 <b> / 建议 <c>）：
- `<index.html 的本地绝对路径，如 C:UsersAdministratorDesktoptempreportindex.html>`
  ——浏览器打开即见本次运行，点击「查看报告」里的文件名
  可分别打开投标单位的独立报告和横向对比报告（任务文件夹与本次全部产物都在
  `<绝对路径去掉 reportindex.html>` 目录下）

模板要点：摘要必须按投标人分段给出问题计数与要点，让用户不打开报告也能拿到结论；回复内容只围绕本次检查结果本身，不附加任何产品推广、归属声明或营销话术。

交付前确认两件事已完成：按「文件卫生」运行 cleanup_task.py（任务文件夹内只留中间产物JSON 与报告）、按「阶段 7」运行 build_run_index.py（report/index.html 已包含本次运行）。

资源

• scripts/doctor.py —— 运行环境一次性自检（流程第一条命令，见「依赖安装」开头）：

输出 Python 版本/解释器绝对路径、PATH 中 python/py 的真实性甄别（Windows Store占位程序会标出）、工作目录、技能脚本目录、venv 与依赖状态、report/ 运行记录状态、next_hint 行动建议；结果仅输出到 stdout（如需文件可重定向），由 cleanup 兜底清理）；除此之外不得执行任何环境探测命令

• scripts/init_task.py —— 任务文件夹管理：init_task.py <项目简称> 在当前工作目录（即会话工作空间，

与输入文件所在位置无关）创建 投标符合性检查-<项目简称>-<时间戳>/ 并输出路径；--list 列出已有任务文件夹（跨会话续跑指认用）

• scripts/check_workspace.py —— 同项目前置检查：check_workspace.py --tender-no <招标编号>

在创建任务文件夹前运行，比对本次招标编号与 report/data.json 已有运行记录（编号归一比对，忽略大小写/连字符/空格差异）；EMPTY=无记录、MATCH=同项目可继续（退出码 0）、WARN=编号不一致，须把提示原文转述给用户并由用户决定（退出码 2）

• scripts/cleanup_task.py —— 交付前清理：仅在任务文件夹内删除 tmp/ 与技能自有指纹临时文件

（_raw_*、outline_*、report_log*、__* 双下划线前缀、doctor_result*、pip_log* 等），不使用通用扩展名通配（*.py/*.log/*.err/*.txt）、不触及任务文件夹之外的任何目录；只留中间产物 JSON 与 HTML 报告；--dry-run 预览；多标书任务自动把根目录误放的 <投标人>_extracted/consistency/merged.json归位到对应投标人子目录（只移动、不删除）

• scripts/extract_text.py —— 统一提取器（docx/pdf/xlsx/md），支持 outline / 全文 / 正则检索三种模式。

--pages 15-30（可混写：19、15-30、1-30,35,40-）按页码过滤输出，精读 PDF 中间章节一律用它，不要为此现场手写临时脚本（docx/txt 无页码，对该文件不生效并提示）；--from-json <extracted.json> 零解析成本路径：提取过一次后，所有 outline / 精读 /检索都应走这里（毫秒级，不再重解析原始 PDF），可与 --pages / --search / --mode 组合；对原始文件直接 --search 会重解析全文（慢），已提取过的文件禁止用原路径检索

• scripts/check_consistency.py —— 内部一致性自动检查，输出结构化 findings；

用户拒绝盖章类检查时加 --skip-seal，跳过"签字盖章位疑似未签署"项

• scripts/build_report.py —— 生成 HTML 报告（仅支持 html 输出，md/xlsx 均已停用；

报告底部不附带生成说明与归属文案）。默认 --mode compliance 生成投标符合性检查报告（报告头 + 风险概览 + 废标问题清单 + 五分类章节 +问题清单详情 + 评分点覆盖与得分预估 + 附注；检查结论置于报告头；报告内不附历史比对，版本间对比由用户在 report/index.html 查看；身份证/手机号自动脱敏）；--mode tender 生成招标文件解析报告（仅解析招标文件时使用；未显式指定 tender 但数据中无投标文件且无问题时会自动切换）；身份证/手机号自动脱敏

• scripts/build_run_index.py —— 运行记录索引维护（阶段 7）：--task-dir <任务目录>

在工作空间根目录 report/ 下维护 data.json（全部历史运行记录：任务文件夹名、最终产物名称与相对路径、重点检查大分类、问题数量列表、上一次运行文件夹名）并重新生成index.html（全部运行卡片平铺、最新在最上、报告相对路径链接可跳转）；同一任务文件夹重出报告时原位覆盖不产生重复记录。多标书任务的问题数量、重点检查项与单家报告均按投标人各自成组展示（「投标人N：公司名」+ 各自的表/芯片/报告链接，不混合进一张表、不出合计行），单家报告链接放入对应投标人分组内，底部标签为「横向报告」、只保留横向对比报告链接（显示原始文件名）；「上一次结果」不再做差值计算，直接以表格原样展示上一次运行各投标人的问题数量；索引页 HTML 骨架读取 assets/index_template.html（脚本运行依赖该文件，勿移动或删除）

• references/eligibility_checklist.md —— 废标项与符合性审查完整清单（A–G）+ 法定否决情形摘录
• references/methodology.md —— 要求抽取、逐条判定、评分点分析的方法论、判定陷阱、

多标书对比流程与异常处理

• references/output_guide.md —— 严重度定义、报告结构、写作规范、免责边界
• assets/findings_template.json —— 合并结果的 JSON 模板
• assets/index_template.html —— report/index.html 索引页的 HTML 模板

（build_run_index.py 读取渲染；模板内置示例数据，双击打开即可预览页面样式；可替换区块用成对注释标记 <!--tpl:key-->…<!--/tpl:key-->（键名：title / update_time / cards），脚本渲染时把标记之间的内容替换为真实值——修改页面样式/结构时直接编辑本文件，保留标记即可，无需改动 Python 代码）