购物智能体正在剔除的是「无法确认」的商品，而不是缺货的商品

这一季度智能体购物里有一个值得留意的新迹象：当一个自主助手在收窄候选清单时，它越来越常用的筛选维度是「可信度」，而不是库存。商品被剔除，是因为它某个必需属性无法从商家自己的结构化文本中得到确认，而不是因为它缺货。

对商家来说这个区别很关键。库存状态几乎是每个平台都已经同步的字段，因此很少成为商品消失的原因。「确认」就不一样了。如果智能体无法从它信任的来源里解决买家真正用来决策的那个约束——净空、材质、兼容范围、保修条款——那么更安全的行为是把这款产品排除掉，而不是带着一个未知数去推荐它。

## 为什么「可信度筛选」现在才出现

两个条件同时成熟了。第一，智能体开始获得决策权，而不只是生成清单，这让判断错误的代价变高。第二，把内容检索进一个答案的成本已经足够低，使得智能体可以核对多个候选——这意味着一个「无法核实」的候选不再是唯一选择，而只是风险最高的那一个。

实际后果是：数据缺失所带来的惩罚是不对称的。一个没解决的约束不会让产品的排序略微下降，它可能直接把产品从候选集合里移除。受到最大影响的，恰恰是那些数据丰富但不完整的商家——所有内容都是写给人类读的，没有一个放在可核查的字段里，因为在读者看来，页面是完整的。

## 「确认」到底需要什么

确认不等于「出现过」。页面上某处提到过一个尺寸，比在一个机器可读结构里以带单位的形式断言该尺寸要弱得多。而当两者冲突时——页面文案说一套、商品 feed 说另一套——冲突本身就是一次确认失败，而且往往恰好在最不合适的时刻被发现。

权重最大的属性，是买家用来决策的那几条轴，而不是完整参数表：尺寸与净空、材质与排除项、兼容性与功率要求，以及决定胜负的履约条款。

## 商家应该从中得出什么

有用的做法是：不要再把缺失属性当成「完整度问题」，而开始把它当成「被排除的风险」。这会重新定义工作内容——关键不在于页面里有没有这条信息，而在于当一个智能体来核查某项约束时，它能否找到一条它信得过、且已明确写下的表述。

## Visora 的视角

这正是我们在 /audit 上的扫描器要暴露的缺口。它会报告哪些属性缺失、格式错误、或与 feed 不一致，并按这些缺陷在买家真实提问上阻塞引用的频率排序。它是诊断工具，不是保证，没有任何工具能承诺你进入助手的短名单。它能做的，是用一次扫描告诉你：哪些商品会让智能体不得不「靠猜」——而靠猜，正是智能体被设计来避免的行为。