Article
2026-03-02-校招
蚂蚁集团-人事板块
校招系统研发阶段总结（招聘域 · 2023）
阶段性质：业务驱动的功能改造 + 局部结构演进
设计含量集中在规则抽象与数据模型重构。
一、阶段整体说明
该阶段主要支撑 2024 届秋招系统迭代，工作内容以：
- 功能增强
- 批量能力建设
- 局部数据结构调整
- 自动化规则抽象
为主。
不是架构主导型建设，而是在既有系统框架下进行结构优化与能力增强。
二、主要工作模块
1️⃣ 简历自动分配规则引擎（核心设计模块）
这是本阶段设计含量最高的模块。
1.1 背景问题
- 简历量集中爆发
- 招聘同学规则差异化明显
- 部门存在层级关系
- 人工分配效率低
需要实现：
- 规则配置化
- 自动批量执行
- 部门层级覆盖机制
- 冲突可控
1.2 系统分层结构
整体分为三层：
- 条件转换层（DSL 抽象）
- 调度控制层（规则治理）
- 执行层（动作执行器）
1.3 条件转换层
将业务侧配置的筛选条件转化为结构化 DSL 表达：
- 字段
- 操作符
- 条件值集合
- 逻辑连接关系
不直接拼接 SQL，不依赖语义推理。
系统只基于“结构表达”判断条件范围关系。
例如：
父部门规则：
- 学校类型 ∈ {A, B}
子部门规则：
- 学校类型 ∈ {A}
通过集合包含关系判断： 子部门规则范围更小。
系统无法理解语义子集关系，只能判断显式集合包含。
1.4 调度控制层（核心难点）
该层负责：
- 规则排序（按部门层级 + 优先级）
- 范围裁剪
- 冲突判断
- 批量执行调度
规则关系分为：
（1）范围独立 → 正常执行
（2）范围包含且动作一致
执行逻辑：
- 先执行子部门规则
- 父部门规则自动剔除已覆盖范围
- 对剩余范围执行
（3）范围交叉且动作冲突
定义为冲突规则：
- 同阶段
- 条件交叉
- 动作不同
此类规则在配置阶段进行阻断。
1.5 执行层设计
采用注册式执行模型：
- 动作枚举
- 执行器接口
- 执行器注册表
支持：
- 主动作
- 子动作组合
新增动作时：
- 新增枚举与执行器
- 无需改动调度逻辑
实现了调度层与执行层解耦。
1.6 数据模型设计
核心表结构包括：
- 策略表 —— 定义规则主体
- 策略条件表 —— 结构化存储 DSL 条件
- 字段定义表 —— 限定规则语言能力边界
- 动作定义表 —— 抽象业务行为
- 策略动作关联表 —— 支持主/子动作绑定
设计目的：
- 避免规则字符串化存储
- 支持冲突检测
- 支持扩展动作
- 保证规则可治理
2️⃣ 面试排期模型重构（数据结构改造型项目）
这是本阶段第二个有结构意义的改造。
2.1 原模型
每一轮面试只对应一个面试实例：round → interview
不支持同一轮多面试并行。
2.2 改造后模型
引入“面试组”概念：round → interview_group → interview
实现：
- 同一轮可包含多个面试
- 支持批量排期
- 支持资源组级别管理
2.3 改造影响范围
数据模型变更后，引发链式改造：
- 面试资源分配逻辑
- 冲突校验逻辑
- 流程推进逻辑
- 批量排期接口
- 状态同步机制
该改造属于：
数据结构演进带来的全链路适配改造。
3️⃣ 面试间双来源适配
在面试间场景中：
- 需要兼容校招与社招两种来源
- 根据业务来源分流读写路径
- 调用不同实现
属于多来源分流适配，而非系统整合。
4️⃣ AntStar 流程改造与数据脱敏
基于既有流程引擎：
- 增加校招分支判断
- 调整节点流转逻辑
- 实现按角色字段脱敏
属于功能增强型改造，不涉及流程模型重构。
三、阶段总结
这一阶段的核心能力提升体现在：
- 第一次完整设计规则抽象系统
- 理解组织层级对规则系统复杂度的影响
- 体验数据模型重构对全链路的冲击
- 学会在批处理模型下控制执行边界
这是一个：
- 从功能开发走向结构思考的阶段
- 规则抽象能力开始成型的阶段