招聘管理整体设计方案

文档说明

• 生成日期：2026-04-17
• 适用范围：ruoyi-office 人力资源模块招聘管理功能整体设计
• 文档用途：作为招聘管理一期建设蓝图，用于指导后续后端、PC 端、UniApp 移动端、BPM 流程与菜单权限的统一实现

设计目标：在现有人力模块已具备组织架构、人事档案、人事异动、考勤、假期的基础上，补齐招聘管理能力，并形成“招聘需求 -> 职位执行 -> 候选人推进 -> 录用审批 -> 入职建档 -> 后续 HRM 使用”的业务闭环。

一、产品定位与设计原则

1.1 产品定位

本产品定位不是独立 ATS 工具，而是企业一体化 HRM 平台中的招聘子域。因此招聘设计必须服务于以下目标：

1. 与组织架构、员工档案、人事异动、考勤假期等模块天然打通。
2. 以内部流程协同、组织管理与业务闭环为优先，而不是以外部渠道生态深度集成为优先。
3. 兼顾通用性与后续扩展性，既能支持标准招聘流程，也能为后续校招、内推、猎头协同、人才库激活预留扩展空间。

1.2 设计原则

1. 复用优先：复用现有 HRM + BPM + 附件 + 入职建档 + 移动审批 架构，不另起招聘专用框架。
2. 闭环优先：一期先做标准闭环，保证从需求到入职的链路跑通。
3. 流程与状态分治：审批决策节点使用 BPM；高频业务推进节点采用状态机，避免流程泛化。
4. 主数据统一：组织、部门、字典、附件、用户、员工档案都使用现有平台能力。
5. PC 主操作、移动端补协同：一期复杂录入、配置和批量处理以 PC 为主，移动端支持核心发起、查看、审批。

二、一二期边界划分

2.1 一期范围

一期按标准招聘闭环建设，包含以下能力：

• 招聘需求申请与审批
• 招聘职位管理
• 候选人/简历中心
• 候选人投递与阶段推进
• 多轮面试记录与结论沉淀
• 录用审批单
• 录用通过后生成入职申请单
• 与员工档案建档链路打通
• PC 菜单、权限、基础统计视图
• UniApp 的核心发起、查看、审批

2.2 二期范围

二期作为增强能力扩展：

• 人才库激活与运营
• 内推管理
• 猎头协同与猎头费用管理
• 校招批量场景
• 渠道自动对接
• AI 简历解析、AI 面试纪要、AI 推荐
• 招聘 BI 大屏、渠道 ROI、招聘质量分析

2.3 一期明确不做

为保证一期交付聚焦，以下内容不纳入一期：

• 直接对接第三方招聘网站的账号抓取与发布
• 在线测评、背调、体检等外部生态深度集成
• 从招聘模块直接建员工档案
• 将每个招聘阶段都建成 BPM 流程

三、业务总体蓝图

3.1 核心闭环说明

1. 用人部门先提交招聘需求单并完成审批。
2. 审批通过后，招聘专员基于需求单创建招聘职位。
3. 候选人进入候选人中心，并与目标职位建立投递关系。
4. 招聘推进过程中沉淀筛选、面试、评价、淘汰原因等信息。
5. 对拟录用候选人发起录用审批单。
6. 录用通过后，系统生成 HRM 入职申请单。
7. 入职申请单审批通过后，沿用现有 HRM 链路创建员工档案。

四、领域模型设计

4.1 模块划分

招聘管理建议拆分为五个子域：

1. 招聘需求域：管理编制申请、招聘预算、岗位要求、审批流。
2. 招聘执行域：管理职位、招聘负责人、渠道、职位状态、招聘进度。
3. 候选人域：管理候选人主档、简历、标签、来源、历史应聘记录。
4. 面试评估域：管理面试轮次、面试官、评分、结论、淘汰原因。
5. 录用入职域：管理录用审批、待入职、入职申请单映射。

4.2 主数据与配置类

以下对象建议采用普通 CRUD 管理：

• 招聘渠道
• 招聘紧急度
• 招聘职位类别
• 职级/岗位序列引用
• 面试结论
• 淘汰原因
• 人才标签
• 面试评价模板

其中：

