简介：公共人才招聘网网站后台需求说明书是一份面向系统分析、产品设计与后台开发人员的项目需求文档，内容围绕宁夏公共人才招聘网展开。文档依据人社部相关文件要求，明确了公益性公共就业人才服务网站的定位、总体目标与互联互通原则，规划了“两区”建设人才资源库和重点企业人才需求库，并给出首页—一级栏目—二级栏目的三层信息结构与对应页面设计。技术层面涵盖J2EE标准、AJAX+Struts+Spring+Hibernate架构、B/S结构、站群统一管理、内容管理、全文检索及数据迁移等要求，可作为同类公共招聘平台需求梳理与方案编写的直接参考。资源包仅含1个PDF文件，大小约110KB，轻量易读，已有63人学习浏览。对于需要撰写政务类招聘网站需求说明书或规划后台功能模块的读者，这份文档具有较好的示范价值。
1. 公共人才招聘网后台需求说明书：先想清楚这三件事再动笔
拿到「公共人才招聘网,网站后台需求说明书.pdf」这个标题，很多人第一反应是找模板、搜格式，真正动手时才发现：后台需求说明书不是给开发看的功能列表，而是给整个项目定规则的第一份契约。开发、测试、产品、运营都靠它对齐，一份含糊的说明书会让审核流程、权限边界、数据一致性这些看不见的地方在后期反复返工。
这类平台与普通商业招聘网站最大的差异是「公共」二字：它面向全社会，有公益属性，审核要求更严，数据隐私更敏感，而且用户往往低频使用——求职者可能一年只用几次，但每次都要能快速完成投递。这意味着后台的设计重心不是「增长」，而是「管理」：企业资质怎么审、职位怎么控、简历怎么保护、异常怎么处理。
这篇笔记按我实际做类似项目的思路来拆：先定角色和模块边界，再讲权限、状态机和数据约定，最后给出避坑清单和自检方法。不管你要写的是几十页的完整说明书，还是先出一版能开工的初稿，这套框架都适用。顺便说一句，后缀是 pdf 还是 docx 不重要，内容能不能让开发不问你就开工，才是唯一的验收标准。
2. 公共招聘后台的核心模块拆解：先分清角色再谈功能
后台需求说明书最怕一上来就写「用户管理」「企业管理」这种大名词。每个词背后是一整条业务链路，不拆清楚，开发拿到需求只能靠猜。我一般按「角色 → 模块 → 功能条目」三层来拆，先回答「谁在用后台」，再回答「每个角色要做什么事」。
2.1 公共招聘后台和普通商业招聘后台的四个关键差异
先理解这类平台的特殊性，你才知道需求说明书里哪些地方要重点写。
第一是审核链路长。公共平台对真实性要求高，企业要核营业执照、核经办人身份，职位要核岗位名称、薪资范围、福利描述，连招聘简章里有没有违规词都要过一遍。这条链路涉及多角色协同：企业提交 → 初审 → 复审 → 驳回/通过，每一步都要有记录。
第二是数据公共属性强。简历里的手机号、身份证号、住址属于敏感信息，平台需要对求职者负责。需求说明书里必须写明「谁在什么场景下能看到完整字段」，而不是笼统写一句「做好隐私保护」。
第三是访问模式特殊。平时流量平稳，但一到招聘会、毕业季，企业和求职者会集中涌入。后台的审核队列可能瞬间积压几百条职位，运营需要批量操作能力，说明书里要设计「批量通过」「批量驳回」这类功能。
第四是缺乏商业闭环。公共平台不以盈利为目标，后台功能聚焦「管得住」，而不是「转化高」。这意味着很多在商业平台重要的功能（如付费置顶、竞价排名）在这里不存在，反而要多出「违规公示」「举报处置」「黑名单」这类管理功能。写说明书时不要照搬商业招聘网站的后台结构，要按公共平台的治理逻辑重新组装。
2.2 四个端点与功能模块清单：一张表理清后台全貌
公共人才招聘网的后台通常拆成四个端点，每个端点服务不同类型的用户。需求说明书的第一章应该是这张模块总览表，让所有人对「系统到底有哪些部分」有一致认知。
表格：公共人才招聘网后台模块总览
| 端点 | 服务对象 | 核心模块 | 需求说明书必须写清的点 |
|---|---|---|---|
| 个人用户端后台 | 求职者 | 实名认证、简历管理、投递记录、隐私设置 | 实名认证的方式与审核时限；简历的公开/隐藏策略 |
| 企业端后台 | 企业HR与经办人 | 企业认证、职位发布与管理、简历查收、面试安排 | 企业认证材料清单；职位审核被驳回后的修改流程 |
| 运营后台 | 平台运营与审核人员 | 企业审核、职位审核、简历巡检、举报处理、公告管理、数据统计 | 每个审核任务的分配规则；举报处理的响应时限 |
| 平台管理端 | 系统管理员 | 账号管理、角色权限、操作日志、系统参数配置、黑白名单 | 角色与权限的对应关系；日志保留时长与查询条件 |
这张表的价值不只是列功能，它强制你回答「每个模块的边界在哪」。比如「简历管理」从用户端看是「编辑、公开、投递」，从运营后台看却是「巡检违规简历、处理简历举报」，两个端点的功能完全不同，不能混在一个模块里写。
2.3 功能条目的写法：每个模块用七要素描述，不留模糊地带
模块拆完，下一步是把每个模块展开成功能条目。我用的模板是七要素，每一条都按这个写，开发才不需要回头反复确认。
表格：功能条目七要素模板
| 要素 | 说明 | 示例（职位审核） |
|---|---|---|
| 功能编号 | 全局唯一，方便追踪变更 | POS-AUDIT-001 |
| 功能名称 | 动词+对象，不要用「管理」这种泛词 | 职位审核通过 |
| 优先级 | P0必做 / P1重要 / P2可选 | P0 |
| 业务规则 | 触发条件、处理流程、字段规则 | 仅状态为「待审核」的职位可执行；审核通过后职位状态变为「已发布」并推送通知 |
| 异常处理 | 失败场景与兜底逻辑 | 职位在审核期间被企业撤回，系统提示「该职位已撤回，无法审核」并返回列表刷新 |
| 验收标准 | 可测试的量化条件 | 审核通过后5秒内职位状态更新，企业端收到站内信与短信通知 |
| 关联数据 | 涉及的表与字段 | 职位表status字段、审核日志表、通知记录表 |
这里最容易犯的错是「异常处理」不写或随便写。审核功能看起来简单——点一下通过就完了，但「职位在审核中被企业撤回」「职位已被审核专员A通过、专员B又打开页面」这种并发场景，开发必须知道系统的预期行为。你可以在需求说明书里明确「同一职位同一时间仅允许一个审核任务生效」，一句话就能省掉后面无数扯皮。
我一般会先花半天把模块总览和功能条目模板定下来，再让团队里的开发、测试各自按模板补两条，确认理解一致。模板不对，后面写再多细节都会被带偏。
3. 权限矩阵与核心流程状态机：需求说明书最容易翻车的两个地方
后台需求说明书里，权限和状态流转是开发最依赖、也最容易出分歧的部分。权限没写清楚，开发把接口做成了「登录就能访问」；状态机没写清楚，测试阶段会发现一堆流程走不通。这两块值得单独用一章来细化。
3.1 六类角色与权限矩阵：功能权限和数据权限要分开写
公共招聘网后台至少涉及六类角色：超级管理员、平台运营、审核专员、企业管理员、企业普通员工、求职者。需求说明书里不能只写角色名，要写清楚每个角色「能做什么功能」和「能看哪些数据」两个维度。
功能权限比较好理解：企业管理员可以发布职位、查看本企业简历，但看不到其他企业的任何数据；审核专员可以处理分配给自己的审核任务，但不能修改企业资料。数据权限才是容易被忽略的。审核专员通常按地域或行业分组，比如 A 专员只负责某区的企业，他登录后只能看到该区的待审列表，而不是全平台的。这个约束不在权限矩阵里写清楚，开发就会做成「所有审核专员看到全量数据」，上线后运营立刻投诉。
表格：公共人才招聘网后台权限矩阵（节选）
| 功能点 | 超级管理员 | 运营专员 | 审核专员 | 企业管理员 |
|---|---|---|---|---|
| 企业资质审核 | 全部数据 | 不可见 | 仅本辖区 | 不可见 |
| 职位审核 | 全部数据 | 全部数据 | 仅本辖区 | 提交后不可改 |
| 简历查看 | 隐藏手机号 | 隐藏手机号 | 不可见 | 仅本企业收到的投递 |
| 账号禁用 | 可操作 | 不可操作 | 不可操作 | 本企业子账号 |
| 操作日志查询 | 全部日志 | 仅本人相关 | 仅本人相关 | 本企业相关 |
数据权限的写法要具体到范围描述，比如「仅本辖区」「仅本企业收到的投递」「本人相关」，避免使用「可查看所有信息」这类表述。还需要补充说明「隐藏手机号」的具体规则：审核专员在审核企业资质时需要联系企业，但不需要看到企业经办人的完整手机号，可以看后四位以便人工核对，这个细节要在文档里点明。
权限矩阵建议用一个表装下所有角色与功能点的交叉关系，需求说明书附上完整表格即可，正文只写特殊规则和典型例子。
3.2 三条核心状态机：职位、投递、审核记录的状态流转
状态机是需求说明书里「写好了开发省心，写漏了开发翻白眼」的部分。公共招聘后台至少要定义三条状态机：职位状态、投递状态、审核记录状态。
职位状态围绕发布生命周期：草稿、待审核、已发布、已下架、违规封禁，加上一个「审核驳回」分支。需要特别说明的是驳回不是终态，企业修改后可重新提交，重新进入待审核，但系统要记录驳回次数，超过三次进入人工复核。这个「次数限制」必须在需求说明书里写明，否则开发只会做一次驳回，企业改完再提交又被机械驳回，形成死循环。
投递状态围绕求职者的行为：已投递、被查看、已沟通、邀面试、已录用、已关闭。关键分支是「关闭」：求职者可以主动撤回投递，企业可以关闭职位导致投递失效，系统也要自动关闭超过 180 天未处理的投递记录。这些触发条件要列全，否则测试时发现「用户撤回了简历但企业还能看到」，原因就是需求里没写撤回后的数据可见规则。
审核记录状态要独立成表：待处理、审核中、已通过、已驳回、已撤销。审核记录不是职位状态的附属品，不能合并写，因为一个职位可能被审核三次，每次都要留痕。需求说明书要说明审核记录的查询条件（按审核人、按时间范围、按审核结果）和保留策略，供后续审计追溯。
用表格呈现状态流转会比纯文字清晰得多：
表格：职位状态流转关键路径
| 当前状态 | 触发动作 | 目标状态 | 条件说明 |
|---|---|---|---|
| 草稿 | 企业提交审核 | 待审核 | 必填字段完整性校验通过 |
| 待审核 | 审核通过 | 已发布 | 审核专员确认信息合规 |
| 待审核 | 审核驳回 | 已驳回 | 驳回原因必填 |
| 已驳回 | 企业修改后重提 | 待审核 | 驳回次数小于3 |
| 已发布 | 企业主动下架 | 已下架 | 下架后不删除数据 |
| 已发布 | 系统检测违规 | 违规封禁 | 触发平台规则，需运营确认 |
表格列出的是主路径，需求说明书正文还要补充每个路径的异常情况，比如「职位已发布但企业已注销，职位该怎么办」，这类问题不写，开发就只能自己决策，而大概率是错的方向。
3.3 状态机的并发与边界场景：不写清楚就是埋雷
状态机的主流程谁都能写，差距在边界场景。我挑三个最常见的来说。
第一个是「撤回与已读的冲突」。求职者投递简历后，企业HR已经点开查看，这时求职者撤回投递，HR的端上是否还保留这份简历？两种方案都合理，但需求说明书必须选一个。我的建议是：已读状态下保留简历但标记「已撤回」，未读状态下彻底移除，两种处理方式的理由都要写进文档说明。
第二个是「职位过期与存量投递」。职位发布时可设置有效期，到期自动下架。但下架前求职者已投递的简历怎么办？是让企业继续处理，还是统一关闭？如果选择「继续处理到流程结束」，就得写明时限，比如 30 天内有效，超时自动关闭投递记录。
第三个是「重复提交与并发放大」。两个审核专员同时打开了同一个待审核职位，A 点击通过、B 点击驳回，系统最终以谁为准？推荐做法是加任务锁机制：审核任务被 A 打开时进入「审核中」状态，B 打开时提示「该职位正在被他人处理」，按钮置灰不可点。需求说明书写一句「同一审核任务同时仅允许一名专员操作」，开发就知道去实现互斥逻辑。
这些边界条件不写，开发会按自己的理解实现，测试用例也无从设计。我在项目评审时有一个习惯：拿状态机表格逐条追问「然后呢」——从草稿一路问到违规封禁，问不下去的地方就是需求缺失的地方。
4. 数据与接口约定：需求说明书里的字典、表结构和接口清单
后台需求说明书不只是功能描述，还承担着「数据契约」的作用。开发拿到文档要能直接建表、直接定义接口入参出参，而不是再开一轮会议确认字段含义。这块写得好不好，直接决定开发周期。
4.1 核心数据表清单：六张表支撑整个后台
公共招聘网后台的核心数据可以收敛到六张表：用户表、企业表、职位表、投递表、审核日志表、操作日志表。需求说明书不需要给完整建表语句（那是详细设计的事），但要给表结构约定，包括关键字段、类型、业务含义。
| 表名 | 用途 | 关键字段 | 备注 |
|---|---|---|---|
| user | 个人用户与企业经办人统一账户 | user_id, user_type, mobile, real_name, id_card_no, status | user_type 区分求职者/企业经办人/运营人员 |
| company | 企业主体信息 | company_id, company_name, credit_code, legal_person, licence_url, audit_status | audit_status 关联审核流 |
| job | 职位信息 | job_id, company_id, job_title, salary_min, salary_max, status, expire_time | status 与职位状态机一致 |
| resume | 简历信息 | resume_id, user_id, phone, education_list, work_list, is_public | 手机号等敏感字段单独设置脱敏规则 |
| delivery | 投递记录 | delivery_id, resume_id, job_id, user_id, status, created_at | 一条投递唯一，避免重复投递 |
| audit_log | 审核留痕 | log_id, biz_type, biz_id, auditor_id, action, reason, created_at | 所有审核动作可追溯 |
4.2 一张建表 DDL 说明状态与时间字段怎么写
需求说明书中「状态字段用什么类型」「时间字段怎么定义」这类约定看起来琐碎，但能避免开发各自为政。下面以审核日志表为例，展示我在文档中给出的字段规范：
CREATE TABLE `audit_log` ( `log_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键'， `biz_type` TINYINT NOT NULL COMMENT '业务类型: 1-企业认证, 2-职位审核, 3-简历巡检', `biz_id` BIGINT UNSIGNED NOT NULL COMMENT '业务主键ID', `auditor_id` BIGINT UNSIGNED NOT NULL COMMENT '审核人用户ID', `action` TINYINT NOT NULL COMMENT '动作: 1-通过, 2-驳回, 3-撤销, 4-转人工', `reason` VARCHAR(500) NOT NULL DEFAULT '' COMMENT '驳回/撤销原因, action=2/3时必填', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '操作时间', `version` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', `is_deleted` TINYINT NOT NULL DEFAULT 0 COMMENT '软删除: 0-正常, 1-删除', PRIMARY KEY (`log_id`), KEY `idx_biz` (`biz_type`, `biz_id`), KEY `idx_auditor` (`auditor_id`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='审核日志表';这段 DDL 每个字段的选择都有讲究，需求说明书里要配合文字说明。
状态字段的类型，建议统一使用TINYINT枚举而不是VARCHAR。原因很简单：数字枚举在代码中好比较、好索引，不易因空格或大小写产生脏数据。同时必须在文档里附一张枚举值释义表，否则数字就变成了黑匣子。
时间字段统一用DATETIME，不要混用TIMESTAMP。两者行为在时区和 2038 年问题上不同，如果项目没有专门的 DBA 规范，统一用 DATETIME 最省事。created_at和updated_at是约定俗成的字段名，文档里直接写明「所有业务表必须包含这两个字段」，避免每个人起名不同。
版本号字段version用于乐观锁，解决并发问题。审核专员 A 和 B 同时打开同一条记录，A 提交后版本号从 0 变 1，B 再提交时版本对不上就提示失败——这就是 3.3 节说的并发互斥在数据层的实现。软删除标记is_deleted也有必要，公共平台的数据不能物理删，被误删的企业信息需要能恢复。
4.3 字典表和接口清单：让前后端不被字段含义绊倒
需求说明书里应该包含一份「数据字典」：所有枚举字段集中定义，全局统一引用。比如审核动作 1-通过 2-驳回 3-撤销 4-转人工，投递状态 1-已投递 2-被查看 3-已沟通 4-邀面试 5-已录用 6-已关闭。这份字典放在文档附录中，前端后端都按编号对接。
接口层面的约定，需求说明书不需要写具体路径，但要有接口清单表格，让前后端知道有哪些数据传输通道。
| 接口名称 | 请求方 | 主要入参 | 主要出参 | 权限要求 |
|---|---|---|---|---|
| 提交企业认证 | 企业端 | 营业执照图片、企业名称、信用代码 | 审核单ID、当前状态 | 需登录且未认证或驳回状态 |
| 职位审核列表 | 运营后台 | 辖区ID、状态、时间范围 | 职位列表、分页信息 | 审核专员仅返回本辖区数据 |
| 职位审核操作 | 运营后台 | 职位ID、动作、驳回原因 | 操作结果、最新状态 | 动作与权限矩阵一致 |
| 投递记录查询 | 企业端 | 职位ID、投递状态、时间 | 简历摘要列表 | 仅本企业数据 |
| 批量通过 | 运营后台 | 审核单ID数组、动作 | 成功/失败明细 | 状态需全部为待审核 |
接口清单的作用是提前暴露问题：比如「职位审核操作」要求权限矩阵里审核专员只能操作本辖区数据，那你就能及时想到入参里需要带辖区ID，由后端做二次校验，而不是靠前端隐藏按钮。
5. 写公共人才招聘网后台需求说明书的5个常见坑
需求说明书写得越多，越容易踩重复的坑。我把做类似项目时积累的典型问题整理成下面五条，每一条都是「现象 → 原因 → 解决」的结构。
5.1 审核操作只写「通过/驳回」，没写驳回原因必填
现象：开发把驳回做成了可选项，运营在后台点「驳回」时可以不填原因直接提交，企业收到通知后根本不知道哪里不合格，只能打电话找客服。
原因：需求说明书里写的是「审核专员可驳回，被驳回的职位进入已驳回状态」，把「原因」写成了可选字段。开发按字面实现，觉得少填一个字段还能减少输入成本。
解决：在功能条目的字段规则里写明「驳回原因必填，字符长度不小于5个字」，同时说明「调用驳回接口时，原因为空则接口返回错误码提示」。需求说明书里所有带「驳回」字样的功能，都要带上这条规则，宁可重复也不能漏。
5.2 权限只写到角色，没写数据范围
现象：审核专员登录后看到全平台所有企业的审核列表，运营发现后要求返工，因为辖区专员能看到其他区的企业数据，存在信息泄露风险。
原因：权限矩阵只写了「角色能操作哪些功能」，漏掉了「角色能看哪些数据」这个维度。开发实现了功能权限控制，数据库行级过滤完全没做。
解决：权限矩阵里增加「数据范围」列，明确「仅本辖区」「仅本企业」「全部」等粒度。同时在审核列表查询接口的说明里写一句「根据当前用户所属辖区ID进行数据过滤」，让开发无法忽略。
5.3 状态机漏了「撤回」和「过期」分支
现象：测试阶段发现求职者撤回投递后，企业端仍能查看简历；职位设置了有效期，到期后系统没有执行下架操作，职位一直挂在页面上。
原因：需求说明书画状态机时只画了正向主路径（提交→审核→发布→下架），把用户主动撤回、系统自动过期这两个触发动作遗漏了。
解决：在状态机表格中列出所有触发动作，包括用户行为触发的和系统定时任务触发的。每个动作都标注「由谁触发」和「触发条件」。我通常会检查一遍每个状态的「入边」和「出边」，保证每个状态都有明确的进入和离开路径。
5.4 敏感字段只写「脱敏」，没写脱敏规则
现象：开发实现了手机号脱敏，但脱敏格式五花八门，有的显示前三位后四位（138****5678），有的只显示后四位（****5678），运营反馈不统一，且某些后台页面显示了完整号码。
原因：需求说明书里只有「简历手机号脱敏显示」这句话，没有具体到「哪些字段脱敏、什么格式、哪些角色可见完整值」。
解决：写一份敏感字段矩阵，例如「手机号：运营端显示 1385678，企业端求职者简历中显示 1385678；审核专员处理认证时可查看完整号码；所有脱敏规则统一由后端处理，前端不接触完整明文」。一句话能解决的问题，落成表格才能约束到每个页面。
5.5 把解决方案写进需求，而不是写验收标准
现象：产品经理在需求说明书里写「审核列表采用虚拟滚动渲染，保证千条数据不卡顿」，开发实现时发现现有框架不支持虚拟滚动，需要换方案，于是需求评审变成技术选型讨论会。
原因：需求说明书混入了技术实现方案，模糊了「要什么」和「怎么做」的边界。开发被具体方案束缚，反而忽略了真正的目标是「列表流畅」。
解决：需求说明书里只写验收标准：「审核列表在1000条数据时，滚动无明显卡顿，帧率不低于30FPS」，具体用虚拟滚动还是分页加载由开发决定。记住一条原则：技术选型写进技术方案文档，需求说明书只写目标和验收标准。例外情况是架构强约束（如「必须使用统一认证服务」），这类约束要单独标注。
6. 用一份自检清单判断需求说明书能不能让开发直接开工
写完初稿后，不要急着发给团队评审。先花半小时按下面的方法自检一遍，能筛掉大部分低级问题。
第一个动作是「朗读测试」：找一位没参与过需求讨论的同事，让他从头到尾读一遍文档，然后画出来他对权限、状态机的理解。如果你发现他画的和你想的不一致，说明文档里有歧义，立即修改原文而不是口头解释。
第二个动作是「异常场景追问」：随机挑三个功能条目，追问「如果这里出错怎么办」。比如职位审核时企业撤回、投递后简历被删除、审核专员离职后名下待办如何转移。回答不上来的地方，就是文档需要补充的异常处理章节。
第三个动作是「验收标准核对」：对照文档里的验收标准逐条问自己「测试能不能按这句话执行」。如果验收标准写「响应速度快」，测试无法量化执行；改成「列表查询接口在1000条投递记录下P95响应时间小于500毫秒」才算可测试。
表格：公共人才招聘网后台需求说明书自检清单
| 检查项 | 通过标准 |
|---|---|
| 角色边界 | 能列出全部角色，且每个角色有明确的数据范围描述 |
| 权限矩阵 | 功能权限与数据权限分离，特殊角色（审核专员）的行级过滤已标注 |
| 状态机完整 | 职位、投递、审核记录三条状态机覆盖所有触发动作，含撤回/过期/违规 |
| 异常处理 | 每个功能条目下都有「异常处理」要素，存在兜底逻辑 |
| 字段规范 | 状态字段使用枚举类型，附数据字典，时间字段统一约定 |
| 敏感字段 | 有敏感字段矩阵，明确脱敏格式与可查看完整值的角色 |
| 接口清单 | 前后端数据传输路径有清单，权限要求与矩阵一致 |
| 可测试性 | 每个验收标准可量化，不使用「流畅」「快速」等模糊词 |
这套自检方法不只是检查文档，也在检查你的业务思考是否闭环。我自己的习惯是：每写完一个模块，就模拟运营从登录到处理完一条审核的全流程，走不通时立刻回到文档里补状态或补边界。坚持这个习惯后，需求评审会从两小时缩短到半小时，开发过程中「需求没写」引起的追问也少了大半。
公共平台的后台需求，核心从来不是功能列表多全，而是规则定义得是否清楚。你愿意在这一步多花时间，后面开发、测试、验收都会省力。希望这篇笔记能帮你少走几趟弯路。
本文还有配套的精品资源，点击获取
