这个品类的数据长什么样
普通高校招生录取投档的异常追溯与人工复核，核心材料是招生计划、投档规则与录取名册。招生计划来自省级招生管理部门下达的批次与专业目录，投档规则来自当年录取工作文件，录取名册由高校招生办在每轮投档后生成。更新节奏按批次推进，每轮投档结束即形成一版名册，补录与征集志愿会再出新版。字段特征集中在院校代号、专业代号、计划数、投档数、录取数、投档日期与审核签字栏。材料进入该功能时，招生计划与投档规则作为比对基准，录取名册作为被追溯对象，异常清单与复核结论由人工复核环节产出并交负责人处置。
配置怎么定
这一环由工作流里的 HTTP 节点执行，输出响应体、状态码与返回字段。异常清单与复核结论由后续节点解析响应，或外部系统按约定处理接着完成。HTTP 节点不代替外部系统写库或审批。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 招生计划 | 院校代号、专业代号、计划数与批次日期须与录取名册逐项对应，签字栏不得为空 | 取计划文件与名册同批次记录，按代号与日期比对，核对签字与回执 |
| 投档规则 | 投档比例、志愿顺序与同分处理规则须与名册实际投档结果一致，版本日期须为当年 | 调取规则文件与名册，逐条核对投档数、日期与版本号 |
| 录取名册 | 同一记录在名册与计划中的名称、数量、日期须一致，缺签字或回执须标记 | 按院校代号与专业代号抽取记录，比对名称、数量、日期与签字栏 |
| HTTP 节点 | 请求地址与路径参数中的占位变量能解析成实际值，请求头按外部系统要求传入，请求体字段与接口约定一致 | 在请求预览里看渲染后的完整地址，核对请求头名称与取值来源，用一条样例请求比对返回 |
容易做错的三处
- 现象：同一考生记录在录取名册与招生计划里的专业名称、计划数、投档日期对不上。原因：两份材料由不同环节填报，未按院校代号与专业代号做逐项比对。
- 现象：投档规则文件与录取名册使用的版本不一致，名册仍按上一批次规则生成。原因：版本未同步，规则更新后未重新下发至名册生成环节。
- 现象：名册记录缺审核签字或回执，异常清单无法追到源头材料。原因：签字与回执未随材料一并归档，复核人无法确认原始记录支撑。
怎么确认配好了
本功能验收：预览渲染后的请求，核状态码与返回字段，再对一条样例比对结果；在变量面板核对 variables、Authorization、responseData 三个占位的来源与取值。
业务测试：造一条异常记录，看能否追到源头材料，核对异常清单与复核结论是否有原始记录支撑、复核人签字，再交负责人处置。
- 在请求预览里核对渲染后的完整地址、请求头名称与取值来源，确认
Authorization与variables均能解析成实际值。 - 用一条样例请求比对返回字段，核对
responseData中异常记录的院校代号、专业代号、计划数、投档日期与签字栏，确认与招生计划、投档规则、录取名册一致。