117 lines
4.7 KiB
Markdown
117 lines
4.7 KiB
Markdown
# 事故采集业务规则基线
|
||
|
||
## 规则来源
|
||
|
||
本基线交叉比对以下来源：
|
||
|
||
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 的明确改造项，不能被解释为本基线认可的目标行为。
|