路测团队角色与职责：测试工程师、系统工程师、数据标注员的分工
实车路测不是一个人能搞定的事。我见过不少新入行的朋友，以为路测就是拿着电脑坐副驾，跑几圈就完事了。其实，一个成熟的路测团队，至少需要三个角色紧密配合——测试工程师、系统工程师、数据标注员。今天我们就聊聊这三者的分工，以及他们之间怎么协作。
核心观点：路测团队不是流水线，而是一个三角协作模型。任何一角薄弱，整个路测闭环就会出问题。
为什么需要明确分工？
说白了，路测的本质是「发现问题 → 定位根因 → 修复验证」的循环。一个人干不了所有事，原因很简单：
- 精力有限：开车、看数据、记场景、分析日志，一个人同时做这些，很容易漏掉关键信息。
- 技能差异：测试工程师擅长「找问题」，系统工程师擅长「分析问题」，数据标注员擅长「整理问题」。术业有专攻。
- 责任清晰：出了问题，谁负责测试执行？谁负责根因分析？谁负责数据准备？分工明确了，扯皮就少了。
我在早期项目里就吃过这个亏。当时团队小，测试和系统分析都是一个人干。结果有一次路测发现AEB误触发，我一边开车一边记日志，差点追尾前车。嗯，从那以后，我再也不提倡「全能型」路测了。
三个角色的核心职责
我们先看一张整体框架图，再逐个展开。
测试工程师：路测的「眼睛」
测试工程师是路测的第一道防线。他们的工作，说白了就是「在路上找茬」。
主要职责
- 测试执行：按照测试用例和场景列表，在真实道路上执行测试。包括城市道路、高速、乡村、夜间、雨雾等各种工况。
- 问题发现与记录：发现车辆行为异常时，第一时间记录时间戳、场景描述、车辆状态。我习惯让测试工程师用语音记录，比手写快得多。
- 数据采集：确保传感器数据（摄像头、激光雷达、毫米波雷达）、车辆CAN信号、定位信息完整采集。数据丢了，后面分析就是白搭。
- 初步分类：对发现的问题做初步分类——是感知问题？规划问题？还是控制问题？不需要精确，但方向要对。
我的经验：测试工程师最容易被忽视的技能是「场景描述能力」。我曾经带过一个测试，每次报问题就写「车辆异常减速」，但不说是在什么场景下、前方有什么目标、自车速度多少。这种描述对系统工程师来说，基本等于没报。
系统工程师：路测的「大脑」
系统工程师是问题定位的核心。测试工程师发现问题，系统工程师负责搞清楚「为什么会这样」。
主要职责
- 日志分析：拉取路测数据，分析传感器原始数据、算法输出、决策规划轨迹、控制指令。我常用的工具是ROS bag分析 + Python脚本 + 可视化工具。
- 根因定位：从现象反推根因。是传感器误检？是融合模块丢帧？是规划路径不合理？还是控制响应延迟？
- 修复方案制定：定位到根因后，给出修复建议。可能是调参、改代码、加规则，也可能是补充训练数据。
- 回归验证：修复后，安排测试工程师进行回归路测，确认问题不再复现。
注意：系统工程师最容易犯的错误是「过度分析」。我曾经见过一个同事，花了两天时间分析一个偶发性的误刹车问题，最后发现是测试车的前雷达支架松动了。所以，先排除硬件和安装问题，再深入算法分析。
数据标注员：路测的「记忆」
数据标注员这个角色，很多人容易低估。其实，没有高质量的标注数据，AI模型就是瞎子。
主要职责
- 数据清洗：剔除无效数据（比如传感器被遮挡、车辆熄火、GPS丢星等）。我见过标注员一天处理几百GB的原始数据，其中可能有20%是无效的。
- 数据标注：对关键场景进行标注——目标检测框、车道线、交通标志、行人意图等。标注质量直接影响模型训练效果。
- 场景库管理：将标注好的数据按场景分类入库，形成可复用的场景库。比如「Cut-in场景」、「鬼探头场景」、「雨天场景」等。
- 标注质量审核：定期抽检标注结果，确保标注准确率。我一般要求标注准确率不低于98%。
一个容易被忽略的点：数据标注员和测试工程师之间需要「场景对齐」。测试工程师记录的「前方车辆切入」场景，标注员需要知道具体是哪一段数据、哪个时间窗口、目标车辆是哪一辆。否则标注出来的数据可能和实际场景对不上。
三者的协作流程
我们用一个典型的「问题处理流程」来说明三者的协作关系：
| 步骤 | 负责人 | 动作 | 产出 |
|---|---|---|---|
| 1 | 测试工程师 | 路测执行，发现问题，记录场景 | 问题描述 + 原始数据 |
| 2 | 系统工程师 | 拉取数据，分析日志，定位根因 | 根因分析报告 |
| 3 | 系统工程师 | 制定修复方案，提出标注需求 | 修复方案 + 标注需求单 |
| 4 | 数据标注员 | 根据需求标注相关数据 | 标注数据 |
| 5 | 系统工程师 | 用标注数据训练/验证模型 | 更新后的模型 |
| 6 | 测试工程师 | 回归路测，验证修复效果 | 验证结果 |
你看，这个流程里每个角色都不可或缺。测试工程师是「发现者」，系统工程师是「分析者」，数据标注员是「支撑者」。三者缺一，闭环就断了。
常见协作问题与避坑
我在多个项目里见过一些典型的协作问题，这里列几个：
- 问题描述模糊：测试工程师只写「车辆异常」，不写具体场景。我建议用「场景五要素」来描述——时间、地点、天气、目标类型、自车行为。
- 标注需求不明确：系统工程师说「把Cut-in场景标一下」，但没给具体的时间窗口和目标ID。标注员只能瞎标。我习惯在标注需求单里附上截图和日志片段。
- 回归验证不充分：修复后只跑一次就认为问题解决了。有些偶发问题需要多次复现才能确认。我一般要求至少跑3次相同的场景。
- 数据管理混乱：原始数据、标注数据、分析结果散落在不同地方，找起来费时费力。建议用统一的版本管理工具，比如Git LFS或专用的数据管理平台。
一个小技巧：我习惯在每次路测前开一个5分钟的「对齐会」，测试工程师、系统工程师、标注员一起过一遍当天的测试目标和重点关注场景。这样大家心里都有数，协作起来顺畅很多。
总结
路测团队的分工，本质上是为了让专业的人做专业的事。测试工程师负责「找问题」，系统工程师负责「分析问题」，数据标注员负责「支撑问题」。三者形成闭环，才能让路测真正发挥价值。
你想想看，如果让测试工程师去分析日志，或者让系统工程师去标注数据，效率能高吗？我见过不少团队因为分工不清，导致路测效率低下、问题反复出现。所以，从一开始就把角色和职责定清楚，后面会省很多事。