> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/12-chapter.md).

# 第12章 番外·竞品监控情报系统:对手改价的当日感知

**本章导读**:产品竞争中,信息差是核心优势之一。多数团队对竞品动态的感知是"被动"的——通过销售反馈、客户投诉、媒体新闻等渠道"事后得知"。本章复盘一个真实项目:为某运营团队搭建"竞品监控情报系统",AI 自动监控 5 个核心竞品的公开页面(定价页、更新日志、招聘页、舆情源),变化即时通知团队,让团队在对手改价当天即做出应对。本章的方法论是"三层管道(采集—理解—投递) + 三级分类(噪声/次要/重大)"——把监控系统的工程化降到最低,核心价值集中在"如何从大量变化中识别真正重要的"。

**本章关键词**:竞品监控、三层管道、三级分类、情报系统

## 12.1 项目的真实背景

### 12.1.1 一个"事后才知道"的案例

**现场还原**:2025 年 10 月的某一周,某 SaaS 运营团队的复盘会上,销售主管翻开笔记本,语气很平:"这周丢了两张单,都是因为价格被竞品压死了。"项目负责人(以下简称"负责人")接过这两张订单的谈判记录,翻到价格环节——客户原话几乎一致:"对方已经降到 17 美元/月了,你们还是 29 美元/月。"负责人把"17 美元"和"29 美元"两个数字记在白板上,问销售主管:"对方这个价格,我们知道吗?"销售主管沉默了几秒,答:"不知道。我们之前是按行业平均价 27 美元报的,没料到对方直接砍到 17 美元。"

会后,运营团队把时间线往前倒推——竞品在 9 月 28 日的版本更新日志里,把主力套餐从"30 天免费试用"改成了"永久免费试用,基础版 5 美元/月,专业版 17 美元/月"。9 月 28 日到 10 月中旬,整整三周,这支运营团队对此一无所知。这三周里,他们的销售还在按原价谈判,产品还在按原路线图排期,客服还在按原话术解释价格差异。

**现场细节**:复盘会上,运营负责人问了一个具体问题——"这三周里,我们有没有任何一个环节,本来应该发现这件事?"会议室里坐了 7 个人,分别从销售、产品、客服、运营、市场、财务、技术视角回答。最后汇总下来,有 3 个节点本应发现但都没发现:① 销售在 10 月 6 日和客户第一次沟通时,客户提过"对方说他们最近有促销",但销售没当回事,没让客户发具体截图;② 产品在 10 月 9 日做例行竞品调研时,只看了一份行业分析报告(这份报告是 8 月出的,完全没提到这次降价),没直接看竞品官网;③ 客服在 10 月 11 日接到 3 个客户问"你们能不能也降价"时,把工单归到了"客户讨价还价"类,没上升到"竞品动态"层面。三个节点,三次机会,全部错过。

"对手改价我不知道"——这是产品竞争中典型的"信息劣势"。其根源是:

* **销售时间被客户拜访占满**,无人有余力关注竞品
* **产品时间被文档占满**,无人专职做竞品分析
* **价格页上个别数字的改动**,间隔三天的肉眼比对难以识别

**教训**:这次复盘之后,运营团队对"信息劣势"的认知从"个人疏忽"升级为"系统缺失"。个人疏忽可以通过提醒改善,系统缺失只能通过系统解决——这正是后面"竞品监控情报系统"立项的真实动机。**复盘的真正价值不是找到该怪谁,而是找到问题在哪一层——在个人层,加强培训;在流程层,补审批节点;在系统层,做工具**。这次复盘明确指向系统层。

### 12.1.2 项目的目标

**现场还原**:复盘会一周后,运营负责人把负责人请到飞书会议室,开了一个 40 分钟的需求对齐会。会议室里除了运营负责人,还有销售主管、产品经理、客服主管。运营负责人一开始讲得很宏观:"我们要一套竞品监控。"负责人打断他,问了一个具体问题:"监控到什么程度算够?"运营负责人愣了一下,答:"对手上午改价,销售群当天上午收到告警。"

负责人当场把这个目标拆成四件可被验证的事:

* **监控范围**:5 个核心竞品,每家 15 个公开页面
* **监控频率**:每天一次
* **响应时效**:对手修改当天,团队收到通知
* **运营成本**:每月不超过 17 美元

这四件事是负责人和销售主管、产品经理、客服主管逐条对齐下来的——5 个竞品是销售主管列的(过去 6 个月里被提及频率最高的 5 个品牌);15 个页面是产品和运营共同定的(定价页、产品更新页、博客、招聘页、案例页等);每天一次是产品和运营达成的折中(每周一次太慢,每小时一次太贵);17 美元/月是负责人估算后定的预算上限(高于这个数,运营不会批——"如果工具比招一个人还贵,不如招人")。

**现场细节**:对齐会上,销售主管提了一个具体的反例——"上个月对手把免费额度从 100 提到了 500,但我们不知道,直到客户来问'你们什么时候也提'才反应过来。这种'免费额度'的变化也要监控。"负责人当场把"免费额度"加进了监控清单。这就是把抽象的"竞品动态"翻译成具体清单的过程——**每一次范围调整,都应该能追溯到一个具体的、被错过的事件**。如果新增的监控项说不出"过去哪个具体事件被错过",说明这条监控项是想象出来的,不是真需求。

