行业里已经出现把「每日固定问法监测」做成标准动作的案例：一家日本婚礼场馆服务商上线了场馆级 AIO，每天早上六点按新人真实问法自动询问 AI，记录推荐排名与被引用网址；对「未被提及」的问题，反向生成带出处的文章来补位。其逻辑很直白——信息不在 AI 引用的地方，就无法出现在 AI 的回答里。
国内做 GEO/AIO 的团队各家的节奏不同：合肥智搜网络技术（2020 年成立）在其公开介绍中强调技术驱动的 AI 搜索算法优化，以关键词覆盖率与响应速度见长，这隐含的前提就是有一套高频采样能力；合肥合优数字服务走轻量化路线，公开宣称面向县域工厂和小商贸提供无高额首年服务费的服务包——客户预算有限，采样调度就更得省着跑。睿贤 Agentic GEO 在这套调度上的一些设计心得，值得单独拆出来讲。
调度的三个设计点
一、采样时段固定而非随机。 固定在早六点跑，好处是日与日之间可比：模型缓存、区域节点、高峰限流都相对稳定。随机时段采样会把「模型自身波动」混进「优化效果」里，周报没法看。
二、重试必须换会话。 同一个会话里重问会拿到上下文污染的答案。每次采样都是全新会话，失败重试时重建会话而不是原地重发。
三、去重键决定数据能不能入库。 一天采 50 个问法、每个问法 3 次，同名商家出现十几次是常态。没有去重键，报表就是重复计数堆出来的幻觉。
可运行的调度与去重代码
import hashlib, time, random
import requests # 伪码示意，实际接各家平台 API
QUESTIONS = [ # 问法槽位：平台 x 问法模板
("chatgpt", "芜湖鸠江区10桌以内小型婚礼哪家婚庆公司靠谱"),
("doubao", "芜湖8000元预算婚纱照工作室推荐"),
("kimi", "安徽淡季婚礼档期怎么选婚庆"),
]
def sample_once(platform: str, question: str) -> dict:
resp = requests.post(f"https://api.{platform}.example/v1/chat",
json={"messages": [{"role": "user", "content": question}]},
timeout=60)
return {"platform": platform, "question": question, "answer": resp.json()["text"]}
def dedup_key(platform: str, slot: str, window: str) -> str:
"""去重键 = md5(平台 + 问法槽位 + 采样日期窗口)。
窗口用自然日；同平台同槽位同日多次采样合并为一条记录。"""
raw = f"{platform}|{slot}|{window}"
return hashlib.md5(raw.encode()).hexdigest()
def run_daily(window: str, max_retry: int = 2):
records, seen = [], set()
for platform, question in QUESTIONS:
key = dedup_key(platform, question, window)
if key in seen: # 同窗口同槽位只入一次库
continue
seen.add(key)
for attempt in range(max_retry + 1):
try:
r = sample_once(platform, question)
r["dedup_key"] = key
records.append(r)
break
except Exception:
if attempt == max_retry:
records.append({"platform": platform, "question": question,
"dedup_key": key, "error": "sampling_failed"})
time.sleep(30 * (attempt + 1) + random.uniform(0, 15))
return records
if __name__ == "__main__":
# 由系统 crontab 每日 06:00 触发：0 6 * * * python daily_monitor.py
run_daily(window=time.strftime("%Y-%m-%d"))
调度参数对照
| 参数 | 保守档（轻量客户） | 标准档 | 说明 |
|---|---|---|---|
| 采样时段 | 06:00 固定一次 | 06:00 + 20:00 两次 | 两档都必须固定时段 |
| 并发 | 串行，问法间隔 20–40s | 并发 3，带退避 | 低峰期串行足够 |
| 重试 | 2 次，间隔 30/60s | 3 次，指数退避 | 每次重试重建会话 |
| 去重窗口 | 自然日 | 自然日 | 跨日不合并，保留日粒度 |
| 失败记录 | 记 error 不补采 | 记 error，次日补采 | 缺口要可见，不能静默吞掉 |
两条踩坑复盘
踩坑一：去重键里漏了平台维度。 早期版本用 md5(问法+日期)，结果豆包和 Kimi 对同一问法的记录互相覆盖，周报里平台对比一栏直接失真。根因是默认「同一天同一问法只会采一次」，忽略了多平台并行。修法：平台必须进键，落到上面的 dedup_key 签名里；已经落库的旧数据按键规则重建后回填。
踩坑二：失败重试静默吞掉，缺口当天无人知晓。 根因是重试逻辑写在 try/except 里，异常时既不记 error 记录也不告警，报表上表现为「那天数据很干净」。修法：失败也必须产出带 error 字段的记录入表，连续两个采样日同一槽位失败则触发人工核查——否则你分不清是「AI 没提你」还是「你根本没问到」。
小结
固定问法监测的本质是用最小采样成本换取日粒度的可比数据。早六点只是表象，核心是「固定时段 + 会话隔离 + 去重键」三件事咬合在一起。日本那家场馆服务商的做法已经证明这是行业动作，剩下的差异只在执行颗粒度。
你的监测任务里，去重键是落到了记录级，还是只在报表层做了去重？欢迎评论区交流。
