Files
bid-doctor/evals/check/prompts/style-B.md
YANG JIANKUAN 2beccd5fc5 feat(evals): 风格 B(两个分册、改写、自己的编号、干扰项 T01);注入的三处待修项
- 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>
2026-11-04 12:51:17 +08:00

28 lines
1.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 风格 B「简写型」改写说明(开发集用)
你在为评测集改写虚构投标文件的技术响应表。输入是一组表格行,每行有编号 `key`、招标要求原文 `requirement`、规矩的响应 `answer`。按下面的风格改写,**只改写法,不改内容**:
## 改写 `requirement`(招标要求那一栏)
真实投标人常常不照抄要求原文。每行按下面几种做法之一改写(轮换使用,大约各占三分之一):
- **截断**:只留前半句或关键词,后面用「……」或直接截掉。例:「支持多种接入方式,包括有线、无线和蜂窝网络,并支持自动切换」→「支持多种接入方式……」
- **改写**:换一种说法概括。例:「最小报文发送间隔不大于 50 毫秒」→「报文间隔≤50ms」
- **去掉编号和标记**:删掉原文开头的序号、★、▲。
## 改写 `answer`(投标响应那一栏)
- 大约三分之一的行**只写值、不复述要求**:例「64GB DDR4」「支持」「3 年」。这些行只输出 `answer`,不输出 `requirement`。
- 其余行用简短的说法,例「满足,单机 64GB」「支持,含硬件 BFD」。
- **数值、单位、是否满足必须和原响应完全一致**:原响应写 64GB,改写后也必须是 64GB(不能写成 64G 或 65536MB);原响应是满足,改写后不能出现「不支持」「部分」「可选」这类字眼。脚本会核对数字,对不上的改写会被丢弃。
## 不要做的
- 不要编造原文没有的参数、型号、品牌。
- 不要改变响应的含义(满足的仍然满足)。
- 例子里的设备和参数是虚构的,不要照搬到输出里。
## 输出
一个 JSON 对象:`{"<key>": {"requirement": "…", "answer": "…"}, …}`,只写 `answer` 的行省略 `requirement`。每个输入行都要有一项。