企业官网建设流程全解析

1. 从感知到决策：自动驾驶真正难啃的骨头在哪

聊自动驾驶，大多数人第一反应是激光雷达、摄像头、BEV感知这些"眼睛"层面的东西。但真正在一线做过系统落地的人心里都清楚，感知做到90分固然难，可决策模块从90分往99分爬的那段路，才是让人夜不能寐的部分。我接触过几个做自动驾驶决策规划的朋友，他们有个共识：感知的bug你能通过标注数据、加传感器去补，但决策的bug往往没有标准答案——同一个场景，不同的人开法都不一样，你凭什么说你的算法就是对的？

这就是决策算法最核心的困境：它面对的不是一个有唯一正确答案的问题。感知是"是什么"，预测是"可能会怎样"，而决策是"我该怎么办"。前两者有客观真值可以对齐，决策却要在安全、效率、舒适、合规这几个经常互相打架的目标之间做权衡。你保守一点，后车骂你龟速；你激进一点，安全员一脚刹车踩下去。这种没有绝对对错的特性，让决策算法的设计、验证和迭代都变得格外棘手。

这篇内容我想把决策算法这块拆开聊透。从它的核心任务边界、主流技术路线的取舍逻辑、到实际工程落地时那些文档里不会写的坑，再到我对这个方向未来演进的一些个人判断。适合已经对自动驾驶有基本认知、想深入理解决策层设计思路的从业者，也适合刚入行想搞清楚"决策到底在做什么"的朋友。我不会堆砌公式，更多是从工程视角讲清楚每个选择背后的"为什么"。

先给一个最朴素的框架：决策模块的输入是感知和预测的结果（周围有什么、它们可能怎么动），输出是一条或者一组可行的轨迹（我接下来几秒怎么走）。中间要完成的事情包括：理解当前场景的语义（这是路口还是匝道汇入）、评估各种行为的风险与收益、生成满足车辆动力学约束的轨迹、并且在多个目标之间做优化。听起来逻辑很清晰，但每一步展开都是一堆工程难题。

2. 决策模块的任务边界：它到底该管多宽

2.1 决策、规划、控制的分层与模糊地带

教科书上通常把自动驾驶系统分成感知、决策、规划、控制四层。但实际工程里，决策和规划的边界非常模糊，不同团队的定义能差出十万八千里。有的团队把"选车道、选行为"叫决策，"生成具体轨迹"叫规划；有的团队把两者揉在一起叫"决策规划"一个大模块。我见过最极端的，把行为决策直接塞进规划器里，用统一的优化框架一起解。

这种边界模糊不是坏事，反而说明一个问题：决策和规划本质上是耦合的。你决定"变道"，这个决策本身就隐含了对轨迹可行性、时间窗口、后车距离的评估，而这些评估又依赖规划器能不能算出一条安全轨迹。硬要把它们切开，中间就得定义一套接口，而接口一旦定义死，很多跨层的联合优化就做不了了。

我的经验是，早期原型阶段可以分得清楚一点，方便调试和定位问题；但到了追求性能的阶段，适度耦合反而能拿到更好的结果。关键是要想清楚：哪些决策是"离散的"（变道/不变道、让行/抢行），哪些是"连续的"（加速度多少、横向偏移多少）。离散决策适合用规则或搜索，连续优化适合用数值方法，两者怎么衔接是设计的核心。

2.2 决策模块必须处理的几类核心场景

决策算法的复杂度，很大程度上取决于它要覆盖多少场景。我把它粗略分成几档，难度递增：

跟驰和换道这类场景，规则+优化基本能搞定，工业界已经比较成熟。真正难的是无保护交互和非结构化场景，因为这里没有清晰的"路权"可以依赖，算法必须学会像人一样去"读空气"——通过对方的微小动作判断意图，通过自己的动作去传递意图。这就引出了决策算法最本质的一个问题：它不只是个优化问题，还是个博弈问题。

2.3 为什么"端到端"没有让决策模块消失

