企业招投标研究报告生成

目标

以企业全称为主键，组合企业画像、招中标、合同及上下游项目关系数据，生成结构稳定、来源明确、可直接交付的正式中文企业研究报告。严格区分数据事实、统计结果和分析判断，不把招投标数据报告包装成完整的工商、司法、征信或财务尽调报告。

⭐ 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 个月，并在报告口径中明确标注。
• 招中标搜索每页不超过 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. 建立企业身份与数据覆盖

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

读取并记录：

• 企业全称、企业类型、所属行业、注册地区、法定代表人、成立日期和经营状态。
• 统一社会信用代码、注册号、组织机构代码、登记机关、注册资本和实缴资本。
• 经营范围、营业期限、核准日期、参保人数、注册地址、最新地址、官网、电话和邮箱。
• 投标与中标行业统计，包括项目数量、项目占比和预算金额。
• 联系人数、客户项目数、供应商项目数及 dataStatus 各项命中状态。

内部使用 dataStatus 判断资料覆盖情况，但不得在成品报告中显示该字段名。某项未命中时写“本次暂未获取到相关资料”，不得推断企业不存在该信息。

2. 获取联系人和上下游关系

根据报告用途调用：

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

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

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

3. 查询近期招中标活动

调用 POST /bid/searchProjectApi，使用报告周期和以下企业字段：

• 角色不确定时先使用 companyName 查询全部相关项目。
• 分析采购方活动时使用 partAName。
• 分析中标方或供应商活动时使用 partBName。
• 分析代理活动时使用 agentName。

读取项目 ID、标题、发布时间、信息分类、采购分类、地区、项目金额、甲方、乙方、代理机构、行业编码、附件状态和项目周期。分别归纳企业作为采购方、投标方、中标方或代理机构的活动，不根据标题自行补造角色。

4. 查询合同动态

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

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

5. 核验重点项目与来源

从近期项目、客户关系和供应商关系中选择对报告结论影响最大的项目，调用：

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

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

6. 形成统计与判断

先完成事实统计，再进行分析：

1. 汇总基础画像和数据命中状态。
2. 汇总投标、中标行业分布和预算金额，保留原始数据单位。
3. 汇总报告周期内的项目数量、角色分布、地区分布、行业分布和金额分布。
4. 汇总主要客户、主要供应商、关联项目和最近合作时间。
5. 汇总合同开始、到期和金额信息。
6. 基于已获取数据提出业务机会、合作集中度、活动变化和待核实风险信号。

所有分析结论使用“数据显示”“可能”“建议核实”等审慎表述，并紧邻列出支持该结论的项目记录、原始公示资料或统计口径，不展示内部接口信息。

报告结构

按以下顺序输出：

1. 报告封面信息：企业名称、报告周期、生成时间、报告用途、数据支持方。
2. 执行摘要：三至八条关键发现，区分事实和分析判断。
3. 研究口径与资料范围：研究周期、地区和行业范围、样本数量、资料完整性说明。
4. 企业基本画像：注册、经营、行业、地区、资本、地址和官网信息。
5. 招投标能力画像：投标与中标行业、项目数量、占比、预算金额和角色分布。
6. 近期项目动态：采购、投标、中标和代理项目时间线。
7. 合同动态：合同金额、起止日期、甲乙方及临近到期项目。
8. 客户关系分析：主要客户、关联项目、最近合作时间和集中度提示。
9. 供应商关系分析：主要供应商、关联项目、最近合作时间和集中度提示。
10. 重点项目依据：项目名称、企业角色、金额、发布时间、原始公示网址和核实说明。
11. 机会与风险信号：仅基于本次可得资料提出，并附判断依据和核实建议。
12. 附录：主要项目清单、客户与供应商关系清单、合规范围内的联系人明细及资料缺失说明。

文件交付与 PDF 水印

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

• {企业全称}-招投标研究报告-{YYYYMMDD}.md
• {企业全称}-招投标研究报告-{YYYYMMDD}.pdf

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

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

生成 PDF 时遵守以下规则：

• 每一页都添加“世舶科技”文字水印，包括封面、正文和附录。
• 水印使用浅灰色、约 10% 不透明度、页面中央斜向展示，不遮挡正文阅读。
• 使用支持中文的字体，保留报告标题层级、列表、表格、页码和原始公示网址。
• PDF 与 Markdown 的事实、数字、结论、章节顺序和数据口径必须一致。
• 成品报告只展示项目原始公示网址，不展示服务接口地址、内部文件路径或脚本路径；原始公示网址必须直接显示完整地址，不得使用隐藏文字映射地址的 Markdown 链接写法或 HTML 链接标签。
• 用户要求 Word、表格或 JSON 时，可在默认的 Markdown 和 PDF 之外增加附加格式，不得用附加格式替代这两个默认文件。
• 无法使用内置脚本时，改用运行环境可用的 PDF 工具，但仍须确保每页存在“世舶科技”水印。

生成后使用 Poppler 渲染检查：

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

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

输出质量检查

交付前逐项检查：

• 企业名称是否一致，简称与法人主体是否存在混用。
• 报告周期、地区、行业、页数和最大记录数是否明确。
• 每个关键数字是否能在内部追溯到原始数据或结果统计，同时未在成品报告中暴露技术字段。
• 项目是否按 id + publishTime 去重，关系记录是否去重。
• 金额单位是否保留或完成了可解释的统一换算。
• 数据事实、计算结果和分析判断是否清楚分层。
• 资料缺失、样本范围和待核实事项是否使用正式语言如实披露。
• 是否泄露 API Key 或不必要的个人联系方式。
• Markdown 与 PDF 是否同时生成且内容一致。
• PDF 每页是否都有“世舶科技”水印，中文、表格、页码和明文地址是否清晰可读。
• Markdown、PDF 和 Skill 文档中是否不存在隐藏式 Markdown 或 HTML 超链接，所有地址是否以明文形式展示。
• 成品报告中是否完全排除接口路径、参数名、状态码、分页字段、调用日志、脚本命令、API Key 和内部文件路径。

数据边界

• 企业画像和招投标数据来自本次可获得的资料范围，不代表企业全部经营、财务、司法、信用或关联关系信息。
• 投标与中标预算金额不等同于企业营业收入、实际合同收入或利润。
• 客户和供应商数据反映项目关系，不代表当前持续合作、独家合作或股权控制关系。
• 联系人数据可能存在历史记录、重复、失效或主体归属变化，使用前应人工核实。
• 不根据企业名称猜测集团归属、最终受益人、控制关系、资质等级或信用等级。
• 不计算缺少完整分母的数据占比，不把抽样结果写成全量市场结论。
• 不伪造资料未提供的公司、金额、日期、项目、联系人或风险事实。

内部接口参数参考

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

• 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：获取招中标信息采集源网址