潜在投标人预测（Tender Bidder Predictor）

Overview

接收一条标讯（招标/采购公告），结合采购人历史公告、同类项目历史中标人、候选企业工商与司法数据，推断最可能的潜在投标人或被邀请方，并输出结构化 HTML 报告。支持"时间隔离"模式（假设结果未公布，只用公告发布日之前的数据）。

本技能是业务逻辑层：数据访问依赖已安装的 bidi-tender-search 技能（比地 API、Token、接口目录）。若未安装该技能，先提示用户安装并配置 BIDI_API_TOKEN。

依赖与认证

令牌复用 bidi-tender-search 的约定：从环境变量 BIDI_API_TOKEN 读取 Bearer Token。不得在命令、日志、报告或示例中输出 Token。若已配置，会话内自动复用，后续调用不再询问。
scripts/predict.py 启动时会检测 BIDI_API_TOKEN；若缺失，抛出清晰错误并提示调用方设置该环境变量（不猜测、不调用未授权接口）。
首次被触发时，先确认 Token，再收集项目信息：
1. 检查环境变量 BIDI_API_TOKEN 是否已配置。
2. 若已配置：直接请用户提供项目信息（比地公告链接 / 公告标题 / docId 任选其一），随后立即开始预测。
3. 若未配置：第一句话只问 Token：
  
  "预测潜在投标人需要比地开放平台的数据接口 Token。请问你现在有比地 API 的 Bearer Token 吗？"
  - 用户回答"有"或粘贴 Token：记录为 BIDI_API_TOKEN，然后请用户提供项目信息（公告链接 / 标题 / docId 任选其一）。
  - 用户回答"没有"或"没有 token"：引导用户到比地数据开放平台申请：
    
    "没有 Token 暂时无法调接口。你可以前往比地数据开放平台（https://www.bidizhaobiao.com/sjjk/）申请接口 Token。申请通常是免费的，注册账号后进入『开放数据 / API 接入』页面即可获得 Bearer Token。拿到后把 Token 贴给我，我会仅在本轮会话内临时使用，不会写入任何项目文件，然后开始预测。"
API 基础地址与状态码规范见 bidi-tender-search 的 SKILL.md；本技能的常见调用陷阱见 references/bidi-pitfalls.md。

参数

| 参数 | 类型 | 默认 | 说明 | |---|---|---|---| | tender | 字符串（必填） | — | 标讯标题、docId 或比地 URL。 | | time_isolation | 布尔 | false | false=使用全部公开数据（含该标讯历史中标结果，最快最准）；true=以目标公告发布日为截止点，只用此前数据，且不调用该标讯自身的中标结果接口辅助预测（用户要求"结果未公布/严谨预测"时开启）。 |

工作流程

