xiaotutongxue/docs/数据信息填报系统PRD-功能逻辑卷.md

深学在线 · 功能逻辑 PRD

产品代号：深学在线 版本：V2.0（2026-10 需求收敛：4 角色 / 不设二期 / 门禁失败只留「重新填写」） 日期：2026-09-24 文档定位：只描述"系统怎么运转"，不含数据库设计、接口定义、代码结构 配套文档：《数据信息填报系统PRD》（主 PRD，含库表与接口）—— 主 PRD 回答"做什么"，本文回答"怎么运转" 读者：产品经理、研发、测试、UI 设计

变更记录

版本	日期	变更内容
V2.0	2026-10	需求收敛：① 角色由 6 个减为 4 个（平台运营 / 学校管理员 / 班主任 / 学生；删「副班主任」「审核员」）；② §2.2 社会收集、§3.12 历史数据整理器、专项职业能力相关段落 整节作废；③ §3.1 门禁失败只留「重新填写」——原「申请加入名单」（FR-509）通道整体撤销，名单外的人由老师手工加人，系统内不展示任何联系方式；④ 不再有任何二期功能设计（OCR 与材料识别改为「缓做，等供应商」）。跨文档数字：接口 119 / 错误码 54 / 权限码 28 / 原型 29 屏。
V1.0	2026-09-24	初稿：角色/流转/12 个功能逻辑/规则速查/20 个边界场景/文案规范
V1.1	2026-09-24	压缩逻辑按实测重写：用 28 张真实 A4 扫描件实测，300dpi/q85 下 28/28 达标（平均 806KB），无需牺牲清晰度。① §3.7.1 新增实测结论；② §3.7.3 由"逐级降质逼近"改为"一次编码到位 + 兜底路径"；③ §3.7.4 抽检机制标注为"实测不触发"；④ §4 速查表、§7 未决事项同步更新
V1.2	2026-09-24	修正材料来源通道：取消"直接拍照"（实测 4 类材料无一来自现场拍照，均为截图/扫描件/照相馆电子版）。① §3.5 改为"微信聊天记录 / 手机相册 / 聊天文件"三通道，拍照默认关闭；② 新增"必须保留原始文件名"设计逻辑（聊天记录可拿到原始名，相册拿不到）；③ 新增来源引导文案与 4 个相关异常分支；④ §4 速查表、§5 场景表（+4 条）、§6 文案、§7 未决事项同步更新
V1.3	2026-09-24	新增"名单门禁"（D6）：① §2.1/§2.2 流程图改为"扫码 → 姓名+身份证核验 → 填报"，社会收集也必须先导名单（废除"自由填报"）；② §2.4 由三条铁律扩为四条，新增"没有名单就没有填报"；③ §3.1 整节重写为门禁逻辑（判定优先级、命中后绑定、统一失败提示、限流防枚举、名单不下发）；④ §3.3 名单逻辑补充"姓名/身份证列为必填、缺列阻断发布"；⑤ §4 速查、§5 场景（14/15 改写，+4 条）、§6 文案（+5 组门禁文案）、§7 未决事项（+4 项）同步更新
V1.4	2026-09-24	新增材料识别设计（方案 B：规则为主 + VLM 兜底）：① §3.5 升级为「材料上传与材料识别」，新增 3.5-B 材料识别整节（四路信号、文件名/形态/关键词/印章四类规则、置信度分级、VLM 三种触发条件、冲突裁决表、成本预估、三条不可违背原则、六个集成点）；② §4 速查新增"材料识别"块；③ §5 场景 +4 条（29–32）；④ §6 文案 +3 组；⑤ §7 未决事项 +3 项
V1.5	2026-09-24	材料识别规则实测校正（用 112 个真实文件 + 32 个 OCR 抽样验证）： ① 证伪初版形态规则——初版写"身份证宽高比 ≈1.585"，实测为 0.732–1.016，与一寸照片 0.714 高度重叠，形态层根本无法区分；② 架构改为四层递进：文件名 → 形态（只分流派，不定型）→ OCR 强词计分 → VLM；③ 证伪"命中即判定"——实测关键词大量交叉命中（工作证明含"学籍/学校"、学籍表含"居民身份证"），改为只用强词 + 加权计分取最高；④ 新增一寸照片"零文字"判据（实测 8/8 无文字）；⑤ VLM 触发率由 15% 重估为 2%~10%（初版偏高的原因是形态规则写错产生假冲突）；⑥ 新增 §3.5-B 开头的实测验证结果表 + OCR 耗时表 + 局限性说明；⑦ §4 速查、§7 未决事项同步更新
V1.6	2026-09-28	按官方《考生线下报名信息导入模板》校准表单填写逻辑：① §3.4 重写——新增**「评价计划」三级级联**（职业→工种→等级受计划约束，从源头防错，源自官方规则 04/05/06）；② 新增补考科目数量约束（三/四/五级最多 1 科、一/二级最多 2 科、专项职业能力无补考）；③ 新增专项职业能力整体降级（无工种/无等级/无补考）；④ 明确 "无"是合法业务值而非空值（工作单位、报考工种）；⑤ 补格式校验（入学时间 YYYY-MM-DD、工作年限阿拉伯数字、下拉严格受限）；⑥ §4 速查新增"表单填写"块；⑦ 异常分支 +3 条
V1.7	2026-09-28	新增「评价计划导入」完整逻辑（确认下发文件模式 = A）：① §3.2 拆为 3.2-A 评价计划导入 + 3.2-B 任务创建向导；② 定义导入七步流程（上传 → 自动解析 → 人工确认列映射 → 导入体检 → 差异对比 → 确认写入 → 留痕）；③ 明确列映射必须人工确认但可保存复用、原始文件必须留档、差异对比中移除项须关联已有考生告警；④ 7 条异常分支（扫描版PDF、合并单元格、增量 vs 全量、机构临时增补…）；⑤ §4 速查新增"评价计划"块；⑥ §7 未决事项 +3 项（需索取真实计划清单样本）
V1.8	2026-09-28	实测校正：不存在"计划清单"文件，报考范围来自名单： ① §3.2-A 由"评价计划导入（七步流程）"整体重写为「报考范围聚合」——名单导入后自动聚合"职业×工种×等级"集合 + 一致性体检 + 管理员确认； ② 新增追加名单告警机制（超出已确认范围的报考项需管理员确认——范围失控的主要入口）； ③ §3.4 新增 ⚠️ 最关键的第 1 条「字段三类规则」：🔒锁定（姓名/身份证号/报考三项，空则阻断发布）／✏️预填可改（其余，标注"老师已填请核对"）／📄材料（学生唯一重活）——依据是实测名单 21 项已填 18 项，学生端几乎不用打字； ④ §3.4 步骤重新编号为 13 步，异常分支措辞校正（"计划已过期"→"报考范围已关闭"）； ⑤ §4 速查新增"报考范围""字段三类规则"两块，删除"评价计划"块； ⑥ §7 关闭 21/22/23，新增 24（预填字段能否由学生修改）
V1.9	2026-09-28	同步数据库决策（PG / Vastbase）与字段落库方式：① §3.4「字段三类规则」补存储说明——18 个业务字段在名单表与填报单表中为正式列（非 JSON），"按工种统计""按学历筛选"可直接走索引，仅机构额外追加字段进 extras_json；② 本文档其余部分不受影响（功能逻辑卷不承载库表设计，DDL 见主 PRD §7.3）

---

目录

• 0. 文档说明与关键决策
• 1. 角色与端
• 2. 全局业务流转
• 3. 功能逻辑详述
  • 3.1 身份识别与任务匹配
  • 3.2 报考范围聚合与任务创建
    • 3.2-A 报考范围聚合
    • 3.2-B 任务创建向导
  • 3.3 名册逻辑
  • 3.4 表单填写逻辑
  • 3.5 材料上传与材料识别逻辑
    • 3.5-A 上传流程
    • 3.5-B 材料识别（这是什么材料）
  • 3.6 命名规范化逻辑
  • 3.7 压缩逻辑（扫描件强制 1M）
  • 3.8 校验逻辑
  • 3.9 审核逻辑
  • 3.10 汇总导出逻辑
  • 3.11 通知与催报逻辑
  • 3.12 历史数据整理器逻辑
• 4. 一页纸规则速查
• 5. 异常与边界场景
• 6. 用户可见文案规范
• 7. 未决事项

---

0. 文档说明与关键决策

0.1 本文包含 / 不包含

包含	不包含
角色能做什么、不能做什么	数据库表结构
每个功能的触发条件与处理步骤	接口定义与字段
判断规则、优先级、兜底策略	代码结构、类设计、框架选型
状态流转与谁能改变状态	部署、性能参数
用户看到什么、看到哪句话	测试用例（另见主 PRD §12）

0.2 已决策事项（本文据此撰写）

编号	决策	影响章节
D1	扫描件（工作证明/申报表等 A4 材料）强制压缩到 1M，不做体积放宽、不设例外。 当"≤1M"与"清晰度"冲突时，体积优先，牺牲清晰度；被牺牲的文件必须标记出来供人工抽检	§3.7
D2	学籍表等屏幕截图类材料保持原始像素与 PNG 格式，不缩放、不转 JPG	§3.7
D3	校验位（身份证）用于裁决证件号争议，而非仅做格式校验	§3.6、§3.8
D4	一寸照片统一规格化为 295×413 px（25×35mm @300dpi）	§3.7
D5	材料来源只提供"选择已有文件"：微信聊天记录 / 手机相册 / 手机文件；不提供"直接拍照"（默认关闭，材料级可配）。理由：实测 4 类材料无一来自现场拍照	§3.5
D6	填报必须先过名单门禁：学校收集与社会收集都必须先导入名单，填报人进入前必须填写「姓名 + 身份证号」与名单匹配，匹配不到只提示、不放行（取消原"自助认领"与"自由填报"）	§3.1、§3.3

---

1. 角色与端

角色	主用端	可以做什么	不可以做什么
平台运营	PC	开通/停用租户、查看全局用量、内容风控	查看任何考生的材料内容
学校管理员	PC（主）+ 手机（次）	建任务、配规则、导名册、终审、导出上报	修改已归档任务的配置
班主任	PC + 手机	催报、初审、批量通过、代传材料	终审、导出、查看其他班级
副班主任 / 审核员	—	已删除（2026-10 需求收敛）：内置角色由 6 个减为 4 个（平台运营 / 学校管理员 / 班主任 / 学生）	—
填报人（学生）	微信小程序	填报、上传、修改、撤回（未审核前）	查看他人材料、修改已终审内容
社会填报人	—	不做（2026-10 取消社会收集）	—

