OPEN STEWARDSHIP

共建 OpenODC

这个项目已经完成了第一版结构，但它不应该停留在个人维护的状态。下一步需要更多有标准工作、智驾开发、测试评价、功能安全、数据工程和开源运营经验的伙伴，把它做成一个实时更新、权威可信、行业共享、开源开放的平台。

WHY NOW

OpenODC 需要从个人项目变成公共基础设施

ODC 的价值不在于做一次性样例，而在于持续跟踪用户手册、功能版本、运营规则、监管材料和厂家确认版本。这个工作需要行业经验、标准意识和长期维护机制，而不是靠某一个人偶尔补数据。

邮件联系 → GitHub 讨论 →

定期跟踪用户手册、功能说明、配置表、OTA 说明和政府运营规则，维护 Tesla、华为、小鹏、萝卜快跑、小马智行等样例的证据日期和覆盖率。

维护 GB/T 45312—2025 与 ISO 34503、ASAM OpenODD、BSI PAS 1883、SAE J3016 等标准之间的术语和结构映射。

从量产功能、系统限制、驾驶员接管、L2 / L3 / L4 语义边界角度审查样例，防止把辅助驾驶写成自动驾驶。

推动 OEM、Tier 1、测评机构、学会或标准化组织提交可公开的 ODC 字段，建立 vendor-confirmed 的确认机制。

把手册导入、证据抽取、差异对比、版本更新、链接检查和发布审核做成自动化流水线，减少人工维护成本。

维护英文术语、国际标准对照、英文页面和海外社区沟通，让 OpenODC 不只是中文语境里的项目。

给每个样例设置证据核验日期、来源状态和更新责任人，避免样例随着 OTA 和手册版本变化而过期。

把用户手册、PDF、配置表和运营规则自动归纳到 144 个 ODC 要素中，输出证据句、页码、阈值和未明确项。

设计企业域名验证、联系人角色、公开字段确认、脱敏说明和管理员审核机制，让厂家不必依赖 GitHub。

明确样例合并标准、错误更正时限、审阅人制度、数据许可和利益冲突披露，让平台长期可信。

OpenODC 只描述公开边界和证据缺口，不给车型或企业打分。

每个关键要素都应能回到手册、官方页面、运营规则、监管材料或明确标注的推定来源。

L2 只描述功能适用条件，不能写成系统承担动态驾驶任务。

代码开源、数据开放，但高置信样例必须经过来源、术语和语义边界审查。