定位标讯：用 scripts/predict.py 的 search() 按标题关键词检索，确认 docId、采购人、发布时间、预算、采购方式。若需时间隔离，记录 publishTime 作为截止点。
读取正文：用 document(doc_id) 拉公告正文，识别采购方式（公开招标/询价/邀请/竞争性谈判/询比）、资质门槛、服务内容、是否联合体、特定许可要求。同时产出两块结论前置内容（见步骤 8 与「设计红线」）：① 资格要求两类式——从公告原文结构化拆成"公告已明确（任一不符即废标）"与"需查采购文件确认"两组；② 采购内容解读四象限——服务模式 / 人员要求 / 特有要求 / 关键核对项，并给出品类陷阱提示（如"劳务外包≠食材配送"）。
业主画像：用 company() 查采购人（业主）的工商基本信息（企业名称/统一社会信用代码/法人/企业类型/注册资本/成立日期/注册地址/登记状态/登记机关/经营范围），用 employee() 查主要人员（高管），据此生成报告的"业主情况说明"章节（置于"项目概况"之前）。插入位置红线：若报告已有"核心结论"章节，业主章节必须插在核心结论完整内容之后（即下一个 <h2> 之前），绝不能插在 <h2>核心结论</h2> 与其结论卡片/正文之间——否则核心结论的候选卡片会掉进业主章节，读者会看到两章内容混在一起。插入后用行集合 diff 校验"除位移外内容零丢失"。要点：只展示 isHistory==0 的现任人员；position 可能是逗号分隔的多职务（如"副董事长,董事,董事兼总经理"），须取其一展示；机关/事业单位的 employee() 常返回 300104001（查无记录），此时降级为"公开登记信息未披露主要人员名单，可确认的负责人为 XXX"。所属行业接口无直接字段，须依据 companyType + businessScope 判断，并在报告中标注"依据登记类型与经营范围判断"。
检索历史：用 search() 检索采购人历史公告 + 同类项目（同关键词/同地域）历史中标人，统计重复出现的供应商。时间隔离模式下，所有历史检索的 publishTime 严格早于截止点。
选择范式：按下方"六类范式决策树"判定本项目所属范式，确定预测重心。
候选核查：对 Top 候选用 company()（工商基本信息/经营范围）、executed()（被执行人）、dishonest()（失信被执行人）核查；遇到接口返回 401（未开通）则标记"未开通、跳过"，在报告局限段注明，不中止流程。
前三名企业档案：对 Top3 候选逐家生成"家底 · 业绩 · 合作 · 资质"档案（置于"这几家公司靠不靠谱"之后，后续章节顺延重编号）。章名用"企业档案"而非"企业实力"（"企业实力"属用户可见禁用词，见「设计红线」）。参与概率一律用单点代表值（如 90%），置信区间只在"预测边界"说明里提，不写进排名表。取数口径：
- 工商与高管：company() / employee()（同第 3 步的 isHistory、多职务、空壳返回三个坑）。
- 相关业绩：search() 必须传 winTenderer（string，中标单位字段）并显式传 publishTime（默认只查近三个月），拉取后本地再按 winTenderer 字段二次筛选（服务端过滤偏宽松）。
- 与业主合作次数与项目：tenderee（业主名）+ searchWord 关键词（企业名，range=30 全文），拉取后本地筛 winTenderer 含该企业名且 tenderee 含业主名——tenderee 单独过滤极不精确（大业主可返回数千条），必须本地二次筛选。查不到就如实写"公开记录中未见直接中标记录（不排除历史公告未完全覆盖）"，不得编造。
- 资质证书：POST service-api-open/v1/operation/qualification（OP-006），参数 companyName/pageNo/pageSize，返回 certName/certNumber/validStart/validEnd/authority。
- 司法：executed() / dishonest() 的 total，展示时注明"为公开记录全量条数，含历史陈案"，并指向上一章的资格判读。
- 该章节同样不得出现接口编号。
生成报告：复制 assets/report_template.html（v3，已内置核心结论 4-KPI、1.3 采购内容解读四象限、纯 CSS 条形图、行动建议判断卡），按"决策链"顺序填充并输出浅色主题 HTML：核心结论（4 KPI）→ 业主情况说明 → 项目概况（含 1.2 资格两类 + 1.3 采购内容解读）→ 历史依据 → 预测排名（含概率分布图）→ 资质与信用核查 → 前三名企业档案 → 关键判断与行动建议（5 骨架）→ 数据从哪来的。模板已内置统一设计系统，直接整段套用并填充占位符，勿回退旧版式（详见"输出规范 → 视觉规范"）。正文不得出现接口编号，仅"数据从哪来的"段保留 BID-/JU-/IC- 溯源编号。

六类范式决策树

按公告特征自动归类，决定"预测谁"的重心：

