3. 核心概念与术语
在智能驾驶量产问题闭环工程中，最容易造成沟通成本的并不是技术本身，而是术语被混用。同一个现象，测试同学叫“问题”，开发同学叫“缺陷”，质量同学叫“故障”，管理层关心的是“有没有闭环”。如果术语边界不清，就会导致定级争议、责任推诿、验证口径不一致。本节把最常用的八个术语放在同一条“从现象到关闭”的链路上解析，帮助团队建立统一语言。
一、八个术语的定位与关系
先看一张关系图。它把“问题出现—定级—定位—修复—回归—验证—确认—闭环”串成一条主线，同时标出每个术语在链路中的角色。注意：问题、缺陷、故障三者不是同义词，而是同一事件在不同视角下的三种描述。
二、核心原理：为什么必须区分“验证”与“确认”
验证（Verification）回答的是“我们是否正确地构建了产品”，关注需求到实现的符合性，例如单元测试、仿真回放、代码评审。确认（Validation）回答的是“我们是否构建了正确的产品”，关注用户与场景的真实需求，例如实车路测、用户场景验收、法规符合性。二者方向相反：验证是“向下核对”，确认是“向上回溯”。
在量产问题闭环中，常见错误是只做验证不做确认：代码改了、单测过了、仿真过了，就认为问题关闭。但真实道路上的光照、雨雾、遮挡、异形车辆等长尾场景，往往只有确认环节才能暴露。因此闭环的出口条件必须同时包含验证通过和确认通过。
三、方法流程：从问题到闭环的七步法
- 问题登记：记录现象、时间、版本、场景、数据包，避免“口头问题”。
- 定级与分派：按安全、体验、法规维度定级，明确责任人与时限。
- 复现与定位：用数据回放、日志、仿真复现，区分偶发与必现。
- 根因分析：用 5Why、鱼骨图、故障树定位到最小充分机制。
- 修复与回归：修改后跑回归集，确认无劣化、无新增问题。
- 验证与确认：验证需求符合性，确认场景有效性。
- 闭环归档：更新知识库、测试用例、监控规则，形成防再发。
四、案例场景：一次 AEB 夜间误触发
某车型在夜间隧道出口出现 AEB 误触发。测试同学登记为“问题”；开发定位到毫米波雷达与摄像头融合阈值在逆光下未做场景区分，这是“缺陷”；车辆非预期制动是“故障”；根因是“逆光下视觉置信度骤降但融合权重未降权”。修复后，团队跑了 300 条回归用例，验证了阈值逻辑符合需求，确认了夜间隧道场景不再误触发，最终闭环。
问题单字段示例：
problem_id: ADAS-2024-0871
现象: 夜间隧道出口 AEB 误触发
版本: SW 3.2.1 / 感知模型 v17
场景: 逆光 + 隧道出口 + 前方无目标
定级: B（体验/安全边缘）
根因: 逆光下视觉置信度下降，融合权重未动态调整
修复: 增加逆光场景识别与雷达权重提升
回归: 300 条用例全通过，无劣化
验证: 需求符合性检查通过
确认: 实车夜间隧道场景 20 次无复现
状态: 已闭环五、术语对照清单
| 术语 | 回答的问题 | 典型证据 | 常见误用 |
|---|---|---|---|
| 问题 | 发生了什么异常？ | 数据包、日志、视频 | 把问题直接当缺陷 |
| 缺陷 | 哪里不足？ | 代码 diff、设计评审 | 把缺陷当故障 |
| 故障 | 造成了什么后果？ | 功能失效记录 | 把故障当根因 |
| 根因 | 为什么会被触发？ | 复现实验、故障树 | 停在“人为疏忽” |
| 回归 | 有没有改坏别的？ | 回归报告、覆盖率 | 只跑新增用例 |
| 验证 | 做对了吗？ | 单测、仿真、评审 | 与确认混为一谈 |
| 确认 | 做对东西了吗？ | 实车、用户场景 | 用仿真替代实车 |
| 闭环 | 可以关闭了吗？ | 验证+确认+防再发 | 修复即闭环 |
六、复盘：术语统一带来的工程收益
当团队统一使用这套术语后，问题单的流转效率会明显提升：测试提交时能说清“现象”，开发定位时能聚焦“缺陷”，质量评估时能判断“故障”等级，管理层看板能直接统计“闭环率”。更重要的是，根因、回归、验证、确认四个环节被显式记录后，知识可以沉淀为测试用例和监控规则，形成真正的防再发能力。术语不是文字游戏，而是闭环工程的接口协议。