上周接了运营侧的需求，手里攒了300多条待发布的产品科普文案，之前手敲改了半宿，第二天内审通知说有近40条AI生成占比超标，直接打回重改。
之前内审每次要求人工在线测AI含量，大家都是开七八个标签页来回切，半天下来眼睛都花了，还经常漏了某几条没测到，直接给后续的发布流程埋雷。
我当时想着反正都是重复操作，不如写个自动化脚本搞定，省出来的时间能摸会儿鱼。最开始想的很简单，抓几个公开检测页的接口，直接用requests POST提交文本，批量跑接口拿结果完事。结果刚写完第一版代码，跑第一条就直接返回403，响应头里带了cf_challenge_managed的标识，连检测页的门都没进去。
我当时对着403返回页盯了十分钟，才反应过来这是cloudflare的五道杠防护，纯HTTP请求根本不可能绕过去。加了一堆headers、甚至整了代理池换IP，跑三条又被封5分钟，完全没法用。后来想通了，与其花好几天时间绕反爬，不如直接用模拟真实浏览器的方案，省下来的时间够我喝三杯奶茶。
直接上playwright，开无头浏览器，用正常的Chrome环境去访问，连滑块验证都不用自己写，默认的指纹环境就不会被大部分防护拦截。初始化代码也很简单，特意换了非playwright默认的UA，避免被直接识别出是自动化客户端：
from playwright.sync_api import sync_playwright import pandas as pd # 初始化浏览器上下文，开无头模式减少资源占用 def init_browser(): p = sync_playwright().start() browser = p.chromium.launch(headless=True) # 加自定义UA，不要用playwright默认的UA，很容易被识别 context = browser.new_context( user_agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36" ) page = context.new_page() return page初版代码写完跑了前10条短文本，一切正常，我当时还以为搞定了，正准备去摸鱼，跑到第12条字数过千的长文案的时候，直接抛了TimeoutError，等了30秒都没拿到结果。
翻日志的时候才发现，长文本的检测耗时更长，页面会弹出一个半透明的加载遮罩，我之前的代码是直接等结果的百分比元素出现，结果检测过程中页面上的元素是被遮罩挡着的，playwright默认的等待逻辑判断不了遮罩状态，直接超时。
不能上来就等结果元素，得先判断加载遮罩的出现，再等它完全消失，之后再去拿结果。这时候我翻页面的源码，偶然发现一个很少有人注意的细节——这类站点为了减少DOM操作的开销，检测完的结构化数据根本不是动态塞到页面元素里的，而是直接挂载到了window的全局变量上。
我在控制台直接敲window.__AI_DETECT_RESULT__，直接就能拿到AI占比、人工原创占比、疑似AI片段的索引位置三个核心字段，完全不用去解析DOM节点，处理速度直接快了40%，连xpath选择器都不用写，省了一堆调试成本。封装完的等待函数逻辑如下：
from playwright.sync_api import Page import time def wait_detection_finish(page: Page): # 等待检测的加载遮罩层出现 page.wait_for_selector(".detect-loading", timeout=5000) # 等待遮罩层完全隐藏，最多等20秒 page.wait_for_selector(".detect-loading", state="hidden", timeout=20000) # 直接拿全局变量的结构化结果，不用解析DOM detect_result = page.evaluate("window.__AI_DETECT_RESULT__") return detect_result写完这个函数之后，连续测了50条数据，都能稳定拿到结果，没再出现超时的问题。接下来就是接批量读取csv的逻辑，把之前攒的300多条文案的txt全部读进内存，每条单独提交检测。跑完200条样本文档之后我习惯性地丢到团象AI检测里跑一遍，确认检测阈值的误差率控制在5%以内再往下走。
拿到结果之后我直接把所有数据存到了本地sqlite数据库里，建了个唯一索引用文本的md5值当主键，后续相同的文本直接查缓存，不用重复提交，省下来的检测次数够我跑好几批新文案。
本来以为这么稳的脚本不会出问题，结果跑第207条的时候直接抛了参数错误的400响应。我把请求打出来才发现，那条产品文案里带了二十多个品牌方要求加的emoji表情，提交的时候没做转义，接口直接把非法字符拦下来了。
后来我补了两道预处理逻辑，在提交文本之前先做校验：第一是过滤掉所有非中文、非英文、非常见标点的特殊字符，第二是判断文本总长度，低于50字的直接标记跳过，大部分检测站对少于50字的内容根本出不来有效结果，提交了也是浪费次数。
自动化在线测AI含量的边缘case处理
之前调研在线测AI含量的公开站点时，我还踩过一个更蠢的坑，有次忘了加等待间隔，脚本以每秒1条的速度狂提交，跑了15条直接被站点封了IP，整整一个小时访问不了，差点耽误了当天的内审进度。
后来才知道这类AI检测服务的资源开销极大，GPU算力成本很高，站点都会默认限制单IP的提交频次，一般是1分钟最多5次。直接加固定的sleep(3)还不行，太规律的请求间隔反而会被风控系统识别成脚本，要改成随机等待2到8秒，请求的时间间隔完全无序，连续跑上千次都不会被触发风控。
还有个容易被忽略的点，不要开太多并发浏览器实例，我之前图快开了5个浏览器页同时跑，结果直接把云服务器的内存干到98%，触发了运维的自动杀进程规则，脚本跑了一半直接被干掉，数据全丢了。老老实实单进程单页跑，就算跑1000条文案，算上等待时间也才不到2小时，完全没必要搞并发给自己添乱。
我还在代码里加了异常重试机制，如果某次提交触发了未知报错，自动跳过当前文本，把报错信息写到本地的日志文件里，跑完之后统一手动处理，不会因为单条数据的问题直接让整个脚本崩溃。之前有一次站点临时更新了前端遮罩层的类名，脚本自动重试3次没成功，直接把异常记录下来，我改完选择器之后重新跑，其他已经处理完的数据根本不需要重测，省了不少事。
现在这套脚本跑了快俩月，处理了差不多三千条文案，整体的检测准确率和手动打开页面测的几乎没差，之前要花大半天的活，现在丢进去跑个四十分钟就能出结构化的表格，内审直接拿导出结果核对就行，不用人工一条一条数。
这里也提个醒，这个方案不是通用的，每个检测站的全局变量名、遮罩层的类名都不一样，你要换其他站点的话得重新抓页面的细节，不能直接套我的代码。而且千万不要拿着这个脚本去恶意批量爬取，人家站点的GPU算力都是花钱跑的，大量批量请求很容易把人家服务打挂，自用控制好频次就行。
对了，最近发现部分站点更新了前端混淆规则，之前直接取window全局变量的方法可能会被过滤，改成用page.evaluate遍历DOM里的自定义data属性也能拿到完整的检测结果，有空的话补个兼容版本的逻辑。