• 通用枚举优先走系统字典
• 面试评价模板和评价维度建议独立表，不建议全部字典化

4.3 BPM 单据类

一期建议只新增两个核心 BPM 单据：

1. HRM_RECRUITMENT_REQUIREMENT_BILL

   • 单据编码建议：207
   • 流程定义 Key：hr_recruitment_requirement_bill
   • 作用：规范招聘入口，完成编制与需求审批

2. HRM_RECRUITMENT_OFFER_BILL

   • 单据编码建议：208
   • 流程定义 Key：hr_recruitment_offer_bill
   • 作用：规范录用审批、薪资口径、入职准备口径

说明：

• 招聘职位本身不建议设计为 BPM 单据
• 面试安排、筛选、阶段推进不建议 BPM 化
• 这样可以兼顾规范性与执行效率

4.4 核心业务实体

4.4.1 招聘需求单

建议命名：RecruitmentRequirementBill

职责：

• 明确用人部门的编制申请
• 记录岗位名称、需求人数、期望到岗日期、任职条件、预算说明
• 审批通过后成为职位创建的上游来源

4.4.2 招聘职位

建议命名：RecruitmentPosition

职责：

• 归属招聘需求单
• 管理招聘执行信息
• 记录开放状态、招聘负责人、渠道范围、当前在招人数

4.4.3 候选人主档

建议命名：RecruitmentCandidate

职责：

• 作为候选人全局主档
• 管理身份信息、联系方式、来源、意向岗位、标签
• 统一承接候选人附件

4.4.4 候选人投递关系

建议命名：RecruitmentApplication

职责：

• 记录候选人与某一职位的具体应聘关系
• 保存当前阶段、推进时间、负责人、淘汰原因
• 同一候选人可对应多个投递关系

4.4.5 面试记录

建议命名：RecruitmentInterviewRecord

职责：

• 记录每轮面试安排、面试官、时间、方式、评分、结论、评语
• 支持多轮面试
• 支持结构化评分模板

4.4.6 录用审批单

建议命名：RecruitmentOfferBill

职责：

• 记录拟录用人员、部门、岗位、职级、试用期、计划入职日、薪资口径
• 审批通过后进入待入职状态
• 驱动入职单生成

4.4.7 人才库记录

建议命名：RecruitmentTalentPoolRecord

职责：

• 保存未录用但建议保留的候选人
• 一期先支持沉淀和检索
• 二期再做激活运营

五、数据模型建议

5.1 表结构总原则

1. BPM 单据主表遵循现有 HRM 流程单据规范。
2. 单据表统一带 bill_code、process_instance_id、process_status、公司/部门字段、creator_name、remark。
3. 复杂附件统一走 AttachmentService，不在主表中存 URL 字符串。
4. 一对多明细统一采用独立子表。
5. 组织、字典、员工、流程都复用现有平台基础能力。

5.2 建议核心表

5.2.1 hrm_recruitment_requirement_bill

用途：招聘需求申请单主表。

关键字段建议：

• bill_code
• process_instance_id
• process_status
• company_id / company_name
• dept_id / dept_name
• position_name
• position_category
• headcount
• urgency_level
• expected_arrival_date
• employment_type
• job_description
• qualification_requirements
• salary_budget_desc
• creator_name
• remark

5.2.2 hrm_recruitment_position

用途：招聘职位执行主表。

关键字段建议：

• requirement_bill_id
• position_code
• position_name
• position_category
• dept_id / dept_name
• headcount
• headcount_open
• headcount_filled
• recruiter_user_id
• recruiter_user_name
• status
• publish_status
• channel_scope
• close_reason

5.2.3 hrm_recruitment_candidate

用途：候选人主档。

关键字段建议：

• candidate_code
• name
• gender
• mobile
• email
• id_card_no
• birthday
• highest_education
• graduation_school
• graduation_major
• work_years
• current_city
• source_type
• source_channel
• current_company
• current_position
• expected_city
• expected_salary_desc
• status
• talent_pool_status
• latest_resume_attachment_count

说明：

• 该表负责候选人唯一性识别
• 建议对 mobile + email + id_card_no 建去重策略

5.2.4 hrm_recruitment_application

用途：候选人应聘职位关系表。