| 范式 | 识别特征 | 预测重心 | 典型信号 | |---|---|---|---| | 小额邀请询价 | 采购方式含"询价/邀请"且预算低于阈值（如 ≤20 万） | 历史被邀请/合作方，而非公开中标记录 | 正文写"被邀请的供应商才能参与" | | 强资质重渠道(医疗) | 资质要求医疗器械经营/生产许可、注册证 | 持牌经销商 + 厂家授权链 | "医疗器械""注册证""不接受进口" | | 强牌照 | 资质要求 IDC/增值电信/特定行业牌照 | 持牌运营商/服务商 | "IDC 资质""增值电信业务经营许可证" | | 强文保 | 资质要求文物保护/古建专项资质 | 文保名录企业 | "文物保护单位""古建筑工程" | | 轻资质重历史 | 资质门槛低、重业绩/案例 | 同类项目历史中标人外推 | 仅要求独立法人、无特定证书 | | 名录封闭 | 采购人为合格供应商名录制（国企/军工/轨交） | 名录内企业，公开记录稀缺 | "合格供应商""询比采购""候选公示" | | 通用(兜底) | 以上均不典型 | 资质 + 历史 + 地域综合评分 | — |

工商与司法核查（权限自检 + 优雅降级）

对 Top 3 候选企业调用 company()、executed()、dishonest()。
每个接口返回后检查业务 code：
- 200=成功，正常取数；
- 300104001=空结果（查无记录，可判为"干净"）；
- 300103001/401=该子 API 未开通，标记"接口未开通、跳过"，在报告"局限与不确定性"段如实注明，不报错中断。
限制高消费、经营异常、严重违法等接口若本账户未开通，同样优雅跳过并标注。

输出规范

