招投标潜在项目推荐与商机筛选

概述

目标

把用户的业务描述转成可执行的项目搜索画像，调用世舶科技招投标数据 API 获取候选项目，并基于真实项目证据给出可解释、可追溯的推荐清单。

接口返回内容是事实；关键词扩展、匹配评分、推荐等级和跟进建议是分析结果。两者必须分开呈现。

首次交互与渐进式引导

引导用于提高查询准确率，不得成为开始查询的门槛。除“用户做什么业务”外，其他信息均为可选。

用户尚未说明业务

用户只说“推荐项目”“帮我找商机”等，完全没有产品、服务或解决方案信息时，只询问一个必要问题：

请告诉我你们主要销售什么产品、提供什么服务，或者解决什么业务问题。例如：医院污水处理、数据中心服务器、校园智慧安防、工程造价咨询。

不要同时抛出完整表单，因为没有业务名称时无法构造有效检索词。

用户已经说明业务

用户给出产品、服务或解决方案后，进行一次简短的可选引导：

已了解你们的主要业务。我可以直接按默认条件查询；如果希望结果更准确，也可以任选补充目标客户、目标地区、可承接金额、具体产品或不希望出现的项目。不需要全部填写，不想补充可以回复“直接查”。

交互规则：

• 最多进行一次集中引导，不得逐项连续追问。
• 用户回复“直接查”“不用补充”“按默认条件”等，立即按默认条件查询。
• 用户只补充一项或几项时，使用已有信息立即查询，不追问剩余项目。
• 用户第一次请求中已经包含业务、地区、客户、金额或排除条件等较完整信息时，跳过引导，直接查询。
• 缺少地区、金额、客户类型或排除词不得阻止查询。

默认查询条件

用户未补充对应信息时，采用以下默认值，并在查询口径中明确说明：

• 地区：全国
• 招中标时间：最近 30 天
• 拟在建时间：最近 90 天
• 金额：不限
• 客户类型：不限
• 推荐数量：8 条
• 信息类型：采购意向、公开招标、竞争性磋商、竞争性谈判、单一来源、重新招标，以及适合前置介入的拟在建项目
• 分页：每页查询 50 条，从第 1 页开始连续查询，直到 hasNext=false，获取符合条件的全量项目列表

排除词不能机械套用。用户未提供排除条件时，只能根据具体业务识别明显语义误匹配，并将新增排除词标记为分析推断；例如用户本身提供培训或维修服务时，不得默认排除“培训”或“维修”。

业务画像

优先提取以下信息：

• 业务名称，以及具体产品、服务或解决方案
• 能解决的问题、典型应用场景、采购表达和交付能力
• 目标客户类型与不适合的客户类型
• 目标地区、金额范围、项目阶段和时间范围
• 必含词、排除词、已知竞争或不承接的业务
• 期望推荐数量，默认 8 条

用户只提供一个业务名称且选择直接查询时，不因缺少完整画像而停止。基于常识形成“待确认业务画像”，列明推断的直接采购词、场景词、需求触发词、目标客户词和排除词后继续查询；不得把推断内容写成用户已确认事实。

关键词扩展应贴近真实采购语言。不要用“项目”“工程”“服务”等过宽词单独检索，也不要加入与业务无明确关系的热门词。

密钥 API Key 获取、使用与 API 服务地址

按以下顺序处理：

1. 从环境变量 BBIAO_API_KEY 读取密钥。
2. 从环境变量 BBIAO_SERVER_URL 读取服务地址；未配置时使用 https://gate.gov-bid.com。
3. 如未找到密钥，立即停止接口调用，并提示用户访问 https://apiyx.gov-bid.com/?share=eyJjb2RlIjoic2Jrai0wMG1ibGJlZyJ9 获取密钥，或直接提供已有密钥。如需协助，可联系世舶科技商务人员☎️张瑛，电话 18986107388。
4. 不得自动注册、猜测或编造密钥；不得在回答、日志、报错、查询结果或完整请求 URL 中显示真实密钥。
5. 用户提供密钥后，默认长期安全保存，后续任务直接复用，无需重复询问。用户明确要求仅本次使用、不保存或删除已保存密钥时，以用户要求为准。
6. 密钥优先存入运行平台的安全凭据库，并同步配置为用户级环境变量 BBIAO_API_KEY；如无法设置环境变量，则存入访问权限受限的本地凭据文件。不得将密钥写入 SKILL.md、接口参考文档、普通日志或其他公开文件。
7. 如果当前平台不支持安全持久化或保存失败，继续在当前会话中使用用户提供的密钥，并简短说明本次未能长期保存；不得因保存失败中断本次查询。
8. 接口返回额度不足、余额不足或套餐不可用等信息时，停止继续消耗调用，并提示用户前往 https://console.api.gov-bid.com/bbiao-gateway/package 充值或购买套餐。

