企业官网建设流程全解析

1. 先把这个标题拆开看：车载定制大模型到底在解决什么

前几天刷到一条标题，大意是某新能源车企的掌门人放话，要给自家车型量身定制一个专属的对话大模型。评论区吵成两派，一派说这是营销话术，一派说这是座舱体验的下一代入口。我在车载语音和端侧推理这条线上做了几年，看到这类消息第一反应不是激动，而是习惯性地把标题拆成几个可落地的技术问题：模型放哪儿跑、车控怎么接、安全怎么兜、数据怎么闭环。这篇就把这几个问题一次讲透。

先说清楚这篇文章是什么。它不是新闻解读，也不是产品评测，而是一份车载定制大模型（座舱 Agent）从架构设计到最小可用版本落地的实操拆解。涉及端云协同的算力分配、车辆信号如何注入上下文、工具调用（Function Calling）怎么设计、安全兜底怎么写、灰度测试怎么跑、上线后盯哪些指标。适合三类人看：做座舱软件的产品和研发、想把自己的对话能力塞进硬件终端的算法同学、以及对"大模型上车"这件事好奇但不满足于看热闹的技术爱好者。

为什么"定制"这两个字是关键？因为通用对话模型直接塞进车里，十有八九会翻车。你对着它说"我有点冷"，它可能回你一段关于空调原理的科普；你说"把风调小点"，它可能把温度调高。车里这个场景的特殊性在于：指令短、上下文强依赖传感器、容错率极低、用户耐心只有两秒。通用模型擅长的是长文本理解和开放生成，而车里需要的是"听得懂、接得准、控得住"。这两件事的能力模型完全不是一个方向。所以"量身定制"不是加个车规外壳，而是从模型选型、上下文构造、工具协议到安全策略的一整套重做。下面我按实际做项目的顺序往下拆。

1.1 从"语音助手"到"座舱 Agent"，差别不在模型大小

很多人以为升级就是把原来的规则式语音助手换成一个几十亿参数的大模型，其实真正的差别在决策路径。老一代语音助手是"意图分类 + 槽位填充 + 固定话术"三段式，工程上叫 pipeline，好处是可控、可测、延迟低，坏处是覆盖面窄，用户稍微换个说法就掉到兜底话术里。我见过最典型的情况：用户说"前面那个服务区还有多远"，规则库里只有"距离最近服务区"这一条，识别不了"前面那个"这种指代，直接回"抱歉我没听懂"。

大模型带来的变化是把"理解 + 决策 + 生成"揉成了一个环节，它能处理模糊表达、能追问澄清、能把一句话里的多个意图拆开。比如"把空调调到24度然后把座椅加热关掉，顺便看看还有多久到"，这句话里三个动作加一个查询，规则式方案要写四条正则，而 Agent 方案只需要一次工具编排。但代价也很直接：延迟上去了、不确定性上去了、测试用例从几百条变成几万条。所以我在项目里一直坚持一个观点——不是所有指令都该交给大模型。高频、明确、安全相关的指令走规则通道，模糊、复合、需要解释的走模型通道，两条路并存才是能上车的形态。这也是后面端云分工和路由设计的出发点。

1.2 通用对话模型直接上车，会撞上哪几堵墙

我在内部做过一次对照实验，把同一个通用对话接口接到模拟座舱里，跑了两百条真实车主指令，结果有四类问题反复出现。第一类是幻觉补全：车内噪声大，语音识别把"打开除雾"听成"打开橱雾"，模型不去追问，反而自信地编了一个不存在的功能。第二类是单位与量纲混乱：用户说"温度调两度"，模型分不清是调到两度还是加减两度，也分不清摄氏华氏。第三类是越权执行：用户开玩笑说"把车窗全打开"，模型老老实实执行，完全不管当时车速一百二。第四类是上下文丢失：多轮对话里"再大一点"到底指音量还是风速，模型在前一轮没锁死指代对象。

