Waymo Gemini 车载助手系统提示词设计：角色边界、工具调用与安全护栏

无人车里的 AI 助手和手机里的聊天机器人不是一类产品。

手机助手答错一个百科问题，通常只是体验不好；车载助手如果把自己的身份、能力边界或操作权限说错，乘客可能会误以为它能控制车辆，甚至在紧急情况下做出错误判断。自动驾驶车内的 AI 助手必须同时满足三个目标：能帮乘客解决问题，不能干扰驾驶系统，还要在乘客紧张、抱怨、误解时保持稳定表达。

Waymo 车载 Gemini 助手的 1200 多行系统提示词，很适合当成一个车载 AI 助手设计样本来看。它不是简单写一句“你是一个友好的助手”，而是把角色、人设、工具权限、失败处理、隐私边界、竞品话术、车内界面引导都拆成了细粒度规则。

核心设计可以概括成一句话：

Gemini 是乘客助手，不是司机；它可以解释、安抚、调用有限车内功能，但不能控制 Waymo Driver 的驾驶行为。

车载 AI 助手真正解决什么问题

Waymo 的自动驾驶系统叫 Waymo Driver，负责感知环境、规划路线、控制车辆。Gemini 则是车内对话助手，面向乘客提供信息和轻量控制能力，例如调节温度、开关车内灯、控制音乐播放、呼叫客服等。

这两个系统必须分开理解：

车载 AI 助手要解决的不是“让 AI 开车”，而是“让乘客更容易理解和使用无人车服务”。乘客在没有司机的车里，会遇到很多问题：车怎么停、门怎么开、麦克风是否在录音、能不能改下车点、为什么车速不能更快、能不能调温度、遇到不舒服怎么办。传统按钮和菜单可以覆盖一部分操作，但语音助手能降低学习成本，尤其适合乘车这种手不方便操作屏幕的场景。

整体关系可以抽象成这样：

flowchart LR
    R[乘客] -->|按钮激活 / 语音或文本输入| G[Gemini 车载助手]

    G --> C[运行时上下文<br/>乘客名字、行程状态、车辆信息]
    G --> T[工具路由器]

    T -->|可直接执行| Cabin[车内功能<br/>温度、风扇、灯光、音乐、位置、客服]
    T -->|不能执行但乘客可操作| UI[车内屏幕 / Waymo App / 物理控件]
    T -->|越权或敏感| Guard[拒绝或安全重定向]

    D[Waymo Driver<br/>自动驾驶系统] --> V[车辆行驶]
    G -. 无驾驶控制权限 .- D

这套结构里，最关键的虚线是 Gemini 到 Waymo Driver 的“无驾驶控制权限”。如果这条边界模糊，乘客问“你能开快点吗”，助手只要回答得像是自己能影响车速，就会制造危险的能力错觉。

系统提示词不是一句人设，而是一组运行规则

普通聊天机器人经常用一段简短提示词定义风格，例如“你是一个友好、专业、简洁的助手”。车载场景远远不够。Waymo 的设计把提示词拆成多个模块，每个模块负责约束一种行为。

这种设计思路有一个好处：助手的行为不是靠模型“临场发挥”，而是由清晰的策略表驱动。大语言模型（LLM，Large Language Model）仍然负责理解自然语言和生成回复，但关键边界由规则锁住。

最重要的身份边界：Gemini 不能说“我在开车”

车载助手最容易出问题的地方，是把自动驾驶系统的能力说成自己的能力。乘客问“你怎么看路”，如果 Gemini 回答“我用摄像头和激光雷达看路”，听起来就像对话助手本身在控制车辆。

正确做法是把驾驶能力归属给 Waymo Driver：

这种措辞不是文字洁癖，而是安全设计。乘客必须知道：能聊天的 Gemini 和真正控制车辆的 Waymo Driver 是两个不同系统。

可以把这条规则写成一个强约束：

Gemini 可以解释 Waymo Driver 的通用工作方式。
Gemini 不能把驾驶动作、感知能力、决策能力归因于自己。
Gemini 不能承诺改变车辆速度、路线、驾驶风格。

音频优先：车内回答必须短

车内助手大多通过语音输出。语音和文本的交互负担完全不同：文本可以扫读，语音只能按时间线听完。车内还有路况、乘客聊天、音乐等干扰，因此回答越长，越容易变成噪音。

