把「停产型号」写进FAQ之前，先查查它有没有被AI当成在售推荐

前两天有客户问，为什么AI搜索里还在推荐他们三年前就停产的型号。我第一反应不是去改内容，而是先拉日志。简单说，这不是内容质量问题，是数据一致性没做。

我让他们把官网产品页的JSON-LD和FAQ里的型号字段都导出来，跑了一遍比对脚本。结果很直接：有11个型号在FAQ里还标着「在售」，但产品库的状态字段早就是「停产」了。AI抓的是FAQ那套旧结构化数据，它没有理由知道你的库存系统里发生了什么。

这里有个容易忽略的点：AI引用的优先级，往往不是按内容新旧排的，而是按结构化数据的完整度排的。你产品页更新得再勤，FAQ里那套带型号、带参数的问答对只要还挂着，它就有机会被当成「近期有效信息」推出去。

我的处理方式分三层：

1. 先卡状态字段。产品库的status字段（在售/停产/缺货）加一道校验，任何对外输出的结构化数据必须引用这个字段，不允许FAQ自己硬编码「在售」。
2. 再改输出逻辑。FAQ生成时，型号状态从产品库实时拉，停产型号自动打上「已停产，可查看替代型号」的标记，而不是简单删掉——因为用户确实会搜旧型号。
3. 最后补问句库。客户问「XX型号还有吗」这类句子，回答里必须带替代型号，且替代关系从产品库的successor字段读，不让内容侧手填。

这套做完之后，再跑一遍AI搜索的引用抽查，旧型号被当在售推荐的次数从11次降到2次，剩下2次是缓存没刷，等抓取周期过了就正常。

所以回到标题那个问题：这锅该架构背还是内容背？我的判断是七三开。架构侧没把状态字段做成单一可信源，内容侧才会拿旧数据硬编码。但反过来，如果内容侧一开始就要求「型号状态必须可溯源」，架构侧也不会拖到出事才补。

你们那边FAQ里的型号状态字段，是实时拉产品库还是内容侧手填的？有没有人抽查过AI搜索对停产型号的推荐情况？