这个品类的数据长什么样
本页面向学校安全隐患排查与校园事件上报场景，材料包括安全检查表、隐患整改台账、突发事件报告三类。安全检查表按周或月更新，记录检查项目、隐患位置、初判风险与检查人签字；隐患整改台账按次更新，登记隐患名称、数量、整改日期、责任人与验收签字；突发事件报告按事件发生即时形成，包含事件经过、涉及人员、处置措施与上报回执。三类材料进入该功能时，安全检查表提供排查依据与检查频次，隐患整改台账提供闭环证据与责任人链条，突发事件报告提供上报口径与回执凭证。字段核对关注名称、数量、日期与签字四类，更新节奏不同导致同一记录在两份材料里可能对不上。
配置怎么定
这一环由应用设置（回复上限等）执行，输出单次回答长度与可容纳的上下文范围。「可回指原文的依据条目」由模型接着完成。回复上限用滑块控制单次回答的长度，设置过低回答会被截断，设置过高会增加消耗。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 安全检查表 | 检查项目、隐患位置、初判风险与检查人签字能否与台账逐项对上 | 对照同一隐患的名称与日期，核对检查人签字是否齐全，确认引用条数按数组长度记录 |
| 隐患整改台账 | 隐患名称、数量、整改日期与验收签字是否与报告口径一致 | 抽取一条隐患，比对台账与报告中的名称、数量、日期，检查验收签字与回执是否缺失 |
| 突发事件报告 | 事件经过、涉及人员、处置措施与上报回执是否版本现行 | 核对报告版本是否为现行，确认回执完整，检查引用文本的 tokens 与 quoteMaxToken 预算 |
| 回复上限 | 单次回答长度与页面要求的回答长度匹配 | 在应用设置里核对开关与滑块位置，提一个需要长回答的问题看结尾是否完整，对比两次运行的用量 |
容易做错的三处
- 现象：同一隐患在两份材料里的名称、数量、日期对不上。原因：检查表与台账更新节奏不同，录入口径未统一。
- 现象：报告版本未同步，引用旧版内容。原因：材料更新后未替换现行版本，引用仍指向历史条目。
- 现象：缺签字或回执，依据条目无法回指原文。原因：检查人签字、验收签字或上报回执未归档，条目缺少可核对象。
怎么确认配好了
本功能验收：提一个需要长回答的问题，看结尾是否完整；核对 maxResponse 与 maxContext 设置，确认回答未被截断。
业务测试：问一个跨材料的依据问题，看回答是否给出可回指的出处，并核对引用条数与 quoteMaxToken 预算分别记录。
- 在应用设置里核对回复上限开关与滑块位置，提一个需要长回答的问题看结尾是否完整。
- 抽取一条隐患，比对安全检查表、隐患整改台账与突发事件报告中的名称、数量、日期与签字，确认版本现行且可回指原文。