Waymo 的提示词用 input_modality 区分输入来源：

这条规则适合所有车载 AI 产品。比如乘客用语音问“我怎么下车”，助手不适合讲一大段门锁结构，而应该直接给操作步骤：

要下车，拉一次内部车门把手解锁，再拉一次同一个把手打开车门。如果需要帮助，可以使用屏幕上的“支持”按钮。

简短不等于信息少，而是只保留乘客当前动作需要的信息。

个性化只能用最小必要数据

车内助手会拿到一些运行时上下文，例如乘客名字、行程状态、车辆位置、历史乘车次数等。Waymo 的设计允许助手在首次问候时使用乘客名字，例如：

你好，Jane！有什么我可以帮你的吗？

但个人信息不能无限扩展使用。PII（Personally Identifiable Information，个人身份信息）只能用于明确需要的功能，不能主动索取、记录或复述无关隐私。

可以把个性化分成三个等级：

如果乘客主动说出不必要的隐私信息，助手不应该“记下来”，而应该礼貌拒绝：

为了保护你的隐私，我不能记录个人信息。关于当前行程本身，有什么我可以帮忙的吗？

工具调用：能直接做的事情必须直接做

车载助手不是纯聊天系统。它有一组可调用工具，用来控制部分车内功能。Waymo 的提示词强调：如果乘客请求能映射到已有工具，就必须调用工具，而不是去搜索答案。

例如乘客说“车里有点热”，这明显是空调请求，助手应该调用温度设置工具，而不是搜索“车里太热怎么办”。

可用工具大致分为几类：

用伪代码表示，工具路由逻辑可以写成这样：

def handle_request(user_input, context):
    intent = classify_intent(user_input, context)

    if intent.is_driving_control():
        return refuse_driving_control(intent, context)

    if intent.involves_finance_or_sensitive_pii():
        return refuse_for_privacy_and_safety()

    if intent.matches_multiple_tools():
        return ask_clarifying_question(intent)

    if intent.has_direct_tool():
        result = call_tool(intent.tool, intent.arguments)

        if result.failed:
            return explain_tool_failure_and_redirect_to_screen(intent)

        if result.value_is_empty:
            return explain_info_unavailable_and_offer_related_info(result)

        return confirm_tool_result(intent, result)

    if intent.can_be_done_by_user_interface():
        return redirect_by_ui_priority(intent)

    return answer_general_question_or_redirect(intent)

工具调用的决策流程可以画成这样：

flowchart TD
    A[乘客请求] --> B[识别意图]

    B --> C{是否涉及驾驶控制<br/>速度/路线/驾驶风格}
    C -->|是| C1[明确拒绝控制车辆<br/>可提供 ETA 或界面入口]
    C -->|否| D{是否涉及金融交易<br/>或不必要 PII}
    D -->|是| D1[因安全和隐私拒绝]
    D -->|否| E{是否能映射到直接工具}

    E -->|是| F{意图是否明确}
    F -->|否| F1[提出澄清问题]
    F -->|是| G[调用工具]

    G --> H{工具是否成功}
    H -->|成功且有数据| H1[确认结果]
    H -->|调用失败| H2[承认无法处理<br/>引导使用车内屏幕]
    H -->|成功但数据为空| H3[说明信息暂不可用<br/>提供相关信息]

    E -->|否| I{乘客能否通过界面完成}
    I -->|是| I1[按优先级引导<br/>车内屏幕 → App → 物理控件]
    I -->|否| I2[简短说明能力限制]

这里有两个细节很重要。

一是“直接工具优先”。能调温度就调温度，不要把执行型请求变成问答型请求。

二是“不猜测”。如果乘客说“你能弄一下音乐吗”，这个请求可能是暂停、继续、上一首、下一首。助手不能随便跳到下一首，而应该问：

可以。你想暂停音乐，还是跳到下一首？

不是所有车内功能都能控制

Gemini 的工具范围是有限的。音量、车窗、座椅、路线变更、下车点修改等能力并不直接开放给助手。对于这些请求，助手要承认限制，并把乘客导向正确界面。

UI（User Interface，用户界面）引导有固定优先级：

车内屏幕 → Waymo App → 物理控件

例如：

复合请求要拆开处理。比如乘客说：

把温度调高点，并给我看看路线图。

正确顺序是：能做的先做，不能做的立刻给入口。

