天好富兴 | 招标文件综合审查

概述

招标文件需求解析与综合审查

Overview

对一份招标文件同时完成两件事：

1. 需求解析——把招标文件拆成结构化清单：要求清单 R（强制性/资格/商务/技术/形式）、

基本信息与关键时间节点、废标项（否决条款与无效投标情形）、技术需求与实质性条款、评分办法与评分项。解析结果供招标人核对文件内容、供各方快速掌握招标要求使用。

1. 综合审查（合规性检查）——对招标文件本身做三层审查：
   • 法规符合性：歧视性/排他性条款、法定时限与金额红线、评分办法合法性

（清单见 references/legal_review.md）

• 完整性与一致性：必备章节是否齐全、跨章节口径是否矛盾、评标办法能否执行

（清单见 references/structure_checklist.md）

• 两层结果合并进同一份问题清单，输出一份 HTML 综合审查报告

核心交付不是"读后感和建议"，而是每一条结论都能指向具体条款和具体页码。

输入决定模式（硬性闸门，先看文件再动手）：

• 恰好 1 份招标文件 → 正常执行（阶段 0–6）
• 0 份（没有招标文件）→ 不执行，提示上传招标文件
• 招标文件 > 1 份 → 不执行，告知一次只处理 1 份，等用户删减
• 混入了投标文件 → 不执行，告知本技能只处理招标文件，请把投标文件拿掉后再开始

安全与保密约束

招标文件可能涉及未公开的商业与预算信息，处理全程守住三条底线：

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

外部服务或在线接口。扫描件没有文本层时，请用户提供可复制文字的版本，不要建议使用在线 OCR、云转换等外部服务。

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

严禁为"显得完整"而编造分值、权重、条款内容或法规条文号——宁可缺失，不可虚构。

1. 经验私有：提取的 JSON、中间结果与报告一律只写入本次任务的任务文件夹

（脚本 --out / --out-dir 指向的本地目录），不写入云端、共享位置或系统缓存。

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

像一位专业又热心的同事：先回应，再说明「我打算做什么、会给到什么结果」。

收到招标文件，准备开跑：

收到～ 我会先帮您把这份招标文件的要求梳理成清单（资格条件、技术需求、评分办法、

废标项、关键时间节点），再重点审查它本身合不合规——歧视性条款、评分办法合法性、

章节完整性、前后口径矛盾都会查，最后给您一份带问题清单的审查报告。

收到了投标文件（本技能不处理）：

这一份看起来是投标文件，我只做招标文件的解析与审查哦。请把投标文件拿掉、

留下要审查的招标文件，我马上开始～

多份招标文件：

一次审查最多支持 1 份招标文件，您目前上传了 X 份。麻烦先挑一份（多个标段/包件

可以分多次依次审查），我马上开始～

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

还没收到可以处理的文件哦。本技能需要 1 份招标文件（.docx / .pdf / .xlsx / .md / .txt

均可，PDF 优先提供可复制文字的版本）。把文件发给我，我先帮您确认解析范围。

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

本技能的用户是不懂编程的白领——Python、pip、venv、镜像源这些词一律不得出现在对话里，环境准备全部由 agent 静默完成。需要提前说明的最多一句轻量预告：

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

禁止任何形式的环境探测——不要单独执行"检查工作目录与环境"之类的步骤、不要试运行 Unix / PowerShell 命令。环境信息只来自一条命令：

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

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

doctor 跑完会一次性输出全部环境信息到 stdout——无回显环境里 stdout 是空的，一律加 --out 落盘后读文件拿结果（python scripts/doctor.py --out，默认写当前目录 __doctor_result.txt，也可 --out <路径> 指定位置；__ 前缀文件会被交付前的 cleanup 清扫，禁止 > xxx_result.txt / Out-File /tee 这类把输出重定向到当前目录的写法），不要对着空 stdout 反复重跑。

根目录自愈（无需手动删除任何文件）：在命令行做重定向是脚本参数约束不到的行为（init_task.py 连 --out 都不提供，照样被写出了 init_result.txt）。因此 doctor.py与 init_task.py 每次运行都会先清扫一次工作目录当前层，把上一轮这类残留收走，结果体现在 doctor 输出的 tidy_root: 一行；给 --out 传裸文件名时还会自动补 __ 前缀，不必再纠结文件名会不会留下垃圾。判定口径统一由 scripts/tidy_root.py 掌管：只删符合临时模式的文件，绝不删目录（.venv/、report/、任务文件夹全部安全），也不删根目录下的 .py（用户根目录里可能有自己的脚本）。