端能力差异（功能逻辑层面）

能力	小程序	PC
填报	✅ 主入口	❌
材料来源选择	✅ 从微信聊天记录选（可拿原始文件名）/ 从相册选 / 从手机文件选；不提供拍照	✅ 仅本地上传（拖拽或文件选择）
初审 / 批量通过	✅	✅
表单设计与规则配置	❌（屏幕太小且易误操作）	✅ 唯一入口
名册导入	❌	✅
汇总导出	❌	✅
查看大图 / 对比原图与压缩图	✅ 支持	✅ 支持

---

2. 全局业务流转

2.1 学校收集（主流程）

【前置】学校管理员建任务
   ↓ 导入名单（Excel）+ 选定班级 + 配置表单与材料规则
   ↓ 发布任务 → 生成填报二维码
填报人扫码 → 微信授权
   ↓ 【门禁】填写「姓名 + 身份证号」→ 与名单匹配
   ↓ 匹配成功 → 绑定名单项 → 回填只读信息 → 进入填报
   ↓ 匹配失败 → 统一提示页（只有「重新填写」+ 提示联系老师），不给填报
填报人逐项填写表单 → 逐项上传材料
   ↓ 每次上传后立即：命名规范化 → 压缩 → 校验 → （必要时）OCR
   ↓ 填报人看到"文件名已规范 / 体积已压缩 / 有无问题"的即时反馈
填报人提交
   ↓ 系统做提交前总校验（有无缺失、有无红色阻断项）
   ↓ 通过则进入【待初审】
班主任初审（手机或 PC）
   ↓ 一键批量通过全部绿色项
   ↓ 红黄项逐个处理：通过 或 驳回（选原因）
   ↓ 驳回 → 填报人收到通知 → 修改 → 重新提交（回到【待初审】）
管理员终审
   ↓ 全部通过后进入【已通过】
管理员导出
   ↓ 系统按目录规范打包（含分卷、汇总 Excel）
   ↓ 下载上报至认定机构

🔒 门禁不变式：没有名单，就不能填报。 名单是唯一的准入依据，不存在"自由填报"。

2.2 社会收集（差异流程）—— 不做（2026-10 取消）

⚠️ 本节作废：社会收集（collectMode=2）不再设计，传入直接返回 40044。 原设计的差异点（跳过班主任初审、直达管理员终审）记录在此仅供追溯。 名单导入与身份核验两项与学校收集完全一致，这条不变。

2.3 状态机

填报单状态

状态	含义	谁能改变	可回到哪些状态
草稿	已开始填但未提交	填报人	→ 待初审/待终审（提交）
待初审	已提交，等班主任	班主任、系统（跳过初审时）	→ 待终审（通过）／→ 已驳回（驳回）
待终审	初审通过，等管理员	管理员	→ 已通过（通过）／→ 已驳回（驳回）
已驳回	被打回，等填报人修改	填报人	→ 待初审/待终审（重新提交）
已通过	终审通过	管理员（解锁）	→ 已归档
已归档	任务结束后锁定	—	不可逆

🔒 业务不变量：终审通过后默认不可修改。如需更正，必须管理员主动"解锁"，且解锁动作计入审计。

任务状态

状态	含义	转入条件	转出条件
草稿	配置中，填报人不可见	新建	管理员点"发布"
收集中	可填报	发布	到期自动截止 / 手动截止
暂停	临时停止接收	管理员操作	管理员恢复
已截止	不再接收新提交（已提交的仍可审核）	到期或手动	归档
已归档	只读	管理员操作	不可逆

材料项状态

状态	含义
未上传	该材料尚未提交
已上传待处理	文件已到，正在规范化/压缩/校验
已受理	处理完成，无阻断问题
有警告	处理完成，存在黄项（可提交但需注意）
有阻断	处理完成，存在红项（不可提交）
已驳回	审核认为本项不合格，需重传
已通过	审核确认合格

2.4 四条铁律

1. 没有名单，就没有填报——两种收集模式都必须先导入名单，填报人必须通过「姓名 + 身份证号」核验才能进入填报页，核验不通过只提示、不放行。
2. 一个人在一个任务下只有一份填报单——不允许同一人重复建单，只允许在原有单上修改。
3. 没有规范文件名、没有压到 1M 内的文件，不得进入汇总包——导出时若发现不合格文件，导出直接报错并列出清单，不允许"带着问题打包"。
4. 终审通过是"进入上报范围"的唯一门槛——初审通过不算，材料上传完成也不算。

---

3. 功能逻辑详述

每个功能按「触发 → 处理 → 输出 → 异常」四段描述。

3.1 身份识别与名单匹配（进入填报的门禁）

⚠️ 本版强化：学生填报与外部（社会）填报都必须先导入名单，填报人必须先通过「姓名 + 身份证号」匹配名单，匹配成功才进入填报页。匹配不到就不给填，只做提示。

触发：填报人扫码或点击链接进入任务。

处理步骤

扫码进入
  ↓ ① 微信授权（静默取 openid）
  ↓ ② 解析任务：二维码带的任务标识 → 无效则提示"链接无效"
  ↓ ③ 检查任务状态：未开始 / 已暂停 / 已截止 / 已归档 → 分别提示，不进入
  ↓ ④ 【门禁页】填写两项：
        · 姓名
        · 身份证号（数字键盘、自动分段、末位 X 自动大写、支持粘贴）
        本地先做格式 + 校验位校验 → 不合格当场提示，不发请求
  ↓ ⑤ 提交匹配（在服务端完成）
  ↓ ⑥ 命中 → 绑定 → 进入填报页
       未命中 → 失败提示页（只有「重新填写」+ 提示联系老师）

匹配判定顺序

优先级	判定条件	结果
1	身份证号 + 姓名 完全一致	✅ 直接命中
2	身份证号命中，但姓名不一致	尝试形近字 / 同音字纠错（复用 §3.6 能力）→ 命中则请用户确认"你是不是 XXX？"
3	身份证号命中，姓名纠错后仍不一致	🔴 失败（不提示姓名错误，统一提示）
4	身份证号未命中	🔴 失败
5	命中多条（同一人在两个班）	列出可选班级，由本人选择

命中后的处理

1. 该名单项锁定绑定到当前用户（openid），防止他人冒用；
2. 若该名单项已被其他人绑定 → 提示"该信息已被登记，如有疑问请联系老师"；
3. 姓名、身份证号回填并置为只读（避免用户改动后又对不上名单）；
4. 班级、专业、学号等名单中已有的信息一并回填；
5. 进入填报页。

匹配失败提示（统一文案）

"没有找到你的信息。 请核对姓名和身份证号是否与老师提供的名单一致。 如确认已报名，请联系老师把你加入名单。"

只提供一个系统内动作：重新填写；另加一句纯文案提示"请联系老师把你加入名单" （原「申请加入名单」自助通道已于 2026-10 撤销）——系统内不展示任何联系方式

🔒 安全要求（重要，必须实现）

要求	说明
限流	同一 openid 每小时最多 10 次匹配；同一 IP 每分钟最多 20 次；超出则锁定并提示"操作过于频繁，请稍后再试"
失败原因不区分	无论"身份证号不在名单"还是"姓名不匹配"，提示文案完全一致。否则可被用来探测某个身份证号是否在名单中
名单不下发	名单只在服务端参与匹配，绝不下发到前端
不记录明文匹配日志	失败尝试只记 openid、时间、结果，不记明文姓名与身份证号
传输加密	姓名与身份证号走加密传输

异常分支

情况	处理
姓名对、身份证号错（或反之）	统一失败提示，不透露是哪一项错
身份证号对、姓名有错别字（如"扬晨"↔"杨晨"）	形近字纠错命中 → "你是不是 杨晨？" → 用户确认后通过
一人在两个班的名单中	两条都列出，让本人选择班级；结果通知管理员核对
该名单项已被他人绑定	提示"该信息已被登记，如有疑问请联系老师"
任务已截止但确需补交	提示已截止；管理员可延长截止或点名放行
同一微信帮多人填（哥哥帮弟弟）	允许，但切换填报人需重新走核验，且记录操作留痕
名单外的人确实要报名	本版按需求实现为"不给填、只提示"，需老师去后台把人加进名单（见下方待决策事项）

✅ 已决策（2026-10，需求收敛）：名单外的人由老师在任务里手工加人，不做自助通道。 曾经的"学生自助申请 + 管理员逐条审批"（FR-509）已整体撤销（模块、表、接口、页面、错误码一并删除）。 门禁失败页只保留「重新填写」+ 一句"请联系老师把你加入名单"，系统内不展示联系方式。 这样守住的仍是同一条铁律：没有名单，就不能填报 —— 加人的动作留在老师手里。

3.2 报考范围聚合与任务创建

3.2-A 报考范围聚合（⚠️ 按实际情况校正）

纠正：上一版假设"认定机构会下发一份计划清单文件"，该假设不成立。 经真实名单实测确认：「报考职业 / 报考工种 / 报考等级」这三列，在导入名单时就已经由老师填好了（28/28，均为「车工 / 数控车工 / 四级中级工」）。 ⇒ 报考范围从名单聚合而来，不需要任何外部文件。

触发：名单导入完成后自动执行。

处理步骤

名单导入
   ↓
① 【聚合】扫描全部名单行的「报考职业 / 报考工种 / 报考等级」
   ↓ 生成"职业 × 工种 × 等级"的取值集合
   ↓
② 【一致性体检】输出报告：
   · 是否有人的三项为空（红色必填，不该为空）
   · 同一职业下是否出现互相矛盾的工种
   · 等级是否与该工种的常规设置相符
   · 是否与参考字典拼写不符（如"数控车床工" vs "数控车工"）
   · 本次共涉及几组"职业/工种/等级"
   ↓
③ 【管理员确认 / 修正】
   ↓ 写入 collect_task.plan_scope_json
   ↓
④ 学生端只读展示 + 导出时原样写回 Excel 的 G/H/I 列

追加名单时的约束（关键防线）

情况	处理
追加的人报考项在已确认范围内	✅ 直接接受
追加的人报考项超出范围	⚠️ 告警："新增了范围外的报考项：车工 / 普通车工 / 三级"，需管理员确认后才接受，并同步更新范围

💡 中途补录最容易绕过审核，是报考范围失控的主要入口，必须设这道闸。

