1. 为什么我要给个人网站做一套AI可见性监测个人站长这两年应该都有一个共同的感受辛辛苦苦写的文章搜索引擎里排名还行但丢给几个主流AI助手一问要么完全不知道你的站要么张口就是过时信息甚至把别家的内容张冠李戴安到你头上。我自己的技术博客就遇到过这种情况——一篇讲Python异步爬虫的实操文在某AI助手里被总结成了某框架官方文档的翻译连站点名字都没提。这件事促使我开始认真思考一个问题在AI逐渐成为信息入口的今天一个网站的可见性已经不只是SEO排名还包括AI模型能不能准确识别、引用、复述你的内容。我把这个维度叫做AI可见性它和传统SEO有重叠但关注点完全不同。SEO关心的是爬虫抓取和关键词排名AI可见性关心的是模型在生成回答时是否把你的站点当作可信信源。于是我给自己定了一个小项目搭一套自动化的AI可见性监测台用一批固定的探针问题去反复询问多个AI助手记录它们是否提到我的站点、提到了哪些页面、描述是否准确然后把这些结果沉淀成可对比的时间序列数据。整套系统跑下来目前稳定运行82道探针题每天自动采样一轮结果存本地数据库配一个简单的看板。这套东西适合谁参考我觉得有三类人一是像我这样的个人站长或独立开发者想量化自己在AI眼里的存在感二是做AI测试开发的同学想找一个真实的多模型采样场景练手三是对Playwright自动化感兴趣、想找个完整项目落地的工程师。整套方案用Python Playwright SQLite就能跑起来不需要服务器集群一台常开的机器足够。下面我把整个设计思路、核心实现、踩过的坑和排查经验完整拆开讲尽量做到你照着能复现。2. 整体架构设计与技术选型思路2.1 系统要解决的三个核心问题在动手之前我先把需求拆成了三块因为不同的需求对应完全不同的技术方案混在一起做很容易返工。第一块是探针管理。82道题不是随便凑的它们要覆盖我站点的核心主题同时要能区分模型知道我的站和模型只是泛泛而谈。所以每道题都要有预期关键词、预期页面、以及一个如果模型提到了这些词就算命中的判定规则。这部分本质上是数据建模问题。第二块是自动化采样。我需要程序化地向多个AI助手提问并抓取回答。这里最大的难点是这些AI产品大多没有公开API或者API要付费、有额度限制。所以只能走浏览器自动化用Playwright模拟真人操作。这就引出了反自动化检测、登录态维持、回答流式加载等一系列工程问题。第三块是结果分析与可视化。采样回来的原始回答是一堆文本需要做命中判定、去重、时间序列聚合最后呈现成本周AI可见性得分哪些探针题命中率下降这类可读指标。2.2 为什么选Playwright而不是Selenium这个选择我纠结过一阵。Selenium生态更老、资料更多但实测下来在AI产品这种重前端、频繁异步渲染的页面上Playwright的优势非常明显。首先是自动等待机制。AI回答是流式输出的DOM会不断变化。Selenium需要你手写大量WebDriverWait而Playwright的locator自带等待和重试写起来干净很多。其次是多浏览器上下文隔离Playwright的browser.new_context()可以给每个AI产品开独立的cookie和storage互不干扰这对同时登录多个账号特别有用。第三是网络拦截能力Playwright可以直接监听和修改请求某些场景下比纯DOM抓取更稳。至于热词里提到的CDPChrome DevTools ProtocolPlaywright底层其实就是通过CDP和Chromium通信的。我在调试阶段会直接用CDP的Network域去看请求确认回答数据是从哪个接口回来的——有时候直接抓接口比解析DOM靠谱得多。但正式运行时我还是以Playwright的高层API为主CDP只在排查问题时用。2.3 数据存储为什么用SQLite而不是MySQL个人项目单机运行数据量每天也就几百条记录SQLite完全够用而且零运维。我的表结构大致是这样表名用途关键字段probes探针题库id, question, expect_keywords, expect_urls, categoryruns采样批次id, run_time, model_name, statusanswers原始回答id, run_id, probe_id, raw_text, latency_mshits命中判定结果id, answer_id, hit_keyword, hit_url, is_accurate这个设计的好处是原始回答和判定结果分离。判定规则以后可能会改但原始回答必须原样保留否则历史数据就没法重新分析了。我踩过一个坑早期把判定结果直接写进answers表后来想调整关键词匹配逻辑发现历史数据全废了只能重跑。从那以后我坚持原始层不可变分析层可重建。2.4 采样频率与调度策略82道题乘以多个AI产品如果每道题都实时问一遍一轮下来要几个小时。我的策略是分片采样把82道题按类别分成若干组每天只跑一组一周覆盖全部。这样既降低了单次运行时长也避免了对AI产品的高频请求触发风控。调度用的是最朴素的方案——系统自带的定时任务加一个Python入口脚本。没有上Airflow这类重型调度因为个人项目没必要一个crontab或者Windows计划任务就够了。关键是脚本要能处理上一次没跑完的情况我加了一个运行锁文件防止任务重叠。3. 探针题库的设计与命中判定逻辑3.1 一道合格的探针题长什么样探针题不是随便问你知道XX网站吗那样太直白模型容易敷衍。好的探针题应该模拟真实用户的提问场景让模型在自然回答中暴露它是否真的了解你的内容。我总结了几种题型。第一种是事实型比如Python里用asyncio做并发请求怎么控制最大并发数如果模型提到我某篇文章里的具体方案就算命中。第二种是对比型比如Playwright和Selenium在等待机制上有什么区别这类问题容易引出具体技术细节命中判定更精准。第三种是场景型比如我想给个人博客做自动化监测有什么开源方案这种问题模型往往会推荐具体工具和文章。每道题我都标注了三个字段expect_keywords期望出现的关键词、expect_urls期望引用的页面路径、category所属主题分类。判定时只要回答里出现了期望关键词或URL就记为一次命中。3.2 命中判定为什么要做模糊匹配一开始我用的是精确字符串匹配结果命中率低得离谱。原因是模型复述你的内容时措辞几乎不可能和你原文一模一样。比如我原文写的是用信号量控制并发模型可能说成通过Semaphore限制同时运行的任务数。后来我改成了关键词集合 模糊匹配的组合策略。具体做法是把期望关键词拆成核心词和修饰词核心词必须出现修饰词出现任意一个即可。同时用编辑距离做容错允许一定程度的拼写差异。对于URL我做了归一化处理去掉协议头和末尾斜杠再比对。提示模糊匹配的阈值不要设太松否则会把泛泛提到类似概念误判成引用了你的内容。我的经验是核心词必须精确命中修饰词才允许模糊。3.3 82道题是怎么分布出来的82这个数字不是拍脑袋定的是我按站点内容结构反推出来的。我的博客大致分几个板块Python基础、爬虫与自动化、AI工具实践、个人项目复盘。每个板块下我挑了15到25个高频问题加起来凑成82道。分布上我刻意做了倾斜爬虫与自动化占的比重最大因为这正是我站点最有辨识度的内容也是最容易被AI引用的部分。而个人项目复盘类的问题命中率天然低因为这类内容太个性化模型很难从训练数据里学到。保留它们是为了观察哪些类型的内容更容易被AI记住这个对比本身就有价值。3.4 探针题的版本管理探针题会随着站点内容更新而调整所以我给题库加了版本号。每次修改题目或判定规则就升一个版本采样结果里记录用的是哪个版本。这样在做时间序列对比时可以排除因为改了题目导致命中率变化的干扰。这个细节看起来小但实际分析时特别重要。我有一次发现某类问题命中率突然掉了20%排查半天才发现是那周我调整了判定关键词把标准收紧了跟AI本身没关系。4. 用Playwright实现多AI产品自动化采样4.1 环境准备与依赖安装先把基础环境搭起来。Python建议3.10以上Playwright对版本有一定要求。python -m venv venv source venv/bin/activate # Windows用 venv\Scripts\activate pip install playwright playwright install chromium这里有个热词里经常被问到的坑npx playwright install失败。如果你用的是Python版Playwright根本不需要npx直接用playwright install命令即可。npx是Node.js生态的东西两者别搞混。如果下载浏览器失败通常是网络问题可以设置镜像环境变量后重试。# 设置下载镜像示例具体地址以官方文档为准 export PLAYWRIGHT_DOWNLOAD_HOST镜像地址 playwright install chromium依赖方面我额外装了beautifulsoup4做HTML清洗jieba做中文分词辅助关键词匹配pandas做结果聚合。这些都是常规库pip install即可。4.2 登录态维持的三种方案对比AI产品基本都要登录才能用登录态维持是自动化的第一道坎。我试过三种方案各有取舍。方案做法优点缺点持久化上下文用launch_persistent_context指定用户数据目录一次登录长期有效目录被占用时无法并发保存storage_state登录后导出cookie和localStorage可复用、可并发过期需重新导出每次重新登录脚本里模拟输入账号密码最稳定慢且易触发风控我最终选的是storage_state方案。做法是手动登录一次然后把上下文状态导出成JSON文件后续每次采样都加载这个文件。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context(storage_stateauth/ai_a.json) page context.new_page() page.goto(https://example-ai-site.com/chat) # 后续操作注意storage_state里的cookie有有效期一般几天到几周不等。我加了一个检测逻辑如果页面跳转到登录页就发通知提醒我手动重新导出。别指望它能永久有效。4.3 提问与流式回答抓取的核心逻辑这是整个项目最核心的部分。AI回答是流式输出的你不能goto完就立刻抓文本得等它输出完。我的做法是监听回答容器的文本变化当文本在若干秒内不再增长时判定为输出结束。import time def ask_and_wait(page, question, answer_selector, timeout120, idle5): # 定位输入框并输入问题 input_box page.locator(textarea).first input_box.fill(question) input_box.press(Enter) # 等待回答容器出现 answer_el page.locator(answer_selector).last answer_el.wait_for(statevisible, timeouttimeout * 1000) last_text stable_count 0 start time.time() while time.time() - start timeout: current answer_el.inner_text() if current last_text and current.strip(): stable_count 1 if stable_count idle: break else: stable_count 0 last_text current time.sleep(1) return last_text这段逻辑的关键在idle参数——文本连续5秒不变才认为输出结束。设太小会截断长回答设太大浪费时间。我实测5秒是个比较稳的值但不同产品响应速度不一样需要分别调。4.4 多AI产品并行采样的调度如果串行跑82道题乘以N个产品时间会很长。我用concurrent.futures做了简单的并行每个AI产品一个独立的browser context互不干扰。from concurrent.futures import ThreadPoolExecutor def sample_one_model(model_config, probes): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context(storage_statemodel_config[auth]) page context.new_page() results [] for probe in probes: text ask_and_wait(page, probe[question], model_config[selector]) results.append({probe_id: probe[id], raw_text: text}) browser.close() return results with ThreadPoolExecutor(max_workers3) as executor: futures [executor.submit(sample_one_model, cfg, probes) for cfg in model_configs] for f in futures: save_results(f.result())提示并行数别开太高。一是本地资源有限二是同时向多个AI产品高频请求容易触发风控。我一般控制在3到4个并发。4.5 反自动化检测的应对思路这块要谨慎讲我只说通用的、合规的工程思路不涉及任何绕过安全机制的手段。AI产品普遍会检测自动化行为常见的信号包括无头浏览器特征、鼠标轨迹缺失、请求频率异常、WebDriver标志位等。我的应对原则是让自动化行为尽量接近真人而不是去对抗检测。具体做法一是用headlessFalse加虚拟显示很多产品对无头模式更敏感二是输入问题时模拟逐字输入而不是一次性fill加随机延迟三是每道题之间随机等待几秒到几十秒模拟真人思考节奏四是控制单账号的日请求量别一天问几百遍。import random def human_type(locator, text): for ch in text: locator.type(ch, delayrandom.randint(50, 150)) time.sleep(random.uniform(0.5, 1.5))这些手段的本质是降低请求的机器味而不是破解什么。如果某个产品明确禁止自动化访问那就应该尊重它的规则改用官方API或放弃该渠道。这一点我在项目里写得很清楚只对允许自动化访问的渠道做采样遇到明确禁止的就移除。5. 结果分析、可视化与常见问题排查5.1 从原始回答到可见性得分采样回来的原始文本不能直接看得先做清洗和判定。清洗包括去掉markdown标记、去掉引用块、统一标点。然后跑命中判定把结果写进hits表。可见性得分的计算我用了加权方式命中核心关键词得1分命中期望URL得2分因为引用具体页面比泛泛提及更有价值描述准确额外加1分。每道题的满分是4分把所有题的得分加起来除以满分就是这一轮的可见性得分。def calc_score(hits, total_probes): score 0 for h in hits: if h[hit_keyword]: score 1 if h[hit_url]: score 2 if h[is_accurate]: score 1 return score / (total_probes * 4)这个公式不是标准答案你可以根据自己的关注点调整权重。关键是权重一旦定了就别频繁改否则时间序列就没意义了。5.2 用pandas做时间序列对比有了每天一轮的得分就可以做趋势分析了。我用pandas把数据读出来按日期聚合看整体得分走势也看分类得分的差异。import pandas as pd df pd.read_sql(SELECT * FROM hits JOIN runs ON hits.run_id runs.id, conn) df[date] pd.to_datetime(df[run_time]).dt.date daily df.groupby(date)[score].sum().reset_index() print(daily.tail(30))我特别关注两个指标一是整体得分的周环比二是单题命中率的突变。整体得分缓慢上升是正常的说明内容在慢慢被模型吸收但如果某道题命中率突然从80%掉到20%那就要警惕了可能是模型更新了也可能是我的页面改版导致内容结构变了。5.3 常见问题速查表跑这套系统大半年遇到的问题基本集中在下面几类。我整理成表格方便你对照排查。现象可能原因排查方向解决思路回答抓取为空选择器失效页面改版导致DOM结构变化用CDP看实际DOM更新selector回答被截断idle阈值太小长回答输出间隔超过阈值调大idle或改用停止生成按钮状态判断频繁跳登录页storage_state过期cookie失效重新导出状态加过期检测请求被限流频率过高单账号请求太密集降低并发加随机延迟命中率异常波动判定规则改动关键词或阈值变了检查探针版本号对比历史规则浏览器启动失败依赖缺失系统库不全重装playwright浏览器补系统依赖5.4 几个我踩过的坑和独家经验第一个坑是时区问题。我服务器用的是UTC但AI产品的回答里偶尔会带时间信息导致我一度以为采样时间错乱。后来统一在入库时转成本地时区问题消失。第二个坑是回答里的markdown污染。模型输出经常带**加粗**、###标题这类标记直接做关键词匹配会漏判。我的做法是先做一轮markdown清洗把标记去掉再匹配。但要注意清洗不能太激进否则会把URL也洗掉。第三个经验是保留原始HTML。我一开始只存纯文本后来发现有些判定需要看链接的href属性纯文本里链接和普通文字混在一起分不清。现在我同时存纯文本和原始HTML分析时按需取用。第四个经验是给采样加健康检查。每轮采样开始前先问一个已知答案的简单问题确认模型能正常响应、抓取逻辑正常再开始正式采样。这样能避免因为登录失效导致整轮数据全是空的尴尬。5.5 这套系统还能怎么扩展目前这套东西只做了监测其实还能往优化方向走。比如把命中率低的探针题对应的页面找出来分析是不是内容结构不利于AI理解——标题不够明确、缺少结构化数据、关键结论埋在长段落里。这些都是可以针对性改进的点。另一个扩展方向是多模型对比。同一个问题问不同AI产品看谁更了解你的站这个对比数据本身就很有意思也能帮你判断内容应该优先适配哪个渠道。我个人在实际操作中的体会是AI可见性这件事短期看是玄学长期看是内容质量的映射。模型愿不愿意引用你最终还是取决于你的内容是不是真的解决了问题、是不是有独到的经验。监测台只是把这件模糊的事情量化了让你知道该往哪个方向使劲。