深学在线 · 管理端(PC)交互原型

https://admin.tianbaotong.cn/tasks

进行中任务

覆盖 6 个班级 / 168 人

待我终审

24中技数控1班等 3 个班

异常待处理

证件号 3 · 低清 2 · 串档 1

本月导出

4次

最近 09-26 14:20

进行中的收集任务按截止时间排序

任务名称	模式	覆盖班级	应填 / 已提交	进度	截止	状态
2026年9月机电专业认定材料收集	学校收集	24中技数控1班	28 / 23	82%	10-15	收集中
2026年9月汽车维修工认定收集	学校收集	24中技汽修1班	42 / 42	100%	10-12	待终审
2026年秋季社会人员认定报名	社会收集	南昌报名点	98 / 61	62%	10-20	收集中

需要我处理的按紧急度排序

24中技数控1班 · 陈子文疑似串档　一寸照片的证件号与他其他材料不一致，且两个号码校验位都通过（是两个真实的人）。需管理员判断是否驳回。
班主任已初审：标记为待管理员确认

24中技数控1班 · 报考范围发现异常项　28 人中 27 人报「车工/数控车工/四级中级工」，1 人报「车工/普通车工/三级高级工」（占比 3.6%），疑似填写错误。

STEP 01 工作台：先给结论，再给细节四张统计卡回答"现在什么状况"，下面两张卡回答"我要做什么"。异常按紧急度排在最上面——串档（有红项）在范围异常（黄项）之上。注意"异常待处理 7"下面标注了构成（证件号 3 · 低清 2 · 串档 1）——管理员不用点进去就知道是什么类型的问题。

https://admin.tianbaotong.cn/tasks/new?step=7

1基本信息

›

2覆盖班级

›

3名单

›

4表单

›

5材料

›

6审核流

›

7预览发布

发布前必须完成一次命名规则试跑。粘贴几条学生可能交上来的原始文件名，确认系统改出来的结果符合机构要求——这是防止"规则配错导致全员改名错误"的唯一闸门。

命名模板

{姓名}{证件号}{材料名} {班级}{工种}{序号}

{姓名}-{证件号}-{材料名}.jpg

与机构模板一致。连接符为半角 -，大小写按名单原样。

纠错开关

自动修复多余扩展名自动补齐缺失的连接符证件号末位统一大写形近字纠错（需学生确认）校验位裁决推荐

试跑粘贴任意条数，不影响真实数据

数据来自真实批次样本

试跑结果自动修复 4 待确认 1 需人工 1

原始文件名	规范后	判定
曾伊豪-361029200907295110身份证.jpg.jpg	曾伊豪-361029200907295110-身份证.jpg	自动修复
于豪-360103200805166169-身份证.jpg.jpg	于豪-360103200805186619-身份证.jpg	校验位裁决
扬晨-360825200904303215-一寸照片.jpg	杨晨-360825200904303215-一寸照片.jpg	形近字待确认
曹文锋-36012120081211239-一寸照片.jpg	曹文锋-360121200812111239-一寸照片.jpg	名册补齐
徐程宇360981200901292334-身份证.jpg.jpg	徐程宇-360981200901292334-身份证.jpg	自动修复
陈子文-360122200902044232-一寸照片.jpg	— 不予自动修改 —	疑似串档 · 转人工

最后一条必须人工处理。陈子文的照片证件号 360122200902044232 与名单 36010520090817121X 不一致，且两个号码校验位都通过——说明是两个真实存在的人，不是打字错误。系统不猜，交人工判断。

试跑通过率 83%（5/6 可自动处理）

STEP 02 · 最重要的一屏命名规则试跑：发布前的唯一闸门 没有这一屏，规则配错就会导致全员改名错误——而且错到导出时才会发现，那时已无法挽回。所以它被设成发布的前置条件（未试跑不给发布）。结果表用红底高亮"改了什么"、绿底标"补了什么"。最后一行陈子文的案例最有价值：系统明确说"两个号码校验位都通过 = 是两个真人，不是打字错误"，并拒绝自动修改——把判断权交还给人。

https://admin.tianbaotong.cn/tasks/1/roster/import

① 表头识别已自动定位

系统没有假设"第一行是表头"，而是在工作表中逐行查找同时包含「姓名」「身份证号」的行。本次在工作表「填表注意事项」的第 6 行找到表头——该文件前 5 行是填表说明与示例。

行	A	B	C	D	E	…	判定
1	特别注意：请勿调整模板！！！在第一个…						说明
2	01、标题颜色：红色标题为必填项…						说明
3	02、下拉选项：学历、报考等级…						说明
4	…						说明
5	…						说明
6	序号	姓名	身份证号	学历	联系电话	…	表头
7	1	熊宇豪	360981…4437	技工学校	199…0823	…	数据
8	2	魏航	360427…3318	技工学校	178…3067	…	数据