异常分支

情况	处理
名单里有人三项为空	🔴 阻断发布："名单中有 N 人未填写报考职业/工种/等级"
整批出现多组不同的报考项	正常（一个任务可覆盖多个工种），但需管理员确认无误
老师发现填错想改	管理员可直接修改名单行（留痕），范围自动重新聚合
名单里出现参考字典没有的职业/工种	仅提示"可能拼写有误"，不阻断（最终以机构要求为准）
认定类型 = 专项职业能力	不做（2026-10 取消；传 certType=3 返回 40044）

关键设计

#	设计点	理由
1	范围是"聚合结果"，不是"约束来源"	老师已经确定好了，系统只做体检与展示，不越权更正
2	一致性体检比范围校验更有价值	单看一行都合法，但"38 人报数控车工、2 人报车工"很可能是填错——这类问题只有聚合后才能发现
3	追加名单必须告警	见上表
4	参考字典只提示、不阻断	机构可能有非常规的职业名称，系统不该比机构更权威

输出：collect_task.plan_scope_json（本期报考范围）+ 一致性体检报告。

3.2-B 任务创建向导

触发：管理员在工作台点"新建收集任务"。

七步逻辑

步骤	输入	校验	输出
① 基本信息	任务名、收集模式（学校/社会）、批次号、专业、工种、等级、起止时间	必填；结束时间必须晚于开始时间；批次号在租户内唯一	任务骨架
② 覆盖班级	勾选本次收集涉及哪些班级	学校模式至少选 1 个班；社会模式可选报名点	应填人范围
③ 名单	上传 Excel 或手动添加（两种模式均必填）	必须含「姓名」「身份证号」列；人数 > 0	准入名单
④ 表单	选模板或自定义字段	至少 1 个字段；必填字段不得全部为空	填报字段集
⑤ 材料	材料清单、命名模板、体积上限、压缩档位	至少 1 项材料；命名模板必须含"姓名""证件号""材料名"	材料规则集
⑥ 审核流	是否启用班主任层、驳回次数上限、超时小时数	学校模式默认启用；社会模式默认关闭	审核规则
⑦ 预览发布	—	试跑至少 1 条样本文件名，确认命名结果正确	二维码 / 链接

关键逻辑点

• 第 ⑦ 步必须有"命名规则试跑"：管理员粘贴几条学生可能的原始文件名，系统立即演示会被改成什么，确认无误才能发布。这是防止"规则配错导致全员改名错误"的唯一闸门。
• 每一步都可保存为草稿，中途退出不丢失。
• 已发布的任务修改配置时：表单与材料规则的新改动只对新提交生效，已提交的数据不受影响（避免数据错乱）。
• 任务支持"克隆"：复制配置与名册，不复制任何已上传的文件。

3.3 名单逻辑

🔒 铁律：两种收集模式（学校 / 社会）都必须先导入名单，名单是唯一的准入依据。 初稿曾允许"社会收集可不导名单、自由填报"，本版已废除。

触发：管理员在上传名单步骤选择 Excel 文件。

处理步骤

1. 定位表头：不假设第 1 行是表头。系统从前 10 行中自动寻找包含"姓名""身份证"等关键词的行作为表头（真实模板第 1–5 行是说明文字，第 6 行才是表头）。
2. 字段映射：自动匹配标准字段（姓名、身份证号、手机号、学号、班级、专业等），无法自动识别的列由管理员手动指定或忽略。「姓名」与「身份证号」为必填列（缺任一列则无法用于门禁核验，必须补齐后才能发布任务）。
3. 逐行体检（导入前），生成《导入体检报告》：
   • 身份证号格式与校验位是否通过
   • 姓名是否为空、是否有重复
   • 同一证件号是否重复出现
   • 手机号格式
4. 按体检结果决定：有致命问题（如证件号重复、校验位失败）→ 提示管理员确认后仍可导入，但问题行被标记。
5. 建立名单：证件号通过哈希去重存储，界面展示时脱敏（如 3601**********1234）。
6. 发布前校验：任务发布前必须确认名单人数 > 0 且姓名/身份证号列完整，否则不允许发布。

输出：名单列表 + 体检报告（可下载）。

异常分支

情况	处理
找不到表头行	提示"未识别到表头，请检查 Excel"，并允许手动指定行号
缺少「姓名」或「身份证号」列	🔴 阻断发布："名单必须包含姓名和身份证号才能开启填报核验"
模板被学生自行修改过（多列、少列、换表头）	以字段映射向导兜底，不强行报错
名单里有人实际不报名	管理员可"移出应填名单"，状态记为已移除，不计入完成率
名单导入后发现漏人	支持追加导入，按证件号去重合并；追加后新人即可立即填报
名单项始终无人认领	不影响任务完成率统计口径（完成率 = 已提交 / 名单有效人数）

名册变更留痕：任何姓名/证件号的修改都必须记录"谁在何时把 X 改成 Y"，并在审核界面可见。

3.4 表单填写逻辑

触发：填报人通过名单门禁后进入填报页。

表单来源：任务所属评价计划 + 任务表单配置。默认套用官方《考生线下报名信息导入模板》的 21 字段（详见主 PRD §5.4.1）。

处理步骤

1. 字段三类规则（⚠️ 最关键：决定了学生端要填多少字）

   实测老师交上来的名单里，21 个字段已填满 18 个。因此学生端的字段按三类呈现：

   类别	字段	学生端行为
   🔒 锁定	姓名、身份证号、报考职业、报考工种、报考等级	只读不可改。名单为空 → 阻断任务发布（这三项必须由老师确定）。学生要改只能找老师
   ✏️ 预填可改	学历、是否在校生、在读学校、所学专业、入学时间、工作单位、联系电话、是否补考、补考科目、本职业工作年限、已获证书相关	名单有值 → 预填并标注"老师已填，请核对"，学生可直接修改（留痕）；名单为空 → 学生必填
   📄 材料	一寸照片、身份证、学籍表、工作证明等	学生上传（学生唯一的重活）

   💡 实测数据说明为什么"锁定"是必要的：整班 28 人的报考三项完全一致（车工/数控车工/四级中级工）——这是老师根据机构要求统一定的。让学生去选只会制造错误。 💡 实测数据也说明为什么其余字段该允许改：联系电话有 28 个不同值、入学时间可能记错——允许学生自己改正比回退给老师更高效。

   📦 存储说明：这 18 个业务字段（除姓名/身份证号外）在名单表和填报单表里都是正式列（不是 JSON），因此"按工种统计报名人数""按学历筛选"这类查询可直接走索引。只有机构额外追加的字段才进 extras_json。详见主 PRD §7.3。

2. 报考范围的一致性体检（在学生填报之前完成） 系统从名单聚合出本期范围时，会做一次体检：

   • 同一职业下出现互相矛盾的工种 → 提示老师确认
   • 等级与该工种常规设置不符 → 提示
   • 与参考字典拼写不符（"数控车床工" vs "数控车工"）→ 提示
   • 有人三项为空 → 🔴 阻断发布

   单看一行都合法，但"38 人报数控车工、2 人报车工"很可能是填错——这类问题只有聚合后才能发现。

3. 选择范围先收窄（⚠️ 源自官方规则 04/05/06） 「报考职业 / 报考工种 / 报考等级」三项不是自由选择，而是限定在本期报考范围内：

   本期范围 → 只列出范围内的职业
      ↓ 选中职业
      只列出该职业范围内的工种（该职业无工种 → 只能填"无"）
      ↓ 选中工种
      只列出该工种范围内的等级
   

   ⇒ 从源头杜绝填错，而不是提交后报错。

   注：实测官方 Excel 模板里「报考职业」「报考工种」根本没有下拉（21 列中 13 列自由填写）——这正是本系统相对模板的核心增量。

4. 条件显示（级联）：官方模板用绿色标题标识级联列，共两组：

   触发字段	值	级联行为
   是否补考	是	按等级放开补考科目（见第 5 条）
   是否补考	否	补考理论 / 实操 / 综合 全部隐藏且不校验
   是否在校生	是	在读学校 / 所学专业 / 入学时间 三项显示且必填
   是否在校生	否	上述三项隐藏且不校验

   隐藏的字段不参与必填校验，也不出现在导出结果中。

5. 补考科目数量约束（官方规则 07，最容易做错）

   认定类型 / 等级	最多可选科目数	可选项
   专项职业能力	0	不做（2026-10 取消）
   三 / 四 / 五级	1	补考理论、补考实操 中选一个
   一 / 二级	2	补考理论、补考实操、补考综合 中最多选两个

   ⇒ 达到上限后，其余科目选项置灰不可选（而不是事后报错）。

6. 专项职业能力的整体降级：不做（2026-10 取消二期；certType=3 直接 40044）。原设计是：该类型下工种、等级、补考三项全部隐藏，官方规则 05/06/07 整体跳过。

7. 下拉严格受限：官方规定"若手动输入则只能填写下拉选项中包含的值"。 ⇒ 移动端一律用选择器；PC 端允许输入但做严格值匹配，不在选项内的值直接拒绝。

8. "无"是合法值，不是空值（⚠️ 实现陷阱）

   • 工作单位没有 → 填"无"
   • 报考工种该职业没有 → 填"无"
   • ⇒ 必填校验时 "无"算已填；做单位统计、去重时不能把"无"当成真实单位名。

9. 格式校验

   • 联系电话：11 位数字
   • 入学时间：必须 YYYY-MM-DD
   • 本职业工作年限：只能阿拉伯数字（0、1、2…）

10. 实时校验：每个字段失焦即校验，立即反馈，不等到提交时集中报错。

11. 草稿自动保存：每 10 秒或字段变更后保存；断网时暂存本地，恢复网络后补传。

12. 跨任务记忆：同一人第二次填报自动带出上次信息（仅本租户内）。

13. 提交前总校验：汇总所有问题，分三类呈现

    • 🔴 阻断项：必须处理才能提交
    • 🟡 警告项：可勾选"我已确认"后继续
    • 🟢 通过项

输出：提交成功 → 进入待初审/待终审；或显示阻断清单。

异常分支

情况	处理
填报中途退出	草稿保留，重新进入时提示"继续上次填写"
提交时网络中断	提示"提交未成功，已保存草稿"，不做"假成功"
同一账号在两台设备同时填	以最后保存的版本为准，并提示"你的内容在另一台设备上被修改过"
提交后又想改	未进入审核前可"撤回"；已进入审核需联系老师驳回
报考范围已关闭（认定机构批次结束）	提示"本批次已结束"，不允许新建填报单；已提交的不受影响
学生发现自己的报考职业/工种/等级不对	提示"该三项由老师统一确定，请联系老师修改"，不允许自行输入
选了"专项职业能力"却想填工种/等级	不做（2026-10 取消该认定类型）

