4.7 KiB
4.7 KiB
事故采集业务规则基线
规则来源
本基线交叉比对以下来源：
- V1.0.9 交互接口文档；
workflow/20260726/事故信息采集20260726.json；prompts/20260723/单车拍照.txt；prompts/20260723/双车拍照.txt；- 当前
src/api/endpoints.py； - 2025 版本 workflow/Prompt，仅用于识别历史兼容行为。
发生冲突时采用接口文档和 2026-07-26 规则；历史状态别名只在 API 边界兼容。
全局规则
- 每个自然语言回复必须以且仅以一个
<state>四位数字</state>开头。 - 用户明确要求“转人工”“找人工”“人工客服”等时，立即进入
0001。 - 明确或高度可信的人伤、三辆及以上机动车、涉及行人/非机动车等复杂情况进入
0003。 - 明确否定人伤时不得因句中出现“受伤”“流血”等词误触发
0003。 - ASR 内容破碎或人伤语义矛盾时，用当前采集状态封闭确认，不能直接冒险放行。
- 当前问题没有有效答案时不得跳题。第一次澄清，第二次强制选择；仍失败进入
0002。 - 连续第一次无回复使用固定唤醒话术；连续第二次进入
0004。 - 用户有效回复后无回复计数清零。
- 状态候选必须经过枚举和迁移矩阵校验才能持久化。
准备与事故信息采集
- 新 session 初始为
1001，提示撤离到安全区域、开启双闪、放置警告牌。 【开始】或【继续办理】后进入1002。- 采集顺序：
- 事故经过；
- 是否有人伤；
- 是否涉及非机动车/摩托车/自行车；
- 事故时间并校验不能晚于当前时间；
- 是否仍在现场；
- 机动车数量。
- 用户提前提供的字段用于填槽，但进入下一项前应做封闭式确认。
- 一辆机动车、无人伤且不涉及非机动车/行人：进入
2000。 - 两辆机动车、无人伤且不涉及非机动车/行人：进入
2010。 - 三辆及以上，或涉及非机动车/行人，或有人伤：进入
0003。
单车拍照
严格顺序：
2000 车前/车牌
-> 2001 车辆碰撞部位
-> 2002 被撞物品
-> 2003 本人正面
-> 2004 确认或纠正车牌
-> 2005 确认车损位置
-> 3001 单车信息确认
2000–2003只有PhotoCompletedEvent可以正常推进；其他普通输入重复当前固定指令。2004肯定车牌或提供完整新车牌后进入2005；仅否定但不提供号码时停留并追问。2005获得有效车损位置后进入3001；连续两次无效回答进入0002。- 任意单车照片状态收到拍照失败事件立即进入
0005。
双车拍照
严格顺序：
2010 第一辆车侧前方/车牌
-> 2011 第一辆车碰撞部位
-> 2012 第二辆车碰撞部位
-> 2013 第二辆车侧后方/车牌
-> 2014 另一方驾驶人正面
-> 2015 本人正面
-> 2016 确认或纠正车牌
-> 3002 双车信息确认
2010–2015只有PhotoCompletedEvent可以正常推进。2016肯定或提供完整新车牌后进入3002；无关或不完整回答停留，连续两次失败进入0002。- 任意双车照片状态收到拍照失败事件立即进入
0005。
当事人信息确认
单车 3001
依次确认：
- 是否为对应车辆车主/驾驶人；
- 姓名；
- 身份证后四位；不一致时采集完整号码并二次确认；
- 手机号后四位；不一致时采集完整号码并二次确认；
- 完成后进入
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 的明确改造项，不能被解释为本基线认可的目标行为。