产品数据验证：需要理解时用 AI，其余交给规则

产品数据输入杂乱、输出看似结构化，很适合 AI。但能读文档或写文案的模型，不应决定合规。我们把概率性理解与确定性控制分开：模型负责提取和表述，可追溯规则负责验证和决策。

产品数据是控制系统，不是写作任务

一条产品记录连接供应商证据、商业要求、法规、渠道规范和主数据。单一属性可能影响搜索、物流、税务或安全。流程必须接收证据、识别实体、应用政策、路由例外、记录审批并发布授权版本。

理解： 读取多变的文档、图像和文本，映射术语并起草内容。
控制： 检查必填项、类型、值域、单位、依赖、证据、权限和状态。

引入 AI 前先定义规范记录

为每个属性定义稳定 ID、类型、负责人、单位、来源、证据、适用范围和审批权。原始证据不可变，候选值与批准值分开。

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

如同带认证页的 B2B 产品目录，每项声明始终连接证据。

模型适合创造价值的环节

从非结构化证据提取候选值

模型可从表单、规格书、标签和图像提取候选值及证据位置。没有证据时返回 null，不能猜测。置信度只用于路由，不替代证据。

映射到受控词表

模型提出概念及理由，最终由规则或授权审核者接受；精确同义词先由确定性逻辑处理。

生成面向客户的文本

标题、要点、摘要和翻译只能使用已批准属性，再由规则检查长度、禁用声明、限定语、术语和无依据内容。模型不能审判自己的输出。

必须由规则决策的环节

规则类型	示例控制
存在性	产品类别必填属性已填写
类型与格式	值符合声明类型
范围	数值位于授权区间
枚举	值属于当前词表
单位	单位允许且换算获批
跨字段	触发时依赖字段存在
证据	声明有有效且最新来源
一致性	数量、尺寸和合计一致
适用范围	对目标语言、市场和渠道有效
权限	角色获准批准或发布

每条规则都有 ID、版本、负责人、严重度和可读消息。摄取、编辑、批处理、API 和发布使用同一验证服务。这也使多目的地 flatfile 自动化更安全：格式变化不会削弱规范政策。

参考工作流

Ingest: 登记文件、校验和、来源和时间。
Preprocess: 分类并关联候选产品身份。
Extract: 先用解析器，未解决字段再用模型。
Normalise: 转换格式和单位，不改变语义。
Validate: 执行版本化规则。
Review: 例外和高风险变更交授权人员。
Approve: 记录值、证据和批准者。
Publish: 通过受控适配器写入。
Observe: 捕获拒绝、纠正和结果。

每次状态变化都生成事件，便于重放和重新验证。多语言商务架构也应把翻译视为派生、版本化输出，共享批准事实和证据。

置信度用于路由，不授予真实性

高置信度不能证明来源正确、最新或已授权。风险、规则与置信度共同决定路径；敏感声明始终需审批，缺乏证据则弃权。阈值应按属性和文档类型校准。

例外也是产品的一部分

组合、替代品、地区变体、旧记录和冲突文档都很常见。每个例外需要原因码、严重度、负责人、期限和允许的解决方式。override 必须明确且限域；反复 override 表明规则、分类或来源需要调整。

从基线衡量到结果

上线前衡量完整度、首次通过率、纠正周期、审核时间、下游拒绝和严重缺陷。机密报告使用 Baseline = 100，绝对值留在授权环境。

候选准确率和证据覆盖率；
规则通过率与弃权率；
人工 override 和纠正率；
队列年龄和批准时长；
发布后拒绝及纠正；
严重错误护栏。

模型、prompt、分类和规则独立版本化。重放比较新增接受和拒绝；护栏恶化时，即使平均准确率提高也阻止发布。

把变更当作政策变更治理

规则变更需要负责人、理由、生效日、测试和相称审批。模型要在标注、对抗及低质量输入上测试。先 shadow mode，再有限群组，护栏稳定后扩展。写入适配器强制幂等、最小权限和回滚，模型不得直接无限访问记录系统。

可扩展的职责划分

这不是“AI 对规则”。模型将多变证据变成候选值、将批准事实变成语言；规则表达可重复政策；人处理歧义和高风险。系统必须区分观察、推断和允许，并记录谁作出决定。需要理解的地方用 AI，能明确决策的地方用规则。