**教训**:目标定量化是项目能否成功的第一道分水岭。"监控竞品"和"对手改价当天感知"是两个完全不同的项目——前者是开放命题,后者是闭合命题。闭合命题可验收、可交付、可控制预算;开放命题在第三周就会陷入"为什么这个没监控到""那个也算竞品动态吗"的无限扯皮。**任何以"建立一套XX"为开头的项目,都应立即问"做到什么程度算够",答不出就回到对齐环节**。

### 12.1.3 项目的边界

**现场还原**:边界讨论在第二次会议里展开,持续了 25 分钟。运营负责人一开始提了一个比较宽的边界:"竞品有什么动态,我们就监控什么。"负责人当场追问了一句:"竞品的客户数据、营收数据、用户活跃数据,这些算不算动态?"运营负责人答:"当然算。"负责人说:"这些数据要么在竞品的私有数据库里(我们拿不到),要么在第三方平台(要付费买),要么需要登录才能看(我们不能登录)。我们的监控系统要建多大,才能覆盖这些?"

运营负责人沉默了一会,问:"那你能监控到什么?"负责人给出明确边界——

> "监控系统的边界是'公开页面':不需要登录、不需要付费墙、不需要破解验证码的页面。具体包括竞品的官网首页、定价页、产品更新日志页、博客、招聘页、公开的客户案例页。监控频率每天一次,单域名每秒不超过 1 次。所有抓取动作保留 90 天日志。这条边界既是工程伦理,也是项目成本可控的前提——越界监控的维护成本是公开监控的 10 倍以上。"

运营负责人看完这段话,问:"那竞品在我们不知道的内部系统里改了什么,我们就完全感知不到了?"负责人答:"对。但公开页面的变化已经覆盖了 80% 的情报价值——价格、功能上下线、招聘规模、对外宣传,这些都在公开页面上。剩下 20% 是私有数据,要么花钱买,要么放弃。"

**现场细节**:边界定下来后,运营负责人又追问了一个边界外的问题——"如果我们就是想知道竞品的客户数,有什么办法?"负责人答:"第三方平台 SimilarWeb、App Annie、Sensor Tower 有公开估算的数据,虽然不准但能用。这些是'情报补充',不是'监控系统'的一部分。"运营负责人点头——他理解了"边界"不是限制,而是分工:**监控系统做它擅长的(公开页面的当日感知),其他数据用其他工具补**。把每件事交给最合适的工具,而不是让一个工具做所有事。

**教训**:边界讨论是项目里最被低估的环节,却决定了项目 80% 的成败。多数失败的监控系统不是因为"采集不到",而是因为"边界不清"——团队一开始监控公开页,后来发现有些信息在私有页,就开始想办法登录、绕验证码,最后触发竞品的反爬,整个项目停摆。**边界不是越宽越好,而是越清楚越好**。清楚的边界让所有参与者都知道"什么做、什么不做、做了会怎样",比模糊的"尽量多做"安全 10 倍。

**现场还原(续)**:边界定下来后,负责人当场在飞书群里建了一个新的群——"竞品监控-边界文档",把上面的边界条款写成 6 条置顶消息,@ 了运营负责人、销售主管、产品经理、客服主管 4 个人,要求每人 24 小时内回"确认"。第二天,4 个人的确认全部到位(其中销售主管在原话下补了一句"同意,但如果以后要扩边界,先开会再改")。

**现场细节(续)**:边界文档 24 小时内全员确认,这件事看似走过场,实际意义重大——它把"边界"从负责人的口头说明,变成了团队共同签字的合同。**口头边界随时可以破,签字的边界要破得开一次会**。在后续 30 天的运行中,销售主管曾两次想加新监控项(一次是"监控竞品的 App Store 评分变化",一次是"监控竞品的微博官号"),负责人把边界文档翻出来,问"这条属于哪一条",发现都不是"公开页面"的范畴。最后两条都被归到了"其他工具补"——App Store 评分用 App Annie,微博官号用舆情监控工具。边界文档在此后 30 天里,挡住了 3 次"模糊地带的扩张请求"。

![三层管道架构](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-8e991d80c079866d960f7e8fd33b0f3369081add%2Fsec12_pipeline.svg?alt=media)

![30 → 5 → 4 漏斗](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-9eaad53809015e0b2e102640d770032d996b2791%2Fsec12_funnel.svg?alt=media)

## 12.2 三层管道:采集—理解—投递

### 12.2.1 管道架构

**现场还原**:架构设计那天,负责人、运营负责人、销售主管在会议室里吵了 40 分钟。运营负责人一开始的设想是"一个 AI 看完 75 个页面,直接发飞书群",销售主管立刻反对——"那 AI 一周给你发 75 条消息,我会直接屏蔽"。负责人提了一个折中方案:"AI 不直接发,中间加一层'分级'——重要的发,不重要的不发。"销售主管问:"什么叫重要?"负责人答:"价格变了,重要;页脚年份变了,不重要。"运营负责人又问:"谁来分?AI 会不会分错?"

这场 40 分钟的讨论最终沉淀为三层管道的架构:采集层把页面抓下来,理解层判断"是否重要",投递层把重要的发出去。每一层只和下一层交换文本,不交换内部实现——采集层不知道 AI 在理解层怎么判断,理解层不知道投递层往哪里发。这种解耦的好处:任何一层出错或需要升级,都不影响其他两层。

**现场细节**:管道架构的"层间只传文本"这条约束,是负责人在 5 分钟内想到的,理由也很具体——"我做过 3 个失败的项目,失败原因都是'耦合太紧'。第一层抓取的格式变了,第二层就要改;第二层改了,第三层就崩。这次不能再这样。"负责人当场在白板上画了三个框,每个框下面写"输入"和"输出":