关键字段建议：

• candidate_id
• position_id
• requirement_bill_id
• apply_source
• apply_date
• current_stage
• stage_status
• owner_user_id
• owner_user_name
• recommended_entry_date
• 淘汰原因
• 淘汰备注
• is_talent_pool

说明：

• 同一候选人可以投递多个职位
• 阶段推进应落在该表，而不是候选人主档

5.2.5 hrm_recruitment_interview_record

用途：面试记录主表。

关键字段建议：

• application_id
• candidate_id
• position_id
• round_no
• interview_type
• interview_time
• interview_method
• interview_result
• score_total
• summary
• suggestion

5.2.6 hrm_recruitment_interview_evaluator

用途：一轮面试的面试官及评分明细。

关键字段建议：

• interview_record_id
• interviewer_user_id
• interviewer_user_name
• dimension_name
• score
• comment

5.2.7 hrm_recruitment_offer_bill

用途：录用审批单主表。

关键字段建议：

• bill_code
• process_instance_id
• process_status
• candidate_id
• application_id
• position_id
• company_id / company_name
• dept_id / dept_name
• position_name
• job_post
• job_position
• grade_level
• probation_months
• plan_entry_date
• salary_plan_ref
• salary_desc
• report_to_user_id
• report_to_user_name
• creator_name
• remark

5.2.8 hrm_recruitment_assessment_template

用途：面试评价模板主表。

关键字段建议：

• name
• position_category
• status
• remark

5.2.9 hrm_recruitment_assessment_dimension

用途：评价模板维度子表。

关键字段建议：

• template_id
• dimension_name
• weight
• sort

5.3 与附件系统的关系

附件不建议单独建招聘业务文件表，统一通过 AttachmentService 关联：

• 候选人简历
• 证书附件
• 作品集
• 面试材料
• 录用函

推荐的业务归属方式：

• 候选人类附件：以 candidateId 作为业务主键
• 单据类附件：按 HrmBillTypeEnum 的 typeCode + 单据 ID 存储

六、状态机设计

6.1 招聘需求单状态

• 草稿
• 审批中
• 审批通过
• 审批拒绝
• 已取消
• 已转执行

说明：

• process_status 负责 BPM 状态
• 业务状态可通过是否已创建职位来判断是否“已转执行”

6.2 招聘职位状态

• 待发布
• 招聘中
• 暂停中
• 已招满
• 已关闭

6.3 候选人投递阶段

建议统一阶段字典：

• 待筛选
• 初筛通过
• 初筛淘汰
• 待一面
• 一面通过
• 一面淘汰
• 待二面
• 二面通过
• 二面淘汰
• 待录用审批
• 录用审批中
• 录用通过
• 录用拒绝
• 待入职
• 已入职
• 已入人才库

说明：

• 一期不要把所有阶段拆成独立流程
• 通过投递关系表进行推进即可

6.4 录用审批单状态

• 草稿
• 审批中
• 审批通过
• 审批拒绝
• 已取消
• 已生成入职单

七、BPM 设计方案

7.1 单据一：招聘需求单

流程定位

用于控制招聘入口的合规性，解决“谁提需求、为什么招、招几人、预算是否合理”的问题。

建议流程角色

1. 发起人：用人部门负责人或用人部门指定人员
2. HRBP：校验岗位合理性、编制合理性
3. HR 负责人：确认招聘策略与优先级
4. 分管领导：必要时审批预算或关键岗位需求

字段权限建议

• 发起节点：可编辑全部业务字段
• HRBP 节点：可编辑补充说明、招聘负责人建议、渠道建议
• 领导节点：只读为主

7.2 单据二：录用审批单

流程定位

用于控制录用口径、用工条件、薪资口径、计划入职时间，避免候选人录用信息脱离 HRM 主数据体系。

建议流程角色

1. 发起人：招聘专员或招聘负责人
2. 用人部门负责人：确认人选匹配度
3. HR 负责人：确认录用与组织归属
4. 薪资审批角色：当薪资超阈值时介入
5. 分管领导：关键岗位或高职级场景审批

字段权限建议

• 发起节点：可编辑候选人信息、岗位归属、职级、试用期、计划入职日、薪资口径
• 部门负责人节点：只读为主，可补充意见
• HR 节点：可调整入职相关字段
• 薪资节点：仅开放薪资相关字段

