这个品类的数据长什么样
本页面向职业院校技能竞赛组织场景，材料按竞赛规程、报名表、训练计划三类归集。竞赛规程来自主办方发布的正式文件，更新节奏随赛项年度调整；报名表由参赛院校提交，字段含选手姓名、身份证号、组别、指导教师与签章；训练计划由承办校或指导团队编制，字段含阶段日期、训练内容与负责人签字。三类材料进入问答受理与缺项补问功能时，规程充当判定依据，报名表与训练计划充当待核对的记录源。问答受理先读材料，再识别缺项并生成追问，最后把补齐的问项与受理记录一并转承办人处理。字段特征集中在名称、数量、日期与签字四处，同一记录在规程与报名表之间、报名表与训练计划之间常出现名称、数量、日期对不上，或版本未同步、缺签字与回执。
配置怎么定
这一环由工作流里的 HTTP 节点执行，输出响应体、状态码与返回字段。受理记录与补齐的问项由后续节点解析响应，或外部系统按约定处理接着完成。HTTP 节点只负责发请求与取回结果，不代替外部系统写库或审批。
| 对象 | 判断 | 核验动作 |
|---|---|---|
| 竞赛规程 | 名称、日期与签字字段是否与报名表逐项对应 | 取规程中的赛项名称、组别、日期字段，与报名表同名记录比对，看是否一致 |
| 报名表 | 数量、日期与签字回执是否与训练计划对得上 | 核对选手数量、训练起止日期与负责人签字，检查缺签字或回执的条目 |
| 训练计划 | 版本是否同步、字段是否与规程口径一致 | 比对计划版本号与规程发布日期，确认同一记录的名称、数量、日期无冲突 |
| HTTP 节点请求 | 路径参数、请求体与请求头中的占位是否解析成实际值 | 在请求预览里看渲染后的完整地址，核对 Authorization 与 variables 来源，再比对 responseData 返回字段 |
容易做错的三处
- 现象：同一选手姓名在报名表与训练计划里写法不同，数量也对不上。原因：两份材料各自录入，未按规程口径统一字段。
- 现象：规程已更新，报名表仍用旧版赛项名称与日期。原因：版本未同步，材料间缺少发布与回执的比对环节。
- 现象：报名表缺指导教师签字，训练计划缺承办回执。原因：签字与回执未纳入字段核对，缺项未被识别并追问。
怎么确认配好了
本功能验收：预览渲染后的请求，核状态码与返回字段，再对一条样例比对结果；同时核对 Authorization、variables、responseData 三处取值来源与返回字段是否一致。
业务测试：提一个缺关键信息的问句，看是否先追问再作答。
- 在变量面板核对每个占位的来源，确认路径参数、请求体与请求头中的变量都能追到全局变量、系统变量或前方节点输出。
- 用一条样例请求比对返回，检查外部系统是否收到空字段，并核对请求头名称与取值来源是否符合外部接口约定。