使用 assets/report_template.html（v3）作为版式骨架（浅色主题、比地 logo 占位、章节结构完整、核心结论 4-KPI、1.3 采购内容解读四象限、纯 CSS 条形图、行动建议判断卡）。
报告必须包含（按供应商决策链顺序）：核心结论（4 张 KPI 卡：竞争烈度 / 头号对手 / 甲方确定性 / 价格锚点）→ 业主情况说明（采购人工商画像）→ 项目概况（基本信息 + 1.2 资格要求两类式 + 1.3 采购内容解读四象限）→ 历史依据 → 预测排名（含概率分布条形图） → 资质与信用核查表 → 前三名企业档案（家底·业绩·合作·资质） → 关键判断与行动建议（5 条骨架） → 数据从哪来的。
语言风格：面向非技术读者（老板、市场人员等），章节与表头用通俗口语（如"谁最有可能来投标""来的可能性""能接这活吗""是不是老赖"），专业术语以括号轻注（如"被执行人（被法院强制执行）"）。版式与措辞以 assets/report_template.html 为基准。
约束：报告正文（除"数据说明"段）不得出现 BID-/JU-/IC-/OP-/RISK-/CONS- 等接口编号及 JU： 类缩写；仅在"数据说明"溯源段保留编号以便核对。
约束：报告正文与"数据说明"段均不得出现接口调用方式、接口返回状态码、子接口编号（如 OP-006 子接口 134）、业务码（300104001）、HTTP 码（404/401）、"接口未开通/接口缺陷"等技术实现细节及"调用 XX 接口 N 次"等调用次数统计。溯源段描述来源时使用自然语言，如"通过公告搜索（BID-001）命中""均取自公开原始数据"等。数据覆盖不全或权限不足一律用"暂无对应数据 / 未能核验 / 覆盖不完整"等业务语言表述，禁止写"未开通""已开通""参数被后端忽略""字段名""docId"这类权限或技术词（公告编号写成"公告编号 824122163"而非 docId 824122163）。
交稿前自检（必做）：对成稿全文跑一遍正则 (BID|IC|JU|CONS|RISK|OP)-\d{3}|未开通|已开通|docId|调用|子接口|状态码|返回码|接口|字段|后端|参数|code=|API|token|JSON，逐条确认命中项只落在"数据说明/数据从哪来的/数据来源"章节；落在其它章节的一律改写。接口编号只允许在溯源段出现一次清单式列举，不要散落在结论、提醒、局限等叙述句里。
约束（通俗化改造红线）：对已生成报告做措辞通俗化改造时，只允许替换标题层（title/h1/h2/h3/tag）、表头（th）与白名单术语（如"潜在投标人"→"可能来投标的公司"、"失信被执行人"→"老赖"、"被执行人"→"被法院强制执行"、"核验"→"核对"、"司法数据"→"法院数据"）。严禁改动候选企业名单、评分、概率区间、金额、日期、依据文字与溯源编号。改造前必须把原文单独备份到独立目录；改造后必须做差分校验（对比改造前后的企业名集合 / 评分集合 / 概率区间集合 / 金额集合 / 日期集合 / 溯源编号集合），任一不一致立即回滚、绝不带病交付。
数据说明章节（精简口径）：只写"本报告用到哪几类数据"，维度式一句话带过——招标公告与公告正文 / 历史招标与中标记录 / 企业工商登记信息 / 司法与信用记录，括号里挂溯源编号（如 对应公告检索 BID-001/002、工商信息 IC-001、法院执行与失信记录 JU-001/002）+ 检索日期。不要展开检索式、关键词组合、时间窗口起止、命中条数、逐条检索过程（如"按采购单位=XXX 与关键词组合检索，共获取历史公告 86 条"）。用户要的是"数据来自哪些维度"，不是"怎么查的"。
参与概率口径（单点值，已对齐官方生成逻辑框架 v1.5）：排名表与核心结论一律用单点代表值（如 90%），不写"低–高"区间；置信带宽（如 85–95%）只在"预测边界"说明里作为推断口径提及，并标注样本量（近 N 年、有效投标人约 M 家）与依据强度（直接先例 / 同类外推 / 弱关联）。理由：用户实测"区间看不懂"，单点值更易决策。
视觉规范（模板已内置，直接套用即可，不得回退旧版式）：
- 版式骨架：assets/report_template.html 已内置自洽设计系统（浅色主题、1120px 容器、统一圆角/阴影/间距 token）。生成时整段复制模板并填充占位符，不要另写一套 CSS 或复用更早的简化版式。
- 目录导航：每个章节 <h2 id="sN"> 配一个 <section class="sec" id="sN-sec"> 包裹；页首 .brand 之后插入 <nav class="toc">，内含「目录」标签 + 各章节锚点链接（#sN，标题过长截 13 字加 …）+ 末尾 ↑ 回到顶部（#top，.wrap 需带 id="top"）。toc 为 sticky 毛玻璃横条，可横向滚动。
- 章节卡片化：所有章节内容包 <section class="sec">（白底、圆角、细边框、浅阴影），scroll-margin-top 避免被目录遮挡。
- 键值卡：工商信息 / 业主画像 / 项目要素等"标签-值"数据用 <dl class="kvlist">（响应式网格，<div><dt>标签</dt><dd>值</dd></div>）；内容超 55 字的项加 class="wide" 跨整行；「注册资本/金额/资本」项给 <div class="num"> 使数值右对齐、等宽数字。
- 表格：所有 <table> 包 <div class="tw">（横向滚动容器，表头浅底、斑马纹、hover 高亮）；表头含「金额/价格/预算/出资/注册资本/数量/条数/次数」的列加 class="num"（右对齐等宽），含「时间/日期/成立/发布/截止/年份」的列加 class="mid"（居中）。
- 结论卡片：若用 .cards 网格展示 Top3，nth-child 自动给第 1/2/3 张卡顶部上红/琥珀/绿色条，卡片 hover 上浮。
- 标题层级：h2 左侧渐变竖条、h3 左侧浅蓝竖条 + 渐变底；正文段落保持 11px 间距、行高 1.82；避免段落堆叠无间距。
- 响应式：≤900px 卡片 2 列、≤680px 单列；含打印样式（隐藏目录、去阴影）。

设计红线与禁用词（来自官方生成逻辑框架）

