Competitor Watch

核心用法

Competitor Watch 是一套自动化竞品情报系统，通过脚本化工作流实现 24/7 监控。用户配置竞争对手分级（fierce/important/watching/adjacent），系统自动按计划抓取网页、存储快照、智能比对变化、生成可读的差异摘要。

关键流程：
1. 初始化配置（setup.sh）→ 2. 添加竞争对手（add-competitor.sh --tier=fierce）→ 3. 设置定时任务（cron 或 heartbeat 每30-60分钟执行 check.sh）→ 4. 接收智能告警（report.sh 生成结构化摘要）

智能差异化：系统内置噪声过滤（时间戳、session ID、广告位、社交计数），聚焦真实信号——定价变更、新功能区块、博客文章、导航结构调整。变更按影响分级（minor/medium/major/critical），结合分级策略决定是否告警。

显著优点

• 分级监控成本可控：直接竞品每30分钟深度扫描， adjacent 市场玩家每周轻量跟踪，避免资源浪费
• 智能降噪：diff 算法过滤动态内容，只报告实质性变化，解决传统网页监控"狼来了"问题
• 可执行摘要：告警不止于"页面变了"，而是结构化提取"新增企业版$999/月，Pro版涨价61%"等关键情报
• 本地化数据存储：快照、变更日志、告警历史均存于 ~/.config/ 目录，无云服务商锁定，可长期回溯
• 多场景覆盖：产品团队追踪功能发布、销售团队监控定价战、创始人把握战略动向

潜在局限

• 技术门槛：需熟悉 shell 脚本、cron 配置、JSON 编辑，非技术用户上手成本较高
• 静态网页限制：对重度 JS 渲染的 SPA 需依赖 browser 模式（文档提及但未详述实现），可能有稳定性差异
• 社交监控浅层：当前仅支持检查公开社交页面，未实现 API 级帖子流监听
• 反爬风险：高频监控可能触发目标站点的 rate limit 或 IP 封禁，需自行配置代理/延迟策略
• 语义理解有限：变更检测基于文本 diff 和关键词匹配，无 LLM 深度分析（列为未来功能）

适合人群

• 技术型创始人、产品负责人，需要自动化替代手动竞品 bookmark 检查
• 中小 SaaS 公司，有明确 3-5 家直接竞争对手，希望缩短情报滞后时间
• 销售/市场团队，希望第一时间获知对手定价调整、案例上线、定位变化

常规风险

• 合规边界：工具声明仅监控公开内容、遵守 robots.txt，但用户可能误用于付费墙/登录后内容爬取，存在法律风险
• 数据囤积：90天快照保留策略可能累积大量冗余数据，需定期清理
• 告警疲劳：即使内置降噪，fierce 级高频率监控仍可能产生大量 minor 变更，需精细调参阈值和冷却期
• 依赖单点：基于本地文件存储，无内置备份/同步机制，机器故障可能导致配置与历史数据丢失

核心用法

Competitor Watch 是一款面向创始人和产品团队的自动化竞品情报工具，通过 CLI 脚本实现 24/7 监控。用户首先运行 scripts/setup.sh 初始化配置，然后通过 scripts/add-competitor.sh 添加竞品并指定监控层级（fierce/important/watching/adjacent）。系统按预设频率抓取目标 URL，存储快照，使用智能 diff 算法过滤噪声（如时间戳、广告），并生成结构化变更报告。

分层监控策略是该工具的核心设计：

• Fierce（直接竞品）：30分钟检测周期，深度监控定价、功能、文档、博客、社交
• Important（重要竞品）：2小时周期，关注定价和功能更新
• Watching（潜在威胁）：每日检测，跟踪首页和博客重大变化
• Adjacent（边缘市场）：每周检测，仅关注重大转型或发布

智能变更评分系统将变更分为 Minor/Medium/Major/Critical 四级，结合关键词匹配（如"launching""announcing"）和文本差异比例，确保仅在有意义的变更时触发告警。

显著优点

1. 分层成本优化：避免对所有竞品同等投入，将有限监控资源集中在真正威胁上
2. 智能噪声过滤：自动识别并排除 session ID、缓存标记、动态广告等非内容变更
3. 结构化输出：告警信息包含"What changed"和"Why it matters"，而非原始 HTML 堆
4. 隐私合规设计：仅访问公开网页，尊重 robots.txt，配置 2 秒 rate limit，符合 GDPR/CCPA 数据最小化原则
5. 极低依赖：仅依赖 jq，无 npm/pip 生态风险，部署轻量化

潜在局限

1. 静态内容限制：依赖 web_fetch，对重度 JavaScript 渲染的现代 SPA 支持有限（文档标注未来考虑浏览器自动化）
2. 无自动清理：配置了 retention_days 但未实现过期快照自动删除，长期运行可能导致存储膨胀
3. URL 验证薄弱：add-competitor.sh 未严格校验 URL scheme，存在 file:// 等危险协议注入风险
4. 社交监控初级：当前仅支持 Twitter/LinkedIn 账号页面检查，非真正的社交监听 API 集成
5. 单点执行：基于 cron 的调度模型，无分布式或高可用设计，不适合大规模企业级部署

适合人群

• 早期至成长期创业团队：3-10 个核心竞品，需要自动化情报但无预算购买 Enterprise CI 平台
• 独立产品经理：负责竞品分析，希望从手工书签检查中解放
• 销售赋能团队：需要实时定价和竞品动态更新 battlecard
• 技术型创始人：偏好 CLI 工具和工作流集成，愿意自行托管和维护

常规风险

• 误配置风险：若将内部系统 URL 误加入监控列表，可能导致敏感信息外泄或内网扫描
• 法律边界模糊：虽然声明遵守 robots.txt 和 rate limit，但大规模商业监控在某些司法管辖区可能触发 CFAA 或数据保护争议
• 过度反应风险：实时告警机制可能导致团队对竞品动态过度反应，干扰自身产品节奏
• 依赖单一维护者：audsmith28 个人账号发布，无明确组织背书，长期维护存在不确定性