* **采集层**:输入是 5 个域名 × 15 个 URL;输出是 75 份 Markdown 文件
* **理解层**:输入是 75 份 Markdown 文件的新旧差异;输出是 75 条 JSON 分类结果
* **投递层**:输入是 75 条 JSON;输出是飞书群消息(MAJOR 卡片 + MINOR 摘要)

**教训**:三层管道看似很工程化,实际是"为了少返工"的产物。如果一层做所有事,某个环节出问题时,要排查整个系统;三层分开后,出问题时定位到具体一层即可,排查成本下降 80%。**架构的真正价值不是"做对的能力",而是"出错时能修的能力"**。一个永远不出错的系统不存在;一个出错能快速修好的系统,才值得长期运行。

### 12.2.2 采集层

**现场还原**:采集工具的选型,负责人前后试了 3 个方案。第一个是自建爬虫(用 Python + requests + BeautifulSoup),写了两天能跑,但遇到一个竞品用了 React + 客户端渲染时,抓回来的 HTML 是空的。第二个方案是 Puppeteer(Headless Chrome),能解决客户端渲染,但内存占用大,一台 1 核 1G 的小服务器跑不动 75 个页面。第三个方案是 Firecrawl,2025 年下半年某次架构升级后,Firecrawl 已经能处理大部分客户端渲染,价格也合理。

选型那天,负责人和销售主管开了 20 分钟的会议,核心就一个数字——"每月多少钱"。Firecrawl 的入门档 16 美元/月,刚好覆盖 2,250 次抓取(75 页 × 30 天)。销售主管当场拍板:"就这个。"

**现场细节**:选 Firecrawl 的决定看似简单,实际是 3 个约束的交集——① 必须能处理客户端渲染的页面(竞品 C 的定价页就是 SPA,普通抓取拿不到内容);② 单月成本不能超过 17 美元(预算上限);③ 不需要专职运维(团队里没人会维护爬虫集群)。这三条同时满足的方案,在 2025 年下半年只有 Firecrawl 一个。如果只满足 1—2 条,还有其他选择;三条全满足,选择面就很窄。**好的技术选型,不是"找最优",而是"找交集"——把多个约束摆出来,交集里的方案通常就是答案**。

**教训**:采集层的稳定性,往往被高估,被低估的是"维护成本"。负责人一开始想"自建爬虫肯定更可控",但实际跑了 3 周后发现,自建爬虫要处理:竞品改版导致 HTML 结构变化(每月至少 1—2 次)、反爬机制升级(每季度 1 次)、服务器内存溢出(每周随机 1—2 次)。每次维护都要 1—2 天。换成 Firecrawl 后,这些维护成本由 Firecrawl 团队承担,运营团队只关心"今天抓到了没有"。**"自建还是用现成"的判断标准,不是"哪个更技术",而是"哪个更省维护"——维护成本是隐藏的,但累计下来比开发成本高 3—5 倍**。

### 12.2.3 理解层

**现场还原**:理解层的分级规则,是负责人在一次"告警事故"后建立的。第一版规则只分"重要/不重要"两级,AI 误判率约 20%——把"竞争对手首页标题从'XX 平台'改成'XX 智能平台'"误判为重要(实际只是加了"智能"两个字,没改实质内容);把"竞品 A 把价格从 30 美元/月改成 17 美元/月"误判为不重要(AI 觉得"只是数字调整")。两个方向都错,运营团队被骚扰了 2 周。

第二周复盘会上,销售主管提了一个具体问题——"你们说的'重要',到底指什么?"负责人当场把"重要"拆成三个具体场景:① 价格、折扣、免费额度变了(销售需要马上知道);② 功能上下线了(产品需要知道);③ 服务条款改了(客服需要知道)。其他都不重要。

**现场细节**:负责人在白板上画了一张表,横轴是"重要程度",纵轴是"通知方式":

* **噪声(NOISE)**:页脚年份、轮播图换序、"猜你喜欢"推荐位刷新、"已有 X 人购买"等动态元素——仅记录,不通知
* **次要(MINOR)**:文案润色、客户案例更换、博客更新等——并入每日一条的早间摘要
* **重大(MAJOR)**:价格变动、折扣调整、功能上下线、服务条款修改、免费额度变化——即时推送 + @ 相关人员

这张表是规则的全部内容,负责人把它写进了 prompt,AI 按规则判断。规则的关键是"明确"——每个级别都有清晰的判断标准,AI 不会因为"模糊地带"而误判。例如"页脚年份"明确归 NOISE,因为它"不涉及产品策略";"价格变动"明确归 MAJOR,因为它"直接影响销售谈判"。

**教训**:分级规则的失败案例值得记下来——第一版的"重要/不重要"之所以失败,是因为规则太抽象。"重要"对不同人意味着不同的事:对销售,价格变重要;对产品,功能变重要;对客服,条款变重要。一个抽象的"重要"无法覆盖三种视角,误判是必然。第二版的"NOISE/MINOR/MAJOR"之所以成功,是因为每级都对应了具体的"通知方式"——NOISE 不通知、MINOR 进摘要、MAJOR 立即推。这种"通知方式"是规则的硬约束,**抽象的"重要"不如具体的"怎么通知"**。

### 12.2.4 投递层

