shield_lock
JinDaGe
← Back to skills
extension
Category: Data & AnalyticsAPI key required

竞争对手企业画像-比地招标网

输入一家竞争对手公司名称，产出一份面向投标方的竞争对手情报报告，用于投标前的对手研判与策略制定。

personAuthor: u_20ecd0d1hubenterprise
downloadDownload package

竞争对手企业画像-比地招标网

为参与投标的供应商（乙方/销售与投标准备团队），提供一份可快速阅读的单一竞争对手深度画像： 输入一家客户最关心的对手公司名称，自动拼出它的 工商基本面、中标战绩与活跃度、竞争格局（同业主赛道对手）、区域布局、业主/客户结构、 品类专长、资质壁垒与司法/信用风险，并可选纳入**我方（调用方）**做对比，最后给出 「这家对手多强、在哪里赢、擅长什么、在跟谁抢标、被谁锁定、软肋在哪、我方怎么错位打」的研判。

与「业主采购画像」的根本差异——视角从「买家」翻转为「对手」：

  • 业主画像回答「这个客户是谁、怎么花钱、跟谁合作、偏好什么」（用于拜访前客户洞察）；
  • 竞争对手画像回答「这家对手有多强、在哪里赢、擅长什么、被谁锁定、软肋在哪、我方如何错位竞争」（用于针对单一对手的投标准备）。

核心设计：一次聚焦分析「一家」对手公司（像业主画像一次聚焦一个主体，但视角是乙方/对手）； 可选提供我方（调用方）公司名称用于「与我方对比」。若客户只知道目标业主、不确定该分析哪几家对手， 先用 discover 列出该业主的历史中标单位排行，再挑一家传给 analyze --company。

首次调用引导（强制顺序，必读）

任何调用（含 analyze）之前，先跑 status 判断是否首次——零成本、不计费：

python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py status

退出码 0 = 凭据与开通闸口均就绪，可直接进入 analyze；退出码 1 = 尚未就绪，按下列顺序补齐。

前 3 步是硬门槛：不满足就停下来引导用户，不要直接开跑 analyze。第 4、5 步是必问项。

| 步骤 | 做什么 | 不满足时怎么引导 | |---|---|---| | ① 凭据 | 检查环境变量 BIDI_API_TOKEN → 回退 ~/.codex/config.toml | 引导用户去比地招标网开放平台开通「开放接口」并取得 Token（账号未授权时联系比地商务/账号管理员）。用户给到 Token 后协助写入配置。绝不代填、不落盘、不回显、不写日志；真正的"注册开通"只能由用户完成，agent 不能代为注册 | | ② 开通闸口 | 跑 init（探测 → 提交自助开通 → 复探 → 出闸口报告） | 出现 300102001 no permission = 该接口的「自助开通」主能力未对本账号授权，需联系比地后台放开；Token 失效 / 出口 IP 不在白名单 按脚本输出的指引处理后重跑 init | | ③ 对手公司全称 | 确认要画像的那家对手公司的工商全称 | 用户只给简称/俗称时，先向其确认全称再跑。名称不准会产出零命中报告，而页头告警是事后才出现，那时 API 费已花掉。若用户只知道目标业主、不确定对手是谁，先用 discover --owner 拉排行再选 | | ④ 我方公司 | 主动询问：「请问贵司（调用方）的公司名称是什么？」 | 用于「与我方对比」（共享业主 / 品类重叠 / 空白市场 / 直接竞品识别）。用户拒答或答不出不强求，但报告不出「与我方对比」节，策略建议改为纯对手格局视角 | | ⑤ 成本确认 | 说明取数范围与预估费用（约 1–3 元/家）后征得同意 | 用户要控成本 → 建议 --no-deepdive、调小 --search-pages、或 --no-risk 跳过敏感司法接口 |

补充说明：

  • status 读取的运行状态写在 ~/.workbuddy/state/bidding-competitor-profile.json（在 skill 目录之外，不会被打进分发包）；内容仅含 init_at / init_ready / init_total / last_analyze_at / last_target，不含 Token。
  • 无凭据时脚本不再只丢一行报错，而是打印完整的三步配置引导（取得凭据 → 两种配置写法 → init 命令）后退出，等价于自动完成第 ① 步的引导。

