# 事故采集业务规则基线

## 规则来源

本基线交叉比对以下来源：

1. V1.0.9 交互接口文档；
2. `workflow/20260726/事故信息采集20260726.json`；
3. `prompts/20260723/单车拍照.txt`；
4. `prompts/20260723/双车拍照.txt`；
5. 当前 `src/api/endpoints.py`；
6. 2025 版本 workflow/Prompt，仅用于识别历史兼容行为。

发生冲突时采用接口文档和 2026-07-26 规则；历史状态别名只在 API 边界兼容。

## 全局规则

1. 每个自然语言回复必须以且仅以一个 `<state>四位数字</state>` 开头。
2. 用户明确要求“转人工”“找人工”“人工客服”等时，立即进入 `0001`。
3. 明确或高度可信的人伤、三辆及以上机动车、涉及行人/非机动车等复杂情况进入 `0003`。
4. 明确否定人伤时不得因句中出现“受伤”“流血”等词误触发 `0003`。
5. ASR 内容破碎或人伤语义矛盾时，用当前采集状态封闭确认，不能直接冒险放行。
6. 当前问题没有有效答案时不得跳题。第一次澄清，第二次强制选择；仍失败进入 `0002`。
7. 连续第一次无回复使用固定唤醒话术；连续第二次进入 `0004`。
8. 用户有效回复后无回复计数清零。
9. 状态候选必须经过枚举和迁移矩阵校验才能持久化。

## 准备与事故信息采集

1. 新 session 初始为 `1001`，提示撤离到安全区域、开启双闪、放置警告牌。
2. `【开始】` 或 `【继续办理】` 后进入 `1002`。
3. 采集顺序：
   - 事故经过；
   - 是否有人伤；
   - 是否涉及非机动车/摩托车/自行车；
   - 事故时间并校验不能晚于当前时间；
   - 是否仍在现场；
   - 机动车数量。
4. 用户提前提供的字段用于填槽，但进入下一项前应做封闭式确认。
5. 一辆机动车、无人伤且不涉及非机动车/行人：进入 `2000`。
6. 两辆机动车、无人伤且不涉及非机动车/行人：进入 `2010`。
7. 三辆及以上，或涉及非机动车/行人，或有人伤：进入 `0003`。

## 单车拍照

严格顺序：

```text
2000 车前/车牌
 -> 2001 车辆碰撞部位
 -> 2002 被撞物品
 -> 2003 本人正面
 -> 2004 确认或纠正车牌
 -> 2005 确认车损位置
 -> 3001 单车信息确认
```

- `2000`–`2003` 只有 `PhotoCompletedEvent` 可以正常推进；其他普通输入重复当前固定指令。
- `2004` 肯定车牌或提供完整新车牌后进入 `2005`；仅否定但不提供号码时停留并追问。
- `2005` 获得有效车损位置后进入 `3001`；连续两次无效回答进入 `0002`。
- 任意单车照片状态收到拍照失败事件立即进入 `0005`。

## 双车拍照

严格顺序：

```text
2010 第一辆车侧前方/车牌
 -> 2011 第一辆车碰撞部位
 -> 2012 第二辆车碰撞部位
 -> 2013 第二辆车侧后方/车牌
 -> 2014 另一方驾驶人正面
 -> 2015 本人正面
 -> 2016 确认或纠正车牌
 -> 3002 双车信息确认
```

- `2010`–`2015` 只有 `PhotoCompletedEvent` 可以正常推进。
- `2016` 肯定或提供完整新车牌后进入 `3002`；无关或不完整回答停留，连续两次失败进入 `0002`。
- 任意双车照片状态收到拍照失败事件立即进入 `0005`。

## 当事人信息确认

### 单车 `3001`

依次确认：

1. 是否为对应车辆车主/驾驶人；
2. 姓名；
3. 身份证后四位；不一致时采集完整号码并二次确认；
4. 手机号后四位；不一致时采集完整号码并二次确认；
5. 完成后进入 `0000`。

### 双车 `3002`

先完成第一位驾驶人上述信息，再要求将电话交给第二位驾驶人，重复相同步骤。第二位完成后进入 `0000`。

身份证和手机号允许分段输入；中间态只保存已接收片段，不应把未完成号码写入已确认业务字段。日志、trace 和黄金数据不得包含真实号码。

## 表单更新

- `needFormUpdate=false` 时无需返回 `formUpdate`。
- `needFormUpdate=true` 时只返回本轮相对当前表单发生变化的字段。
- LLM 提取结果必须经过 `field-registry.json` 白名单和类型校验。
- patch 之外的原字段保持不变。
- 不允许 LLM 更新 phase、状态码、计数器或版本号。

## 当前实现与目标规则的差异

- FastGPT Prompt 承担了多数计数和迁移逻辑，服务端未校验迁移合法性。
- 当前 prefix 正则不是开头锚定且接受任意位数字。
- 当前 `/set_info` 可写任意 key。
- 当前 `/get_info` 和 `/set_info` 通过辅助 LLM 对话访问状态。
- 当前日志会记录完整用户输入、回复和表单。

这些差异是 Phase 1–8 的明确改造项，不能被解释为本基线认可的目标行为。