**现场还原**:投递方式的选择,销售主管提了三种:飞书群消息、邮件、短信。飞书群最直接,但"群消息太多会被划走";邮件最正式,但"销售不会盯着邮箱";短信最快,但"短信费贵"。最终选了飞书群,理由是"销售每天在飞书上沟通客户,消息会看到"。

飞书群的搭建也踩过坑。第一版用普通文本消息,@相关人员,但效果很差——文本消息在群里被刷走,销售第二天才看到。改成"流式卡片"后效果好很多——流式卡片会浮在飞书对话顶部,直到被点击关闭。负责人把第一版和第二版的对比截图发到群里,销售主管回了三个字:"就该这样。"

**现场细节**:流式卡片的内容格式,是负责人和销售主管、产品经理、客服主管共同定的:

> 【MAJOR】\[竞品名] - \[页面类型]
>
> * 摘要:\[40 字以内的实质变化]
> * 证据:\[diff 原文片段]
> * 建议:\[1 条可执行动作]
> * @ 角色:@销售主管 / @产品经理 / @客服主管

这条卡片格式有几个具体的细节值得说:① "证据"字段强制要求 diff 原文,防止 AI 把"折扣倒计时文案"误判为"价格调整";② "建议"字段是"可执行动作",不是"分析"——销售不需要"竞品在调整定价策略"这种分析,需要"明天的客户谈判里,可以提'我们提供等价值服务'"这种动作;③ "@ 角色"用 @ 角色而不是 @ 个人,是因为销售主管可能请假,@ 角色能自动路由到当值的销售。

**教训**:投递层的核心不是"消息能发到",而是"消息会被看"。第一版用普通文本消息,技术上能发到,但销售划走不看,等于没发。第二版用流式卡片,技术上复杂一点,但消息浮在顶部,强制阅读,等于发到。**投递方式的选择,不看"哪个技术上能发",而看"哪个实际上会被读"——信息到达率比到达速度更重要**。一条 5 小时后被读的短信,比一条 5 分钟被划走的群消息,价值高 10 倍。

![三种买法成本对比](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-ec5709e6d3d9ffaee5b302661ba507b5f836d7ba%2Fsec12_cost.svg?alt=media)

## 12.3 30 → 5 → 4 的漏斗

### 12.3.1 漏斗的形成

**现场还原**:漏斗的具体数字,不是设计出来的,是运营 2 周后统计出来的。负责人原本预期"每天 30 条原始变化,5 条 MAJOR"——按这个比例,系统应该每天推 5 条 MAJOR。实际跑 14 天后,数据如下:

* 30 条原始变化:基本符合预期(平均 28.3 条)
* 5 条 diff:略低于预期(平均 4.7 条)
* 4 条 MAJOR:远低于预期(平均 1.2 条,14 天共 17 条)

销售主管看了这组数据,说了一句:"1.2 条 MAJOR 一天,正好。再多我就要屏蔽了。"负责人把数字记下来,加到项目文档里——"漏斗的最终数字,不是设计指标,是用户能接受的最高频率"。

**现场细节**:漏斗的三级开关,是调优时定位问题的关键。第一周漏斗跑到 30→8→6,6 条 MAJOR 太多,销售主管反馈"看不过来"。负责人先看第二级开关(diff 阈值),把最小变化阈值从"3 个字符"调到"10 个字符",结果漏斗变成 30→4→3,3 条 MAJOR 还是偏多。继续调第三级开关(AI 分级规则),把"客户案例更换"从 MINOR 升到 MAJOR 的逻辑改回 MINOR,漏斗最终稳定在 30→4.7→1.2。**每一级开关对应一个可调整的参数,数字异常时,先定位是哪一级的问题,再调该级的参数**。

**教训**:漏斗的价值不在数字本身,而在"漏斗让数字可视化"。30→5→4 这三个数字,是项目可被讨论的基础——运营团队看到"今天 30 条变 4 条 MAJOR",会觉得"系统在干活";看到"今天 30 条变 12 条 MAJOR",会觉得"系统在乱发"。**没有漏斗就没有"多 vs 少"的判断标准,有了漏斗,所有判断都有数字依据**。这是漏斗对团队最大的价值——把主观感受("系统今天发的有点多")变成客观数据("漏斗第三级今天 12 条,平均 1.2 条")。

### 12.3.2 漏斗的价值

**现场还原**:漏斗的价值,有一次特别具体的体现。某天系统推送了 8 条 MAJOR,销售主管直接在群里说"今天怎么这么多?"。负责人调出当天的漏斗数据——30 条原始变化里,12 条是某竞品把"案例展示"页面整批换了一批客户 logo(AI 误判为功能变化),5 条是另一竞品把"博客"页面换了一批文章标题(AI 误判为功能更新)。这两类"假 MAJOR"在原始数据里共 17 条,占了当天 MAJOR 的 80% 以上。

负责人把这两类场景整理成"反例",加进了 NOISE 规则——"批量更换客户 logo"明确归 NOISE,"批量更新博客文章"明确归 NOISE。第二天,漏斗从 30→4→1.2,回到正常水平。销售主管回了三个字:"就该这样。"

**现场细节**:漏斗让"误报"和"漏报"都变得可追溯。30→5→4 的每一级都有具体数字,数字异常时,可以直接定位到该级的规则,改规则即可。如果不分级,误报和漏报都混在"AI 判断错了"里,无法定位。**分级的本质是"让错误可定位",不是"让判断更准"——判断不可能 100% 准,但分级让 100% 准成为可逼近的目标**。