吸收比地《项目分析报告·生成逻辑框架》已验证的设计原则，作为本技能报告的交稿红线。这些红线优先于"把信息堆全"的冲动——供应商付费是为省时间，不是看数据汇编。

结构原则

每章第一段先给结论，数据放后面佐证：核心结论卡给判断，正文给依据，行动建议给动作，三层不重复。
每个数字带口径：无样本量、无时间范围的价格和概率一律不许出现（如"近 3 年、有效投标人约 5 家"）。
结论前置、正文论证：核心结论卡给判断，正文给依据，第七章给行动，三层不重复。

用户可见文案禁用词

评级化 / 模糊表述：头部 / 长尾 / 腰部 / CR5 / CR10 / 企业实力 / 信用合规 → 用客观事实替代（如"主要候选""分散参与者""企业档案"）。
"现任" → 统一为"上期中标供应商"（最近一次同类项目成交供应商），避免误读为本项目已中标单位。
内部术语不进用户可见文案：信号分 / 宽池 / 候选池代码 等一律不写；接口编号仅在"数据从哪来的"溯源段出现（详见接口编号约束）。

数据兜底三原则

缺失字段写"—"，脚注统一"以正式公告为准"；不编造、不用行业均值冒充。
不推算未来节点：开标 / 中标 / 公示等未发生节点一律不推算，脚注"以正式公告为准，公告发布后此处自动追加"。
样本不足不输出判读：如采购周期规律需 ≥3 个历史样本，不足则不输出该提示。

已确认避免的模块

报价参考：报价是最敏感输出，平台参考价一旦出错用户跟着报错价、责任无法承担；只保留客观历史成交统计，不做报价推荐。
时间倒排行动表：每个项目节奏不同，模板内置倒排表不通用；时间信息只以事实形式出现在项目进展。
"当前您正在查看"标记：报告是文档不是网页，导出 PDF 后无意义。

可视化体系（固定 5 图 + KPI 卡，全部纯 CSS，PDF 无兼容问题）

全部标注"演示口径 / 以平台实时统计为准"：

| 位置 | 图 | 数据输入 | 回答什么 | |:---:|---|---|---| | 核心结论 | 4 张 KPI 卡（2×2） | 各章预计算结论回填 | 结论先行 | | 四章排名表后 | 候选池参与概率分布条形图（深色=有效梯队≥30%） | 参与概率序列 | 竞争格局断档在哪 | | 四章对手档案 | 同系统同类中标数对比条形图 | 档案卡"同系统记录" | 谁是本系统常客 | | 五章采购人 | 历年项目金额趋势条形图（同色系=同品类） | 采购人历史项目金额 | 需求是涨是缩 | | 五章 | 预算 vs 成交价对比条形图 | 上期同类预算/中标金额 | 让价空间有没有先例 |

模板已内置 .kpis / .chart / .quad / .verdict 组件，直接填充即可。

交稿前自检清单（合并既有 + 框架）

[ ] 结构 = 核心结论（4 KPI，每卡含数据）+ 业主 → 概况 → 历史 → 排名 → 核查 → 档案 → 行动建议 → 数据来源
[ ] 每章第一段是结论，不是数据堆砌
[ ] 排名表与核心结论用单点概率值；"预测边界"含样本量与推断口径
[ ] 1.2 资格要求两类式（已明确 / 待确认），非行业通用清单
[ ] 1.3 采购内容解读四象限已给品类陷阱提示
[ ] 上期中标供应商已单独标记（未用"现任"）；"企业实力"等禁用词零出现
[ ] 成交价字段均注明"单笔合同成交总价"口径
[ ] 缺失字段写"—"，无编造；未推算未来节点
[ ] 正文（除"数据从哪来的"）无 BID-/JU-/IC-/OP-/RISK-/CONS- 编号及技术实现细节（见下方约束）
[ ] 可视化齐备：概率分布图、同系统中标数图、金额趋势图、预算vs成交图
[ ] 页脚含演示数据声明

报告增强（augment）模式（对已有报告注入 v3 组件）