这两年端到端自动驾驶很火，从传感器输入直接输出控制信号，中间不显式建模感知、预测、决策。很多人就问：那决策模块是不是要没了？我的看法是，端到端改变的是决策的实现形式，而不是消灭了决策这件事本身。它把原来显式的规则和优化，变成了隐式的网络推理，但"在冲突目标间做权衡"这个核心任务一点没变。

而且端到端目前最大的问题恰恰在决策层面：可解释性差、长尾场景难覆盖、安全边界说不清楚。你没法跟监管解释"为什么这个网络在这里选择不让行"。所以在可预见的未来，显式的决策模块仍然有它的价值，尤其是需要给出安全论证和可解释性的场景。更现实的路线是混合架构：端到端负责常规场景的流畅处理，显式决策负责兜底和边界情况。

3. 主流技术路线的取舍：规则、优化还是学习

3.1 有限状态机与规则系统：为什么它还没被淘汰

有限状态机（FSM）是最经典的决策方法。把驾驶行为定义成若干状态（跟驰、换道、超车、让行等），状态之间定义转移条件，每个状态内部用规则决定具体动作。这套东西听起来很"土"，但你去问任何一家量产自动驾驶公司，他们的决策系统里几乎都有状态机的影子。

原因很简单：可解释、可调试、可验证。出了事故，你能明确说出当时系统处于哪个状态、为什么触发转移、规则是怎么写的。这在功能安全认证里是巨大的优势。而且规则系统对已知场景的处理非常稳定，不会像神经网络那样出现莫名其妙的抖动。

但状态机的天花板也很明显。状态一多，转移条件就爆炸，维护成本急剧上升。我见过一个项目，状态机有几十个状态、上百条转移规则，改一条规则可能影响好几个场景，最后没人敢动。而且规则是"硬"的，遇到规则没覆盖的边角场景，系统要么卡死要么做出很傻的决定。所以状态机适合做骨架和兜底，但不适合作为唯一的决策手段。

3.2 基于优化的方法：把决策写成数学问题

优化方法的核心思路是把决策变成一个带约束的目标函数求解问题。比如变道决策，可以写成：最小化"到达目标车道的时间 + 加速度变化率 + 与周围车的风险"，约束是"不碰撞、满足动力学限制、满足交通规则"。然后用二次规划（QP）或者模型预测控制（MPC）去解。

这套方法的优雅之处在于，它天然能处理多目标权衡，而且约束是显式表达的，安全性有数学保证。MPC尤其适合决策规划，因为它能滚动优化，每个周期重新求解，对动态环境适应性强。

但优化方法的坑也不少。首先是目标函数的权重极难调。安全权重给高了，车开得畏畏缩缩；给低了，又容易激进。而且这些权重往往跟场景相关，高速和城区的最优权重完全不同，用一套固定权重根本不行。其次是非凸问题，很多真实决策问题是离散+连续混合的，标准QP解不了，得上混合整数规划或者采样优化，计算量一下就上去了。最后是约束的建模，怎么把"礼让行人"这种模糊的社会规范写成数学约束，本身就是个难题。

3.3 学习类方法：模仿学习与强化学习的现实差距

学习类方法听起来最"先进"：模仿学习直接从人类驾驶数据里学决策，强化学习让算法自己在仿真里试错。但实际落地时，两者的差距都不小。

模仿学习的问题是分布偏移。训练数据是人类开的，人类很少遇到极端危险场景，所以模型也没见过怎么处理。一旦实际运行中偏离了训练分布，模型的表现就断崖式下跌。而且人类数据本身就不一致——同一个场景，十个司机有十种开法，模型学出来的是个"平均司机"，往往优柔寡断。

强化学习理论上能通过试错学到最优策略，但样本效率和安全性是两座大山。在真实世界试错成本太高，只能靠仿真，而仿真和现实的差距（sim-to-real gap）又让策略迁移困难。奖励函数的设计也是玄学，奖励给不好，学出来的策略可能钻空子，比如为了"不碰撞"干脆停在原地不动。