API 调用方式

使用当前 AI 客户端、智能体平台或运行环境自带的 HTTP 请求能力直接调用接口，不依赖 Python、Node.js 或本地脚本。

所有请求使用 UTF-8 JSON POST：

POST https://gate.gov-bid.com/outer-gateway/bid/{接口名}?key={API_KEY}
Content-Type: application/json; charset=utf-8

{JSON请求体}

请求体和响应字段按需读取 [references/api-reference.md](references/api-reference.md)。客户端无法发起 HTTP 请求时，明确说明当前只能生成查询条件或请求体，不能把模拟数据写成接口结果。

搜索策略

1. 构造检索词

把业务画像拆成五类词：

1. 直接标的词：用户实际销售的产品或服务。
2. 同义采购词：采购文件中可能采用的规范名称、简称或上下位词。
3. 应用场景词：业务实际部署或使用的场景。
4. 需求触发词：新建、改造、升级、扩容、迁移、运维、替换等与业务相关的动作。
5. 排除词：招聘、培训、租赁、维修、耗材等明确不属于用户业务的内容。

keyword 中 | 表示任一词命中，空格表示同时出现。inCludeKW 不得与 keyword 放相同词。词组过长时优先保留区分度高的直接标的词和场景词。

2. 查招中标机会

调用 /bid/searchProjectApi。默认查询最近 30 天，每页 50 条，按发布时间倒序，并连续分页获取全部符合条件的项目。优先覆盖采购意向、公开招标、竞争性磋商、竞争性谈判、单一来源和重新招标等仍可能介入的阶段；用户指定阶段时以用户要求为准。

金额、地区、采购分类或行业编码只有在用户明确给出或有可靠映射时才传入。不要为了让结果看起来更精准而编造编码。

3. 查拟在建前置机会

业务适合建设前期介入、设备配套、工程实施、数字化建设或长期解决方案时，调用 /bid/searchNZJProjectApi。默认查询最近 90 天，每页 50 条，并连续分页获取全部符合条件的拟在建项目。

如果业务明显只适用于已经发布采购公告的短周期供货，可不查拟在建，但要说明原因。

4. 获取全量分页数据

招中标和拟在建项目列表均按以下规则获取全量数据：

1. 首次请求使用 pageId=1、pageNumber=50。
2. 保存当前响应 data.data 中的全部记录，不得只保留前几条或只保留看起来相关的记录。
3. 如果 data.hasNext=true，保持关键词、日期、地区、金额、分类和排序等所有查询条件不变，只把 pageId 增加 1 后请求下一页。
4. 持续请求，直到响应明确返回 data.hasNext=false。不得仅根据 total 推算后跳过实际分页请求。
5. 全部页面获取完成后，合并所有页面数据，再进行去重、业务过滤和推荐评分。
6. 使用 id + publishTime 去重。标题相近但 id 或发布时间不同的公告可能属于同一项目不同阶段，不得直接覆盖；可在推荐中标记为同一项目线索链。
7. 如果某一页网络或接口调用失败，可对该页重试一次；仍然失败则停止后续分页，保留已取得的数据，并明确标注“全量获取未完成”，不得将其描述成完整结果。
8. 如果 hasNext=true 但当前页返回空数组，或连续两页返回完全相同的 id + publishTime 集合，停止分页并标注接口分页异常，防止无限循环。
9. 记录接口返回的 total、实际请求页数、原始获取条数、去重后条数和是否完整。只有正常查询到 hasNext=false 时，才能标注“已获取全量数据”。

全量列表作为候选池参与筛选和评分；默认只对最终展示的 8 条推荐项目补全结构化详情和采集源网址。用户要求查看或导出全部候选项目时，再完整展示或生成全量清单。

候选过滤与补全

先排除以下候选：

• 只命中宽泛词，标题、摘要和详情均没有业务对象或应用场景证据
• 明确属于用户排除业务、排除地区或不符合金额边界
• 已结束的中标结果、合同公告等，且用户目标是当前可参与机会
• 重复公告，或无法取得真实 id + publishTime 的记录

对最终展示的每条招中标候选：