这四类问题本质上不是模型不够聪明，而是缺约束。约束来自三个地方：结构化输入（车辆状态要显式喂进去，而不是让模型猜）、工具协议（每个动作的参数范围、前置条件、禁用场景要写死在 schema 里）、以及一层规则校验（模型输出必须过一遍硬校验才能下发到执行器）。我常跟团队说，模型在车里不是一个"司机"，它是一个"副驾"，负责理解和建议，方向盘和刹车必须留在确定性系统手里。这句话听着像口号，但落到代码上就是一条铁律：任何改变车辆物理状态的指令，都不能由模型直接下发。

1.3 这套东西的适用边界在哪儿

得说清楚，不是所有车、所有场景都值得做定制大模型。我判断的标准有三条：座舱芯片的 NPU 算力能不能撑起端侧小模型（后面会给估算方法）、云端链路是否稳定到能接受首字几百毫秒的抖动、以及整车电子电气架构是否支持把车控信号以较低成本汇总到座舱域。三条缺一条，我建议先做"云端为主 + 端侧兜底"的轻量版本，别一上来就追求全端侧。

反过来，如果你的车已经在量产车上跑通了连续对话、支持多意图指令、且有一套相对完整的信号上报机制，那这套方案的收益会非常明显。用户感知最强烈的不是"它能聊诗和远方"，而是"我说一句它就懂，不用重复第二遍"。这一点在真实车主调研里几乎每次都能排到座舱体验的第一位。所以别被标题里的热度带偏，定制大模型的价值不在炫技，在于把"听懂一句话"的成功率从七成拉到九成以上，剩下的都是加分项。

2. 整体架构怎么搭：端云分工与三层边界

动手之前必须先定架构，因为架构决定了后面所有细节。车载大模型最容易犯的错误是"一刀切"——要么全放云端，隧道里一断网就变砖；要么全塞端侧，算力和内存都不够，体验稀碎。我在几个项目里摸下来，比较稳的形态是端云协同 + 三层边界：端侧负责快、云端负责难、规则层负责狠。

端侧放什么？放那些必须在一秒内响应、且不需要复杂推理的任务：唤醒词检测、语音识别流式首字、意图粗分类、槽位抽取、简单车控指令解析、离线兜底话术。这些任务用 1B 到 3B 级别的量化模型就能覆盖，内存占用可控。云端放什么？放开放域问答、多轮复杂澄清、路线规划说明、跨域任务编排、以及需要外部信息检索的场景。规则层放什么？放所有涉及车辆物理动作的最终校验、参数钳制、场景禁用判断。这三层的关系是：端侧先接手，判断"这活儿我能不能干"，能干就干，不能干就带着结构化上下文上云，云端返回动作意图后再经过规则层放行。

这个分工听起来朴素，但真正落地时会发现一个隐藏成本：上下文在端云之间来回搬，格式必须统一。我在第一个项目里就吃过亏，端侧喂给云端的上下文和云端自己拼的上下文用了两套字段命名，结果同一个"温度"字段一边是整数一边是字符串，导致工具调用参数校验疯狂报错。后来我们把上下文定义成一份 schema，端云共用同一份定义文件生成代码，这类问题才彻底消失。

2.1 端侧小模型和云端大模型，算力账怎么算

选型之前先算账，别拍脑袋。端侧模型的速度瓶颈通常不是算力（TOPS），而是内存带宽。解码阶段每生成一个 token，都要把模型权重完整读一遍，所以理论解码速度约等于"内存带宽 ÷ 权重大小"。举个具体的算法：一个 7B 模型用 INT4 量化，权重约 3.5GB，如果座舱域控制器的有效带宽按 50GB/s 估，理论上限是 50 / 3.5 ≈ 14 token/s。这还只是理论值，实际要打个六折左右，也就是 8 到 9 token/s。这种速度用来做车控指令够用（一句"打开空调"输出十几个 token 就够），但用来做长篇回答就明显卡顿。