**教训**:漏斗让"信息密度"成为可被讨论的指标。30 条/天的"全量推送"会让团队成员划走不看;1 条/天的"精准推送"会被认真阅读。这个差别,不是"AI 聪明不聪明"的差别,是"信息到达率"的差别。**监控系统的真正价值不是"发现了几次变化",而是"真正重要的内容有没有被人看见"**。漏斗是这个价值可被衡量的基础。

### 12.3.3 漏斗的调优

**现场还原**:漏斗的调优节奏,是运营 30 天后逐步成型的。前 7 天,负责人每天看一次漏斗数据,根据销售主管的反馈微调规则。第 8—14 天,改成每 3 天看一次,这一阶段主要是处理"批量误报"(类似上面"批量换 logo"的场景)。第 15—30 天,改成每周一看一次,这一阶段主要是处理"长期漂移"——某些原本是 MAJOR 的事件,随着业务关注度变化,应该降级为 MINOR。

调优的契机,通常是某个具体事件。某周一,产品经理反馈:"上次你们推的'竞品招聘规模扩大'是 MAJOR,但我后来去 LinkedIn 看,人家只是正常补缺,不是扩张。这种事能不能降级?"负责人查了当天的 diff,发现"招聘数量 +1"和"招聘数量 +10"被 AI 判为同一级别,显然不合理。规则改成"招聘数量 +5 以上才算 MAJOR,+5 以下归 MINOR"。调优就是这样——**不是"AI 学得更聪明",而是"规则越写越细"**。

**现场细节**:30 天调优的记录,负责人在飞书文档里留了 8 个版本:

* v1.0(第 1 天):"重要/不重要"两级
* v1.1(第 3 天):改成 NOISE/MINOR/MAJOR 三级
* v1.2(第 5 天):增加"价格变动必须含数字"规则
* v1.3(第 8 天):把"批量换 logo"加进 NOISE
* v1.4(第 12 天):把"博客更新"加进 NOISE
* v1.5(第 16 天):把"招聘 +5 以上"才归 MAJOR
* v1.6(第 22 天):把"案例更换"明确归 MINOR
* v1.7(第 28 天):增加"MAJOR 必须有 evidence 字段"硬规则

这 8 个版本是 30 天调优的全部产物。每个版本对应一次具体问题、一次具体规则调整。**调优不是"改 AI",是"改规则文档"——文档每改一次,系统就准一点**。

**教训**:漏斗的调优,让团队形成了一个具体的工作节奏——周一复盘,月底评估,季度重构。这个节奏的好处是"调优可预期":团队知道每周一会收到"上周 MAJOR 准确率报告",就会主动把上周的 MAJOR 卡片再翻一遍,把"觉得不对的"反馈给负责人。如果调优是"随时改",团队就不会主动反馈——因为"反正改了也没用,下次还改"。**调优节奏比调优次数重要——每周一次的小调,胜过每月一次的大调**。

## 12.4 成本与边界

### 12.4.1 成本结构

**现场还原**:成本数字的确认,是项目立项时最关键的一次对话。运营负责人一开始估的预算"每月不超过 200 美元"——这是按"招一个兼职运营"的成本倒推的。负责人把 200 美元拆成 3 部分:采集成本 + 理解成本 + 投递成本。Firecrawl 入门档 16 美元/月(2,250 次抓取覆盖 75 页 × 30 天),Haiku 级别模型读 diff 每月 0.8 美元(75 次/天 × 30 天 × 平均 1,000 tokens),飞书机器人 0 美元。三项加起来 16.8 美元,加上偶尔的 API 调试 0.2 美元,总成本 17 美元/月。

运营负责人看到这个数字,沉默了一会,说:"17 美元能做的事,以前花了 2,000 美元请外包做了个报告,还不能每日更新。"——这句话后来成了项目复盘时被反复引用的一句话。**好的系统不是"花得多",而是"花得值"**。17 美元/月的成本对应的不是"少花钱",而是"每日自动化",这种自动化在人工成本里至少值 2—3 个全职岗位。

**现场细节**:成本数字背后有一组对比——

* **自建系统**:Firecrawl 16 美元 + 模型 0.8 美元 + 飞书 0 美元 = 16.8 美元/月
* **轻量商业工具**(如 Visualping、Bright Data 等):100—500 美元/月
* **商用竞品监控平台**(如 Crayon、Klue 等):15,000—50,000 美元/年(折合 1,250—4,200 美元/月)

运营负责人看到对比,直接拍板——"就用 17 美元这套"。后来这套系统稳定运行 6 个月,运营团队一次也没有讨论过"要不要换商业工具"。**成本不是"看单价",而是"看是否解决问题"**。商业工具不一定更准,但贵 100 倍;自建工具不一定更糙,但便宜 100 倍。

**教训**:低成本让监控系统在中型团队中具有可行性。17 美元的成本远低于商业方案,这种成本优势让"竞品监控"从"大公司的特权"变成"中型团队的标配"。如果监控系统的成本是 1,000 美元/月,只有大公司用得起,中型团队会继续"人工盯着看";17 美元/月,中型团队也能用,**工具的真正价值是"降低门槛",不是"功能多"**。同样一件事,从 1,000 美元降到 17 美元,使用人群会扩大 10 倍,这是工具普及的核心规律。

### 12.4.2 边界设定

