这个品类的数据长什么样
本页面向学校安全隐患排查与校园事件上报场景，材料来自安全检查表、隐患整改台账、突发事件报告。安全检查表按周或按次填报，字段含检查点位、隐患描述、检查人、日期；隐患整改台账按整改流程更新，字段含隐患名称、数量、整改期限、责任人、销号签字；突发事件报告按事件发生即时上报，字段含事件名称、涉及人数、发生日期、上报人、回执。三类材料进入异常追溯与人工复核功能时角色不同：安全检查表提供原始发现记录，隐患整改台账提供处置过程与销号依据，突发事件报告提供事件定性与上报回执。多轮对话与提示词配置让模型在连续追问中承接前文指代，输出异常清单与复核结论，供负责人处置。
配置怎么定
这一环由应用设置里的记忆轮数与提示词配置执行，输出参考的历史消息范围与回答约束。异常清单与复核结论由模型接着完成。记忆轮数控制回答时最多参考前面多少轮对话，取值与问题需要的前文范围匹配即可。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 安全检查表 | 隐患名称、数量、日期与隐患整改台账逐项对得上，检查人签字齐全 | 取一条隐患记录，在安全检查表与隐患整改台账中分别定位名称、数量、日期与签字 |
| 隐患整改台账 | 整改期限、责任人、销号签字与突发事件报告回执一致，版本为最新 | 对照台账版本号与突发事件报告回执，核对销号签字与回执是否齐备 |
| 突发事件报告 | 事件名称、涉及人数、发生日期与安全检查表、隐患整改台账不冲突 | 以事件日期为轴，回溯安全检查表与隐患整改台账中的对应条目并记录差异 |
| 多轮对话与提示词 | 第二轮追问能承接第一轮的指代，参考的历史消息范围与回答约束匹配 | 用两轮连续问句试跑，核对 chatId 下的 messages 与 variables 是否被正确带入 |
容易做错的三处
- 现象：同一隐患在安全检查表与隐患整改台账里名称、数量对不上。原因：两份材料填报口径不同，未做交叉核对。
- 现象：台账版本未同步，旧版销号签字被当作最新依据。原因：更新节奏不一致，缺少版本标记与回执比对。
- 现象：突发事件报告缺上报回执或复核人签字。原因：上报流程未闭环，复核环节未留痕。
怎么确认配好了
本功能验收：两轮连续追问，第一问给出隐患名称，第二问用指代追问整改情况，看第二问是否承接第一问的指代，并核对 chatId、messages、variables 的带入范围。
业务测试：造一条异常记录，看能否追到源头材料，并确认异常有原始记录支撑、复核人签字。
- 在应用设置里核对记忆轮数当前取值，与问题需要的前文范围匹配，对比两次运行的用量记录。
- 用两轮连续问句试跑，检查开场消息是否被当成前文，第二问指代是否答非所问。