个人站长最怕的一件事不是服务器宕机也不是流量下滑而是某天你搜自己的品牌词发现首页全是别人的内容自己的站点连影子都找不到。更麻烦的是你根本不知道是哪个环节出了问题——是内容没被收录还是被收录了但排名掉了还是压根就没被抓取过。这套「AI 可见性监测台」就是为解决这个问题而生的用 82 道探针题每天自动去问各大 AI 搜索入口把我的站点在 AI 眼里到底可不可见这件事量化成可追踪的数据。整套系统基于 Python Playwright 搭建核心思路是把人工反复搜索的动作自动化再配合 CDP 协议做深度页面状态采集。适合有一定 Python 基础、想给自己的站点做长期可见性监控的独立开发者也适合想入门浏览器自动化采集的测试同学参考。1. 为什么个人网站需要一套自己的可见性监测1.1 传统 SEO 工具在 AI 搜索时代的盲区做站的人对传统 SEO 工具都不陌生关键词排名、收录量、外链数这些指标看板拉出来一大片。但这两年搜索入口的形态变了越来越多的用户不再只依赖传统搜索结果页而是直接向 AI 助手提问然后拿到一段整合后的回答。问题就出在这里传统 SEO 工具监测的是链接排名而 AI 回答里给的是内容引用这两套逻辑完全不是一回事。我自己的站点就遇到过这种情况传统工具显示关键词排名稳定在前三但去 AI 入口里问同样的问题回答里压根没提到我的站。原因很简单AI 回答的生成逻辑更看重内容的语义匹配度、结构化程度、以及是否被高质量来源交叉引用而不是单纯的关键词密度和外链数量。传统工具压根不采集 AI 回答这个维度所以你在它的看板上看到的一切正常实际上你在新的流量入口里可能已经隐形了。这就是为什么我决定自己搭一套监测台。市面上的工具要么太贵要么不开放 AI 回答采集这个能力要么就是采集频率低到没有参考价值。自己动手反而能把控每一个细节。1.2 82 道探针题是怎么设计出来的整套系统的核心是探针题这个概念。所谓探针题就是一组预先设计好的、覆盖站点核心主题的提问用来探测 AI 入口在回答相关问题时是否会引用或提及你的站点。82 这个数字不是拍脑袋定的而是经过几轮迭代收敛出来的。设计探针题有几个原则。第一是覆盖度要把站点的核心主题拆成若干子领域每个子领域至少 3 到 5 道题保证不会因为某个冷门话题没被覆盖而漏判。第二是区分度题目不能太宽泛比如什么是编程这种任何站都可能被引用也不能太窄比如直接搜你的品牌名那必然会出现没有监测意义。理想状态是中等热度 明确指向你的专业领域。第三是稳定性同一道题在不同时间问AI 回答的波动要可控否则数据噪声太大没法做趋势分析。我最初设计了 120 多道题跑了两周后发现其中 30 多道题的答案波动极大几乎每天都不一样这些题要么删掉要么降权处理。最后收敛到 82 道分成核心题30 道每天必跑、扩展题32 道隔天跑、长尾题20 道每周跑三档。下面是我实际使用的探针题分类结构供参考分类数量采集频率用途核心题30每日追踪核心主题的可见性趋势扩展题32隔日覆盖相邻领域发现新机会长尾题20每周监测长尾流量入口的变化1.3 监测台要回答的三个核心问题搭这套系统之前我先想清楚它到底要回答什么问题。想不清楚这个代码写出来也是一堆没用的数据。最终锁定三个问题第一个是可见性有没有也就是在 82 道题里有多少道题的 AI 回答中出现了我的站点。这个是最基础的指标反映的是整体覆盖情况。第二个是可见性稳不稳同一道题连续多天的结果是否一致波动大的题说明该领域的 AI 回答还不稳定可能是机会也可能是陷阱。第三个是可见性往哪走把时间维度拉长看整体趋势是上升还是下降哪个子领域的可见性在改善哪个在恶化。这三个问题对应三套数据视图覆盖率看板、稳定性分析、趋势曲线。后面所有的采集逻辑和数据处理都是围绕这三个问题展开的。想清楚这一点之后代码结构就清晰多了——采集层负责拿原始数据解析层负责判断是否可见存储层负责按时间序列落库展示层负责把三个问题可视化。2. Playwright 采集层的搭建与踩坑2.1 为什么选 Playwright 而不是 Selenium浏览器自动化框架的选择上我在 Selenium 和 Playwright 之间纠结过一阵。最后选 Playwright主要基于几个实际考量。第一是自动等待机制Playwright 内置了元素可见性、可点击性的智能等待写采集脚本时不用到处塞 sleep代码干净很多跑起来也更稳。Selenium 在这方面需要自己封装显式等待维护成本高。第二是多浏览器上下文隔离。监测台需要同时跑多个采集任务每个任务要有独立的 cookie、缓存、会话状态Playwright 的 browser context 机制天然支持这个开多个 context 互不干扰资源占用也比开多个浏览器实例低得多。第三是网络拦截能力Playwright 可以在请求层面做拦截和修改这对后面判断页面是否真正加载完成很关键。当然 Selenium 也有它的优势生态更成熟社区资料多遇到冷门问题更容易搜到答案。但就这个项目而言Playwright 的现代 API 设计确实让开发效率高了不少。安装上就是标准的 pip 流程pip install playwright playwright install chromium这里有个坑要提前说playwright install下载浏览器二进制文件时如果网络环境不稳定很容易卡住或者失败。我的做法是配置国内镜像源或者提前把浏览器包下载好放到缓存目录。另外playwright install默认装所有浏览器实际只需要 chromium 的话指定一下能省不少时间和磁盘空间。2.2 采集任务的并发模型设计82 道题如果串行跑每道题平均耗时 15 到 30 秒包括页面加载、输入、等待回答生成一轮下来要 20 到 40 分钟。这个时间对于每日任务来说勉强能接受但如果想提高频率或者增加题目就扛不住了。所以并发是必须的。我的并发模型是这样的用 asyncio 做异步调度每个采集任务是一个协程同时最多跑 5 个任务。为什么是 5 个因为再高的话目标站点的反爬机制容易触发而且本机内存和 CPU 也会吃紧。5 个是一个实测下来比较稳的平衡点。每个任务内部用 Playwright 的 async API 创建一个独立的 browser context这样每个任务的 cookie 和会话都是隔离的。任务完成后 context 关闭资源释放。这里要注意的是browser 实例本身是共享的不要每个任务都去 launch 一个新 browser那样开销太大。正确的做法是全局维护一个 browser 实例每个任务从它那里 new 一个 context。import asyncio from playwright.async_api import async_playwright async def run_probe(browser, question): context await browser.new_context() page await context.new_page() try: # 采集逻辑 result await collect(page, question) return result finally: await context.close() async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessTrue) semaphore asyncio.Semaphore(5) async def limited(q): async with semaphore: return await run_probe(browser, q) tasks [limited(q) for q in questions] results await asyncio.gather(*tasks) await browser.close()这个 semaphore 控制并发的写法很实用比手动维护任务队列简单得多。实测下来5 并发跑 82 道题一轮大概 6 到 8 分钟效率提升明显。2.3 页面加载完成的判断标准采集里最容易出问题的地方就是什么时候算加载完成。如果判断早了AI 回答还没生成完采到的是空内容判断晚了浪费时间还可能触发超时。我试过几种方案最后用的是组合判断。第一种是等特定元素出现比如回答区域的容器元素。这个最直接但问题是不同 AI 入口的 DOM 结构不一样而且它们改版频繁选择器容易失效。第二种是等网络空闲Playwright 的wait_for_load_state(networkidle)可以做到但 AI 回答是流式生成的网络请求可能一直不断networkidle 永远等不到。最后我的方案是元素出现 内容稳定双重判断先等回答容器元素出现然后每隔 500 毫秒检查一次容器内的文本长度连续三次长度不变就认为生成结束。这个逻辑虽然土但实测最稳不受 DOM 改版和流式生成的影响。async def wait_for_answer(page, selector, timeout60): await page.wait_for_selector(selector, timeouttimeout * 1000) last_len 0 stable_count 0 start time.time() while time.time() - start timeout: text await page.inner_text(selector) if len(text) last_len and len(text) 0: stable_count 1 if stable_count 3: return text else: stable_count 0 last_len len(text) await asyncio.sleep(0.5) return await page.inner_text(selector)注意这个稳定判断的阈值3 次、500 毫秒是我根据实际网络情况调的如果你的网络延迟高可以适当放宽否则容易误判为已稳定而采到半截内容。3. CDP 协议在深度采集里的实际用法3.1 CDP 能拿到 Playwright 高层 API 拿不到的东西Playwright 的高层 API 已经很好用了但有些底层信息它不直接暴露这时候就要用 CDPChrome DevTools Protocol。CDP 是浏览器内核提供的调试协议Playwright 本身也是通过它跟浏览器通信的所以我们可以直接发 CDP 命令拿到更细的数据。在这个项目里我用 CDP 主要做三件事。第一是拿网络请求的完整记录包括每个请求的响应状态、耗时、大小用来分析 AI 入口在生成回答时到底请求了哪些接口。第二是拿页面的性能指标比如首次内容绘制、DOM 完成时间用来判断采集时机是否合理。第三是模拟更真实的用户行为比如通过 CDP 设置设备指纹、地理位置让采集请求看起来更像真实用户。获取 CDP session 的方式很简单cdp await context.new_cdp_session(page) await cdp.send(Network.enable)开启 Network 域之后就能监听所有网络事件了。这个能力在排查为什么某道题采不到回答时特别有用——你能看到底是哪个请求失败了是超时还是被拦截。3.2 用 CDP 监听网络请求判断回答是否真正生成前面说的文本长度稳定判断其实还有个隐患有些 AI 入口会先返回一个占位文本然后再替换成真正的回答。这种情况下文本长度可能在占位阶段就稳定了导致采到错误内容。用 CDP 监听网络请求可以规避这个问题。具体做法是监听回答生成相关的 API 请求等这个请求的响应完整返回后再去做文本提取。不同入口的 API 路径不一样需要先抓包分析。我一般会先手动跑一次用 CDP 把所有请求 URL 打出来找到那个返回回答内容的接口然后在代码里针对性地等它。answer_received asyncio.Event() def on_response(params): url params.get(response, {}).get(url, ) if answer in url or completion in url: answer_received.set() cdp.on(Network.responseReceived, on_response) # 触发提问后 await asyncio.wait_for(answer_received.wait(), timeout60)这个方案比纯文本判断更可靠但维护成本也更高因为 API 路径会变。我的做法是把它作为辅助判断和文本稳定判断结合使用两者都满足才认为采集完成。3.3 反检测让采集请求看起来像真实用户做采集绕不开反检测这个话题。目标站点会通过各种信号判断你是不是机器人比如 navigator.webdriver 属性、浏览器指纹、行为模式等。Playwright 默认启动的浏览器navigator.webdriver 是 true这个很容易被识别。我的处理方式分几层。第一层是启动参数加上--disable-blink-featuresAutomationControlled这个能去掉大部分明显的自动化特征。第二层是用 CDP 注入脚本在页面加载前修改 navigator.webdriver 等属性。第三层是行为模拟输入问题的时候不要一次性填完而是模拟逐字输入中间加随机延迟。await context.add_init_script( Object.defineProperty(navigator, webdriver, { get: () undefined }); )行为模拟这块逐字输入的实现async def type_like_human(page, selector, text): await page.click(selector) for char in text: await page.type(selector, char, delayrandom.randint(50, 150))提示反检测是个持续对抗的过程没有一劳永逸的方案。我的建议是控制采集频率不要短时间内高频请求同一入口这比任何技术手段都有效。另外采集到的数据仅用于自己站点的可见性分析不要用于其他用途。4. 数据解析怎么判断AI 回答里有没有我的站4.1 从原始回答文本里提取站点提及采集拿到的是 AI 回答的原始文本接下来要判断这段文本里有没有提到我的站点。最直接的方法是字符串匹配搜站点域名、品牌名、核心关键词。但实际做下来纯字符串匹配的误判率不低。误判主要来自两种情况。一种是同名不同站比如你的品牌名是个常见词AI 回答里提到这个词但指的不是你的站。另一种是变体匹配AI 可能用你的品牌简称、或者带后缀的写法纯匹配主域名会漏掉。我的解决方案是维护一个站点标识词库包含主域名、品牌全称、品牌简称、常见变体然后对每个标识词做匹配同时记录匹配到的上下文人工抽检时能快速判断是否误判。SITE_IDENTIFIERS [ example.com, 示例站点, 示例站, ] def check_mention(text): hits [] for ident in SITE_IDENTIFIERS: idx text.find(ident) if idx ! -1: context text[max(0, idx-50):idx50] hits.append({identifier: ident, context: context}) return hits4.2 提及位置和上下文权重的计算光判断有没有提到还不够还要判断提得重不重要。AI 回答里你的站出现在开头第一句和出现在最后一句的相关推荐里价值完全不一样。所以我给每次提及算一个权重分。权重的计算维度有几个位置越靠前权重越高、上下文是否在正面描述里、是否带链接带链接的提及价值更高、提及次数多次提及加权。这套权重算法没有标准答案我是根据自己的业务理解调的核心是让高质量提及和低质量提及在数据上能区分开。维度权重系数说明位置靠前1.5出现在回答前 30% 区域带链接2.0提及处附带可点击链接正面上下文1.3上下文为推荐、肯定语气多次提及每次 0.2同一回答内重复出现最终每道题的可见性得分 基础分是否提及× 权重系数。这样算下来一道题的最高分可能是 5 分左右最低 0 分。把 82 道题的得分加总就是当天的整体可见性指数。4.3 处理提到了但没链接的中间态实际数据里有一大类是提到了但没链接这种中间态最让人纠结。它说明 AI 知道你的站但没把你作为推荐来源。这种情况可能是内容质量够但权威性不足也可能是 AI 的回答策略就是不给链接。我的处理是把这类提及单独统计不和带链接提及混在一起。因为这两种状态的优化方向完全不同带链接提及要维持没链接提及要争取升级。在数据看板上我用两种颜色区分一眼就能看出哪些领域是有认知无推荐哪些是既有认知又有推荐。这个区分对内容策略的指导意义很大。比如我发现某个子领域有大量没链接提及说明我的内容在这个领域已经被 AI 认可了接下来要做的就是加强这个领域内容的权威信号争取把提及升级成带链接的推荐。5. 数据存储与趋势分析5.1 用 SQLite 做时间序列存储的取舍数据存储上我选了 SQLite。有人会问为什么不用 MySQL 或者时序数据库理由很简单这个项目的数据量不大每天 82 条记录一年也就 3 万条SQLite 完全扛得住而且零配置、单文件、方便备份。用 MySQL 反而要维护一个服务得不偿失。表结构设计上核心是一张采集结果表字段包括采集时间、题目 ID、题目内容、是否提及、提及次数、权重得分、原始回答文本。原始回答文本单独存方便后续回溯分析。另外还有一张题目表存 82 道题的元信息包括分类、频率、权重。CREATE TABLE probe_results ( id INTEGER PRIMARY KEY AUTOINCREMENT, probe_date TEXT NOT NULL, probe_id INTEGER NOT NULL, mentioned INTEGER DEFAULT 0, mention_count INTEGER DEFAULT 0, weight_score REAL DEFAULT 0, raw_answer TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP );注意原始回答文本可能很长SQLite 存大文本没问题但查询时要注意不要 SELECT *只取需要的字段否则数据量上来后查询会变慢。5.2 可见性指数的计算与平滑前面提到每道题有个权重得分把 82 道题的得分加总再除以满分82 × 5就得到当天的可见性指数范围 0 到 1。这个指数是核心指标但直接用原始值做趋势图会很抖因为 AI 回答本身有随机性。所以要做平滑处理。我用的是 7 天移动平均把每天的原始指数和过去 6 天的值平均一下。这样趋势线会平滑很多能看出真实的走向而不是被单日波动干扰。移动平均的窗口大小可以调7 天是我试下来比较合适的既能反映趋势又不会太滞后。def moving_average(series, window7): result [] for i in range(len(series)): start max(0, i - window 1) window_data series[start:i1] result.append(sum(window_data) / len(window_data)) return result除了整体指数我还按题目分类算了子指数这样能看出是哪个领域在拖后腿。比如核心题指数稳定但长尾题指数下滑说明长尾内容的可见性在恶化需要针对性优化。5.3 异常波动的自动告警数据每天跑不可能天天盯着看。所以我加了一个异常告警机制当某天的可见性指数相比 7 天移动平均偏离超过阈值我设的是 20%就触发告警发一封邮件或者写一条日志。告警的触发逻辑要小心设计避免误报。单日波动可能是正常的随机性所以我加了确认机制连续两天偏离才告警单日偏离只记录不告警。这样能过滤掉大部分噪声。def check_anomaly(today_index, ma7, threshold0.2): if ma7 0: return False deviation abs(today_index - ma7) / ma7 return deviation threshold实测下来这个告警机制帮我抓到过几次真实的问题。有一次是某个 AI 入口改版导致采集脚本失效数据全是 0告警及时提醒了我。还有一次是站点被某个入口降权可见性指数连续下滑告警让我第一时间发现了趋势。6. 跑起来之后发现的几个真实问题6.1 采集频率和反爬的平衡系统跑起来第一周我就遇到了反爬问题。因为 82 道题并发跑短时间内对同一入口发起了大量请求触发了频率限制部分请求返回空结果或者验证码页面。这个问题很典型采集系统都绕不开。我的解决方案是三个层面。第一是降低并发从 5 降到 3牺牲一点速度换稳定性。第二是加随机延迟每个任务开始前随机等 1 到 3 秒打散请求时间。第三是分散入口如果监测多个 AI 入口不要在同一时间集中请求同一个入口而是错开时间。调整之后采集成功率从 70% 左右提升到了 95% 以上。这个经验说明采集系统的稳定性往往不取决于技术多先进而取决于你有没有尊重目标站点的负载能力。6.2 回答内容格式变化导致的解析失败AI 入口的回答格式不是一成不变的有时候会加个以下是相关回答的前缀有时候会把链接放在不同的位置。这些变化会导致解析逻辑失效采到的数据要么是空的要么是错的。应对这个问题我的做法是解析逻辑尽量宽松不要依赖精确的格式匹配。比如提取回答文本时不要指定具体的 DOM 路径而是找包含回答内容的最近容器。判断是否提及时用模糊匹配而不是精确匹配。另外加一个数据质量检查如果某天的采集结果里空值比例超过 30%就标记为异常人工介入检查。def quality_check(results): empty_count sum(1 for r in results if not r.get(raw_answer)) if empty_count / len(results) 0.3: return False # 数据质量异常 return True6.3 数据积累到一定量级后的分析思路系统跑了三个月积累了近万条数据。这时候单纯看每日指数已经不够了需要更深层的分析。我开始做几件事一是按题目维度看长期趋势找出哪些题的可见性在持续改善哪些在恶化二是做题目之间的相关性分析看哪些领域的可见性变化是同步的三是把可见性数据和站点的内容更新记录做关联看内容更新对可见性的影响。这些分析帮我发现了不少有意思的规律。比如内容更新后的 3 到 7 天相关题目的可见性会有明显提升但两周后会回落说明 AI 对新鲜内容有偏好但需要持续更新才能维持。又比如某些领域的可见性提升会带动相邻领域说明 AI 的知识图谱里这些领域是关联的。这些规律没法从单日数据里看出来只有积累到一定量级、做时间序列分析才能发现。这也是我坚持自己搭监测台而不是用现成工具的原因——数据在自己手里想怎么分析就怎么分析。7. 给想复刻这套系统的朋友几点实操建议如果你也想给自己的站点搭一套类似的监测台有几个点我想提前说。第一是从小规模开始不要一上来就设计 82 道题先跑 10 道核心题把采集、解析、存储、展示的链路跑通再逐步扩展。我最初就是 10 道题起步的链路跑通后才慢慢加到 82 道。第二是把采集和解析解耦。采集层只负责拿原始数据解析层负责判断和打分两层之间用原始文本做接口。这样解析逻辑改了不用重新采集采集逻辑改了历史数据还能用新解析逻辑重新处理。这个设计在后期迭代时省了我大量时间。第三是重视数据质量而不是数据量。82 道题里如果有 20 道题的数据质量很差那不如砍到 62 道题但每道都可靠。我现在的做法是每道题都有质量标记质量差的题在分析时降权或者排除。第四是做好异常处理。采集系统跑久了什么奇怪的情况都会遇到页面加载超时、元素找不到、网络中断、目标站点改版。每个环节都要有 try-except 和重试机制单次失败不要影响整体任务。我的做法是每个任务最多重试 2 次重试还失败就记录失败原因继续跑下一道题最后统一汇总失败列表。最后分享一个我在实际使用中体会很深的小技巧把采集时间固定在每天的同一时段。因为 AI 回答的质量和稳定性可能跟时段有关比如高峰期响应慢、回答质量波动固定时段能让数据更有可比性。我选的是每天凌晨 3 点跑这个时段网络稳定目标站点负载低采集成功率最高。