② 字段映射21 列已自动匹配

Excel 列	系统字段	状态
B · 姓名	姓名	已匹配
C · 身份证号	身份证号	已匹配
G · 报考职业	报考职业锁定	已匹配
H · 报考工种	报考工种锁定	已匹配
I · 报考等级	报考等级锁定	已匹配
D · 学历	学历可改	已匹配
N · 是否在校生	是否在校生可改	已匹配
— 未识别 —	（其余 14 列）	忽略

③ 导入体检可以导入

总行数

通过

警告

1 项需要注意（不阻断导入）
「报考工种」出现 2 种写法：数控车工（27 人）与普通车工（1 人）——见下一步的「报考范围确认」。

身份证号 28/28 全部通过校验位，无重复、无缺失。姓名列无重复。

表头定位 + 字段映射已确认，可导入

STEP 03 名单导入：把"系统怎么认表头"摊开给人看实测两份真实文件，表头一个在第 1 行、一个在第 6 行，工作表名也不同。所以系统不猜、也不要求用户改文件，而是把定位过程可视化——说明行标灰、表头行标绿，让人一眼确认"认对了没有"。第②栏的字段映射里，报考三项带"锁定"标记——这是在导入阶段就告诉管理员：这三项由你确定，学生端只读。第③栏的体检把"警告"和"通过"分开呈现，并明确写"不阻断导入"。

https://admin.tianbaotong.cn/tasks/1/scope

本期报考范围由名单自动聚合而来。系统不做更正，只做一致性体检——单看一行都合法，但"27 人报 A、1 人报 B"这种情况只有聚合后才能发现。

聚合结果共 2 组 · 28 人

报考职业	报考工种	报考等级	人数	占比	判定
车工	数控车工	四级/中级工	27	96.4%	主体范围
车工	普通车工	三级/高级工	1	3.6%	疑似填错

「普通车工 / 三级高级工」仅 1 人，占比 3.6%，明显偏离主体范围。 常见的三种可能：① 该生确实单独报考了另一个工种；② 老师录入时选错了；③ 该生是转班生，用的是上一批次的配置。
请核对后再决定——系统不会自动改名单。

定位到的人

姓名	身份证号	归属
余饶平	360281…4035	24中技数控1班

后续影响重要

· 学生端展示
学生核验通过后会看到"你报考：车工 / 普通车工 / 三级高级工"——如果这是错的，学生会发现并反馈。
· 中途追加名单
若之后补录的人报考项超出已确认范围，系统会告警并要求你确认后才接受。

确认后，学生端将按此范围展示报考信息

STEP 04 · 新概念报考范围确认：不做更正，只做体检「报考范围」这个实体是我们拆解官方模板时才发现的——模板规则 04/05/06 说"只能填当前评价计划中的职业/工种/等级"，但实测确认这个范围就藏在名单里（老师导入时已填好），不存在独立的计划文件。所以这里不设计"约束"设计，而是"体检"设计：系统把聚合结果摆出来，标出"少数派"，给出三种常见原因，然后把决定权交还给人。这种"27 人一致、1 人例外"的问题，单看任何一行都合法，只有聚合后才能发现。

https://admin.tianbaotong.cn/tasks/1/dashboard

应填人数

1 个班级

已终审通过

53.6%

提交待处理

初审 4 · 待核对 3 · 异常 1

未提交

距截止 3 天

按报考工种统计来自正式列，实时聚合

报考工种	等级	人数	占比
数控车工	四级/中级工	27	96.4%
普通车工	三级/高级工	1	3.6%

这类统计之所以能实时出，是因为 18 个业务字段建成了正式列，而不是塞进 JSON。SQL 直接 GROUP BY，还能吃到索引。

材料异常清单需处理 4

姓名	问题	级别
陈子文	一寸照片证件号与其它材料不符	串档
杨晨	身份证图偏小 558×745	低清
曹文锋	证件号 17 位，已按名单补齐	待核对
黎思明	证件号 17 位，已按名单补齐	待核对

处理进度按状态分布

已通过 15 待初审 4 待核对 3 异常 1 未提交 5

STEP 05 数据看板：把"为什么能实时统计"写出来这是当初坚持把 18 个业务字段建成正式列、而不是塞进 JSON 换来的能力——按工种统计、按学历筛选、按班级排名全部走 SQL 聚合 + 索引，实时出数。看板上直接放了一句说明："这类统计之所以能实时出，是因为字段建成了正式列。"——把架构决策的收益摆在用户能看到的地方，比写在技术文档里有用。