7.3 流程技术实现建议

按照现有 HRM 规范接入：

• 在 HrmBillTypeEnum 中新增单据类型
• Service 实现 FlowBillService
• 使用 BillCodeUtils.generateBillCode(SystemEnum.HRM, ...)
• 使用 BpmProcessVariableUtils.buildBillVariables(...)
• 使用字段权限动态控制模式
• 使用 BasicForm 作为 PC 端流程单据详情容器

7.4 不建议 BPM 化的业务

以下业务建议使用状态推进，而不是 BPM：

• 简历录入
• 候选人标签维护
• 候选人转阶段
• 面试安排与面试评价
• 人才库沉淀

原因：

• 这类操作频次高、推进快、参与角色多变
• 如果全部 BPM 化，会显著增加流程定义复杂度和实际操作成本

八、与现有 HRM 的打通设计

8.1 与组织架构打通

全部招聘业务必须基于现有部门树和公司体系：

• 招聘需求单：绑定提报部门与公司
• 招聘职位：绑定招聘岗位所属部门
• 录用审批单：绑定拟入职公司与部门
• 后续入职单：直接复用部门和公司信息

实现原则：

• PC 端复用当前用户公司部门树
• 后端复用 DeptApi
• 不维护独立“招聘组织树”

8.2 与员工档案和入职单打通

这是招聘模块闭环设计的关键。

核心原则

录用审批通过后，不直接创建员工档案，而是自动生成 HRM 入职申请单，继续走现有入职链路。

原因

1. 现有 HRM 已实现完整的“入职单 -> 审批 -> 建档案”能力。
2. 直接建档会产生双路径建人，导致后续异动、考勤、假期的数据口径混乱。
3. 候选人信息和正式员工信息的审核口径不完全一致，需要由入职单做最后确认。

字段映射建议

候选人到入职单建议至少映射以下字段：

• 候选人姓名 -> 入职单姓名
• 手机号 -> 入职单手机号
• 邮箱 -> 入职单邮箱
• 身份证号 -> 入职单身份证号
• 性别 -> 入职单性别
• 生日 -> 入职单生日
• 最高学历 -> 入职单学历
• 毕业院校 -> 入职单毕业院校
• 专业 -> 入职单专业
• 职位名称 -> 入职单职位
• 职务/岗位序列 -> 入职单职务/岗位
• 计划入职日期 -> 入职日期
• 工作经历 -> 入职单工作经历子表
• 教育经历 -> 入职单教育经历子表
• 简历与证明材料 -> 入职单附件

8.3 与附件系统打通

所有招聘附件必须统一通过 AttachmentService 管理。

禁止做法：

• 在主表中维护 resumeUrl
• 在主表中维护 JSON 附件字符串
• 在页面中直接使用 FileUpload 替代业务附件组件

推荐做法：

• PC 端使用 AttachmentList
• BPM 单据附件按 typeCode 归档
• 候选人附件按业务对象归档

8.4 与 BPM 通知链路打通

招聘需求单和录用审批单都应复用现有 HRM 的通知和流程回写机制：

• 本地监听
• Feign 回调
• MQ 消费

这样可保证：

• 审批状态自动回写
• 单据状态统一管理
• 移动端审批详情可正常识别业务表单

8.5 与薪酬绩效预留打通点

一期不进入薪酬、绩效业务闭环，但应预留以下字段：

• 职级
• 岗位序列
• 试用期
• 薪资方案引用
• 汇报对象
• 绩效考核对象标识

这些字段未来可直接供薪酬和绩效模块复用。

九、前后端落位建议

9.1 后端目录建议

全部落在 yudao-module-hrm：

• controller/admin/recruitment/
• service/recruitment/
• dal/dataobject/recruitment/
• dal/mysql/recruitment/

推荐的接口子域：

• requirement
• position
• candidate
• interview
• offer
• config

9.2 PC 端目录建议

API 建议：

• src/api/hrm/recruitment-requirement/index.ts
• src/api/hrm/recruitment-position/index.ts
• src/api/hrm/recruitment-candidate/index.ts
• src/api/hrm/recruitment-interview/index.ts
• src/api/hrm/recruitment-offer/index.ts