再看小模型。一个 1.5B 模型 INT4 量化约 0.9GB，同样的带宽下理论能跑到 50 token/s 以上，实测三十多，做意图分类和槽位抽取非常宽裕。所以我的常见配置是：端侧挂一个 1.5B 到 3B 的模型专门做"路由 + 抽取"，云端挂一个几十B的模型做"理解 + 编排 + 生成"。中间加一条判定线：端侧置信度高于阈值就直接执行，低于阈值就上云。这个阈值怎么定，后面第四章会给实测方法。

2.2 车控域、座舱域、云端的三层隔离

隔离这件事在车里不是可选项。我见过一些早期方案，让模型直接调用一个通用的"执行动作"接口，参数是一个自由文本，结果模型某次输出了个不存在的动作名，整条链路静默失败，用户以为车坏了。正确做法是把三个域物理和逻辑上都隔开：

这张表的关键在于中间那层。规则校验层是模型的"刹车"，它的输入必须是结构化参数，不能是自然语言。举个最常见的例子：模型输出"把温度调低"，校验层要收到的是{"device":"climate","field":"temperature","delta":-2,"unit":"celsius"}，然后校验层检查 -2 在允许范围内、当前不在极寒保护模式、目标温度不低于 16 度，全部通过才转成车控指令。模型再聪明，也过不了这层硬闸门。这条设计我在每个项目里都会坚持，因为它把"模型出错"的后果从"车行为异常"降级成了"这次没听懂"。

2.3 数据和隐私的边界，得在架构阶段就画死

车内是个高度私密的空间，这一点在架构阶段就必须处理，不能等出事再补。我的原则是三条：原始音视频不出车、声纹和身份信息本地处理、上云的只有脱敏文本和必要信号。具体到实现，麦克风采到的音频在端侧做完识别后，原始音频流直接丢弃，只保留文本；车内摄像头的画面除非用户主动触发（比如拍照），否则不进入推理链路；车辆信号上云前要做白名单过滤，位置信息做模糊化处理，比如把精确坐标降精度到百米级，或者直接换算成"距目的地约 X 公里"。

还有一个容易被忽略的点是日志留存。为了排查问题，我们肯定要存对话日志，但存多久、存多细、谁能看，必须有明确规则。我们内部的做法是对话文本留存周期短于车辆信号，敏感字段做哈希，调试用的完整日志只在灰度阶段开启，全量发布后默认关闭详细日志。这套东西写起来不复杂，但要在架构评审时就定下来，因为后期再加会牵扯到大量数据链路改造。我在一个项目里就是因为日志方案定晚了，上线前两周返工，代价不小。

3. 核心细节：把车辆信号变成模型能吃的上下文

这一章是整篇文章最硬的部分。模型能不能听懂人话，一半靠模型本身，另一半靠你喂给它的上下文。很多团队在这块偷懒，只把用户这句话丢给模型，结果模型只能靠猜。正确的做法是每一轮对话都携一份结构化的车辆状态快照，让模型知道"现在几点、车在哪儿、开多快、空调什么状态、后排有没有人"。

状态快照的设计有两个原则。第一是只给相关的，不要把几百个信号全塞进去，那会把上下文窗口撑爆，还会稀释模型注意力。第二是给换算后的语义值，不要给原始报文值。比如车速不要给0x1A3F，给speed_kmh: 62；电量不要给百分比原始值，给battery_pct: 34, range_km: 152, is_low: false。这种语义化处理看着琐碎，但对模型准确率的提升是肉眼可见的，我在对照测试里见过同一句话在语义化上下文下正确率从 61% 提升到 88%。

快照的字段要按场景分组：驾驶态（速度、挡位、辅助驾驶状态）、环境态（车内外温度、天气、时间、光照）、舒适态（空调、座椅、车窗、氛围灯）、能量态（电量、续航、充电状态）、乘员态（座位占用、儿童座椅状态）。每一组控制在十个字段以内，总量控制在五十个字段内，这样 token 开销大概在两三百，完全可接受。

