适用读者：本地生活平台开发者、连锁门店技术负责人、做商家评价系统的后端工程师

一、问题的起点：本地服务的 AI 推荐逻辑与电商不同

本地服务业（家政、维修、 dental 诊所、宠物店、健身工作室这类）的获客路径正在起变化：用户不再只搜"附近+品类"，而是问 AI 更具体的问题——"哪家宠物医院周日营业且能看异宠"、"周边有没有口碑好、能上门的家电清洗"。DeepSeek、豆包、美团系 AI 在回答这类问题时，引用的依据不再是页面标题匹配，而是结构化的商户属性和评价数据。

我们负责的一个连锁家政平台，60 多家直营门店各有独立详情页。做 GEO 诊断时发现两个问题：一是详情页完全没有结构化数据，AI 引擎只能从页面文案里猜营业时间和服务范围；二是评价数据躺在自己的小程序里，公开网页上几乎不可见，AI 引擎无从引用。

本文记录我们补齐 Review 与 AggregateRating Schema 的完整过程，重点是有对照的数据：同样的商户页，加上评价结构化数据前后 45 天，AI 推荐表现的变化。样本不大，但趋势清楚，做本地服务的同学可以直接参考方法。

二、先理解：AI 引擎推荐本地商户的四层信号

动手前拆解了一下本地服务 AI 推荐的信号层次，这决定了优化的优先级排序：

基础事实层我们此前已经通过 LocalBusiness Schema 覆盖了（这部分在之前的 POI 同步文章里讲过），这次的主战场是第二层：评价信号。选它有明确理由——本地服务的用户决策几乎完全被口碑驱动，AI 引擎在模拟用户决策时自然给评价数据更高权重；而且评价数据我们手里有，缺的只是把它结构化地"摆"到 AI 爬虫面前。

三、方案设计：评价数据的结构化输出管线

评价系统的数据链路是：用户在小程序提交评价 → 后端审核 → 存入 MySQL。要让 AI 爬虫读到，需要在商户详情页（服务端渲染部分）输出 JSON-LD。核心类型是 LocalBusiness（已有）下挂 aggregateRating（聚合评分）与 review（精选评价列表）。

数据库侧不用大改，关键是把审核通过的评价按质量分排序取前 N 条：

-- 每个商户取 5 条高价值评价：有文字、字数达标、近期、非异常
SELECT r.store_id, r.author_name, r.rating, r.content, r.created_at
FROM store_reviews r
WHERE r.status = 'approved'
  AND CHAR_LENGTH(r.content) BETWEEN 15 AND 300
  AND r.created_at >= NOW() - INTERVAL 90 DAY
  AND r.store_id = %s
ORDER BY r.quality_score DESC, r.created_at DESC
LIMIT 5;

筛选条件有讲究：纯五星无文字的评价对 AI 没有语义价值，反而像刷出来的；字数上限过滤掉情绪化长文；只取 90 天内的评价保证时效性。aggregateRating 的数值必须与页面可见的评分完全一致——AI 引擎会交叉验证，不一致的代价是整页信任度降级。

详情页输出的 JSON-LD 片段（服务端拼装）：

{
  "@context": "https://schema.org",
  "@type": "HomeAndConstructionBusiness",
  "name": "洁到家家庭服务·滨江店",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "江南大道 228 号 2 层",
    "addressLocality": "杭州"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "326",
    "bestRating": "5"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "王女士" },
      "datePublished": "2026-08-21",
      "reviewBody": "阿姨上门很准时，油烟机清洗得比预期干净，价格和页面标的一致。",
      "reviewRating": { "@type": "Rating", "ratingValue": "5" }
    }
  ]
}

三个实现细节值得记下。第一，review 只放 3-5 条，全量输出会让详情页体积膨胀，爬虫反而不抓完；第二，评价文本里出现的具体服务名（"油烟机清洗"）是 AI 匹配"哪些店提供某项服务"的关键词，精选评价时优先选提及具体服务项的；第三，author 用姓氏加称谓而非全名，兼顾真实感与隐私合规。

四、对照实验设计与执行

为排除内容质量本身的干扰，我们选了 30 家商户做分组：15 家上评价 Schema（实验组），15 家不动（对照组），两组在评分分布（4.6-4.9）、评价数量（200-400 条）、开业时长上做了配对。观察期 45 天。

评价 Schema 于第 1 天全量上线，第 15 天做了一次中期检查修了两个问题（下述踩坑），除此之外无任何其他改动，保证单一变量。

五、45 天数据对比：评价结构化的真实影响

几组数据值得展开说。抓取频次翻倍说明结构化数据本身就是爬虫磁铁——爬虫对携带丰富 Schema 的页面有明显的优先抓取倾向。最关键的是第四行：只有实验组商户在"滨江哪家做油烟机深度清洗"这种带具体服务名的长尾问题里被引用，这正是精选评价里服务名关键词起的作用——评价文本成了服务能力的语义证据，这是纯页面文案给不了的。

自然流量增长 49% 说明结构化数据对传统搜索同样有效，Google 的富结果星级展示在部分页面已生效，等于一次改造两个收益。

