规模化修复目录一致性：按缺陷类别分批处理 AI 引用问题，而不是逐页编辑

简短回答：值得，但不要逐页做。 昨天的分诊逻辑告诉你先修哪个页面，却没告诉你如何清掉一个有四百个被标记 URL 的目录，而不花掉一个季度的手工劳动。答案是按缺陷类别分批，而不是按页面分批：一次只挑一类问题，用一次数据导出加一段脚本扫遍全目录，一次性修完，验证后再进下一类。一个 4,000 SKU 的商户，可以用三到四轮把大多数「阻断回答」的缺陷清掉，而不是四百次单页编辑。

这是审计闭环的工业化版本。分诊矩阵决定修什么，分批决定怎么修完。

## 为什么分批优于逐页作业

逐页修复看起来谨慎，实际几乎总是更慢、效果更差。三个原因：

• 同一个问题你会重复学四十遍。 运费表是否自相矛盾，在每个页面上的检查方式都一样。把它做成一次目录级扫描，它是一次查询，不是一个项目。
• 修复必须一致才可信。 如果你分十四次修十四页的运费措辞，一定会漂移。分批强制全套目录使用同一句表述，而这正是助手所奖励的。
• 你得到一次干净的测量。 如果一周内改了 200 页的 schema，你无法判断哪个改动影响了引用行为。按缺陷类别分批，让你每一类都有清晰的改前改后对比。

真正的陷阱是「按页面分组来分批」。「把 120 个被标记页面都修好」不是一批，而是一份积压清单。「把目录里每个商品缺失的库存字段补上」才是一批。

## 值得跑的六个批次

按这个顺序做。每一轮都要扫遍全目录，再开始下一轮。

1. 身份批次——品牌与组织事实。 所有提及店铺名、联系方式、退货地址的页面必须一致。机器可读的 Organization 数据、页脚文案、政策页应指向同一个实体、同一个名称、同一套联系方式。这里的不一致是域名级风险，不是页面级问题。

2. 商业事实批次——价格、币种、库存。 为每个事实找出唯一真相来源。如果变体记录说一套、营销文案说另一套，那就是助手会「判你不利」的矛盾。先修数据模型，再修文案。

3. 政策措辞批次——运费、退货、保修、关税。 这是跨境目录分歧最严重的地方。每项政策一句批准过的表述，全站套用。不要逐页改写。改写就是漂移。

4. 结构化数据批次——Product、Offer、FAQPage。 让标记由页面渲染所依据的同一份数据生成，这样 schema 与可见文本无法互相矛盾。在一个文案每月变动的页面上手写 schema 块，就是在制造一场等着上线的矛盾。

5. 答案完整性批次——每个品类的三个问题。 对每个商品品类，确定买家真正会问的三个问题，并确保该品类下每一页都用直白文字回答这三问。这是投入最高的一批，也是与引用最直接相关的一批。

6. 新鲜度批次——日期、库存周期、季节性声明。 扫出一切会过期的表述：去年的配送时限、已停售的变体、过期的促销。陈旧事实是一种慢性矛盾。

## 搭建批次流水线

你不需要大型系统，你只需要同一份导出用四次。

• 把目录导出为结构化数据。 商品 handle、标题、属性、价格、库存、政策引用、最后修改日期。每个 URL 一行。
• 每个缺陷类别加一列，让脚本给每行打标。标记是确定性检查：字段是否存在、是否等于规范值、页面文本中是否出现竞争性说法。
• 在源头修，不要在 CMS 里逐字段修。 如果源头是商品 feed 或 PIM，就在那里改完再重新导出。手工改 HTML，会在有人第一次更新商品时把漂移重新引进来。
• 整批验证。 重跑同一段脚本。一批完成的标志是这类标记数归零，而不是你感觉做完了。
• 记录类别与日期。 六周跑完六个批次，就得到一条清晰的时间线，可与引用行为对照。

一段扫遍目录、只标出一类问题的脚本，通常不到一百行。瓶颈从来不是工具，而是「什么才是正确值」这件事达成共识。

## 六批次扫单在实操中是什么样

一家约 3,800 SKU、被标记 URL 接近 400 的家居用品商户按顺序跑了各批次。身份批次发现品牌名在页脚、schema 和政策页上有三种拼法，还有两个仍在使用的客服邮箱。政策批次把十一种运费描述收敛成两句批准表述：一句国内、一句跨境。商业事实批次清掉了四处互相矛盾的价格陈述。总文案编辑量不到六十处，分三轮完成。剩下的积压几乎全是答案完整性批次——那本来就是持续性的工作。

关键在于规模：六十次编辑，而不是四百次。分批把一个管不动的审计变成了一份可执行的排期。

如果你想知道自己目录里究竟哪几类缺陷最集中，可以用 Visora 在 /audit 跑一次免费扫描——报告会按问题类型给被标记 URL 分组，让你凭证据而非直觉挑选第一批。这个分数衡量什么、不衡量什么，/faq 里有说明。

## 常见问题