sequenceDiagram
    participant R as 乘客
    participant G as Gemini
    participant T as 温度工具
    participant UI as 车内屏幕

    R->>G: 把温度调高点，并给我看看路线图
    G->>T: set_temperature_setpoint(...)
    T-->>G: 设置成功
    G-->>R: 已经为你调高温度。要查看路线图，可以在屏幕菜单中选择“路线视图”。

这类处理能避免两个问题：只回答不能查看路线图而忽略温度请求，或者为了完成其中一部分而假装自己能显示路线图。

驾驶控制是硬边界

乘客最可能提出的高风险请求包括：

• 开快点
• 慢点开
• 在这里转弯
• 现在靠边
• 直接停这里
• 开得猛一点
• 别绕路
• 换条路走

这些请求都涉及车辆控制或路线规划。Gemini 不能执行，也不能暗示自己能影响 Waymo Driver。合适的回答模式是：

1. 明确说明自己不能控制车辆速度、路线或驾驶风格。
2. 解释 Waymo Driver 会以安全方式运行并遵守交通规则。
3. 如果有帮助，可以提供 ETA 或指向车内可用按钮。

例如乘客说：

能开快点吗？我要迟到了。

合适回答：

我无法控制车辆速度。Waymo Driver 会以安全平稳的方式行驶；如果你愿意，我可以帮你查看最新预计到达时间。

“停车”请求更复杂，因为同一句话在不同状态下含义不同。

这里的重点不是让助手“更聪明地停车”，而是让乘客知道真正可用的安全入口在哪里。

敏感话题要减少推测

车载助手会遇到很多敏感问题，尤其是事故、竞品、实时驾驶行为。Waymo 的策略很克制：不分析具体事件，不替驾驶系统解释某个瞬间的决策，也不对新闻、视频、事故做确认或否认。

乘客说“我看过一个 Waymo 撞东西的视频，发生了什么”，助手不适合分析视频。更稳妥的回答是：

我无法评论具体事件或报告。Waymo Driver 的设计以安全为优先，并持续处理复杂道路场景。

乘客说“这安全吗？刚才离旁边车好近”，语气上要不同。它不是攻击，而是焦虑。回答要先接住情绪：

我理解这种乘车方式可能会让人感觉不一样。请放心，Waymo Driver 被设计为观察车辆周围环境，并与周围物体保持安全距离。

同样是“不解释具体驾驶动作”，但一个偏事实边界，一个偏情绪安抚。

商业交易和隐私不能碰

车内助手不能处理购买、付款、信用卡、订单等请求。即使模型本身会联网搜索，也不能主动把“我不能下单”扩展成“我帮你找附近商家”。

比如乘客说：

我把信用卡告诉你，你能帮我订披萨吗？

合适回答：

为了你的安全，我不能处理信用卡等个人财务信息，也不能替你下订单。我可以回答问题或控制支持的车内功能。

这里故意不主动搜索披萨店，因为主动搜索会模糊能力边界。乘客可能误以为助手虽然不能下单，但仍然可以参与交易流程。对高风险场景来说，少做一步比多做一步更安全。

失败处理：不能假装成功，也不能编答案

工具调用和上下文读取都会失败。车载助手必须把失败讲清楚，并给出可操作替代方案。

Waymo 的失败协议可以拆成三类：

例如乘客要求打开车内灯，但工具失败：

我现在处理这个有点问题。你也可以使用车内屏幕上的控件打开车内灯。

如果当前位置工具返回了街道名，但速度字段为空，助手不应该说“位置工具失败”，而应该说：

当前速度暂时不可用，不过看起来我们正在 Main Street 上。

这类细节会影响乘客对系统可靠性的判断。承认失败不丢人，假装成功才危险。

对话管理也要写进规则

车载助手不只处理任务，还要处理对话本身。Waymo 的提示词为一些常见互动设定了协议。

比如乘客说“音乐很好听”，助手可以回答：

很高兴你喜欢这首音乐。

乘客说“别说话了”，助手不应该继续解释规则，而应该快速收束：

好的，我现在安静。

如果乘客第三次追问一个超出范围的问题，助手不必继续重复同一句拒绝，可以退出循环：

看来这个问题我无法提供你想要的帮助。我们可以聊点别的；如果需要更多协助，也可以使用屏幕上的“支持”按钮。

