234 lines
14 KiB
Markdown
234 lines
14 KiB
Markdown
---
|
||
name: leave-approval-reviewer
|
||
description: 对请假申请做合理性与合规性初审，逐项检查请假类型与天数自洽、事由充分性、长假对项目的影响、病假凭证、超额/频繁请假、时效与时间冲突、占位/测试数据等风险点，遵循“信息不足以判断即偏向退回核实”的从严原则。输出两个相互独立、不可混淆的字段：①【审核决策】只有「放行 / 退回」二选一，决定流程往哪走；②【决策说明】承载放行后仍需关注的细节，或退回的理由。当收到请假申请数据、请假审批、休假审核、leave review、请假合规检查等请求，或拿到包含 leave_type/days/reason 等字段的请假表单数据需要判断是否通过时，务必使用本技能。只输出结构化文本，不要输出 JSON。
|
||
category: Compliance & Security
|
||
---
|
||
|
||
# 请假审批审核助手（Leave Approval Reviewer）· 从严版
|
||
|
||
## Overview
|
||
|
||
本技能面向企业 OA 请假流程，对一张请假申请做**自动初审**，识别合理性与合规性风险。
|
||
|
||
本技能采用**从严审核（fail-closed）立场**：当请假类型与天数不自洽、事由不足、信息不足以判断合理性时，**默认退回**核实而非放行。初审的价值在于把好第一道关，把明显有问题或无法判断的请假挡在前面，再交人工审批。
|
||
|
||
⚠️ **核心模型：决策（二元）与说明（文本）是两个完全独立的字段，绝不可混为一谈。**
|
||
|
||
1. **【审核决策】**：**只有两种、互斥、二选一** —— **放行** 或 **退回**。这是唯一驱动 OA 流程往哪走的字段。
|
||
- **放行**：单据流向下一个人工审批节点（如经理）。
|
||
- **退回**：单据打回发起人修改，修改后可重新提交；流程未终止。
|
||
2. **【决策说明】**：一段文本，**与决策正交**，用来承载“为什么”和“注意什么”。
|
||
- 放行时：写**通过后仍需提醒人工审批人关注的细节**（没有就写“无”）。
|
||
- 退回时：写**必须退回修改的理由**。
|
||
|
||
> 不存在“需关注”这种第三种决策。“需关注”不是一个决策档位，而是 **决策=放行 + 决策说明里写明了要关注的点**。把“是否放行”和“有没有要关注/要修改的事”彻底拆开，是本技能最重要的纪律。
|
||
|
||
定位说明：
|
||
|
||
- 你是**初审 agent**，只负责审核并**输出文本结论**。
|
||
- 下游 OA 系统会把你的文本交给另一个 LLM 做 JSON 结构化提取，因此你**绝对不要自己输出 JSON、代码块或伪代码**，只输出下文规定格式的自然语言文本。
|
||
- 你只能在“放行 / 退回”之间二选一，**无权终止流程**。你的“退回”=打回修改（可重提），**不等于**人工审批环节里的“驳回”（流程直接终止）。
|
||
|
||
## Triggering Cues
|
||
|
||
出现以下任一情况就使用本技能：
|
||
|
||
- 中文：请假审批、请假审核、请假初审、休假审核、请假合规检查、年假/病假/事假审批
|
||
- 英文：leave review, leave approval, time-off request review
|
||
- 收到一段请假表单数据（含 `leave_type` 请假类型、`days` 天数、`reason` 事由 等字段），要求判断是否可以通过审批。
|
||
|
||
## 输入（Input）
|
||
|
||
通常会收到一张请假申请的字段数据，常见字段：
|
||
|
||
| 字段 key | 含义 | 说明 |
|
||
|---|---|---|
|
||
| `leave_type` | 请假类型 | annual(年假) / sick(病假) / personal(事假) |
|
||
| `days` | 请假天数 | 必填；≤0 或非数字即退回 |
|
||
| `reason` | 请假事由 | 自由文本 |
|
||
| `start_date` / `end_date` | 起止日期 | 可能没有；用于核对与天数自洽、时间冲突 |
|
||
| `cert_img` | 病假证明/凭证 | 可能没有；病假长假一般应有 |
|
||
| `balance` | 假期余额 | 可能没有；用于判断是否超额 |
|
||
| `creator` / `dept` | 发起人/部门 | 可能没有 |
|
||
|
||
字段缺失时：
|
||
- **必填项（天数）缺失或无效（≤0、非数字）**：视为硬性缺陷，**退回**。
|
||
- **可选上下文（日期、余额、凭证）缺失**：不因此卡死流程，但要在 `【说明与假设】` 中说明“因缺少 X 无法核验 Y”，并按从严方向取舍。
|
||
|
||
## 审核要点清单（核心）
|
||
|
||
逐项检查以下 8 类。每条标注：**检查什么 → 何时判为问题 → 严重度**。严重度分 `高/中/低`。
|
||
|
||
### 1. 天数有效性 —— 字段 `days`
|
||
- 检查：天数是否为 0/负数/非数字、是否异常巨大。
|
||
- 异常：`days` ≤ 0、非数字、明显不合逻辑 → 数据无效（**高**，退回）。
|
||
- 严重度：**高**。
|
||
|
||
### 2. 类型与天数自洽 —— `leave_type` × `days`
|
||
- 检查：天数与类型是否吻合（如年假是否超出常规额度、事假/病假是否过长）。
|
||
- 异常：
|
||
- 类型与天数明显不自洽、或单次天数异常长（如事假连休数十天无说明）→ 需核实（**中**；信息严重不足则升级）。
|
||
- 严重度：**中**（无异常则跳过）。
|
||
|
||
### 3. 事由充分性 —— 字段 `reason`
|
||
- 检查：事由是否能说明请假原因。
|
||
- 异常：
|
||
- 事由**缺失、仅写“请假/有事/个人原因”等无信息词** → 无法判断（**中**，退回）。
|
||
- 事由有内容但偏笼统 → **低**。
|
||
- 严重度：中 / 低。
|
||
|
||
### 4. 长假对项目的影响 —— `days`
|
||
- 检查：长假是否需要交接或提级关注。
|
||
- 异常：连续请假**超过约 5 天**（具体阈值随公司制度）→ 需关注排期与交接（**中**，放行但提示）。
|
||
- 严重度：**中**。
|
||
|
||
### 5. 病假凭证 —— `leave_type=sick` × `cert_img`
|
||
- 检查：较长病假是否附医疗证明。
|
||
- 异常：病假且天数较长（如 > 3 天）但**未附任何病假证明** → 凭证缺失（**中**；若制度强制则升级为高）。
|
||
- 严重度：中 /（制度强制时）高。无该字段或短病假则按从严方向在说明中提示。
|
||
|
||
### 6. 超额 / 频繁请假 —— `days` × `balance` × 历史
|
||
- 检查：是否超出假期余额、是否近期频繁请假。
|
||
- 异常：
|
||
- 提供 `balance` 且**请假天数超出余额** → 超额（**高**，退回，要求确认假期类型/余额）。
|
||
- 提供历史上下文且呈现频繁请假模式 → 需关注（**中**）。
|
||
- 严重度：高 / 中。无余额/历史则不臆断，仅按其它要点判断。
|
||
|
||
### 7. 时效与时间冲突 —— `start_date` × `end_date` × `days`
|
||
- 检查：起止日期与天数是否自洽、是否为已过去的补请、是否与已知冲突。
|
||
- 异常：
|
||
- 起止日期与 `days` 明显矛盾 → 数据矛盾（**高**，退回）。
|
||
- 大幅事后补请且无说明 → 时效问题（**中**）。
|
||
- 严重度：高 / 中。无日期字段则跳过。
|
||
|
||
### 8. 数据自洽与可疑信号 —— 跨字段
|
||
- 检查：字段是否相互矛盾、是否含明显占位/测试数据（如 reason=test、days=999）。
|
||
- 异常：字段矛盾、疑似测试/占位数据 → **高**（退回，宁缺毋滥）。
|
||
- 严重度：**高**（无此类信号则跳过）。
|
||
|
||
> 字段标注约定：当某条发现指向具体字段时，**用字段英文 key**（`days`/`leave_type`/`reason`/`cert_img` 等）标注，方便下游结构化。
|
||
|
||
## 判定规则：先定决策，再写说明（从严）
|
||
|
||
两个字段分两步独立产出，**顺序不能反、内容不能串**：
|
||
|
||
### 第一步：定【审核决策】（放行 / 退回，二选一）
|
||
|
||
依次判断，命中任一条即 **退回**：
|
||
|
||
| 命中情况 | 决策 |
|
||
|---|---|
|
||
| ① 存在任一 **高** 级缺陷（天数无效、超额、日期与天数矛盾、字段矛盾、占位测试数据等） | **退回** |
|
||
| ② **没有高级缺陷，但累计存在 ≥ 2 条“中”级风险** | **退回** |
|
||
| ③ 仅有 **1 条“中”级风险或仅“低”级风险** | **放行**（在说明里提示） |
|
||
| ④ 完全无风险 | **放行** |
|
||
|
||
> 从严要点：信息不足以判断合理性时按从严方向取舍、倾向退回核实；中级风险会叠加（单条放行、≥2 条退回）。
|
||
|
||
### 第二步：写【决策说明】（与决策正交的文本）
|
||
|
||
- 决策=**放行** → 说明里写：放行后仍需人工审批人关注的点（如长假需交接）；**若完全无风险，就写“无”**。
|
||
- 决策=**退回** → 说明里写：导致退回的缺陷是什么、需要发起人怎么改。
|
||
|
||
置信度：根据信息完整度给出 `高/中/低`。信息越不足，置信度越低，但**不改变从严倾向**。
|
||
|
||
## 输出格式（Output Format）
|
||
|
||
**只输出下面这种结构化中文文本，不要输出 JSON、不要用代码块包裹。** 按固定小标题组织，便于下游 LLM 抽取：
|
||
|
||
```
|
||
【审核决策】放行 / 退回（二选一，这是唯一驱动流程的字段）
|
||
【决策说明】放行时写需提醒审批人关注的点（无则“无”）；退回时写退回修改的理由。
|
||
【一句话摘要】用一句话说明本次决策的核心原因。
|
||
【置信度】高 / 中 / 低（或百分比）
|
||
|
||
【风险发现】
|
||
1. 字段：days ｜ 严重度：中 ｜ 问题：连续请假 7 天，超过 5 天需关注排期与交接 ｜ 建议：确认是否影响项目排期并安排交接
|
||
...（无风险时写“无”）
|
||
|
||
【说明与假设】列出做判断时假设的前提、缺失的上下文（如未提供假期余额、无起止日期等），以及因信息不足而做出的从严取舍。
|
||
```
|
||
|
||
要求：
|
||
|
||
- 【审核决策】**只能填“放行”或“退回”**，不得出现第三种值、不得写“需关注/通过/不通过”等含糊词。
|
||
- 【决策说明】与【审核决策】严格对应：放行时是“关注点/无”，退回时是“退回理由”。
|
||
- 【风险发现】每条固定四段：`字段 ｜ 严重度 ｜ 问题 ｜ 建议`，用全角竖线 `｜` 分隔；严重度只用 `高/中/低`。
|
||
- 自洽性：有任一“高”级风险 ⇒ 决策必为“退回”；“中”级风险 ≥ 2 条 ⇒ 决策必为“退回”；仅 1 条“中”级或仅“低”级 ⇒ 决策为“放行”。
|
||
|
||
## Workflow
|
||
|
||
1. 解析输入的请假字段（leave_type/days/reason 等）。
|
||
2. 按“审核要点清单”8 类逐项检查，记录命中的每条风险（字段、严重度、问题、建议）。
|
||
3. **第一步定决策（从严）**：有“高”级缺陷→退回；无高级但“中”级≥2条→退回；否则→放行；信息不足以判断时按从严方向取舍。
|
||
4. **第二步写说明**：放行则概括关注点（无则“无”），退回则逐条写明退回理由与整改要求。
|
||
5. 评估置信度（信息越不足越低，但不改变从严倾向）。
|
||
6. 按“输出格式”输出结构化文本，**不要输出 JSON**。
|
||
|
||
## Examples
|
||
|
||
### 示例 1：正常短假 → 放行（说明为“无”）
|
||
输入：
|
||
```
|
||
leave_type=annual, days=2, reason=休息调整，处理家中事务
|
||
```
|
||
输出风格：
|
||
```
|
||
【审核决策】放行
|
||
【决策说明】无。
|
||
【一句话摘要】年假 2 天、事由清晰、无超额或冲突，无明显风险。
|
||
【置信度】高
|
||
|
||
【风险发现】无
|
||
|
||
【说明与假设】未提供假期余额，按当前字段判断未发现异常。
|
||
```
|
||
|
||
### 示例 2：长假 → 放行（说明里写交接提示）
|
||
输入：
|
||
```
|
||
leave_type=annual, days=7, reason=回老家探亲并安排家庭事务
|
||
```
|
||
输出风格：
|
||
```
|
||
【审核决策】放行
|
||
【决策说明】连续请假 7 天属长假，请审批人确认是否影响项目排期并安排工作交接；事由清晰，无硬性缺陷，仅此一条长假关注。
|
||
【一句话摘要】长假属唯一“中”级关注，事由清晰，放行进入人工审批并提示交接。
|
||
【置信度】中
|
||
|
||
【风险发现】
|
||
1. 字段：days ｜ 严重度：中 ｜ 问题：连续请假 7 天超过 5 天，需关注排期与交接 ｜ 建议：确认项目影响并安排交接
|
||
|
||
【说明与假设】未提供起止日期与假期余额，长假影响以常识判断。
|
||
```
|
||
|
||
### 示例 3：天数无效 → 退回
|
||
输入：
|
||
```
|
||
leave_type=personal, days=0, reason=有事
|
||
```
|
||
输出风格：
|
||
```
|
||
【审核决策】退回
|
||
【决策说明】请假天数为 0 属无效数据，且事由“有事”过于笼统无法判断；请填写有效天数并补充具体事由后重新提交。
|
||
【一句话摘要】天数无效叠加事由不足，数据无法支撑审批。
|
||
【置信度】高
|
||
|
||
【风险发现】
|
||
1. 字段：days ｜ 严重度：高 ｜ 问题：请假天数为 0，属无效数据 ｜ 建议：填写有效的请假天数
|
||
2. 字段：reason ｜ 严重度：中 ｜ 问题：事由“有事”笼统，无法判断请假原因 ｜ 建议：补充具体事由
|
||
|
||
【说明与假设】仅基于当前字段判断，未提供起止日期。
|
||
```
|
||
|
||
## Guidelines
|
||
|
||
- **只输出文本**，绝不输出 JSON / 代码 / Markdown 表格作为最终结论（示例里的代码块仅为演示排版，实际回复直接给文本）。
|
||
- **决策与说明分离是铁律**：先用判定规则定出放行/退回，再独立去写说明。
|
||
- **从严但克制**：请假是常规事务，不要无端制造风险；只在天数无效、超额、字段矛盾、信息严重不足以判断时退回。长假、单条事由笼统等属“放行+提示”，不要误判为退回。
|
||
- **中级风险会叠加**：单条中级放行并提示；≥2 条中级即退回。
|
||
- 判定要**稳定可复现**：同样的输入应给出同样的决策，便于下游提取与回归测试。
|
||
- 缺少可选上下文（余额、日期、凭证）时，在 `【说明与假设】` 里说明，并按从严方向取舍；不要凭空编造数据。
|
||
- 这是**初审辅助**，不替代 HR/上级的最终判断；措辞用“疑似/建议/需核实”，但退回理由要具体、可整改。
|
||
- 决策与风险严重度必须自洽：有“高”必“退回”；中级 ≥2 必“退回”；仅 1 条中级或仅低级必“放行”。
|