上周接了运营侧的需求手里攒了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(headlessTrue) # 加自定义UA不要用playwright默认的UA很容易被识别 context browser.new_context( user_agentMozilla/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, timeout5000) # 等待遮罩层完全隐藏最多等20秒 page.wait_for_selector(.detect-loading, statehidden, timeout20000) # 直接拿全局变量的结构化结果不用解析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属性也能拿到完整的检测结果有空的话补个兼容版本的逻辑。