“小蓝灯”退场之后：创新设计要补的研发与验证记录
一、这类要求真正落在文档柜里
有报道把主管部门规范车辆灯光及创新设计研发测试验证这件事，读作野蛮生长告一段落。报道没有给出文件名、条款内容与生效安排，我们也不去猜执行尺度会怎么走。对做软件和系统交付的人来说，这类要求唯一会长期起作用的地方，是研发流程里的记录。
一项会被车外的人看见或听见的功能——一盏灯、一段提示音、外饰上的一块显示、屏幕上一段动效——它算不算做完了，判据从来不是设计评审签了字，而是能不能拿出一份东西，回答清楚三个问题：这个信号在哪些条件下出现；出现时希望被路人、后车、车主理解成什么；我们用什么办法验证过它只在那些条件下出现，而且验证结果今天还能复算。
也就是说，被要求补的不是审美说明，是可核查性。可核查性只能由测试记录与判定结论提供，宣传物料提供不了。反过来，一个团队如果过去从来没有为”对外呈现的信号”单独建过验证条目，那么这类文件对它的全部影响，就是要在很短时间内把欠账补齐——而这恰恰是最容易出事的补法。
二、先划清哪些功能要进这张表
判断一项功能是否要建记录，不用看它属不属于”灯光”或”造型”，看它的效果是不是由外部观察者来读。凡是外部人员会据此推断车辆状态的东西，都进入范围。按这个口径，常见的五类是：
- 车外灯光状态：位置灯、示廓、指示某项功能已开启的灯效，以及各类呼吸、流水一类的动态灯效。
- 车外提示音：低速提示音、警报音、迎宾音，重点是”听见的人会不会以为它在提示自己让行”。
- 外饰交互：投影、门侧显示、可动部件在人前的开合动作。
- 座舱屏幕动效与状态提示：尤其是那些同时向车内与车外呈现的内容。
- 自动驾驶或辅助功能的状态指示：车内提示与车外指示共用一套语义时要格外小心，因为这正是被误读最多的一类。
范围一旦按”谁来读这个信号”划，就会得出一个不那么舒服的结论：这项功能的责任人往往不在同一个人手上。灯是造型与电子在管，音是声学，屏幕动效是座舱软件，状态指示则牵到感知与规控。所以下面这张清单的第一个作用，是让每个条目都能找到署名的人。
三、每一项对外呈现的功能要备齐的六项记录
这份清单可以直接抄进项目模板，一项功能一份，缺项就标红。真正容易被省掉的是后三项。
| 记录条目 | 要写到的内容 | 缺失时的典型后果 | 签署责任 |
|---|---|---|---|
| 设计意图与适用边界 | 这个信号想传达的唯一含义；明确列出它不表示什么、不适用的场景 | 用户按设计者没预设的方式理解，事后无人能说明原意 | 功能负责人与设计负责人共同签 |
| 触发条件与状态机定义 | 输入条件集合、状态与转移、每一状态下的输出、优先级与互斥关系 | 多个模块都能驱动同一信号，出现谁都没设计过的叠加态 | 系统工程师 |
| 测试用例矩阵 | 工况分档、环境光分档、雨雾与镜面脏污、夜间、干扰光源、观察视角与距离档 | 只在单一实验室条件下验过，装车后现场结论无法判定 | 测试负责人 |
| 实测结果与判定结论 | 每条用例的观察记录、判定依据、通过或不通过及理由，且结论可由他人复算 | 档案里只有照片没有结论，评审时说不清到底验过没有 | 测试执行人与复核人双签 |
| 变更与版本记录 | 每次改动对应的软硬件版本、生效批次、受影响用例是否重跑、未重跑的理由 | 逻辑改了一处，旧的外观测试结论仍被当作仍然有效 | 配置管理员 |
| 遗留风险与已知不适用场景 | 未覆盖的条件、已知误读风险、临时抑制措施与其失效条件、后续补测安排 | 风险只存在于某个工程师的口头交代里，人员一流动作就断 | 项目质量负责人 |
前两项是把功能说清楚，中间两项是把结论留下来，最后两项是把时间和边界钉住。很多团队的记录只做到第三项，一旦软件开始频繁迭代，前面留下的结论立刻失效，但流程里没有任何地方提示它已经过期。
四、状态语义必须唯一，否则一切记录都白写
被投诉和被误用的源头，通常不是灯不够亮或者动效太花，而是同一个信号在不同模式下承担了两种含义：待命时亮、开启某项功能时也亮，只是闪烁方式略有区别；或者两种互斥状态共用同一位置，靠颜色区分。这类设计在评审时看起来节省，一到现场就是灾难，因为外部观察者既没有模式上下文，也没有能力分辨细微的节奏差别。
要把”语义唯一”变成可执行的东西，需要三件事：
- 一张信号—状态映射表，行是每一个可观察状态，列是它对应的输出，检查时看同一输出是否出现在多于一行的位置。出现重叠就是设计缺陷，要在这一层解决，而不是交给用户去猜。
- 一份互斥与优先级约定，写清楚当两个模块同时请求输出时，谁压制谁、被压制的一方是否留痕。没有这条约定，最后胜出的是代码里改动最晚的那个分支。
- 一个”不允许新增叠加态”的关卡：任何新增功能如果要复用已有信号，必须先证明它不改变这个信号原有含义，否则就申请新的可观察载体。
这条约定对软件供应商的影响最直接。车外指示往往由多个域控共同决定，座舱域、车身域、智驾域都可能在某个时刻改变同一个输出的状态。这时真正需要的不是各家都写一套判断，而是一份书面约定：谁持有状态真值，其余节点只消费不解释。谁都能改，等于没人负责，事后想还原”当时那盏灯为什么亮”就只能靠猜。
五、测试要能被别人复现，判据不能写成体验良好
一份验证记录值不值钱，取决于别人按同样的条件做一遍，能不能得到同样的结论。灯光与显示类功能最容易在这里失守，因为观察结果对条件太敏感。
可复现至少要固定这几样：环境光的分档与测量方式，同一批用例在不同档位下分别执行；相机或采集设备的参数与拍摄位置，把档位与视角写进记录，而不是随手拍；雨雾与脏污等表面状态的模拟方法与程度档；观察视角与距离按约定档位执行，每个档位单独出结论。这里要避免的正是”随手把参数改了以让结果好看”，所以参数应由测试负责人预先设定并在记录中回显，执行人无权自行调整。
判据要写成可观察条件。”夜间辨识度高””效果明显””体验良好”这类描述无法复核，也无法在争议时保护团队。换成这种写法：在约定的暗档环境与约定视角、约定距离档下，连续若干次记录中均能看到稳定亮态、无异常闪烁、且与相邻信号不混淆。判定的是”看得清、认得出、不与其他含义混”，而不是”好不好看”。前者能被第三方重复，后者只能被争论。
同时要留一条反向检查：在功能不该出现的条件下，确认它确实不出现。漏测这一半，是后来被误读的主要来源。
六、流程上给验证留不可跳过的关卡
现实里最常见的失效方式不是没做测试，而是次序倒了。造型冻结的时间常晚于验证窗口，外观信号的定义在样车阶段还在改，而测试排期按整车节点早就开始跑。等到设计定稿，留给验证的时间只剩下把之前的结论”整理成文档”。这时候补的是文档，不是证据，风险不但没减，反而多了一份看起来完整的假记录。
要防这件事，流程里需要两个硬关卡：一是外部呈现类功能必须有独立验证节点，未通过不得随整车一起放行，判定物就是第三节那六项；二是设计变更后强制回归，回归范围按信号—状态映射表来圈，而不是由提出变更的人自己判断影响面。洹拓在给工业与车企客户做软件交付时，通常会把第二关做成一张可查询的对照表：改哪一行，就必须重跑哪几条用例，没有重跑就必须在遗留风险条目里写明理由和补测安排。这条约定看起来笨，但它把”谁动了信号语义”这件事从口头提醒变成有记录的动作。
对做软件与云的团队，还有一条更普遍的启示：任何面向外部呈现的功能，上线前先把”它想让别人理解成什么”写下来，并让另一个没参与设计的人只看这句话、不看代码，判断能否复现同样的理解。这个成本很低，却能提前暴露绝大多数语义冲突。记录不是给检查的人准备的，它是团队在半年后还能说清自己当初做了什么、验过什么的唯一办法。