lovife
4a5790d900
一、dev-clean-e2e.py：加「在用组织保护」后执行
· 先算「仍被存活任务引用的组织」并保留 —— 当前演示态就挂在其中一个
「E2E 24数控1班」上，删了它演示态就坏（保留 3 个，演示态完好：
任务 1449 / 名册 3 人 / 组织 43 都在）
· 已执行 --apply --demo-tasks --orphan-files：
49 个 e2e 租户 + 147 个测试组织 + 84 个【演示·旧】任务，
共 3714 行 / 27 个文件（业务表按 information_schema 动态枚举，不写死清单）
二、dev-clean-qiniu.py（新增）：清真实桶里本项目前缀的测试对象
· 只动 xiaotutongxue/ 前缀；默认 dry-run；删前核实库中零引用、
数量异常（>5000）直接停
· 已执行：2036 个对象 / 116 MB 全部删除，删后复验 0 个（F-93「删库不删桶」）
· 签名按官方文档逐字核对 —— 踩了两个 401 才对：旧 QBox 格式（一个换行 +
"QBox " 前缀）不对，是「两个换行 + Qiniu 前缀」；batch 的 Body 必须进
签名串（列举无 Body 能过、批删全 401 —— 同一签名函数一好一坏，线索在 Body）
· 列举在 rsf.qiniuapi.com，不在 rs（打错 host 报「Bad method: list」）
三、xt-minio 容器已删（F-2）—— 代码早已不用 S3，deploy 里也没有它
四、文档核销与记录
· docs/08：F-3/4/7/10（小节）与 F-14/26/29/30/31/38/51/57/64/65/71/72/93
（表格行）全部标「已闭环」；F-5 补执行记录；F-28 备案维持两级（→D-11）；
变更记录补两行 —— **F-1~F-100 至此无未决项**，剩余全部等外部输入
· docs/01：新增 E4「国标职业库数据来源待客户确认」（F-34，字典页如实显示 0 项）
· 交接摘要：新增 §一·三十一（17 项决策执行记录）
· AGENTS.md：清理一节写清三个工具与「在用组织保护」
验证：python scripts/verify-all.py --with-e2e →
通过 8 / 失败 0 / 跳过 0（37 个 E2E 脚本 / 1577 条断言 / 0 失败，291s；
prodguard 9/9；test profile 能起）
456 lines
27 KiB
Markdown
456 lines
27 KiB
Markdown
# 确认函 · 数据信息填报系统
|
||
|
||
> 文档用途：汇总需各方拍板的事项，**可直接转发**
|
||
> 发出日期：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~~ | ~~门禁限流阈值~~ | ⚠️ **口径已更新，见 E2**：改为"**只对失败计数**"（按人 10 次/小时、按 IP 20 次/分钟；成功侧 600 次/分钟，2026-09-30 二次压测后由 200 上调）—— 旧口径会把整间教室挡住 | 压测后已改（2026-09-30，两次） |
|
||
| D4 | 材料识别强特征词表 | 平台预置 + 租户可自维护 | **需在"社会评价"批次数据上补充标定** |
|
||
| D5 | 一寸照片形态判定阈值 | 用真实样本标定（宽高比容差、背景纯净度） | — |
|
||
| D6 | 微信三条来源通道的体积上限 | 需真机实测 | 决定超限提示与降级路径 |
|
||
| ~~D7~~ | ~~文件名规则的真实准确率~~ | ✅ **已降级**（见下） | 客户确认后重新评估：该指标**不再影响任何交付项** |
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## E 组 · 第二轮待确认（2026-09-30 新增）
|
||
|
||
> 上一轮回执（2026-09-28）之后，开发又推进了一大段，**新出现三件需要外部推动的事**。
|
||
> 其中 **E1 是真正的阻断项**（不是"我们还没做"，而是"**没有它做不了**"）。
|
||
|
||
### E1. ⚠️ `union_id`：两条填报腿不能同时上线（阻断项）
|
||
|
||
**背景（一句话）**：同一个学生用「H5 扫码」与「微信小程序」进来时，
|
||
微信给出的是**两个不同的 openid**（不同 appid 各自签发），
|
||
系统会把他当成**两个人** —— 他第二次进来会看到「该信息已被登记」。
|
||
|
||
**事实核对**（我们这边已就绪的部分）：
|
||
|
||
| 项 | 状态 |
|
||
|---|---|
|
||
| `sys_user.union_id` 字段 | ✅ **已预留** |
|
||
| 「按 union_id 认人」的方案 | ✅ **已写进代码注释**（`MpH5AuthService` 类头） |
|
||
| 实际读写 | ❌ **零**（683 个用户全为 `null`）—— 因为拿不到 union_id |
|
||
|
||
**需要谁做什么**：
|
||
|
||
| 谁 | 做什么 |
|
||
|---|---|
|
||
| **商务 / 客户** | 确认是否注册并认证**微信开放平台**账号（￥300/年），并把**小程序与公众号都绑定到它** |
|
||
| 我方开发 | 拿到 union_id 后：登录时存 union_id，并按 union_id 认人（预计 0.5 人日） |
|
||
| 客户决策 | 若**一期只上 H5**（推荐），此事可推迟；**但"小程序上线"必须先完成这一步** |
|
||
|
||
**建议**：一期按 H5 单腿上线（学生扫 H5 码即可填报），小程序作为第二条腿，
|
||
在开放平台绑定完成后一起开。**这样不必等它，但必须知道它挡着什么。**
|
||
|
||
回复：☐ 现在就办（我方可提供绑定步骤） ☐ 一期只上 H5，二期再办 ☐ 其他 ______
|
||
|
||
### E2. D3 门禁限流阈值口径已更新（备案，无需回复）
|
||
|
||
原 D3 写的是「同 openid 每小时 ≤10 次」。**压测后已改为"只对失败计数"**：
|
||
|
||
| 计数器 | 计什么 | 限额 | 为什么 |
|
||
|---|---|---|---|
|
||
| 失败（按人） | **只计失败** | 10 次/小时 | 防猜 |
|
||
| 失败（按 IP） | **只计失败** | 20 次/分钟 | 防枚举 |
|
||
| 成功（按 IP） | 只计成功 | **600 次/分钟**（2026-09-30 由 200 上调，见下） | 防"批量取数据" |
|
||
|
||
**为什么必须改**：一个班的学生坐在同一间教室、连同一个 WiFi，出口是同一个公网 IP。
|
||
按旧口径，60 人同时扫码时**只有 20 个能进**，其余 40 个看到「操作过于频繁」——
|
||
而那是**首次落地第一分钟就会发生的事**。
|
||
|
||
关键区分：**枚举攻击产生的是失败，教室产生的是成功。**
|
||
|
||
> **2026-09-30 二次修正（备案，无需回复）**：成功侧上限原定 200 次/分钟，
|
||
> 实测**恰好卡在"一个年级"的量级** —— 250 个不同学生同时核验（全部正确）时
|
||
> **213 个成功、37 个被挡**。全校在同一个出口 IP 集中填报（开学第一课集体扫码）
|
||
> 就会撞上，而**没有人做错了什么**。已上调为 **600 次/分钟**，
|
||
> 复测 250 人 **250/250**、500 人 **500/500**；失败侧两个计数器原样未动
|
||
> （防枚举的强度没有降低）。详见《09-部署与运维》§9.3。
|
||
|
||
### E3. 二期（社会收集 / 社会评价 / 专项职业能力）的启动时点
|
||
|
||
一期范围已按约定锁死为「学校收集 + 自助认定」（其他模式一律返回 `40044`）。
|
||
但**二期什么时候启动**会影响两件现在就能做、也可以等的事：
|
||
|
||
| 事项 | 如果二期在 3 个月内启动 | 如果更晚 |
|
||
|---|---|---|
|
||
| D4 材料识别强特征词表标定 | 建议现在就在社会评价批次数据上标定 | 可现在只做学校批次的标定 |
|
||
| D5 一寸照片形态阈值标定 | 同上 | 同上 |
|
||
| 二期审核流与会话设计 | 建议现在出一版概要设计，避免一期代码挡住它 | 一期交付后再说 |
|
||
|
||
回复：☐ 二期预计 ____ 启动 ☐ 暂无计划
|
||
|
||
### E4. 国标职业库数据的来源（字典页「职业（国标）」目前是空的）
|
||
|
||
`sys_occupation_ref`（国标职业库）一期为 **0 行**：契约 §13.3 把 `OCCUPATION` 字典的数据来源
|
||
指定为这张表，而它是**国标数据**（GB/T 职业分类），需要贵方提供或采购后导入 ——
|
||
不是我们能自行生成的。现状：字典管理页里「职业（国标）」显示 0 项（如实展示，不假装有数据）；
|
||
`itemCount` 直接用 `COUNT(*)`，数据导入后自动就对了，**不需要改代码**。
|
||
|
||
回复：☐ 我方提供数据（预计 ____） ☐ 采购（预算 ____） ☐ 一期不上这个字典
|
||
|
||
## 附：已闭环的决策（无需再讨论）
|
||
|
||
| 决策 | 内容 | 依据 |
|
||
|---|---|---|
|
||
| **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 周。）
|