3.5 材料上传与材料识别逻辑

3.5-A 上传流程

⚠️ 重要修正（V1.2）：不提供"直接拍照"入口。 复核 4 类材料的真实来源后发现，没有一类是"现场拍照"产生的：

材料	真实来源	实测证据
学籍表	教务系统屏幕截图	28 张均为约 1025×590 的 16:9 截图
工作证明	扫描仪扫描件（多在打印店完成）	28 张均为 1208–1352 dpi 的 A4 扫描图
一寸照片	照相馆拍摄后的电子版	27/28 张尺寸完全一致（984×1378）
身份证	既有扫描件或翻拍件	尺寸跨度 558×745 ~ 2216×2796，来源不一

现场拍照只会引入模糊、畸变、反光、阴影问题，反而制造返工。填报入口必须是"选择已有文件"。

触发：填报人在某个材料项上点击"选择材料"。

四种来源通道（按实际使用频率排序）

#	通道	适用材料	说明
1	从微信聊天记录选择	全部（主力通道）	学生从照相馆、打印店、老师、家人处收到的文件，通常就躺在聊天记录里
2	从手机相册选择	学籍表截图、已有的翻拍件	手机截图会自动存入相册
3	从聊天记录 / 手机文件选择	扫描件 PDF、Word 版申报表	需要选中"文件"类型而非"图片"类型
4	直接拍照	默认关闭	材料级可配置开启（例如某批次允许现场补拍身份证），但默认不提供

两条关键设计逻辑

① 必须保留原始文件名（极其重要）

• 从聊天记录选择文件时，微信会返回该文件的原始名称（例如 张三-360121200010101234-工作证明.jpg）；
• 从相册选择图片时，拿不到文件名（通常是 IMG_0001.jpg）。

⇒ 系统必须优先使用前者。文件名本身就是最有价值的信息——命名规范化引擎（§3.6）能直接从文件名中读出姓名、证件号、材料类型，准确率远高于从无名截图里靠 OCR 猜。

⇒ 产品层要提示用户："优先从聊天记录里选，因为文件名里带着你的信息，系统能自动帮你填。"

② 支持一次多选 身份证正反面、多页材料允许一次选多张，减少重复操作。

③ 来源引导（每个材料项都要给）

材料	引导文案
一寸照片	"照相馆给过你电子版吗？在微信聊天记录里搜一下"
工作证明	"打印店扫描后会发给你，从聊天记录里选"
学籍表	"教务系统截图后，从手机相册里选"
身份证	"拍过的照片或者扫描件都可以，从聊天记录或相册里选"

处理步骤（一次上传的完整生命周期）

点击"选择材料"
  ↓ 弹出来源选择：微信聊天记录 / 手机相册 / 手机文件
  ↓ 选中文件（可多选）
  ↓ 【客户端】只做三件事：
  ↓          ① 记录原始文件名（若来源支持）
  ↓          ② 方向校正
  ↓          ③ 尺寸限幅（长边 ≤2400px）
  ↓          不做有损质量压缩（原因见 §3.7.6 二次有损防护）
  ↓ 上传到存储（显示进度；支持断点续传）
  ↓ 【服务端】形态识别 → 选定压缩档位
  ↓ 命名规范化（§3.6）
  ↓ 压缩到目标体积（§3.7）
  ↓ 格式转换（如需）
  ↓ 校验（§3.8）
  ↓ 必要时 OCR 识别并回填
  ↓ 返回处理结果
填报人看到结果卡片：
   ┌─────────────────────────────────────────┐
   │ 原名：曾伊豪-361029200907295110身份证.jpg.jpg │
   │ 已规范为：曾伊豪-...-身份证.jpg               │
   │ 体积：17.1MB → 512KB ✅                      │
   │ 校验：通过 ✅                                 │
   └─────────────────────────────────────────┘

输出：材料项状态变为"已受理/有警告/有阻断"，并附上处理前后对比。

异常分支

情况	处理
上传中断	断点续传；已传部分不重复上传
格式不在白名单	提示支持的格式，并说明"建议用 JPG"
从聊天记录选文件时超出微信单文件体积限制	提示改为"从相册选那张图片"，并说明聊天中收到的图片可选择非原图版本（体积更小）。各通道的实际体积上限需在开发期实测确认
聊天记录里找不到该文件（过期/被清理）	提示替代方案：请对方重新发送 / 从手机文件里找 / 联系老师代传
从相册选的图片没有文件名（IMG_0001.jpg）	无法从文件名提取信息 → 走 OCR 识别回填，并在界面提示"这张图没有名字信息，请确认归属"
文件来自"文件传输助手"	正常处理，文件名可保留
选中的是压缩过度的聊天图片（微信默认会压缩图片）	检测分辨率是否偏低，若低于建议值则提示"这张图可能被压缩过，建议让对方发原图"
文件过大（>50MB）	提示"文件过大，请让对方重新发送一份清晰的扫描件"
处理超时	转后台异步处理，页面显示"处理中"，完成后推送通知
处理失败	保留原图，标记失败原因，允许一键重试；不丢弃用户已上传的内容
上传了错误的材料（如把身份证传到照片项）	依靠 OCR 内容比对提示"这张看起来不是身份证"，并允许一键移动到正确材料项
重复上传同一材料	保留历史版本，默认取最新；旧版本可回溯

3.5-B 材料识别（这是什么材料）

决策（方案 B）：规则为主 + 视觉大模型兜底。 先用零成本规则判断，只在"规则判不准"或"与用户声明冲突"时才调用视觉大模型。

📊 实测验证结果（2026-09-24，用 112 个真实文件 + 32 个 OCR 抽样）

层	方法	实测结果	成本
第 1 层 文件名	别名表匹配	112/112 = 100%	0
第 2 层 形态	粗分流派	111/112 = 99.1% 能正确分流派，但流派内无法定型	0
第 3 层 内容 OCR	强词计分 + 零文字判据	32/32 = 100%（4 类材料各 8 个）	OCR（本来就要做）
第 4 层 VLM	兜底	触发率 2%~10%（重估）	按次

OCR 耗时实测（CPU，图片降采样至 2000px）

材料	耗时	文字量
一寸照片	0.1–0.3s	0 字
身份证	0.9–1.6s	107–138 字
学籍表	1.0–1.4s	265–269 字
工作证明	3.5–4.9s	702–755 字

本次验证发现并修正的两处设计错误

#	初版设计（错）	实测真相	修正后
1	身份证宽高比 ≈ 1.585，可按形态直接判定	实际 0.732–1.016，与一寸照片 0.714 高度重叠	形态层降级为"只分流派"
2	OCR 关键词"命中任一即判定"	关键词大量交叉命中（工作证明里含"学籍/学校"，学籍表里含"居民身份证"）	改为只用强词 + 加权计分取最高

⚠️ 本次验证的局限性（必须在开发期补测）

1. 文件名 100% 是"有偏测试"——这 112 个文件是老师已经规范命名过的；真实收集中学生传来的文件名更乱，准确率必然更低；
2. OCR 抽样仅 32/112，未覆盖全部文件；
3. 未覆盖的困难场景：模糊件、翻拍反光、非标准材料（学信网备案表、其它佐证材料在本数据集中不存在）；
4. 上述结果不能直接当作线上准确率承诺，只用于验证架构方向。

要解决什么问题

#	场景	问题
1	填报上传	用户在"身份证"槽位传了学籍表 → 需要发现并提示
2	整理器散图分拣	已取消（2026-10，整理器模块删除）
3	审核辅助	班主任想快速确认"这堆材料里有没有传错的"
4	缺失检测兜底	例如"其它佐证材料"传了 3 张，需要区分它们分属什么

四路信号

信号	内容	可靠性	成本
S1 槽位	用户在哪个材料项上传的（用户声明）	高，但用户可能传错	0
S2 文件名	原始文件名里的材料名（如 ...-工作证明.jpg）	最可靠（前提是聊天记录来源）	0
S3 形态	宽高比、像素量、DPI、是否有大面积红色（印章）	中（拍歪、裁图后会失效）	极低（只读头部）
S4 内容	OCR 文字关键词、版面特征	高	OCR 已在做，无额外成本

🔑 一个必须记住的前提：不是所有材料都有文字。 一寸照片完全没有文字，只能靠形态（5:7 比例、纯色背景、人脸居中）判断。因此不能因为"没识别出关键词"就判定材料错了。

规则层判定（必跑，零成本）

① 文件名规则（最强信号）

• 用材料别名表（§3.6）做最长匹配
• 命中 → 直接定为该材料，置信度 0.95

🔧 三层递进架构（实测校正后的最终设计）

⚠️ 本文档初版把形态层写成"直接判定材料类型"，实测证明是错的。 正确架构如下：

第 1 层  文件名       → 能定死就定死（准确率实测 100%，零成本）
          ↓ 判不出
第 2 层  形态         → 【只分流派，不材料定型】
          ↓ 流派内还有多个候选
第 3 层  内容(OCR)    → 在流派内定死（准确率实测 100%）
          ↓ 仍判不出
第 4 层  VLM          → 兜底（实测触发率仅 2%~10%）

第 1 层：文件名规则（最强信号）

• 用材料别名表（§3.6）做最长匹配
• 命中 → 直接定为该材料，置信度 0.95
• ⚠️ 前提是来源为微信聊天记录（可保留原始文件名）；相册来源拿不到文件名

第 2 层：形态规则 —— 只分流派（关键修正）

形态流派	判定特征（实测标定）	该流派内的候选材料	定型靠什么
A4 扫描件流	像素量 > 2000 万（实测 1.44~1.81 亿）	工作证明 / 申报表 / 备案表	内容层
宽屏截图流	宽高比 1.60~1.90（实测 1.689~1.758）	学籍表 / 学信网备案表截图	内容层
竖版小照片流	宽高比 0.60~1.05，像素 < 2000 万（实测 0.714~1.016）	一寸照片 / 身份证翻拍 ← 混合！	内容层
未判定	其他	—	VLM