**现场还原**:边界设定那天,运营负责人和销售主管在会议室里争论了 25 分钟。运营负责人说:"既然系统已经在跑了,顺便监控一下竞品的 App Store 评分和微博官号。"销售主管说:"对,他们微博最近老发促销信息。"负责人当场把边界文档翻出来,问:"这两条属于'公开页面'吗?"运营负责人答:"App Store 是公开的,微博也是公开的。"负责人说:"App Store 评分和微博是公开的,但它们不是'页面'——前者是第三方平台的数据接口,后者是社交媒体的内容流。这两类内容的抓取频率、稳定性、变化模式都和普通网页不同,需要单独的工具和规则。"

运营负责人听完,问:"那这两类用什么监控?"负责人答:"App Store 评分用 App Annie 或 Sensor Tower,微博用舆情监控工具(如新浪舆情通、蜜度)。这两类数据是'情报补充',不是'竞品监控'的一部分。"

**现场细节**:边界设定后,负责人把所有"边界外"的需求归到一个清单,叫"情报补充工具清单":

* **App Store / Google Play 评分**:App Annie、Sensor Tower、点点数据
* **微博/小红书/抖音 官号**:新浪舆情通、蜜度、知微
* **行业报告**:艾瑞咨询、易观、IDC、Gartner
* **媒体新闻**:百度新闻、谷歌新闻
* **融资/工商信息**:IT 桔子、企查查、天眼查

这份清单是边界外需求的"出口"——任何"想监控 X,但 X 不在公开页面"的需求,都能在这份清单里找到对应的工具。**边界不是"不做",而是"用对的工具做"**。监控系统专注公开页面,其他工具专注其他类型数据,各司其职。

**教训**:边界设定后,后续 30 天里有 3 次"边界外"需求,都被清单"消化"了——销售主管想监控微博,产品经理想看 App Store 评分,客服主管想监控媒体新闻。每次都从清单里找对应工具,没扩张过监控系统的边界。**边界的可持续性,不是"守住",而是"给出口"——只有给边界外的需求一个出口,边界才不会被反复冲击**。

## 12.5 实战效果

### 12.5.1 上线效果

**现场还原**:系统上线的第一天,负责人和销售主管、产品经理、客服主管 4 个人一起,等早上 7:30 的抓取结果。7:33,飞书群弹出第一条 MAJOR 卡片:

> 【MAJOR】竞品 B - 定价页
>
> * 摘要:专业版从 29 美元/月降至 24 美元/月,免费版用户数从 100 提升至 200
> * 证据:"Pro Plan: $24/month (was $29/month)... Free tier: 200 users (was 100 users)"
> * 建议:销售在明天的客户谈判中,可强调"我们提供等价值服务而非低价"
> * @ 角色:@销售主管 / @产品经理

销售主管看完卡片,第一反应是:"我昨天还跟客户说对方是 29。"——这是系统上线的第一次实战检测,从发现到通知用了不到 1 小时,正好达到"对手修改当天,团队收到通知"的目标。

**现场细节**:上线 30 天的数据,负责人在飞书文档里留了完整记录:

* **每日告警**:平均 1.2 条 MAJOR 级消息(漏斗 30→4.7→1.2)
* **响应时效**:对手修改当天,团队收到通知(平均从修改到通知间隔 2.3 小时)
* **零误报**:30 天内误报率接近 0(无重大错报,只有 2 次边缘 MAJOR 在销售主管反馈后被标记为"参考级")
* **运营成本**:每月 16.5 美元(在预算内)

销售主管每天早上 8 点打开飞书群,30 天里只错过 1 次(那天他请假,@ 角色自动路由给了当值的销售)。**数据本身不说明价值,说明价值的是"这 30 天里,团队对竞品动态的感知从'偶尔听客户说'变成了'每天主动知道'"**。

**教训**:上线的第一天,负责人做了一件看似多余的事——把系统推送的每一条 MAJOR 都截图存档,按"竞品名 - 页面类型 - 日期"分类。这件事后来证明非常关键:第 17 天有客户问"竞品 X 是不是最近有降价",负责人当场翻出 3 周前的 MAJOR 卡片,展示证据,**让销售谈判时有了具体抓手**。上线第一天的小习惯,在第 17 天变成了具体价值。

### 12.5.2 业务价值

**现场还原**:第一次 MAJOR 告警是 10 月 18 日——竞品 A 把主力套餐价格从 27 美元/月降到 17 美元/月(降幅 37%)。告警推送时间是上午 8:12,销售主管 8:24 看到,8:30 在销售群里发了一条:"今天起,所有正在谈判的订单,价格策略调整如下——如果客户提到竞品 A,直接给到 22 美元/月,锁定客户。"当天下午,销售反馈了 2 个被锁定的客户。

第二次 MAJOR 告警是 11 月 2 日——竞品 B 上线了一个新功能"AI 自动生成报告",产品经理当天调整了自家路线图,把"AI 报告生成"从 Q2 提前到 Q1。

第三次 MAJOR 告警是 11 月 14 日——竞品 C 取消了免费额度,客服主管在第二天客户问"你们也有免费版吗"时,直接答"我们没有免费版,但有 14 天试用,试用期内功能完整"。

**现场细节**:三次 MAJOR 告警对应三种不同的业务影响——

* 价格类:直接影响销售谈判策略
* 功能类:影响产品路线图排期
* 条款类:影响客服话术

**业务影响类型的清晰分类,让每次告警的"接收者"很明确**——价格类 @ 销售,功能类 @ 产品,条款类 @ 客服。这种"接收者清晰"的告警,比"全员通知"的告警效率高 5—10 倍——销售不会去读功能类告警(读了也不知道怎么处理),产品不会去读价格类告警(读了也不是自己负责的)。**告警的价值不在"通知所有人",而在"通知该知道的人"**。

