确认函 · 数据信息填报系统
文档用途：汇总需各方拍板的事项，可直接转发
发出日期：2026-09-28
回复期限：建议 5 个工作日内
版本：V1.0
致各位
我们已完成《数据信息填报系统》的需求与设计，进入开发前需确认若干关键事项。本文档把需确认的问题按拍板方分为四组：
| 分组 |
拍板方 |
项数 |
为什么需要确认 |
| A |
认定机构 |
6 |
直接决定验收标准——压缩到什么程度算合格、什么格式算合格 |
| B |
校方 / 客户业务 |
9 |
决定流程规则——名单外的人怎么处理、预填字段能不能改 |
| C |
商务 / 法务 |
5 |
决定资质与商业模式——小程序类目、定价、合规 |
| D |
我方内部技术 |
7 |
不涉及客户，仅内部拍板 |
每项都给出了「建议方案」，如无异议可直接回复"全部同意建议方案"。
若 5 个工作日内未收到回复，我方将按建议方案推进——以便不阻塞开发排期，后续如与预期不符可再调整（涉及外部技术依赖的除外，会单独再次确认）。
如何回复：只需按编号回答即可，例如——
A 组 · 请认定机构确认（技术规格）
这些直接决定交付物是否合格。我们已用真实批次（28 名学生 / 112 个文件）实测过，结论都有数据支撑。
A1. 「300dpi 扫描件」是否可接受？
|
|
| 背景 |
认定机构要求单文件 ≤1M。工作证明等 A4 材料原始为 1272dpi、16MB。我们实测将 A4 等比缩至 300dpi / 质量 85，28 张全部达标，平均 806KB，最大 831KB——即无需牺牲清晰度。 |
| 问题 |
输出为标准 300dpi 扫描件，是否可接受？ |
| 建议方案 |
✅ 接受 300dpi 输出（这是文档扫描的行业标准分辨率，清晰度零损失） |
| 需谁确认 |
认定机构 |
| 回复 |
☐ 同意 ☐ 需更高分辨率（请注明期望值） |
A2. 若某张扫描件内容特别复杂，压缩参数的下限怎么定？
|
|
| 背景 |
绝大多数材料 300dpi/q85 即可达标。但极端情况（满页手写、彩色底纹）可能需要降质。需要事先约定"最低可接受到什么程度"。 |
| 问题 |
允许系统自动降到的最低档是多少？ |
| 建议方案 |
✅ 建议：允许自动降至 200dpi / 质量 70；低于此值则标记"强制压缩"并需人工确认后才提交 |
| 回复 |
☐ 同意 ☐ 不允许降质，超限就驳回重传 |
A3. 学籍表等截图类材料，保留 PNG 格式是否会被拒收？
|
|
| 背景 |
实测学籍表为教务系统的屏幕截图（约 1025×590，PNG 格式，40KB）。若强行转 JPG，文字边缘会发虚——而截图本身已经很小，转换没有收益、只有损失。 |
| 问题 |
保留 PNG 是否可以？ |
| 建议方案 |
✅ 建议：截图类保留 PNG 原样输出（命名仍按规范） |
| 回复 |
☐ 可以保留 PNG ☐ 必须统一 JPG |
A4. 分辨率下限：什么样的图判定为"不合格、需重传"？
|
|
| 背景 |
实测发现有一张身份证翻拍件仅 558×745 / 0.08MB，明显低于同批其他人（1279×1706）。体积小不等于合格，需要设下限。 |
| 问题 |
长边低于多少像素应判定为不合格？ |
| 建议方案 |
✅ 建议：身份证等证件翻拍长边 ≥1400px；低于则提示重传（不阻断提交，由审核人决定） |
| 回复 |
☐ 同意 1400px ☐ 其他阈值：______ |
A5. 材料「工作证明」的规范文件名，与实际内容不符，是否保留？
|
|
| 背景 |
按机构模板，「职业技能等级个人申报表」的规范文件名却是「工作证明」（例：张三-身份证号-工作证明.jpg）。这是机构的既有习惯。 |
| 问题 |
是否按机构习惯保留这个命名？ |
| 建议方案 |
✅ 建议：保留机构习惯（系统支持别名映射，不影响内部识别） |
| 回复 |
☐ 保留 ☐ 改为"个人申报表" |
A6. 导出包的目录结构与命名是否符合接收要求？
|
|
| 问题 |
这个结构是否满足接收要求？ |
| 建议方案 |
✅ 建议：按上述结构（如需调整，请提供一份理想结构的样例） |
| 回复 |
☐ 符合要求 ☐ 需调整为：______ |
B 组 · 请校方 / 客户业务确认（流程规则）
B1. 不在名单上的人想填报，怎么处理？ ⚠️ 优先级最高
|
|
| 背景 |
按现有需求，系统采用"先导名单、姓名+身份证核验通过才能填报"的门禁机制。名单外的人一律不给填、只提示联系老师。
但这会带来运营问题：老师需要反复去后台手工加人。在几百人的社会收集中会很痛苦。 |
| 问题 |
是否给名单外的人一条"申请加入"通道？ |
| 建议方案 |
✅ 建议选 A —— 既不破门禁，又免去老师手工加人 |
| 选项 |
方案 |
代价 |
| A（建议） |
失败页增加「申请加入名单」按钮 → 生成管理员待办 → 管理员批准后自动放行 |
需开发一个审批小流程 |
| B |
维持现状：只提示，老师去后台加人 |
零开发，但老师负担重 |
| C |
给每个任务配"白名单开关"，允许自由填报 |
门禁形同虚设，不推荐 |
回复：☐ 选 A ☐ 选 B ☐ 选 C
B2. 社会收集的名单从哪里来？
|
|
| 背景 |
学校收集的名单可从教务系统导出，很稳定。但社会收集同样要求"先导名单"，如果名单来源不稳定，这套机制在社会侧很难跑起来。 |
| 问题 |
社会收集的名单由谁提供、怎么来？ |
| 建议方案 |
✅ 建议：由报名点/机构维护预报名名单，导入后开放填报；同时允许在填报期内随时追加（系统会告警范围外的报考项） |
| 回复 |
名单来源：__________ 维护责任人：__________ |
B3. 学生能不能修改老师预填的字段？
|
|
| 背景 |
实测老师交上来的名单里，21 个字段已填满 18 个（学历、在校生、学校、专业、入学时间、联系电话、报考三项等）。所以学生端主要是"核对 + 传材料"。
但老师填的东西可能出错——比如电话写错、入学时间记错。 |
| 问题 |
哪些字段允许学生改？ |
| 建议方案 |
✅ 建议按下表三分类 |
| 类别 |
字段 |
学生端 |
| 🔒 锁定 |
姓名、身份证号、报考职业/工种/等级 |
只读不可改（要改找老师） |
| ✏️ 可核对修改 |
其余全部（学历、在校生、学校、专业、入学时间、电话…） |
预填并标注"老师已填，请核对"，可改且留痕 |
| 📄 学生负责 |
各类材料文件 |
上传 |
回复：☐ 同意该分类 ☐ 要求全部只读（学生只能改电话） ☐ 其他：______
B4. 要不要再加一层手机号验证码？
|
|
| 背景 |
目前门禁是"姓名 + 身份证号"。理论上，只要有人拿到这两项信息，就能代填。 |
| 问题 |
是否需要加手机号验证码？ |
| 建议方案 |
⚠️ 建议不加。理由：① 名单里已有手机号，加验证等于要求一致；② 学生群体换号频繁，会制造大量"收不到验证码"的运营问题；③ 有人代填（如家长帮填）在本场景是可接受的。
若机构有实名硬要求，则必须加。 |
| 回复 |
☐ 不加 ☐ 必须加（请说明是哪个环节要求） |
B5. 学生被驳回几次后应升级提醒管理员？
|
|
| 问题 |
驳回次数上限设为几次？ |
| 建议方案 |
✅ 默认 3 次，达到后自动提醒管理员介入 |
| 回复 |
☐ 同意 3 次 ☐ 改为 ____ 次 |
B6. 导出包在服务器保留几天？
|
|
| 问题 |
导出包保留时长（超期自动清理，释放存储） |
| 建议方案 |
✅ 默认 7 天，管理员可随时重新导出（不重复计费） |
| 回复 |
☐ 同意 7 天 ☐ 改为 ____ 天 |
B7. 压缩质量的抽检由谁做？
|
|
| 背景 |
系统对"清晰度可能受损"的文件会打标记，需要人工抽检确认。但实测 28 张扫描件全部达标，不产生任何待抽检文件——这个机制可能用不上。 |
| 问题 |
是否需要保留抽检环节？由谁执行？ |
| 建议方案 |
✅ 建议保留机制但默认不启用（仅在出现"强制压缩"标记时才触发），由班主任在审核时顺带确认 |
| 回复 |
☐ 同意 ☐ 不需要该机制 |
B8. 一期是否需要与认定机构的业务系统对接？
|
|
| 问题 |
是否需要把数据直接推送到机构系统，而不是导出文件包？ |
| 建议方案 |
✅ 建议一期不做（导出标准包已可满足），但预留开放接口，二期按需启用 |
| 回复 |
☐ 一期不做 ☐ 一期就必须对接（请提供对方接口文档） |
B9. 社会收集是否需公安实名核验？
|
|
| 问题 |
是否调用公安实名核验接口（涉及按次收费） |
| 建议方案 |
✅ 建议不做。当前"名单核验 + 材料人工审核"已足够；如机构有硬要求再启用 |
| 回复 |
☐ 不做 ☐ 必须做 |
C 组 · 请商务 / 法务确认
| # |
事项 |
建议方案 |
回复 |
| C1 |
微信小程序主体资质是否齐备？教育类目可能需要办学许可或合作方资质，这会影响上线时间 |
请法务提前确认类目与所需资质；若小程序受阻，备选 H5 扫码填报可保底 |
☐ 资质齐备 ☐ 有问题，预计 ____ 解决 |
| C2 |
定价策略 |
建议：按在册人数计费（如 3–5 元/人/学期），免费版限 1 任务 / 60 人 |
☐ 同意 ☐ 改为 ______ |
| C3 |
是否向学生收取费用（如报名服务费）？ |
建议一期不做（涉及支付资质与资金合规），仅收 B 端服务费 |
☐ 不做 ☐ 需要 |
| C4 |
私有化部署版本是否同期开发？ |
建议 SaaS 优先、私有化后置（同代码，按需打包） |
☐ 同意 ☐ 同期开发 |
| C5 |
微信隐私保护指引需更新（需声明收身份证号、相册权限） |
我方负责配置，但需法务确认文案 |
☐ 由法务审文案 ☐ 我方自行处理 |
D 组 · 我方内部技术决策（仅备案，不需客户回复）
| # |
决策项 |
建议 |
备注 |
| D1 |
OCR 引擎选型 |
待比价（腾讯云 / 百度 / 本地模型） |
需同时评估数据出境合规 |
| D2 |
视觉大模型（VLM）选型 |
抽成可替换接口，不绑定供应商 |
实测触发率仅 2%~10%，成本可控 |
| D3 |
门禁限流阈值 |
同 openid 每小时 ≤10 次 |
上线后按真实数据标定 |
| D4 |
材料识别强特征词表 |
平台预置 + 租户可自维护 |
需在"社会评价"批次数据上补充标定 |
| D5 |
一寸照片形态判定阈值 |
用真实样本标定（宽高比容差、背景纯净度） |
— |
| D6 |
微信三条来源通道的体积上限 |
需真机实测 |
决定超限提示与降级路径 |
D7 |
文件名规则的真实准确率 |
✅ 已降级（见下） |
客户确认后重新评估：该指标不再影响任何交付项 |
附：已闭环的决策（无需再讨论）
| 决策 |
内容 |
依据 |
| D1 强制 1M |
A4 扫描件强制压到 1M，无例外、不设放宽 |
客户已确认 |
| 压缩参数 |
默认 300dpi / q85，实测 28/28 达标，平均 806KB |
用真实扫描件实测 |
| 无"拍照"入口 |
材料来源只有聊天记录 / 相册 / 手机文件三种 |
实测 4 类材料无一来自现场拍照 |
| 报考范围来源 |
从名单聚合，不存在独立的"计划清单"文件 |
真实名单验证（三列已填 28/28） |
| 数据库 |
PostgreSQL（纯 PG，不依赖 Vastbase 专有语法） |
已确认 + DDL 实测通过 |
| 软删除字段 |
deleted |
已确认 |
| 滑动交互 |
只做「右滑通过」，驳回必须点按钮 |
误触后果不对称 |
| 批量操作范围 |
批量通过只带无问题的单，红黄一律排除 |
防止"手快全选"放行异常 |
| 导出前置检查 |
有不合格文件时直接禁用导出按钮，不允许带问题打包 |
铁律 |
客户回执（2026-09-28）
回执结论：全部 23 项按我方建议方案执行。
本文档转为需求冻结基线——以下各项视为已确认，不再重新讨论。
A 组 · 认定机构（6 项）
| # |
确认结论 |
落地动作 |
状态 |
| A1 |
接受 300dpi 输出 |
无需改动。实测 28/28 达标，均值 806KB |
✅ 已一致 |
| A2 |
允许自动降至 200dpi / q70；低于此值标记"强制压缩"需人工确认 |
已一致：min_quality=70、hardFloorDpi=200、markWhenForced=true |
✅ 已一致 |
| A3 |
截图类保留 PNG |
已一致：keepPngForScreenshot=true；学籍表 1025×590 PNG 不缩放 |
✅ 已一致 |
| A4 |
证件翻拍长边 ≥1400px |
已一致：min_long_side DEFAULT 1400（仅 P2 档生效） |
✅ 已一致 |
| A5 |
保留「工作证明」命名（即使内容是个人申报表） |
已一致：材料别名映射，规范名不"纠正" |
✅ 已一致 |
| A6 |
导出包结构按建议 |
已一致：{批次号}-{任务名}/{班级}/{材料}/姓名-证件号-材料名.ext |
✅ 已一致 |
结论：A 组 6 项零改动——因为当初就是按实测数据设计的，确认只是把假设变成了事实。
B 组 · 校方业务（9 项）
| # |
确认结论 |
落地动作 |
状态 |
| B1 |
选 A：增加「申请加入名单 → 管理员审批」通道 |
⚠️ 需开发：新增 FR-509 系列 + 1 张表 + 4 个接口 + 2 屏原型 |
🔨 待实施 |
| B2 |
社会收集名单由报名点/机构维护预报名名单，导入后开放；填报期内可随时追加 |
已一致：FR-508 追加导入；补充说明写入 PRD §5.5 |
✅ 已一致 |
| B3 |
字段三分类：姓名/证件号/报考三项锁定，其余可核对修改并留痕 |
已一致：FR-502b + changed_fields 机制 |
✅ 已一致 |
| B4 |
不加手机号验证码 |
无需改动（当前门禁即姓名+证件号） |
✅ 已一致 |
| B5 |
驳回上限 3 次 |
已一致：maxRejectCount=3，超限升级管理员 |
✅ 已一致 |
| B6 |
导出包保留 7 天 |
已一致：expire_time = NOW() + 7 days |
✅ 已一致 |
| B7 |
保留抽检机制但默认不启用 |
已一致：FR-616，仅"强制压缩"标记触发 |
✅ 已一致 |
| B8 |
一期不对接机构系统，预留开放接口 |
已一致：§14 开放接口已设计但不启用 |
✅ 已一致 |
| B9 |
不做公安实名核验 |
无需改动 |
✅ 已一致 |
结论：B 组 9 项中 8 项零改动，仅 B1 需开发。
B1 的建议是我方主动提出的（原需求只有"只提示"），客户采纳后这是一次功能增量，已按 §变更记录 追加设计与排期。
C 组 · 商务法务（5 项）
| # |
确认结论 |
落地动作 |
| C1 |
小程序教育类目资质：按建议准备，若受阻走 H5 扫码填报保底 |
商务/法务启动；H5 保底方案需在 M0 期间做技术预研（约 2 人日） |
| C2 |
定价：按在册人数计费（3–5 元/人/学期），免费版 1 任务/60 人 |
已一致：sys_tenant_package 表已在 DDL 中 |
| C3 |
一期不向学生收费 |
无需改动 |
| C4 |
SaaS 优先、私有化后置（同代码按需打包） |
已在架构中体现 |
| C5 |
隐私保护指引：我方配置、法务审文案 |
⏳ 待法务出文案 |
D 组 · 我方内部（7 项）
| # |
决策 |
状态 |
| D1 |
OCR 引擎选型（腾讯云/百度/本地） |
⏳ M2 结束前定 |
| D2 |
VLM 抽成可替换接口，不绑定供应商 |
✅ 已按此设计（04 文档 M3 §3.6） |
| D3 |
门禁限流：openid 10 次/小时、IP 20 次/分钟 |
✅ 已实现口径 |
| D4 |
需索取「社会评价」批次的原始材料样本 |
✅ 已后置为二期（一期只做学校收集 + 自主认定，不涉及社会评价材料） |
D4 补充说明：为什么需要「社会评价」的样本
我们的实测数据集（24中技数控1班，28 人 112 文件）全部是自主认定批次，只覆盖 4 类材料。
而 cert_type=2 社会评价 批次的材料清单有两类是完全不同的，目前一份样本都没有。
| 材料编码 |
名称 |
出现在 |
强特征词现状 |
样本 |
PHOTO1 |
一寸照片 |
两者都有 |
一寸、证件照、免冠 |
✅ 112 个实测 |
IDCARD |
身份证 |
两者都有 |
身份证、公民身份、人像面 |
✅ 实测 |
WORK_PROOF |
工作证明 |
两者都有 |
申报表、工作证明、公章 |
✅ 实测 |
SCHOOL_ROLL |
学籍表 |
仅自主认定 |
学籍 |
✅ 实测 |
XJW_BA |
学信网备案表 |
仅社会评价 |
学信网、备案表、电子注册 |
❌ 零样本 |
OTHER_PROOF |
其它佐证材料 |
仅社会评价 / 专项 |
写不出词 |
❌ 零样本 |
需要样本解决的三件事
| # |
要解决什么 |
现状的猜测成分 |
| 1 |
标定 XJW_BA 的强特征词与形态阈值 |
现有词是从官方模板的文字要求里抄的，不是从真实文件观察来的。备案表可能是网页截图（P4）、打印扫描（P3）、或拍屏（P2），形态不同则识别与压缩策略完全不同 |
| 2 |
决定 OTHER_PROOF 要不要做自动识别 |
它含"毕业证 / 社保权益单 / 职称证明 / 技能等级证书"四类版式完全不同的东西。用一个编码承载，识别引擎无法从内容判断它"是不是其它佐证材料"。可能应改为：不做识别、默认识别失败放行、由学生自选槽位 |
| 3 |
校准 P2/P3/P4 的自动判定阈值 |
现有阈值是用院校批次（学籍表截图 1025×590）标定的 |
样本要求
| 项 |
说明 |
| 理想 |
一个完整的社会评价批次（1 个任务、全部人的全部材料） |
| 退而求其次 |
10~20 份，但必须覆盖「学信网备案表」和「各类佐证材料」（这两类现在零样本） |
| 特别注意 |
记录材料来源与格式——社会人员可能直接从学信网下载 PDF（而非拍照/扫描）。若是，file_types 白名单、预览、压缩策略都要跟着调整 |
✅ 已后置为二期（2026-09-28 客户确认）：一期范围收窄为「学校收集 + 自主认定」，材料只有 4 类（一寸照片 / 身份证 / 学籍表 / 工作证明），全部有 112 个真实文件实测。
因此 D4 不再是待办、也不阻塞任何里程碑。待二期做「社会评价」时再索取即可。
| D5 | 一寸照片形态阈值用真实样本标定 | ✅ 已有实测（984×1378，5:7） |
| D6 | 微信三条来源通道体积上限需真机实测 | ⏳ 待测 |
| D7 | 文件名规则在"学生原始乱名"上测真实准确率 | ✅ 已降级为文案校准（不需样本） |
D7 补充说明：为什么这个指标不再重要
原担忧：文件名层识别实测 112/112 命中，但这批文件是老师已经命名过的，属有偏样本。
学生的原始文件名可能是 微信图片_20260928103015.jpg、IMG_20260928_103015.jpg 这种，完全没有姓名和证件号。
重新评估后结论：这个指标的"有偏性"不影响任何交付项。
| # |
为什么不影响 |
依据 |
| 1 |
输出命名不依赖文件名 |
规范名一律取自名册（{姓名}-{证件号}-{材料名}），文件名只用于判断归属，不用于命名 |
| 2 |
归属校验不依赖姓名 |
判据是 证件号反查名册 > OCR > 姓名（仅辅助）；姓名单独不构成规则 |
| 3 |
材料类型识别有槽位兜底 |
学生在哪个槽位上传就默认是哪类（confidence 0.60），文件名只是交叉验证——用于发现传错槽位 |
| 4 |
识别失败一律放行 |
兜底策略已定：识别不出来不阻断提交 |
⇒ 即使学生的文件全是乱名（层 1 完全失效），系统行为也只是：
少了一层"传错槽位"的交叉验证，而槽位本身的准确性由学生自己保证，且形态层（层 2）与内容层（层 3）仍能发现明显错位。
不会出错，只会少一层提示。
降级后唯一残留的需求（文案问题，非算法问题）
上传页的「去哪里找」引导语（collect_material_def.tip_text）要贴合学生真实看到的文件名。例如：
| 如果学生文件名普遍是 |
引导语应该说 |
微信图片_20260928103015.jpg |
"在聊天记录里往上翻，找你发出去的那张图" |
IMG_20260928_103015.jpg |
"在相册里按拍摄日期找" |
Screenshot_2026-09-28.png |
"在相册的截图分类里找" |
怎么获取：不需要专门准备样本——班主任在班级群里问两句，或者让学生随手截几个文件名发过来即可。
⚠️ 原样本需求已取消，不再向客户索取"学生原始乱名样本"。
本次回执带来的变更汇总
| # |
变更 |
影响面 |
工作量 |
| V1 |
新增 FR-509 系列：名单加入申请与审批 |
PRD / DDL / 接口 / 模块设计 / 原型 / WBS / 测试 |
+9 人日 |
| V2 |
社会收集名单来源补充说明（B2） |
PRD §5.5 |
0.5 人日 |
| V3 |
H5 保底方案技术预研（C1） |
M0 追加 |
2 人日 |
|
|
合计 |
+11.5 人日 |
修订后排期：380 → 391.5 人日；关键路径 67 → 76 人日；工期 14 周 → 15 周。
（B1 落在 M2，而 M2 在关键路径上，故工期顺延 1 周。）
lovife
63aec55329