3.1 上下文构造的实际写法与 token 预算

我把上下文分三段拼：系统提示词、车辆快照、对话历史。系统提示词写角色和铁律，控制在三百 token 内；车辆快照用紧凑 JSON，两百 token 左右；对话历史只保留最近三轮，超出就做摘要压缩。整个输入预算压在 1200 token 以内，这样云端推理的首字延迟能稳在五百毫秒级别。

# 上下文构造的最小示例（示意，非真实接口） def build_context(user_utterance, vehicle_state, history): snapshot = { "time": vehicle_state["local_time"], "speed_kmh": vehicle_state["speed"], "gear": vehicle_state["gear"], "inside_temp_c": vehicle_state["cabin_temp"], "outside_temp_c": vehicle_state["ambient_temp"], "climate": { "on": vehicle_state["ac_on"], "target_c": vehicle_state["ac_target"], "fan_level": vehicle_state["fan_level"], }, "energy": { "battery_pct": vehicle_state["soc"], "range_km": vehicle_state["range"], }, "occupancy": vehicle_state["seat_occupied"], # 例: {"driver":1,"rear_left":1} } messages = [{"role": "system", "content": SYSTEM_PROMPT}] messages.append({"role": "system", "content": "当前车辆状态:" + json.dumps(snapshot, ensure_ascii=False)}) messages.extend(compress(history, keep_turns=3)) messages.append({"role": "user", "content": user_utterance}) return messages

注意：快照里的字段名要用稳定的英文标识，别用中文键名，否则跨端解析时编码问题会让你调半天。另外布尔值和数值别混用，ac_on就老老实实给true/false，不要一会儿给1一会儿给"on"，模型对这类不一致非常敏感。

3.2 工具调用怎么设计，才不会被模型乱用

工具调用（Function Calling）是座舱 Agent 的手脚，设计得好坏直接决定体验。我总结出四条硬规矩。第一，工具粒度要粗一点，别把"调高温度"和"调低温度"拆成两个工具，给一个set_climate带delta参数就够了，工具越多模型选错的概率越高。第二，每个参数都要有范围和单位，写进 schema，别指望模型自己知道摄氏度范围是 16 到 30。第三，必须写"什么时候不要调用"，这一条最容易被忽略，但对减少误触发极其有效。第四，描述里给正例和反例，模型对示例的敏感度远高于对规则的敏感度。

{ "name": "set_climate", "description": "调整座舱空调。仅在用户明确表达冷热感受或直接要求调节空调时调用。用户只是描述天气、询问功能、或表达情绪时不要调用。", "parameters": { "type": "object", "properties": { "delta_c": { "type": "number", "minimum": -5, "maximum": 5, "description": "温度相对变化量，单位摄氏度。'调低两度'对应 -2。" }, "fan_level": { "type": "integer", "minimum": 0, "maximum": 5, "description": "风速档位，0 为关闭。用户未提及则不要填。" } }, "required": ["delta_c"] } }

这段 schema 里有个细节值得单独说：delta_c用的是相对变化量而不是绝对目标温度。为什么？因为用户说"有点冷"时，模型不知道当前设定温度是多少，用相对量更贴近自然语言表达，也避免了"用户说调低结果反而调高"这类经典错误。绝对温度只在用户明确说"调到 24 度"时才用，这就需要在工具里再加一个target_c字段并做互斥校验。这类设计上的取舍，文档里通常不写，但实际调起来差别很大。

3.3 意图澄清：什么时候该追问，什么时候别啰嗦

追问是把双刃剑。用户说"有点热"，你回一句"请问您是想调低温度还是调小风量"，体验就崩了。我的策略是默认执行最优猜测，只在猜测成本高或不可逆时才追问。判断依据是三个维度：指令是否可逆、影响范围多大、置信度多高。调温度可逆、影响单人，置信度过六成就直接执行；开窗涉及安全和天气，置信度不过八成先问一句；涉及儿童座椅、驾驶模式这类不可逆或高风险的，一律追问。

