面向顾问的竞品监控 API：一个客户一个监控

每一份顾问合约里都有一句话，说你会帮客户盯着市场。这句话从来不单独计费，也是忙月里第一个被丢下的事。

手动的做法是每个客户开一个浏览器标签页，外加好记性。搭建的做法是写个 scraper，撑到第三个项目为止。到那时，你为第一个客户写的东西正在默默比对一个六月就改版过的页面，而且没人发现，因为一个什么都没查到的监控和一个已经死掉的监控，从外面看一模一样。

面向顾问的竞品监控 API 背负着一个内部团队没有的约束：你同时盯着好几个市场，替别人盯，而且只盯到每个项目结束为止。

怎么把一个客户的监控和另一个客户的分开

一个客户一个监控。一个监控就是一个名称、最多 20 个 URL、一条 cron 排程和一个时区，一个账户可以放 50 个。那就是五十个项目、每个二十个页面，之后才轮到你去操心任何上限。

curl -X POST https://crawlforge.dev/api/v1/monitors \
  -H "X-API-Key: cf_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Northwind - competitor pricing",
    "targets": [
      { "url": "https://rival-a.com/pricing", "selector": ".pricing-table" },
      { "url": "https://rival-b.com/careers", "selector": "main" }
    ],
    "schedule_cron": "0 7 * * 1",
    "timezone": "Europe/London",
    "retention_days": 365,
    "notify_emails": ["you@yourfirm.com"]
  }'

用客户的名字来命名。这不是整理癖：每次检查都会往你的请求日志里写一行，带上这个名称、监控 id 以及实际扣掉的 credits，于是八月我们在 Northwind 的市场上花了多少就成了日志能直接回答的问题，而不是你在开票前一晚硬凑出来的数字。

timezone 也要按监控单独设。客户的周一早上不一定是你的周一早上，而在错误的半球跑的一次 7:00 检查，会赶在它本该支撑的那场会议之后才到。

能不能用 Claude Code 而不是 curl 来操作

可以，而且在项目的头一周，它是更趁手的工具。CrawlForge 的 MCP server 通过 track_changes 暴露同一套机制，于是探索阶段——这家客户这边到底什么值得盯——就发生在你已经在写方案的那个编辑器里。

{
  "url": "https://rival-a.com/pricing",
  "operation": "create_scheduled_monitor",
  "trackingOptions": { "customSelectors": [".pricing-table"] },
  "scheduledMonitorOptions": {
    "hosted": true,
    "name": "Northwind - rival A pricing",
    "schedule": "0 7 * * 1"
  }
}

关于这个调用，有两件事最好在依赖它之前就知道，而且从 schema 上都看不出来。

hosted 默认是 false。 本地的定时监控跑在 MCP server 进程里，所以你一关编辑器它就停了。用来做一周的探索没问题，用来撑长期合约就不行。传 hosted: true，监控就搬到 CrawlForge 自己的 scheduler 上，无论你的笔记本开着还是关着都会触发。

自然语言写的 goal 撑不过这次搬家。 在本地你可以写 goal: "tell me when the Pro plan price changes"，由模型逐个 diff 去判断。hosted 监控会忽略 goal，对每一个变更、新建、被拦截或出错的页面都发通知。工具确实会返回一条警告说明这一点，但很容易一划就过去了。请改用 CSS 选择器来圈定一个 hosted 监控，而不是用一句话。

还有一个算术问题，算不上陷阱。MCP 这条路径是一个 URL 建一个监控，把 customSelectors 摊成同一个页面上的多个目标，所以这样盯一个客户的二十个页面，要吃掉你五十个监控里的二十个。上面那个 REST POST 把二十个装进一个里。探索期用 MCP，等到确定要长期保留的那个监控，再用一次 REST 调用。

项目的两个阶段之间会怎样

暂停它。对监控发 PATCH 把 status: "paused" 设上，它会保留每一条基线、拿不到下一次运行，所以等待期间一分钱不花。恢复之后，第一次检查会拿暂停之前的最后一份快照来比对。安静的那几个月会以一次变更的形式回来，而不是记录里的一个窟窿。

当某个阶段今天就要答案、等不到下一个时段时，POST /api/v1/monitors/{id}/run 会当场跑一次检查并把页面结果交回来。

交付物到底从哪里来

来自检查历史，而不是你对它的记忆。GET /api/v1/monitors/{id}/checks 按从新到旧列出检查，读取其中一次会返回它的各个页面，带 change_percent、新增和删除的计数，以及 diff 两侧各最多 20 行样本。这就是本季度有哪些变化那页幻灯片可以直接引用的材料，而不是某人七月截的一张图。

第一天就把 retention_days 设好。它的范围是 1 到 365，默认 30，超出窗口的检查会在每次运行结束时被清理掉，而且不会回来。一个为期十二个月、希望在结项时拿到自己完整历史的项目，必须一开始就写 365；到第十一个月再想要是要不回来的。端点参考在文档里。

盯住一个客户的市场要花多少钱

每个被抓取并比对的目标 3 credits，也就是 track_changes 的价格，不管调用来自 REST 还是 MCP。被拦截和出错的目标不计费。创建、更新、暂停和删除监控都是免费的。

二十个页面按周一的排程跑，在 30 天窗口里是四到五次检查，也就是 240 到 300 credits。十个客户都按这个模式，加起来一个月也不到 3,000 credits。这里没有按人头收费，也没有可以盯多少页面的上限，那是另一篇文章的话题。

值得据此行动的结论是：广度便宜，频率不便宜，所以盯更多页面、但盯得没那么勤。对手在招聘页上悄悄挂出一个慕尼黑的客户经理职位，这件事告诉你的下两个季度，比他们的定价页要多，而那个页面一年大概才变两次。

它不会做的事

• 没有面向客户的界面。 一个账户、一把 key，没有按客户的登录，监控之间也没有权限边界。客户看到的，就是你发给他们的。
• 它没有联系人数据或企业属性数据。 它读的是你指给它的页面，位于你研究工作已经在用的那套数据库之上。它不是 Apollo 或 ZoomInfo，也不假装是。
• robots.txt 始终遵守， 没有开关。被禁止的路径每次检查都会返回 ROBOTS_DISALLOWED，而且从不计费。
• 两次运行之间至少间隔五分钟， 这让它成为一件按天和按周使用的工具。反正那本来就是出报告的节奏。

如果你想要的是把变更送进 CRM 或某个频道，而不是写进一份文档，webhook 那一侧在这里。

免费开始，赠 1,000 credits，大约够一个客户五个页面盯两个月，或者打开监控面板，在写任何代码之前先读一次真实的检查结果。