https://admin.tianbaotong.cn/review?status=pending_final

全部 23 无异常 22 有异常 1 "一键全部通过"仅在零异常时可用

姓名	班级	初审人	材料	系统校验	提交时间
曾伊豪	24中技数控1班	李老师	4/4 · 2.9MB	无问题	09-28 09:41
李绍康	24中技数控1班	李老师	4/4 · 3.1MB	无问题	09-28 08:12
何天宇	24中技数控1班	李老师	4/4 · 2.6MB	无问题	09-27 21:03
陈子文	24中技数控1班	李老师	4/4 · 1.4MB	疑似串档	09-27 16:55
曾云天	24中技数控1班	李老师	4/4 · 2.2MB	无问题	09-27 15:20

"一键全部通过"按钮此刻是禁用状态（因存在 1 条异常）。这是刻意的：防止管理员大而化之地放行。只有整批零异常时才允许全通过。

STEP 06 终审：把"全选"这条路堵掉一半终审是最容易出事的环节——管理员面对 23 条记录，天然想"全选通过"。所以设计上做了两层限制：异常行默认不勾选且标红，"一键全部通过"在没有异常时才可用。表格里保留"初审人"一列——终审时能看到是谁初审判过的，出问题时可以回溯到人。责任可见，是审核质量的前提。

https://admin.tianbaotong.cn/export/new

前置检查未通过：1 份材料存在异常，无法打包。
陈子文的「一寸照片」疑似串档尚未处理。这是铁律——不合格的文件不允许进入汇总包。

导出范围

全任务（23 人）仅已终审通过（15 人）推荐按班级选择指定人员

同时包含原始文件（未经压缩）生成汇总 Excel 证件号脱敏

打包设置

分卷大小

预计 1 卷，共 约 37 MB。对比原始文件总量 475 MB，压缩率 92%。

目录结构预览按机构要求生成

├─ 202609机电认定-24中技数控1班/

├─ 一寸照片/

│　└─ 熊宇豪-360981200812084437-一寸照片.jpg 96KB

├─ 身份证/

│　└─ 熊宇豪-360981200812084437-身份证.jpg 810KB

├─ 学籍表/

│　└─ 熊宇豪-360981200812084437-学籍表.png 41KB

├─ 工作证明/

│　└─ 熊宇豪-360981200812084437-工作证明.jpg 806KB

└─ 考生线下报名信息导入模板（汇总）.xlsx 18KB

共 15 人 × 4 项 = 60 个文件，已全部通过命名规范与体积校验。

导出为异步任务，完成后微信通知你

STEP 07 导出中心：把"不允许带问题打包"做成按钮禁用 PRD 里的铁律 2 是「没有规范文件名、没有压到 1M 内的文件，不得进入汇总包」。这里不是弹个警告了事，而是直接禁用"开始导出"按钮，并指出是哪一个人的哪一项卡住了。右侧的目录树预览是关键——管理员在点导出之前就能看到最终交付的文件长什么样、名字对不对、体积标没标。不用等打完包再解压检查。
底部还报了一个容易被忽略的数字：原始 475MB → 最终 37MB，压缩率 92%。

https://admin.tianbaotong.cn/tasks/new?step=4

1基本信息

›

2覆盖班级

›

3名单

›

4表单

›

5材料

›

6审核流

›

7预览发布

表单分两层：内置字段（来自官方模板，存正式列、可统计）+ 扩展字段（机构额外要求，存 JSON）。内置字段的标签可改、顺序可调，但不能删除——它们是导出模板的固定列。

字段库

基础

单行文本

数字

单选 / 多选

日期

下拉字典

专用

身份证号

手机号

职业工种级联

拖到右侧画布即可添加

表单画布21 内置 + 0 扩展

内置字段 · 来自官方模板

⋮⋮姓名文本锁定

⋮⋮身份证号身份证锁定

⋮⋮报考职业 / 工种 / 等级级联锁定

⋮⋮学历下拉 11 项可改

⋮⋮联系电话手机号

⋮⋮工作单位文本

⋮⋮是否补考是/否

⋮⋮补考理论 / 实操 / 综合级联条件显示

⋮⋮是否在校生是/否

⋮⋮在读学校 / 所学专业 / 入学时间级联条件显示

⋮⋮本职业工作年限数字

⋮⋮已获证书职业工种 / 等级 / 编号文本

扩展字段 · 存 JSON，不参与核心统计

从左侧拖字段到这里

字段属性学历

标签

选项来源

校验

必填严格值匹配（禁止手填）

学生端行为

预填可改
名单有值则预填并标注"老师已填，请核对"

