结构化数据里同一个字段名，我们组三个系统填出了三种类型，AI解析直接乱套

上周排查一个线上问题：AI 回答里商品价格时而带「起」字、时而带币种符号，时而变成纯数字。翻了半天喂料日志，根因不是模型，是我们自己三个系统对 price 这个字段的类型定义不一致。

具体情况：

• 商品中台导出的 JSON-LD 里 price 是 "99.00"，字符串；
• 运营后台的 Excel 导入模板把它转成 Float，写进页面变成 99；
• 老 CMS 那套模板更离谱，直接拼成 "￥99起" 塞进 offers.price，schema 校验能过是因为我们没开严格模式。

三个来源合流到一个喂料批次，AI 侧解析时把 "￥99起" 当成非法值丢掉，于是同一款商品在不同答案里出现「未提供价格」和「99元」两种说法。用户截图来问，我们一开始还以为是模型幻觉。

我的处理步骤，给有类似问题的同行参考：

1. 先锁口径再改代码。拉上商品、运营、前端三方，把 price 的语义定死：币种单独放 priceCurrency，数值字段只允许 decimal 字符串，禁止带任何单位或修饰词。
2. 在 CI 里加 schema 严格校验。用 additionalProperties: false 加类型枚举，任何非字符串的 price 直接让构建失败，不给自己留情面。
3. 批次哈希对比。每次喂料前对结构化数据块算 SHA-256，和上一批次比对，字段类型一变就报警，比事后翻日志快得多。
4. 页面速度顺带查了一下。JSON-LD 内联在 head 里，体积涨了 12KB，LCP 掉了 0.3s，后来把非首屏商品的 offers 拆到独立接口异步注入，才把指标拉回来。

改完之后跑了一周，价格相关的问题反馈从每天 5～6 条降到 0。但有个新情况：availability 字段也有同样的隐患，我们三个系统分别填的是 InStock、in_stock、有货，目前还没爆，属于定时炸弹。

想问问各位：你们团队做结构化数据字段治理时，是靠 schema 注册中心统一发类型，还是靠 CI 校验兜底？字段枚举值这块有没有更硬的约束手段，比如 protobuf 或 JSON Schema 的 enum 强校验？