我的判断是，纯学习类方法短期内很难独立承担决策重任，但作为规则和优化的补充很有价值。比如用学习来预测他车意图、用学习来调整优化权重、用学习来处理规则覆盖不到的边角场景。混合架构才是现实解。

3.4 三条路线的对比与组合策略

把三条路线放一起对比，能看得更清楚：

实际工程里，我见过比较成功的组合是：状态机做顶层行为管理，优化做轨迹生成，学习做意图预测和参数自适应。状态机负责"现在该进入哪个驾驶模式"，优化负责"在这个模式下具体怎么走"，学习负责"预测别人会怎么动、当前该偏保守还是偏激进"。三层各司其职，既保证了可解释和可验证，又保留了对复杂场景的适应能力。

4. 工程落地时那些文档不会写的坑

4.1 目标函数权重：调参调到怀疑人生

前面提到优化方法的权重难调，这里展开说说。我参与过一个城区决策项目，目标函数里有安全、效率、舒适、合规四项，每项又有若干子项，加起来十几个权重参数。刚开始大家拍脑袋定了一组值，结果车在路口要么不敢走，要么抢行吓人。

后来我们做了系统的权重标定：先定义评价指标（比如通行时间、急刹次数、安全员接管率），然后在仿真里做网格搜索和贝叶斯优化，找帕累托前沿。这个过程极其耗时，而且发现一个残酷的事实：没有一组权重能在所有场景都表现好。高速上最优的权重，放到城区拥堵场景就是灾难。

最终的解法是场景自适应权重：先做场景分类（高速/城区/泊车、畅通/拥堵），每类场景用一套标定好的权重，场景切换时做平滑过渡。这又引入了新问题——场景分类本身可能出错，切换时的平滑如果没做好，车会有突兀的行为变化。我们后来用了一个滑动窗口做权重插值，过渡时间设成2秒左右，实测下来体感比较自然。

提示：权重标定一定要建立自动化的评价流水线，靠人工看视频调参效率太低，而且人的判断标准会漂移。把关键指标量化，让机器帮你搜。

4.2 预测误差如何传导成决策灾难

决策依赖预测，而预测一定不准。问题在于，预测的小误差可能被决策放大成大灾难。举个真实遇到的例子：一个路口，右侧有辆车缓慢移动，预测模块给出它"大概率直行、小概率右转"的概率分布。决策模块如果只看最大概率，就会假设它直行，于是规划了一条从它前面通过的轨迹。结果那辆车突然右转，直接逼停。

这类问题的根源是决策没有充分利用预测的不确定性。正确的做法是把预测的概率分布纳入决策，做风险敏感的规划——不是优化期望收益，而是优化在坏情况下的表现（比如CVaR，条件风险价值）。但这样会让问题变复杂，计算量上升，而且怎么定义"坏情况"又是个主观选择。

我们的折中方案是：对高风险目标（比如预测不确定性高的车、弱势参与者）做保守化处理，扩大安全裕度；对低风险目标正常处理。同时设置一个"风险预算"，当累计风险超过阈值时，主动降速或靠边。这套逻辑写起来不难，难的是阈值怎么定，还是得靠大量路测数据去标。

4.3 交互博弈中的"礼貌"与"果断"如何平衡

交互场景最考验决策的"情商"。太礼貌，一直让行，后面堵一长串，通行效率极低；太果断，见缝就钻，安全员和周围司机都受不了。这个平衡点非常微妙，而且不同地区的驾驶文化还不一样，同样的策略在这个城市好用，换个城市就被骂。

我总结的经验是，交互决策要遵循几个原则。第一，意图要清晰：你要让行就明确减速，要通行就明确加速，最忌讳犹犹豫豫、似走非走，这种"暧昧"行为最容易引发误判和事故。第二，博弈要分级：对行人、非机动车这类弱势参与者，无条件优先；对机动车，可以适度博弈，但要留足退出空间。第三，要有时间压力：不能无限等待，设置一个合理的等待上限，超时后要么果断通行要么换策略，避免死锁。

