摘要：OpenODC 是一个把 GB/T 45312—2025《智能网联汽车 自动驾驶系统设计运行条件》落地成机器可读公共数据集的开源项目。目前包含 144 个 ODC 要素 Schema、6 个公开样例库（Tesla FSD Supervised、Tesla 中国区辅助驾驶、华为乾崑 ADS 4、百度萝卜快跑武汉示范运营、小鹏 XNGP、小马智行 Gen-7 Robotaxi）、横向矩阵、双视图（开发者 / 消费者）、以及未来的厂家资料工作台。本文是这个项目的起点说明，也是一封欢迎共创、必要时可以无偿交接的公开邀请。
如果一个车企说自家的智驾系统"全国都能开"，我现在最想问的不是它能开到哪里。
我更想问：
- 它不能在哪里开？
- 什么天气要退出？
- 遇到施工、积水、车道线不清、传感器遮挡，系统到底怎么处理？
这些问题不如"有路就能开"“车位到车位"“全场景"好传播。
但安全往往就藏在这些不太适合做标题的细节里——当然更不是 PPT 右下角的小字备注里 😅。
一、ODC 到底是啥？
设计运行条件（Operational Design Conditions，ODC），包括运行设计范围 ODD、驾乘人员状态和车辆状态。
国标 GB/T 45312—2025《智能网联汽车 自动驾驶系统设计运行条件》 对 ODC 进行了详尽的阐述（文末有官方标准解读）。
但我们不用陷进标准术语。换成大白话，ODC 就是一张边界清单：
- 这个功能被设计在什么道路、什么速度、什么天气、什么光照、什么交通参与者条件下使用。
- 哪些情况不建议使用，哪些情况应该降级，哪些情况应该提示驾驶员接管，哪些情况系统本来就没有公开说清楚。
消费者真正需要的，不只是"这个功能很强”。
还包括——”这个功能在什么情况下不该被依赖"。
这就是我做 OpenODC 的起点。
二、OpenODC 是什么？
OpenODC，目前是一个单人周末开源项目（文末链接）。
它想做的事情很朴素：把散落在各种公开资料里的辅助驾驶和自动驾驶的运行边界，整理成一张可查、可比、可追溯的开放表格。
它不是智驾排行榜。它不是智驾排行榜。它不是智驾排行榜。
也不是安全认证。
它只回答一个更基础的问题：
公开资料到底把一个功能的运行边界讲清楚了多少？
比如 Tesla 的 FSD Supervised，美国公开手册里哪些限制可以查到？
比如中国市场的 Tesla 辅助驾驶，车主手册把哪些条件说清楚了？
比如萝卜快跑在武汉的 Robotaxi 示范运营，政府规则和公开资料能支撑哪些 ODD 边界？
这些信息原本分散在手册、官网、配置表、政府公告、运营规则和免责声明里。OpenODC 做的是把它们放进同一套框架。
三、OpenODC 做了几件事
3.1 把 ODC 标准做成机器可读 Schema
把 GB/T 45312—2025 的 ODC 要素做成机器可读 Schema。也就是说，ODC 不再只是 PDF 标准里的文字，而可以被校验、对比、渲染和导出。
3.2 公开样例库
目前包括 6 个样例：
- Tesla FSD Supervised（美国）
- Tesla 中国区辅助驾驶
- 华为乾崑 ADS 4
- 百度萝卜快跑武汉示范运营
- 小鹏 XNGP
- 小马智行 Gen-7 Robotaxi
这是 AI 辅助选择的，覆盖几个公开信息相对完整的"智驾系统"。
需要明确的是：这些都不是厂家官方 ODC 声明。它们是基于公开资料反推整理的高置信草稿。每个关键元素都尽量回到用户手册、官方网页、政府运营规则或明确标注的推定来源。
3.3 横向矩阵
把 144 个国标要素和多个样例横向摆在一起，看哪些要素被公开资料覆盖了，哪些是缺口，哪些只是推定。
3.4 “开发者 + 消费者"双视图
- 开发者视图：保留完整层级、JSON 和标准条款。
- 消费者视图：尽量讲人话——什么时候建议使用，什么时候不应使用，哪些情况可能退出。
3.5 厂家资料工作台（设计中）
未来更合理的流程，不是厂家工程师手填 100 多行的静态表格，而是：
导入资料 → 自动抽取 ODC 草案表 → 标出证据句、页码、阈值和未明确项 → 由厂家确认哪些字段可以公开。
OpenODC 不想做安全认证，也不想做智驾排行榜。它真正想做的，是一个公共坐标系：
- 同一套标准。
- 同一套证据规则。
- 同一套机器可读格式。
- 同一套持续更新机制。
真正值得开源的，不是结论，而是边界、证据和更新机制。
四、这个想法，拖了太久
我参与了 GB/T 45312 部分章节的撰写。在标准制定的讨论会上，我就有一个很强烈的感觉：ODC 如果只停留在标准 PDF 里，它当然有价值，但离行业真正用起来还差一步（可能其他很多标准也是同理）。
标准解决的是"应该怎么定义”。 行业每天面对的，却是另一个问题：
- 某个车型的高速 NOA，到底能不能在施工区用？
- 一个 Robotaxi 在某个城市开放运营，地理围栏、天气限制、远程协助边界，公开资料到底说清楚了多少？
- 用户手册里写"雨雪雾可能影响功能"，那它对应到 ODC 要素里，是天气的量化边界、速度限制、道路标线的遮盖程度，还是退出行为？
这些问题，靠读标准本身解决不了。
那时候我其实已经想做 OpenODC。
但说来惭愧，一直拖着。
原因不复杂：我没有网站设计经验，也没有专门团队。一个人既要做教学科研、量产项目，还有很多探索的爱好和想法，又要把 144 个 ODC 要素做成网页、样例库、编辑器和对比矩阵——过去看起来确实不现实。
五、AI 消灭了起步的门槛，但真正的门槛还在后边
这次 OpenODC 能跑起来，很大程度上是因为 AI 工具逐渐成熟了。
页面怎么排，中英文怎么切，JSON 怎么渲染，样例库怎么筛选，矩阵怎么做，链接怎么查，手机端会不会崩——这些过去会消耗大量时间的事情，现在可以用"与 Claude Code 聊天"来完成。
但做完以后，我反而更清楚地看到：网页不是门槛。
真正的门槛，是底层逻辑和长期治理。
L2 辅助驾驶的 ODC，描述的是功能适用条件，驾驶员仍然要负责动态驾驶任务。L3、L4 自动驾驶的 ODC，才涉及系统在特定运行域内承担动态驾驶任务。
如果这里写错，页面做得再漂亮，也是在制造误解。
需要注意的是，“智驾"不是一个专业词汇，本文提到的"智驾"是"L2 辅助驾驶和 L3/L4 自动驾驶"的简称。传统 L2 辅助驾驶功能运行条件相对简单，通常由车厂根据具体功能定义适用场景，不用严格遵循 GB/T 45312—2025（针对 L3 及以上自动驾驶系统）的 ODC 规范。但当下的 L2 组合驾驶功能"越来越强大”，个人认为有必要参考 ODC 国标界定功能适用条件。
即将实施的强制性国家标准《智能网联汽车 组合驾驶辅助系统安全要求》也明确规定：车辆制造商应按照 GB/T 45312 对系统和功能的 ODC 元素进行说明。
AI 降低了做网页的门槛，但没有降低理解自动驾驶边界的门槛。
六、现在有了雏形，也暴露了缺口
OpenODC 现在有 6 个公开样例，覆盖 L2 辅助驾驶和 L4 Robotaxi 场景。
它把 GB/T 45312—2025 的 ODC 体系整理成 144 个要素，并给每个样例尽量附上公开证据。
目前站内有 346 条逐项证据引用，其中 97 个来自官方、手册或政府文件的高置信项。
但我最在意的数字不是 346，也不是 97。
是 0。
0 个厂家确认版本。
这不是批评谁。恰恰相反，它说明 OpenODC 还只是一个公开草稿和方法验证。社区可以基于公开资料反推样例，但长期可信的平台，最终需要厂家确认、机构审阅和持续更新。
而这件事，一个人做不动。
七、欢迎共创，也可免费交接
如果有合适的个人、团队、学会、研究机构、测评机构、开源组织，甚至某家公司，愿意长期维护 OpenODC，我可以把这个项目完全免费交接出来。
包括现有仓库、网站结构、样例库、Schema、工具链、方法说明和后续维护思路，我都可以配合交接。
我不想把它烂在手里，成为永久半成品。如果它能由更合适的组织长期维护，那就太棒了。
但有几条底线：
- 保持开放。
- 证据优先。
- 不做智驾能力排行榜。
- 不做某一家公司的营销工具。
- 不把 L2 辅助驾驶写成自动驾驶。
- 不把"公开资料覆盖率"包装成"厂家披露率"。
只要这些底线能守住，OpenODC 最好的归宿，本来就不应该是"AutoZYX 个人作品"。
八、我在找什么样的人
如果你做过标准工作，知道一个术语被写错会带来多少后续麻烦，我希望你来。
如果你做过智驾开发，知道功能边界、接管条件、退出策略不是随便写几句话，我希望你来。
如果你做过功能安全、SOTIF、测试评价、仿真、数据工程，知道"证据"和"推定"不能混在一起，我希望你来。
如果你在学会、测评机构、研究团队、开源社区或企业里，觉得这个项目可以被你们长期接住，也欢迎直接来谈。
不用一开始承诺很多。
你可以先从一个样例、一条来源、一个术语翻译、一个错误修正开始。
入口
OpenODC 网站：openodc.autozyx.com
OpenODC GitHub：github.com/AutoZYX/OpenODC