报告结构：

核心结论（KPI 卡 + 一句话研判：这家对手强在哪、软肋在哪、我方怎么打）
一、分析对象与口径（对手全称 / 数据来源 / 时间窗 / 品类过滤 / 与我方对比标识）
二、企业基本面（工商 IC-001 / 股东 IC-006 / 高管 IC-004）——规模、性质、决策层、历史沿革
三、中标战绩与活跃度（以其为中标单位的公开标讯）——中标次数 / 累计·平均金额 / 年份跨度 / 近 90 天活跃 / TOP5 大单
四、竞争格局分析（同业主赛道对手）——在同一采购人（业主）处还有哪些中标单位、目标排名第几、跨业主的关键交锋对手是谁
五、区域布局（中标项目所在省份分布）——强势区域与薄弱区域
六、业主 / 客户结构（反复中标的采购人 tenderee）——被锁定的客户关系
七、品类专长（product 词频 + 域名词典）——核心能力与错位空间
八、金额段定位（单项目金额区间）——大单型 vs 走量型
九、资质与合规优势（OP-006 / IC-008 / 信用中国 CC-002，仅展示有效期内项）
十、风险与软肋（JU-001 被执行人 / JU-002 失信 / CC-001 行政处罚 / JU-004 裁判文书）——可攻击面
十一、与我方对比（若提供我方公司名）：共享业主 / 品类重叠 + 我方空白市场 + 直接竞品识别
十二、投标应对策略建议（正面硬刚 / 错位竞争 / 攻击软肋 / 联合体 / 空白市场切入 / 情报跟进）
十三、数据缺口与免责（接口未开通 / 零命中 / 首标段口径 / 名称推测占比 等如实标注）
附录　竞争对手近期中标记录（按公告日期倒序，最多 30 条 —— 日期 / 项目名称（可跳原文）/ 采购人 / 中标金额 / 地区）

章节编号为动态连续编号：任一可选章节（竞争格局 / 区域布局 / 业主结构 / 资质 / 风险 / 与我方对比 等）因数据缺失或未启用而不渲染时，其后的章节序号会自动前移，不会跳号。目录锚点与正文一一对应。 附录不占章节编号，恒置于正文之后，并在目录中给出独立锚点。

报告呈现规范：

页头：KPI 卡（累计中标次数 / 累计披露金额 / 覆盖年份跨度 / 覆盖省份 / 风险信号数）+ 一句话研判
目录：按实际渲染章节动态生成锚点，可页内跳转
二、企业基本面：规模 / 性质（国企/民营/股份制）/ 决策层（股东 IC-006、高管 IC-004）；
    机关类无公开股东高管时合并为一句说明，不铺空表；比地用字面量「-」表示空值，已归一化
三、中标战绩：KPI + 概览卡（次数 / 金额 / 年份跨度 / 近90天活跃）+ TOP5 大单表
四、竞争格局：赛道排名一句话概览（目标在各业主处排第几、赛道共几家）+ 同业主竞标单位表（按业主分块）+
    关键交锋对手表（跨业主重复出现的同台对手）；目标是「这家对手和谁抢、谁抢得最凶」
五、区域布局：省份分布条形图 → 强势区域与薄弱区域
六、业主结构：采购人排行表（≥2 次视为「锁定关系」）+ 业务口吻说明
七、品类专长：product 词频条形图 → 核心能力与错位空间
八、金额段：单项目金额区间分布 → 平均单项目额，判断大单型/走量型
九、资质与合规：有效期内的资质壁垒卡片；过期项隐藏并在页脚计数
十、风险与软肋：按严重度分级——
    失信(JU-002)/行政处罚(CC-001) 拉红（硬软肋，投标时应重点核查资格），
    被执行(执行中)/合同类裁判文书(JU-004) 中风险，均无记录（含 300104001 正常空响应）记为「未发现公开风险记录」属利好
