docs: 产品文档与交互原型(P1-P7 交付物)
一期范围:学校收集 + 自主认定(4 类材料全部有实测样本) - 主 PRD 190KB:125 条 FR / 21 条 VAL / 20 张表 DDL / 121 个接口 - 功能逻辑卷 88KB:不含代码模块 - 接口设计 116KB:58 个错误码 / 12 个 VO - 核心模块设计:M1 命名 / M2 压缩 / M3 识别 / M4 门禁 / M5 校验 / M6 导出 - 开发任务拆解:100 任务 / 387 人日 / 15 周 - 验收测试清单:36 条 Golden 断言 / 111 条功能验收 - PostgreSQL DDL:已在 PG 16.15 实测零错误 - 交互原型 31 屏:学生端 11 / 班主任端 9 / 管理端 11
This commit is contained in:
@@ -0,0 +1,376 @@
|
||||
# 确认函 · 数据信息填报系统
|
||||
|
||||
> 文档用途:汇总需各方拍板的事项,**可直接转发**
|
||||
> 发出日期:2026-09-28
|
||||
> 回复期限:建议 **5 个工作日内**
|
||||
> 版本:V1.0
|
||||
|
||||
---
|
||||
|
||||
## 致各位
|
||||
|
||||
我们已完成《数据信息填报系统》的需求与设计,进入开发前需确认若干关键事项。本文档把需确认的问题按**拍板方**分为四组:
|
||||
|
||||
| 分组 | 拍板方 | 项数 | 为什么需要确认 |
|
||||
|---|---|:--:|---|
|
||||
| **A** | 认定机构 | 6 | 直接决定**验收标准**——压缩到什么程度算合格、什么格式算合格 |
|
||||
| **B** | 校方 / 客户业务 | 9 | 决定**流程规则**——名单外的人怎么处理、预填字段能不能改 |
|
||||
| **C** | 商务 / 法务 | 5 | 决定**资质与商业模式**——小程序类目、定价、合规 |
|
||||
| **D** | 我方内部技术 | 7 | 不涉及客户,仅内部拍板 |
|
||||
|
||||
**每项都给出了「建议方案」,如无异议可直接回复"全部同意建议方案"。**
|
||||
若 5 个工作日内未收到回复,我方将按建议方案推进——**以便不阻塞开发排期**,后续如与预期不符可再调整(涉及外部技术依赖的除外,会单独再次确认)。
|
||||
|
||||
**如何回复**:只需按编号回答即可,例如——
|
||||
```
|
||||
A1 同意
|
||||
A2 选 B
|
||||
B1 选 A,但希望增加审批环节
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 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. 导出包的目录结构与命名是否符合接收要求?
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **背景** | 系统默认按下述结构打包: |
|
||||
|
||||
```
|
||||
{批次号}-{任务名}/
|
||||
├── 24中技数控1班/
|
||||
│ ├── 一寸照片/ 张三-360121200010101234-一寸照片.jpg
|
||||
│ ├── 身份证/ 张三-360121200010101234-身份证.jpg
|
||||
│ ├── 学籍表/ 张三-360121200010101234-学籍表.png
|
||||
│ └── 工作证明/ 张三-360121200010101234-工作证明.jpg
|
||||
└── 考生线下报名信息导入模板(汇总).xlsx
|
||||
```
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **问题** | 这个结构是否满足接收要求? |
|
||||
| **建议方案** | ✅ **建议:按上述结构**(如需调整,请提供一份理想结构的样例) |
|
||||
| **回复** | ☐ 符合要求 ☐ 需调整为:______ |
|
||||
|
||||
---
|
||||
|
||||
## B 组 · 请校方 / 客户业务确认(流程规则)
|
||||
|
||||
### B1. 不在名单上的人想填报,怎么处理? ⚠️ **优先级最高**
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **背景** | 按现有需求,系统采用"**先导名单、姓名+身份证核验通过才能填报**"的门禁机制。名单外的人**一律不给填、只提示联系老师**。<br>但这会带来运营问题:**老师需要反复去后台手工加人**。在几百人的社会收集中会很痛苦。 |
|
||||
| **问题** | 是否给名单外的人一条"申请加入"通道? |
|
||||
| **建议方案** | ✅ **建议选 A** —— 既不破门禁,又免去老师手工加人 |
|
||||
|
||||
| 选项 | 方案 | 代价 |
|
||||
|---|---|---|
|
||||
| **A(建议)** | 失败页增加「**申请加入名单**」按钮 → 生成管理员待办 → **管理员批准后自动放行** | 需开发一个审批小流程 |
|
||||
| B | 维持现状:只提示,老师去后台加人 | 零开发,但老师负担重 |
|
||||
| C | 给每个任务配"白名单开关",允许自由填报 | 门禁形同虚设,**不推荐** |
|
||||
|
||||
**回复**:☐ 选 A ☐ 选 B ☐ 选 C
|
||||
|
||||
### B2. 社会收集的名单从哪里来?
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **背景** | 学校收集的名单可从教务系统导出,很稳定。但社会收集**同样要求"先导名单"**,如果名单来源不稳定,这套机制在社会侧很难跑起来。 |
|
||||
| **问题** | 社会收集的名单由谁提供、怎么来? |
|
||||
| **建议方案** | ✅ **建议:由报名点/机构维护预报名名单,导入后开放填报**;同时允许在填报期内**随时追加**(系统会告警范围外的报考项) |
|
||||
| **回复** | 名单来源:__________ 维护责任人:__________ |
|
||||
|
||||
### B3. 学生能不能修改老师预填的字段?
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **背景** | 实测老师交上来的名单里,21 个字段**已填满 18 个**(学历、在校生、学校、专业、入学时间、联系电话、报考三项等)。所以学生端主要是"核对 + 传材料"。<br>但老师填的东西可能出错——比如电话写错、入学时间记错。 |
|
||||
| **问题** | 哪些字段允许学生改? |
|
||||
| **建议方案** | ✅ **建议按下表三分类** |
|
||||
|
||||
| 类别 | 字段 | 学生端 |
|
||||
|---|---|---|
|
||||
| 🔒 **锁定** | 姓名、身份证号、**报考职业/工种/等级** | **只读不可改**(要改找老师) |
|
||||
| ✏️ **可核对修改** | 其余全部(学历、在校生、学校、专业、入学时间、电话…) | 预填并标注"老师已填,请核对",**可改且留痕** |
|
||||
| 📄 **学生负责** | 各类材料文件 | 上传 |
|
||||
|
||||
**回复**:☐ 同意该分类 ☐ 要求全部只读(学生只能改电话) ☐ 其他:______
|
||||
|
||||
### B4. 要不要再加一层手机号验证码?
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **背景** | 目前门禁是"姓名 + 身份证号"。理论上,**只要有人拿到这两项信息,就能代填**。 |
|
||||
| **问题** | 是否需要加手机号验证码? |
|
||||
| **建议方案** | ⚠️ **建议不加**。理由:① 名单里已有手机号,加验证等于要求一致;② 学生群体换号频繁,会制造大量"收不到验证码"的运营问题;③ 有人代填(如家长帮填)在本场景是可接受的。<br>**若机构有实名硬要求,则必须加。** |
|
||||
| **回复** | ☐ 不加 ☐ 必须加(请说明是哪个环节要求) |
|
||||
|
||||
### 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 周。)
|
||||
Reference in New Issue
Block a user