# 对齐车机方案的实施流程复审

## 1. 目标

本文档用于重新审视当前项目的实现方向，并将“对齐小鹏车机类方案”的核心流程、分支决策和典型场景演示明确下来。

目标不是做一个普通聊天机器人，而是做一个面向车机/客服/前台场景的低延迟执行型 Agent：

- 简单请求本地快速闭环
- 复杂请求云端增强处理
- 多轮短句能够恢复上下文
- 多命令能够拆分为 workflow 执行
- 超出能力边界时明确拒绝或澄清

---

## 2. 对齐车机方案的核心原则

结合前面参考的小鹏公开专利，可以抽象出下面几个工程原则：

- 本地优先，云端增强，不是所有请求都直接走远端大模型
- 本地不是单模型，而是多支路并发
- 快反馈和最终反馈分离，首反馈必须短而稳
- 多轮短句优先靠上下文改写和缓存恢复，不是每轮重做完整规划
- 高风险动作必须确认
- 超能力边界时必须拒答，不能强行分类执行

---

## 3. 总体流程图

```mermaid
flowchart TD
    A[用户语音输入] --> B[ASR 转文本]
    B --> C[文本归一化]
    C --> D[本地多支路并发]

    D --> D1[keyword / rule / trie]
    D --> D2[local bert classifier]
    D --> D3[context rewrite / cache]
    D --> D4[retrieval matcher]

    D1 --> E[本地融合分级器]
    D2 --> E
    D3 --> E
    D4 --> E

    E -->|高置信| F[直接执行或直接生成 workflow]
    E -->|中置信| G[等待 100~300ms 观察补充分支/云端结果]
    E -->|低置信| H[云端 planner / LLM / RAG]

    G --> H
    H --> I[生成 intent / workflow / clarify / reject]

    F --> J[插件执行]
    I --> J

    J --> K[首反馈 ack / progress]
    J --> L[最终反馈 result / clarify / reject]
```

---

## 4. 本地与云端分工

### 4.1 本地快链路

本地负责：

- 高频固定控制类命令
- 已知业务集合内的快速意图识别
- 短句、省略句、连续调节的上下文恢复
- 简单任务的直接执行
- `<1s` 以内的首响应

本地组件：

- `keyword / rule / trie`
- `local bert classifier`
- `context rewrite / cache`
- `retrieval matcher`
- `fusion grader`

### 4.2 云端慢链路

云端负责：

- 多命令拆分
- 条件型请求理解
- 歧义消解
- 复杂问答
- planner 级 workflow 生成

---

## 5. 本地分级决策图

```mermaid
flowchart TD
    A[本地多分支结果] --> B{融合分级}
    B -->|high| C[直接执行]
    B -->|medium| D[等待 100~300ms]
    B -->|low| E[不直接执行]

    D --> F{云端是否及时返回}
    F -->|是| G[采用云端结果或覆盖本地]
    F -->|否| H{本地是否达到最低执行阈值}

    H -->|是| I[执行本地结果]
    H -->|否| J[澄清或拒答]

    E --> K[云端理解 / clarify / reject]
```

关键修正点：

- 不是“本地 BERT 有结果就执行”
- 不是“云端没返回就一定执行本地”
- 必须先判断本地结果是否达到最低可执行阈值
- 高风险动作即使高置信，也不能直接执行

---

## 6. 用户反馈状态图

```mermaid
stateDiagram-v2
    [*] --> Received
    Received --> Ack: 已接收请求
    Ack --> ExecutingFast: 本地快执行
    Ack --> WaitingCloud: 等待云端/复杂规划
    Ack --> Clarify: 缺关键槽位
    Ack --> Confirm: 高风险动作
    Ack --> Reject: 超能力边界

    ExecutingFast --> Result
    WaitingCloud --> Result
    Clarify --> Result
    Confirm --> Result
    Reject --> [*]
    Result --> [*]
```

反馈规则：

- `ack`：收到，马上处理
- `progress`：正在为你处理
- `result`：执行完成或查询完成
- `clarify`：信息不足，补一个关键字段
- `confirm`：高风险动作确认
- `reject`：能力边界拒答

---

## 7. 反馈模板策略

### 7.1 快执行

适用：

- 打开车窗
- 调低空调
- 播放音乐
- 导航去公司

推荐反馈：

- 首反馈：`好的，正在打开车窗`
- 最终反馈：`车窗已打开`

如果设备动作极快，也可以直接播报最终反馈：

- `车窗已打开`

### 7.2 慢执行

适用：

- 查订单
- 查物流
- 多命令复杂规划
- 条件型任务

推荐反馈：

- 首反馈：`收到，我先帮你查一下`
- 最终反馈：`订单还没发货`

### 7.3 复合命令

例如：

- `打开车窗，空调调低至20度`

推荐反馈：

- 首反馈：`好的，正在为你打开车窗并调低空调`
- 最终反馈：`车窗已打开，空调已调到20度`

### 7.4 边界外请求

例如：

- `打开飞机门`

推荐反馈：

- `这个我暂时做不了，但我可以帮你导航、查订单、调空调或播放音乐`

---

## 8. 多轮上下文恢复流程

```mermaid
flowchart TD
    A[当前轮输入: 再低一点] --> B[读取 session context]
    B --> C{是否命中高频改写缓存}
    C -->|是| D[改写为完整句]
    C -->|否| E[轻量改写模型/规则补全]
    D --> F[进入 router]
    E --> F
    F --> G[意图识别 + 槽位提取 + 执行]
```

说明：

- 这里的“上下文能力”不是 BERT 自己缓存的
- 而是 Agent 在 `session state` 中保存上轮任务和关键槽位
- 再由 `rewrite engine` 完成短句恢复

---

## 9. 典型场景流程演示

