人力资源流程自动化需求说明生成

场景

HR 对 IT 说“把入职流程自动化”，往往只描述理想结果，没有说清触发条件、例外、权限和验收。AI 可以从真实流程记录中整理需求说明初稿，让业务、IT 和法务在开发前对齐边界。

输入

选择一个具体流程，收集当前流程图、触发事件、表单字段、经办人与审批链、系统接口、历史异常、频率、耗时和现行制度。不要从供应商宣传的“全流程自动决策”倒推需求；尤其录用、薪酬、劳动关系等决定应保留人工判断。

写法

先画现状：谁在什么时间输入、在哪个系统做什么、交给谁、遇异常如何处理。再写目标流程的功能要求：自动读取、校验、提醒、生成草稿或发起审批，逐项标注数据来源与权限。对每个节点列正常路径、缺资料、重复提交、审批拒绝、系统断连四类例外和回退。写非功能要求：日志、留痕、访问控制、保存期限、人工干预。最后用真实样本写验收场景，明确“节省时间”要在试点实测，不能凭文章估算。

提示词：

根据以下 HR 真实流程材料，生成一份自动化需求说明初稿，包含业务目标、触发、输入/输出字段、角色权限、系统接口、正常路径、异常与回退、人工审批点、日志和可执行验收用例。未提供的信息列待确认，不猜测接口能力。资料：〔内容〕。

验收与来源

HR 确认业务逻辑，IT 确认接口能力，法务/安全检查个人数据与决策边界。A0533《人力资源 AI 智能体》列出入转调离节点流转和跨系统搬运方向；A1034 的面试“决策智能体”架构不能直接用于高影响人事决定。本文需求说明结构是根据实施风险设计。

入职流程的需求样例

触发事件不是“新员工要来了”这样模糊的描述，而是“录用审批已通过、入职日期和员工编号已确认”。自动化可从已批准记录生成资料清单、通知 IT 开账号、提醒导师；合同签署、身份核验和特殊权限仍需相应责任人。若入职日期变更，系统应撤销旧提醒并重新计算节点；若审批撤回，应停止后续动作并通知相关部门。这些例外比正常路径更能检验需求是否完整。

验收用例

至少写四个可执行用例：标准入职、缺身份证件材料、同名员工、入职延期或取消。每个用例列输入、预期输出、人工审批点和失败时系统状态。上线后测实际处理时间、漏项率和返工率，与人工基线比较；不要仅以“流程能够跑通”作为验收。

需求说明至少回答七个问题

一是为什么做：当前流程的具体痛点和基线；二是什么触发：如录用审批通过而非“HR 想办理”；三是谁参与：发起、审核、执行、被通知者；四是数据从哪来：字段、系统、权限和版本；五是自动做什么：只读查询、生成草稿、发送提醒还是写入正式系统；六是例外怎么办：缺资料、撤销、重复、系统失败；七是怎样验收：给定输入后应出现什么结果和日志。AI 可把访谈纪要整理成这些栏目，但空白必须保持待确认。

以调岗流程为例，员工或主管发起申请后，先确认岗位、薪酬和生效日期是否获批准；AI 可提醒审批人并生成通知草稿，却不能在审批未完成时提前变更系统权限。若申请被撤回，已有提醒和草稿怎样失效？若员工已转岗但旧系统未同步，谁负责纠错？这些异常路径决定系统能否真正上线。

验收用例要包括普通、边界和失败路径，写出具体样本与预期状态。上线后跟踪漏项、错误、人工返工和员工投诉，与原流程基线对比；数字好看但产生员工权益风险的自动化不算成功。

交付与验收清单

• 触发条件、角色、数据源、动作和审批点明确。
• 缺资料、撤销、重复提交与系统故障均有路径。
• 高影响人事决定没有被自动化越过人工责任。
• 验收用例含输入、预期状态与日志。

需求说明要由 HR、IT、数据安全和法务按职责确认；AI 草稿不是开发许可。