审批队列摘要

用途

把用户从 OA、工单或表格导出的多笔审批记录整理成可复核的队列快照：统一统计时点和状态口径，检查数据质量，计算总龄期、节点龄期和可验证的 SLA 状态，并列出缺件、依赖、升级依据、建议跟进及待确认项。

本技能不登录审批系统，不批准、拒绝、催办或升级，不修改优先级或字段，也不把超时解释为拒绝、失职或责任归属。

适用场景

• 适合：运营、财务、采购、HR、IT 和共享服务团队做日常审批积压盘点、跨节点跟进和 SLA 证据整理。
• 不适合：撰写单笔审批申请、说明服务可用性事故、整理权限到期、代替审批人作决定或自动操作 OA。

与相近技能的区别

• discount-approval-brief、policy-exception-brief 等：准备单笔申请内容；本技能不评价申请是否合理，只分析多笔记录的流转状态。
• sla-breach-note：说明服务 SLA 或可用性影响；本技能只计算审批队列的处理时限。
• access-expiry-digest：按到期日整理权限提醒；本技能处理审批节点、缺件、依赖和升级依据。
• team-weekly-rollup：合成团队更新；本技能固定统计时点、状态映射、双龄期和 SLA 分母，不评价个人表现。

怎么使用（普通用户）

在 AI 助手里直接说，例如：

• 「以北京时间 9 点为统计时点，把这批审批按 SLA、龄期、缺件和依赖整理成队列摘要。」
• 「找出确有升级依据的积压项；不要把超时写成驳回，也不要自动催审批人。」
• 「检查导出的审批表有哪些重复、未来时间、状态冲突和无法计算 SLA 的记录。」

建议先提供队列口径：

• 统计时点、时区、队列范围、来源、导出时间和纳入/排除状态。
• SLA 来源：明确截止时间，或时长、起算事件、自然/工作时间、工作日历和暂停规则。
• 临近到期窗口、升级规则、排序规则；没有时不得自创政策门槛。

每条记录建议包含：

• 唯一 ID 或脱敏代号、申请类型、原始状态、当前节点。
• 提交时间、进入当前节点时间、最后更新时间、明确截止时间。
• 当前处理角色、缺件、外部依赖、暂停区间和来源。
• 用户提供的正式优先级或升级标记。

不要提供身份证号、账号、合同原文、薪酬明细、密码、验证码、token 或私钥。姓名不是队列判断所必需时改用角色或代号；输出不得复述凭证。

时间与 SLA 规则

固定统计口径

• 计算前必须固定统计时点和时区。用户未提供时先询问；若用户明确允许使用当前时间，输出实际采用值。
• 同时记录导出时间。导出早于统计时点时展示数据新鲜度，不推断导出后的状态变化。
• 时间戳无时区、跨时区混用或晚于统计时点时，不猜测修正；标为无效/待确认，并从相关计算分母中排除。

区分三类时间

• 总龄期：统计时点减提交时间。
• 节点龄期：统计时点减进入当前节点时间。
• 最后更新时间：仅表示最近记录变化，不能替代前两项的起算时间。

只有明确暂停规则及暂停区间时才扣除暂停时间。“补件中”不自动等于 SLA 暂停。

判断 SLA

• 有明确截止时间：直接与统计时点比较，输出超出或剩余时长。
• 只有 SLA 时长：必须同时具备起算事件、时间单位、工作日历和暂停规则，才能推导截止时间。
• 临近到期只使用用户提供的窗口；没有窗口时只列剩余时长，不贴“临期”标签。
• 缺截止时间或规则不完整时写“无 SLA”或“无法计算”，不得按同类型其他记录补值。
• 使用输入允许的精度和单位；自然小时不得换算为工作小时。

队列清理规则

• 保留原始状态并写明映射。“审批中”“待审批”“处理中”只有用户确认同义时才归并。
• 相同 ID 仅在范围和版本可确认一致时合并；字段冲突时保留两版。无 ID 时用来源行号或临时代号，不强行去重。
• 已批准、已拒绝、已撤回等终态是否排除，以用户提供的终态定义为准；终态混入活动导出时列数据质量提醒。
• 跨部门或申请类型 SLA 不同，不得套用一套门槛。
• 补件、依赖、暂停和无人承接分别呈现，不把所有积压归因于当前审批角色。

处理流程

