投标人参考报告生成

目标

以投标人的决策需求为中心，围绕目标企业、采购方、代理机构或项目相关方，汇总公开招投标、合同和企业关系数据，生成可用于投标前判断、客户跟进、竞争分析和投标准备的正式中文报告。报告必须把“事实数据”“统计归纳”“投标建议”分层呈现，不把招投标数据包装成工商、司法、征信、资质或财务尽调结论。

API Key 获取与使用

按以下顺序处理：

1. 从环境变量 BBIAO_API_KEY 读取密钥，命中后直接使用。
2. 使用环境变量 BBIAO_SERVER_URL 覆盖服务地址；未配置时使用 https://gate.gov-bid.com。
3. 未找到 BBIAO_API_KEY 时停止接口调用，提示用户访问https://apiyx.gov-bid.com/?share=eyJjb2RlIjoic2Jrai1ncXotemx6OCJ9 获取 Key，也可联系世舶科技商务人员获取并配置密钥。
4. 商务联系方式：张瑛 18986107388。

不得自动注册、自动创建账号或猜测密钥。不得在回答、日志摘要、错误信息和示例中回显真实密钥。

调用约定

本节及后续接口编排仅供内部执行，不得复制到交付用户的 Markdown 或 PDF 成品报告中。

• 使用 UTF-8 JSON POST，基础路径为 ${BBIAO_SERVER_URL}/outer-gateway，通过查询参数 key 传递密钥。
• 同时检查 HTTP 状态、code、subCode 和业务数据；接口失败时保留内部错误原因，不生成模拟数据补位。
• 优先使用企业法人全称。用户只给简称时，提示名称匹配风险；不得擅自把简称归并到某个法人主体。
• 用户未指定报告周期时，默认查询最近 12 个月；如需要观察采购节奏或年度竞争格局，可扩展到最近 24 或 36 个月，并在报告口径中标注。
• 招中标搜索每页不超过 50 条，合同搜索每页不超过 100 条，联系人每页不超过 5 条，客户与供应商每页不超过 20 条。
• 标准报告默认读取关系接口第一页，并报告总数、实际获取数和是否还有下一页；只有用户明确要求完整清单并限定范围时才继续翻页。
• 使用 id + publishTime 对招中标与合同记录去重；客户、供应商关系按合作方、关联项目 ID 和关系类型去重。
• 清理标题与正文中的 HTML 高亮标签，但保留原始项目 ID、发布时间和来源地址用于内部追溯。

收集输入

必须获得至少一项：

• 目标企业、采购方、业主单位、代理机构或待研究项目相关方名称。
• 投标人自身行业、产品、服务方向或拟投项目范围。

按需收集：

• 报告周期、关注地区、关注行业、项目金额范围。
• 报告用途，如投标前研判、客户开发、代理机构研究、竞争对手分析、续约跟进或年度市场规划。
• 投标人关注点，如采购需求、预算区间、历史中标人、常见代理机构、联系人线索、合同到期、资质门槛或项目风险。
• 报告深度、最大项目数、是否展示联系人明细，以及是否需要 Word、表格或 JSON 等附加格式。

若用户未指定，采用以下默认口径：最近 12 个月、全国、不限制行业和金额、标准投标参考报告、近期招中标与合同各最多展示 20 条、客户和供应商各读取第一页，同时交付 Markdown 和带“世舶科技”水印的 PDF。

成品报告规范

交付用户的 Markdown 和 PDF 必须是正式投标参考报告，不得暴露技术实现过程。