条件显示规则官方模板用绿色标题标识的级联列

当是否补考=是 →显示补考理论 / 补考实操 / 补考综合并校验：科目数受等级约束

当是否在校生=是 →显示且必填在读学校 / 所学专业 / 入学时间入学时间格式 YYYY-MM-DD

当认定类型=专项职业能力 →隐藏报考工种 / 报考等级 / 全部补考科目整组跳过校验

STEP 08 表单设计器：内置字段锁定，扩展字段自由左中右三栏是老配方（字段库 / 画布 / 属性），但有一个关键约束：内置的 21 个字段带锁标记，可改标签、可调顺序，但不能删除——它们是导出模板的固定列，删了就无法写回官方 Excel。底部那三条条件显示规则直接对应官方模板的"绿色标题 = 级联选项"。第三条（专项职业能力 → 整组隐藏并跳过校验）最容易被漏做，单独列出来。
"扩展字段"区域用虚线框标注存 JSON、不参与核心统计——把之前那个架构取舍摆在配置界面上，管理员就知道为什么有些字段能统计、有些不能。

https://admin.tianbaotong.cn/tasks/new?step=5

1基本信息

›

2覆盖班级

›

3名单

›

4表单

›

5材料

›

6审核流

›

7预览发布

材料清单4 项

一寸照片

P1 证件照 · ≤0.3M

身份证

P2 证件翻拍 · ≤1M

学籍表

P4 截图 · ≤1M

工作证明

P3 扫描件 · ≤1M

「一寸照片」的规则实测 984×1378 → 规格化 295×413

命名模板

{姓名}-{证件号}-{材料名}.jpg

{姓名}{证件号}{班级}{序号}

别名（用于识别历史文件名）

1寸照片 · 一寸电子照片 · 证件照 · 免冠照

格式与体积

jpgpngpdfheic

体积上限 KB 含下限保护

压缩档位

本项有专属规则：证件照规格化会裁切并写入 300dpi

来源引导语（显示在学生端）

必传允许一次多选开启拍照入口默认关闭

STEP 09 材料规则配置：把"压缩档位"做成可解释的选择每个材料项独立配置命名模板、别名、格式白名单、体积上限、压缩档位、来源引导语。左侧列表直接显示每项的档位与上限——管理员一眼能看出四项材料用了四套不同规则。三个细节：① 体积上限旁标"含下限保护"（防止过度压缩，实测有一张身份证只有 0.08MB）；② 压缩档位下拉里写明每档的适用条件（"P1 证件照（固定 295×413）"），不是让管理员去猜 "P1" 是什么；③ "开启拍照入口"默认不勾——因为实测 4 类材料无一来自现场拍照。

STEP 10 · 角色与授权权限是契约、不是配置：内置角色只读，自定义角色可配内置角色现在只剩 4 个（平台运营 / 学校管理员 / 班主任 / 学生），权限写在后端代码里（BuiltinRole）、界面上只读。租户可另建自定义角色，于是"谁能做什么"第一次变成客户可以自己配的东西 —— 而这类功能一旦做松，代价是管理员把自己锁在系统外。五个细节：
① 内置角色只读——可以看、不能改。它的权限是前后端契约（权限码定义在代码里），改它等于改代码；界面上正确的做法是"照着它新建一个"；
② 「看得见」与「有权限」分开——菜单只决定左侧显示哪些入口，真正的访问控制是权限码校验（绕过前端只会拿到 40301）；
③ 平台级权限与平台专用菜单在界面上禁用，服务端也会以 40301 拒绝——"学校管理员给自己人造一个平台账号"是这套系统里最不可逆的越权；
④ 改完立即生效——服务端在写授权时清掉该角色的缓存，所以不必"重新登录看看生效没有"；停用角色同理（立刻不再给权限，而不是等 token 过期）；
⑤ 防自锁——不允许去掉自己进入本页所依赖的最后一条「角色与授权」权限/菜单，也不允许删掉唯一的管理员角色；这类错误只能靠 SQL 救回来。

深学在线 · 管理端交互原型

工作台

新建收集任务

导入名单

报考范围确认

数据看板

终审

创建导出

新建收集任务

新建收集任务

角色与授权

设计依据 · 桌面端与移动端的分工

01为什么管理端必须做在 PC

02为什么"命名规则试跑"是最重要的一屏

03为什么表头识别要可视化

04为什么"报考范围"只做体检不做更正

05为什么导出要禁用按钮而不是弹警告

06为什么数据看板要标注"来自正式列"

07为什么内置字段要"锁"

08为什么压缩档位要写成"P1 证件照（固定 295×413）"

09为什么内置角色只读、自定义角色才能改