2beccd5fc5
- build.py：风格 B 分商务资格册和技术册，表格行按 rewrite.json 改写（数字对不上的改写丢弃，规矩靠构造 保证），用自己的编号，每 12 行技术响应挪到商务资格册（T01）；干扰项写进 spec.traps。 - mutate.py：支持多个分册；表格的响应方式以档案的 mode 为准（评分要的技术规格表是 presence，不再把单元 推成逐条响应）；「暂不支持」只套在功能类要求上，数值参数写不满足的值；「提供……方案 / 证明 / 报告」 这类文件要在的要求不注入参数类问题。 - prompts/style-B.md、prompts/profile.md：风格 B 改写说明和招标文件档案说明（开发集用）。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5.0 KiB
5.0 KiB
写「招标文件档案」的说明
为查标评测集写一份招标文件档案（tender profile），供 evals/check/build.py 生成虚构的规矩投标文件。
读这些
- 档案格式：
evals/check/build.py文件头的 docstring，以及各 kind 的生成逻辑。 - 响应方式的定义：
evals/check/GUIDELINES.md§2（含本文件那一行的记录，记录不准时以招标原文为准，并在回复里说明）。 - 招标文件全文（带句子编号
[p页s句]）：evals/out/docs/<ID>/sentences.txt - 读标正式清单（要分配 routes 的条目）：
evals/out/check/tenders/<ID>.items.tsv（列：iid、类别、重要性、页码、标题） - 写好的档案可以参考格式（不要照抄内容）：
evals/out/check/tenders/S02.json、S04.json、S10.json。
不要读 evals/out/check/_sealed/、server/、prompts/（仓库根目录那个）。
只写一个文件
evals/out/check/tenders/<ID>.json。不改仓库里的其他文件，不做 git 操作。
要求
project：项目名称、编号、采购人、代理机构、投标截止日期（deadline，YYYY-MM-DD）、投标有效期天数、最高限价或预算（元，纯数字字符串）、采购包（编号、名称、限价）。多包时只投一个包，写bidding_lot，ceiling_total填那个包的限价，只属于别的包的条目 routes 记na。全部从招标原文取。modes：按类别（tech_param、substantive、commercial、qualification、scoring，必要时加 scope）记响应方式（explicit / implicit / evidence / presence / platform），evidence 写when（bid 或 award）。每条带basis：p页码，t从 sentences.txt 逐字复制、不少于 8 个字的片段（去掉<u>这类标记）。同一份文件里两处写法冲突时都记上，并在回复里说明。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"的表单（它会把全部附件渲染一遍）。
- 叙述性的（投标函、授权委托书、声明函、承诺书）用
attachments：规矩投标人要附的每份证明材料（按本文件要求来；写明「投标文件中无需提供」的、中标后才交的不附）。证书类scan: true，lines写虚构内容（单位名 {bidder}，信用代码 {credit_code}，有效期覆盖截止日之后至少一年，社保月份按要求的区间）。全部虚构，不出现真实企业或真实人名。routes：tsv 里每一个 iid 都要分配：tech_row：技术参数、功能要求；commercial_row：商务要求（交货期、地点、质保、付款、售后响应等）；attach:<附件 key>：靠附证明材料满足的；form:<表单 key>：靠某份格式文件满足的；prose或prose:<节标题>：靠技术方案散文响应的（实施方案、售后服务方案等评分项）；- 一条要求要走几处时用
+连起来，例如tech_row+attach:a3（表里一行，另附证明材料）； na：不需要投标人响应的（无效情形的列举、评审程序、日期、采购人义务、合同条款、说明标注规则的句子、别的包的条目）。
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 列表、拿不准的地方。