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

产品数据很适合作为企业 AI 的应用场景：输入杂乱，期望的输出看起来却是结构化的。但能读文档或写描述的模型，不应决定一条记录是否合规。我们把概率性的理解与确定性控制分开：模型负责提取和表述，可追溯的规则负责验证和决策。

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

一条产品记录连接供应商证据、商业要求、法律义务、渠道规范和内部主数据。一个属性可能影响搜索、物流、税务、安全审核、包装或客户预期。看似微小的编辑，也可能传播到多个下游系统。

因此，把“生成产品内容”作为系统边界并不合适。生成只是其中一项活动。真正的工作流要接收证据、识别实体和属性、应用政策、转交异常、记录批准并发布获授权的版本。可靠性取决于整条链。

所以，我们先把工作分为两类：

理解：读取形式多变的文档、图像或自由文本，把陌生表述映射到已知概念，起草简洁描述。
控制：检查必填字段、数据类型、允许值、单位、跨字段依赖、证据要求、权限和发布状态。

理解是概率性的，适合借助模型。只要政策能够明确表达，控制就应采用确定性方式。把两者放进同一个提示词，会让输出难以审计、测试和申诉。

引入 AI 前先定义规范记录

规范产品模型需要稳定标识符、带类型的字段和明确的责任归属。对于每个属性，我们记录其定义、单位、基数、允许来源、必需证据、市场或渠道作用范围，以及批准变更的权限。

原始证据保持不可变。提取出的候选值与已批准值分开存储，防止模型生成的值悄然变成事实，也让审核者能够对照来源检查候选值。最小的数据血缘记录包括：

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

生产记录只包含通过相关规则和审批路径的值。这与带认证页面的 B2B 产品目录背后的架构一致：声明应始终与证据关联，而不是被当作可以随意替换的营销文案。

模型适合创造价值的环节

模型适合处理工作流中输入多变的边缘环节。

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

供应商表单、技术资料、标签和图像，往往以不同版式或措辞表达同一个属性。模型可以定位可能的值、规范化周边文本，并返回带证据引用的结构化候选值。输出契约应要求在没有证据时返回 null；猜测不等于完成任务。

对于视觉任务，系统应保留支持提取结果的图像区域或页面；对于文本，应保留简短的来源片段或坐标。置信度适合用于任务路由，但它不是证据，绝不能替代来源引用。

把表述映射到受控词表

来源术语可能与企业的分类体系不完全一致。模型可以提出最接近的受控概念并解释映射依据，最终是否接受仍由规则或授权审核者决定。如果分类体系有精确的同义词表，应先执行确定性匹配，再让模型处理尚未解决的部分。

生成面向客户的文本

模型可以根据已批准属性起草标题、要点、摘要或翻译。提示词只能引用已批准记录，并明确标注可选的风格指令。生成的文案随后接受规则检查，涵盖长度、禁止的声明、必需限定语、术语和缺乏依据的值。

不应让模型判断自己的文本是否合规，否则同一个概率性组件就同时成了作者和裁判。

必须由规则决策的环节

如果失败条件可以表达并测试，就适合使用规则。典型类别包括：

规则类型	控制示例
存在性	该产品类别的必填属性已填写
类型与格式	值可以按声明的类型和编码解析
范围	数值位于获授权的区间内
枚举	值属于当前受控词表
单位	单位获准使用，换算无损或已经批准
跨字段	触发值适用时，依赖字段必须存在
证据	声明有符合要求且仍有效的源文档
一致性	包装数量、尺寸和推导出的合计相互吻合
作用范围	值对目标语言、市场和渠道有效
操作权限	操作者获准批准或发布该字段

每条规则都需要标识符、版本、负责人、严重度和便于人理解的消息。消息很重要：“验证失败”会产生支持工单；“净含量需要经批准的单位和来源引用”则会形成明确的修复任务。

这种分离也让面向多个目标平台的 Flatfile 自动化更安全：可以调整目标平台专用格式，而不削弱规范记录的验证政策。

规则应在多个边界执行：数据摄取时、提取后、人工编辑后、导出前和发布前。界面、批处理数据管道和 API 应使用同一个版本化验证服务。在不同系统中重复实现规则逻辑，会产生互相矛盾的结果。

参考工作流

我们把流程实现为一系列明确的状态转换：

摄取：登记源文件、校验和、来源和接收时间。
预处理：对文档分类，并与候选产品标识关联。
提取：先使用确定性解析器，再用模型处理未解决的字段。
规范化：转换格式和单位，不改变语义。
验证：执行适用的版本化规则集。
审核：只把异常或高风险变更转交授权人员。
批准：记录接受的值、证据和批准者身份。
发布：通过受控适配器写入各个目标平台。
观察：捕获下游拒绝、修正和结果信号。