**教训**:监控系统的业务价值不在"发现了几次变化",而在"避免了哪些损失"——这三次 MAJOR 告警如果没被系统捕捉到,可能发生的事是:销售在谈判桌上继续按原价报价(被竞品压死),产品在 Q2 才补"AI 报告生成"(被竞品抢走先机),客服按老话术回答客户(被客户说"你们怎么这么落后")。**监控系统卖的不是"信息",是"决策时间"——把"事后知道"变成"当天知道",这段时间差,就是业务价值**。每次告警的价值远超系统成本——17 美元的月成本,换来了"对手动态当日感知"的能力。

## 12.6 方法论提炼与可复用资产

**现场还原**:项目运行 30 天后,运营团队开了一次复盘会。运营负责人、销售主管、产品经理、客服主管、负责人 5 个人围着白板,把 30 天的 MAJOR 卡片按类型归类——价格类 8 条、功能类 5 条、条款类 3 条、招聘类 1 条。销售主管指着白板说:"这 17 条 MAJOR,平均每条省下来的是 2—3 个销售的小时工作量(不用再人工查竞品动态)。17 条 × 2 小时 = 34 小时,按 100 美元/小时算,价值 3,400 美元,系统成本 17 美元/月。投入产出比 200:1。"——这个数字后来被运营负责人写进了季度汇报。

本章的方法论可提炼为四个原则。

**原则一:三层管道解耦**。采集、理解、投递三层只传文本,各自独立可替换,降低系统复杂度。

**原则二:三级分类决定信息密度**。NOISE/MINOR/MAJOR 三级分类,让信息从"全量"变成"精准",避免告警疲劳。

**原则三:边界清晰是可持续运营的前提**。只监控公开页面,不越界,既是工程伦理,也是成本控制。

**原则四:成本远低于商业方案**。17 美元/月的自建成本,是商业方案的 1/10 到 1/100,让中型团队也能用得起。

**可复用资产:竞品监控系统的检查清单**——本节 12.2 给出的三层架构,可作为所有"周期性数据监控"项目的模板。

```
竞品监控系统检查清单

[采集层]
□ 监控范围:5 个核心竞品 × 15 个公开页面
□ 监控频率:每天一次
□ 采集成本:每月 < 20 美元
□ 稳定性:持续运行 30 天无中断

[理解层]
□ 分级规则:NOISE / MINOR / MAJOR 三级明确
□ 漏斗:30 → 5 → 4 数量级递减
□ 误报率:< 5%
□ 调优机制:每周复盘、每月调整

[投递层]
□ 通知方式:飞书群流式卡片
□ 通知时效:变化发生后 1 小时内
□ 可追溯:通知内容可被检索
□ 接收者认领:每条 MAJOR 有人认领处理
```

### 12.7.1 本章思考题

1. 12.1.2 的"对手改价当天感知"四件事(5 竞品×15 页/每天一次/当天通知/≤$17/月):你的监控系统满足几条?哪一条最难做到?
2. 12.2.1 的三层管道(采集—理解—投递):你团队的监控是"一层做所有事"还是三层解耦?如果是前者,排查问题的平均时间是多少?
3. 12.2.3 的"NOISE/MINOR/MAJOR"三级分类:你团队当前的"重要"判定是"抽象的重要"还是"具体的通知方式"?误判率是多少?
4. 12.3 的 30→5→4 漏斗:你团队的漏斗实际数字是多少?如果 MAJOR > 2 条/天,销售是否会开始屏蔽?
5. 12.1.3 的"公开可见 vs 开放取用"边界:你团队的监控范围有没有越界(登录后页面、付费墙后内容)?越界后的法律风险评估过吗?

### 12.7.2 本章延伸阅读

1. **\[数据报告] Visualping 官方博客《Understanding Visualping's Pricing》(2026-04-11)** — Business 档 $100/月起含 20,000 次检查/200 页;Slack/Teams 团队集成门控在 Business 档 | 第 12 章
2. **\[数据报告] Linkeddit《Crayon and Klue Alternatives: The 2026 Guide for Small Teams》(2026-07-03)** — 企业级 CI 平台第三方估算:Crayon 约 $25,000—$60,000/年、Klue 约 $30,000—$100,000/年 | 第 12 章
3. **\[数据报告] ScoutRival《The Best Visualping Alternatives for Website Change Monitoring (2026)》(2026-07-23)** — 轻量监控工具档位参照:Distill.io 云端付费约 $15/月起、Wachete 约 $4.90/月起、Hexowatch Pro 约 $29/月起 | 第 12 章
4. **\[文章] CSDN 合法爬虫四底线 法律边界(2026-05)** — 最高检 2025-11 口径:登录后越权拉数据仍可构成刑法 285 条 | 第 12 章
5. **\[文章] 绍兴市律师协会爬虫法律争议调研** — 上海晟品案首开刑事处罚、大众点评诉百度、微博诉脉脉的国内判例梳理 | 第 12 章

## 12.7 完整提示词:竞品监控系统的全流程编排

以下提示词用于"自动监控 5 个核心竞品的公开动态,变化即时通知团队"。它体现了"三层管道(采集—理解—投递)+ 三级分类(NOISE/MINOR/MAJOR)+ 清晰边界(只监控公开)"的方法论,且所有抓取动作都必须在 prompt 里显式声明边界。

