一、背景：把一句定义变成一个系统

儿童玩具的通用监管定义可以概括为：设计或预定供14岁以下儿童玩耍、经过加工制作并用于销售的产品，但生产者明示不供儿童玩耍的除外。这句话看似只是法规条文，落到工程侧，其实是一个典型的“文本规则 → 可计算分类”问题：给定一个商品，系统要自动判断它是否属于儿童玩具、属于哪个年龄分段、是否需要人工复核。

这个能力在多类场景中有直接价值：

• 电商平台：商品入驻与类目治理，防止风险玩具错挂类目、警示信息缺失；
• 制造企业：产品主数据管理，出库、包装、说明书的合规联动；
• 质量与召回：一旦发生召回，可按年龄分段、批次快速圈定受影响商品。

下面按照“要素拆解 → 数据建模 → 规则引擎 → 分级与复核 → 架构与工程实践”的顺序展开。

二、合规要素的形式化拆解

把定义逐句拆开，可以提炼出四个可计算的判定要素：

1. 销售属性：经过加工制作并用于销售。它排除了家庭自制、纯展示用途的物品。对应字段：processed_for_sale（布尔）。
2. 用途属性：供儿童玩耍。这是最模糊的一项，纯靠人工描述不可靠。工程上通常用“玩耍特征得分”量化：是否以娱乐为主要功能、是否包含游戏玩法、品类关键词命中情况等，加权得到 play_feature_score。
3. 年龄属性：14岁以下。表现为商品声称的适用年龄区间，如3~6岁、6~12岁。注意14是监管阈值，应做成可配置参数，而不是硬编码。
4. 排除条款：生产者明示不供儿童玩耍。这是唯一能“一票否决”的要素，但“明示”必须有证据：包装警示语、销售页声明、正式声明文件。系统必须保存证据影像与时间戳，避免纠纷时无据可查。

一个重要的设计原则是：排除条款优先于正向规则。只要声明有效，先判“非儿童玩具”，再做其他判断，这与条文的语义顺序一致。

三、数据模型设计

核心实体是商品与生产者声明，示意性结构如下：

{
  "sku": "SKU-2024-0001",
  "category": "拼插积木",
  "processed_for_sale": true,
  "play_feature_score": 0.92,
  "declared_age_min": 3,
  "declared_age_max": 12,
  "producer_disclaimer": {
    "declared": false,
    "evidence_urls": [],
    "declared_at": null
  },
  "risk_flags": ["small_parts"]
}

几个设计要点：

• declared_age_min/max 允许为空，但字段缺失时不能默认放行，应进入人工复核，即“缺失即从严”；
• producer_disclaimer 是内嵌对象而非简单布尔值，因为排除判定依赖证据链，单纯一个 true/false 在审计时站不住脚；
• risk_flags 记录小零件、磁性部件、尖锐边缘等行业通用的风险维度，供后续年龄分级与提示语生成使用。

四、规则引擎与判定流程

规则建议用“条件 + 排除 + 结论”的三段式表达，并支持优先级，便于运营人员而非开发者调整。规则示意如下：

{
  "rule_id": "toy-core-001",
  "priority": 10,
  "when": {
    "all": [
      {"field": "processed_for_sale", "op": "==", "value": true},
      {"field": "play_feature_score", "op": ">=", "value": 0.8},
      {"field": "declared_age_max", "op": "<", "value": "${AGE_LIMIT}"}
    ]
  },
  "unless": [
    {"field": "producer_disclaimer.declared", "op": "==", "value": true}
  ],
  "then": {"label": "CHILDREN_TOY"}
}

用伪代码描述整体判定流程：

AGE_LIMIT = 14  # 可配置的监管阈值
def classify(product):
    # 1. 排除条款优先
    if product.disclaimer_declared and product.evidence_valid():
        return "NON_TOY"
    # 2. 销售属性校验
    if not product.processed_for_sale:
        return "NON_TOY"
    # 3. 正向规则：玩耍属性 + 年龄属性
    if product.play_feature_score >= 0.8 \
            and product.age_max is not None \
            and product.age_max < AGE_LIMIT:
        return "CHILDREN_TOY"
    # 4. 不确定样本进入人工复核
    return "MANUAL_REVIEW"

流程中有两点值得强调：

• 三态输出优于二态输出。CHILDREN_TOY / NON_TOY / MANUAL_REVIEW 的三态设计，把规则拿不准的样本显式交给人工，避免“宁可错杀”或“默认放行”两种极端；
• 阈值集中管理。0.8、14 这类参数全部收口到配置中心，规则变更可灰度、可回滚。

五、年龄分级与风险提示

判定为儿童玩具后，通常还要做年龄分段，供页面展示、警示语生成与召回圈选使用。业界常见的分段方式是 0~3、3~6、6~12、12~14，分段依据除声称年龄外，还应结合风险标记：

• 含小零件且声称下限年龄低于3岁 → 高风险，强制提示窒息风险；
• 含磁性部件 → 提示误吞风险；
• 电动类目 → 补充电池与充电安全提示。

这些提示语应由规则引擎统一生成、统一版本管理，避免各业务线文案不一致带来的合规瑕疵。

六、系统架构与工程实践

推荐分层架构：

1. 接入层：商品入驻、信息变更申报入口，负责字段校验与证据上传；
2. 规则计算层：无状态规则服务，输入商品快照，输出判定结果与命中规则ID；
3. 人工复核层：复核工单系统，规则结果与人工结论都会回流为标注样本；
4. 审计追溯层：完整记录“当时用了哪个版本的规则、输入是什么、结论是什么”。

在基础设施上可以复用通用云能力：对象存储存放声明文件与检测报告影像；消息队列承接商品变更事件，削峰后异步触发重判；日志服务留存判定轨迹；监控告警跟踪规则命中率与复核积压量——命中率突降往往意味着字段采集出了问题。

工程实践中的几个高频坑：

• 重判时机：生产者声明、年龄标注发生变更时必须触发重判，否则“明示除外”会退化为“历史除外”；
• 组合商品：套装类商品应按组件中风险最高的结论判级，而不是取平均；
• 跨境场景：不同司法辖区对年龄界限与测试要求不同，AGE_LIMIT 等参数应按辖区维度配置；
• 指标监控：关注自动判定准确率、误判率、人工复核率、平均判定时长四项指标，复核率持续走高通常是数据质量恶化的信号。

七、总结

儿童玩具的定义只有一句话，但把它落成系统，需要完整的要素拆解、数据建模、规则引擎与复核闭环。核心经验可以浓缩为三条：条文语义顺序决定规则优先级；证据链与审计日志是合规系统的底线；三态输出加参数化阈值，让系统在准确与灵活之间取得平衡。这套方法论并不局限于玩具类目，任何“法规定义 + 商品分类”的合规场景都可以直接复用。