每次转换都会产生事件。事件日志使系统能够重放：分类体系或规则变化时，可以识别受影响记录并重新验证，无需重新提取全部内容。

同一原则也适用于不同语言版本。严谨的多语言电商架构把翻译视为派生的版本化输出，同时共享已批准的事实和证据。

这种工作流还避免了一种成本高昂的反模式：把所有字段都发送给可用的最大模型。精确标识符、日期、已知单位和枚举代码应走确定性路径，模型只处理有歧义的字段。这样既降低成本和延迟，也让剩余模型任务的评估更有意义。

置信度用于分派工作，不能证明真实性

置信度分数经常被误解。模型的高置信度不能证明来源正确、仍有效或获授权，只描述了模型在某种方法下的判断。

我们结合置信度、风险和规则结果选择处理路径。具有直接证据且通过全部规则的低风险候选值，可以进入轻量审核队列；受监管或商业敏感的声明，可能无论置信度多高都需要人工批准。缺失证据时应放弃作答，而不是降低阈值。

阈值应按属性和文档类型，使用代表性数据校准。一个全局阈值会掩盖重大差异：提取标准标识符与理解材料声明并不等价。我们针对每个有意义的分群，追踪精确率、召回率、放弃作答率和审核者覆盖情况。

异常也是产品的一部分

真实产品目录包含组合产品、替代商品、地区变体、旧记录和相互冲突的供应商文档。只为正常路径设计的系统，会在不可观测的地方产生人工工作。

每个异常都需要原因代码、严重度、负责人、到期日和允许的解决方式。审核者应在同一个视图中看到候选值、源证据、未通过的规则和下游影响，并能接受、修正、拒绝或要求新证据，而不必编辑原始源数据。

覆盖必须明确且限定作用范围。审核者可以针对一个产品和一个目标平台覆盖某条警告，但不应全局停用底层规则。反复出现的覆盖是一个信号：规则、分类体系、来源流程或产品模型可能需要修订。

服务等级应反映业务风险，而不是按到达顺序决定。缺少可选营销字段与安全属性相互矛盾，不应进入同一个队列。

从基线衡量到结果

自动化之前，我们衡量字段完整度、首次验证通过情况、修正轮次、审核时间、下游拒绝率和严重缺陷率。对于保密的内部报告，可以把每个序列表示为以 Baseline = 100 为基准的指数，将绝对数量和商业价值留在获授权的环境内。

上线后，我们区分提取质量与运营绩效。一次提取可能在技术上正确，却到得太晚，错过发布时间；工作流也可能缩短审核时间，却增加严重缺陷。因此，评分卡包括：

按属性分类的候选值准确率和证据覆盖率；
规则通过率和放弃作答率；
人工覆盖率和修正率；
队列等待时长和形成已批准记录所需的时间；
目标平台拒绝情况和发布后的修正；
针对高严重度错误的护栏。

模型、提示词、分类体系和规则的变更分别进行版本管理。评估集包含常见记录和已知异常。部署前，我们重放拟议版本，对比新近被接受和新近被拒绝的记录。如果某项护栏恶化超过约定容忍度，即使平均准确率提高，也要阻止发布。

把变更当作政策变更治理

规则编码运营政策。更新规则可能改变哪些产品可以发布、哪些声明获准使用，以及哪些团队接收工作。因此，规则变更需要负责人、理由、生效日期、测试和与影响程度相称的批准。

模型变更需要类似的纪律，但测试内容不同。我们用标注案例评估提取和表述，包括对抗性输入和低质量输入；也测试结构化输出契约：未知字段、无效类型和缺失证据都必须以安全方式失败。

部署应逐步推进。影子模式在不改变记录的情况下比较新路径，然后面向有限分群上线；护栏保持有效时，再扩大部署范围。写入适配器强制落实幂等性、最小权限和回滚。任何模型都不能直接、不受限制地访问权威记录系统。

能够规模化的职责划分

可持久使用的架构不是“AI 对规则”，而是有意识的职责划分。

模型把多变的证据转化为候选值，把已批准的事实转化为有用的语言。规则表达可重复执行的政策。人处理歧义、批准高影响变更，并在异常暴露缺口时改进政策。事件日志把每项决策连接到证据和版本化逻辑。

这种设计更容易向管理层解释，因为风险受到动作和证据的约束；更容易构建，因为组件具有可测试的契约；也更容易运营，因为失败原因变得具体：提取遗漏了值、来源不符合要求、规则拒绝某个组合，或授权审核者覆盖了一条警告。

企业产品数据永远不会完全干净或统一，也不必如此。系统需要知道什么是观察结果、什么是推断、什么获准使用，以及谁作出了决定。确实需要理解的地方用 AI；企业已经知道如何明确表达决策的地方用规则。