多轮指代是另一个坑。"再大一点"这四个字，可能是音量、风速、座椅角度、导航缩放。解决办法是在上一轮执行后记录一个指代锚点，把最近操作的对象写进上下文，模型下一轮优先解析到这个对象。实现上很简单，在状态快照里加一个last_action字段，记录最近一次工具名和关键参数。这个字段加上去之后，多轮指令的解析成功率提升非常明显，我实测过一轮，从七成出头提到九成。这个技巧几乎零成本，但效果立竿见影，强烈建议加上。

3.4 安全兜底：模型可以犯错，但不能犯大错

兜底分三层。第一层是参数钳制，模型给的参数超出物理范围就直接截断到边界值，同时记一条日志，用于后续优化提示词。第二层是场景禁用，维护一张"场景—动作"的禁用表，比如高速行驶时禁止调整座椅到躺平、行驶中禁止中控播放视频、电量极低时禁止大功率加热。第三层是兜底话术，任何一层校验不通过，都不向用户暴露技术细节，只说"这个操作现在不方便执行"，并给出替代建议。

还有一类兜底容易被漏掉：恶意或玩笑指令。用户说"把车开到河里"，模型不能顺着接梗，也不能一本正经地解释危险。我的做法是在系统提示词里明确写死一组拒答规则，同时把这类输入在端侧就拦掉，不走云端，避免浪费链路。这类规则的写法要注意，别写成一大段道德说教，模型会把它当成可协商的内容。写成短句、祈使句、带明确触发词的规则，执行率最高。

4. 实操过程：从零跑通一个最小可用版本

理论讲完，进实操。这一章我按自己的项目节奏走一遍，从环境准备到灰度上线，把能抄的部分都写出来。需要说明的是，具体接口和参数各家不同，我给的是方法和量级，落地时按自己平台的文档替换。

第一步是确定最小闭环。别一上来就做全场景，先选三个高频指令：空调温度、导航目的地、媒体播放。这三类覆盖了座舱交互的绝大部分请求，且分别代表"连续量调节""路径规划""内容检索"三种不同的工具形态，跑通这三个，剩下的都是复制粘贴。我一般要求团队在两周内做出能演示的版本，跑不通就说明架构有问题，早点返工比后期改成本低。

第二步是准备测试集。这是最容易被低估的工作。我的要求是至少五百条真实表达，来源包括车主访谈记录、客服工单、内测反馈，每条标注期望动作和参数。测试集要包含三类难例：带噪声的语音识别结果、一句话多意图、以及刻意模糊的表达。这套测试集是整个项目的标尺，后面每次改提示词、换模型、调阈值，都要拿它跑一遍，看指标是涨是跌。

4.1 模型选型和部署环境的具体配置

端侧模型我一般选 1.5B 到 3B 的参数规模，量化到 INT4 或 INT8。选择依据不是榜单分数，而是在自己的芯片上实测的首 token 延迟和吞吐。同一份权重在不同 NPU 上的表现能差两三倍，务必实测。部署时注意两个细节：一是把模型常驻内存，别每次唤醒都重新加载，加载一次几百毫秒，用户等不起；二是把 KV cache 预分配好，避免运行中动态扩容导致卡顿。

云端这边选择空间大，重点是首字延迟和并发成本。我的经验值是首字延迟压到六百毫秒以内，用户基本感知不到等待。并发按峰值的百分之三预估，别按日活算，早高峰大家一起出门，瞬时并发会很吓人。缓存策略上，把高频查询（天气、路况、充电站）做结果缓存，命中率能到三成，能省不少成本。

下面是一份简化的部署配置示意，字段名按需替换：

