这个品类的数据长什么样
本页面向自费出国留学申请服务的受理材料。来源包括留学服务合同、学校申请表、个人陈述，以及受理环节形成的受理记录与补齐的问项。更新节奏随申请批次与补件回执推进，合同签署、申请表提交、陈述定稿各自产生日期与签字节点。材料进入该功能时角色不同：留学服务合同提供委托关系、服务范围与签署日期，用于核对申请主体与授权；学校申请表提供院校、专业、入学季与提交状态，用于识别缺项；个人陈述提供文本版本与签字确认，用于判断材料是否齐备。字段特征集中在名称、数量、日期与签字：同一记录在合同与申请表里的名称可能不同，数量与日期可能对不上，版本未同步或缺签字、缺回执时，受理记录无法直接转承办人。
配置怎么定
这一环由应用设置里的记忆轮数与提示词配置执行，输出参考的历史消息范围与回答约束。「受理记录与补齐的问项」由模型接着完成。记忆轮数控制回答时最多参考前面多少轮对话，数值过小用不上前文，数值过大带入无关内容并增加消耗。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 留学服务合同 | 名称、日期与签字须与受理记录一致，服务范围可核对 | 在应用设置里核对当前记忆轮数取值，用两轮连续问句试跑，检查合同字段是否被正确引用 |
| 学校申请表 | 院校、专业、入学季与提交状态须与合同记录对应，缺项应被识别 | 对比两次运行的用量记录，查看申请表字段在 messages 与 variables 中的承接情况 |
| 个人陈述 | 版本须同步，签字或回执缺失时应触发补问 | 用两轮连续问句试跑，确认第二问能承接第一问的指代，并核对陈述版本与签字状态 |
| 受理记录与补齐的问项 | 缺项被识别并追问，回答有材料依据，可转承办人处理 | 在应用设置里核对当前记忆轮数取值，检查 chatId 对应的历史消息范围与回答约束 |
容易做错的三处
- 现象：同一记录在合同与申请表里的名称、数量、日期对不上。原因：受理时未按字段逐项核对，两份材料各自录入后未做交叉比对。
- 现象：个人陈述版本未同步，受理记录引用旧稿。原因：更新节奏与申请批次脱节，新版本未回写受理记录，旧版本仍留在历史消息范围。
- 现象：缺签字或回执时仍继续作答。原因：提示词配置未把签字与回执列为必查项，模型缺少追问依据，直接给出补齐结论。
怎么确认配好了
本功能验收：两轮连续追问，看第二问是否承接第一问的指代；核 messages 与 variables 中的历史消息范围，确认回答约束生效。
业务测试：提一个缺关键信息的问句，看是否先追问再作答。
- 在应用设置里核对当前记忆轮数取值，与问题需要的前文范围匹配，并对比两次运行的用量记录。
- 用两轮连续问句试跑，检查第二轮能否正确承接第一轮的指代，并确认开场消息未被当成前文。