十一、与我方对比：共享业主 / 品类重叠表 + 我方空白市场清单 + 重叠度最高的直接竞品
十二、投标应对策略：编号清单，首条为「无有效战绩时如何破局」，含正面硬刚/错位/攻击软肋/联合体/空白市场/情报跟进
附录：竞争对手近期中标记录清单（紧凑表格，最多 30 条，`--appendix-max` 可调；按公告日期倒序）
    · 列：# / 公告日期 / 项目·公告名称（超链接至比地原文）/ 采购人（业主）/ 中标金额 / 地区
    · 金额缺失时回退为招标预算并显式标注「预算」；无公开记录时输出一句兜底说明，不铺空表
    · 结尾注明展示条数与检出总条数，并声明仅覆盖公开中标公告、不含未中标投标记录
    横幅告警：该对手作为中标单位公开标讯为 0 条时，卡片顶部出琥珀横幅提示「招投标章节缺失/极薄」+ 业务口吻建议（核对全称 / 扩大检索范围）
★ 用词规范（硬约束）：报告正文一律不得出现 CLI 参数/命令或实现术语
    （如 --company / --my-company / --search-pages / analyze / init / check / 接口 / 翻页数 / API / 重跑 等），
    一律改为业务口吻（"可扩大检索范围后重新生成报告""数据源未覆盖"等）；技术操作说明只保留在 SKILL.md 与 CLI help，不进报告。
    例外：接口代码（OP-006 / IC-008 / CC-002 / JU-001 / JU-002 / CC-001 / JU-004 / BID-001 等）作为数据溯源标签，保留在章节小标题与说明中。

适用场景

  • 投标前想摸清：本标段历史上是哪家具体对手在抢、这家对手强在哪、弱点是什么、有没有履约/合规风险。
  • 拿到一个具体对手公司名（如客户说"帮我看看 XX 公司"），需要一份可转发的单主体深度画像 HTML。
  • 需要识别「我方与这家对手正面冲突最激烈之处」以及「对手已占、我方尚未进入的空白业主/品类」。
  • 不确定该分析哪几家对手时，先用 discover 按目标业主拉出历史中标单位排行，再挑最值得研究的一家。

数据流与安全

  • 复用 bidi-tender-search 的同套接口与凭据：环境变量 BIDI_API_TOKEN（Authorization: Bearer <token>）。 脚本优先取环境变量，否则回退到 ~/.codex/config.toml 的 [mcp_servers.bidi-tender-search.env]。禁止输出、落盘或回显 Token。
  • 接口基础地址：https://moose-api.bidizhaobiao.com/。详见 references/api-map.md。
  • 每次 API 调用均计费：公告搜索 0.2 元/次；企业类约 0.05–0.4 元/次；司法/信用类约 0.1 元/次。 分析「一家」对手含：标讯搜索 + 资质深挖（IC-001/IC-006/IC-004/OP-006/IC-008/CC-002 各 1 次）+ 风险探测（JU-001/JU-002/CC-001/JU-004 各 1 次），约 1–3 元量级； 竞争格局分析默认开启：最多 3 条业主赛道 × 每条 --landscape-pages（默认 4）页搜索，约 +1–3 元； 附录「近期中标记录」不新增任何调用（复用已取回的中标记录，仅排版），零成本； 加 --my-company 对比再 +约 0.6 元（我方标讯搜索 + 主体查询）。执行前先向调用方说明取数范围与大致成本； 可用 --search-pages / --no-deepdive / --no-risk / --no-landscape / --landscape-pages 控制成本。
  • 隐私：仅使用公开工商 / 招投标 / 司法 / 信用数据；不采集、不输出任何非公开信息。
  • 字段名在不同企业间可能不一致，脚本已做候选键模糊匹配；个别字段缺失时如实标注「—」，不臆造。

接口申请与配置（安装前置，必读）

本技能依赖比地招标网开放接口，使用前必须完成配置，否则 init / analyze 会因无凭据直接失败。 无凭据时脚本会直接打印完整配置引导后退出（取得凭据 → 两种配置写法 → 下一步命令），不落盘、不回显 Token；先跑 status 可判断当前是否已就绪。

