第五篇 治理：场景命名编码与版本演进

一、为什么需要"治理"

5 层架构本身不是问题。真正的问题是当 100 家公司、1000 个采集团队、10000 个采集员同时使用这套架构时，它会不会乱、怎么不乱。

我们看一下不治理会出什么乱子：

所以——治理 ≥ 架构。这一篇不写好，前面 22 章的努力都会被冲淡。

二、ID 分配：谁来分配、按什么顺序

2.1 三级分配机制

2.2 ID 编号顺序的潜规则

不要按"申请顺序"分配 ID——这样会让"新场景塞在末尾"，老场景常占低号但实际过时。

正确做法：

• 同一上层下，**按"本领域内最常见 → 最罕见"**排列。
• 每一层预留 50% 空位（即 99 个位置只用约 50 个）。
• 重大版本（v2.0、v3.0）允许"重排"，但必须给出旧 ID → 新 ID 映射表。

2.3 ID 占位与保留

• D00 / S00：预留给"跨场景的公共动作"（如"打开门""按按钮""走路"），不归属任何具体场景。
• D99 / S99：预留给"实验中场景"（草案）。
• C00 / T00 / A00：预留给"无情境约束""无任务分组""无动作细分"的占位符。

三、版本号策略

3.1 三段式版本号

v{MAJOR}.{MINOR}.{PATCH}

3.2 升级节奏

3.3 升级公告

每次发布版本，必须公告：

• 变更摘要
• 新增 ID 列表
• 废弃 ID 列表（含原因）
• 重命名 ID 映射表
• 已知问题
• 升级建议（建议什么时候迁移）

四、新场景如何审批入库

4.1 5 步审批流程

flowchart LR
    A[① 提案] --> B[② 命名审查]
    B --> C[③ 公开 RFC<br/>14 天]
    C --> D[④ 编委会决议]
    D --> E[⑤ 入库公告]

4.2 命名审查 7 条

新场景命名必须通过以下检查：

1. 名称简洁（≤6 字）。
2. 不包含厂商名 / 品牌名 / 商标。
3. 不包含技术术语（如"DDPG"），只用业务语言。
4. 不与现有场景重名。
5. 中英文双语对照。
6. 一句话定义明确。
7. 至少有 1 家公司或团队"已经在做"。

4.3 提案模板（详见附录 E）

proposed_id: D04-S09
proposed_name_zh: 自动驾驶配送
proposed_name_en: Autonomous Delivery
domain_parent: D04
short_description: 末端配送中无人车 / 无人机辅助场景
why_needed: 多家厂商已开展，需统一编码
example_tasks:
  - 货物装载
  - 路径监控
  - 取件交付
similar_existing: D04-S06 末端配送
overlap_explanation: S06 是人工配送，S09 是无人车配送，两者并行
proposer: 张三 / XX 物流公司
date: 2026-04-15

五、老场景如何"退役"

5.1 退役 4 状态

flowchart LR
    Active[Active 在用] --> Deprecated[Deprecated 不推荐]
    Deprecated --> Sunset[Sunset 即将下架]
    Sunset --> Retired[Retired 已退役]

5.2 退役公告 5 要素

• 原因（合并 / 过时 / 行业消失）
• 替代 ID（如有）
• 老数据迁移方案
• 时间表
• 联系方式

5.3 ID 不可复用原则

退役的 ID 永久标记，不分配给新场景。理由：

• 老数据集仍可能在使用旧 ID。
• 复用会造成"同一 ID 指代两件不同的事"，灾难性混淆。
• 编号空间足够（每层 99 个位置，预留 50% 空位），不缺号。

六、公司内部 SKU 与本书对接

6.1 三种对接模式

6.2 映射表模板

6.3 扩展使用模板

{本书ID}+{公司私有后缀}

例：D04-S03-C01-T05@JD-A1 表示"京东亚一仓的拣选扫码任务"。

后缀规范：

• 必须以 @ 分隔
• 后缀长度 ≤16 字符
• 不与本书 ID 字符冲突

七、跨语种命名

中文为本书主语言，但鼓励多语种。建议同时维护：

跨语种命名的 3 条规则：

1. 同一 ID 在所有语种下指代同一概念。
2. 翻译必须经过编委会确认。
3. 同一动作在不同语种下可以用最自然的本地化表达，不必逐字翻译。

八、数据集版本与场景库版本的解耦

很多团队会问：我的数据集 v3.2.1 必须用本书场景库 v1.5 吗？

答案是：解耦。

数据集应该在元数据里声明使用的场景库版本：

{
  "dataset_name": "JD-PickingDataset",
  "dataset_version": "3.2.1",
  "scene_book_version": "1.5.0",
  "compat_books": ["1.4.0", "1.5.0", "1.5.1"]
}

只要场景库的 MINOR 版本兼容，就可以直接用。

九、治理委员会

9.1 7 人编委会

建议构成：

• 2 名采集企业代表（鹿明 / 京东 / 蚂蚁等）
• 2 名机器人公司代表（智元 / 优必选 / 宇树等）
• 1 名学术界代表（高校 / 研究所）
• 1 名采集员代表（一线工人）
• 1 名独立监管 / 法务专家

9.2 任期

• 每届 2 年。
• 同一人最多连任 2 届。
• 编委会主席每届轮换。

9.3 决策机制

• 重大决议（MAJOR 升级）：≥5 票同意。
• 一般决议（MINOR 升级）：≥4 票同意。
• 紧急公告（PATCH）：秘书发布即可。

十、社区贡献

10.1 4 类贡献

• 提议新场景
• 修正现有定义
• 翻译多语种
• 撰写专题章节

10.2 贡献者署名

• README 末尾列出所有 v1.x 贡献者。
• 重大贡献（≥5 个新场景 / ≥1 个新章节）单独致谢。

10.3 PR 流程

1. Fork 仓库
2. 在 proposals/ 目录添加提案文件
3. 提 PR
4. 编委会审议
5. 合并入库

十一、本篇一图回顾

mindmap
  root((21 治理篇))
    ID 分配
      三级分配
      预留空位
      D00 S00 占位
    版本策略
      MAJOR 3-5年
      MINOR 季度
      PATCH 滚动
    新场景审批
      5 步流程
      命名7条
      模板入档
    老场景退役
      4 状态
      ID 不可复用
      公告 5 要素
    公司SKU对接
      完全采纳
      映射对照
      扩展使用
    跨语种
      中英为主
      解耦
    治理机构
      7人编委会
      任期2年
      贡献署名

十二、行动清单

• 如果你是公司，决定 6.1 三种对接模式 中选哪种。
• 如果你想提新场景，按 4.3 提案模板 准备草案。
• 关注本书每季度 MINOR 升级公告。

十三、自检三问

1. 为什么"ID 不可复用"是治理的核心原则？
2. 公司内部 SKU 与本书对接的 3 种模式各适合谁？
3. 编委会决议的"重大决议"和"一般决议"门槛分别是什么？

下一篇预告：第二十二篇 拓展篇，看 AGI 时代还有哪些"未来场景"等着被纳入。