```
你是竞品情报分析师,擅长把 5 个核心竞品的公开动态变化,转化为团队可决策的告警。接下来的所有工作,你必须严格按"采集—理解—投递"三层管道推进,每层只传文本,互不依赖彼此的内部实现。

【你的工作边界——这条最重要,先读完】
- 只监控公开页面(无须登录、无付费墙、无验证码)
- 不绕过任何技术防护
- 不抓取登录墙、付费墙、验证码之后的内容
- 不抓取个人敏感信息(姓名、手机、邮箱、身份证)
- 抓取频率控制到对方感受不到(单域名每秒不超过 1 次,每天总量不超过对方页面数的两倍)
- 所有抓取动作保留完整日志(URL、时间、频率、HTTP 状态码),至少保留 90 天
- 越界监控可能引发纠纷或停摆——边界比情报重要

【你的工作方式】
- 采集层:每天早上 7 点(北京时间)触发,从 5 个核心竞品 × 15 个公开页面 = 75 个页面抓取,保存为 JSON 文件
- 理解层:用廉价模型对比新旧两版,按"NOISE / MINOR / MAJOR"三级分类
- 投递层:MAJOR 级以飞书流式卡片推送到"竞品情报"群,标题为竞品 + 页面类型,正文 40 字摘要 + 证据片段 + 建议动作

【三级分类规则(必须严格遵守)】
- NOISE(噪声):页脚版权年份、轮播图换序、"猜你喜欢"推荐位刷新、"已有 X 人购买"等动态元素——仅记录,不通知
- MINOR(次要):文案润色、客户案例更换、博客更新等——并入每日一条的早间摘要
- MAJOR(重大):价格变动、折扣调整、功能上下线、服务条款修改、免费额度变化——即时推送 + @ 相关人员

【30 → 5 → 4 漏斗的纪律】
- 75 个页面每天平均产生 30 条原始变化
- 采集层过滤后,5—8 条 diff 需要你阅读
- 5—8 条中,MAJOR 误报每天约 5 条(经三层过滤后降至每周 1 条以内)
- 真正重要、值得团队成员放下手头工作查看的变化,平均每天不足 4 条
- 漏斗的每一级都有控制开关,某级数字异常时调整该级

【证据字段是分级的基础】
MAJOR 判定必须附带 diff 原文作为 evidence;没有 evidence 字段,自动降级为 MINOR。理由:防止模型把"折扣倒计时文案"误判为"价格调整"。

【分析 Prompt 模板(理解层使用)】
你收到一段某竞品公开网页的新旧两版差异(diff 文本)。请按以下要求处理:
1. 用一句中文概括变化的实质(不超过 40 字)
2. 按规则分级:NOISE / MINOR / MAJOR
3. 若判为 MAJOR,指出受影响的内部角色(销售/产品/客服),并给一条可执行的建议动作;否则 action 填 null
4. 只输出 JSON,不要输出其他内容:
{"summary": "...", "level": "NOISE|MINOR|MAJOR", "evidence": "引用 diff 原文片段", "action": "...或 null"}

【投递卡片格式(MAJOR 级)】
【MAJOR】[竞品名] - [页面类型]
- 摘要:[40 字以内的实质变化]
- 证据:[diff 原文片段]
- 建议:[1 条可执行动作]
- @ 角色:@销售主管 / @产品经理 / @客服主管

【输入格式】
提供——
- 5 个竞品的官方域名
- 每家 15 个监控页面 URL
- 飞书群 ID
- 授权的 @ 人员名单

【输出格式】
- 采集层产出:JSON 文件(75 个页面的快照)
- 理解层产出:diff 文件 + 分类结果 JSON
- 投递层产出:飞书消息(MAJOR 卡片 + MINOR 摘要)

【边界约束(再次强调)】
- 75 个页面必须是公开的、无须登录的
- 频率必须严格控制(单域名每秒不超过 1 次)
- 任何反爬拦截的页面,降权或转人工
- 抓取过程中遇到验证码,立即停止并通知
- 所有抓取动作留痕,保留 90 天

【遇到这些情况,暂停监控并通知我】
- 抓取接口被反爬拦截(连续 3 次失败)
- 数据突增 5 倍以上(可能是抓取脚本出错)
- 监控费用超过预算(每月 20 美元)
- 你发现某个竞品页面的变化无法判断重要性
- 飞书群消息发送失败
- 任何越界请求(需要登录、需要付费)

【30 天持续运行的纪律】
- 每周一:复盘上周的 MAJOR 告警准确性(基于团队反馈)
- 每月 1 日:评估监控范围是否需要调整(增删竞品、增删页面)
- 每季度:重新测试 stealth 占比,调整积分预算
- 长期运行后,清理 90 天前的日志
```

## 本章方法论:让 AI 替读者保持信息优势

本章的方法论核心是"让 AI 替读者保持信息优势"——竞品监控系统的价值不在于"知道所有变化",而在于"对重要变化保持当日感知"。三层管道(采集—理解—投递)+ 三级分类(NOISE/MINOR/MAJOR)+ 清晰边界(只监控公开),共同构成"低成本、高时效、可持续"的监控系统。

下一章将进入"AI 生成代码的失序"——讨论 AI 编程中四类反复发作的工程问题:代码质量下滑、上下文失效、文档与代码不一致、架构渐进腐化。这一章关注的是"AI 替读者干活时的副作用",以及如何系统化地治理。