1. 锁定口径：记录统计时点、时区、范围、来源、导出时间、状态映射、SLA、暂停、临期和升级规则。
2. 检查质量：统计输入数、有效活动项、终态、重复、缺字段、未来时间、冲突和数据新鲜度。
3. 计算时间：只对有效记录计算总龄期、节点龄期、超出或剩余时长，并公开计算分母。
4. 形成总览：按原始状态、节点和类型计数；每个数字注明分母。
5. 识别缺件与依赖：写缺什么、卡在哪、已知处理角色和来源，不推断责任。
6. 核对升级依据：只有符合用户规则的记录才标“升级候选”，列规则、证据和仍需人工确认项。
7. 给出建议跟进：建议核对缺件、确认 Owner 或按现有流程发起催办/升级，不声称已执行。

用户未给优先级规则时，可按“已确认超时 → 明确截止时间升序 → 总龄期降序”展示，但必须注明这是展示顺序，不是审批优先级。

缺料与降级

• 无统计时点或时区：先追问，不能计算龄期或 SLA。
• 只有状态没有时间：只做状态/节点计数，时间类结论写无法计算。
• 只有提交时间没有 SLA：可算总龄期，不能判超时。
• 工作时间 SLA 缺工作日历或暂停规则：保留原始规则并列待确认，不按自然时间代算。
• 队列为空：说明“本次输入无记录”，不能推断真实系统无待办。
• 大批量分批处理：固定同一统计时点、时区、状态映射和来源批次，最后统一去重并重算分母。

输出要求

严格使用 references/approval-queue-template.md，并遵守：

• 所有计数明确分母；有效活动项、无效项和终态分开。
• 每个超时、临期或升级判断附截止时间、差值、规则和来源。
• 展示顺序与审批优先级分开；建议动作与已执行动作分开。
• 缺件不等于申请人失职，超时不等于拒绝，升级候选不等于已升级。
• 输出是内部草稿；发送或写回前由有权人员复核。

完整示例

输入

统计时点：2026-07-20 09:00，Asia/Shanghai
导出时间：2026-07-20 08:50，Asia/Shanghai
范围：共享服务待办导出；活动状态=待审批、补件中；终态=已批准、已拒绝、已撤回
时间口径：均为自然小时；due_at 为系统已计算的明确截止时间，已包含获批暂停；“补件中”不额外暂停
临近窗口：剩余 12 小时内
升级规则：已超时至少 24 小时且无有效暂停，可列为升级候选，须人工确认后按现有流程升级
展示顺序：已超时 → 临近到期 → SLA 内 → 无 SLA

Q-101｜采购｜待审批｜财务负责人
submitted_at=2026-07-16 09:00
stage_entered_at=2026-07-17 09:00
last_updated_at=2026-07-17 09:00
due_at=2026-07-18 09:00
缺件=无｜依赖=无｜暂停=无

Q-102｜采购｜补件中｜业务补件
submitted_at=2026-07-19 12:00
stage_entered_at=2026-07-19 18:00
last_updated_at=2026-07-19 18:00
due_at=2026-07-21 12:00
缺件=第二份报价｜依赖=申请方补交｜暂停=无

Q-103｜权限｜待审批｜安全评审
submitted_at=2026-07-17 17:00
stage_entered_at=2026-07-19 09:00
last_updated_at=2026-07-19 15:00
due_at=2026-07-20 17:00
缺件=无｜依赖=安全架构意见，预计今日 15:00｜暂停=无

Q-104｜办公用品｜待审批｜部门负责人
submitted_at=2026-07-20 08:00
stage_entered_at=2026-07-20 08:00
last_updated_at=2026-07-20 08:00
due_at=空
缺件=无｜依赖=无｜暂停=无

Q-105｜采购｜待审批｜财务负责人
submitted_at=2026-07-21 08:00
stage_entered_at=2026-07-21 08:00
last_updated_at=2026-07-20 08:30
due_at=2026-07-22 08:00
缺件=无｜依赖=无｜暂停=无

Q-106｜采购｜已批准｜已结束
submitted_at=2026-07-18 10:00
stage_entered_at=2026-07-20 08:30
last_updated_at=2026-07-20 08:30
due_at=2026-07-19 10:00
缺件=无｜依赖=无｜暂停=无

输出

# 审批队列摘要

## 1. 队列口径
- 统计时点：2026-07-20 09:00，Asia/Shanghai。
- 导出时间：2026-07-20 08:50；数据新鲜度为统计时点前 10 分钟，之后变化未知。
- 范围：活动状态“待审批、补件中”；终态“已批准、已拒绝、已撤回”排除。
- SLA：使用输入中的明确 due_at，按自然小时比较；临近窗口为剩余 12 小时内。
- 升级：超时至少 24 小时且无有效暂停，仅列候选，仍需人工确认。
- 展示顺序：超时 → 临期 → SLA 内 → 无 SLA；不是审批优先级。