1. 申请开放接口 Token

  • 在比地招标网开放平台申请开通「开放接口」并获取 token（用户自备凭据，脚本不内置）。
  • 若某些接口返回 300102001 company api error: no permission，表示该接口的「自助开通」主能力未对贵司账号授权，需联系比地后台放开后才能使用。

2. 配置 Token（二选一，环境变量优先）

export BIDI_API_TOKEN='你的token'   # 方式 A：环境变量（推荐）
# 方式 B：写入 ~/.codex/config.toml 的 [mcp_servers.bidi-tender-search.env]
#   BIDI_API_TOKEN = "你的token"

3. 首次运行 init 开通接口（自助开通闸口）

平台没有「查询已开通列表」的接口，脚本用探测法判断开通范围，再对未开通的提交自助开通（幂等）。

BIDI_API_TOKEN='<token>' python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py init

流程：凭据预检 → 逐接口探测（已开通 / 已开通(空) / 未开通 / 异常）→ 对未开通的提交自助开通（幂等）→ 复探确认 → 出闸口报告（就绪 N/M）。 check 仅探测、不提交开通，用于诊断。共 11 个接口：BID-001、IC-001、IC-004、IC-006、OP-006、IC-008、CC-002、JU-001、JU-002、CC-001、JU-004。 探测会对每个接口发起一次真实调用，一次自检约 1–2 元。

工作流程

0. 先查运行状态（零成本、不计费）

python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py status

判断"是否首次调用"：凭据是否就位（含来源，不回显内容）、首次开通是否已完成及就绪接口数、最近一次分析时间与对象。 退出码 0 = 可直接 analyze；1 = 按上一节《首次调用引导（强制顺序）》补齐。别跳过——否则容易跑到一半才发现没凭据或接口没开通。

1. 开通接口（仅首次）

BIDI_API_TOKEN='<token>' python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py init

2.（可选）不确定该分析谁？先用 discover 按业主拉中标单位排行

BIDI_API_TOKEN='<token>' python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py discover \
  --owner "某业主/采购单位" --top-n 10 --years 3

打印「业主历史中标单位排行」，把其中最值得研究的一家传给下一步的 --company。

3. 确认对手全称、询问我方公司名并执行分析（单主体）

执行前先确认这两件事，再跑命令：

  1. 要画像的那家对手公司全称（来自客户指定，或上一步 discover 的排行）；
  2. 向用户询问：「请问贵司（调用方）的公司名称是什么？」 该名称用于「与我方对比」（共享业主 / 品类重叠 / 空白市场 / 直接竞品）。用户拒答不强求，报告不出「与我方对比」节。
BIDI_API_TOKEN='<token>' python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py analyze \
  --company "华南建设集团股份有限公司" \
  --my-company "我方智能公司" \
  --years 3 \
  --search-pages 10 \
  --html report.html --json snapshot.json --md report.md

参数说明：

  • --company（必填）：要画像的那一家竞争对手公司名称（如「广东格林律师事务所」）。
  • --my-company（推荐）：我方（调用方）公司名称。用于与我方对比（共享业主 / 品类重叠、空白市场、直接竞品识别）。
  • --category（选填）：人工品类关键词，逗号分隔（如 市政,信息化,运维）；用于过滤该对手中标记录到相关品类，不指定则分析全品类。
  • --years：回顾年限，默认 3。
  • --search-pages：公告搜索翻页数（每页 20 条），默认 15。对手标讯多可调大。
  • --no-deepdive：跳过资质深挖（省约 5 次调用）。
  • --no-risk：跳过敏感司法/信用风险探测（JU-001/JU-002/CC-001/JU-004），不评估软肋。
  • --no-landscape：跳过竞争格局分析（同一采购人处其他中标单位的检索），省约 3 条业主赛道的搜索费；报告不出「竞争格局」节，后续章节序号自动前移。
  • --landscape-pages：竞争格局每条业主赛道的搜索翻页数，默认 4（共最多 3 条业主赛道）。调大可提高同台对手覆盖率，但费用同比例上升。
  • --appendix-max：附录「近期中标记录」最多展示条数，默认 30；传 0 表示全部列出。零 API 成本（仅复用已取回的数据），只影响报告排版。
  • --html / --json / --md：分别落盘 HTML 报告 / JSON 快照 / Markdown 简版。缺省 --html 时，控制台打印 Markdown 摘要。