❌ 本文档初版写的"身份证 宽高比 ≈1.585（85.6:54）"是错的。 实测：真实身份证件是竖版/近方拍摄，宽高比 0.732~1.016，与一寸照片的 0.714 高度重叠，像素量也重叠（416K6196K vs 1356K3378K）。 ⇒ 形态层根本无法区分「一寸照片」和「身份证」，必须交给内容层。这是本次验证最重要的结论。

第 3 层：内容规则（OCR 关键词加权计分）

❌ 本文档初版写的"命中任一关键词即判定"是错的。 实测发现关键词大量交叉命中：工作证明里同时出现"学籍/学校/入学/专业/姓名"，学籍表里也出现"居民身份证"，身份证里也出现"学校/姓名"。 ⇒ 必须只用高唯一性强词 + 加权计分取最高，通用词（姓名/学校/专业/出生/单位/本人）全部剔除。

材料	强特征词（权重 ×3）	实测得分
身份证	公民身份号码 / 签发机关 / 有效期限 / 居民身份证	9~12
学籍表	学籍 / 学籍号 / 学籍状态 / 学籍证明	6（另有身份证噪声 3）
工作证明·申报表	职业技能等级认定 / 个人申报表 / 申报表 / 兹证明 / 技能等级	12（另有学籍表噪声 3）
一寸照片	——（零文字，见下）	9

🔑 一寸照片的"零文字"判据 实测 8/8 张一寸照片 OCR 文字量为 0（真实证件照没有任何文字）。 ⇒ 规则：整图文字量 < 5 字 → 判定为一寸照片（结合竖版小照片流派）。 这是整个识别体系里最干净的信号，比任何关键词都可靠。

判定规则

对每个候选材料算分：分数 = 3 × (命中的强词数)
若整图文字量 < 5 字  → 一寸照片得 9 分
取最高分者为识别结果；全部为 0 分 → 交 VLM

📌 强词表必须可配置（每个租户/机构材料名与措辞不同），并提供"从历史文件自动学习候选强词"的辅助功能。 📌 学信网备案表、其它佐证材料等当前数据集未覆盖，需在新批次数据上补充标定。

④ 印章检测（辅助信号） 扫描件上大面积红色像素区域 → 提示"疑似盖章文件"。仅作辅助，不能单独定论。

判定与置信度

置信度 ≥ 0.90  → 直接采信识别结果
置信度 0.70–0.90 → 采信但标记，界面提示用户确认
置信度 < 0.70  → 不判断，以用户槽位为准（不打扰用户）

VLM 兜底触发条件（成本控制的核心）

只有以下三种情况才调用视觉大模型：

#	触发条件	理由
1	规则层置信度落在 0.4–0.7（疑似但不确定）	值得花钱确认
2	规则识别结果与槽位冲突	这是最需要判断的场景（防传错）
3	散图分拣且规则层无法判定	没有槽位可参考，只能靠内容

不触发 VLM 的情况（占绝大多数，零成本通过）

• 规则层置信度 ≥ 0.9（文件名清楚 / 关键词明确）→ 直接定
• 槽位与识别结果一致 → 无需二次确认
• 规则层置信度 < 0.4 且无冲突 → 不值得花钱，直接放行
• 一寸照片等纯形态材料 → 靠形态规则即可（比例特征极其稳定）

成本预估（已按实测重估）

方案	调用量（按 48 万文件/学期）	相对成本
全部走 VLM	48 万次	100%
本方案（规则为主 + 兜底）	约 1~4.8 万次	约 2%~10%
只用规则	0 次	0%（但模糊件判不出）

实测触发率（按"聊天记录来源占比"推算）

聊天记录来源占比	VLM 触发率	48 万文件的调用量
90%	2.0%	约 1.0 万次
80%	4.0%	约 1.9 万次
70%	6.0%	约 2.9 万次
50%	10.0%	约 4.8 万次

✅ 勘误：本文档初版预估"触发率约 15%"，实测重估为 2%~10%。 初版之所以偏高，是因为形态规则写错（把身份证误判为一寸照片）产生了大量假冲突，从而错误触发 VLM。 修正形态规则后，冲突大幅减少，成本也随之下降 60%~85%。

⚠️ 上表的"相册来源中 20% 需 VLM"为保守假设，需在开发期用真实数据实测标定。

冲突裁决表（核心规则）

用户槽位（声明）	识别结果	置信度	系统动作	用户看到
A	A	任意	✅ 通过	无感
A	B	≥ 0.9	🟡 提示 + 一键移动	"这张看起来是学籍表，不是身份证。要移过去吗？"
A	B	0.7–0.9	🟡 软提示，不强制	"这张不太像身份证，请确认一下"
A	B	< 0.7	放行	无感
A	无法识别	—	放行	无感
无槽位（散图）	A	≥ 0.9	✅ 自动归入	—
无槽位	A	0.7–0.9	建议归入，可改	"建议归到「学籍表」"
无槽位	无法识别	—	进入「待人工归属」	拖拽归位界面

🔒 三条不可违背的原则

1. 只提示，不自动改位置（散图除外） 识别必然有误判。自动改位置比传错更危险——它会把用户原本放对的文件挪走。唯一的例外是散图分拣：那里本来就没有位置，自动归入是无害的。
2. 识别结果不覆盖用户的声明 即使用户把身份证传到了"学籍表"槽位，系统也只是提示；最终位置由用户决定。
3. 识别不出 ≠ 材料错 新材料类型、无文字的图片、模糊件都可能识别失败。识别失败一律放行，不得阻断提交。

集成点

场景	时机	动作
填报上传	每次上传后（异步）	冲突时提示 + 一键移动
提交前总校验	提交时	汇总"疑似传错"清单，按 🟡 警告呈现
整理器·散图分拣	—	已取消（2026-10）
整理器·体检报告	—	已取消（2026-10）
审核辅助	班主任查看时	材料卡片上显示"系统判定：身份证 92%"
规则优化	定期	用人工纠正确认的结果反哺关键词表

异常与降级

情况	处理
OCR 服务不可用	降级为仅文件名 + 形态判定，不阻断
VLM 超时（>5s）或失败	放弃识别，以用户槽位为准，放行
图片无法解码	交压缩模块报错处理
遇到系统中不存在的新材料类型	不判断，放行
同一文件被识别为多个材料且置信度接近	归入"待确认"，提示用户选择

性能要求

• 识别为异步执行，不阻塞上传与提交；
• 规则层（含关键词匹配）单文件 ≤300ms；
• VLM 兜底 5s 超时，超时即放弃。

3.6 命名规范化逻辑

目标：无论填报人交上来什么名字，系统都输出 姓名-证件号-材料名.后缀。

处理步骤

步骤	做什么	关键判断
1	剥离扩展名	循环剥离，直到没有已知扩展名为止（解决 .jpg.jpg）
2	提取证件号	从文件名中找出最长的 15–18 位号码片段
3	证件号归一化	补齐位数、末位 x 统一为大写；位数不足或校验不通过时启动裁决（见下）
4	材料名识别	用材料别名表做最长匹配（"在职证明""工作证明扫描件"→ 统一为"工作证明"）
5	姓名识别	取剩余的中文串；与名册比对，做形近字/同音字纠错
6	组装	按模板拼接，清理非法字符，重名自动加序号
7	标记	标注本次是"全自动""已修复""待确认"还是"需人工"

证件号争议裁决表（核心规则）

文件名中的号	名册中的号	判定结论	系统动作
校验通过	校验通过	两个都是真实有效号码 → 疑似两人材料	🔴 不自动改，必须人工确认（串档）
校验不通过	校验通过	文件名写错了	✅ 自动按名册改正
校验通过	校验不通过	名册可能录错	🟡 提示管理员核对名册
位数不足 / 无法校验	校验通过	文件名残缺	✅ 按名册补齐 + 🟡 标黄供确认
名册中查无此人	—	非本任务人员	转"待认领"队列

这条规则的价值：把"证件号到底谁对"从人的判断变为算法的判断。实测 5 个人工疑点中，3 个可自动处理，只有 1 个必须人工。

姓名纠错规则

情况	判定	动作
与名册姓名不一致，但只差 1 个字且拼音相同（如"扬晨"↔"杨晨"）	高置信	自动改为名册姓名
与名册姓名不一致，差 1 个字但拼音不同	中置信	🟡 标黄，由填报人或班主任确认
与名册姓名完全不一致（如 3 个字都不同）	低置信	🔴 标红，转人工

材料名别名表（可维护）

规范名	接受的别名
一寸照片	1寸照片、一寸电子照片、证件照、照片、免冠照
身份证	身份证正反面、身份证扫描件、身份证正面、身份证反面
学籍表	学籍证明、在读证明、学籍卡
工作证明	在职证明、工作证明扫描件、个人申报表、申报表、单位证明
学信网备案表	学信网学历备案表、学历证书电子注册备案表、备案表
其它佐证材料	毕业证书、社保个人权益单、职称证明、技能等级证书、佐证

异常分支

情况	处理
文件名完全无法解析（如 IMG_20260924_0932.jpg）	保留原名 + 标红"需人工"；同时提供"手动指定归属"入口
同一人同一材料出现多个版本	版本号递增，默认取最新；旧版本保留可回溯
规范后与他人重名	追加序号（如 ...身份证(2).jpg），并提示
材料名与内容不符（如"工作证明"里其实是申报表）	以规则的规范名为准（机构要求如此），不擅自改名

3.7 压缩逻辑（扫描件强制 1M）

3.7.1 核心决策

D1：所有材料，包括 A4 扫描件，一律强制输出 ≤ 1M。不设例外、不提供体积放宽选项。

由此确定约束的优先级：

约束	性质	冲突时的取舍
输出体积 ≤ 1M	硬约束	不可协商
分辨率与清晰度（DPI / 质量）	软约束	冲突时牺牲清晰度，但必须标记
原始文件保留	保障措施	始终保留 30 天，用于复核与重出

✅ 重大实测结论（2026-09-24，用 28 张真实扫描件完整实测）

"体积 ≤1M" 与 "清晰度" 根本不冲突。 按 A4 等比缩放至标准扫描分辨率 300dpi（2480×3508）、质量 85 编码：

输出参数	平均体积	最大体积	达标情况
300dpi / q90	958 KB	964 KB	✅ 28/28（余量仅 6%，不推荐）
300dpi / q85	806 KB	831 KB	✅ 28/28 ← 默认参数
300dpi / q80	718 KB	740 KB	✅ 28/28
300dpi / q75	653 KB	673 KB	✅ 28/28
400dpi / q80	1070 KB	1078 KB	❌ 全部超标

结论：

