享界 G9 L3 测试：开源社区的“透明”与“封闭”博弈

华为智选车产品总监彭磊试驾享界 G9 的 L3 功能测试车，并称体验“划时代”——这个表态在开源社区引发了一个微妙的问题：当“划时代”的技术突破发生在封闭的供应链里，我们如何验证它是否真的值得信赖。

作为长期关注自动驾驶开源生态的贡献者，我看到的是华为在测试透明度上的矛盾：一边是公开路测、认领视频、制造话题，另一边是核心算法、训练数据、场景库仍处于黑盒状态。这种“划时代”的体验，在社区看来更像是一个限定版的演示，而非可复现的工程成果。

从“划时代”到“可复现”——L3测试的透明度问题

彭磊提到的“划时代”体验，很可能基于华为在端到端感知、规控融合上的突破。但开源社区衡量技术价值的标准从来不是“有多好”，而是“有多容易验证”。一个典型的开源项目，比如 Carla 仿真器，每次发布都会附带详细的 benchmark 结果和复现步骤。

华为的 L3 测试车贴上标签上路，这种“路演”值得肯定，但缺乏社区参与式的验证机制。在 GitHub 上，我们习惯用 compare 视图对比不同 commit 的性能差异，而华为的“划时代”体验，目前只能依赖产品总监的试驾笔记。

[!info] 社区视角
一个真正的“划时代”技术，应当提供可复现的测试环境。华为可以考虑开放部分场景库，就像 Apollo 开放了“Scenarios”文件夹一样，让开发者用同样的条件跑一遍测试，而不是只展示剪辑后的视频。

华为的测试车：是黑盒还是开源参考实现？

从曝光的视频来看，享界 G9 的测试车配置了激光雷达、毫米波雷达、摄像头等传感器，并印有“L3 级自动驾驶道路测试”字样。这让我想起 Waymo 早期在 GitHub 上开源的 Open Dataset，以及 Tesla 的硬件参考设计。华为的硬件方案大概率是自研的，但软件层面有没有可能借鉴开源社区的做法？

设想一个开源参考实现的结构：

享界G9_L3_architecture/
├── perception/
│   ├── lidar_processing (基于 PointPillars)
│   ├── camera_fusion (基于 BEVFormer)
│   └── radar_filter (基于 Kalman)
├── prediction/
│   ├── trajectory_forecast (基于 Transformer)
│   └── interaction_model (基于 Social LSTM)
├── planning/
│   ├── behavior_planner (基于规则+学习)
│   └── motion_controller (基于 MPC)
└── system/
    ├── safety_monitor (基于 Formal Verification)
    └── hmi_interface (基于 ROS2 消息)

如果华为能将这套架构以模块化的方式开源，哪怕只提供部分组件的接口规范，都能极大推动社区对 L3 安全性的讨论。但现实是，华为选择了一条封闭路线：所有代码跑在自家的 MDC 计算平台上，不暴露任何 API 给外部开发者。这使得“划时代”体验成了“黑盒里的奇迹”，社区无法通过 Pull Request 来改进它。

社区治理视角：L3 汽车的“Pull Request”谁来审核？

L3 级自动驾驶意味着系统在特定条件下承担全部责任，一旦发生事故，责任归属是关键。在开源社区，我们通过 Review 机制和 CI/CD 流水线来保证代码质量。但汽车安全不同于软件 bug —— 一个错误的 merge 可能导致人身伤害。

华为的治理模式是“中心化”的：所有决策由内部专家团队做出，消费者只能被动接受。而开源社区推崇“分布式”治理：每个贡献者都可以提出改进，通过 Peer Review 和测试覆盖率来保证质量。对于 L3 汽车，这种社区治理模式显然不现实，但可以借鉴其“透明度”原则。

比如，华为能否公开 L3 系统的“安全冗余设计文档”和“失效模式分析”？能否像 Linux 内核一样，定期发布“安全公告”描述已知漏洞和修复方案？这些做法不需要代码开源，但

原文链接：华为智选车产品总监彭磊试驾享界 G9 的 L3 功能测试车，称体验“划时代” - IT之家