页面建议：

• src/views/hrm/recruitment/requirement/list/index.vue
• src/views/hrm/recruitment/requirement/info/index.vue
• src/views/hrm/recruitment/position/list/index.vue
• src/views/hrm/recruitment/position/info/index.vue
• src/views/hrm/recruitment/candidate/list/index.vue
• src/views/hrm/recruitment/candidate/info/index.vue
• src/views/hrm/recruitment/offer/list/index.vue
• src/views/hrm/recruitment/offer/info/index.vue

页面模式建议：

• 需求单、录用单：list/info + BasicForm + BPM
• 职位、候选人：list/info 独立页
• 简单配置：index + modal

9.3 移动端目录建议

一期建议先支持：

• src/pages-hrm/recruitment-requirement/create/index.vue
• src/pages-hrm/recruitment-requirement/detail/index.vue
• src/pages-hrm/recruitment-offer/create/index.vue
• src/pages-hrm/recruitment-offer/detail/index.vue
• src/pages-hrm/recruitment-candidate/detail/index.vue

移动端定位：

• 我的需求单
• 我的录用单
• 审批详情
• 候选人核心查看

9.4 BPM 菜单配置建议

在移动端 BPM 配置中新增：

• processDefinitionKey = hr_recruitment_requirement_bill

• mobileCreatePath = /pages-hrm/recruitment-requirement/create/index

• mobileViewComponent = RecruitmentRequirementDetail

• processDefinitionKey = hr_recruitment_offer_bill

• mobileCreatePath = /pages-hrm/recruitment-offer/create/index

• mobileViewComponent = RecruitmentOfferDetail

十、菜单、权限与字典建议

10.1 菜单建议

建议在人力资源模块下新增“招聘管理”目录，并包含：

• 招聘需求
• 招聘职位
• 候选人中心
• 录用审批

二期再扩展：

• 人才库
• 招聘统计
• 招聘配置

10.2 权限建议

建议权限前缀统一为 hrm:recruitment-*，例如：

• hrm:recruitment-requirement:create
• hrm:recruitment-requirement:submit
• hrm:recruitment-position:update
• hrm:recruitment-candidate:update
• hrm:recruitment-offer:submit

10.3 字典建议

建议新增字典：

• hrm_recruitment_channel
• hrm_recruitment_urgency_level
• hrm_recruitment_position_category
• hrm_recruitment_interview_result
• hrm_recruitment_elimination_reason
• hrm_recruitment_application_stage

十一、实施路径

阶段一：基础建设

目标：完成入口与主数据打底。

交付内容：

• 招聘字典和配置
• 招聘需求单
• 招聘职位管理
• 菜单和权限

阶段二：招聘主链路

目标：完成招聘执行核心链路。

交付内容：

• 候选人主档
• 候选人投递关系
• 面试记录
• 阶段推进
• 录用审批单

阶段三：HRM 闭环打通

目标：完成录用到入职建档的闭环。

交付内容：

• 录用审批通过生成入职单
• 候选人到入职单字段映射
• 移动端需求单/录用单支持
• 招聘漏斗和基础统计

十二、一期验收标准

满足以下条件，可视为一期招聘管理闭环成立：

1. 用人部门可发起招聘需求单并完成审批。
2. 审批通过的需求可创建招聘职位。
3. 候选人可录入并与职位建立投递关系。
4. 候选人可完成筛选、面试、录用推进。
5. 录用需经过审批，而不是仅修改状态。
6. 录用通过后可一键生成入职申请单。
7. 入职申请单审批通过后可按现有链路生成员工档案。
8. 移动端可完成需求单和录用单的核心发起、查看、审批。

十三、总结

本方案的核心不是“做一个单独的招聘系统”，而是在现有人力资源体系中补齐招聘子域，并通过“需求审批 + 执行推进 + 录用审批 + 入职建档”打通前后链路。

这样设计有三点价值：

1. 业务闭环清晰，避免招聘与 HRM 主数据割裂。
2. 技术实现可复用现有 HRM/BPM/附件/移动端模式，落地成本可控。
3. 一期可快速交付，二期又保留足够的扩展空间。