1. 输出的是标准 300dpi 扫描件，清晰度零损失，认定机构没有正当理由拒收。
2. 整班 444MB → 22MB，压缩率 95%；单张处理约 2 秒。
3. 下文 3.7.3 的"逐级降质"路径作为兜底保留，但预计 100% 不会触发。
4. §3.7.4 的"清晰度牺牲标记 + 人工抽检"机制实测中不会产生任何待抽检文件，作为极端情况的安全网保留。

📌 参数可随实际情况调整：若某些批次扫描件内容更复杂（如满页手写、彩色底纹），系统会自动进入兜底路径，无需人工干预。

3.7.2 材料形态识别与档位

系统先识别材料属于哪种物理形态，再套用对应策略（不能对所有图片用同一把尺子）：

档位	形态	典型材料	尺寸策略	输出格式
P1 证件照	标准证件照（比例 5:7）	一寸照片	固定 295×413 px	JPG
P2 证件翻拍	手机翻拍（有透视变形）	身份证、备案表	长边控制在 1400–2400 px	JPG
P3 扫描件	A4 纸张扫描件（超高像素）	工作证明、申报表	按 A4 等比缩放，用 DPI 控制	JPG
P4 截图	屏幕截图（比例接近 16:9）	学籍表	保持原始像素，不缩放	PNG
P5 文档	PDF / Word	各类文档	页面重采样	PDF

形态自动判定依据：像素总量、宽高比、格式、压缩特征。判定置信度低时，回退到管理员为该材料指定的档位。

3.7.3 压缩执行顺序（关键逻辑）

压缩有两个可调旋钮：采样率（尺寸） 和 编码质量。二者的使用顺序按形态区分：

形态	顺序	原因
文字类（P3 扫描件 / P4 截图）	先降采样，后降质量	文字与印章是"高对比边缘"。质量降低会在笔画边缘产生锯齿状噪点（JPEG 伪影），直接破坏可读性；而等比重采样是可控的平滑，对文字更友好
照片类（P1 证件照 / P2 翻拍）	先降质量，后降采样	人脸细节对重采样敏感（一缩放就"糊脸"），对轻度质量下降反而不敏感

P3 扫描件的完整压缩路径（一次编码到位）

1. 形态确认为 A4 扫描件
2. 判断是否需要先做安全降采样（像素过大时先降到安全区，见 3.7.5）
3. 方向校正 + 色彩统一 + 剥离隐私信息（GPS、设备型号）
4. 用默认参数直接编码一次：
      A4 等比缩放至 300dpi（2480×3508），JPEG 质量 85
5. 测量输出体积：
      ≤ 1M → 直接输出，结束          ← 实测本批 28/28 走这条
      > 1M → 进入兜底路径（第 6 步）
6. 兜底路径（预计极少触发；参数按形态区分顺序）：
      300dpi/q80 → 300dpi/q75 → 300dpi/q70
      → 240dpi/q80 → 200dpi/q80 → 180dpi/q75 → 150dpi/q70
      → 120dpi/q65 → 继续降采样直至达标
7. 写回清晰度等级（见 3.7.4）

实测参考值（A4 扫描件，JPEG 编码）

输出 DPI	质量	平均体积	结论
300	90	958 KB	✅ 达标但余量小，不采用
300	85	806 KB	✅ 默认参数
300	80	718 KB	✅ 备选
300	75	653 KB	✅ 备选
400	80	1070 KB	❌ 超标，不可用
500	80	1452 KB	❌ 超标，不可用

📌 与初始推算的差异：本文曾推算"要压进 1M，A4 扫描件只能取 150–170dpi"，该推算错误。 原因是文档扫描件以白底为主、内容稀疏，压缩率远高于照片（照片的 1M 上限确实需要大幅降质，文档不需要）。

3.7.4 清晰度标记与人工抽检

这是"强制 1M"的必要配套机制——既然存在有损的可能，就必须让人知道哪些文件损了。

✅ 实测说明：在 28 张真实扫描件上，默认参数（300dpi/q85）全部直接达标，因此不产生任何 🟡 或 🔴 文件。本机制作为极端情况（满页手写、彩色底纹、内容极复杂）的安全网保留，不会给班主任增加日常负担。

系统为每个文件打一个清晰度等级：

等级	判定条件	系统动作
🟢 优	DPI ≥ 200 且质量 ≥ 75	直接通过
🟢 良	DPI 150–200	通过
🟡 可	DPI 120–150	通过 + 进入抽检清单
🔴 强制压缩	DPI < 120，或触达质量地板	通过 + 必须人工确认 + 界面醒目标记

抽检机制

1. 每个任务生成一份《压缩质量抽检清单》，列出所有 🟡 与 🔴 文件。
2. 班主任/管理员在审核界面可一键只看这些文件。
3. 抽检认为不可接受的，可驳回要求重传（并提示"请用手机拍摄而非扫描仪扫描"）。
4. 抽检结论回写到文件记录，用于后续参数优化。

3.7.5 超大图的保护逻辑

真实数据中存在 1.6 亿像素的扫描件（约 1272dpi A4）。这类图片如果不做保护，会直接拖垮服务器。

保护规则

1. 处理前先只读取图片的头部信息取得宽高，不解码像素。
2. 像素数超过 5000 万 → 先做一次流式降采样到安全区，再进入正常流程。
3. 单个文件处理超过 20 秒 → 中断并转入后台队列，页面显示"处理中"。
4. 单文件像素上限 2 亿、体积上限 50MB，超出直接拒绝并提示。
5. 内存与并发：图片处理占用的内存远大于 CPU，因此并发数按内存反推设定，不能按 CPU 核数设定。

3.7.6 二次有损防护

问题：如果客户端先压一次、服务端再压一次，图片会被"有损压缩两遍"，清晰度损失远大于一次到位。

规则

1. 客户端只做无损操作：方向校正 + 尺寸限幅，不做有损质量压缩。
2. 最终编码由服务端一次性完成，参数只在服务端确定。
3. 服务端检测到"该图已被明显有损压缩过"（如体积远小于同尺寸的合理值）时，不再压缩，只做格式与命名处理，并标记"疑似过度压缩"。

3.7.7 其他材料的压缩逻辑

材料	处理
一寸照片（P1）	先降质量（85→80→76→72），触底后按比例缩尺寸；最终统一输出 295×413 px
身份证（P2）	长边压到 2400px 以内但不得低于 1400px；低于 1400px 的原始图不压缩，标记"分辨率不足"
学籍表（P4）	保持原始像素，输出 PNG，仅做无损优化；不缩放、不转 JPG（转 JPG 会让文字边缘发虚）
图片本身已 <1M	仅做命名规范化与格式确认，不重新压缩（避免无谓降质）
图片体积过小且分辨率过低	标记"疑似过度压缩"，提示重传（体积小不等于合格）

3.7.8 失败与异常

情况	处理
压缩后仍 >1M 且已触达下限	继续降采样直至达标（强制路径），标记为强制压缩
图片损坏 / 无法解码	保留原图，提示"文件无法识别，请重新上传"
输出体积异常小（如 30KB）	标记"疑似过度压缩"，进入抽检
处理超时	转后台异步，不阻塞用户
用户重传同一材料	以新版本重新走完整流程，旧版本保留

3.8 校验逻辑

校验的三层呈现：🔴 阻断（不可提交）／🟡 警告（可提交但需确认）／🟢 通过。

编号	规则	触发时机	级别	反馈给谁	系统动作
V1	身份证号格式与校验位	输入时 / 上传后	🔴	填报人	高亮错误位置，要求核对原件
V2	证件号与名册一致	输入时 / 上传后	🔴	填报人	展示名册值，按裁决表处理
V3	姓名与名册一致	输入时	🟡	填报人	给出形近字建议
V4	同一人跨材料证件号一致	每次上传后	🔴	填报人	标出是哪两份材料冲突
V5	材料完整性（必传项）	提交时	🔴	填报人	列出缺失清单，附上传入口
V6	文件格式白名单	上传时	����	填报人	自动转换或提示重传
V7	文件体积上限	上传时	🔴	填报人	自动压缩；压不动才提示
V8	图片可读性（分辨率过低 / 全黑 / 全白 / 严重模糊）	上传时	🟡	填报人	提示重新提供（重扫描 / 索取原图）
V9	重复文件（同一文件被多次上传）	上传时	🟡	填报人	提示"与 XX 的材料重复"
V10	身份证有效期是否过期	OCR 后	🟡	填报人	提示
V11	名册内证件号重复	名册导入时	🔴	管理员	指出具体行号
V12	材料内容与类型不符（如"身份证"位传了风景照）	OCR 后	🟡	填报人	提示疑似传错，提供"移到正确材料项"入口

校验的展示原则

• 一次性列出全部问题，不做"改一个报一个"的循环；
• 每个问题必须包含三要素：哪里错、错成什么、怎么改；
• 阻断项必须给出直达修复的入口（点击跳转到对应字段/材料）。

3.9 审核逻辑

触发：填报人提交后进入待审队列。

班主任初审逻辑

1. 打开待审列表：默认按"异常优先"排序，红黄项排前面。
2. 列表呈现：每行一个学生，含头像、姓名、班级、各材料缩略图、状态色点。
3. 一键批量通过：只对"全部材料均为 🟢 且无待确认项"的学生生效；任何有红黄项的自动跳过，不允许被批量带过。
4. 逐项审核：查看大图、可对比原图与处理后的图、查看校验问题清单。
5. 处理动作：
   • 通过 → 进入待终审
   • 驳回 → 必须选择原因（提供常用原因快选），可补充文字
6. 审核超时：超过设定时长未处理，系统每小时提醒一次，并升级通知管理员。

管理员终审逻辑

1. 只能看到"初审通过"的填报单。
2. "全部通过"按钮仅在整批零红黄项时可用（防止管理员大而化之地放行）。
3. 终审通过后默认锁定，不再允许学生修改。

驳回逻辑

1. 驳回必须带原因，原因是结构化选项 + 可选文字补充。
2. 学生收到通知后修改，重新提交，回到初审（不是回到终审，除非该单此前已在终审环节被驳回）。
3. 驳回次数累计，达到上限（默认 3 次）自动提醒管理员介入。
4. 驳回记录全部留痕，审核时间轴对学生可见（让学生知道进度）。

审核行为的边界