它一次性输出：Python 版本与该用哪个解释器（scripts_python，见下）、PATH 中 python / py 的真实性（Windows 的 python 常是 Microsoft Store 占位程序，exitCode 0 但什么都不执行，doctor 会标出，这种绝不能拿来跑脚本）、工作目录、技能脚本目录、venv 与依赖状态、report/ 运行记录状态、next_hint 行动建议。

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

1. doctor 跑通 → 后续所有脚本一律用输出的 scripts_python：.venv 已建时它就是

venv 内解释器（第三方依赖装在那里）；executable 是受管基础解释器，只用于建 venv与装依赖——拿它跑抽取/出报告必然缺依赖，会白跑一轮；

1. 受管路径不存在 → 唯一允许的甄别动作 <候选命令> -c "print(1)"，**有真实 stdout

输出才算可用**（Store 占位程序 exitCode 0 但无输出，必弃）；候选顺序：Windows py→ python，Unix python3 → python；

1. 都不可用 → 用平台自带的运行时安装能力静默装受管 Python（3.11+），装完重跑 doctor；
2. 平台连安装能力都没有 → 按「环境准备失败的沟通口径」告知用户。

（下文的示例命令为可读性写成 python scripts/xxx.py，实际执行时 python 一律指doctor 输出的 scripts_python 那个绝对路径。跑脚本失败时不要靠试解释器来排查——缺依赖只可能是没装，按 deps:* 与 next_hint 处理。）

依赖按需安装（缺什么装什么，装过的绝不重装）：

（报告是 HTML，生成不需要第三方库。）

• 「可用（venv）/ 可用（全局）」→ 不装；「缺失」→ 只装缺的那个包，多个缺失包合并成

一条 pip 命令

• 安装到隔离虚拟环境 venv（已存在则复用）；个别平台受管 Python 是 embeddable 精简

发行版、-m venv 报 "No module named venv/ensurepip" 时，允许直接装进受管解释器

• pip 一律通过解释器以 -m pip 方式调用，优先国内镜像源，换源降级一条命令完成；

安装/建环境等命令的输出一律不做重定向（> / Out-File / tee 全禁）：这类命令只要 exitCode 0 就够了，输出不需要留证；真要留就用 --out __pip.log 这种 __ 前缀。万一失手落了裸名文件也不用慌——下次 doctor / init_task 会自动清扫，交付前 cleanup 再兜底，不需要你手动 rm / del（手动删反而容易误伤）：

# Windows（<缺失的包名> 只填 doctor 标「缺失」的；Unix 镜像源级联同理）
.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 <缺失的包名>

• 装完必须复检：重跑 doctor 并读输出，确认对应 deps:* 从「缺失」变「可用」
• 脚本调用一律用 doctor 输出的 scripts_python 绝对路径；不要先用 executable 试跑、

失败了再回退到 venv 解释器（受管解释器只有标准库，必然失败，白跑一轮，还会把 venv、依赖这类技术细节暴露给用户，违反零感知原则）；除 doctor.py外不得执行任何环境类命令，目录列举、路径拼接、文件查找全部用 Python 完成

环境准备失败的沟通口径（安装链静默完整重试一轮、仍失败才开口）：

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

或防火墙把下载/安装动作拦住了。麻烦您检查一下网络是否正常、沙箱是否限制了文件下载

或程序运行；处理好之后跟我说声"再试一次"就行，已完成的进度不会丢。

工作流程

阶段 0：文件识别与前提确认

先识别哪份文件是招标文件——按文件名判定，判不出的再按正文骨架判定。识别结果写入meta.tender_file。

判定顺序：只命中招标侧强特征词 → 直接继续跑；无强特征命中看弱特征；两侧都命中或都判不出 → 用 extract_text.py <文件> --mode outline 看正文骨架（招标文件的骨架特征：「投标人须知前附表」「评标办法」「投标邀请书/招标公告」「投标截止时间」）。名称与骨架都判不出时，问用户一次（这是唯一必须的用户交互，一次问清）。

过闸门：判定后清点——招标文件恰好 1 份才继续；0 份 / >1 份 / 混入投标文件 →按「与用户沟通」的对应话术处理，不建任务文件夹、不跑任何阶段。

其余前提一律自动推断，不追问用户：项目类型、招标人、代理机构、预算、截止时间等从文件名和正文抽取，抽不到的在报告中标"未识别"。本技能没有盖章开关之类的交互——不涉及投标文件签章核验。

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

角色判定通过后、阶段 1 之前执行一次：

python scripts/init_task.py <项目简称>
# 输出：.../招标文件审查-XX项目-20260920-1530/

