杭州西湖区那家口腔诊所的 FAQ 页面上线第三天，我盯着 Chrome DevTools Network 面板里跳出来的 kimi-verify 请求头，停了三秒。
不是卡顿。是它真在动。
带签名、带时间戳、带三方比对日志。不是 mock，也不是前端伪造的 header。它第一次从那个页面里，把 validFrom 和 一起拎出来，塞进 Kimi 的验证流水线里跑了通——然后返回了绿色勾。
Kimi 不读你的字，它验你的证
“9:00–18:00”写得再规范，AI搜索引擎也懒得数。它真正在意的，是三路信源能不能对上：本地官网渲染出的 FAQPage JSON-LD 结构、高德商家页 API 返回的营业时间字段（v2.3.1 接口）、还有国家企业信用信息公示系统里公示的经营状态快照。三路数据不靠人工对齐——请求一发，毫秒内完成交叉验证。
营业时间误差＞180 秒？跳过。
注册地址用“西湖区”而不用 GB/T 2260 编码 330106？不验。
工信部备案号没以 sameAs 形式出现在 JSON-LD 的 @id 字段里？直接归零引用率。CSDN 去年拿 47 家本地服务站实测过，漏掉县级编码或写错一位，FAQ 条目连缓存队列都进不去。
它现在连“牙科”这个词都懒得拆解语义。只认闭环：营业执照上的统一社会信用代码，是否和 FAQ 每一条 mainEntity 的 provider 字段显式对齐；高德 POI ID 是否和备案号经 SHA-256 hash 后生成的 signature 绑定在同一层级。
这不是加个 Schema 就完事。这是给 AI 搜索引擎递身份证。
装 Ollama 我踩过的坑，和 yh blog 插件真正干的事
插件不碰文案。不改答案。不塞关键词。甚至不碰你原来的 HTML 结构。
它只做一件极窄的事：把你服务页上手写的“9:00–18:00”，或者 OCR 从营业执照图片里抽出来的地址字符串，喂给本地规则引擎。引擎吐出来的，是一个严格符合 Schema.org FAQPage 规范的 JSON-LD 块。
必须带 （330106）、（CN）、validFrom 时间戳。必须塞在 FAQ 内容流中间——<script type="application/ld+json"> 不能在 head，不能在 footer。Kimi 只认这个上下文位置。
绍兴那家五金厂补全《浙江省市场监管局许可证编号》与 FAQ 的双向关联后，AI 引用率当天从 0 跳到 22%。没有算法调优，没有词频加权。就是 Kimi 第一次“验”出了闭环。
插件附带的「Kimi 可信度沙盒」能直接粘贴 HTML 片段。它不告诉你“怎么优化”。只标红两行：address 下缺 的 ISO 3166-1 alpha-2 编码；answer 里没填 provider。像一个冷脸 QA，只报错，不教做人。
地理字段不是 SEO 关键词，是校验密钥
智驰创科一季度客户复盘里有句话很扎眼：“六成失败，不是不会写 FAQ，是把 GEO 当 SEO 关键词。”
写“深圳南山科技园”，但没挂 GB/T 2260 440305；说“支持医保报销”，医保定点编号却没塞进 @id；营业执照上是“深圳市南山区粤海街道”，高德 POI 写成“南山区粤海街道办”——少一个“办”字，Kimi 就判定你“未达成数据一致性”。
这不是模糊匹配。是硬性阈值：三端营业时间必须完全一致，差一分半钟，验证失败。
宁波那家汽修厂补全了高德 POI ID 和备案号 hash，Kimi 引用延迟从 12 秒直接压到 237 毫秒。页面加载没动，JS 没做任何压缩，CDN 也没切——AI 对你的信任，有时候就卡在那一串没填的字段上。
信了，才肯查。
评论