我用规则封爬虫封错了三次，最后才让AI看日志找异常

先说失败的部分

接手一个线上服务的访问日志分析之前，我一直觉得「识别爬虫」是个已经解决的问题：加个 User-Agent 黑名单，配个频控，再不济上个人机验证，总能挡住。

第一次翻车：UA黑名单。三天后日志里出现大量 Mozilla/5.0 (Windows NT 10.0) 这种再普通不过的标识，请求频率却是人类的八十倍。对方换UA的成本是零，我维护黑名单的成本是每天。

第二次翻车：全局频控。设了「单IP每分钟60次」，结果误伤了一批走公司出口NAT的真实用户，客服工单先于爬虫报警到达。更尴尬的是，爬虫用了一批轮换的低频IP，每个IP每分钟只来20次，规规矩矩地从我阈值底下钻过去了。

第三次翻车：直接把日志丢给AI，「帮我找出爬虫」。模型很努力地返回了一篇教科书式的爬虫特征科普，附带一堆泛泛的建议，没有一条落到我这几百万行日志上。问题不在AI,在我给它的任务等于让一个实习生「看看数据，说说想法」——没有上下文、没有判断标准、没有输出格式，任何人都只能交差式回答。

正确的路径：把AI当成「读日志的取证助手」

我后来想明白一件事：AI在这里的价值不是「懂爬虫知识」，而是它能把几百万行日志里人类根本看不过来的模式，按你给定的标准逐条核对、归类、举证。

关键转变有三个：

1. 先让AI帮我把「什么叫异常」定义清楚，而不是先跑模型。我把业务背景(正常用户的访问路径、峰值时段、典型会话长度)喂给它，让它先起草一份异常判定假设清单，我人工确认修订。
2. 让AI做结构化输出，不做自由发挥。每条结论必须带证据：哪个IP、哪段时间、什么模式触发了哪条假设。
3. 闭环验证。AI标记出的可疑IP,先抽样人工核实，再决定是否封禁，规则沉淀下来下一轮复用。

具体流程

第一步：预处理。 日志太大不能全喂，先按小时切片，用脚本聚合成「IP级会话摘要」——每个IP的请求数、独立路径数、路径熵值、UA数量、请求间隔分布、命中率(200/404比例)。这一步是普通脚本能干的，别浪费token。

第二步：带假设地提问。 把摘要样本加上业务背景一起给AI,用下面这个模板：

角色:你是一名访问日志取证分析师。

背景:
- 这是一个【电商/内容/工具类】网站,正常用户日均访问【N】页,平均停留【N】分钟
- 正常流量高峰在【时段】,存在真实用户共用出口IP的情况
- 网站没有公开API,所有机器请求都应视为可疑

数据:以下是按IP聚合的小时会话摘要,字段包括
【请求数/独立路径数/路径熵/UA数/请求间隔分布/状态码比例】

任务:
1. 逐条对照以下异常假设,判断每个IP命中了哪些:
   - 假设1:请求间隔方差极小(机器节奏)
   - 假设2:单会话访问路径熵异常高或异常低
   - 假设3:多个UA出现在同一IP
   - 假设4:404/探测路径(.env、/admin)占比高
   - 假设5:多IP行为指纹高度一致(分布式爬虫)
2. 你认为还有哪些假设值得补充?说明理由
3. 输出格式:表格,列为【IP / 命中假设 / 证据摘要 / 置信度(高中低)】
   只输出表格和补充假设,不要写科普内容

第三步：人工抽验。 高置信度的直接进观察名单，中低置信度抽样看原始日志。这一步省不掉，但工作量从「看几百万行」变成「看AI圈出的几十行」。

第四步：规则沉淀。 把确认的指纹(IP段、UA组合、行为模式)固化到网关层，同时把误判案例记下来，作为下一轮提示词的修正输入。

用AI前后的对比

最大的变化不是「抓得多准」，而是每一次封禁我都能拿出一条可解释的证据链。以前误伤用户时我只能道歉，现在能说清楚为什么这个IP之前被标记、为什么这次解除了。

几个提醒

• 别把原始日志原文直接扔进去，聚合摘要比原始行更有效也更省成本。token成本与模型档位相关，以官网价格页为准。
• 别让AI直接执行封禁动作。它的产出应该是「建议+证据」，执行权留在你的规则系统里。大模型会犯自信的错误，这一点在封IP这种事上代价不对称。
• 判定标准要随业务更新。上了一次活动、改了一次路由结构，正常行为画像就变了，提示词里的背景描述要跟着改。

反爬不是一次性的战役，是一个持续取证的过程。AI把「看不过来的日志」变成了「看得过来的证据清单」，这件事本身就值回票价。

如果你也在找一个稳定的大模型接入层来跑这类日志分析任务，可以看看这个平台的注册入口：https://api.thistoken.ai/register

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。