让一辆车的数据，走完它该走的路

引言

一辆自动驾驶汽车，每天产生 TB 级的数据。这些数据要被采集、传输、标注、清洗、训练、验证、回流——每一个环节，都是一次「数据的旅行」。

ASD（Apollo Self-Driving Data）是百度智驾云的核心平台，让这趟旅行可以被研发团队看见、追踪、干预。

我用了三年时间，把这套复杂的数据流，变成一套人能读懂的视觉秩序。

背景与挑战

背景

自动驾驶研发的核心瓶颈，不是算法，是数据。

模型训练需要海量标注数据，但研发团队面对的现实是：

• 数据散落在不同传感器和场景里，找不到也对不齐
• 标注流程长、协作角色多，问题难以追溯
• 设计语言不统一，每个子产品都在重复造轮子

挑战

作为 0 到 1 的 SaaS 平台，ASD 面对三个并发的设计命题：

1. 01

   如何让「数据流」这种抽象概念，被研发人员一眼读懂？

2. 02

   如何让数十个功能模块共用一套视觉语言，且不互相打架？

3. 03

   如何在 3 年、多版本的快速迭代里，保证设计不返工、不失控？

过程

6.1 拆解：把「数据闭环」翻译成视觉语言

我做的第一件事，不是画图，是画流程。

把数据从车端到云端的完整链路——采集 → 传输 → 标注 → 清洗 → 训练 → 验证 → 回流——拆成 7 个核心阶段、23 个子任务、超过 80 个数据状态。

每一个状态，都需要一个对应的视觉标识。

6.2 建系：从原子到系统的可视化组件库

ASD 的复杂度，决定了它不能靠"一页一页设计"来支撑。

我搭建了一套三层组件体系：

• Atom 层 ─ 基础原子（按钮 / 标签 / 状态点 / 数据卡）
• Module 层 ─ 业务模块（数据列表 / 标注面板 / 流程节点 / 审核流）
• Template 层 ─ 页面模板（标注工作台 / 数据看板 / 任务分配中心）

每一个组件，都同时定义了：视觉规范、交互行为、状态变体、研发实现路径。

这套体系上线后，新页面的设计-研发协作周期，从平均 5 个工作日，压缩到 1.5 个工作日。

6.3 决策：在三个关键岔路口的取舍

3 年里，我们做过很多取舍。其中三个决定，影响了整个平台的体验走向：

1. 01

   暗色还是亮色？

   研发场景长时间使用，我们做了 A/B 测试。最终选择「暗色为主 + 高对比度色板」，疲劳度数据下降 23%。

2. 02

   信息密度优先，还是留白优先？

   B 端工具的天敌是「看上去舒服，用起来费劲」。我们选择信息密度优先，但用栅格和层级把密度组织得有节奏。

3. 03

   要不要做「新手引导」？

   我们决定不做。研发用户是高频专家用户，引导反而是干扰。取而代之的是「快捷键体系」和「右键菜单」。

6.4 落地：让设计活在多版本的迭代里

ASD 在 3 年里迭代了 14 个大版本。设计师最容易掉进的陷阱是——版本越多，规范越乱，最后没人记得为什么这么设计。

我建立了三个机制来对抗这件事：

• 设计-研发双周对齐会 ─ 组件库与代码库同步更新
• 设计决策记录（Design Decision Log） ─ 重要变更必须留档
• 季度规范审计 ─ 每季度回看哪些组件被滥用、哪些被遗弃

最终方案

最终交付物

• 1 套完整的 ASD 设计系统（3 层架构 / 87 个组件）
• 14 个产品版本的视觉设计与体验迭代
• 1 套可视化组件规范文档（设计-研发双向使用）
• 1 套 Design Decision Log（截至离职时已记录 230+ 条决策）

成果与反思

可量化的影响

• 千万级数据吞吐｜支撑百度智驾研发数据闭环
• 设计-研发协作周期｜5 天 → 1.5 天（↓ 70%）
• 组件复用率｜78%（同类 B 端平台平均 < 50%）
• 视觉规范一致性评分｜内部审计 92 / 100
• 助力产品从 0 到 1 顺利量产交付

不可量化的影响

ASD 的设计系统，后来成为百度智驾云其他产品线（数据标注平台、模型评测平台、仿真平台）的视觉基底。

我搭建的不只是一个产品的设计，
而是一个产品线的视觉语法。

如果重做，我会怎么做？