呱呱 后端与接口
用 Firecrawl 定期监控竞品定价、功能与更新日志
需要对竞争对手的定价、功能、更新日志和产品变化做周期性情报收集时使用。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 38/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15
适用场景
用 Firecrawl 定期监控竞品定价特定
解决思路
- 从上下文推断竞品列表、关注重点、监控频率和输出格式；如果竞品已明确就直接开始，不要多问。
- 仅在信息不足时最多提 1-3 个简短问题，例如竞品清单、关注领域、是否需要登录后的页面或账号。
- 对每个竞品使用 Firecrawl 的 scrape 或 browser 抓取：定价页、年付/月付切换、展开后的功能对比表。
- 抓取功能页和产品页。
- 抓取 changelog、博客、release notes、文档更新。
- 仅在用户有合法访问权限时抓取需要登录的 dashboard。
- 如条件允许，使用 sub-agents 或等价的并行任务执行器；按每个竞品一个研究员或每个关注领域一个研究员来拆分。
- 要求每个研究员返回定价档位、功能、近期变化、来源 URL 和置信度说明。
- 按固定 markdown 结构产出最终交付物：Alerts（值得注意的定价/功能/定位变化）、Per-Competitor Breakdown（定价档位、功能清单、近期变化）、Cross-Competitor Comparison（定价表、功能矩阵、关键差异点）、Suggested Follow-Ups（下一步监控什么）、Sources（访问过的 URL）、Rerun Inputs（workflow、competitors、focus、cadence）。
- 当需要结构化输出时，JSON 中包含 generatedAt、competitors、pricing、recentChanges、features、sources 字段。
- 质量要求：尽量提取真实的套餐名称、限制和日期；对 contact-sales 或受限信息做标注而不是猜测；保留来源 URL 以便未来 diff 对比。
适用边界 · 注意事项
- 需要 Firecrawl API key（FIRECRAWL_API_KEY）才能使用。
- 这是针对长期监控竞品的流程，不适用于一次性的广泛竞品分析。
- 抓取需要登录的 dashboard 时必须确保用户有合法访问权限。