声明式覆盖
章节头写了 > 覆盖条目：R-012，正文一个字没写。v1 的覆盖率算 100%，报告全绿。
v2 区分声明级与实质级覆盖，只在声明出现的条目直接
COV-02 阻断。
Release v2.0.1 · 2026-10-18
把标书
把标书
当账本写
投标失败通常不是因为写得不好，而是因为 漏了一条要求、编了一个参数、 承诺了一句不该承诺的话。v2 把这三种事故变成三门可被机器拦住的闸机： 条目化台账、零发明标记、双轨核查。
12项确定性检查RULES
4种工作模式ROUTING
23项回归测试TESTS
8件交付物DELIVERABLES
Why v2
v1 能用，但会在三个地方
让你误以为"已经做完了"
这三个问题都不是"功能不够"，而是"通过得太容易"。看上去都绿了，实际上什么都没查。
正则失配的假通过
覆盖率用 \bR-\d{3,}\b。中文算 \w，"条目R-001"匹配不到——覆盖率可能恒为 0 或恒为 100。
改成 lookaround，并补
T01 回归用例锁死这个行为。
静默降级
没装 python-docx 时返回 [跳过] 字符串，它被当作正文参与扫描。报告"正常"，数据全错。
改为显式
InputError + 退出码 2：宁可失败，不给假绿。
Routing
先路由，再执行
v1 不管你问什么，都跑六阶段。一句话的请求也要走完全流程——慢，且容易在无关步骤上跑偏。v2 先判断你要的是哪一种活。
M1 · 读标 S0 → S1
先把文件读懂
"这份招标文件讲了什么？红线在哪？"
交付：台账 + 废标红线 + 评分点表
M2 · 编标 S0 → S5
出成稿
"帮我写技术标 / 商务标。"
交付：八件套
M3 · 体检 S4 双轨
会不会废标
"复核一下这版有没有坑。"
交付：核查报告 + 整改清单
M4 · 定点 单点
就问一句
"这句话能不能写？算不算负偏离？"
交付：结论 + 原文依据
Pipeline
六阶段，四个闸机
与 v1 最大的差别不是"多了几步"，而是每一步都有失败动作：门禁不过时，正确做法是停下来说明缺什么，而不是继续往下写。
S0
建档
收齐 I1–I8，跑资格符合性自检：只列缺口。
G0 · 无文件即停S1
解析
条目化 + 去重 + 溯源行号，产出三个基准数字。
G1 · 量级不符即补抽S1.5
人工修订
修 mandatory / strength，补 owner，整理澄清函。
S2
映射
每条要求有主应答章节；评分点有落点与证据。
G2 · 硬门禁S3
撰写
覆盖声明 + 首段逐字回应 + 承诺分级。
S4–S5
核查与交付
脚本管形式，清单管实质；八件套齐备才算交付。
G3 · BLOCKER 清零Fixed
九个缺陷，每一个都
对应一条测试
不是"优化了一下"，而是可以复现的 bug：给旧脚本同一个输入，它会给出错误的"通过"。
v1 的行为
真实后果
v2
章节头写编号即通过，正文空着也报 100%
COV-02 仅声明未展开 → 阻断
\bR-\d{3,}\b 匹配条目编号中文语境下失配，覆盖率可能恒为 0
lookaround 改写 + T01
占位字符串被当正文扫描，报告全错
显式报错，退出码 2
#docx 转文本没有 #，检查恒为空
支持 第X章 / # N. / N、 三种体例
资格、格式条款被批量误判，owner 派错人
句内优先、章节兜底 + 强信号章节
同一要求写三遍算 3 条必答，分母虚高
dup_of 三类重复合并
号称溯源，其实无法定位原文位置
line_no + source_ver
与文档不符，CI 把"用错参数"判成"不合格"
统一 0 / 1 / 2 语义
"有安排没落点"，仍然算通过
MAP-02 阻断
New
六块新能力，
都指向同一个问题：能不能核对
投标这件事，说不清就等于没做。新增能力全部以"可被第三方复核"为标准设计。
评分作战表
把评分办法拆成"得分点 → 分值 → 证据 → 章节 → 把握度"，一张表回答三个问题：哪些分确定拿不到、哪些分还没落点、离满分差多远。
- 无承载章节 →
SCORE-01阻断 - 证据为空 →
SCORE-02阻断 - 可达分 < 70% → 竞争力提示
复用污染扫描
比"凭空编造"更危险的编造变体：旧项目名、旧编号、内部用语没删干净。读起来通顺，直到资格性审查被废标。
- 旧编号 →
POLL-01阻断 - 旧项目名 →
POLL-02警告 - "按上次标书" →
POLL-03阻断
机器可读报告
validate.json：每条发现带 id、规则号、定位、证据、整改建议，直接接 CI 与台账。
强制强度五级
禁止 / 必须 / 应 / 宜 / 可，替代 Y/N 二分——整改时先改哪条，不再靠感觉。
溯源三件套
原文摘录 + 行号 + 版本标记。随机抽三条，30 秒内找不到原文，就是溯源不合格。
交付契约与异常边界
固定目录（00-输入 到 50-交付）、命名规则、Issue ID（F-001）、十节核查报告结构；外加 14 类真实异常的处理口径：扫描件、加密文件、超长标书、多版本补遗、联合体、分包、电子标 CA、涉密项目…… 每一类都明确"怎么降级、怎么标注、什么情况下必须停"。
Quick start
三步，全部零依赖
只要 Python 3.8+。读 .docx 才需要可选的 python-docx，不装也能跑 .md / .txt。
1 · 抽取要求台账
# 一条命令把招标文件变成可勾选的台账 python scripts/extract_requirements.py --input 招标文件.md --output requirements.csv --ver v1 # 输出：原始条目 22 / 去重合并 3 / 主条目 19 / 必答 12 / 需澄清 2
2 · 交付前双轨核查
# exit 0 = 通过；1 = 有阻断项；2 = 输入有问题 python scripts/validate_bid.py --bid ./20-正文 --req requirements.csv \ --map outline-map.csv --score scoring-matrix.csv \ --project "本项目名称" --project-no "KM-2026-1234" \ --report validate.json
3 · 验证脚本在你机器上行为一致
python -m unittest discover -s tests -v ... Ran 23 tests in 1.7s OK