这是一种防止对话死循环的设计。

高频问题需要预设口径

车内场景里有些问题会被大量重复询问，适合用预设回答统一口径。

预设回答的意义不是让助手死板，而是减少高风险问题上的口径漂移。尤其是麦克风、下车、支持呼叫这类问题，回答必须短、准、稳定。

可以把这套设计落成一个提示词骨架

如果要设计类似的车载 AI 助手，系统提示词可以按“身份、上下文、能力、策略、失败、预设回答”拆开，而不是写成一整段长说明。

一个简化骨架如下：

assistant_identity:
  name: Gemini
  role: in-car conversational assistant
  not_role: driver
  driving_agent_name: Waymo Driver
  tone:
    - friendly
    - helpful
    - reassuring
    - neutral
    - concise

runtime_context:
  input_modality: audio_or_text
  rider_info:
    allowed_fields:
      - first_name
  trip_context:
    allowed_fields:
      - eta
      - destination_status
      - vehicle_motion_state

capability_map:
  direct_tools:
    - set_temperature_setpoint
    - get_temperature_setpoint
    - set_fan_speed
    - get_fan_speed
    - cabin_lights_on
    - cabin_lights_off
    - next_track
    - previous_track
    - pause_music
    - resume_music
    - get_current_location
    - call_rider_support
  unsupported_controls:
    - vehicle_speed
    - route_change
    - driving_style
    - windows
    - seat_adjustment
    - payment
    - order_purchase

policy_router:
  direct_tool_first: true
  ask_clarification_when_ambiguous: true
  ui_redirection_priority:
    - in_car_screen
    - waymo_app
    - physical_control

failure_protocols:
  tool_error:
    retry_same_tool: false
    response: apologize_and_redirect_to_screen
  missing_context:
    response: do_not_fabricate
  empty_tool_result:
    response: explain_information_unavailable_and_offer_related_info

privacy_policy:
  collect_unnecessary_pii: false
  allowed_pii_usage:
    - first_name_for_greeting

safety_boundaries:
  driving_control:
    response: refuse_and_reference_waymo_driver
  finance:
    response: refuse_for_security_and_privacy
  accidents_or_specific_events:
    response: no_comment_on_specific_event_general_safety_message

真正上线时，提示词只是第一层约束。工具权限必须由后端 API（Application Programming Interface，应用程序编程接口）控制，不能只靠模型自觉。

可靠实现通常需要三层防线：

flowchart LR
    P[系统提示词策略] --> M[模型输出与工具选择]
    M --> A[工具调用权限层]
    A --> S[服务端执行与审计]

    A -->|只允许白名单工具| W[车内舒适功能]
    A -->|拒绝| B[驾驶控制 / 金融交易 / 非必要隐私]
    S --> L[日志、告警、回放测试]

提示词负责让模型“知道不该做什么”，权限层负责让模型“即使想做也做不了”。

测试用例比提示词长度更重要

车载 AI 助手的规则写完后，需要用测试集不断压。测试集不能只包含正常请求，还要覆盖越权、模糊、复合、失败和敏感场景。

对于这类产品，测试用例本身就是安全规范的一部分。提示词越长，越需要结构化测试来确认规则没有互相冲突。

车载 AI 助手设计的几个原则

Waymo Gemini 的设计展示了一种很现实的方向：车载 AI 不应该追求“什么都能聊、什么都能做”，而应该在高风险环境里变得可预测。

可以提炼出几条原则：

1. 角色必须分离：对话助手不能冒充驾驶系统。
2. 工具必须白名单化：只开放低风险车内功能，驾驶控制不能进入工具集。
3. 语音输出要短：车内环境不适合长篇解释。
4. 能执行就执行，不能执行就给入口：不要用闲聊替代操作，也不要假装有权限。
5. 失败要透明：工具失败、数据为空、上下文缺失都不能编。
6. 隐私要最小化：能不用个人信息就不用，不能处理金融交易。
7. 敏感事件不推测：不分析事故、不解释实时驾驶动作。
8. 提示词不能替代权限控制：真正的安全边界必须落到服务端工具权限和审计系统里。

无人车里的 AI 助手越强，越需要学会克制。它的价值不在于替 Waymo Driver 开车，而在于让乘客在无人驾驶环境中知道发生了什么、能做什么、不能做什么，以及遇到问题该按哪个按钮。