实现上，我们用了一个简单的博弈框架：把交互建模成序贯决策，每一步评估"我让"和"我走"两种选择的收益，收益里包含安全、效率和对对方意图的估计。关键是对方的意图估计要实时更新——如果对方明显在减速让行，我就该走；如果对方在加速，我就该让。这个更新逻辑用简单的规则就能实现，不一定非要上复杂的博弈论模型。

4.4 仿真测试与实车表现的鸿沟

仿真里跑得再好，实车一上就露馅，这是常态。鸿沟主要来自几个方面。一是感知的仿真不够真实，仿真里的目标检测是完美的，实车有漏检误检，决策得处理这些噪声。二是他车行为模型太理想，仿真里的NPC车要么很规矩要么很傻，真实司机的行为千奇百怪。三是执行误差，仿真假设轨迹能精确跟踪，实车有延迟和偏差。

应对办法是在仿真里主动注入噪声和对抗。我们会在仿真里故意让感知输出抖动、让NPC车做出不合理行为、给控制加延迟，看决策还能不能扛住。这种"压力测试"能提前暴露很多问题。另外就是影子模式：实车运行时决策模块照常计算但不执行，把它的输出和人类司机的操作对比，积累差异数据来迭代。

5. 我对决策算法演进方向的几点判断

5.1 从"单打独斗"到"车路云协同"

单车智能的决策受限于视野和算力，很多场景下信息不足。车路协同能把路侧感知的信息接进来，让决策看到"墙后面"的情况，这对无保护路口、遮挡场景帮助巨大。但协同也带来新问题：通信延迟、信息可信度、责任划分。我的判断是，协同会先从信息辅助切入（路侧告诉你盲区有车），逐步过渡到协同决策，但完全依赖路侧做决策短期内不现实，单车能力仍是基础。

5.2 大模型会给决策带来什么

大模型在决策领域的应用，我目前看到比较有希望的方向是场景理解和常识推理。比如遇到一个从没见过的施工场景，大模型能结合常识判断"这里应该绕行"，而传统规则系统只能报错。但大模型直接输出控制信号我不看好，延迟、稳定性、可解释性都不过关。更现实的用法是让大模型做"高层语义决策"，输出"建议靠左绕行"这样的抽象指令，底层还是交给优化器去生成具体轨迹。

5.3 安全冗余与可解释性的长期价值

无论技术怎么演进，决策模块有两个属性是不能丢的：安全冗余和可解释性。安全冗余意味着任何单点故障都不能导致危险，决策要有独立的监控和兜底。可解释性意味着出了事能说清楚为什么，这在监管和公众信任层面是刚需。学习类方法再强，如果这两点做不到，就很难真正上车。所以我一直认为，未来的决策架构一定是"学习负责能力上限，规则和优化负责安全下限"的混合体。

6. 几个实操层面的经验补充

最后分享几个我在实际项目里踩过、觉得值得记下来的点。第一，决策模块的日志一定要记全，不只是最终输出，中间的候选轨迹、每个目标的代价、约束的松弛情况都要记。出问题时，这些中间量是定位问题的唯一线索，只记输入输出等于抓瞎。第二，给决策加一个"心跳"和"降级"机制，决策计算超时或者异常时，要能平滑降级到最简单的安全策略（比如减速靠边），而不是直接崩溃。第三，别迷信复杂模型，很多场景用简单的规则就能解决，上复杂模型反而引入不确定性，工程上"够用且可靠"比"先进但脆弱"重要得多。

决策算法这个方向，越做越觉得它不像纯技术问题，更像是在工程约束、安全要求、人类习惯之间找平衡的艺术。没有银弹，只有不断的权衡和迭代。如果你正在做这块，欢迎交流，这个领域需要更多一线的经验分享，而不是纸上谈兵。