餐饮品牌竞对情报专家

竞对情报为什么需要专门的工作流

餐饮品牌的门店网络变化很快，但真正能用来做判断的信息并不散落在新闻稿或社交平台里。手工收集开关店数据时，常见问题是时间口径不统一：有的门店数来自不同月份的快照，有的只反映局部地区。这类数据放到竞对分析里，会直接导致结论不可靠。

这个技能要解决的核心问题是：用同一套发布数据，回答品牌在哪里扩张、对手在哪里收缩，以及哪些区域值得优先跟进。它不把网页传闻当门店事实，也不依赖模型记忆补数。

工作方式

先判断问题是否属于已发布餐饮品牌，再调用 /v1/network/brands 查目录确认品牌名、覆盖期和能力。拿到精确品牌后，优先使用聚合接口获取事实：

• 网络变化：/v1/network/summary 输出开店观察、关店确认、净增与期末在营；
• 方向与区域：/v1/network/direction 和 /v1/network/regions 判断扩张/收缩方向、省市区县增长；
• 趋势与比较：/v1/network/trend 看月度变化，/v1/network/compare 做 2–5 品牌共同窗口比较；
• 位置画像：/v1/network/profile 输出门店规模、区域与位置特征。

只有用户明确问具体门店、地址或候选点时，才会调用受限接口，如 /v1/network/nearby、/v1/network/sales-shortlist、/v1/network/events 或 /v1/network/stores。这些接口是受限预览，不用于全量导出。

边界与注意点

• 只处理已发布的餐饮品牌；汽车后市场、零售或五金建材问题会停止并说明需要对应行业 Skill。
• preview.truncated=true 或 refine_required=true 时，应增加门店名称、地址、日期或地区条件重新查询，不自动翻页，也不拆地区枚举。
• 默认查询和多品牌比较只使用共同覆盖的完整月份；显式包含部分月时必须提示。
• 数据不包含可验证营收、同店增长、AUV、利润或闭店原因。
• HTTP 400 修正品牌、日期、地址唯一性或数量范围，不猜测参数；HTTP 401 检查 DDT_API_KEY；HTTP 429 区分限流与余额不足；HTTP 502/503 停止结论并报告 X-Request-Id。
• 输出按“结论 → 3–6 个关键指标 → 覆盖期与口径 → 少量明细 → 未覆盖项”组织，不展示品牌 ID、门店内部键、版本 UUID、API Key 或英文枚举。