情况	规则
班主任帮学生代传材料	允许，但记录操作人；审核界面标注"由 X 老师代传"
班主任批量通过后发现有错	支持在进入终审前撤回单个学生的通过结论
审核人变更（换班主任）	支持转交，历史审核记录保留原审核人
同一份单被两个人同时审	以后提交的动作为准，前面的人收到"该单已被 XX 处理"提示

3.10 汇总导出逻辑

触发：管理员点击"导出"。

处理步骤

1. 前置检查：扫描导出范围内所有文件，若存在"命名未规范 / 体积超 1M / 存在红项未处理"的文件，直接报错并列出清单，不允许打包。（对应 §2.4 铁律 2）
2. 范围确定：默认只导出"已通过终审"的记录；可选按班级、按人员筛选。
3. 目录结构生成（默认规范，可配置）：

{批次号}-{任务名}/
├── 24中技数控1班/
│   ├── 一寸照片/  张三-360121200010101234-一寸照片.jpg
│   ├── 身份证/    张三-360121200010101234-身份证.jpg
│   ├── 学籍表/    张三-360121200010101234-学籍表.jpg
│   └── 工作证明/  张三-360121200010101234-工作证明.jpg
├── 24中技数控2班/
└── 考生线下报名信息导入模板（汇总）.xlsx

4. 汇总 Excel：合并所有填报字段，一行一人，并附完成情况。
5. 分卷压缩：超过设定单包体积（如 50MB）时自动分卷，便于上传与传输。
6. 异步执行：导出在后台进行，页面显示进度，完成后通知。
7. 有效期：导出包默认保留 7 天，过期自动清理（避免长期堆积大文件）。

输出：可下载的压缩包（分卷）与汇总 Excel。

异常分支

情况	处理
有文件未通过终审	报错并列出名单，提供"仅导出已通过者"的选项
有文件命名不规范	报错并列出，提供"立即修复"入口（一键重新规范化）
导出过程中有人提交新数据	以导出任务创建时刻的快照为准，不动态变化
导出包过大	自动分卷；或提示"建议按班级分批导出"

3.11 通知与催报逻辑

通知渠道优先级：微信订阅消息（首选）→ 服务号模板消息 → 短信（兜底，计费）。

触发点与内容

触发点	发给谁	内容要点
任务发布	全体应填人	任务名、截止时间、填报入口
临期提醒	尚未提交者	剩余天数、未完成项
提交成功	填报人	已提交、进入审核
审核驳回	填报人	驳回原因、修改入口
审核通过	填报人	已通过
待审提醒	班主任	有多少人待审、超时人数
超时升级	管理员	哪个班主任有单超时未处理
导出完成	管理员	下载入口与有效期

催报规则

1. 自动催报：截至日前 7 天、3 天、1 天、当日各一次，只催未提交者，不打扰已完成的人。
2. 手动催报：班主任/管理员可随时对指定人员或"全部未提交者"发起。
3. 频次保护：同一人同一天最多收到 2 条催报（防止打扰引发反感）。
4. 夜间免打扰：22:00–08:00 不发送。

订阅消息额度管理（重要） 微信的一次性订阅消息需用户逐次授权，发几次就消耗几次，额度很容易耗尽。

对策：

• 填报人首次进入时一次性请求多条订阅授权，并引导其勾选"总是保持以上选择"；
• 系统记录每个人剩余的授权额度，额度不足时自动降级到服务号或短信；
• 产品层减少催报次数、提升一次填完率（减少返工即减少通知）。

3.12 历史数据整理器逻辑 —— 已取消（2026-10 需求收敛）

⚠️ 整节作废：历史整理器（含"散图分拣"与《材料体检报告》）连模块、表、接口、权限码、 PC 页面与原型屏一并删除，不再排期。

它当年复用的是同一套规则（形态识别 → 命名规范化 → 压缩 → 校验），这条"规则引擎只有一套"的 设计结论仍然成立，只是不再有"处理历史乱文件夹"这个入口。

---

4. 一页纸规则速查

材料来源

• ❌ 不提供"直接拍照"——所有材料都是已有文件（截图、扫描件、照相馆电子版）
• 三个入口：① 微信聊天记录（主力）→ ② 手机相册 → ③ 聊天/手机文件
• 优先引导用户从聊天记录选：那里能拿到原始文件名，系统可直接读出姓名+证件号+材料名
• 相册来的图没有文件名（IMG_0001.jpg）→ 只能靠 OCR，须让用户确认归属

报考范围（从名单聚合，不是外部文件）

• ❌ 不存在"认定机构下发的计划清单文件"——实测确认名单里已填好报考三项（28/28）
• 范围 = 名单中「职业 × 工种 × 等级」的聚合结果，存 collect_task.plan_scope_json
• 一致性体检比范围校验更有价值：单看一行都合法，但"38 人报数控车工、2 人报车工"只有聚合后才能发现
• 追加名单必须告警：超出已确认范围的报考项需管理员确认——这是范围失控的主要入口
• 参考字典只提示拼写、不阻断（机构可能有非常规职业名）

字段三类规则（决定学生填多少字）

• 🔒 锁定：姓名、身份证号、报考职业/工种/等级 → 只读，名单为空则阻断发布
• ✏️ 预填可改：其余字段 → 名单有值则预填标"老师已填，请核对"并可改；空则学生必填
• 📄 材料：学生上传 —— 这是学生唯一的重活
• 实测老师名单已填满 21 项中的 18 项 ⇒ 学生端几乎不用打字

表单填写（官方模板 21 字段）

• 报考职业/工种/等级必须在"本期报考范围"内 —— 从源头防错
• ⚠️ 官方 Excel 模板里「报考职业」「报考工种」根本没有下拉（21 列中 13 列自由填写）→ 这正是我们相对模板的核心增量
• 补考科目数：三/四/五级最多 1 科；一/二级最多 2 科；专项职业能力没有补考
• 是否在校生=是 → 在读学校/所学专业/入学时间三项必填，入学时间 YYYY-MM-DD
• "无"是合法业务值，不是空值（工作单位、报考工种都可能填"无"）
• 专项职业能力：无工种、无等级、无补考，三项整体跳过
• 官方要求：手动输入时只能填下拉选项里有的值

准入（门禁）

• 两种模式都必须先导名单，没有名单不能填报
• 进入填报前必须填写「姓名 + 身份证号」匹配名单，不通过只提示、不放行
• 匹配失败不区分原因（防止探测身份证号），只给「重新填写」一个出口 + 提示联系老师加人
• 匹配接口必须限流（同 openid 每小时 ≤10 次）
• 姓名形近字/同音字可纠错，但必须让用户确认后才通过

命名

• 目标：姓名-证件号-材料名.后缀
• 证件号争议：名册优先，但"两个号码都合法"时必须人工
• 姓名纠错：差 1 字且拼音相同 → 自动；否则标黄/标红
• 无法解析 → 保原名 + 标红，绝不乱猜

材料识别（这是什么材料）

• 四层递进：① 文件名（能定就定）→ ② 形态（只分流派，不定型）→ ③ OCR 强词计分（在流派内定死）→ ④ VLM 兜底
• 形态层不能区分「一寸照片」和「身份证」——二者宽高比高度重叠（0.714 vs 0.732–1.016），必须靠内容层
• 一寸照片永远是零文字 → "文字量 < 5 字"是最干净的判据
• 关键词必须只用强词 + 加权计分，通用词（姓名/学校/专业/出生）全是噪声
• 只提示、不自动改位置（散图分拣除外）——自动挪位置比传错更危险
• 识别不出 ≠ 材料错，识别失败一律放行
• 实测：文件名层 100%、形态分流 99.1%、内容层 100%；VLM 触发率仅 2%~10%

压缩（强制 1M）

• 体积 ≤1M 是硬约束，扫描件无例外
• 默认参数：A4 等比缩至 300dpi（2480×3508）+ 质量 85 ← 实测 28/28 达标，平均 806KB，清晰度零损失
• 一次编码到位；只有超限才进兜底路径（先降采样、后降质量）
• 兜底触发下限（<120dpi）→ 标记"强制压缩"，必须人工确认（实测不会触发）
• 客户端的活：只做方向校正 + 尺寸限幅；最终编码只在服务端做一次

校验

• 三层：🔴阻断 / 🟡警告 / 🟢通过
• 一次列全，每条必须含"哪里错 + 错成什么 + 怎么改"

审核

• 批量通过只带绿色项，红黄项一律不放过
• 驳回必须选原因；驳回后回到初审
• 终审通过即锁定

导出

• 有不合格文件直接拒绝打包（铁律 2）
• 只导出终审通过的；目录结构可配置；默认 7 天清理

通知

• 只催未提交者；同日同人 ≤2 条；夜间免打扰
• 订阅消息额度有限，必须管理剩余额度

---

5. 异常与边界场景

用真实数据中的 28 人 / 112 个文件作为场景库。