edge_model: name: intent-router-small params: 1.8B quant: int4 max_context: 2048 residency: persistent # 常驻内存，唤醒不重载 kv_cache_prealloc: true timeout_ms: 800 # 超时直接降级到规则通道 cloud_model: name: cabin-agent-large max_context: 8192 temperature: 0.2 # 车控场景不要创造性 top_p: 0.8 stream: true # 流式返回，首字优先 timeout_ms: 2500 routing: edge_confidence_threshold: 0.72 fallback_to_rules: true max_tool_rounds: 3 # 防止模型无限调用工具

max_tool_rounds这个参数别忽略。我见过模型在工具返回失败后不断重试，一轮对话调了七八次接口，延迟爆炸。设成三轮，超了就走兜底，用户体验反而更好。

4.2 提示词和工具描述的实际写法

系统提示词我一般分三块写：身份与边界、可用能力、输出格式。身份与边界写"你是某车型的座舱助手，只处理与车辆和出行相关的问题，其他话题礼貌拒绝"；可用能力列出工具清单和调用原则；输出格式规定要么给工具调用，要么给自然语言回答，不要混着来。

这里有个实操经验值得分享：提示词里写"不要做什么"比写"要做什么"更有效。比如"不要在用户没有明确要求时主动调节空调""不要在行驶中建议用户操作中控屏""不要把用户的玩笑当成指令"。这三条写进去之后，误触发率下降非常明显。原因也简单，模型在模糊场景下倾向于"做点什么"，负面约束能有效压制这个倾向。

另一个技巧是给模型一个"不确定"的出口。在提示词里明确告诉它，如果置信度不足可以调用ask_clarify工具追问，而不是硬猜。这个出口一开，错误执行的比率会降下来，代价是平均对话轮次上升一点点。我的经验是这笔交易划算，用户对"多问一句"的容忍度远高于"做错一次"。

4.3 灰盒测试和仿真回放怎么做

上线前必须过仿真回放。做法是把真实语音指令和对应的车辆信号一起录下来，做成一个个场景包，然后让新版本在离线环境里跑，跟期望动作对比打分。指标看四个：任务完成率、参数准确率、平均响应轮次、兜底触发率。我一般要求任务完成率过九成、参数准确率过九成五才允许进灰度。

仿真环境有个坑要提前处理：信号回放要和语音严格对齐。如果语音说的是"开空调"时车还在启动阶段，而回放时车已经行驶，模型判断可能完全不同。解决办法是给每个场景包打上时间戳，回放时按时间戳同步注入信号。这个工程细节看着不起眼，但没做好，测试结果全是噪音，白跑。

灰度阶段我建议分三批：内部员工车、种子用户、公开推送。每批之间至少观察一周，重点看两个指标——兜底触发率有没有异常升高（说明模型在真实噪声下理解能力下降）、用户打断率（说明回答太长或答非所问）。这两个指标比准确率更灵敏，能提前发现问题。

4.4 上线后盯哪些指标，怎么定位退化

上线不是终点。我维护的监控看板上有六个核心指标：首字延迟 P50 和 P95、工具调用成功率、多轮澄清占比、兜底触发率、用户主动打断率、单次会话平均指令数。前两个看性能，中间两个看理解，后两个看体验。任何一个指标周环比波动超过两成，就要去查原因。

定位退化最快的方法是抽样回放。从线上日志里随机抽两百条失败对话，脱敏后放进仿真环境重跑，看是新模型的问题、提示词的问题、还是信号注入的问题。我在一个项目里遇到过这种情况：某次 OTA 后温度调节类指令失败率突然涨了三成，查了两天，最后发现是空调域的信号上报周期从一秒改成了五秒，模型拿到的状态是过期的，判断自然出错。这种跨域问题靠读代码很难发现，只能靠日志回放定位。

5. 常见问题与排查实录

这一章是我这几年攒下来的问题清单，基本都是文档里不会写、但真上手一定会撞上的。按我的经验，把这些问题提前处理掉，能省下至少一半的联调时间。

5.1 典型故障速查表

