做SEO十年我见过最大的范式变化不是移动端分流也不是语音搜索而是AI搜索结果开始自己生成答案。SGE这个词全称是Search Generative Experience对应到国内产品上就是我们现在常用的各类AI搜索、AI问答助手。用户在这些引擎里提问得到的不是十条蓝色链接而是一段聚合答案甚至直接排好了引用来源。“排名”这个概念还在但含义已经变了——你的品牌会不会出现在AI生成的那段话里出现在第几句有没有附带链接这些都是全新的排名维度。这篇保姆级教程我把从零搭建一套SGE排名探测Agent的完整过程写出来包括生成式引擎评测标注的维度设计、探测Agent的需求拆解与代码实现、以及AI搜索全域关键词布局的落地打法。适合三类人做SEO想转型AI搜索优化的做品牌数字资产管理的以及想搞清楚AI搜索流量到底如何分发的产品经理。我会把每个环节的“为什么”也讲清楚方便你迁移到自己的业务场景里。1. 内容整体设计与思路拆解1.1 AI搜索时代的排名定义变了先说背景。过去Google、百度页面上的排名是一套相对稳定的秩序爬虫收录了哪些页面关键词在第几页第几位基本都是可查可证的。SGE这类生成式引擎出现之后答案不是从索引里直接取出来的某条结果而是由大模型根据检索回来的多篇资料“归纳生成”的。这意味着两个关键变化第一排名从“稳定”变成“概率”。同一个问题今天问和明天问生成的内容可能有措辞变化你的品牌可能这次出现在第二位下次直接消失不见。第二排名从“页面”变成“语义实体”。传统SEO优化的是URLAI搜索认的是品牌名、产品名以及围绕这个实体的一致性信息。所以做SGE排名探测本质上是在做一件事持续观测一个“概率性答案空间”里你的品牌被看见的频次和位置。这不是传统SEO顺手能做的事而是需要专门设计一套可重复、可量化、可对比的观测系统。我自己踩过的一个坑就是拿传统关键词排名工具去套AI搜索结果发现数据毫无意义因为生成式答案根本没有“稳定排名第几”这个字段。1.2 生成式引擎评测标注的基本逻辑所谓评测标注就是把AI回答这种“非结构化文本”转化为“结构化指标”。核心难点在于AI回答的形态很不固定可能是一段话、一个编号列表、一段对比表格甚至带Markdown链接。所以评测标注体系必须落在几个可控的锚点上问题库固定探测什么问题、以什么问法问都要先定义清楚避免数据清洗时才发现口径不一致。探测动作固定同一问题同一天探测多少次、间隔多久、在哪些引擎上探测全部由调度系统统一执行。标注规则固定什么算“命中”、什么算“来源”、怎么给位置打分都要先写进标注规范。我把这套逻辑总结成一句话SGE评测标注的目标不是测量某次生成的成败而是测量一段时间内“品牌可见度”的概率分布。你把这个思维转过来之后标注体系的每个字段设计就都顺了。1.3 为什么用Agent架构而不是普通脚本普通抓取脚本也能完成“发请求→收回答→匹配关键词”但SGE探测的真实场景是“多问题×多引擎×多时间片”的矩阵任务这已经超出简单脚本的能力边界。所以我用的是Agent架构——不是非要上LangChain、Dify、CrewAI这种重型框架而是把一个探测Agent拆成职责清晰的五个模块问题样本层Question Pool维护关键词库和问法库。调度层Scheduler控制探测节奏、并发数量、异常重试。引擎适配层Engine Adapter统一封装不同AI搜索平台的调用差异。解析标注层Parser Annotator把原始回答转成结构化标注。存储展示层Storage Dashboard落库、汇总、可视化。这两年Agent Anywhere的概念很火但我建议你在没有跑通数据闭环之前不要一上来就套重型框架。把上述五层用轻量脚本实现反而更容易看清每一步的卡点。这样的好处是任何一层出问题都只影响小范围。比如某个引擎改版导致返回结构变化我只需要改适配层问题库和标注逻辑完全不用动。这也正是Agent开发里常说的“职责单一、编排清晰”而不是把所有动作揉在一个脚本里。2. 核心细节解析与实操要点2.1 探测目标的拆解动手搭建之前先要做一个动作把“我想看品牌在AI搜索里表现怎么样”拆成可执行的目标。我的经验是先列四类目标品牌阵地词品牌名、产品名、官网域名出现的位置与方式。品类机会词用户问“XX类产品哪个好”时你的品牌是否出现、和谁对比。场景长尾词结合使用场景的细节问题比如“办公室用的小型咖啡机怎么选”。竞品对比词用户直接拿你和一个竞品对比时AI的态度倾向。每类目标对应不同的内容策略后面做关键词布局时直接复用这套分类。如果你不清楚怎么拆可以先从用户调研、客服记录、电商评论区里捞一批真实问法把这些问法归到上面四类里再决定每个类的优先级。2.2 关键词样本体系的搭建先别急着写代码把问题库建好再说。问题库是整个探测系统的“输入质量”所在问题样本选不好后面标注再严谨也白搭。我的建议是分三层建第一层是核心词建议20个左右都是品牌名直接组合的强相关问题用来守护基本盘。第二层是品类词建议50个以上覆盖用户提问量最大的场景。第三层是长尾与比较类问题建议100到200个这部分才是真正能拿到增量信息的地方也是竞对最容易忽略的阵地区。建样本时有几个反直觉的注意点不要只选“目标用户一定会问”的问题要混入一些“我们其实不擅长但用户认为我们相关”的问题因为AI搜索的价值就在于暴露认知偏差。不要所有问题都太“干净”稍微口语化的问法反而更接近真实输入。建议每月做一次问题库快照归档方便以后回溯数据变化。2.3 评测标注规则与评分体系标注规则是整个系统的“宪法”。没有它A同学和B同学写的代码解析出来的数据对不上。我实际用下来觉得以下字段是必选项字段说明取值示例task_id单次探测任务唯一IDprobe_20250106_001engine引擎标识ai_search_a / ai_search_bquestion原始问题句小型咖啡机怎么选brand_name目标品牌实体某品牌mentioned是否被提及1/0mention_position首次提及在第几个答案块2从1计数source_url回答中是否附带链接url或空值sentiment态度倾向推荐/中性/对比/缺失probe_time探测时间戳2025-01-06 09:31:22generation_id引擎返回的生成批号用于去重评分环节我用一个可直接落地的公式SGE可见度得分 命中率 × 位置权重 × 态度权重。命中率就是N次探测中被提及的比例位置权重按首次提及的答案块序号衰减第一块取1.0第二块取0.7第三块取0.5四块及以后取0.3态度权重推荐1.2、中性1.0、对比0.7、负面0.3。这套权重不需要一开始就完美建议先跑两周根据业务反馈再调。为了确保稳定性我要求同一个问题在一天内至少探测3次取中位数作为当天的可见度记录避免单次生成随机性带来的误判。这个“三测取中”的习惯几乎是我做SGE评测半年多来最重要的一个细节。3. 实操过程与核心环节实现3.1 探测Agent的核心代码骨架现在讲实现。我不会用很重的Agent框架先给出一个轻量可靠的骨架你跑通后可以再往LangChain、Dify上迁移。核心思想是“适配层隔离引擎差异”。请看这段核心代码from abc import ABC, abstractmethod from dataclasses import dataclass, asdict import time dataclass class RawProbeResult: engine: str question: str raw_text: str probe_time: float class EngineAdapter(ABC): abstractmethod def search(self, question: str) - str: 向引擎发起探测返回原始回答文本。 class ModernAIEngineAdapter(EngineAdapter): def __init__(self, engine_name, endpoint, api_key): self.engine_name engine_name self.endpoint endpoint self.api_key api_key def search(self, question: str) - str: # 真实项目中这里是对应引擎接口的调用 # response requests.post(endpoint, headers..., json{query: question}) # return response.json()[answer] time.sleep(1) return f模拟回答关于“{question}”推荐A品牌其次考虑B品牌。 def safe_probe(adapter: EngineAdapter, question: str): try: raw adapter.search(question) return RawProbeResult( engineadapter.engine_name, questionquestion, raw_textraw, probe_timetime.time() ) except Exception as exc: print(f[异常] {adapter.engine_name} 探测失败: {exc}) return None选择适配层这个设计最重要的原因是不同AI搜索平台的返回结构差异极大有的是纯文本有的是Markdown带链接有的是JSON格式的引用列表。假如你在每个探测任务里直接写死解析逻辑一旦某个平台改版你就要改所有历史代码。我用适配层之后新增一个引擎只需要写一个Adapter其余调度、解析、存储全部复用。3.2 引擎适配与原始结果落地真正落地的时候你会发现“原始回答文本”其实非常脏。我通常会先把原始回答原封不动存一份到本地JSONL文件再做解析。这一步千万别省因为解析规则可能会迭代原始数据留着你才能回放和重判。import json from pathlib import Path def dump_raw(result: RawProbeResult, path: str data/raw_probe.jsonl): line json.dumps(asdict(result), ensure_asciiFalse) with Path(path).open(a, encodingutf-8) as f: f.write(line \n)文件命名最好带上日期比如raw_probe_20250106.jsonl每天一个文件方便按日期回溯和分析。数据量不大不用一上来就上数据库先跑一个月再说后面量大了再迁移到PostgreSQL也不迟。3.3 解析标注与答案块定位原始回答拿到之后进入解析标注环节。这一步我的核心方法是“答案块拆分关键词回归”。先把回答文本按换行、序号、以及常见的有序列表标记拆成多个答案块再到每个答案块里搜索品牌名、产品名和官网域名记录第一次命中的答案块序号。贴一段实用的解析函数import re def split_answer_blocks(raw_text: str) - list[str]: # 先按分割符号粗拆再合并过短的行 parts re.split(r\n|;||\d[\.、)], raw_text) blocks [p.strip().rstrip(。) for p in parts if len(p.strip()) 6] return blocks def annotate(raw_text: str, brand_names: list[str]) - dict: blocks split_answer_blocks(raw_text) mentioned False first_pos 0 sentiment 中性 for idx, block in enumerate(blocks, start1): if any(b in block for b in brand_names): mentioned True first_pos idx # 简单的态度初判出现推荐/值得/首选视为推荐 if any(k in block for k in (推荐, 值得, 首选, 更好)): sentiment 推荐 elif any(k in block for k in (不建议, 缺点, 较差)): sentiment 负面 break return { mentioned: mentioned, first_mention_pos: first_pos, sentiment: sentiment, block_count: len(blocks) }这里只是初判真实项目里如果要做细我建议用正则做几轮迭代或者接入本地小模型做态度分类但初期这版已经够用了。3.4 调度并发与日用节奏调度逻辑要解决两件事并发和重试。并发方面我用Python标准库的ThreadPoolExecutor实现一个简单的批量探测器并发数先控制在8到16不要一上去就跑满容易被限流。重试方面探测失败的任务不要立刻重试而是记录到失败队列在下一轮固定时间补跑这样不会打乱正常节奏。from concurrent.futures import ThreadPoolExecutor, as_completed def run_batch(adapters: list[EngineAdapter], questions: list[str], concurrency: int 8): tasks [ (adapter, question) for adapter in adapters for question in questions ] results [] with ThreadPoolExecutor(max_workersconcurrency) as pool: futures {pool.submit(safe_probe, a, q): (a, q) for a, q in tasks} for future in as_completed(futures): res future.result() if res is not None: results.append(res) return results调度节奏上我的默认配置是每天三个时间片早间8点、午后14点、晚间22点。早间跑核心品牌词午后跑品类词和长尾词晚间全量补跑白天异常任务。这样既覆盖了用户提问高峰又给异常重试留了口子。4. 常见问题与排查技巧实录4.1 探测结果不稳定先查问题库再查引擎我跑了一个月以后发现最不稳定的因素其实不是AI引擎的随机性而是问题库本身有歧义。举个例子某品牌词命中率连续一周忽高忽低一半的探测回答里根本没提到品牌名。我排查之后发现问题出在一个样本上——那个问题有双重语义一个意思指向我们品牌另一个意思完全指向另一个行业。AI生成答案时经常按另一个意思回答品牌自然就“消失”了。所以第一个排查技巧如果你发现命中率明显异常先回看问题样本把歧义问题要么删掉要么改写不要急着怀疑引擎。我后来给每个问题都加了“意图标签”比如“购买意图/对比意图/了解意图”这样定位歧义问题就快很多。4.2 解析逻辑失效从硬匹配转向块级匹配经历过一次线上事故后我学会了不要对AI返回格式做过多假设。某次引擎改版把原本的“1.xx 2.xx”列表改成“xxyy”的加粗标题格式我原先的正则直接把所有答案块拆崩了标注数据全部错乱。排查下来发现根因是答案块拆分太依赖“序号换行”这种硬规则。后来我改成两层策略第一层用更宽松的分隔符粗拆第二层对粗拆出来的块再按块内长度和语义做合并。简单说就是“能分就分太碎就并”这样即使格式变化只要大结构还在就不会崩。这个改动之后解析稳定性从不到70%提升到了95%以上。4.3 并发过高触发限流还有一次我为了赶报告把并发数从16调到64结果跑了十分钟后大批任务开始超时引擎返回“请求过于频繁”之类的错误。这不是什么技术难题纯粹是操作教训AI搜索服务的响应比传统搜索引擎更消耗算力并发阈值远比你想象的低。我的经验是把并发数控制在8到24之间并且给每个任务加一个0.5秒到2秒之间的随机小延迟。这样做的好处不光是避免限流还让每天的探测结果分布更均匀减少同一时刻大量采样带来的系统性偏差。你要是实在有大批量需求就把任务拆到不同时段分段执行别挤在一个窗口里。5. AI搜索全域关键词布局从数据到策略5.1 关键词策略的核心变化探测数据跑起来之后最终要服务于关键词布局。AI搜索时代的词库从结构上就和传统词库不一样。传统SEO的词库是“词根-扩展词-长尾词”的漏斗结构但AI搜索认的是“问题-实体-意图”的网络关系。前者强调覆盖关键词的字符串后者强调覆盖用户的真实问法以及围绕这个问法形成的实体认知。我把词库重新分成三类品牌阵地词用来防守自己的品牌名、产品名、官网名品类机会词用来抢“行业通用需求”的推荐位置观点塑造词包括“哪个好”“值得买吗”“性价比高吗”这类直接影响购买决策的比较型问题。三类词的比例我建议品牌阵地词20%、品类机会词40%、观点塑造词40%因为AI搜索环境下后者决定了AI怎么描述你的品牌形象。5.2 内容适应性改造的三个实操方向写内容时不能再用“以前搜索引擎喜欢长文章投关键词”的思路了。AI生成答案需要从你的页面里抽取“确定性信息”所以内容要做三方面改造第一把核心回答做成FAQ块。页面里要有直接对仗问题句的问答结构不要绕来绕去。第二统一品牌知识表述。品牌名、产品全称、官网域名、核心卖点在站点内保持一致不要让AI从不同页面抽到互相矛盾的信息。第三维护权威来源。AI搜索在引用时更倾向有明确出处和作者的内容有条件的话给关键页面署名、注时间、留数据出处。我举一个前后对照的例子改版前某页面写“我们的咖啡机很好用很多用户都喜欢”改版后写成“XX品牌小型咖啡机型号A1功率800W适合1-2人办公室使用实测研磨时间约25秒支持一键清洗”。后者被AI回答引用的概率明显更高因为AI需要的不是形容词而是可引用的结构化事实。5.3 从探测到优化的完整闭环最后说闭环。探测系统如果只用来出报告价值会大打折扣。真正的用法是让数据回流到内容策略里。我跑通的标准流程是探测→标注→诊断→内容改造→再探测。具体来说命中率低的词看问题库覆盖是否不够补内容命中率正常但态度偏对比的强化差异化卖点表达来源链接缺失的检查是否有可被引用的权威页面。按这个闭环我建议你30天内这样安排第1到3天把问题库建好第4到7天跑通探测流水线和标注规则第8到30天每天固定跑探测每周出具一份品牌可见度周报根据周报更新内容策略。两个月后你回头看数据会比任何拍脑袋复盘都更清楚什么词有效什么内容被AI记住什么打法需要放弃。最后再分享一个小技巧。很多人会把问题库优先排满最商业化的词但我实测下来价值最高的反而不是这些词而是那些“用户真的会问、AI答案还不稳定”的中腰部问题因为答案不稳定就意味着你有机会去影响它。你优先去优化这类词赢面比抢头部词大得多。这套方法论不限于某个平台只要AI搜索还在迭代它就能帮你持续保持信息优势。我自己跑了大半年最大的感受是“SGE排名探测不是一次性项目而是一套持续运营的观测系统”——它的价值随着时间推移指数级上升因为你积累的是别人看不到的、品牌被AI理解的数据底账。