附一：评价文本的服务名抽取——让评价成为服务能力的证据

精选评价里"提及具体服务"这条标准，靠人工筛选撑不起 60 家店的量，我们做了一个轻量的抽取服务。思路是用分词加服务词表匹配，不依赖重型模型：

import jieba

SERVICE_DICT = {"油烟机清洗": 2.0, "空调清洗": 2.0, "深度保洁": 1.5,
                "日常保洁": 1.0, "玻璃清洗": 1.5, "除螨": 1.5}
for w in SERVICE_DICT:
    jieba.add_word(w)

def extract_services(review_text: str) -> list[str]:
    words = set(jieba.cut(review_text))
    return [w for w in SERVICE_DICT if w in words]

def quality_hint(review_text: str) -> bool:
    # 同时提及具体服务与正面感受词的评价，优先入选 Schema
    positive = any(k in review_text for k in ("干净", "准时", "专业", "满意", "推荐"))
    return bool(extract_services(review_text)) and positive

抽取结果有两个用途：一是作为精选评价的入选信号，二是反哺服务类目数据——某项服务在评价里被频繁提及但页面类目里没有，说明类目配置有遗漏。这个闭环跑起来后，我们靠评价文本补齐了 11 个此前没配置的服务子类目。

附二：新店没有评价怎么办

冷启动商户的评价 Schema 有个鸡生蛋问题：新店没有评价，reviewCount 写 0 还是干脆不输出？我们的结论是不输出。零评价的 AggregateRating 不提供任何信息，反而暴露"该店还没有市场验证"；不输出的页面 AI 引擎会自然回退到基础事实信号判断。更重要的是冷启动策略：新店开业前 30 天用首单评价激励（真实交易、真实评价，不做任何虚构）积累 20 条以上有具体服务描述的评价后，再开启 Schema 输出。实测这个阈值以上的店，Schema 上线后 30 天内出现 AI 引用的概率明显更高——评价的"语义密度"比数量更关键。

合规上再强调一句：评价必须来自真实交易，禁止任何形式的人工合成评价进入 Schema。生成式引擎对评价文本的真实性校验能力在快速进化，虚构评价被识别的代价是整个实体的信任清零，比传统搜索时代的处罚重得多。

六、过程中踩的三个坑

1. 评分取整导致交叉验证失败。后台显示 4.8 分，但聚合计算是 4.823，Schema 里我们最初写了 4.82，页面展示写 4.8，AI 引擎判定数据不一致。修复规则：Schema、页面、小程序三端统一用一位小数，计算逻辑全部走同一函数。
2. 评价更新滞后。最初是每天凌晨全量刷新 Schema，结果新评价当天不可见，而页面评价列表是实时的，又被一致性校验盯上。改为评价审核通过后触发商户页 Schema 缓存失效，延迟控制在 10 分钟内。
3. .Schema 与页面 DOM 不对应。有个门店页面改版后评价区块改成了懒加载，首屏 HTML 里没有评价内容，但 JSON-LD 里有——典型的一致性陷阱。AI 爬虫多数不执行 JS，看到的正文里没有评价，Schema 里的评价就成了"凭空捏造"。修复：懒加载区块内的评价不上 Schema，或改为 SSR 输出。

第三个坑的教训最深：结构化数据永远不能快于页面可见内容。宁可少输出，不可虚构输出。

补充一个实验期之后稳定下来的运维机制：评价 Schema 的健康巡检。每天跑一个巡检任务，随机抽 10% 的商户页，抓取线上页面比对三件事——Schema 评分与页面显示评分是否一致、Schema 评价文本是否仍出现在页面上、页面上评价区块是否还在首屏 HTML 里。巡检报告自动进值班群，异常项 24 小时内处理。这个机制上线后捕获过两次问题：一次是门店页模板改版导致评价区块移出首屏，一次是某商户手动删除了差评导致 Schema 与页面评价数不一致。没有巡检的话，这两处不一致会一直挂在页面上持续消耗引擎信任度。

七、误区澄清与给同行的建议

一个高频误区必须澄清：给商户页挂上高分 AggregateRating 不等于 AI 就会推荐。我们对照组里也有两家中途自己加了评分展示（非 Schema），AI 推荐毫无变化——引擎要的不是那个数字，而是数字背后可验证、可交叉的一致性证据链。反过来，低分商户也不必藏评价，3.9 分但有大量具体、真实的评价文本，比一个无文本的 5.0 更可能被引用，因为评价文本才是语义匹配的素材。

给准备动手的同行三条建议：先做一致性审计再做 Schema 输出，端到端统一评分口径；精选评价时把"提及具体服务"放在第一位标准；把评价 Schema 的刷新接入业务事件而不是定时任务。本地服务的 AI 推荐竞争才刚开始，评价数据的结构化是目前投入产出比最高的一步。有踩到别的坑的同学，评论区交流。

关键词：GEO、AI优化AIO、Review Schema、AggregateRating、LocalBusiness、本地服务SEO、AI推荐、评价结构化