4. 仅用快照重新渲染（可选，省 API 费）

python3 ~/.workbuddy/skills/bidding-competitor-profile/scripts/competitor_profile.py render \
  --input snapshot.json --html report.html

附录条数可在重渲染时覆盖（零成本）： render --input snapshot.json --html report.html --appendix-max 0（0 = 全部列出）。

5. 解读报告并交付

  • 核心结论 KPI：累计中标次数、累计披露金额、覆盖年份跨度、覆盖省份、风险信号数。
  • 企业基本面（IC-001/IC-006/IC-004）：规模、性质（国企/民营/股份制）、决策层（股东、高管）、成立年限。
  • 中标战绩：次数 / 累计·平均金额 / 年份跨度 / 近 90 天活跃 / TOP5 大单；零命中时出琥珀横幅提示核对全称。
  • 竞争格局（同业主赛道对手）：该对手在其核心采购人（业主）处排第几、该业主处共几家中标单位、主要同台对手是谁、跨业主的关键交锋对手是谁——即「这家对手在跟谁抢标」。
  • 区域布局：中标项目省份分布，强区与弱区。
  • 业主/客户结构：反复中标的采购人（≥2 次视为锁定关系），即对手的基本盘。
  • 品类专长：product 词频，核心能力与错位空间。
  • 金额段定位：单项目金额区间，判断对手是大单型还是走量型。
  • 资质与合规优势（OP-006/IC-008/CC-002）：有效期内的资质壁垒，过期项已隐藏。
  • 风险与软肋（JU-001/JU-002/CC-001/JU-004）：按严重度分级，失信/处罚拉红，均无记录记为「未发现公开风险记录」属利好。
  • 与我方对比（若提供我方公司名）：共享业主、品类重叠、空白市场清单、重叠度最高的直接竞品。
  • 投标应对策略：基于上述自动生成，以编号清单呈现，可直接打印逐项打勾。
  • 附录 · 近期中标记录：该对手作为中标单位的逐条明细（最多 30 条，按公告日期倒序），含日期 / 项目名称（点击跳转比地原文）/ 采购人 / 中标金额 / 地区；可直接作为拜访、方案引用与项目复盘的证据清单。

