ODD

摘要：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，目前是一个单人周末开源项目（文末链接）。 它想做的事情很朴素：把散落在各种公开资料里的辅助驾驶和自动驾驶的运行边界，整理成一张可查、可比、可追溯的开放表格。 它不是智驾排行榜。它不是智驾排行榜。它不是智驾排行榜。 也不是安全认证。 它只回答一个更基础的问题： ...

摘要：2026 年 Q1，Harness Engineering 在 OpenAI、Anthropic、明日新程 Nextie 几乎同步出现，“12 Primitives"在社区收敛为新的隐性共识。本文论证：主流路线对 Harness 的投入几乎全部集中在"用户体验、性能、效率"维度；而 Safety-Critical 场景里决定能否上市的"安全合规"维度几乎没有被任何商业玩家系统性投入。本文用 12 Primitives × SOTIF / ISO 21448 的双向映射建立桥梁，并识别 12 条可深入研究的方向，作为标准组织、企业预研团队、第三方机构、研究机构共同补位"安全合规维度 Harness"的起点。本文约一万字，公众号上有约 3000 字的精简版。 一、引子：两条线索的同时浮现 最近两个月，“Harness Engineering"这个词在两个完全不同的圈子里被高频讨论。 1.1 AI 工程圈的密集信号 2026 年 2 月，OpenAI 官方博客《Harness Engineering: Leveraging Codex in an Agent-First World》第一次把这个概念从隐性共识变成正式术语。同年 3 月，Anthropic 推出 Managed Agents 架构，技术文档反复强调"Agent Harness"作为一等工程对象。4 月，明日新程 Nextie 在一个月内连融两轮，陆奇和李开复罕见同框入场，核心叙事是"群体智能 + Harness”。同月新智元一篇《最新风口 Harness，李开复、陆奇已重金入场》把 Harness 推成产业热词。 与此同时，GitHub 上的 awesome-harness-engineering 仓库把 12 个原语（Agent Loop、Planning、Context Delivery、Tool Design、Skills/MCP、Permissions、Memory、Task Runners、Verification、Observability、Debugging、HITL）从社区隐性共识收敛成了一份分类法。 1.2 汽车行业的低调但明确的同期信号 汽车行业的信号则相对低调但同样明确。头部智驾公司不约而同地在加码模型输出可解释性与透明度相关工作，把它定义为未来 5–10 年的核心战略。越来越多的车企技术团队开始在内部文件里讨论 Harness。 ...