• 文件夹名 招标文件审查-<项目简称>-<时间戳>，平铺在会话工作空间根目录下

（与输入文件所在位置无关，不得 cd 到文件所在目录执行命令）；项目简称从招标文件名 /封面项目名称推断，推不出用招标编号，再不行用「未命名项目」

• 创建后记住路径，后续所有脚本的 --out / --out-dir 一律指向该文件夹
• init_task.py 能打印出路径就说明目录已创建成功（makedirs 失败会直接报错退出）；

目录刚建时是空的，文件搜索工具（Glob 等）看不到空目录——不要因此怀疑中文参数或创建失败、再跑一轮诊断确认

• 新会话必定新建；同一会话重出报告沿用；跨会话续跑用 python scripts/init_task.py --list

列出已有文件夹供用户指认，不指认就新建

文件卫生（根目录必须干净）：

三条硬约束：

1. 禁止重定向写法：> xxx.txt / Out-File / tee 一律不得出现，这是唯一会把散落文件

留在根目录的动作；确需落盘只用 --out（裸文件名会被自动补 __ 前缀）

1. 不写日志文件，不在根目录创建临时脚本；取证脚本一律进 <任务目录>/tmp/
2. 不要手动删：即使某次失手把文件落到了根目录，doctor.py / init_task.py

下次运行会自动清扫（doctor 输出的 tidy_root: 一行可见），交付前 cleanup 再兜一次底

交付前清理（必做）：

python scripts/cleanup_task.py <任务目录> --sweep-parent

单独查看 / 清扫某个目录的临时残留（无需等到交付）：

python scripts/tidy_root.py --dir <目录>            # 预览
python scripts/tidy_root.py --dir <目录> --apply    # 执行

阶段 1：提取与结构化

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

• 扫描件 PDF 会标记 needs_ocr：友好请用户提供可复制文字的版本，**不要基于空文本层下

"章节缺失/内容缺失"的结论**

• 先看骨架：python scripts/extract_text.py 招标文件.pdf --mode outline
• 精确定位（可反复用）：python scripts/extract_text.py 招标文件.pdf --search "否决|无效|实质性|必须|不得" --context 60
• 大文件分段读局部原文：--mode text --max-chars 50000
• 以上模式（含完整 JSON）都支持 --out <路径> 落盘：无回显环境（stdout 读不到）一律加

--out <任务目录>/tmp/__outline.txt（检索/分段同理）后读文件——不要因为大纲模式拿不到 stdout 就改跑完整 JSON 再自己找骨架，那会多绕一大圈

阶段 2：需求解析（核心交付之一）

按 references/methodology.md 执行，产出：

• 要求清单 R → matrix：每条含 `编号 | 类型(强制性/资格/商务/技术/形式) | 条款原文摘要 |

出处(章节+页码) | 评分影响/所需证明材料。★/▲ 实质性条款与前附表否决项的 type必须填 强制性`——否则报告"强制性要求"相关展示会漏掉最高危条款

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

投标截止与开标时间、投标有效期

• 时间节点 → timeline：公告发布、澄清/答疑截止、投标截止/开标、有效期届满、签约期限
• 废标项 → focus_clauses：只收「会直接导致投标被否决 / 按无效投标处理」的条款，

type 只能是三个固定值之一：无效投标情形 / 围标串标审查 / 特殊限制。保证金（是否收取、金额、形式）、资格条件、付款方式、工期等一般要求不属于废标项，一律进 matrix（招标要求清单），不得混入此数组——例如「本项目不收取投标保证金」是商务约定而非否决情形

• 技术需求 → tech_spec：只填 items（需求清单 / 技术指标 / ★实质性条款标记）；

不填 summary（章节导语，与报告头项目概况重复）与 standards（遵循标准/规范 不展示，这两块用户明确不要）

• 评分项 → scoring：只填 item / nature(主观分/客观分) / max_score / basis；

不写 est_range / risk / bid_ref 三个字段（本技能不预估得分、不做响应比对）

• 无法归类的条款 → unrecognized：location / excerpt / reason(无法归类|附件缺失|

冲突未决|提取失败) / suggestion。不得静默丢弃——附注章节是否充实取决于这个数组

阶段 3：完整性与一致性审查

对照 references/structure_checklist.md 逐项过：

• A 类（完整性）：用 outline 骨架对照必备章节清单，缺整章记入 findings（category=完整性）
• B 类（一致性）：按主题逐项全文检索比对（工期/质保/有效期/保证金/截止时间/预算/

