Files
bid-doctor/prompts
YANG JIANKUAN f98fd51128 fix(server): 按 S01–S10 评测修复读标抽取(F1–F8、口径 Q1–Q4)
- 合并时待确认条目不再借正式条目进清单,没通过的类别记在 pending_categories
- 结构识别:章(按章跳过不相干的部分)、表后「上述……否则无效」说明、★ 节标题
- INVALID 补写法;输出用到上限 92% 按截断处理,拆到底时采用已有输出
- 格式范本正文、整表概括句不收;项目信息多看评标方法所在分块
- WPS 旧版 DOC 直接修正字体表字符集;表格按单元格切句(s3-v4)
- 口径:★ 节继承实质性、★ 定义为计分项时降为重要、「必须/应」声明记 keyword 规则、
  政府采购资格条件按 87 号令第六十三条带无效类别
- 提示词 substantive v5,qualification / schedule / tech_param v4

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-03 23:19:30 +08:00
..

提示词

带版本号的提示词与输出格式定义(架构 §3.6)。代码只按「任务 + 版本」引用,不在代码里写提示词正文。

  • 目录名是任务编号,如 extract.substantive/;文件名是版本 v<N>.md。
  • 文件头的 front matter 写 id、version、capability(vision / fast / reasoning)、output、description。
  • 已发布的版本不再修改:改提示词就加一个新版本,再改代码里引用的版本号。每次调用都记下提示词编号、版本和内容哈希(ai_call 表)。
  • 改了提示词或路由,要跑评测回归(evals/,主要指标是 ★ 和实质性条款的召回率)。

提示词规则和服务端校验

抽取类提示词「证据规则」里的每条禁止事项,都对应服务端的一道校验和一个原因码(server/src/bid_doctor/checklist/extract.py 的 FAILURES)。没通过的结果进待确认区,原因码记在清单项的 ai_values.failures,解析结果按原因计数(verify_failures)。改提示词时同步改这张表;评测时按原因码判断问题出在规则、提示词还是模型。原因码不写进提示词正文(模型会把括注抄进引文)。

提示词规则 原因码
没有证据的结果不要输出 evidence_missing
sid 照抄行首编号,写法如 p12s3 sid_format
sid 必须是本分块里出现过的编号 sid_unknown
quote 复制整句;短句整句复制,不只摘关键词 quote_too_short
逐字复制,不改写、不改正错字、不拼接 quote_not_original
basis 和证据句对得上(★、*、斜体下划线主体、无效后果) basis_unmatched
结构化字段必须能在证据原文里找到 value_unverified、points_unverified、date_unverified、amount_unverified
待填写的空白不算值 placeholder_value
被标注的条款一条都不能漏 marker_uncovered(规则兜底补出)
项目信息:not_found 不带证据 not_found_with_evidence
项目信息:拿不准的回答 ambiguous ambiguous
项目信息:12 个字段都要回答 missing_answer
实质性条款:列表的引导句、表后的概括说明不单独输出 没有原因码:服务端直接丢弃(只引了这类句子的条目),下面列出的各项由规则兜底

项目基本信息每个字段的结论记在解析结果的 info_fields:found、absent(看过的分块都干净地回答没找到,文件本身没写)、needs_review(有歧义、漏答、证据或取值没通过,要人核对)。