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>
45 lines
5.0 KiB
Markdown
45 lines
5.0 KiB
Markdown
# 写「招标文件档案」的说明
|
||
|
||
为查标评测集写一份招标文件档案（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 操作。
|
||
|
||
## 要求
|
||
|
||
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 个字的片段（去掉 `<u>` 这类标记）。同一份文件里两处写法冲突时都记上，并在回复里说明。
|
||
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 列表、拿不准的地方。
|