付款/业绩口径/资格条件/项目编号名称）。解析阶段抽到某主题时就地比对，不要回头补查。冲突条目 locations 至少 2 条（两处原文对照）；能按效力优先级取舍的写明应执行版本，不能确定的在 suggestion 写"建议向招标人书面澄清"，同时 unrecognized 记 reason=冲突未决

• C 类（评标办法可执行性）：分档明确、分值合计 100、否决条款与评分项不冲突

阶段 4：法规符合性审查

对照 references/legal_review.md 逐项过（先判定适用法规体系：政府采购 / 招标投标 /通用红线）。条文号必须先查 references/legal_anchors.md 锚点表——表里有对应项才写条文号，表里没有的只描述风险类型，严禁凭记忆写条文号；两套体系的条文不得跨体系混引。边界临界情形（规模条件分体系、保证金恰好 2%、参数指向性等）对照references/judgment_cases.md 校准，防误升/误降：

• A 类红线：歧视性/排他性条款、规模条件作资格或评分因素、品牌/区域/供应商限定
• B 类程序合规：发售期、20 日编制期、澄清 15 日、保证金 ≤ 2%、有效期设置
• C 类评分合法性：价格分权重区间、量化对应、资格条件重复评分
• D 类必备要素：资格标准、评标标准、合同主要条款等法定必备内容
• E 类需求合理性：技术参数指向性（萝卜标特征）、业绩/资质要求合理性

每条问题必须包含：条款出处（章节+页码）+ 原文摘录 + 法规依据（能对应到具体条文才写条文号，拿不准只描述风险类型）+ 可执行的修改建议。法规适用争议标"存疑"，建议咨询律师或行政监督部门，不下"违法"定论。

盲区强制回溯（阶段 3/4 收尾前必做，防中后段漏检）：

招标文件几百页很常见，技术需求细则、合同条款、格式附件等中后段最容易漏检。逐项过完清单后，必须用 extract_text.py --search 对以下盲区定向回溯一遍，任一未覆盖就在 findings/unrecognized 如实标注（如"建议人工核对"），不得静默当作已查完：

• ★|▲|否决|废标|无效|实质性|不可偏离 全文回溯——高危条款常散落中后段
• 保证金金额/形式/退还：公告、前附表、须知、合同条款多处口径复核（对应 B4）
• 评标办法分值合计复核、否决条款与评分项冲突复核（对应 C 类）
• 图片化表格、"详见附件X"类条款是否已进 unrecognized

阶段 5：合并与出报告

把阶段 2–4 的结果合并成 merged JSON，结构参照 assets/merged_template.json。要点：

• merged JSON 顶层必须带 "mode": "review"（运行记录按此识别审查模式）
• 必须包含全部顶级字段：`meta / timeline / tech_spec / scoring / matrix / findings /

focus_clauses / unrecognized / conclusion；tech_spec.items` 不得留空（留空会导致章节省略）

• findings.category 按问题所涉维度填：法规符合性 / 完整性 / 一致性 / 评分办法 /

否决条款 / 需求合理性（这六个是本技能的唯一分类口径，不要自造）

• severity 定级（审查口径）：违反法规强制性规定 → fatal；易引发质疑/澄清/评审争议 →

major；完善性建议 → minor；观察项 → info

报告必须由脚本生成，禁止手写 Markdown：

python scripts/build_report.py --data <任务目录>/merged.json 
    --format html --out-dir <任务目录>

报告文件名由脚本自动拼接为 招标文件综合审查报告-<项目简称>.html（项目简称取自merged 数据的 meta.project，脚本负责去掉文件名非法字符并截断长度）。不要在--name 里手工拼项目名——同一目录下多份报告靠这个后缀区分；meta.project 缺失时脚本自动退回 招标文件综合审查报告.html。

报告为「{项目名称} 招标文件综合审查报告」，章节：报告头（项目概况 + 审查结论 +严重度说明）→ 风险概览（问题统计卡）→ 招标需求解析组：关键时间节点 / 技术与实质性条款 / 招标要求清单 / 评分办法与评分项（均按需）→ 招标问题清单组：问题概览 /问题清单详情（按严重度分组、可筛选）/ 废标项（均按需）→ 附注：未识别条款与存疑内容。目录按上述两组分级展示，正文顺序与目录一致。

报告结构自检（缺一即退回补数据重跑脚本）：

只产出 .html；不产出 Markdown 与 Excel 文件，用户要文本内容时直接在对话中给出。

阶段 6：登记运行记录（必做）

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

脚本在工作空间根目录维护 report/（data.json + index.html）：全部历史运行卡片平铺、最新在最上、报告相对路径链接可点击跳转。同一任务文件夹重出报告原位覆盖不产生重复记录。交付时提醒用户不要单独移动 report/ 或任务文件夹，否则索引页跳转会失效。

