- 公办本科迎新难点在参与部门多，不在招生量大
- 学院端须是独立工作台，按组织授权过滤数据范围
- 进度要分环节统计，不能只有一条总完成率
- 字段标准库是数据治理起点，价值远超迎新本身
- 留学生迎新当前仅支持身份证体系，需单独立项
普通本科 1278 所（含独立学院 149 所），校均年招生约 3941 人（同一份公报口径）。这个数字对公办本科其实偏小——头部与省属重点院校的年新生往往是这个数的数倍，综合性大学还会叠上研究生与留学生。
所以这一类的真问题从来不是"量大"，是**"参与的人多"**。
34.1 画像：三个特征
特征一：生源分散。 面向全国几十个省份招生，生源地、民族、科类、资助比例全部散开。这带来两个具体要求：一是数据维度要多（按省份、按民族、按学院、按科类都能出数，这些统计在系统里都是现成的分组口径）；二是行程与到校时间高度分散——录取时间不同、报到批次可能分几天、有的专业还要提前军训。
特征二：院系自主。 二十多个学院，各自有辅导员队伍、各自搞迎新活动、各自要求"我们学院的流程不一样"。这不是管理松散，是办学层级的正常状态。 它逼出的需求很明确：院系必须有自己的入口和自己的数，否则学工处会变成全部数据的转录站——所有通知经过它转、所有名单由它导出，最后它成为唯一的瓶颈。
特征三：多套系统并存，且都不肯让。 学工、教务、研究生、财务、一卡通、宿管、人事、图信、校医院，各有一套。有的买了十几年，有的自建过三轮。这一类学校买迎新系统时最常见的原话是："我们不替换任何现有系统，我们只要把迎新这一年办顺。"
这一句要当验收标准看。 它意味着三件事：数据要能抽进来（外部来源支持四类主流数据源，字段与值都可映射，可按唯一编号归并）、要能推出去（导出与对接清单是可交付项）、身份要能合上（统一登录要接得进去——企业微信、今日校园、金智、东软、钉钉这几类主流平台在系统里是有对接形态的）。
34.2 内部分野：综合、理工、应用型，要的东西不一样
综合性大学。 学科跨度大、单位多、留学生与研究生体量不小，往往还有医学院。它真正的难度在数据治理，不在流程——各单位的"学院""专业""班级"定义不一致，年级与学制的对应也不同。对这一类，字段标准库的价值高于一切功能：先把"学生唯一编号怎么定、学院用什么编码、民族和生源地用哪套值域"这些定下来，迎新只是第一个用它的项目。
需要如实说明的一处边界：留学生迎新当前不在这套系统的范围内——内置证件只有身份证，没有面向护照或其他证件的类别与校验，也没有单独的来华留学流程。留学生规模明显的综合性大学，这一条要在选型阶段就问清楚，不要到实施时才发现要二次开发。
理工类院校。 本科生规模稳定、学院之间流程相似，反而最容易标准化。它常见的额外诉求是分校区与大类分流：大一在基础部、二年级进学院。系统对这一类的适配点是"分组定向开放任务"——同一个批次里，可以给不同人群配不同的任务集合与开放时间，分组名单支持按唯一编号批量导入。这件事的实用价值是：分流前后两套流程能在同一个批次里跑完，不用为一年开两个系统。
应用型本科。 多为新建或升本院校，组织在长、流程在定。它的诉求是"跟着学校一起长大"——每年新加学院、新加任务、新加收费项，改起来不能每次都提需求。这类学校最该看的一条，是第三十九章那笔"代差账"：配置化交付与定制开发，三年后的成本差会拉得很开。
34.3 适配：三件必须做实的事
第一件：学院端二级自助。
院系拿到的是一个独立的工作台，不是管理端的一个筛选器。 登录后第一眼是本学院的报到率、今日报到、缴费金额与人数四张卡，加一条近七天的报到趋势；往下是各自带权限的二十多项业务入口——任务办理、新生检索、未报到新生、缴费与押金、任务与报到统计、绿色通道、照片核查、体检与宿舍统计、新生分班、志愿者、核查日志。
它安全的前提在实现层：所有学院端接口统一按组织授权过滤数据范围（授权记录是"人—批次—组织"三元关系，没有授权就是空集），普通账号没有越权旁路，只有超级管理员可以跨范围。这一点很重要——院系愿意用，是因为它拿不到别人的数据；学工处敢放，是因为放出去也不会失控。
一处真实差异要提醒：学院端与管理端共用同一套账号体系，院系入口靠权限码与组织授权收敛，不是另建一套用户库。如果学校要求"学院有完全独立的账号库"，那是新需求，不是现有形态。
第二件：环节级进度，不是一条总百分比。
公办本科的汇报层级多，每个部门问的问题都不是"报到率多少"，而是"卡在哪一环"：资助处问缓缴批了多少，宿管问有多少人没确认住宿，财务问到账金额，学院问自己学院哪几个班还没动。这要求每一环都有独立的可统计状态——任务完成记录是分环节的，进度才能分环节出。一个只有总完成率的系统，在综合性大学里撑不过第一次汇报。
第三件：字段标准库，把它当成一次治理机会。
这是公办本科最该做、也最容易被当成"实施细节"跳掉的一步。 具体要定四样：唯一编号规则、组织编码规则、值域口径（性别、民族、生源地、政治面貌各按哪套标准取值）、权威源归属（每一项以哪个系统为准）。
定完之后会有三个立刻的收益：接外部数据时映射一次配好、以后年年能用；导出给上级或财务时口径不再打架；学校第一次拥有一份"我们自己统一过的学生字段定义"。 这份东西的价值远超迎新——它会在之后每一次跨部门数据协作里被要第二次。
34.4 这一类学校最该问的四个问题
"学院端的账号能不能直接发到辅导员手里，他们能看到的数据边界由什么决定？"——考的是行级范围控制是不是真在实现层，而不是靠前端隐藏菜单。
"我们的名册从教务下来、缴费在财务、宿舍在宿管，最后要能对上同一张表——怎么对？"——这一问是公办本科的核心问题。答不出归并键与对账口径的，说明没做过真实的多系统并存。
"留学生怎么办？"——直接问边界。诚实的答案应该是"当前版本只支持身份证体系，留学生需要单独立项或走别的系统"。绕开这一问的供应商，在别的问上也不会给你准话。
"我们要一份统一的学生字段定义，你们能提供什么？"——这一问问的不是功能，是方法论。 能拿出字段标准与值域参考的，才是把数据治理当回事的团队。