# 写「招标文件档案」的说明 为查标评测集写一份招标文件档案（tender profile），供 `evals/check/build.py` 生成虚构的规矩投标文件。 ## 读这些 - 档案格式：`evals/check/build.py` 文件头的 docstring，以及各 kind 的生成逻辑。 - 响应方式的定义：`evals/check/GUIDELINES.md` §2（含本文件那一行的记录，记录不准时以招标原文为准，并在回复里说明）。 - 招标文件全文（带句子编号 `[p页s句]`）：`evals/out/docs//sentences.txt` - 读标正式清单（要分配 routes 的条目）：`evals/out/check/tenders/.items.tsv`（列：iid、类别、重要性、页码、标题） - 写好的档案可以参考格式（不要照抄内容）：`evals/out/check/tenders/S02.json`、`S04.json`、`S10.json`。 **不要读** `evals/out/check/_sealed/`、`server/`、`prompts/`（仓库根目录那个）。 ## 只写一个文件 `evals/out/check/tenders/.json`。不改仓库里的其他文件，不做 git 操作。 ## 要求 1. `project`：项目名称、编号、采购人、代理机构、投标截止日期（`deadline`，YYYY-MM-DD）、投标有效期天数、最高限价或预算（元，纯数字字符串）、采购包（编号、名称、限价）。多包时只投一个包，写 `bidding_lot`，`ceiling_total` 填那个包的限价，只属于别的包的条目 routes 记 `na`。全部从招标原文取。 2. `modes`：按类别（tech_param、substantive、commercial、qualification、scoring，必要时加 scope）记响应方式（explicit / implicit / evidence / presence / platform），evidence 写 `when`（bid 或 award）。每条带 `basis`：`p` 页码，`t` 从 sentences.txt 逐字复制、不少于 8 个字的片段（去掉 `` 这类标记）。同一份文件里两处写法冲突时都记上，并在回复里说明。 3. `forms`：按「投标文件格式」章的顺序列出投标人要交的全部格式文件。 - 叙述性的（投标函、授权委托书、声明函、承诺书）用 `kind: "text"`，`paragraphs` 照抄固定文字，填空处换成占位符（见 docstring），没有对应占位符的填空写成虚构的合理内容。声明函按规矩投标人的正确填法写；「如有 / 如是」而规矩投标人不适用的不列。 - 开标一览表 `price_summary`；分项报价表 `price_items`，`items` 写名称、数量、单位。**有分项最高限价或单价上限的，每项加 `ceiling`（元）**；上限是单价时再加 `ceiling_is_unit: true`。 - 偏离表 / 响应表 `response_table`：`route` 是 `tech_row` 或 `commercial_row`；implicit 的写 `only_deviations: true`，explicit 的写 false。表头照抄格式（脚本按表头文字决定每一列放什么，支持「序号 / 名称 / 要求 / 响应 / 偏离 / 说明」这些列）。**不是用来逐条响应、只是要求提交的技术文件**（例如评分要的「所投产品技术规格」表），加 `"mode": "presence"`。商务要求要逐项响应但格式章没给表的，可以自拟一张。 - 有固定行的表用 `fixed_rows`，响应栏按规矩填。 - 资格证明、评分证明材料放进**一个** `kind: "attachments"` 的表单（它会把全部附件渲染一遍）。 4. `attachments`：规矩投标人要附的每份证明材料（按本文件要求来；写明「投标文件中无需提供」的、中标后才交的不附）。证书类 `scan: true`，`lines` 写虚构内容（单位名 {bidder}，信用代码 {credit_code}，有效期覆盖截止日之后至少一年，社保月份按要求的区间）。全部虚构，不出现真实企业或真实人名。 5. `routes`：tsv 里**每一个** iid 都要分配： - `tech_row`：技术参数、功能要求；`commercial_row`：商务要求（交货期、地点、质保、付款、售后响应等）； - `attach:<附件 key>`：靠附证明材料满足的；`form:<表单 key>`：靠某份格式文件满足的； - `prose` 或 `prose:<节标题>`：靠技术方案散文响应的（实施方案、售后服务方案等评分项）； - 一条要求要走几处时用 `+` 连起来，例如 `tech_row+attach:a3`（表里一行，另附证明材料）； - `na`：不需要投标人响应的（无效情形的列举、评审程序、日期、采购人义务、合同条款、说明标注规则的句子、别的包的条目）。 6. `prose`：2～4 节虚构的技术方案叙述，每节 2～4 段，节标题要和 `prose:<节标题>` 对得上。**不写任何具体参数数值**，不出现别的项目名称。 ## 自查（用 Python） JSON 能解析；tsv 里的 iid 全部出现在 routes 里、没有多余的键；`form:` / `attach:` / `prose:` 都指向存在的表单、附件、节；modes 的 basis 片段都能在对应页逐字找到。可以把 build.py 的输出目录临时指到 scratchpad 试跑一次（不要写进仓库）。 ## 最终回复 只写简短汇总：routes 各取值的条数、forms 列表（key + kind + 有无 mode）、modes 列表、拿不准的地方。