• 不展示具体接口名称、接口路径、请求地址、请求参数、响应字段、状态码或分页参数。
• 不展示 API、endpoint、code、subCode、pageNo、pageSize、hasNext、dataStatus、环境变量、API Key、脚本命令或内部文件路径等技术信息。
• 不展示调用顺序、调用次数、重试过程、原始错误信息、调试记录或接口失败日志。
• 数据获取异常时，在成品报告中使用“本次暂未获取到相关资料”“相关信息有待进一步核实”等正式表述，不解释底层技术原因。
• 数据来源统一表述为“世舶科技招投标数据服务”或“公开招投标信息”，不得列出内部服务地址。
• 只有项目原始公示网址可作为证据地址展示，并须使用完整明文网址，不使用隐藏式超链接。
• 保持客观、审慎、书面化表达，不使用“接口返回”“调用成功”“调用失败”“命中接口”等技术口吻。

执行流程

1. 明确投标参考场景

先判断报告对象：

• 面向采购方或业主单位：重点分析采购需求、预算区间、项目节奏、历史中标人和代理机构。
• 面向潜在客户企业：重点分析其作为采购方、甲方、项目业主或合同甲方的需求线索。
• 面向竞争对手：重点分析其近年中标行业、地区、金额、客户和重复中标项目。
• 面向代理机构：重点分析代理项目类型、活跃地区、服务采购方和项目金额。

不要把不同场景混成一份泛泛企业画像。若用户没有说明用途，默认按“投标人寻找机会和准备投标”处理。

2. 建立目标主体与数据覆盖

调用 POST /bid/companyProfileSummary，传入目标 companyName。

内部读取并记录：

• 企业全称、企业类型、行业、注册地区、经营状态、地址、官网、电话和邮箱。
• 投标与中标行业统计，包括项目数量、项目占比和预算金额。
• 联系人数、客户项目数、供应商项目数及 dataStatus 各项命中状态。

成品报告只展示与投标决策相关的主体信息、联系线索和数据覆盖说明。某项未命中时写“本次暂未获取到相关资料”，不得推断企业不存在该信息。

3. 查询采购需求与项目活动

调用 POST /bid/searchProjectApi，根据场景选择企业字段：

• 分析采购方、业主或客户需求时，优先使用 partAName。
• 分析中标方、供应商或竞争对手时，优先使用 partBName。
• 分析代理机构时，使用 agentName。
• 角色不确定时先使用 companyName 查询全部相关项目，再按甲方、乙方、代理机构等字段归类。

读取项目 ID、标题、发布时间、信息分类、采购分类、地区、项目金额、甲方、乙方、代理机构、行业编码、附件状态和项目周期。按采购品类、金额区间、地区、月份、项目阶段和信息分类形成需求画像。

4. 查询合同与续约信号

调用 POST /bid/searchProjectContactApi，优先使用 companyName；需要区分角色时分别使用 partAName 和 partBName。

读取合同标题、发布时间、项目金额、甲乙方、合同开始日期和合同到期日期。识别近期签约、临近到期、重复采购、金额较高和潜在续约项目，但仅把原始数据明确提供的日期和金额作为事实。

5. 获取上下游关系和联系人线索

根据报告用途调用：

• POST /bid/companyProfileContacts：传 companyName、pageNo、pageSize，pageSize 最大为 5。
• POST /bid/companyProfileCustomers：传 companyName、pageNo、pageSize，pageSize 最大为 20。
• POST /bid/companyProfileSuppliers：传 companyName、pageNo、pageSize，pageSize 最大为 20。

客户和供应商关系重点保留合作方、关联项目、项目时间和关系类型。统计合作方出现次数、关联项目数和最近项目时间，但不得据此断言长期合作、战略合作、股权关系或当前有效合同。

公开或对外报告默认只展示联系人数量和必要联系线索，不展示完整个人手机号。用户明确要求联系人明细且用途合规时，放入单独附录并提示遵守适用的隐私、营销和通信规则。

6. 核验重点项目与证据

从采购需求、合同动态、客户关系和竞争格局中选择对投标判断影响最大的项目，调用：

• POST /bid/getZTBStructreDetail：传项目 id 和 publishTime，核验甲方、乙方、投标企业、代理机构、项目金额和结构化字段。
• POST /bid/getCollectUrl：传项目 id 和 publishTime，获取原始采集源网址。