## 2. 数据质量
- 输入记录：6。
- 有效活动项：4（Q-101—Q-104）。
- 无效活动项：1（Q-105 的提交和节点进入时间晚于统计时点，排除时间与 SLA 计算）。
- 终态排除：1（Q-106 已批准）。
- 重复 ID：0。
- SLA 计算分母：3（Q-101、Q-102、Q-103 有有效 due_at）；无 SLA 1（Q-104）。

## 3. 队列总览
- 原始状态（有效活动项 n=4）：待审批 3，补件中 1。
- 类型（n=4）：采购 2，权限 1，办公用品 1。
- 当前节点（n=4）：财务负责人、业务补件、安全评审、部门负责人各 1。
- SLA（可计算 n=3）：已超时 1，临近到期 1，SLA 内 1。

## 4. SLA 与龄期看板
| ID | 状态/节点 | 总龄期 | 节点龄期 | 截止与差值 | SLA 状态 | 依据 |
| --- | --- | ---: | ---: | --- | --- | --- |
| Q-101 | 待审批/财务负责人 | 96h | 72h | 07-18 09:00；超出 48h | 已超时 | due_at 与统计时点 |
| Q-103 | 待审批/安全评审 | 64h | 24h | 07-20 17:00；剩余 8h | 临近到期 | 剩余不超过 12h |
| Q-102 | 补件中/业务补件 | 21h | 15h | 07-21 12:00；剩余 27h | SLA 内 | “补件中”不额外暂停 |
| Q-104 | 待审批/部门负责人 | 1h | 1h | 无 due_at | 无 SLA | 不按其他记录补值 |

## 5. 缺件与依赖
- Q-102：缺第二份报价，依赖申请方补交；不得把积压归责于“业务补件”节点。
- Q-103：依赖安全架构意见，输入预计今日 15:00；该时间是依赖预期，不是审批完成承诺。
- Q-101、Q-104：输入未列缺件或依赖；不能证明系统外没有其他阻塞。

## 6. 升级候选
- Q-101：已超时 48h，达到“至少 24h、无有效暂停”的用户规则。建议人工核对当前状态和数据新鲜度后，再按现有流程决定是否升级。
- Q-103 尚未超时；“临近到期”不等于符合升级规则。

## 7. 建议跟进
1. 核对 Q-101 在 08:50 导出后是否已有处理，并由审批协调角色人工判断是否发起升级。
2. 确认 Q-102 第二份报价的补交状态；不声称已催办。
3. 在 15:00 后核对 Q-103 的安全架构意见及 17:00 截止风险。
4. 为 Q-104 确认是否存在正式 SLA；确认前只展示龄期。
5. 修正 Q-105 的未来提交/节点时间后重新计算。

## 8. 排除与待确认
- Q-105：时间无效，当前不能判断龄期或 SLA；需确认日期、时区或导出错误。
- Q-106：按输入终态定义排除，不代表审批队列数据错误。
- 本摘要未批准、拒绝、催办或升级任何记录，也未判断个人责任。

示例的计数、龄期、剩余/超出时长和升级判断全部由示例输入推得；没有将展示顺序写成审批优先级。

质量自检

• 统计时点、时区、来源、导出时间和数据新鲜度是否明确？
• 有效活动项、无效项、终态及 SLA 分母是否分开？
• 总龄期、节点龄期和最后更新时间是否未混用？
• 工作时间、暂停、临期、状态映射和升级门槛是否均有用户规则？
• 超时是否被错误解释为拒绝、优先或责任归属？
• 建议跟进是否仍是建议，没有伪装成已发送、已升级或已审批？

常见问题（FAQ）

• 没有统计时点怎么办？ 先询问；未固定时点和时区不能计算龄期或 SLA。
• 补件中是否自动暂停 SLA？ 不能默认。只有明确规则和暂停区间时才扣除。
• 工作日 SLA 能按自然小时算吗？ 不能。缺工作日历、起算和暂停规则时标无法计算。
• 超时是否表示驳回或处理人失职？ 不是。它只表示超过给定截止或 SLA。
• 能直接催办、升级或批准吗？ 不能。本技能只给草稿和依据，动作由有权人员按现有流程执行。
• 数据很多怎么办？ 分批时保持同一统计时点、时区、映射和来源编号，最后统一去重与重算。

已知限制

• 不能验证导出后状态、系统配置、工作日历或审批人的实际动作。
• 不能替代组织的正式 SLA、优先级、暂停和升级政策。
• 不自动访问 OA、工单、邮件或通讯系统，不发送或写回任何内容。
• 全中文、无脚本、无海外 API 依赖。