关键分析方法

  • 中标单位聚合（竞争视角）：以竞争对手公司名为关键词（range=40/pattern=10）搜索公告，仅保留 winTenderer（中标单位）命中该对手的记录，聚合其历史中标战绩（次数 / 累计·平均金额 / 年份跨度 / 近 90 天活跃 / TOP5 大单）。winTenderer 仅取首标段中标人，多包组项目其他包中标人可能未计入。
  • 竞争格局（同业主赛道对手）：仍以「这一家」为中心，把镜头从对手自身移到「它和谁在同一池子里抢标」。取该对手**前 3 个核心业主（采购人）**作为「赛道」，用业主名称做 range=40/pattern=10 搜索，统计该业主处各中标单位次数并降序排名，得出：①目标在各业主处的名次与赛道规模（样本内共几家有公开中标）；②该业主处的其他主力中标单位（即真实同台竞争对手）；③跨业主重复出现的「关键交锋对手」。
    • 为什么用业主而非品类关键词：业主名是精确实体，检索结果即「同一买家处的所有中标人」，是真正的同池竞争；品类关键词（工程/房建/云）过于宽泛，会命中全国跨行业无关项目，实测产出大量单次无关单位（噪声），故不采用；
    • 业主不可解析（无 tenderee）时竞争格局节自动省略，其后的章节序号自动前移；
    • 这是单主体视角的竞争格局，不是多公司并列矩阵（多公司矩阵是被明确否定的形态）。
  • 业主/客户结构：从命中记录的 tenderee（招标单位）聚合，识别对手被锁定的客户关系（反复中标的采购人）。
  • 金额口径：winBidPrice（中标价）优先，biddingBudget（预算）兜底；统一换算为「元」后按万元口径分桶。累计金额口径 = 中标价优先、缺省取预算，避免"中标次数多但金额小"被误排在前（金额榜与次数榜并列呈现）。
  • 品类词频：从公告 product 字段拆分统计，呈现高频品类；命中内置「有项目指向性」域名词典，刻意排除 服务/销售/代理/技术 等过于通用的词，避免「什么都匹配」。
  • 资质与合规优势：回查 IC-001（主体）、OP-006（资质证书）、IC-008 + CC-002（行政许可），并列展示有效期内的证书为「资质壁垒」卡片；过期项直接隐藏并在页脚计数提示「已隐藏 N 条过期项」，无有效期限视为长期有效保留。
  • 风险与软肋（竞品情报核心增量）：并行调用 JU-001 / JU-002 / CC-001 / JU-004，累计记录数与金额，按严重度分级：
    • 高：失信被执行人（JU-002）/ 信用中国行政处罚（CC-001）→ 直接拉红，作为「硬软肋」，投标时应重点核查其是否满足招标文件资格条件；
    • 中：被执行人（JU-001，且 status=执行中、金额较大）/ 裁判文书（JU-004，且案由偏向合同/买卖/工程纠纷）；
    • 低/无：以上均无记录（HTTP 404 + 300104001 正常空响应）→ 记为「未发现公开风险记录」，属利好，不计入风险评分。
  • 区域/品类解析：中标项目省份从记录 province/city 解析；省份解析采用「省级全称 → 直辖市/特区 → 地级市+市字 → 地级市开头 → 省简称开头」从严顺序，内置全国地级市→省份映射，不做省级简称全文子串匹配（否则「天河北路→河北」假阳性）。
  • 与我方对比：以我方公司名为关键词同样聚合中标战绩，与对手比对共享业主（交集）、共享品类（交集）、对手独有业主（我方空白市场线索）、重叠度最高的直接竞品。