当一份 HTML 报告正文已完整（业主章节 / 前三名档案 / 核查表等已写好，通常依赖 token 取数），但还缺 v3 的数据驱动组件（核心结论 4-KPI 卡、采购内容四象限、概率分布条形图、5 骨架判断卡）时，用 scripts/augment_v3.py 注入组件，比从模板整段重渲更省、且保住已写好的正文与历史数据。典型场景：token 受限无法重跑取数、或只是想把若干存量报告统一升级到 v3 视觉。

组件 JSON 结构（references/augment_v3_example.json 是可直接套用的完整范例）：

{
  "kpi": [{"lab": "竞争烈度", "val": "极高·封闭双雄", "note": "..."}, /* x4：竞争烈度/头号对手/甲方确定性/价格锚点 */],
  "quad": [["服务模式", "..."], ["人员要求", "..."], ["特有要求", "..."], ["关键核对项", "..."]],  /* x4 */
  "prob_chart": [{"label": "企业名", "val": 88, "dim": false, "val_label": "88%"}, /* dim=true 表示弱关联梯队 */],
  "verdict": [{"title": "...", "basis": "依据…", "action": "动作…"}, /* x5 骨架 */]
}

运行：
```
python scripts/augment_v3.py <现有报告.html> <组件JSON> <输出.html> [--check]
```
--check 会在写盘后自动跑一致性校验（组件齐全 / 禁用词 0 / 无占位符 / 标签平衡 / </style> 唯一），并打印 PASS / FAIL。
注入落点（脚本自动适配多种报告结构）：
- KPI 卡：优先注入「核心结论」h2 之后；若无独立「核心结论」章，则注入 hero 后、目录前并补 <h2>核心结论</h2>。
- 四象限：注入含「项目概况」或「是干嘛的」锚点的 <section> 末尾。
- 概率条形图：注入含「谁最有可能来投标」锚点的 <section> 末尾。
- 判断卡：对含「建议」或「提醒」的 <section>；若该 section 同时含「数据从哪来的 / 数据来源 / 方法说明」则追加（保住方法论说明），否则替换其后内容。
关键红线（踩坑固化）：脚本只把 v3 组件 CSS 追加进现有 </style> 之前，绝不整体替换 <style>。现有正文可能用到 .tag2 / .ins.green / .blue / .red / .tldr / .statrow / .danger 等类，模板 <style> 整体替换会丢失这些样式。.kpis/.kpi/.quad/.chart/.verdict/.boundary 在现有样式中均不存在，追加不冲突。
交稿前校验：无论是否用 --check，最终都要确保 6 份报告统一通过：kpis=1 / kpi=4 / quad=1 / chart=1 / verdict=5 / boundary 齐全；禁用词（头部/长尾/腰部/CR5/CR10/企业实力/信用合规/现任）全 0；无残留占位符 {{...}}；section/div/table/nav 标签平衡；</style> 唯一。
数据来源：组件数据一律复用报告已验证正文（候选名单、报价、核查结果），不新拉接口；缺失字段写"—"不编造；概率用单点值并配「预测边界」说明。

时间隔离模式说明

time_isolation=true 时：

截止点 = 目标公告 publishTime（精确到日）。
所有 search() 历史检索强制 publishTime.endTime < 截止点。
禁止用该标讯自身的中标/成交结果接口（如中标公告、候选公示）反推；预测完全基于截止点前的公开历史。
报告中明确标注"本报告按时间隔离口径生成，未引用该项目中标结果"。

局限与注意事项

邀请制/询价制项目公开渠道看不到邀请名单，预测的是"被邀请可能性"而非中标确定性，须如实说明。
历史样本薄（如仅单一同类先例）时，降低置信区间并在报告中标注。
每次 API 调用计费，以满足请求为前提尽量减少调用次数，结果中说明检索范围。
不推测缺失的预算、采购单位或截止时间；缺失则标注"公告未披露"。