很多人一听到“提示工程”这四个字本能想到的是给大模型写“角色扮演”式的对话提示词追求的是让它说话更有条理、更像真人。但我在某量产与预研项目里做了一年多提示工程架构方向的工作之后最大的体会是自动驾驶里的提示工程完全不是这回事。它的核心不在于“把话说漂亮”而在于“设计一套让多模态大模型在受限条件下安全行动的协议”。标题里的“提示工程架构师”就是这样一个特殊角色——他不写端侧的感知代码也不直接调规控参数但他决定了大模型在车上的输入规范、输出契约、评测标准和降级策略。这个角色真正要回答的问题包括如何把多传感器信息压缩成模型能理解的上下文如何让模型输出结构化、可校验的决策如何把交规和乘坐体验变成提示模板里的约束优先级以及如何评估一句提示词的改动会不会让量产车在某个城市场景里多发三次无效变道。把这些讲清楚才算真正“解读”了自动驾驶提示工程。这篇文章适合三类人读正在做模型落地和数据闭环的自动驾驶工程师、想从通用大模型方向跨界过来的同学以及那些认为提示词只是“讲究说话艺术”的人。读完之后你会重新理解提示工程这个岗位的边界和价值。1. 提示系统而非提示词先把“提示工程架构师”的角色重构讲清楚1.1 传统提示工程和自动驾驶提示工程根本不在一个坐标系我面试过不少做通用大模型出身的候选人聊到自动驾驶提示工程时第一反应都是“那你是不是在调自动驾驶模型的语气和风格”这个误解很普遍但不能怪他们因为通用大模型的提示工程已经被“对话体验优化”这件事固化了。实际上传统提示工程的评价体系是“语义满意度”用户问一个问题模型回答得对不对、全不全、自然不自然错了可以重新生成慢了可以等待几秒。自动驾驶提示工程完全不同它的输出是决策级别的模型需要在百毫秒内对连续的物理世界状态做出反应错一次不是重新生成的事而是可能触发接管甚至更严重的后果。我把两套体系的差异整理成一个对比表基本能说清这个问题对比维度通用对话提示工程自动驾驶提示工程输出目标文本回答行为决策 / 轨迹建议 / 风险判断延迟要求秒级甚至分钟级可接受推理阶段百毫秒级别正确率容忍度可重试、可纠错一次错误即可能触发降级或接管上下文来源用户对话、文档、网页多传感器感知、地图、车辆状态、历史决策核心约束语义一致性、风格、知识性交规、安全边界、乘坐体验、物理可执行性失败处理重新生成答案切换到规则兜底或者安全停车从这张表能看出来自动驾驶提示工程从一开始就不是“写提示词”而是一个系统性工程。它处理的对象不是静态文本而是每帧都在变化的多模态状态流。1.2 提示工程架构师到底在架构什么我所在团队的定位是连接“模型能力”和“车辆行为”之间的那一层。感知团队把目标列表和车道线给到我们规控团队告诉我们现在有哪些动作候选集安全团队列出一堆“永远不能违反”的硬约束我们则要把这些信息组织成模型能理解、能输出的提示协议。具体拆开来看提示工程架构师的核心职责有五块。第一设计上下文协议明确哪些信息进提示词、哪些信息不进、以什么顺序进、如何表达坐标和速度。第二定义结构化输出契约让模型输出JSON或函数调用结果而不是自由文本这样规控模块才能解析。第三构建场景化模板体系不同场景要切换不同的约束集合比如雨天、夜间、施工改道、特勤车辆避让各有各的提示差异。第四建立评测基准任何一条提示词改动都要放到固定的场景集里做回归用指标说话。第五制定降级策略模型置信度不足、输出超时、上下文冲突时如何切回规则规划器。这个角色跟“搞算法”不一样的地方在于我们的产出物大部分不是模型权重而是“提示模板文件”“上下文构造代码”“评测场景集”和“上线评审文档”。但它的影响力很大因为模型在每个决策帧看到什么、被要求输出什么、哪些事被禁止做都是从这套协议里来的。2. 提示的输入源设计从传感器原始数据到模型可消费的上下文2.1 多模态原始数据不能直接被扔进提示词很多刚接触自动驾驶大模型的人会有一个直觉既然模型是多模态的那把相机图像、激光雷达点云直接丢进去不就行了实际上在量产域控上这条路走不通。一是算力和显存不允许每帧都处理高分辨率原始数据二是原始数据里存在大量对决策无关紧要的信息比如远处的树、路边的静态设施等全塞进去只会稀释提示的有效性。所以提示工程架构师要设计一个“信息压缩层”。这个层做的事情是把感知模型输出的目标列表、车道拓扑、交通信号状态、自车运动状态筛选、归一化、对齐之后转换成模型可以消费的紧凑上下文。我举个具体例子。一个典型的高速场景提示上下文至少包含这几类信息自车状态当前速度、纵向加速度、转向角、所在车道ID、导航意图第几个出口驶出他车目标目标ID、相对位置、相对速度、尺寸分类、转向灯状态、置信度道路结构当前车道左右边界线类型、邻近车道是否可用、车道曲率、施工区域围挡交通设施交通灯颜色、剩余秒数、限速牌值、是否有临时管制历史决策最近三帧模型的决策ID和执行结果避免前后行为抖动。这些信息并不是靠“写”出来的而是靠一套上下文构造代码从感知和地图接口里读出来的。2.2 一个可落地的场景提示构造流程我把自己常用的一套构造流程简化成伪代码分享出来供参考。这个流程的目的很明确把多源异构数据统一成一个带时间基准和坐标基准的提示序列。def build_scene_prompt(frame, map_vector, nav_instruction): # 1. 统一时间基准所有数据先对齐到同一个时间戳 current_t frame.timestamp aligned_targets align_to_timestamp(frame.targets, current_t) # 2. 统一坐标基准所有目标转换到自车坐标系 ego_t frame.ego_pose local_targets transform_to_ego_frame(aligned_targets, ego_t) # 3. 筛选高显著目标按距离、速度差、置信度过滤 relevant_targets filter_by_significance(local_targets) # 4. 拼接静态上下文地图拓扑 导航意图 场景模板根 static_ctx build_static_context(map_vector, nav_instruction) # 5. 拼接动态上下文目标列表 交通设施 自车状态 dynamic_ctx build_dynamic_context(relevant_targets, frame.traffic_lights, ego_t) # 6. 与少样本示例组合生成最终提示 prompt assemble_prompt(static_ctx, dynamic_ctx, retrieved_examples) return prompt这段伪代码已经在我参与过的多个项目里跑过核心原则也适用于不同模型架构先对齐再筛选再结构化。很多问题出在“对齐”这一步特别是不在同一时间戳的目标被混在一起时模型会误以为多个目标在同一位置进而产生危险决策。2.3 少样本检索与场景记忆让模型学会参考“以前怎么处理”提示工程里有一个常用技巧是把少量历史相似场景的“处理范本”作为少样本示例放进上下文帮助模型理解当前应该采取什么行为模式。这个技巧在自动驾驶场景里同样有价值但实现方式需要调整。我不会把以前的完整轨迹片段塞进去那太占上下文窗口而且容易让模型过度模仿某一次的具体数值。我会做一层抽象从历史路测库中检索“当前场景最相似的N个处理案例”然后只保留三个层次的信息——场景特征摘要、当时的行为决策类型、决策背后的关键原因。比如检索到一个“右侧车辆近距离切入”的案例就提取出“目标车距自车15米横向切入、决策类型为减速让行、原因是切入时相对速度超过5米/秒”来作为示例。这个做法本质上是给模型一个“记忆锚点”让它不是从零开始推理而是能参考过去成功处理过的策略。但要注意示例数量不能贪多我实测下来2到3个高质量示例的效果最佳超过5个之后模型反而会出现策略混杂输出不稳定。2.4 坐标和时间基准两个最容易被忽略的坑在提示上下文设计里最容易被忽视但后果最严重的问题是坐标基准和时间基准不一致。先讲坐标。不同来源的数据接口给出的目标位置可能是全局经纬度、可能是自车当前坐标系、可能是上一帧坐标系。如果在构造提示词之前没有统一坐标系模型就会“看到”目标忽左忽右甚至把右侧车道的车理解成正在逆行。解决方法是所有目标统一转换到自车后轴中心坐标系并且在提示模板里显式声明“所有坐标均以自车后轴中心为原点x轴朝前y轴朝左”。再讲时间。多传感器存在不同的处理延迟相机目标可能落后10ms毫米波目标可能落后30ms如果直接用原始时间戳而不做补偿模型会把同一辆车读成两个目标。我们要在所有上下文构造逻辑里固定一个“时间基准字段”并在提示模板里写明“状态时间为当前帧时刻感知延迟已补偿”。这两行看似只增加了两句话但它们直接决定了模型输出的稳定性。3. 规控侧的提示模板设计行为约束与结构化输出如何落地3.1 约束要有优先级安全、交规、效率、舒适自动驾驶提示模板和通用提示模板最大的差异是每一层约束必须有明确的优先级而且优先级会被下游规控模块严格校验。我的团队习惯把约束分成四层。第一层是安全硬约束绝对不能碰撞、不能冲出可行驶区域、不能违反物理极限第二层是交规约束限速、车道线、交通灯、让行规则正常情况下不可违反第三层是效率约束保持合理车距、选择通畅车道、按时到达导航目的地第四层是舒适约束纵向加速度和横向冲击度控制在一定范围内避免急加速急减速。这个优先级顺序不是写进提示词里就完了而是要在提示模板的字段设计里体现出来。比如“硬约束”和“软约束”要分开成不同的字段因为下游规则校验器会先检查硬约束再评估软约束的满足程度。如果所有约束被混在一个自然语言段落里模型很难区分轻重缓急。3.2 一个可参考的提示模板结构下面是我曾经在项目中用过的一个简化版模板结构用JSON Schema来表示这样规控模块可以直接校验。{ scene_type: highway_follow_with_cutin, time_stamp_ms: 87240912, ego_state: { speed_mps: 28.3, lane_id: 2, intent: keep_lane }, hard_constraints: [ 不得与前车距离小于5米, 不得跨越实线, 不得在目标车横向切入过程中加速 ], soft_constraints: { preferred_headway_m: 25.0, max_deceleration_mps2: 2.5, max_lateral_accel_mps2: 1.2 }, action_candidates: [ keep_lane_and_follow, slight_left_shift_within_lane, emergency_brake_if_needed ], forbidden_actions: [ accelerate_during_cutin, lane_change_to_right ], requested_output: { selected_action: string, target_speed_mps: number, target_relative_clearance_m: number, trajectory_hint: [number], confidence: number } }这个结构看起来不长但每一个字段都不是随便定的。比如“forbidden_actions”这一项就是安全团队给出的危险行为清单提示工程团队把它转成结构化字段又比如“confidence”要求模型输出0到1之间的置信度但我们的后处理并不会完全信任这个值它还要经过校准和阈值判断。3.3 场景化模板切换不同场景要有不同的“纪律”同一套提示模板不可能覆盖所有场景。在高速畅通路段模型的主要任务是稳定巡航在城市拥堵跟车场景模型需要容忍更近的间距、执行更频繁的起步停车在暴雨夜晚模型需要大幅提高跟车距离并且降低变道倾向。我的做法是维护一个“场景模板包”每个模板包对应一组感知状态和外部环境条件。场景切换不是靠模型自己判断而是靠外部模块给信号比如雨天模式由雨刮器和胎压监测联动触发施工改道由V2X消息或感知围栏触发夜间模式直接由时间表和光照传感器触发。这里有个值得特别注意的地方模板切换本身也必须有置信度和滞回区间。如果模型在普通模式和雨天模式之间来回横跳每一帧的提示词都在变模型输出的行为必然抖动。我一般会设置一个“切换确认周期”例如连续三帧都满足切换条件才真正切换模板避免单帧误判带来的行为频繁变化。3.4 结构化输出不是可选项但也不能盲信自动驾驶大模型不能输出自由文本作为规划结果因为规控模块无法解析“我觉得可以慢慢减速”这种话。所以我在设计输出契约时固定采用结构化输出让模型返回一组包含行为、速度、轨迹提示和置信度的字段规控模块再把它作为参考输入。不过结构化输出不等于安全。模型给出的“置信度”只是模型内部的自我评估它可能偏高尤其在训练数据里很少出现的场景中模型经常“自信地犯错”。所以我在下游加了一个置信度校准模块用历史评测数据做分位数校准得到一个校准后的置信度版本。只有当校准后的置信度高于预设阈值时模型的输出才被采纳否则走规则兜底。这个机制看着简单但能挡掉不少提示词微调过程中出现的劣化行为。4. 评测闭环一次提示词改动如何被量化测量4.1 从“感觉变聪明了”到指标收敛提示工程最忌讳的一句话是“感觉效果变好了”。我之前吃过这个亏一条提示词让模型在某个测试路段上表现明显更顺滑但上了另一个城市场景后接管率上升了百分之三十。从那以后我强制团队把每一条提示词改动都纳入评测闭环没有评测结果不允许上线。评测闭环的第一步是建立回归集合。我不会只挑好看的路测片段而是从路测数据中抽出三类场景常规场景占比六成包括高速巡航、城市跟车、红绿灯起步停车挑战场景占比三成包括近距离切入、车辆横穿、行人鬼探头长尾场景占比一成包括异形车辆、施工改道、极端天气。每一类场景都标注成“可回放”的片段提示模板变化后用同样的输入回放再对比模型输出轨迹。4.2 衡量提示词好坏的指标组合单个指标不足以衡量提示词改动的效果我会同时盯五到六个指标并且分场景分层级看。指标含义说明场景完成率场景内是否未发生接管或危险事件最基础的成功率指标接管次数单位里程内安全员手动接管次数提示词劣化最直接的反馈轨迹对齐误差模型输出轨迹与专家轨迹的均方误差衡量行为是否符合预期急刹次数纵向减速度超过3.5m/s²的次数影响乘坐体验和安全感受变道成功率主动变道是否一次完成且无回退关注变道类提示词的影响ECE校准误差模型置信度与真实正确率的差距防止模型“自信地犯错”这些指标各有侧重我不知道你们团队怎么选但我的经验是任何提示词改动至少要同时在“场景完成率”和“接管次数”两个核心指标上不劣化才有继续往下走的资格。4.3 一次A/B测试的完整链路从离线回放到灰度上线我们在实际项目里走的流程可以抽象成六步。第一步提出变更需求明确这条提示词想让模型在什么场景下改变什么行为第二步离线回放在回归集合上跑出指标差异第三步开放闭环仿真在一个仿真环境里连续运行多个小时验证没有明显异常第四步受限路测挑一个限定场景路段由安全员驾驶真实记录行为变化第五步灰度上线按车型和地区小范围放开第六步持续监控观察接管率和急刹次数的周变化。这里我要特别强调一句在改提示词做评测时模型权重一定要冻结。如果一边改提示词一边升模型版本指标变化就无法归因最后出了问题都不知道是改了哪一步导致的。这也是我们的评测流程里最容易被新人忽略的一条铁律。5. Token预算与延迟提示工程在量产域控上的硬约束5.1 上下文窗口不是“装得下”就行还要算延迟很多做云端应用的人对token的概念是“别超出上下文窗口就行”但到了量产车端问题远没那么简单。token数量直接决定推理延迟而推理延迟在自动驾驶决策链路里是有严格预算的。我在某个量产项目里做过一次token压测结论很惊人当提示词从1200 token增加到2400 token时单帧推理延迟增加了将近80毫秒。80毫秒在高速场景下意味着车辆多行驶两米多。所以我在设计提示模板时不是先想“要什么信息”而是先定预算再反推哪些信息必须进、哪些信息可以砍。下面是一份我常用的量级参考提示内容类别token预算占比说明系统提示与角色设定10%以内说明模型角色和输出格式静态地图与导航上下文20%左右缓存后可大幅压缩动态目标与自车状态45%左右核心决策依据少样本示例与场景模板20%左右控制在2到3个示例预留与容错5%防止上下文轻微溢出这组比例不是绝对的但“动态目标占比最高”这个方向始终成立因为动态目标才是决策中最需要模型关注的信息。5.2 上下文压缩的三板斧缓存、增量和筛选既然token预算有限就必须有对应的压缩策略。我在实际项目里反复用到的有三招。第一招是缓存静态内容。地图拓扑、系统设定、导航路径这些信息在一段连续时间内不变完全没必要每帧都重新填充。我会把它们按“道路区块”缓存起来导航路径不变时直接复用缓存内容。第二招是增量更新动态内容。对动态目标列表不是每帧重建全部描述而是只更新目标的增量变化比如“目标ID 0037 相对距离由15米变为12米速度保持”。这样做的前提是目标ID在全链路里是稳定的所以我通常在上下文设计的第一天就跟感知团队对齐目标ID的生成规则。第三招是显著性筛选。动态目标太多时只保留对当前决策最有影响的若干目标。我的筛选逻辑是距离越近权重越高、相对速度差越大权重越高、实际占用本车道或相邻车道优先级最高、能看到转向灯或刹车灯信号的目标也优先保序。通过这种筛选通常可以把动态目标token砍掉一半以上代价只是极少数的边缘信息被忽略对行为影响很小。5.3 延迟分配与降级宁可不要提示也不能让车“呆住”题到最后算账。量产域控的推理延迟分配一般会卡得很紧我给某个项目写过一个目标分配表感知到预测阶段占220毫秒本车模型的提示编码加推理占150毫秒规控解析到执行预留80毫秒。如果提示编码和推理超时系统必须在下一个决策周期开始前决定是继续等待模型输出还是直接切换到规则规划器。我的答案通常是“切换到规则规划器”。因为让车在某个决策帧不做任何动作比让它晚做动作更危险。这里给提示工程架构师一个具体建议上下文构造模块一定要有超时熔断机制一旦构造时间或推理时间超限就自动省略当帧的模型输出由规则规划器兜底。提示词写得再好也必须在“延迟这个硬约束”里让路。6. 跨团队协作与提示词的发布工程从实验到量产6.1 提示词也是代码版本管理要像管模型一样管很多人觉得提示词改动只是文本文件里抹一笔的事直到出了问题才知道后果。在我的团队里提示词模板是放在配置中心里做版本管理的跟代码分支一样走MR评审。每条提示词变更单必须包含变更原因、影响场景、目标行为变化、评测报告、回滚方案。没有这套流程你没法回答“上一版在哪个版本号、为什么效果更好”这种问句。我习惯把“模型版本、提示模板版本、场景包版本”三个版本号绑定成一个整体发布单元。这样一旦路测出现异常我可以直接复现“当时用的是哪三个版本组合”快速定位问题来源。这个做法后来还被其他方向的同事借鉴了因为它把可复现性从“模型维度”扩展到了“整个决策链路”。6.2 和感知、规控、安全团队的接口约定提示工程架构师的工作有一半是“跨团队对齐”。和感知团队对齐的是字段语义目标分类里“卡车”和“公交车”的判定边界是什么置信度指标用的到底是哪个子模块的输出。和规控团队对齐的是动作候选集哪些行为是规控可以执行的哪些只是模型的“建议”而不会被执行。和安全团队对齐的是“禁止项清单”哪些行为在任何情况下都不允许出现要写进提示模板的硬约束字段。我最开始忽视了这个对齐环节结果吃过亏。有一次把“目标车辆占用本车道”写成了“目标车辆在本车道”结果感知团队认为“占用”和“在本车道”不是同一回事模型在特定场景下产生了完全不同的策略。后来我们专门做了一份“提示词字段字典”每个字段都定义到感知接口的原始输出这个字典成为跨团队协作的基础文档。6.3 灰度与回滚提示词比代码更容易回滚但也更容易留坑提示词发布通常采用灰度策略先10%车辆观察两天再扩展到30%再观察最后全量。每个阶段要盯的都是客观指标接管率、急刹次数、无效变道次数、置信度分布。如果在某一阶段指标异常立即回滚到上一个版本。提示词回滚比代码回滚简单因为不需要重新编译只要配置中心发一个新版本或者恢复到旧版本即可。但因为模型有缓存机制上下文缓存和状态缓存里可能还残留上一版本的提示内容回滚后要等待缓存自然过期或者主动清理。这个细节看起来小但如果不处理你会看到“回滚了但现象还在”的怪问题。我习惯在回滚的同时给缓存加一个版本号校验一旦版本不匹配就强制重建内容避免残留。7. 提示工程覆盖不到的地方模型的边界与最后的兜底7.1 提示词不能挽救模型缺失的能力这不是泄气话而是提示工程架构师必须具备的清醒认知。提示词能帮模型“聚焦注意力”但不能给模型“无中生有”的能力。比如某个感知模块在大雨夜里对目标车辆的检测置信度本身就低模型接收到的目标列表就是残缺的你再怎么写“雨天注意横向来车”模型也不可能处理它根本没有感知到的目标。我也见过一种错误倾向提示工程团队试图通过写长提示词来弥补模型能力不足结果上下文越来越长、延迟越来越差、效果却没什么提升。正确的做法是把这类问题反抛给模型团队或感知团队提示工程不该去背模型能力缺失的锅。提示词只是在“能力边界”之内帮助模型做更好的决策边界本身不由提示工程决定。7.2 过度约束会带来反效果一条硬间距提示词的教训分享一个真实的教训。有一段时间某个测试场景里连续出现前车急减速导致的接管团队直接在提示模板里加了一条硬约束“无论任何情况与前车距离不得小于20米”。结果变道成功率在两日内跌了12个百分点因为很多变道场景下20米的距离要求过于苛刻模型几乎无法找到合适的变道窗口。后来我们把这条硬约束改成了软约束并附带一个置信度条件只有当自车速度高于某个阈值时才要求目标间距随速度动态调整到适当范围。改动之后变道成功率恢复了关键场景的接管率也没有劣化。这件事给我的教训是提示工程的核心是“帮助模型在约束中做权衡”而不是“替模型把规则写死”。提示词写得太重模型会变得畏手畏脚写得太轻模型又会忽视安全边界。7.3 人机接管的最后边界定义“放弃提示”的时刻最后说一个更根本的问题提示工程架构师必须想清楚什么时候应该放弃提示词直接让系统进入兜底模式。我在项目中定义了三个“放弃条件”一是关键安全字段持续缺失比如多帧无法获取前车相对速度二是模型输出不具备帧间一致性比如连续三帧输出的目标速度剧烈跳变三是校准后的置信度低于预设阈值同时外部场景模块判定当前处于高风险状态。一旦触发任意一个条件系统会直接跳过模型输出转向安全停车或请求驾驶员接管。这个设计也许会让模型在部分场景中“少做贡献”但它保证了大模型永远不会成为一个“不可控的决策源”。在我看来提示工程在自动驾驶里的最终意义不是让大模型变成万能规划器而是把它的能力约束在一个物理可验证的边界里让它只做自己擅长的、可校验的那部分工作。最后再分享一个我常跟同事说的小技巧每次改提示词之前先写一版“变更假设”说清楚这条提示词到底想让模型在什么场景下改变什么行为然后在评测结果里找证据证明它确实做到了。如果找不到证据说明你可能只是在给模型“做法事”。这句话不太好听但很实在。自动驾驶的提示工程不是写作文它比大多数人想象中更靠近系统架构、评测体系和安全工程。希望这篇解读能给你一个看待这个岗位的新坐标系。