已知坑（务必注意）

  • init 与 check 语义不同，勿混用：init = 探测 + 提交自助开通 + 复探 + 写状态（首次必跑）；check = 仅探测（诊断用，不提交开通、不写状态）。
  • 比地接口用字面量「-」表示空值：机关/事业单位的 IC-001 返回 legalPerson='-'、capital='-' 等，'-' 是 truthy，若不归一化会导致「空表判断」失效。脚本已用 is_blank() 统一处理（含 -/—/无/null/未知），新增字段展示必须走 first_of()。
  • 搜索翻页不足会导致时间覆盖失真：搜索结果按发布时间倒序返回，--search-pages 偏小时「近 N 年」实际只覆盖最近 1 年左右。脚本已自动检测并在报告中给橙色告警（业务口吻提示扩大检索范围，不复述 CLI 参数）。
  • --company 是单家对手，不要传逗号列表：若需分析多家，请分别多次调用 analyze；discover 仅用于「找对手」不直接产出画像。
  • 同一项目存在多条公告：采购/成交/合同公告会重复出现，单笔金额 TOP5 已按标题核心词归组去重，组内优先保留已披露中标单位的成交记录。
  • 累计金额口径 = 中标价优先、缺省取预算：只统计中标价会严重低估（大量项目只有预算），金额榜与次数榜并列呈现。
  • HTTP 404 ≠ 接口异常：body 为 code=300104001 且含「查询数据不存在」时是正常空响应（该公司无该项记录，属利好），不计缺口；只有非此语义的 404 才算真异常。
  • 响应双重嵌套：open/v1 列表接口业务数据在 data.data；搜索接口列表在 data.data。
  • 中标单位仅取首标段：winTenderer 为第一标段中标人，多包组项目其他包中标人可能未计入；已在报告中说明，不臆造。
  • 品类过滤是关键词粗筛：基于标题/product 文本匹配，存在漏召与误召，结论以「公开可验证」为界，不宣称全量。
  • BID-001 搜索必须用 range=40（标题+内容）+ pattern=10（精准）：默认的 range=10（仅标题）搜不到公司名（公司名只在正文的中标单位字段）；pattern=20/30（模糊/智能）会把公司名拆词后乱匹配（实测给「广州方集信息科技有限公司」返回一堆无关公告、winTenderer 命中 0）。二者合起来才稳定命中。
  • 省份解析禁止用省级简称全文子串匹配：会出「天河北路→河北」这类假阳性；必须按「省级全称/地级市+市/城市名开头」从严匹配。
  • IC-008 与 CC-002 字段名不同：IC-008 用 allowContent/allowStartdate/allowEnddate/allowAuthority/isHistory，忽略 isHistory=1 的历史记录；按 licenseName/validStart 解析 IC-008 会得到一排空「—」。
  • 不做「采购地区分布」「公告类型分布」「年度趋势」等业主画像式分析：竞争对手情报聚焦「这家对手强在哪/擅长什么/软肋/怎么错位」，区域分析只看对手的中标项目省份布局（强区 vs 弱区），不分析业主本身。
  • 竞争格局是「单主体视角」，不是多公司矩阵：报告只画像一家对手，竞争格局节是为这家对手回答「它的竞争圈层是谁」。若需了解多家对手，分别多次 analyze --company；不要退回多公司并列矩阵（这是曾被明确否定的形态）。
  • 竞争格局排名为「公开中标样本」近似：业主赛道内各家中标次数受搜索翻页数限制（--landscape-pages，默认 4 页 ≈ 80 条），热门业主（如数十家单位中标）可能未被完全覆盖，导致目标偶发「样本内未入榜」；报告已用「样本内第 N 名 / 样本内未入榜」措辞如实标注，非全量精确排名。
  • 附录「近期中标记录」的数据上限来自已有取数，不是额外检索：附录只是把本次已取回的 wins 按公告日期倒序排版，条数上限为 --appendix-max（默认 30）。若检出总条数多于展示条数，报告会注明「共检出 N 条」——想看到更多明细应调大 --search-pages 重跑，而非只调 --appendix-max。
  • 附录链接格式：https://www.bidizhaobiao.com/info-<docId>.html，仅在 docId 为纯数字时生成超链接，否则降级为纯文本，避免产出坏链。
  • appendix_max=0 语义是「全部列出」：取值时不可用 x or 30 兜底（0 会被吞掉变成 30）；渲染层与快照层均已显式判空（None → 30）。
  • 竞争格局用业主而非品类：曾尝试「同品类赛道」，但品类关键词（工程/房建/云）过于宽泛、会命中全国跨行业无关项目，实测产出一堆单次无关单位（噪声），故改为以业主（采购人）为赛道——业主名精确，检索结果就是真正的同池对手。

数据缺口（诚实标注）

以下情况在报告「数据缺口与免责」中如实列出，不臆造结论：接口未开通 / 未接通、搜索零命中、首标段口径局限、资质与许可未公开、名称推测占比。

局限与免责

  • 画像依赖企业公开工商 / 招投标 / 司法 / 信用数据，无身份证号 / 统一人物 ID，人员与供应商比对为辅助信号。
  • 报告为投标前初步竞争情报辅助材料，不构成尽职调查、资信结论或法律意见；是否投标 / 定标 / 合作以招标文件、实地考察与官方渠道为准。涉及对手的负面信息（被执行/失信/处罚/诉讼）仅为公开记录转述，请勿用于诽谤或不当竞争，使用前请自行评估合规边界。
  • 页头/页脚 logo 为比地招标网商标，公开发布前需替换为自有图标或取得授权。

品牌 logo

  • 报告页头内嵌比地招标网 logo（assets/logo-bidizhaobiao.png，以 base64 内嵌为单文件 HTML，可离线打开与转发）； 文件缺失时自动回退内置 SVG 占位 logo。替换 logo 直接覆盖该 PNG 即可。