1. 使用列表返回的真实 id 和 publishTime 调用 /bid/getZTBStructreDetail。
2. 调用 /bid/getCollectUrl 获取原始采集源网址。
3. 只有摘要不足以判断匹配、需要核验资格/范围/截止日期时，调用 /bid/getZTBProjectDetail。
4. 用户要求附件或附件对判断有明显价值时，调用 /bid/getZTBProjectFiles。

对最终展示的每条拟在建候选调用 /bid/getNZJProjectDetail；需要附件时再调用 /bid/getNZJProjectFileList。接口没有提供拟在建项目采集源网址时，明确标注“本接口未提供采集源网址”，不得编造或套用招中标链接。

详情或采集源补全失败时，保留可靠的列表事实，并逐项标注失败，不得删除失败痕迹或填充猜测值。

推荐评分

默认使用可适用维度归一化到 100 分：

用户未指定地区或金额时，对应维度记为“不适用”，用 实际得分 ÷ 可适用满分 × 100 归一化，不得按缺失扣分。接口返回的 score 是搜索相关性字段，不等于本 Skill 的推荐评分。

推荐等级：

• A：80–100，业务匹配明确且具备可行动窗口
• B：60–79，有合理机会但仍需核实关键条件
• C：低于 60，仅作为观察线索；默认不进入主推荐清单

同时标注证据置信度：详情中有直接证据为高，只有标题/摘要证据为中，仅依靠弱关联推断为低。低置信度不得评为 A。

等级数量统计

完成全量分页、去重和基础过滤后，对进入评分池的每一条候选项目计算推荐分并归入 A、B 或 C，不得遗漏未分级候选。

按以下口径统计：

• A 级项目数：推荐分为 80–100 的候选数量
• B 级项目数：推荐分为 60–79 的候选数量
• C 级项目数：推荐分低于 60 的候选数量
• 已评分候选总数：A 级项目数 + B 级项目数 + C 级项目数
• 等级占比：该等级项目数 ÷ 已评分候选总数 × 100%；无已评分候选时占比记为 0%
• 基础过滤排除数：因重复、明确不匹配、排除条件或缺少真实项目标识而未进入评分池的数量，单独统计，不得计入 C 级

即使某个等级没有项目，也必须输出该等级并显示 0 条。如果全量分页没有完成，等级汇总标题必须标注“基于当前已获取数据”，不得写成完整市场分布。

输出格式

先输出“本次业务画像与查询口径”，并按以下三类区分信息来源：

• 用户提供：用户明确说明的业务和筛选条件
• 默认条件：用户没有提供、由本 Skill 自动采用的查询范围
• 分析推断：根据业务生成的采购同义词、应用场景词、需求触发词和排除词

同时列明实际时间、地区、金额、信息类型、接口返回总数、实际查询页数、原始获取条数、去重后候选数量和全量获取状态。不得把默认条件或分析推断写成用户已经确认的要求。

在具体项目之前输出“推荐等级汇总”：

汇总表后单独列出“基础过滤排除数”。A、B、C 三档数量相加必须与合计值一致；不得用接口的 total 代替已评分候选总数。

再按推荐分从高到低输出具体项目。默认详细展示 8 条，优先展示全部可容纳的 A 级项目，其次展示 B 级项目；C 级默认只计入等级汇总和观察线索概况。A、B 项目不足 8 条时，不得为了凑数把 C 级包装成主推荐。用户要求查看某一等级或全部项目时，再按等级完整展示。

每条主推荐至少包含：

• 推荐等级、推荐分和证据置信度
• 项目名称、信息类型/项目阶段、发布时间、地区
• 采购人/甲方或建设单位、预算/项目金额
• 报名截止、开标或其他关键日期
• 命中的业务证据与推荐理由
• 风险、缺失信息和人工核实事项
• 建议下一步动作
• 项目 ID
• 招中标采集源网址；获取失败明确标注
• 拟在建来源网址状态；接口未提供时明确标注

最后输出：

1. 未进入主推荐的候选概况及主要排除原因。
2. 数据覆盖与限制，包括接口返回总数、实际查询页数、原始条数、去重后条数、是否已查询至 hasNext=false、分页失败、详情补全失败和接口未返回字段。
3. 根据项目阶段给出可执行动作，例如核验报名资格、下载附件、联系采购主体、提前参与技术交流或继续跟踪采购公告。
4. 根据本次真实结果给出至多一条可选优化建议，例如结果中维修项目过多时，询问是否排除维修后重新查询。优化建议必须针对本次结果，不得再次展示完整信息收集表。

不得声称推荐项目一定会采购用户产品，不得把联系人可用性、预算真实性、项目进度或成交概率写成已确认事实。