这张表里我最想强调的是最后一行。提示词和工具 schema 是强耦合的，schema 改了字段名而提示词里还写着旧名字，模型就会调用一个不存在的参数，整条链路报错。解决办法是把两者放在同一个配置文件里，打包成一个版本，禁止单独更新。这个规矩定下来之后，这类事故基本绝迹。

5.2 几个踩过的坑，都是真金白银换的

第一个坑是过度依赖负面示例。早期我在工具描述里写了一堆"不要这样、不要那样"，结果模型变得极其保守，用户正常说"把风调大点"它都要追问一句"您是指空调风速吗"，体验很差。后来调整成"给两个正例、一个反例"，比例控制住，才找到平衡点。这件事让我明白，提示词工程不是越多越好，找到那个临界点才是本事。

第二个坑是忽略语音识别的错误传播。车内有风噪路噪，识别结果本来就有错字，模型拿到错字后如果强行理解，就会产生幻觉。我的处理办法是在端侧加一层置信度过滤：识别置信度低于阈值的片段标记成"?"，让模型知道这里不确定，主动追问。加了这一层之后，噪声场景下的错误执行率降了一个量级。这个改动很小，但收益极大。

第三个坑是测试集和真实场景脱节。我们早期用的测试集是坐在安静办公室里录的，结果一上车就崩。后来改成"必须带真实路噪录制"，且至少覆盖三种车速、两种车窗状态。这件事听起来理所当然，但真正严格执行的团队不多。我的建议是测试集录制当成一个独立的工程任务来管，别让算法同学顺手录几条就完事。

5.3 给准备动手的人几句实在话

如果你现在就打算立项，我给三个建议。第一，先把规则通道做扎实，别指望大模型一步到位。规则通道是兜底，也是对照组，没有它你连模型好在哪儿都说不清。第二，把评估体系建在模型之前。测试集、指标、回放工具，这些是地基，地基没打好，后面每次迭代都是盲人摸象。第三，别急着上全场景。三个高频场景跑通、指标稳定一个月，再扩，这个节奏最稳。

还有一个容易被忽略的点：用户教育。大模型座舱的表达习惯和传统语音助手不一样，用户可以连续说、可以一句话说多个事，但很多老用户还是习惯一句一顿。我们在车机里加了一段很短的引导语，说明"可以连着说"，后续的多轮指令占比明显上升。这类软性的东西不写进技术文档，但对体验的影响不比模型小。

6. 我个人在这条线上的几点体会

做了几个项目下来，我最大的感受是：车载大模型的胜负手不在模型，在工程。榜单上分数高的模型，塞进车里不一定好用；那些看起来参数不大的模型，配上扎实的上下文工程和工具设计，体验反而更稳。我见过团队花三个月换模型，指标涨了两个点；也见过团队花三周把状态快照语义化，指标涨了二十多个点。方向选错了，努力是白费的。

另一个体会是关于克制。座舱这个场景最忌讳"什么都能聊"。用户上车是要去某个地方，不是来找人聊天的。模型能力再强，也要守住边界：该一句说完的别绕三句，该直接执行的别追问，该拒绝的别硬接。我现在的默认设置是把回答长度压得很短，除非用户明确要求解释。这个策略上线后，用户打断率降了不少，满意度反而升了。

最后分享一个小技巧，关于提示词的迭代节奏。我现在的做法是每次只改一处，改完必须跑完整测试集，指标不涨就回滚，绝不叠加修改。这样虽然慢，但每一步都可归因，出了问题能立刻定位。早期我图快，一次改五处，结果指标掉了却不知道是哪处改坏的，只能全部回滚重来，反而更慢。这条经验放在任何提示词工程里都适用，值得刻在工位上。

至于这类"给车定制对话模型"的事后续还能怎么走，我个人的判断是会往两个方向分化：一部分能力继续下沉到端侧，做到断网也能用；另一部分往上走，跟行程规划、补能规划这些长链路任务深度绑定。但不管往哪走，前面那套"端云分工、规则兜底、评估先行"的底子不会变，把这些做扎实了，换什么模型都不慌。