前面几十章是按论证顺序讲的：先讲发生了什么，再讲怎么处理，最后讲值多少。这种讲法适合读，不适合查。一份标书里那句"须提供信息采集、宿舍自选、缴费核验、进度统计的完整功能"，需要的是另一样东西——能逐条勾对、每条都写明边界的清单。
这份清单有四条使用规矩：
- 每一项都写边界。 只写"支持"两个字的答案在验收现场不作数；边界写在哪，责任就划在哪。
- 三档说法贯穿到底。 已经在开学季里跑过的、依赖外部部件接入的、排在后续交付批次里的，分开表述，不混着说。
- 数字只有一个出处。 全书所有数值取自同一张事实基线表，各篇引用，不存在第二处独立取值。
- 定制照实标注。 三十五个任务类型里有两项属于具名外部方的定制，这两项不充作通用能力。
42.1 数据接入
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 导入入口 | 16 个，覆盖新生基础信息、新生其他信息、成员、组织、宿舍、住房设施、缴费、选宿、志愿者、预约、物品、班主任、任务分组、学院绿色通道等 | 十六个入口是分别实现的，不是同一个模板引擎；新增一类数据的进出仍是一次开发工作 |
| 错误回执 | 两套：行号＋原因、仅行号 | 只有行号没有原因的那套仍在部分入口上使用，补齐按批次 |
| 字段映射 | 上游列名与系统字段建立对应关系，换一所学校、换一个数据源，改的是对应关系不是程序 | 映射机制在核心入口经生产检验，尚未覆盖全部十六个入口；部分入口仍按列的先后顺序读表 |
| 值映射 | 性别"男／1／女／0"归成同一个值；民族、行政区划做归一 | 值域强制收敛目前集中在几个高频字段，其余字段的脏值靠进门校验拦 |
| 外部来源直连 | 支持 MySQL、SQL Server、PostgreSQL、Oracle 四类；只允许查询语句并禁分号；连接超时三十秒 | 语句检查是前缀白名单与黑名单式，不做语法级解析；真正的边界在外部账号本身是否为只读授权 |
| 同步与调度 | 可定时调度；人员按唯一编号去重合并，组织按编码去重；多来源按唯一编号分组，主来源定优先 | 去重键是学号与唯一编号，不是证件号；不做跨校名册比对合并 |
| 组织层级推断 | 学院、专业、班级自动归位成层级树（五级组织、九种组织类型） | 名称本身不带层级线索时，仍需人工指定归属 |
这一层真正决定成本的，不是能接多少种数据，是换一所学校要不要改程序。
42.2 源头治理与数据质量
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 进门校验 | 必填、格式、值域、重复四类基础校验，错误行带行号回执 | 校验强度按入口不等，不存在"所有入口同一道闸" |
| 质量规则 | 规则可配，清洗前后的差异可比对，批量清洗走作业队列不阻塞业务 | 规则库由厂商与学校共同维护，学校历史包袱不同，没有一套通用规则能直接套用 |
| 多源冲突裁决 | 身份证号以证件核验结果为准，学号以学籍侧为准，手机号以学生最近一次自填为准 | 冲突处理是逐字段定的优先级，不是通用仲裁机制 |
| 来源标记 | 记录同步与手工两类 | "这一条是谁在哪一天替学校录进来的"这类还原，部分对象尚查不全 |
| 校验不通过之后 | 错误行不入库，整批其余正常导入 | 不存在"先入库再挑错"，也不允许 |
迎新的错九成发生在进门那一刻。进门这一关的强度，决定后面几年的干净程度。
42.3 组织与身份
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 组织树 | 五级组织、九种组织类型（学校／学院／专业／年级／班级／院系／办事机构／身份／企业机构） | 层级靠名称与编码推断，推断不出来时人工指定 |
| 身份体系 | 一个人可挂多种身份：学生、教师、保健教师、家长、其他 | 身份与权限是两层，不是一层——有身份不等于有权限 |
| 一人一条记录 | 一个主键跟到底，考生转新生不换人；名册号与采集号并列显示 | 去重依据是编号，不是姓名与证件号的组合猜测 |
| 志愿者 | 三类服务方向（任务／接站／服务），先被教师认证，才被系统承认 | 教师权限可继承给带队，但没有独立的"带队志愿者"类型 |
| 家长 | 家长是一类独立身份，与家长相关的信息挂在学生记录上 | 家长自己的入口先要定"给他看什么"，这一层判断按批次推进 |
| 多身份人群 | 同一所校园里可并存本科生、研究生、教职工、进修人员等不同人群，靠批次、学生类别、组织节点、任务分组四者区分 | 学位类型、导师这类数据模型不在迎新侧 |
42.4 权限、留痕与导出管控
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 权限链路 | 39 个权限码，四层：角色 → 权限码 → 组织授权 → 数据范围 | 层级到字段级的精细可见性排在后续批次 |
| 数据范围 | 学院端所有接口经统一组织授权范围过滤，无授权记录即空集；普通账号无越权旁路，仅超级管理员可跨范围 | 下级组织递归只在数据大屏一处成立，其余按学院／专业／班级扁平匹配 |
| 操作留痕 | 管理端每一次写操作记人、记时间、记动作，另覆盖四类敏感读取 | 留痕内容是操作本身，不含请求详情与返回结果；师生端的日常办理不进入这张表 |
| 导出 | 全系统 44 个导出端点；走作业队列的导出留痕十二小时 | 导出前的审批与水印排在后续批次 |
| 敏感数据 | 传输全程加密、登录鉴权、定期备份三件齐备 | 字段级加密与序列化层统一脱敏按批次建设，现阶段不要把"密文入库"当成已有能力 |
| 学院只看本院 | 已交付，是账号敢发到院系手里的前提 | 体检数据的行级组织过滤仍按批次与校区为界 |
留痕不是监督，是保护。它真正的作用是让学校敢把权限往下发。
42.5 任务引擎
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 两级模型 | 4 种任务种类 × 35 个任务类型 | 类型全集逐项列在 42.13，含两项外部方定制 |
| 种类与类型的关系 | 多对多：独立选宿既归入学任务也归入报到任务，体检预约同 | 有一个定制类型未登记任何种类 |
| 自定义任务 | 学校自定名称、自定要采集哪些字段，一个批次可挂多个实例 | 自定义任务只解决"要收上来"，不解决"收上来之后谁处理" |
| 时序与依赖 | 可排顺序、设起止时间窗、设必填、设前置任务 | 前置是单链依赖，不支持复杂分支流程 |
| 分组定向 | 批次内分组＋人与组多对多，支持按"唯一编号＋分组名"批量导入名单；生产中有"研究生选宿仅面向某分组开放"的实际用法 | 分组隶属单一批次，跨批次不复用 |
| 到期处理 | 到期后学生端整页拦截，明示"任务已截止"与截止时间，至少六处页面一致 | 是硬拦截不是提醒，这一条对学校也是约束 |
42.6 配置化底座与定制隔离
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 运行配置 | 三层：静态配置文件 → 运行配置表 8 个类别（学校标识、企业微信、人员同步、跨域、安全、学工、移动端、统一登录）→ 业务表 | 学校名称与域名是配置，学校业务规则不是 |
| 敏感配置 | 读取返回掩码，保存时掩码视为未改，缓存十分钟 | 避免配置在页面上明文回显 |
| 界面与品牌 | 主题 25 个可视字段，前端注入 13 个颜色变量，默认学术红；首页轮播、菜单、按批次／学院／任务的单页、站点与资讯位均可配 | 可配的是颜色、图片、名称、入口与显隐，页面结构本身固定 |
| 嵌入学校自有 App | 可隐藏改密与退出入口 | 这两个开关实际存放在运行配置表 |
| 定制的三条路 | 配置项 → 按学校名判断的分支 → 整校专属入口，越靠后越贵 | 按学校名判断的分支涉及 5 所院校名与 1 个运营商名、共 8 处；把这类分支收敛成配置项是既定纪律，不当功能卖点宣传 |
| 功能开关 | 唯一一项是图形验证码开关 | 不存在成体系的功能开关与灰度发布机制 |
42.7 住宿与床位
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 层级模型 | 栋—组团—层—房间—床位，组团为可选标签 | 校区是贯穿宿舍、学生、体检的标注与筛选维度，不是独立的主数据 |
| 资格四道门 | 学院床位池、分组准入、性别过滤、时间窗 | 四道门是并列的，不按权重综合判断 |
| 指定与自选并存 | 学校可先分配再让学生确认，也可完全放开自选 | 两条路都得留，因为学校对"床位谁说了算"的答案并不统一 |
| 预览期 | 预览期看不到"已选"状态 | 避免未开放状态下泄露竞争信息 |
| 设施与台账 | 住房设施可导、可查、可改 | 商品表无库存列，备货与出入库需学校提供 |
| 调宿与走读 | 调宿申请、走读申请（走读追加一组家庭信息字段） | 走读与床位分配之间无互斥校验，靠人工把关 |
| 室友 | 床位数据在报到前就确定，"报到前就知道室友是谁"是官方信息压过野生攻略的凭据 | 匹配只有性别过滤，作息与兴趣匹配按批次建设 |
| 校园地点与路线 | 地点库与路线规划，全景与实拍走外链互补 | 不自建三维校园 |
42.8 并发与批量作业
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 抢床不超卖 | 床位级与人级双层信号量、按序取锁防死锁、存储层唯一性兜底、"已选检查置于人锁内" | 一开学季生产验证：一个学院几千名学生同时在线 |
| 体检预约 | 事务＋号源自增，数千人并发开学季生产验证 | 号源判断与放号节奏由学校规程决定 |
| 批量作业 | 无界队列＋单消费者串行，全程落库（提交人、排队时长、耗时、结果说明、产物文件），页面五秒刷新 | 单消费者意味着串行执行，不是分布式调度 |
| 超时保护 | 批量作业十分钟强制终止 | 大表导入超出十分钟需拆分 |
| 重启自愈 | 一小时内未结束的排队与执行中记录自动置失败并注明原因；每三十分钟清理十二小时前的记录与临时文件 | 服务重启不留"永远执行中"的僵尸作业 |
| 一致性边界 | 进程内锁只在单实例内有效 | 多实例横向扩展下不承诺同类强一致——这既是限制，也是"一校一实例"的理由 |
42.9 消息触达
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 站内消息 | 三张表：消息、收件人、阅读记录；收件人逐人展开，所以"只发给他一个人"成立 | 消息本身不带已读字段 |
| 已读核查 | 资讯、提示、健康通知、任务查看四类载体上可查已读 | 不是所有站内消息都能查已读，这一点必须说清 |
| 自动生成 | 体检预约成功即无条件生成一条个人通知，这是目前唯一一条自动链路 | 生成通知不等于送达，通道是另一件事 |
| 公告 | 可定向、可显隐、可挂任务 | 已读统计只覆盖公告本身这一类载体 |
| 外部通道 | 短信、微信订阅消息、邮件、推送到人，与任务引擎联动的触发设计排在后续批次 | 通道由第三方提供，价格、到达率与备案周期不由本系统承诺 |
| 克制机制 | 频控、静默时段、退订分层随通道一并设计 | 在通道落地前，克制的唯一保障是人工审批 |
42.10 多端与工作台
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 端与页面 | 三端合计 207 页：管理端 108、移动端 73、学院端 26 | 页面数是路由页计数，不含组件文件 |
| 移动端工作台 | 三套：新生、工作人员、志愿者 | 导航按权限拼装，不同人看到的入口不同 |
| 学院端 | 25 项菜单各挂一个权限码，含任务办理、新生检索、未报到新生、各类统计、志愿者、绿色通道、照片核查、新生分班等；首屏是报到率、今日报到、缴费金额、缴费人数四张卡＋近 7 天报到趋势，按批次切换 | 与管理端共用同一套账号，靠权限码与组织授权收敛，没有独立的学院账号体系 |
| 新生自助 | 可自助功能点上限池 94 个，首批工具化约 30 个 | 上限池是能力盘点，不是承诺一次全上 |
| 统一登录 | 对接企业微信、今日校园、金智、东软、钉钉等国内平台 | 具体能接哪一家取决于校方已采购的平台 |
| 接口规模 | 全系统 1057 个接口端点（管理端 842、学院端 55、移动端 160） | 这个数字用于说明覆盖完整度，不用于说明先进性 |
42.11 进度可视与数据大屏
| 能力项 | 现在能做到什么程度 | 边界与依赖 |
|---|
| 大屏 | 1 个统一画布，8 个视角：总览、报到指挥、宿舍、缴费、体检、出行、趋势、竞赛 | 8 个视角不是 8 块屏，切换在同一个画布上完成 |
| 管理端首屏 | 批次切换 → 今日动态（当日办理记录时间轴，取前 20 条，每 30 秒刷新）→ 关键指标五卡 → 学院报到列表（进度条三档变色）→ 最近访问 | 五卡的分子分母口径固定，自定义看板按批次建设 |
| 统计看板 | 一套表三种维度切换（学院／专业／班级）＋四项率＋全校总计行＋导出；近 7 日报到趋势与任务完成趋势两张图；任务完成卡三档（已完成／已浏览未完成／未浏览），点开就是人员名册 | 没有自定义报表与建模工具，指标新增是一次开发 |
| 规则解读 | 大屏上的解读条是八段硬编码阈值判断拼出的中文句，每条都能追问到源数据 | 是规则引擎，不是模型生成的文本 |
| 趋势计算 | 近 7 天、30 天、今日小时分布、按天日趋势 | 环比与同比按批次建设 |
| 口径提醒 | 界面上的"招生数"列实为已导入名册人数 | 系统内没有录取与招生计划数据，这两个数不能混用 |
| 未报到 | 独立页面＋原因多选＋"其他"必填文本，导出含原因 | 原因靠人工回填，系统不自动归类 |
| 预警 | 无阈值配置、无定时告警作业 | "找茬"目前靠人盯着看，到点主动提醒按批次建设 |
42.12 能力之间的咬合
单点能力不构成方案。下面这张表说的是断点——哪一环缺了，前面那一环的投入就白搭。
| 上游 | 下游依赖它做什么 | 断在这里的后果 |
|---|
| 数据接入 | 组织归属、分组定向、权限收窄全都以进门的那份数据为依据 | 同一个性别字段写成三种值，学院分组就漏人，权限就错范围，任务清单推给不该推的人 |
| 任务引擎 | 进度统计、卡点定位、催办全都读任务与办理记录 | 类型与种类没配清楚，"报到率"三个字在三个部门就是三个数 |
| 指标口径 | 大屏、看板、汇报材料共用同一套定义 | 口径不统一，第一次会上就会被推翻，之后所有分析都不再被引用 |
| 并发保护 | 任何"机器替他办一步"的自动化都建立在不错卖之上 | 抢床超卖过一次，后面所有的代办设想都不敢上 |
| 消息触达 | "只给他那一条"的个性化服务要有送达通道 | 定向发放做不到，个性化就退化成全校一样的通知 |
| 操作留痕 | 把账号发到院系与班主任手里的前提 | 不留痕，学工办就不敢授权；不授权，就没人真用系统 |
| 数据分级 | 拿数据去做判断之前，要先知道哪一条能拿去算 | 未分级就拿去分析，是拿学校的名誉去赌概率 |
错的数据不会只错一次，它会在每一个依赖它的判断里再错一次。 全典列的是能力，真正要验收的是这些能力之间有没有缝。
42.13 三十五个任务类型逐项
先说清三个事实，避免这张表被读成"三十五项通用能力"：
- 任务类型全集共 35 项，其中业务项 34 项，另有一项是"无任务相关"的占位项，用于把不挂任务的环节留在同一张表里。
- 编号 8 是空缺的。这不是遗漏，是历次增补留下的痕迹。
- 34 个业务项里有 2 项是具名外部方的定制（湖州职业技术学院的身份验签、武汉移动的手机选号），它们随学校或运营商的合同存在，不作为通用能力对外承诺。
所有类型共用五项配置：名称与说明、起止时间窗、是否必填、前置任务、面向的分组与排除的分组。下表只列各自额外的开关。"归入种类"一列中，入学＝入学任务、报到＝报到任务、活动＝新生活动、学习＝新生学习。
| 编号 | 类型 | 归入种类 | 额外可配置 | 学生侧动作 |
|---|
| 0 | 文字介绍 | 报到 | 挂靠的图文单页、最短阅读时长 | 读一篇文章 |
| 1 | 缴费模式 | 入学 | — | 按缴费方式提交 |
| 2 | 信息采集 | 入学 | 挂一张采集表单 | 填表 |
| 3 | 问卷调查 | 入学 | 挂一张问卷 | 答题 |
| 4 | 宿舍信息 | 入学 | 地图地址、标题、说明、无数据提示语 | 查看分配结果 |
| 5 | 物品预订 | 入学／活动 | 商品分类、是否可多选、领取时间、三种模式（目录／外链／简选）、跳转地址与按钮文案、说明、引导图 | 挑一样或几样 |
| 6 | 来校方式 | 入学 | 是否公开联系方式 | 填行程 |
| 7 | 身份验签 | 入学 | — | 读证件并核验 |
| 9 | 研究生住宿登记 | 入学 | — | 登记是否住宿 |
| 10 | 保险购买 | 入学 | — | 选险种与年限并登记 |
| 11 | 资料学习 | 入学／学习 | 挂一组资料 | 逐条学习 |
| 12 | 考卷考试 | 报到／学习 | 挂一张考卷、是否可看解析 | 答卷 |
| 13 | 学习与考试 | 入学／学习 | 入口指向外部地址（定制项） | 跳转到外部平台学习应考 |
| 14 | 心理评测 | 入学／学习 | 入口指向外部地址 | 跳转到评测页 |
| 15 | 榜样力量 | 入学／学习 | 入口指向外部地址 | 阅读榜样内容 |
| 16 | 手机选号 | 入学／活动 | — | 在号码池里选号并填收件信息 |
| 17 | 存款缴费 | 入学 | — | 按存款缴费方式登记 |
| 18 | 选择宿舍 | 入学 | — | 选房间与床位 |
| 19 | 服装尺寸 | 报到 | — | 填尺码 |
| 20 | 兴趣爱好 | 入学／活动 | — | 填兴趣项 |
| 21 | 住宿或走读选择 | 入学 | — | 二选一，走读追加一组家庭信息 |
| 22 | 照片审核 | 入学 | — | 上传照片并等待核查 |
| 23 | 身份验签（湖州职业技术学院） | 未登记种类 | 整校专属入口（定制项） | 按该校指定链路核验 |
| 24 | 信息确认 | 报到 | 挂一张采集表单，已给值为只读 | 确认而不是重填 |
| 25 | 手机选号（武汉移动） | 入学 | 运营商侧下单分支（定制项） | 选号并下单 |
| 26 | 班级信息查看 | 报到 | — | 查看所属班级 |
| 27 | 独立选宿 | 入学／报到 | — | 在开放池内自选床位 |
| 100 | 新生报到 | 报到 | — | 到场核验，记入办理日志 |
| 101 | 一卡通 | 报到 | — | 办理或领取，留办理记录 |
| 102 | 绿色通道 | 入学 | 是否需要审批 | 提交缓缴与资助材料 |
| 103 | 体检预约 | 入学／报到 | — | 预约时段或查询结果 |
| 104 | 自定义任务 | 入学 | 学校自定名称与采集字段，一个批次可挂多个实例 | 按学校自定义动作 |
| 105 | 健康信息填报 | 入学 | — | 填健康信息 |
| 106 | 宿舍钥匙领取 | 报到 | — | 领取，留办理记录 |
| 200 | 无任务相关 | — | — | 占位项，不面向学生 |
三张补充说明：
- 每一项的办理结果都落同一张记录表：批次、任务、学生、办理人、结果、时间、备注、扩展数据。这张表是进度统计、卡点定位、未报到名单、催办清单的唯一数据来源。
- 这张表里没有"会算的东西"。 三十五个类型解决的是"学校能把什么事交给学生自己办"，不解决"办完之后谁来处理异常"。异常处理在第二十八、二十九章与后续批次里。
- 两个定制项单列出来，是为了说清一件事： 一所学校的特殊流程不应当变成所有人版本里的分支。能收敛成配置项的尽快收敛，收敛不了的留在专属入口，不污染主干。
42.14 人员与办理状态导出
系统能带走的，是"人"和"人办到哪一步"这两类东西。
| 导出对象 | 内容 | 形态 |
|---|
| 新生名册 | 按批次导出全部采集字段 | 字段模板由采集字典动态列举 |
| 任务完成与未完成 | 已完成人员、未完成人员（后者双表） | 同上 |
| 参与度 | 已完成、已浏览未完成、未浏览三档，含唯一编号、姓名、任务、时间 | 点开就是名单，可导出 |
| 宿舍与选宿 | 分配结果、选宿结果 | 同步或异步 |
| 体检 | 预约情况、体检表格 | 走作业队列并留痕 |
| 来校与接站 | 行程、到站时刻、是否接站 | 可作为接站依据表 |
| 未报到新生 | 含未报到原因，原因支持多选与"其他"必填文本 | 走作业队列，导出前二次确认 |
| 缴费与财务 | 应缴、实缴、减免，含绿色通道与贷款信息 | 按批次与学院 |
| 日志 | 操作日志、核验日志 | 供学校自查与归档 |
三点如实说明：
- 字段跟着学校走。 学校加一列采集项，导出的表就多一列，不需要改程序——这是采集字典动态列举带来的直接好处。
- 异步导出的文件与留痕在十二小时后清理。 需要长期存档的学校，要在导出的那一刻自己留一份，不要把系统当成归档库。
- 上级平台的学籍电子注册表结构上报不在当前版本之内。 这套系统做的是"按批次与任务字段导出人员和办理状态"，把导出的表填进上级的注册格式，仍然是学校侧的行政工作。这一句先说在前面，免得学校在上报前一周才发现缺这一段。
交付的终点不是上线，是有人每天看数据；看数据的起点，是这些数据能被带走。