docs: 新增招聘系统需求说明(基于HR访谈原文)

docs/requirements_from_interview.md

+# 招聘系统需求说明
+
+> 本文档由《原文_招聘系统功能盘点与AI评估规则讨论.pdf》(20 页 HR 与研发访谈转写)整理而来,并结合当前系统实际能力标注了"现有/缺失"状态。格式:每项需求先给出 HR 原话要点,再给出需求描述与实现建议;标注「✅ 已有」「🔄 部分」「🆕 新增」。
+>
+> 依据代码现状核实:`backend/app/services/llm.py`(AI 评估/脱敏)、`backend/app/repositories/state_repository.py`(整包状态)、`vue-app/src/utils/normalize.js`(候选人/岗位字段)、`backend/app/models.py`(表结构)、`browser-extension/`(采集插件)。
+
+---
+
+## 一、总体目标与流程主线
+
+**核心诉求**:招聘流程从「用人部门发起需求 → 岗位自动进入系统 → 发布 → 收简历 → 初筛/面试 → Offer → 入职材料」全链路跑通,各模块联动,减少手工维护。
+
+HR 原话要点:
+
+- 「假设企微智能体建完以后,用人部门发起需求,岗位自动弹到这边来」(P1)
+- 「先做人才库,简历库主要用来存简历;我面完了没过的就放人才池」(P19)
+- 「他所有的下推逻辑是要绑定的…我做完以后发现他有些板块不会同步,代办里面也不新增」(P19)——**下推联动是全局痛点**
+- 开发方式:「基于你现在弄的那个系统,按模块(简历库/岗位管理)逐个完善」(P20)
+
+**结论**:延续现有系统架构(整包状态 + 前后端分离),按模块迭代,优先补齐「下推联动」。
+
+---
+
+## 二、多用户与岗位流转(现有 ✅)
+
+**需求 1:多招聘账号 + 总库**
+- 原话:「我们两个的账号要隔离开,他的候选人在他系统里,我的候选人在我系统里,但公司还会有一个总库」(P1)
+- 现状:✅ 多用户登录 + 按用户隔离工作区已实现(`owner_id`),admin 可切换工作区。**「总库」尚未实现**——普通用户只能看自己工作区,没有"所有人可见的共享池"。
+- 建议(🔄):可选加"总库"概念:admin 可将候选人标记为共享(owner 置为特殊值或加 `shared` 标志),普通用户可见共享池;或保持现状,由 admin 作为总库管理员。
+
+**需求 2:OA 同步岗位 + 创建岗位双入口**
+- 原话:「OA 审批完同步过来,已是待发布状态;系统内也要保留手动创建岗位入口」(P2)
+- 现状:✅ 手动创建岗位已有;OA 同步入口部分存在(`/api/jd/sync-external` 接收企微 QwenPaw JD 建岗)。审批流程明确「不在本系统做,走 OA」(P1: 审批回到 OA,此处不存在审批流程)。
+- 建议(🔄):明确 OA 同步字段映射(岗位名/部门/类型/招聘人数/目标),同步后状态为「待发布」。
+
+**需求 3:岗位类型细分**
+- 原话:「岗位类型我还没细分;有研发、解决方案(售前)、销售、商务(两种定义)、产品(暂无)」(P2)
+- 现状:🔄 无岗位类型枚举字段。
+- 建议(🆕):岗位加 `jobType` 枚举(研发/解决方案/销售/商务-销售口径/商务-投标口径/产品/职能/技术),可配置。
+
+**需求 4:招聘人数联动自动关闭**
+- 原话:「目标招 2 个,已录用 2 个,数值相等就自动已关闭;招 1 个就够也能手动关闭」(P2)
+- 现状:🔄 岗位有 headcount/hired 字段,状态流转部分支持(录用入职后 candidate 改已入职)。
+- 建议(🆕):**hired ≥ headcount 时自动置岗位状态「已关闭」**(规则触发,非手动)。
+
+**需求 5:JD 状态 + 版本历史自动迭代**
+- 原话:「JD 状态保留(已生效等);版本号自动识别,确认生效后自动变 V2;改一个字也算小改也要记版本;可查历史版本(以前 JD 什么样、什么时候发布的)」(P2/P9)
+- 现状:✅ JD 状态/版本/历史已有(`jdStatus/jdVersion/jdHistory`);「确认生效自动 +1 版本」为部分(需确认当前是否自动)。
+- 建议(🔄):确认生效时自动生成新版本记录(日期、发布人),历史版本可查看/回溯;小改大改都记版本。
+
+**需求 6:JD 摘要 = 一句话概述**
+- 原话:「JD 摘要类似一句话概述,按 JD 生成内容放进来,Markdown 格式要能自动去掉,不用手动改」(P2/P3)
+- 现状:🔄 JD 摘要字段部分存在;Markdown 清理需确认。
+- 建议(🆕):JD 摘要字段自动从生成内容取一句话概述;展示时剥离 Markdown 符号。
+
+---
+
+## 三、岗位详情与匹配规则(现有部分)
+
+**需求 7:岗位详情页收敛**
+- 原话:「岗位管理二级页面展示岗位历史、迭代版本、目标人数、关联简历数、匹配规则」(P8)
+- 现状:✅ 岗位详情/编辑页已有(JobDetailView/JobEditView),含 JD 版本历史、匹配规则。
+- 建议(🔄):补充「岗位关联简历数」展示(现有多是候选人列表,需统计)。
+
+**需求 8:匹配规则 = 对内 JD 硬性指标**
+- 原话:「对内版本看硬性指标;对内的要求(如竞业)在生成 JD 评级标准时起作用,用于简历评级」(P3)
+- 现状:✅ 对内/对外 JD 双版本已有(`_INTERNAL_ONLY_JOB_KEYS` 剥离敏感项);匹配规则字段已有(mustHave/niceToHave/knockout/matchKeywords)。
+- 建议(🔄):把对内 JD 硬性指标直接作为候选人匹配规则的输入源,生成评级标准。
+
+**需求 9:需求模板(有 JD 粘贴 / 无 JD 用模板 / AI 调研)**
+- 原话:「模板两个用途:已有 JD 直接粘进去生成;没有 JD 用人部门要模板,把模板发他;还有 AI 调研场景」(P9/P11)
+- 现状:✅ 逼问式访谈(AI 调研)已有;「粘贴 JD 生成」入口需确认。
+- 建议(🔄):补齐「粘贴完整 JD → 自动结构化」入口(可走 AI 解析)。
+
+---
+
+## 四、候选人弹窗页(重点,现有缺失)
+
+**需求 10:候选人详情 = 弹窗/页面级展示,收敛所有信息**(核心交互改造)
+- 原话:
+  - 「点击查看这个人,弹出一个页面,展示基本信息、匹配评估、当前流程、面评」(P6)
+  - 「把简历、概览、AI 评估都收敛在弹窗页,关掉好操作,不用一页拉很长」(P13)
+  - 「简历可收缩,点击预览;不点就显示已提取信息(像证书那样)」(P14)
+  - 「页面左侧是履历/PDF 渲染,右侧是基本信息概览;或做成同级页面可返回」(P14/P17)
+- 现状:🔄 候选人有详情视图但非弹窗/抽屉式;信息分散。
+- 建议(🆕):候选人详情改为**抽屉/弹窗式**布局:
+  - 顶部:姓名、关联岗位、来源渠道
+  - 概览:电话/邮箱/年龄/工作年限/学历/学校标签/专业/技能(来自解析)
+  - 摘要:一句话总结过往经历(来自 AI 或本地)
+  - AI 评分区(见需求 13-17)
+  - 操作栏:下推流程/面试记录/评价(可上传 PDF 面试记录,P18)
+
+**需求 11:候选人与岗位「重新匹配」**
+- 原话:「插件抓的岗位是候选人在平台选的期望岗位,实际匹配要用我们的沟通职位;可能抓错,要能改匹配岗位重新匹配」(P12)
+- 现状:🔄 candidate 有 jobId/jobTitle,可改;「改岗位后重新匹配」需确认。
+- 建议(🆕):候选人详情提供「更改匹配岗位」操作,改后触发重新匹配评分。
+
+**需求 12:候选人标记(重点/待跟进)**
+- 原话:「通过一面待二面的人重点标记;很匹配但难找的人标记重点关注;未来每周看提醒沟通维护;标记人工选,AI 不做」(P12)
+- 现状:🔄 候选人有 tag 字段(如"新入库"),无结构化标记体系。
+- 建议(🆕):加候选人标记枚举(重点跟进/待二面/需维护/已淘汰等),列表可筛选;可选加"本周待跟进"提醒视图。
+
+---
+
+## 五、AI 评估规则(重点改造,现有部分)
+
+**需求 13:AI 综合评估必须"稳定可复现"(写规则)**
+- 原话:
+  - 「AI 每次评的都不一样;保存后点 AI 评估,过一会儿再点又是一个报告,到底以哪个为准?」(P5)
+  - 「所以 AI 评估需要写一套规则,这是代办」(P6)
+  - 「AI 说这个电力家园的人没家园经验还让问山东现货,就是没写规则」(P13)
+- 现状:🔄 有 `local-structured` 本地规则回退 + LLM 评估;LLM 评估本身不稳定。
+- 建议(🆕):**AI 评估改为"规则约束 + LLM 填充"**:
+  1. 固定评估维度(见需求 15-17),输出结构化为固定 JSON schema;
+  2. 评估依据限定为「对内 JD 硬性指标 + 候选人简历事实」,禁止自由发挥;
+  3. 同一候选人重复评估结果应基本一致(缓存或确定性提示词);
+  4. 每个维度给"证据引用"(来自简历原文)。
+
+**需求 14:AI 不得引用候选人自述优势**
+- 原话:「不能参考候选人自己写的核心竞争力;简历里大家都写自己优势,要加约束规则」(P16)
+- 建议(🆕):提示词硬规则:候选人自我评价/优势描述不作为评估依据,只作为待验证线索。
+
+**需求 15:匹配分析 = 结合对内 JD 找"哪里匹配"**
+- 原话:「匹配分析结合对内版 JD 分析,给我找人做参考(如找 SAP/金蝶/用友做 ERP 大客户销售的人)」(P16)
+- 现状:✅ 匹配分析已有(matchKeywords/mustHave 等本地规则 + AI)。
+- 建议(🆕):匹配分析输出"候选人符合哪些对内硬性指标"及"可去找哪类公司背景的人",直接作为寻源参考。
+
+**需求 16:核心亮点(能力拆解 + 匹配证据)**
+- 原话:「能力拆解可以做匹配;候选人的匹配证据属于他简历里的事实;项目价值这块可以放弃,写得好不一定实际」(P16)
+- 建议(🆕):核心亮点 = 候选人简历中的客观事实拆解(项目/职责/成就),标注证据;**不做"项目价值"评估**(HR 明确放弃)。
+
+**需求 17:风险点评估(固定几个维度,不泛)**
+- 原话:「风险点不要太泛,只评估几个点:跳槽频率、竞业协议(标准竞对高管需提示人力确认)、客户名单、中间 gap(如 2020-2024 四年 gap 要提示)、高层职业道德」(P16/P17)
+- 现状:🔄 offer 有 risk 字段;候选人无结构化风险点。
+- 建议(🆕):候选人风险点固定维度:跳槽频率、竞业协议风险、职业空窗(gap)、职业道德提示(高层);每项输出"提示 + 依据",由 HR 确认。
+
+**需求 18:快筛评分(本地基础评分)**
+- 原话:「快筛评分本地做,用基本要求/硬性要求评一下,先看一眼;一般到这边的都是看过一遍的」(P6)
+- 现状:✅ 快筛评分已有(local-structured,本地关键词匹配,省 token)。
+- 建议(🔄):保持本地规则,可作为"是否进入 AI 评估"的前置门槛。
+
+---
+
+## 六、面试记录与下推流程(现有部分)
+
+**需求 19:面试记录(多轮 + 面试官评价)**
+- 原话:「一面、二面…每个面试不同面试官反馈都能记在上面;面评要有具体内容和时间;下一轮动作是淘汰还是继续二面三面;面试形式(线上/线下)」(P6/P7)
+- 现状:🔄 interview 表存在(round/scheduled_at/interviewer/result/feedback),前端面试记录 UI 需确认。
+- 建议(🔄):候选人弹窗内提供多轮面试记录,字段:轮次/时间/面试官/形式(线上/线下)/评价内容/结果(通过/淘汰/待定)。
+
+**需求 20:下推流程 = 操作记录 + 状态联动**
+- 原话:「整个下推流程叫操作记录;现在什么状态、下一步怎么操作,放操作栏;状态变了代办要同步新增」(P18/P19)
+- 现状:🔄 候选人 stage 流转 + 事件日志 + 待办生成部分联动(如 Offer 已发送自动生成跟进待办)。
+- 建议(🆕):**候选人操作栏**:当前状态 + 下一步操作(下推/淘汰/安排面试),操作后自动:更新 stage、写事件日志、同步生成/完成相关待办——重点保证"下推联动"不遗漏。
+
+**需求 21:面试评价表 + 入职材料三件套**
+- 原话:「入职材料三个:候选人个人信息表、用人部门面试评价表(需下推给用人部门确认)、录用通知 offer 表」(P7/P8)
+- 现状:✅ offer 审批材料(approvalMaterials)已有。
+- 建议(🔄):材料模板化:三张表模板(候选人信息/部门评价/录用通知),系统预填候选人/部门/岗位等已知字段,HR 补填后导出/下推。
+
+---
+
+## 七、简历库与人才池(现有部分)
+
+**需求 22:简历库 = 简历存储 + 标签 + 统计**
+- 原话:「简历库涵盖所有简历,几十上百份可打标签;要看总量、通过面试人数、各岗位简历量(如 java 岗多少份、人力岗多少份);面完没过的放人才池」(P19)
+- 现状:✅ 简历库/候选人列表已有(candidates 表 + resume 关联),有来源/阶段筛选。
+- 建议(🆕):简历库增强:标签筛选(复用需求 12 标记)、岗位维简历量统计、人才池视图(未通过/待定)。
+
+---
+
+## 八、采集插件修正(现有部分)
+
+**需求 23:插件抓取字段修正**
+- 原话:
+  - 「狗抓的岗位不准,抓的是平台期望岗位,要改成匹配我们的沟通职位」(P12)
+  - 「狗抓到名字是错的(余德宝 888 抓成童童真),但 PDF 抓得准」(P12)
+  - 「期望薪资没抓」(P14)
+- 现状:✅ 插件采集已有(BOSS/猎聘,PDF URL + 摘要),幂等去重。
+- 建议(🆕):插件修正:抓「沟通职位」而非平台期望岗位;修正姓名/字段解析;补抓期望薪资;保留 PDF 下载准确性。
+
+---
+
+## 九、其他与交互细节
+
+- **需求 24:候选人概览抓取准确度**:本地字段抽取(姓名/学校/专业/工作年限)有错抓(名字抓成工作经历),需改进解析(P13)。
+- **需求 25:期望薪资展示**:候选人详情展示期望薪资(插件未抓,人工可补)(P14)。
+- **需求 26:UI 风格**:HR 偏好「玻璃拟态 + 蓝色系 + 有色彩」的偏 fast 风格界面,会提供风格截图(P13)。
+- **需求 27:伯乐帮对照**:外部 AI 工具(伯乐帮)只做"履历合格情况"参考;本系统做完整档案与评估,两者分工明确(P8)。
+
+---
+
+## 十、优先级建议(按访谈强调程度)
+
+| 优先级 | 需求 | 理由 |
+| --- | --- | --- |
+| P0 | 需求 13 AI 评估规则化(稳定可复现) | HR 反复强调,当前最大痛点 |
+| P0 | 需求 20 下推流程联动 | 全局联动是流程跑通的关键 |
+| P1 | 需求 10 候选人弹窗页收敛 | 核心交互,信息分散的根治 |
+| P1 | 需求 12 候选人标记 | 日常跟进刚需 |
+| P1 | 需求 17 风险点评估(固定维度) | 招聘风控刚需 |
+| P2 | 需求 15/16 匹配分析/核心亮点 | 寻源参考,锦上添花 |
+| P2 | 需求 4/5 岗位自动关闭/JD 版本 | 减少手工维护 |
+| P2 | 需求 22 简历库标签/统计 | 简历量上来后刚需 |
+| P3 | 需求 23 插件字段修正 | 采集质量优化 |
+| P3 | 需求 21 入职材料模板 | 流程完整性 |
+
+---
+
+## 附:访谈中的明确"不做/暂缓"事项
+
+- **审批流程不做**:岗位审批走 OA,本系统不实现审批流(P1)
+- **项目价值评估不做**:AI 不评估"项目价值"(P16)
+- **腾讯会议总结自动同步不做**:面试总结手动复制粘贴(会议联动太复杂)(P7)
+- **智能体对话查候选人信息不做**:「问智能体候选人住哪里」这类对话暂不支持,HR 自己记录(P19)
+- **面试记录 PDF 上传**:可做可不做,保留文本记录即可(P18)
+
+---
+
+*整理自 20 页访谈记录,并结合当前代码现状标注;建议按 P0 → P3 顺序逐模块开发。*