1. 课程导论
1.1 一个让我印象深刻的翻车现场
先讲个真事。几年前我参与一个L4级园区物流项目，车跑得好好的，突然在路口急刹——不是撞到东西，是“吓停”了。
排查了一整天，最后发现是决策模块和规划模块打架。决策层说“我要左转”，规划层算出一条平滑轨迹，但决策层又觉得“等等，这个路口好像有行人意图”，于是改成了直行。规划层刚算完新轨迹，决策层又变卦了……
嗯，这种来回拉扯，在实车上就是一顿一顿的“点头”现象。乘客晕车，我们头疼。
说白了，这就是典型的决策与规划割裂带来的问题。我后来跟团队复盘时说过一句话：决策不知道规划能不能做到，规划不知道决策为什么变——这车能开好才怪。
1.2 传统架构：各管各的，各疼各的
传统自动驾驶软件架构里，决策和规划通常是两个独立模块。你想想看，它们之间只靠几个接口参数通信，像极了两个部门只靠邮件对接——信息损耗大，延迟高。
典型割裂表现：
- 决策层：输出“目标车道”“目标速度”等高层指令，不考虑曲率、加速度限制
- 规划层：收到指令后硬算轨迹，遇到不可行时只能“报错”或“降级”
- 反馈机制：几乎没有。规划层说“我做不到”，决策层说“那你看着办”
我在项目中遇到过最离谱的一次：决策层要求换道，规划层算出来需要急转向才能完成，但决策层不知道这会导致车辆侧倾过大。结果实车测试时，货箱里的箱子全倒了。
1.3 痛点清单：这些坑你大概率也会踩
我整理了几个最常见的痛点，你看看是不是似曾相识：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 信息不对称 | 决策不知道规划的能力边界 | 指令不可执行，频繁重规划 |
| 时序不同步 | 决策10Hz，规划50Hz，中间差了好几帧 | 轨迹抖动，控制滞后 |
| 目标冲突 | 决策要安全，规划要舒适，没人拍板 | 保守与激进来回切换 |
| 异常处理真空 | 规划失败时，决策不知道该怎么兜底 | 直接停车或降级到最小风险 |
为什么会这样？我个人的理解是：传统架构把“做什么”和“怎么做”拆得太干净了。拆干净本身没错，但中间缺了一个“协同层”。
1.4 一个简单的例子说明问题
假设场景：前方50米有静止障碍物，决策层决定“向左避让”。
传统流程是这样的：
- 决策层输出“目标车道：左车道，目标速度：30km/h”
- 规划层收到后开始算轨迹
- 算到一半发现：左车道也有车，而且距离不够
- 规划层报错：“无法生成可行轨迹”
- 决策层收到报错，重新决策：“减速，等待”
- 规划层重新算……
你看，这一来一回至少浪费了200ms。在高速场景下，200ms可能就是生与死的区别。
我的建议：决策层在做决定之前，应该先问规划层一句：“这个指令你搞得定吗？”规划层快速给一个可行性评估，决策层再拍板。这就是协同设计的核心思想。
1.5 协同设计到底解决什么问题？
说白了，协同设计就是让决策和规划共享信息、互相反馈、共同决策。不是谁指挥谁，而是商量着来。
我习惯把这种关系比作“驾驶员和副驾”：
- 驾驶员（决策）说“我要超车”
- 副驾（规划）看一眼后视镜说“后面有车，再等等”
- 驾驶员说“好，那等3秒”
- 副驾说“3秒后空间够了，可以超”
你看，这才是正常人的开车方式。但传统架构里，副驾只会说“收到”，然后硬开——开不了再喊“不行”。
1.6 本章知识体系总览
下面这张图是我自己画的一个框架，帮你快速理解决策与规划协同设计的核心逻辑：
注意：这张图里最关键的其实是那条紫色的虚线反馈回路。我曾经在好几个项目里发现，团队把大量精力花在优化单个模块上，却忽略了这条回路——结果就是模块各自跑得飞快，但合在一起就是不行。
1.7 这门课你会学到什么？
这门课不讲虚的。我会带着你从实际工程角度，一步步拆解协同设计的方法：
- 怎么设计决策与规划的接口——不只是定义几个结构体，而是考虑时序、容错、降级
- 怎么让决策层感知规划的能力边界——比如用“可行性热力图”提前预判
- 怎么处理冲突——安全 vs 舒适 vs 效率，谁优先级更高？
- 怎么在实车上调试——我踩过的坑，你尽量别踩
嗯，内容不少。但别担心，我会用项目里真实遇到的案例来讲，保证你听完就能用上。
可可精品资料库