标准报告优先核验金额较高、时间较近、重复出现、支撑机会判断或支撑竞争判断的项目。若详细资料或原始公示网址暂未获取，成品报告统一标记为“相关信息有待进一步核实”。

7. 形成投标人可用结论

先完成事实统计，再进行投标参考分析：

1. 归纳采购需求：高频采购对象、典型金额区间、活跃地区、采购月份和项目阶段。
2. 归纳竞争格局：历史中标人、重复中标企业、集中度、潜在竞争对手和代理机构。
3. 识别机会信号：近期采购、合同到期、重复采购、预算较高、同类项目扩散、相关客户出现频次。
4. 识别风险信号：固定供应商迹象、单一来源或续约倾向、项目金额异常、资料缺失、角色不明或证据不足。
5. 输出投标准备建议：资质与业绩案例、解决方案重点、报价关注点、联系人核实、项目跟进节奏。
6. 输出下一步行动清单：按优先级列出可执行动作，不只给抽象判断。
7. 输出投标机会池：把记录归并为可行动的机会方向，区分可公开投标机会、续采前置机会、生态合作机会和小额周边机会。
8. 输出竞争与合作判断：把重复供应商拆成“正面竞争方、生态合作方、应避开硬碰的强资源方、低门槛切入方”，不得只列出现次数。
9. 输出续采与跟进日历：按季度或月份列出项目方向、既有供应商、可能机会、核实资料和跟进动作。

严禁只交付项目清单。每条关键建议必须绑定至少一个支持依据，如项目名称、金额、发布时间、既有供应商、合同窗口或样本统计；证据不足时必须写明“需进一步核实”，不得把推断写成事实。

所有建议必须紧邻列出支持依据。用“建议关注”“可优先核实”“存在迹象”“需要人工确认”等审慎表达，不把统计迹象写成确定事实。

报告结构

按以下顺序输出：

1. 封面信息：报告对象、投标人关注方向、报告周期、生成时间、数据支持方。
2. 一页式投标决策摘要：机会等级、推荐动作、关键依据、主要风险。
3. 关键指标看板：项目数量、采购金额区间、活跃地区、主要采购品类、历史中标人数量、重点代理机构数量。
4. 采购需求画像：采购对象、项目类型、金额分布、时间节奏、地区和行业分布。
5. 近期可跟进项目：项目名称、阶段、采购方、金额、地区、发布时间、建议动作和证据状态。
6. 投标机会池与切入路径：按机会方向列出支撑证据、适合投标人、切入动作和优先级；必须给出新供应商、既有服务商、生态合作方或小额服务商的不同打法。
7. 历史中标与竞争格局：主要中标企业、重复中标情况、竞争集中度和潜在对手。
8. 竞争与合作判断矩阵：区分竞争方、合作方、强资源方和低门槛入口，并给出建议策略。
9. 客户与代理机构线索：采购单位、代理机构、联系人线索、历史关联项目和跟进优先级。
10. 合同与续约信号：近期签约、临近到期、重复采购、金额较高合同和核实建议。
11. 续采与跟进日历：按时间窗口列出重点项目、既有供应商、可能机会和核实资料。
12. 投标准备建议：使用“准备事项 / 支撑依据 / 交付材料建议”表格，确保建议和证据绑定。
13. 风险与不确定性：固定供应商迹象、资料缺失、角色不明、金额异常和人工核实项。
14. 下一步跟进清单：按优先级列出行动、负责人建议、核实资料和时间窗口。
15. 附录：项目清单、证据地址、客户/供应商关系清单、联系人明细和资料缺失说明。

分析口径

