这个品类的数据长什么样
本页面向同行评议组织的异常追溯与人工复核场景，材料来自审稿邀请、专家审稿意见、作者修改说明三类记录。审稿邀请承载邀请时间、专家身份与回执状态，专家审稿意见承载评审结论、意见正文与提交日期，作者修改说明承载逐条回应、修改位置与确认签字。材料随稿件流转分批进入，更新节奏与审稿轮次同步，每轮产生新版本。三类材料在异常追溯中互为参照：邀请记录定位专家与时间，审稿意见核对结论与日期，修改说明核对回应与签字。字段特征集中在名称、数量、日期与签字四类，版本号与回执状态是判断同步与否的关键。
配置怎么定
这一环由工作流里的 HTTP 节点执行，输出响应体、状态码与返回字段。「异常清单与复核结论」由后续节点解析响应，或外部系统按约定处理接着完成。请求地址、路径参数、请求头与请求体均可通过 variables 引用全局变量、系统变量或前方节点输出，鉴权信息按外部系统要求放入 Authorization。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 审稿邀请 | 邀请记录的名称、日期与回执状态需与专家审稿意见的提交时间一致 | 调取邀请记录与审稿意见，核对专家名称、邀请日期、回执字段，确认签字或回执是否齐全 |
| 专家审稿意见 | 意见正文的结论、日期与签字需与作者修改说明的回应条目对应 | 比对意见条目与修改说明的逐条回应，核对数量、日期与签字，检查版本号是否同步 |
| 作者修改说明 | 修改说明的回应条目需有原始审稿意见支撑且带确认签字 | 抽取一条修改说明，回溯至对应审稿意见与邀请记录，核对名称、数量、日期三处字段 |
| HTTP 响应 | 响应体与状态码需能定位到源头材料，返回字段含 responseData | 在请求预览中核对渲染后的地址与请求头，用一条样例请求比对返回字段与源头记录 |
容易做错的三处
- 现象：同一专家在两份材料里的名称写法不同，日期相差数天。原因：录入时未统一字段口径，版本未同步导致旧记录残留。
- 现象：修改说明的回应条目数多于审稿意见条目数，数量对不上。原因：新增意见未回填至修改说明，或合并条目时未更新计数。
- 现象：复核结论缺少复核人签字或回执，无法交负责人处置。原因：签字环节被跳过，回执未按约定回传至外部系统。
怎么确认配好了
本功能验收：预览渲染后的请求，核状态码与返回字段，再对一条样例比对结果，确认 variables 与 Authorization 取值来源可追。
业务测试：造一条异常记录，看能否追到源头材料，核对名称、数量、日期与签字是否一致。
- 在变量面板核对每个占位的来源，确认路径参数、请求头与请求体中的
variables能解析成实际值。 - 抽取一条异常记录，比对审稿邀请、专家审稿意见与作者修改说明的名称、数量、日期与签字，记录不一致处并交负责人处置。