结论先行

一个可用于采购、集成和运营的游戏目录，不应只是“厂商名 + 游戏名”的展示清单。它至少要回答五组问题：这条记录是谁、来自哪里、对应哪个版本、目前处于什么状态、由谁在何时复核。语言、币种、目标市场、认证与上线状态还必须分别记录，不能压缩成一个含义不清的“可用”。

现有游戏目录以 2026-08-07 名称级快照为基础，包含 11 个厂商、1,194 个游戏名称。该快照适合做前期内容浏览和目录治理起点，但不包含游戏代码、版本、数学模型、封面、试玩、接口字段、认证或实时可用状态，因此不能据此判断具体游戏的项目可用性。

目录数量与日期不改变快照性质，也不等于实时供货、生产开通、第三方授权或目标市场可用证明。

为什么名称清单还不是产品目录

名称可以回答“我们收集到了哪些条目”，却不能稳定地把一个条目连接到 API、版本变更、测试证据或目标市场。重名、改名、不同皮肤、相同游戏类型的不同数学模型，都可能让名称匹配产生错误。

目录治理的目标不是把字段填满，而是让每个结论都能回到一条带来源、时间和责任人的记录。当信息缺失时，正确的值是“待核验”，不应根据第三方页面、文件名或经验补全。

建议的最小数据模型

下表是一套可用于目录治理的字段模型。字段可以拆分到多张表，但语义和责任不应丢失。

字段组 最小字段 回答的问题 使用提示
稳定身份 catalog_record_id、provider_id、provider_game_code、game_name、game_type 这条记录唯一指向什么？ 建立稳定标识，避免重名
来源 source_ref、source_type、source_snapshot_at、source_hash 信息来自哪里，何时取得，能否核验？ 保留来源与日期
游戏版本 game_version、math_model_version、client_build、release_note_ref 当前验证的是哪一个软件和数学模型？ 关联实际交付版本
集成版本 provider_api_version、aggregator_version、integration_version 哪条接口链路与该游戏版本配套？ 记录完整连接链路
记录状态 record_status、status_reason、effective_from、effective_to 该记录在目录生命周期的哪个阶段？ 使用受控状态
交付状态 staging_status、production_status、demo_status、last_verified_at 在指定环境是否有实际验证结果？ 按环境分别记录
支持维度 language_codes、currency_codes、device_scope 哪些语言、币种和设备经过核验？ 不从名称推断
市场与认证 market_code、operator_scope、certificate_ref、certificate_scope、certificate_status 指定对象、版本和范围有什么资料？ 与目标市场逐项关联
权利与限制 content_rights_scope、territory_restriction、usage_restriction、evidence_ref 展示、试玩、分发或目标市场使用有何边界？ 单独记录权利范围
责任与复核 data_owner、reviewer、updated_at、next_review_at、change_reason 谁维护，谁确认，何时再核验？ 保留更新责任与时间

三类 ID 不应混用

  • catalog_record_id 是目录中的稳定记录 ID，即使名称改变也应保持可追踪。
  • provider_game_code 是厂商或上游接口使用的游戏标识，必须来自可验证的接口或交付资料。
  • 页面路径或营销别名只负责展示，不应成为交易、认证或版本关联的主键。

来源、状态、版本、更新与责任

1. 来源必须可回溯

每次导入至少保存来源类型、来源位置或文档编号、截点时间和导入批次。若来源后来被替换，也要保留旧记录的有效期，而不是覆盖历史。第三方页面可用于发现待核验字段，但不能作为授权、版本或实时可用性的唯一依据。

2. 状态必须带对象和维度

建议记录状态采用以下受控值：

状态 含义 可以对外表达什么
draft 已建记录，但关键身份或来源未完成复核 不公开
pending_verification 已有候选资料，仍缺验证证据 仅表达“待核验”
verified_current 在指定版本、环境和日期完成核验 只表达已核验范围
suspended 因证据过期、异常或限制暂时停用 不表达当前可用
retired 已结束维护或被新版本替代 可保留历史，不作为当前目录

“已收录”“staging 已验证”“production 已启用”“目标市场可提供”是不同状态。任何一个状态都不能自动推出另外三个。

3. 版本变化必须触发影响检查

游戏版本、数学模型、RGS 或聚合层、API 协议、币种规则、语言资源及目标市场要求发生变化时，都应触发影响检查。检查结果需要关联新的测试或认证资料；不能默认旧版本结论自动继承。

4. 更新流程必须留下责任链

建议最小流程为：

  1. 数据维护人导入或提出变更，并附来源与变更原因；
  2. 系统检查稳定 ID、必填字段、重复项和受控状态；
  3. 技术、业务或合规责任人按字段范围复核；
  4. 通过后生成新版本或更新有效期，不覆盖历史证据；
  5. 到达复核日、来源失效或关键版本变化时自动回到待核验；
  6. 对外页面只读取已确认可展示的字段和状态。

建立目录时的优先顺序

从名称清单升级为可用于接入和运营的目录时，不应直接批量生成详情页。建议按使用价值逐步补充：

  1. 先补厂商稳定 ID、厂商游戏代码、来源记录和记录责任人；
  2. 再补实际集成所需的游戏版本、接口版本与 staging 验证状态；
  3. 对进入目标市场评估的游戏，单独补市场、运营主体、语言、币种、认证对象与有效范围；
  4. 封面、试玩、游戏介绍等展示字段只有在素材权利与来源确认后再进入发布流程；
  5. 每次只为有真实需求和完整证据的游戏生成详情内容。

目录页面当前提供什么

  • 2026-08-07 名称级快照包含 11 个厂商和 1,194 个游戏名称。
  • 厂商与游戏名称用于前期浏览和内容方向沟通。
  • 名称级快照不是实时库存、上线清单、版本库、授权库或认证库。
  • 本文提供的是后续数据治理所需的字段、状态和责任框架。

使用这些信息时需要注意什么

  • 不能承诺任一游戏当前可调用、可试玩、已上线或在 production 可用。
  • 不能证明任一厂商授权、素材使用权、目标市场许可或认证有效性。
  • 不能从语言、币种、接口可连接或目录收录推导市场合法性。
  • 不能补造游戏代码、RTP、版本、数学模型、封面、试玩链接或认证编号。

FAQ

目录中有一个游戏名称，是否代表可以立刻接入？

不代表。名称只证明该条目被某个来源收录。是否可接入还要核验游戏代码、接口与游戏版本、环境状态、商务权限以及目标市场条件。

为什么游戏版本和数学模型版本要分开记录？

界面或客户端版本变化不一定改变数学模型，数学模型变化也可能需要新的测试和认证判断。拆开记录才能确定既有证据实际覆盖哪个对象。

缺失字段可以从厂商官网或第三方目录自动补齐吗？

可以把公开页面作为候选线索，但必须保存来源并进入待核验状态。只有经适用资料、实际接口或项目责任人确认后，才能用于具体项目判断。

目录多久更新一次？

不应只依赖固定周期。除计划复核外，来源变化、版本发布、状态异常、证据到期和目标市场规则变化都应触发复核。

延伸阅读与下一步

统一下一步：联系我们前，请提供目标市场、拟接入厂商或游戏范围、钱包模式和预计环境。AG 再按具体范围返回需要核验的目录字段与证据清单；该动作不代表供货、授权或上线承诺。

参考资料与适用说明

使用说明：目录数量仅对应 2026-08-07 快照；用于具体项目时应确认记录状态、展示权利和目标市场相关资料。

需要把指南转成项目方案？

文章用于帮助团队梳理采购和接入问题，不替代技术、合同、认证或当地法律确认。

联系我们