#	场景	输入的实际情况	系统判定	输出给用户	是否需人工
1	学生把照片传给了别人	陈子文的一寸照片用的是另一个人的证件号	两个号码校验位都通过 → 不是打字错误，是两个人	🔴"这张照片上的证件号和你其他材料不一致，请检查是否传错"	✅ 必须
2	学生证件号填错	于豪身份证文件名末 6 位倒置	文件名号码校验失败、名册通过 → 文件名错	✅ 自动按名册改正，提示"已自动纠正"	❌ 自动
3	学生姓名写了错别字	扬晨（应为杨晨），证件号正确	差 1 字 + 拼音相同 → 高置信	✅ 自动改为"杨晨"	❌ 自动
4	文件名多了一个后缀	工作证明、身份证共 56 份 .jpg.jpg	循环剥离扩展名	✅ 自动修复	❌ 自动
5	文件名少了个横杠	曾伊豪、徐程宇的身份证文件	识别到证件号前后无分隔符	✅ 自动补上	❌ 自动
6	证件号少了一位	曹文锋一寸照片仅 17 位	位数不足无法校验 → 名册兜底	🟡"已按老师名单补齐，请确认是否正确"	🟡 确认
7	学生传了扫描仪扫的 16MB A4	10517×15445、1272dpi	P3 扫描件档 → A4@300dpi/q85	✅"17.1MB → 810KB，清晰度无损"	❌ 自动
8	学生传的证件照只有 558×745	杨晨身份证 0.08MB	长边低于 1400px → 分辨率不足	🟡"这张图有点小，可能看不清。可以让对方发一张原图，或从聊天记录里选那份带文件名的"	🟡 确认
9	学籍表是系统截图	1025×590、PNG	P4 截图档 → 不缩放、保持 PNG	✅ 不处理，仅规范命名	❌ 自动
10	学生填到一半退出了	网络中断、切后台	草稿已本地暂存	重新进入提示"继续上次填写"	❌
11	学生提交后又改了主意	已提交待审	未进入审核前允许撤回	"已撤回，可继续修改"	❌
12	学生重复提交同一份材料	传了两次身份证	版本号递增	保留最新，旧版本可回溯	❌
13	学生把身份证传到了照片项	材料名与内容不符	OCR 识别出不是证件照	🟡"这张看起来不是一寸照片，是否移动到身份证？"	🟡
14	名单里没有这个人	转班生/插班生/名单漏录	门禁匹配失败	🔴"没有找到你的信息。请核对姓名和身份证号是否与老师提供的名单一致"	✅ 老师把此人加进名单
15	同一人在两个班的名单里	转班未清理旧名单	命中两条	列出两个班级让本人选择，结果通知管理员核对	🟡
16	班主任批量通过后发现错了	有人红项被漏看	批量通过只带绿项，理论上不该发生	支持在终审前撤回；审计留痕	🟡
17	任务截止了但学生要补交	学生忘交	任务已截止	提示"已截止"；管理员可延长截止或点名放行	🟡
18	班主任离职/换人	账号停用	待办无人处理	支持转交；超时自动升级通知管理员	🟡
19	导出时有人材料不全	3 人未完成	前置检查不通过	🔴 报错并列出名单，提供"仅导出已通过者"	🟡
20	老师手里已有 475MB 的乱文件夹	—	走整理器路径	已取消（2026-10：整理器模块删除）	—
21	学生从聊天记录选了照相馆发来的照片	文件带原始名 张三-...-一寸照片.jpg	文件名可读 → 直接提取姓名/证件号/材料名	✅ 一次通过；文案"已按文件名自动识别"	❌ 自动
22	学生从相册选了截图	文件名为 IMG_4821.PNG，1025×590	无文件名信息 → 走 OCR + 人工确认归属	🟡"这张图没有名字信息，已识别为学籍表，请确认"	🟡 确认
23	学生从聊天记录收到的是被微信压缩过的图	分辨率明显偏低	低于建议值	🟡"这张图可能被压缩过，建议让对方发原图"	🟡 确认
24	聊天记录里的文件已过期/被清理	选不到该文件	通道不可用	提示"请让对方重新发送，或从手机文件里找，也可请老师代传"	❌
25	学生姓名打成"扬晨"（名单是"杨晨"）	形近字	身份证号命中 + 姓名纠错命中	🟡"你是不是 杨晨？" → 确认后通过	🟡 确认
26	有人反复试别人的身份证号	尝试枚举名单	触发限流	🔒 锁定并提示"操作过于频繁，请稍后再试"；记录 openid	❌ 系统自动拦截
27	同一个名单项被两个人绑定	冒用 / 代填冲突	已被绑定	🔴"该信息已被登记，如有疑问请联系老师"	🟡
28	老师忘了导入名单就想发布任务	操作遗漏	发布前校验不通过	🔴"请先导入名单，名单必须包含姓名和身份证号"	❌ 阻断发布
29	学生把学籍表传到了"身份证"槽位	槽位与内容冲突	规则层识别出关键词"学籍"，置信度 0.93	🟡"这张看起来是学籍表，不是身份证。要移过去吗？"[一键移动]	🟡 用户确认
30	学生传了一堆散图，没归类	—	整理器无槽位 → 自动归属	已取消（2026-10）	—
31	学生传了一张纯色背景的图	一寸照片（无文字）	形态规则：5:7 比例 + 背景纯净 → 置信度 0.88	🟡"请确认这张是一寸照片"	🟡 确认
32	学生把正确材料放在正确位置，但因图糊识别失败	槽位与内容无法比对	置信度 <0.4 → 不判断	✅ 直接放行（不因识别失败而打扰用户）	❌ 系统静默放行

---

6. 用户可见文案规范

6.1 三条原则

1. 不用术语——不说"证件号校验位不通过"，说"身份证号和老师名单上的不一样"。
2. 指出位置——必须告诉用户是哪一份材料、哪一个字段有问题。
3. 给出动作——每条错误都要有"接下来做什么"，并提供直达入口。

6.2 文案对照表

场景	❌ 不要这样写	✅ 应该这样写
证件号不符	身份证号校验失败	身份证号第 16 位和老师名单上的不一样，请核对身份证原件（名单上是 3601...6619）
疑似串档	跨材料一致性校验未通过	这张"一寸照片"上的身份证号是 3601...4232，和你其他材料不一致，请确认是否传错文件
分辨率不足	图片分辨率低于阈值	这张照片有点小，放大后可能看不清，建议重新拍一张
压缩受限	压缩比未达标	这张图内容太复杂，压到最小还是超过 1M，建议用手机拍一张更清晰的
缺材料	必填项校验失败	还差 1 项：学籍表。点击去上传 →
公章不清	图像质量评分不足	照片有点模糊，公章可能看不清，建议找打印店重新扫描一份
任务已截止	任务状态异常	本次填报已在 9 月 20 日截止。如需补交，请联系你的班主任
姓名不符	姓名匹配度低	老师名单上的名字是"杨晨"，你写的是"扬晨"，是同一个字吗？
材料从哪来	—	"这份材料一般在微信聊天记录里：照相馆/打印店发给你之后，从这里选，系统能自动帮你填好信息"
相册图片无名字	无法解析文件名	"这张图没有名字信息，系统已识别为学籍表。请确认是不是这一份"
聊天图片被压缩过	图片分辨率偏低	"这张图好像被微信压缩过，有点糊。可以让对方发一张原图，或者点开图片后选『原图』再保存"
门禁：匹配失败	未找到该身份证号 / 姓名不匹配	"**没有找到你的信息。**请核对姓名和身份证号是否与老师提供的名单一致。如确认已报名，请联系老师把你加入名单"
门禁：姓名疑似写错	身份证对、姓名形近	"你是不是 杨晨？（老师名单上写的是这个名字）"
门禁：已被绑定	名单项已绑他人	"该信息已被登记，如有疑问请联系老师"
门禁：限流	尝试过于频繁	"操作过于频繁，请稍后再试"
门禁：格式错误	身份证位数/校验位不对	"身份证号看起来不太对（应该是 18 位），请再核对一下"
材料传错位置（高置信）	槽位与识别冲突，置信度 ≥0.9	"这张看起来是学籍表，不是身份证。要移过去吗？" [移动] / [不用，就放这里]
材料存疑（中置信）	置信度 0.7–0.9	"这张不太像身份证，请确认一下"
识别失败（静默）	置信度 <0.7 或无冲突	——（不提示，直接放行，避免制造噪音）

6.3 好消息也要说

处理成功的反馈同样重要——让用户看见系统替他做了什么：

• "文件名已自动规范化：...110身份证.jpg.jpg → ...110-身份证.jpg"
• "体积已压缩：17.1MB → 900KB（省了 95%）"
• "全部 4 项材料已齐全，可以去提交了"

这类反馈是让家长/学生愿意继续用下去的关键——他们能直观看到"这个系统真的帮我干活了"。

---

7. 未决事项

#	事项	影响	需谁确认
1	取得认定机构对"300dpi 扫描件"的书面认可（D1 已定强制 1M，实测 300dpi 下 28/28 达标且清晰度零损失，此项已无技术争议，仅走确认流程）	中	认定机构
2	压缩参数实测标定 已完成（2026-09-24，28 张真实扫描件实测）：默认 300dpi/q85，平均 806KB，0 张超标	—	✅ 已闭环
3	文字类降质顺序 A/B 验证 已取消：默认参数下不触发兜底路径，无需验证	—	✅ 已闭环
4	分辨率不足的判定阈值（建议长边 1400px）需认定机构确认	中	认定机构
5	截图类材料保持 PNG 是否会被拒收	中	认定机构
6	抽检机制由谁执行、抽检比例	低（实测不产生待抽检文件）	客户
7	驳回次数上限默认 3 次是否合适	低	客户
8	导出包默认保留 7 天是否够用	低	客户
9	各来源通道的实际体积上限需实测（微信聊天记录选文件、相册、文件选择三条通道各自能传多大的文件），并据此设计超限提示与降级路径	中	研发
10	微信相册/相机权限的隐私声明需在小程序后台同步更新（当前声明需覆盖"从相册选择"）	中	研发 + 法务
11	名单外的人怎么处理？建议增加"申请加入名单 → 管理员审批后自动放行"通道 → 已决策（2026-10）：不做自助通道，由老师手工加人	—	已关闭
12	门禁限流阈值（同 openid 每小时 10 次）是否合适，需按实际人数与使用习惯标定	中	研发
13	社会收集的名单从哪来 → 已关闭（2026-10 取消社会收集）	—	已关闭
14	门禁核验是否还要加手机号验证码（防止他人拿到姓名+身份证号后代填）	中	客户
15	材料识别的 VLM 选型与单价（用于成本核算与供应商比价）；触发率 15% 为预估值，需用真实数据实测标定	中	研发 + 商务
16	关键词表由谁维护（平台预置 + 租户自维护）；是否需要"从历史文件自动学习关键词"功能	中	产品
17	一寸照片的纯形态判定阈值（宽高比容差、背景纯净度）需用真实样本标定	中	研发
18	强特征词表需在更多批次数据上补充标定——学信网备案表、其它佐证材料在本数据集中不存在，其强词尚未定义	高	产品 + 研发
19	需要补充测试困难场景：模糊件、翻拍反光、非标准材料，当前 112 个样本未覆盖	高	研发
20	文件名规则的真实准确率待测 ✅ 已降级：该指标不影响交付项（输出命名取自名册、归属靠证件号反查、识别有槽位兜底、失败放行）。残留需求仅为上传页引导文案要贴合学生真实文件名，班主任在群里问两句即可，不需专门样本	—	产品
21	认定机构下发文件的真实格式样本 已澄清：不存在该文件，报考范围来自名单 → 问题关闭	—	✅ 已闭环
22	下发文件是全量还是增量 同上，问题关闭	—	✅ 已闭环
23	国标职业字典初始数据来源 降级：字典改为可选的拼写校验（P2），不阻塞开发	低	产品
24	是否允许学生修改"老师预填"的字段？ 本版设计为"可改并留痕"（依据：电话有 28 个不同值、入学时间可能记错）。若机构要求严格一致，需改为"只读 + 申请修改"	中	客户

---

文档结束