### 9.1 场景一：快执行单命令

用户输入：

- `打开车窗`

处理流程：

1. ASR 转文本：`打开车窗`
2. 文本归一化
3. 本地多支路并发
4. 若本地高置信命中 `cabin_open_window`
5. 直接执行车窗插件
6. 播报：`车窗已打开`

时序演示：

```mermaid
sequenceDiagram
    participant U as 用户
    participant A as ASR
    participant R as 本地路由
    participant P as 插件执行
    participant T as TTS

    U->>A: 打开车窗
    A->>R: 打开车窗
    R->>P: 执行 open_window
    P-->>R: success
    R->>T: 车窗已打开
    T-->>U: 车窗已打开
```

### 9.2 场景二：复合命令快执行

用户输入：

- `打开车窗，空调调低至20度`

处理流程：

1. 文本进入本地路由
2. 判断为多命令
3. planner 或本地 splitter 输出两个 step
4. 生成 sequence workflow
5. 顺序执行：
   - 打开车窗
   - 空调调到 20 度
6. 汇总反馈：`车窗已打开，空调已调到20度`

时序演示：

```mermaid
sequenceDiagram
    participant U as 用户
    participant A as ASR
    participant F as 融合分级器
    participant W as Workflow
    participant P as 插件层
    participant T as TTS

    U->>A: 打开车窗，空调调低至20度
    A->>F: 规范化文本
    F->>W: 输出 sequence workflow
    W->>P: step1 open_window
    P-->>W: success
    W->>P: step2 set_ac(20)
    P-->>W: success
    W->>T: 车窗已打开，空调已调到20度
    T-->>U: 车窗已打开，空调已调到20度
```

### 9.3 场景三：慢执行查询

用户输入：

- `帮我查一下订单A123456`

处理流程：

1. 本地高频分支命中订单查询
2. 首反馈先给：
   - `收到，我帮你查一下`
3. 调用订单查询插件
4. 最终反馈：
   - `订单A123456当前待发货`

### 9.4 场景四：条件型请求

用户输入：

- `查一下订单A123456，如果还没发货就取消`

处理流程：

1. 本地识别该请求复杂，进入云端 planner
2. planner 输出 conditional workflow：
   - step1: query_order
   - step2: cancel_order
   - condition: order_status == pending_shipment
3. 先执行 step1
4. 若满足条件，则进入确认
5. 用户回复确认后，再执行取消
6. 最终反馈：
   - `订单A123456已取消`

时序演示：

```mermaid
sequenceDiagram
    participant U as 用户
    participant R as 本地融合器
    participant C as 云端 Planner
    participant W as Workflow
    participant P as 插件层
    participant T as TTS

    U->>R: 查一下订单A123456，如果还没发货就取消
    R->>C: 复杂条件请求
    C-->>W: conditional workflow
    W->>P: step1 query_order
    P-->>W: order_status=pending_shipment
    W->>T: 即将取消订单，仅在订单未发货时取消。请回复确认或取消
    T-->>U: 确认提示
    U->>W: 确认
    W->>P: step2 cancel_order
    P-->>W: success
    W->>T: 订单A123456已取消
    T-->>U: 订单A123456已取消
```

### 9.5 场景五：多轮短句恢复

对话过程：

1. 用户：`把空调调到22度`
2. 系统：`空调已调到22度`
3. 用户：`再低一点`
4. 系统读取 `last_intent=cabin_set_ac` 和 `last_temperature=22`
5. rewrite engine 改写为：`把空调调到21度`
6. 再进入意图识别和执行
7. 系统反馈：`空调已调到21度`

### 9.6 场景六：边界外请求

用户输入：

- `打开飞机门`

正确处理：

1. 本地分支都无法稳定支持
2. 若低于执行阈值，不得直接执行已有意图
3. 进入：
   - reject
   - 或云端澄清
4. 反馈：
   - `这个我暂时做不了，但我可以帮你导航、查订单、调空调或播放音乐`

这类场景必须通过 `unknown / out_of_scope` 机制处理，不能靠封闭集分类硬选。

---

## 10. 当前项目与目标方案的对应关系

### 10.1 已经具备的能力

- 本地 `keyword / classifier / retrieval / fusion`
- 本地 BERT 分类器
- `session state`
- `context rewrite`
- `planner`
- `sequence / conditional workflow`
- 高风险确认
- demo 调试面板

### 10.2 还需要补齐的关键能力

- `unknown / out_of_scope`
- 低分拒识策略
- 明确的 `execute / reject / route_to_cloud` 决策建议
- 更多真实车机意图
- 真实插件接入
- 语音前端与 ASR/TTS 完整接入

---

## 11. 当前阶段的正式实施结论

当前方向可以继续，但必须明确：

- 本地 BERT 是本地快分支之一，不是整个系统的唯一裁决者
- 最终执行依据应来自“本地融合分级器 + planner + 风险规则”
- 用户体验的关键不只是识别正确，还包括：
  - 首反馈是否快
  - 多轮是否顺
  - 边界是否清楚
  - 风险是否可控

因此，当前正式方案应定义为：

```text
车机型 Agent = 本地并发快链路
              + 上下文改写缓存
              + 分级融合决策
              + 云端 planner
              + workflow 执行
              + 风险确认
              + reject / clarify / fallback 策略
```

---

## 12. 下一步执行优先级

建议按以下顺序继续实现：

1. 补 `unknown / out_of_scope` 和拒识阈值
2. 输出统一执行建议：
   - `execute`
   - `clarify`
   - `reject`
   - `route_to_cloud`
3. 扩真实车机场景意图：
   - 车窗
   - 车门
   - 座椅
   - 灯光
   - 后视镜
   - 除雾
4. 强化 rewrite/cache 高频模式
5. 接真实插件与真实语音链路

