说明本文复盘一次城市智驾路口绑灯功能的量产级重构。文章从问题拆解开始说明如何通过数据、地图、引擎和规控四层归因将偶发问题变成可复现用例再通过停止线锚定、受控 link 判断和数字灯状态建模完成架构重构最后用四项指标建立版本回归体系。全文不涉及代码和内部名称重点讨论工程方法和量产验证1. 引言为什么「路口绑灯」是城市智驾的安全红线想象这个场景一辆开启城市领航辅助城市 NZP的车接近一个十字路口——最左侧是左转专用道中间两条直行道右侧一条右转道。路口对面挂着四组红绿灯一个左转箭头灯、两个直行圆灯、一个右转灯旁边还各配了一个倒计时数字灯。车要做的比「看到红灯就停」复杂得多。它必须先搞清楚一件事这四个灯里到底哪一个管的是我这条道这就是「路口绑灯」把感知到的红绿灯正确地绑定到「我所在的车道、我要去的方向、我该停的停止线」上。这件事一旦出错代价是致命的绑错了灯左转道绑到了直行灯直行绿灯一亮车就冲出去而左转灯其实还红着——闯红灯或更糟的事故。绑慢了一拍连续路口一个接一个前一个路口的灯还没处理完下一个路口的灯已经来了系统延迟几秒——该停的没停不该停的急刹。在城市领航里路口是事故率最高、体验最敏感的场景而绑灯就是路口安全的「第一道闸门」。它错一次后面感知、规划、控制做得再漂亮都是在错误的假设上运行。正因为它难、也正因为它重要当我们最终把关键场景下的绑灯成功率和稳定性做到99.9%并且这套方案被采纳为集团内多个车型平台含 Robotaxi的标准技术基线时中间走过的弯路和踩过的坑值得复盘。这篇文章我会讲清三件事一个「顽固的绑灯问题」是怎么被拆成可定位的子问题的我们怎么用「根因定位」代替「调参碰运气」一步步把它推到量产级为什么「评测体系」才是 99.9% 这个数字的真正底气。2. 问题拆解把「顽固问题」变成「可定位的子问题」很多「顽固 bug」之所以顽固不是因为难而是因为它是一个含糊的整体。你没法「调一个参数」去解决一个「说不清是什么」的问题。所以我们的第一步不是改代码而是拆。先立一条流水线路口绑灯表面是一个问题实际上是一条两段串行的流水线[ 绑灯 · 关联 ] ──► [ 信号认知 · 读取 ] ──► [ 下游规划 / 控制 ] 哪个灯管我这条道 这个灯现在什么信号 据此决策第一段绑灯关联确定「哪个灯管我这条道」。要把「灯」和「车道 / 转向 / 停止线」在空间与拓扑上对齐——连续路口、多相位、掉头 / 豁口、大曲率无灯路口全是这一段的坑。第二段信号认知读取确定「这个灯现在是什么信号」——红 / 绿 / 黄、圆灯还是箭头灯、倒计时还剩几秒。绿闪误刹、数字灯误判、状态跳变红绿灯信号遮挡全是这一段的坑。两段串行且耦合先绑对灯才能读对信号绑错了读得再准也是白读。反过来绑对了、读错了比如把绿闪当绿灯、把倒计时当方向一样闯红灯。很多团队的问题在于把这两段糊成一个「红绿灯功能」出了 bug 说不清是哪一段的锅。拆开之后每个 bug 才能落到具体的一段才能往下定位。一个例子倒计时灯的「方向」从哪来用第二段信号认知里的一个真实问题说明「拆解」到底有什么用。路口有一类灯是倒计时灯——纯数字显示 12、11、10……它本身不携带方向信息你不知道它是给左转的、还是给直行的。但它通常和一个方向箭头灯配套出现。系统要回答的问题是这个倒计时灯代表哪个方向的信号最初的实现很简单给每个灯维护一份「历史形状」记录——检测到方向箭头灯时记下它的方向检测到倒计时灯时就用历史里的方向来「补」。逻辑看起来没问题实车一跑就翻车。问题出在状态循环上。一个灯会经历「方向灯绿箭头→ 倒计时灯绿闪数秒→ 方向灯红箭头→ …」这样的循环。单靠一份「历史形状」记录区分不了两种情况现在这个倒计时灯是「从方向灯变来的倒计时」——应该继承方向还是「倒计时已经结束、系统误读成了别的东西」——不应该去污染历史。结果就是实车反馈里最头疼的一类灯变着变着方向就「回不去了」——要么把倒计时灯永久误判成某个方向要么方向在两次循环之间乱跳。这个 bug 的根因不在「识别得不准」而在状态建模不对用一个字段去表达一个本需要多个状态区分的时序问题。后面我们的修复核心一句话把「历史形状」这一个状态拆成能区分「当前是不是倒计时灯」「是不是刚从方向灯变过来」的多个状态让倒计时灯永远只「借」最近一次有效的方向而永远不「污染」它。具体状态机第 5 节展开。拆解带来的三个好处问题可归因每个 bug 都能落到「绑灯段」还是「信号认知段」不再是含糊的「红绿灯有问题」。根因可定位像倒计时灯这种一眼看出是「状态建模问题」而不是「识别精度问题」。方案可复用拆成两段后绑灯的重构方案才能被抽出来、做成跨车型的标准基线——这就是后面 99.9% 能复用到多个平台的起点。下一节讲我们最核心的方法四层根因法——数据 → 地图 → 引擎 → 规控以及为什么它比「调参」快一个数量级。3. 四层根因法数据 → 地图 → 引擎 → 规控拆完之后真正的硬骨头是「偶发」——不是每次都错而是「时不时错一下现场抓不到」。偶发问题最坑人的地方在于没有稳定复现就没有根因。现场报上来一个「过某个路口突然退出」等你派人去那个路口车又好好的。这种时候工程师最容易犯的错就是凭感觉调参——「大概是这个阈值太紧了放宽一点试试」然后祈祷下次不出现。这不是定位这是赌博。我们的做法是把每一个「偶发无效 / 异常降低」的问题先强制归到四层之一再往下挖┌────────────── 一个「偶发」问题 ──────────────┐ │ │ ① 传感器数据 ② 地图数据 ③ 引擎逻辑 ④ 下游规控 脏数据/跳变 拓扑/关联错 状态机/时序 响应/退出① 传感器数据层数据脏、跳变、丢帧、时钟不对齐。这一层的问题会在下游「伪装」成各种奇怪的症状。② 地图数据层link 拓扑错、停止线缺失或偏移、红绿灯与车道的关联标错。③ 引擎逻辑层绑灯状态机、里程计、时序对齐——引擎自己的逻辑和状态。④ 下游规控层对绑灯结果的反应——延迟、提前退出、不该有的制动。关键不在于这四层本身而在于一个反直觉的规律症状所在的层往往不是根因所在的层。举一个真实例子这类问题里最经典的伪装里程计跳变导致路口内功能「非预期退出」。症状在「④ 规控」——车在路口中间功能突然退了。乍一看是规控的退出逻辑太敏感。但真去查会发现是里程计在某个瞬间跳了一下车以为自己已经越过了停止线、离开了路口于是「合法地」把绑灯结果清掉了。而里程计为什么跳再往下追一层是「① 传感器数据」的问题一次车轮打滑、或一次定位数据的毛刺。跳变传到了「③ 引擎」的里程计最后在「④ 规控」露出症状。如果一开始就盯着「④ 规控」去调退出阈值这个 bug 会陪你到量产还会换着花样复现。而一旦定位到「① 数据」问题就从「玄学」变成了「可修」。三件工具把「偶发」变「必现」这套四层归因能跑起来靠的是三件工具抓包复现第一现场问题发生的瞬间把该帧的传感器数据、地图数据、引擎内部状态全部抓下来——这是「现场证据」决定了后面所有分析的地基。日志分析定位到层顺着日志把异常一步步从「症状层」追到「根因层」。数据回灌离线复现把抓下来的现场数据喂回离线环境重跑。一旦离线能稳定复现偶发就变成了必现——这时才谈得上「修复后验证」。这三件工具组合起来的效果是任何偶发问题都能被钉死在某一层并变成可复现、可验证、可回归的用例。这才是后面 99.9% 能站得住的原因——它不是一个「感觉上的成功率」而是一套用真实 case 跑出来的、可回归的数字。下一节讲我们怎么在「③ 引擎逻辑」这一层做了一次架构级的重构——为什么「打补丁」救不了连续路口必须推倒重来。4. 重构方案把「停止线」变成绑灯的锚点定位清楚之后摆在面前的是一个选择继续给旧方案打补丁还是推倒重构。我们的结论很明确补丁救不了。因为旧方案的问题不在参数而在判定的依据本身选错了。旧方案为什么注定解不完旧方案里「路口判断认知」是一个单独的上游模块给出的感知到停止线前 10 米上游给一个「路口内」状态然后系统靠里程计的行驶距离来判断是不是已经驶离了路口。这套机制有三个解不完的坑连续小路口前一个路口还没走完系统就很容易把下一个路口的灯绑了进来——两个路口离得近距离判定的边界是糊的。里程计突变里程计只要跳一下「已驶离」的判定就错了绑灯状态跟着异常失效。最根本的城市路口的范围本身就是非标的——有的路口 30 米有的 80 米还有不规则的。用「固定阈值的行驶距离」去判定进出路口注定有无穷无尽的 case 解不完。这不是调参能解决的是模型选错了。一句话总结旧方案的病根它用一个「推算出来的距离」去判定一个本该「感知出来的事实」。新方案以「停止线认知」为核心重构的核心是把绑灯和进出路口的锚点从「里程计距离」换成了「停止线」。先认知停止线停止线是物理上真实存在、能被感知到的东西相机、激光都能看到。灯绑到停止线上红绿灯本来就控制「在这条线停」灯 ↔ 停止线是天然的绑定关系。「是否驶离路口」从「里程计走了多远」变成「是否已经通过我的停止线」——一个可观测的事件而不是一个距离阈值的猜测。这一步看起来简单但它把一个「解不完的推算问题」换成了一个「可感知、可判定的事实」。连续小路口我只看我自己的停止线跟下一个路口的灯没关系。里程计突变我已经不靠里程计判断驶离了突变影响不到绑灯状态。第 5 节挑两个典型场景展开一个是「受控 link」——先问这个灯到底管不管我这条路线一个是「数字灯」——倒计时灯的方向信息从哪来。它们分别代表「要不要绑」和「读什么信号」两类问题。5. 关键场景攻坚受控 link 与数字灯停止线认知解决了「绑到哪」但落地时还有两类问题分别卡在流水线的两端受控 link管「要不要绑」——先确认这个灯到底管不管我这条路线数字灯管「读什么信号」——确认要绑之后怎么把这个灯的信号读对。5.1 受控 link先问「这个灯管不管我」城市里有一类「路口」其实不需要看灯进环岛后的豁口、Y 字形的汇入、某些 T 型路口——车走的方向跟路边的信号灯没有关系。但感知系统不管这些它只要看到了停止线和信号灯就默认这是「真实路口」直接绑定。结果就是误绑——车把一个「根本不管自己」的灯当成了自己的灯。根因很清晰旧逻辑是**「看到灯就绑」**缺了一道「这个灯到底管不管我这条 link」的判断。方案是引入SD 数据标准精度地图的 link 级拓扑做一层判断通过 SD link 关联确定当前行驶的 link 是不是「受控 link」——即是不是被某个信号灯真正控制的路段。受控 link → 正常绑定非受控 link → 不绑。补上这一层后「看到灯」从绑定的充分条件降级为必要条件——「看到灯」「它管我这条 link」才绑。5.2 数字灯倒计时灯的方向从哪来回到第 2 节留的那个问题倒计时灯本身不携带方向信息系统要靠「历史形状」来补但单靠一份历史记录会在「方向灯 → 倒计时灯 → 方向灯」的循环里把状态搞乱——方向「回不去」。根因是状态建模不对用一个字段去表达一个本需要多个状态区分的时序问题。修复的核心是把「历史形状」这一个状态拆成两个可区分的维度当前是不是倒计时灯是不是刚从方向灯变过来。由此形成一套简单的状态转换看到方向灯→ 记下方向方向灯变成倒计时灯→ 继承「最近一次有效的方向」但不覆盖历史倒计时灯变回方向灯→ 更新方向。一句话倒计时灯永远只「借」方向永远不「污染」方向。无论方向灯怎么循环方向都能正确恢复不会再「回不去」。6. 量化99.9% 是怎么「量」出来的前面讲的都是「怎么修」。但「修好了」和「感觉修好了」是两回事。在量产这件事上有一条我们反复强调的原则不能量化的优化是玄学。一个 bug 修完如果你说不出「它在哪个指标上、从多少变成了多少」那它就不算修完——因为下一版随时可能复现而你连「它有没有回退」都不知道。四个指标把「绑灯」变成可度量的东西所以我们在量产交付小包里围绕路口绑灯算法和感知模型的红绿灯信号处理这两条链路基于真实路测抓回来的 case不是合成数据建了一套评测体系核心是四个指标绑灯成功率绑对的灯占所有应绑灯的比例——这是主指标99.9% 说的就是它。信号稳定性同一个路口、同一个灯算法输出的信号会不会在帧与帧之间乱跳。数字灯判读数字灯/倒计时灯读得对不对——就是第 5 节那个「借方向不污染方向」的场景单独拎出来量化。真实信号与算法输出的一致性算法输出的信号跟现场真实信号对得上吗——这是最终兜底的一项。每一个版本都在回归评测体系的价值不在「跑一次拿个好看的数字」而在它能支撑版本验收与回归每个版本发布包先跑这套真实 case 评测集任何一个改动合入前先看这四个指标有没有回退回退了改动就进不了版。这才是「99.9% 能站得住」的真正原因——它不是一个在某个晴天测出来的峰值而是每一个量产版本都在回归、都在守住的一个数字。这套东西最终在某直辖市的 EX 项目「全国首通」攻关、以及后续的全国泛化测试里被反复验证也直接支撑了城市 NZP 的成功发布。7. 落地与复用从单项目到集团标准基线一次重构如果只在某一个车型、某一个城市跑通那它可能只是一次性的工作。真正决定它价值的是它能不能被别的项目直接拿去用。这次重构最终拿到了两个「被复用」的证据第一个证据真实路网的全国首通验证。方案在某直辖市的 EX 项目上做了全国首通攻关又在后续的全国泛化测试里反复验证。这意味着它不是在某条固定测试路线上「背题」而是在没见过的城市路网上也能稳住 99.9%。第二个证据被采纳为集团标准技术基线。因为方案在「鲁棒性」和「可维护性」上足够站得住它被集团内多个项目——不同车型、不同定位的平台包括 RoboTaxi——采纳为标准技术基线跨车型复用保证一致体验。这两个证据背后其实指向同一件事架构的价值最终体现在「别人愿意拿来复用」上。为什么别的项目愿意复用不是靠关系或流程硬塞而是靠两样东西挣来的鲁棒性停止线认知锚定的是「可感知的停止线」不是「某个城市的固定阈值」——所以它在不同城市、不同路口形态下都能泛化不用每个城市单独调一套参数。可维护性拆成「绑灯 / 信号认知」两段 四层归因 可回归的评测出了问题能定位、能改、能验证——别的团队接得动、敢接。最终这次重构拿到了项目组颁发的「核心优秀交付成果」推荐也直接支撑了城市 NZP 的成功发布与用户口碑。8. 复盘与思考这套方法还能用多久最后收个尾三点复盘加一个对行业趋势的判断。三条复盘根因定位永远比调参值钱。这次重构里最难的不是写代码是「里程计跳变」那个问题——它看起来是规控的锅实际是数据的锅。只会调参这种问题会陪你到量产会四层归因它一天就现形。评测体系是量产的底气。99.9% 不是跑一次测出来的峰值是每个版本都在回归的数字。没有评测体系任何「优化」都是玄学任何「修复」都可能在下个版本悄悄回退。架构要服务复用。一次重构的价值上限不是「解决了这个问题」而是「别人愿不愿意拿它当基线」。鲁棒性 可维护性是复用的前提也是架构和补丁的分界线。一个趋势判断经典感知-融合会变但「数据 几何」不会消失这几年行业有个明显的趋势无图化、端到端。很多过去靠「经典感知 融合 高精地图」解决的问题正在被大模型和在线建图替代。坦白说路口绑灯这类「经典感知-融合」的活儿形态一定会变——绑灯的很多手工规则会逐渐被端到端模型吸收。但有一件事不会变无论模型多强车要安全过路口依然需要知道「我该在哪停、哪个灯管我」。「停止线在哪里」「这个灯管不管我这条路线」「我现在该不该停」——这些是物理世界的几何约束和语义事实是模型绕不开的底座。端到端模型可以自己学但学的过程仍然要真实数据、仍然要几何对齐、仍然要可量化的验证。这些东西恰好是这篇文章从头到尾在做的事。所以我的判断是算法会变、模型会变但「把空间数据和几何约束做成可量产、可验证的系统」这件事会一直在。关于作者Mainland14 年「空间智能」研发前吉利 / 极氪智能驾驶感知开发工程师主导路口绑灯核心算法重构99.9%集团标准技术基线、多车型量产交付现专注机器人 / 具身智能的「现实底座」——三维重建工程化、高精地图 / 时空数据、标定与量产导入。欢迎交流脉脉搜索「Mainland」。