输出规范

• 结论要敢下判断，禁止"基本合规，建议进一步完善"这类无信息量的表述
• 每条问题必须有：条款出处（章节+页码）+ 原文摘录 + 法规依据/风险描述 + 可执行的修改建议
• 拿不准的标"存疑"并写明需要什么材料才能定论，不猜；法规适用争议建议咨询专业人士
• 拿不准严重度时取低一级，在 impact 中写明升级条件

边界

• 这是文档审查，不是法律意见；法规适用争议提示用户咨询律师、招标代理或行政监督部门
• 不得代用户修改、编造招标文件内容；可协助拟定澄清函/异议函的要点，但提示核实后使用
• 不得给出"一定能过审查""绝不废标"式的保证

交付与结束语（必须）

交付纪律：产物卡片/预览只允许出现一个——report/index.html；最终回复中不罗列任务文件夹内的单个 .html 文件路径作为交付入口；脚本打印的 file:/// 地址仅供内部使用，不转述给用户。

最终回复模板：

### 结论速览

<一句话总评，如：本次解析出要求 N 条、评分项 M 项、废标项 K 项；审查发现 X 项问题
（致命 a / 严重 b / 建议 c），主要集中在：>

1. <要点 1（含条款出处）>
2. <要点 2>

运行记录已登记：
- `report/index.html` —— 浏览器打开即见本次运行，点击文件名可查看综合审查报告

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

回归验收

技能修改后，对照 test_cases/cases.md（T01–T10）逐条回归：报告结构自检、废标项归类、双体系判定、盲区回溯、不臆造、法条引用纪律。任一用例不达标先修技能再交付。

资源

• scripts/doctor.py —— 运行环境一次性自检（流程第一条命令）：解释器绝对路径、

PATH 中 python/py 真实性（Store 占位程序会标出）、venv 与依赖状态、report/ 状态、next_hint；结果输出到 stdout，无回显环境加 --out 落盘（默认 __doctor_result.txt，可 --out <路径> 指定，裸文件名自动补 __ 前缀）；每次运行顺带清扫一次工作目录根目录的临时残留（tidy_root: 一行），--no-tidy 可关闭

• scripts/tidy_root.py —— 工作区根目录卫生守卫：只扫【当前层】、只删符合临时模式的

文件（__*、*_result.txt、*_out.txt、tmp*.txt、_raw_*、outline_*、*.log、*.err 等），绝不删目录（.venv/、report/、任务文件夹都安全），也不删根目录下的 .py；独立用法 --dir <目录> [--apply]（不加 --apply 只预览）。doctor.py / init_task.py / cleanup_task.py 共用它的判定口径，避免多处不一致

• scripts/init_task.py —— 任务文件夹管理：init_task.py <项目简称> 创建

招标文件审查-<简称>-<时间戳>/；--list 列出已有任务文件夹；每次运行同样会清扫一次工作目录根目录

• scripts/cleanup_task.py —— 交付前清理：删除 tmp/、日志、临时脚本与散落 txt，

只留中间产物 JSON 与 HTML 报告；--sweep-parent 连带清扫上级目录残留；--dry-run 预览

• scripts/extract_text.py —— 统一提取器（docx/pdf/xlsx/md），支持 outline / 全文 /

正则检索三种模式；--search 只对原始文档生效

• scripts/build_report.py —— 生成 HTML 报告（本技能唯一产物：招标文件综合审查报告，

文件名自动带项目标识 招标文件综合审查报告-<项目简称>.html，无需传 --mode）；身份证/手机号自动脱敏

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

report/data.json 与 report/index.html（识别 merged JSON 顶层的 "mode": "review"）

• references/legal_review.md —— 法规符合性审查清单（A–E 类红线、程序合规、评分合法性）
• references/legal_anchors.md —— 双体系高频法条锚点表（条文号只从这里查；

使用纪律：不默写法条原文、时效存疑标核验、跨体系不混引）

• references/judgment_cases.md —— 边界判定案例集（防误升/误降/跨体系误判，

临界情形拿不准时对照）

• references/structure_checklist.md —— 完整性、一致性、评标办法可执行性审查清单
• references/methodology.md —— 需求解析方法论：要求清单抽取细则、结构化字段口径、

未识别条款处理、上下文管理

• test_cases/cases.md —— 回归测试用例（T01–T10，技能修改后逐条验收）
• assets/merged_template.json —— merged JSON 模板（含字段说明与示例）
• assets/index_template.html —— report/index.html 索引页模板

（build_run_index.py 运行依赖该文件，勿移动或删除）