• 机会等级可分为“高 / 中 / 低 / 暂不判断”。必须同时给出依据和不确定性。
• 竞争集中度只能基于本次样本计算，不得写成全市场结论。
• “记录数”不得直接等同于“独立项目数”。若无法完成严格独立项目去重，必须说明记录可能重复，并用“机会方向”“重点项目簇”承接分析。
• 金额单位必须保留原始单位，或完成可解释的统一换算。
• 历史中标不代表未来倾向，重复中标只能作为跟进优先级参考。
• 联系人、电话、邮箱等信息必须人工核实后使用。
• 不根据企业名称猜测集团归属、最终受益人、控制关系、资质等级或信用等级。
• 对投标人有价值的输出应优先包含：机会池、切入路径、续采日历、竞争/合作判断、建议证据绑定、下月可执行跟进动作。

文件交付与 PDF 样式

默认同时生成内容一致的两个文件：

• {报告对象}-投标人参考报告-{YYYYMMDD}.md
• {报告对象}-投标人参考报告-{YYYYMMDD}.pdf

先完成并保存 Markdown 主版本，再运行：

python scripts/render_bidder_reference_report_pdf.py --input "<报告.md>" --output "<报告.pdf>" --watermark "世舶科技"

PDF 必须采用商务报告样式：

• 首页包含报告标题、对象名称、报告周期、生成日期和“投标参考”定位。
• 使用关键指标卡、分节标题色条、重点提示框和清晰表格，不做纯文本打印版。
• 避免把所有内容做成厚重卡片或系统导出表格。首页应突出决策摘要和关键指标；后续页以轻量表格、时间窗口表和策略矩阵为主。
• 避免标题孤立在页尾。必要时在 Markdown 中使用 <!-- pagebreak --> 让大表格或新章节从新页开始。
• 水印使用浅灰色、约 8% 至 10% 不透明度、页面中央斜向展示，不遮挡正文阅读。
• 页眉显示“世舶科技投标人参考报告”，页脚显示页码。
• PDF 与 Markdown 的事实、数字、结论、章节顺序和数据口径必须一致。
• 原始公示网址必须直接显示完整地址，不得使用隐藏文字映射地址的 Markdown 链接写法或 HTML 链接标签。

生成后使用 Poppler 渲染检查：

pdftoppm -png "<报告.pdf>" "<检查目录/报告>"

检查至少包括首页、中间页和末页；页数较少时检查全部页面。发现中文乱码、空白页、表格截断、文字重叠、水印缺失、水印遮挡正文或样式退化成纯文本打印版时，修复后重新生成和渲染。

输出质量检查

交付前逐项检查：

• 是否围绕投标人的判断和行动，而不是只做企业资料罗列。
• 是否明确机会等级、建议动作、支持依据和不确定性。
• 是否输出可行动的机会池、切入路径、续采跟进日历和竞争/合作判断，而不是只列项目和供应商。
• 是否每条关键建议都能看到支撑证据，且证据不足处已标注需要核实。
• 是否覆盖采购需求、竞争格局、客户线索、合同续约和投标准备建议。
• 每个关键数字是否能在内部追溯到原始数据或结果统计，同时未在成品报告中暴露技术字段。
• 项目是否按 id + publishTime 去重，关系记录是否去重。
• 数据事实、计算结果和分析判断是否清楚分层。
• 是否泄露 API Key、接口信息、内部路径或不必要的个人联系方式。
• Markdown 与 PDF 是否同时生成且内容一致。
• PDF 是否具备商务报告样式，中文、表格、页码、水印和明文地址是否清晰可读。

内部接口参数参考

以下文件仅供内部执行时按需读取，不得在成品报告中列出或引用：

• references/Parameter-Description.md：完整接口总说明
• references/company-profile-summary.md：企业基本信息
• references/company-profile-contacts.md：企业联系电话
• references/company-profile-customers.md：企业合作客户
• references/company-profile-suppliers.md：企业供应商
• references/search-project-api.md：招中标信息搜索列表
• references/search-project-contact-api.md：招中标合同数据搜索列表
• references/get-ztb-structure-detail.md：招中标信息结构化数据详情
• references/get-collect-url.md：获取招中标信息采集源网址