请假申请系统设计：实现清晰的政策与审批

大多数请假流程会出什么问题

人们期望请假申请的体验像预订会议：选择日期、看到余额、得到清晰的批准或拒绝，并且结果能在需要的地方同步显示。当不能这样工作时，团队就会退回到“直接发消息”的做法，系统变成了记录工具而不是可靠的流程。

申请通常卡在交接环节：邮件线程找不到正确的经理、没人更新的电子表格，或无法审计的聊天批准。员工以为自己已经批准，经理以为人力会处理，人力在发薪时才发现余额有误。

请假申请系统设计的真实目标很无聊但很重要：准确的余额、清晰的批准，以及一个单一可信的数据源。如果余额正确但审批不清楚，经理会一直问“我是不是已经批准了？”如果审批完美但日历不对，团队仍会出现冲突。

四类人依赖同一套工作流，但目的不同：

• 员工：快速申请、即时状态、并且确信被记录
• 经理：正确的申请被路由到他们手上，并提供足够的上下文以作决定
• 人力/薪资：一致应用政策且余额与薪酬规则匹配
• 业务方：团队可见性，而不暴露隐私细节

“可读的工作流”意味着你可以查看步骤并用普通语言解释：是什么触发申请、谁来审批、被拒绝会发生什么、以及哪些数据会回写（余额、状态、日历）。如果无法快速解释，人们就会绕过它。

像 AppMaster 这样的工具能帮助把逻辑可视化并集中管理，这样政策变更就不会变成一堆邮件和例外的迷宫。

所需的基础数据（不要过度设计）

一个好的请假工具主要是一些干净的记录和少数明确的关联。如果把基础做好，其余的在日后扩展政策与审批时仍然可读。

从一些能在一分钟内讲清楚的核心对象开始：

• Employee（员工）：谁在申请请假（以及谁审批他们）。
• TimeOffRequest（请假申请）：实际的申请（日期、类型、状态）。
• Policy（政策）：某种假期类型的规则（PTO（带薪休假）、病假、无薪假）。
• Balance（余额）：员工在某政策下的当前可用额度。
• Approval（审批）：与申请关联的决定和评论。

对于申请，本能避免痛点的字段并不花哨，而是具体：存储开始和结束日期/时间、是否为部分日、以及申请时员工的时区。加上一个简短理由，并在需要时允许上传附件（例如病假条）。将附件设为可选，以免阻塞正常的带薪休假。

状态应少且可预期：draft（草稿，已保存但未提交）、submitted（已提交）、approved（已批准）、rejected（已拒绝）、canceled（已取消）。除非必要，避免像“pending HR”这样的额外状态。

不要跳过审计轨迹。即便是最小的“谁在何时改了什么”也能在争议中救你一命。至少要记录提交、批准、拒绝、取消和任何日期修改。

将团队、地点和部门作为独立的参考数据。把员工关联到这些组，把政策关联到适用的组。这样当有人换办公室时，只更新一条员工记录，而不是每条政策。

如果在 AppMaster 中构建，先让每个对象保持简单，然后在数据稳定后再添加校验与工作流步骤。

政策规则：保持清晰且可测试

好的政策故意很枯燥。人们在点击提交前应该能预测结果。在请假申请系统设计中，最容易失去信任的是同一条申请有时被批准有时被拒绝。

从命名假期类型并为每种写一句简单的话开始。比如：Vacation 或 PTO（带薪休假）是计划内的离岗；Sick leave（病假）是非计划的健康相关；Unpaid leave（无薪假）不支付工资；Parental leave（产假/育儿假）通常有特殊日期和文件；Comp time（调休）由加班换来，使用方式类似 PTO。

资格规则应该像清单而不是法律文件。明确：谁能用（全职、兼职、合同工）、何时生效（试用期后、X 天后）、是否依赖工龄。如果有例外，把例外写成单独规则而不是脚注。

申请规则是混乱常起点。具体说明提前通知期、禁用日期和最小时间单位。例如：“休假需提前 5 个工作日提交，紧急情况由人力审批除外”就是可测试的。“尽早提交”就不行。

结转与过期规则应能放入一句话。例如：“最多 40 小时结转到下一年，并于 3 月 31 日过期。”若需要第二句，那说明政策已经过于复杂。

保持政策文本和规则逻辑同步的简单方法：

• 给每条规则一个短 ID（如 PTO-NOTICE-5D）
• 在规则配置旁存储和规则一致的普通语言文本
• 为每条规则添加 2 到 3 个示例用例（通过或拒绝）作为测试
• 只有当规则配置变更时才修改政策文本（反之亦然）

举例：处于试用期的员工申请明天 2 小时的 PTO。系统应以两条易读信息阻止申请：“PTO 在 60 天后生效”和“PTO 需要提前 5 个工作日通知”。在 AppMaster 中，把这些消息放在规则节点附近可以防止更新过程中的漂移。

累计计算：容易导致混淆的模式

累计（accrual）是请假系统常变得混乱的地方，因为小规则叠加会导致复杂性。目标不是复杂的数学，而是与人力和员工预期一致的、可预测的结果。

一个常见混淆是混用累计方式。公司有的按发薪期累加小时、有的按月累加、有的按工作小时累加、有的在固定日期一次性发放年度额度。问题在于只存“余额”却忘了“如何获得”的记录。保持清晰的事件记录：grant（发放）、accrue（累计）、adjustment（调整）和usage（使用）。

按比例分配（proration）是另一陷阱。中途入职或从兼职转为全职的员工不应该需要人工表格修正。选定一种规则并坚持执行。例如：按期间内的日历天数按比例，或按排班小时按比例。无论选哪种，用普通话写清并在系统中统一实现。

上限与负余额会产生“看起来不对”的工单。如果允许结转且有上限，需在具体时刻应用上限（年末、累计期末或每次累计后）。若允许负余额，定义限额及离职时的处理规则。

四舍五入规则会产生无声的漂移。选择一个统一的四舍五入单位（分钟、15 分钟或半天），并在累计与使用上保持一致。如果累计以分钟为单位但申请以半天为单位，员工会觉得系统总是不对。

回溯申请与更正需要审计。若有人提交上周的请假，系统应从申请日期向前重算并记录变更。

一个简单的核对清单能防止大多数争议：

• 将余额变更记录为带日期的交易，而不是单个数字
• 当政策输入变更时，从生效日期重新计算
• 在一个共享函数中应用上限与四舍五入
• 将人工调整与累计逻辑分开
• 对任何显示的余额都标注“截至日期”

在 AppMaster 中，这通常对应一个 Transactions 表，加上在批准或更正时重算余额的小型业务流程。

经理审批：简单路由同时覆盖边缘情况

经理审批工作流应回答一个问题：谁有权自信地说“同意”？如果试图建模每一个组织结构细节，请假系统会变得难以阅读且更难修复。

从一个默认规则开始：由员工的直接经理审批。然后仅添加那些确实改变风险或责任的例外。保持规则顺序明确，以便在不翻设置的情况下解释结果。

单步与多步审批

大多数团队对标准 PTO 使用单步审批即可。仅在请求影响薪酬、合规或跨团队覆盖时才增加步骤。

可读的常见模式：

• 单步：经理审批标准 PTO 和无薪假。
• 两步：经理后 HR，对需要文件或政策核查的假期类型使用。
• 第二审批人：仅在缺席影响共享覆盖（如值班轮换）时加入部门主管。
• 自动批准：低风险请求，如 1-2 小时的预约，或已在日程中预先批准的时间。
• 无经理：对合同工或无明确经理的角色由人力直接审批。

委派、拒绝与重提

当审批人不在时审批会断裂。把委派作为一条第一类规则，而非人工变通。如果经理被标记为休假，路由给代理；若无代理，路由给经理的上级（或以人力为后备）。始终记录哪个规则选了该审批人。

拒绝与编辑是系统变得混乱的地方。保持简单：拒绝关闭申请并要求理由。如果员工编辑了日期或假期类型，则视为重新提交并从头运行路由。这样可以避免“半批准”的申请在内容与批准不符时存在。

一个实用例子：Alex 申请 3 天病假。系统将其路由给经理，但由于这是受政策控制的假期类型，人力在经理批准后再进行第二步审批。如果经理不在，由代理审批，且审计轨迹显示原因。

如果在 AppMaster 中构建，把路由逻辑放到一个可视化流程中，并用一小组明确的规则排序，这样任何人以后都能阅读和维护它。

在放行申请前的校验规则

好的校验让请假系统保持可读，因为它防止了特殊情况渗入审批。目标是易解释、易测试的规则。

从预约规则开始。重叠检查应能捕捉与已有批准假期及待审批申请的冲突。对部分日要明确：存储日期并加上简单单位如上午/下午或小时，以免半天被误算为整天。还要决定对周末和公司假期的处理：阻止它们或允许但在天数统计中忽略。

余额校验比看上去复杂。很多团队在提交时校验余额（防止刷申请），并在批准时再次校验（因为累计和其他审批可能改变余额）。若两处都校验，应向用户显示哪个环节失败。

这里是一组覆盖大多数情况的校验规则：

• 日期有效（开始在结束之前、相同时区、未缺失半天选择）
• 与现有假期（包括半天）不重叠
• 天数统计排除周末与假期（根据你的政策）
• 特定假期类型要求附件时已上传（例如病假条）
• 余额充足（提交时检查，并在批准时再次检查）

团队覆盖检查有帮助，但除非必要，否则避免强制阻止。更好的默认是给经理一个警告，让其决定。例如：“你团队已有两人那天请假。仍要提交吗？”

使错误信息公平且可修复。告诉用户哪里失败、为何失败以及如何修改。例如：“你的申请与 3 月 12 日（下午）的一次已批准 PTO 重叠。请选择其他时间或编辑现有申请。”

在 AppMaster 中，把校验放在申请表单附近并在审批步骤重用相同检查，以防规则随时间漂移。

分步流程：一个易于构建与维护的工作流

一个好的请假系统设计在最好的状态下显得枯燥：每个申请遵循相同路径，每个决定都有唯一明确的理由。保持可读性的最简单方法是把政策数据（规则是什么）与工作流逻辑（点击提交后发生什么）分开。

下面是即便增加更多假期类型也仍然简单的序列：

• 把每种假期类型和规则放在同一处（名称、资格、结转、禁用期）。若规则没写在这里，就不应存在于其它地方。
• 把余额建模为时间线而不是单一数字。存储期初余额、已获得（累计）、已用和调整，以便解释任意日期的余额。
• 在申请表单上做早期校验。校验日期、部分日、重叠、通知期，以及“在开始日之前是否有足够余额”，在审批前就完成这些检查。
• 使用一小组角色（员工、直接经理、人力）路由审批。把例外作为数据（如“超过 10 天需 HR 复核”）而非硬编码特例。
• 仅在批准后创建日历事件，并把它们视为可同步的记录，便于在申请变化时更新或取消。

通过用普通语言记录每次决定（例如：“拒绝：与已有批准假期重叠”）来保持可读性。如果使用 AppMaster 的业务流程编辑器等可视化工具，请把步骤命名为人能读懂的方式。

上线前，用真实场景测试：回溯申请、经理休假、年中政策变更、批准后编辑。如果结果让人力惊讶，说明规则还不够清晰。

能长期保持准确的日历集成

日历应快速回答一个问题：谁在外、何时外出。不要把日历事件当成完整的申请记录。仅放入有助于排班的信息，把其余内容保留在 HR 系统内。

事件内容要保持一致。一个好的默认值是简短标题如 “Out of office - Alex Kim”，若假期类型重要可加上类型（“PTO”、“Sick”）。为保护隐私，细节保持最小。很多团队喜欢把事件显示为“忙碌”，而把理由、余额和备注仅保存在申请中。

把日历事件当镜像而非来源

每个申请都需一个稳定的内部 ID，且每个日历事件应存储该 ID（比如放在自定义字段或描述中）。这样在申请变化时，你可以安全地创建、更新或删除对应事件。

处理状态是系统漂移的常见原因。事先决定是否展示待定申请。如果展示，区分方式要明显（例如标题前缀 “Pending” 与不同的可用性设置）。批准后更新同一事件而非创建新事件。若申请在可见后被取消或拒绝，删除该事件以免日历显示虚假信息。

时区与“怪异”日期

时区是关于整天与部分日请假时最棘手的问题。将开始和结束存为员工本地时区下的精确时间戳，并在申请上同时存储该时区。

仅当确为整天请假时使用全日事件。部分日使用有时段的事件（例如 13:00-17:00），让其他时区的同事也能看到正确的重叠。

• 整天：以员工时区的全日事件
• 部分日：带开始与结束时间的有时段事件
• 多日：全日事件通常可行，但双重确认结束日期是含还是不含

若日历同步失败，不要屏蔽错误。把任务排队、带指数退避重试，并显示清晰的“日历未更新”状态与手动“重试同步”操作。在 AppMaster 这通常是个后台进程加一个管理员界面，用于列出失败的同步尝试，让人力在不改申请的前提下修复问题。

常见错误与避免方法

大多数请假系统失败的原因是规则在悄悄增长。系统仍在“工作”，但没人信任余额，每个奇怪情况都变成支持工单。

错误 1：累计逻辑埋在例外里

如果累计被拆分为许多特殊情况（新入职、结转、无薪、兼职），人们就无法预测余额。

为每种假期类型保留一个清晰的累计模型，然后把例外作为命名且可测试的规则。写下若干示例员工并列出特定日期的期望余额，每次政策变更都重新校验。

错误 2：审批流程无限分叉

无尽的分支审批让测试变得不可能，经理也不知道为什么申请到了别人手上。

更安全的模式是：

• 一个默认审批人（通常为直接经理）
• 基于简单条件的可选第二审批人（HR 或部门主管）
• 审批人不在时的明确后备（代理或上级）
• 每个申请只有一个最终状态（approved、rejected、canceled）

错误 3：把政策文本与计算混在同一字段

政策文本用于人阅读（什么算数、谁有资格），数学规则用于系统（速率、上限、四舍五入、结转）。把它们分开存储，这样能在不影响计算的前提下更新文案，也能在不改文案的前提下测试计算。

错误 4：编辑与取消没有记录

若直接覆盖申请，你就会丢失导致余额变化的“原因”。

始终保留审计轨迹：谁在何时更改了什么，以及之前的值。在 AppMaster 中，这可以通过请求历史表与业务流程中的状态转换来建模。

错误 5：把时区与假期当成事后思考

请假跨日期，但审批与日历使用时间戳。统一归一到一个“政策时区”，并同时存储员工的本地时区。还要事先决定公共假期是否减少申请天数，并一致应用该规则。

上线前的快速核对清单

在向全员宣布之前，与一名员工、一名经理和一名人力成员一起做一轮简短检查。你要确认系统看起来直观，而不仅仅是能运行。

将此清单作为请假系统设计的上线门槛：

• 余额可见性： 员工能看到今日余额以及即将批准的请假如何影响余额（以免后来发现负余额）。
• 政策清晰： 每条规则用普通语言写明（结转、禁用日期、最短通知期、半天规则），且逻辑与文字完全一致。
• 有用的校验： 当申请被阻止时，提示说明如何修改（日期、假期类型、小时、缺失附件），而不是仅显示“错误”或“不允许”。
• 经理就绪的审批： 经理能在一屏内审批并看到足够上下文（剩余额度、团队冲突、移交说明），并能在不来回多次沟通的情况下请求更改。
• 日历与审计： 在批准、更改与取消时创建并保持日历事件同步，且每次状态变更都记录是谁在何时做的。

一个快速实测：创建一条申请、批准、修改日期，然后取消。若任何一步留下错误余额、陈旧的日历事件或无解释的状态，先修复再上线。

若使用 AppMaster，把每一步命名为用户动作（Submit、Validate、Route to Manager、Update Balance、Create/Update Calendar、Log Event），以便政策演进时行为仍清晰。

示例场景：从申请到日历邀请

新员工 Maya 在 3 月 10 日入职。你的请假系统支持按月累计，因此 Maya 在每月第一天获得 PTO。4 月 12 日，她为下周五的医疗预约申请 3 小时的部分日请假。

每个人看到的内容不同：

• 员工（Maya）： 当前余额、此申请将使用的小时数，以及如果会导致负余额的明确警告。
• 经理： 简短摘要（日期、小时、覆盖说明）以及批准、拒绝或委派的选项。
• 人力： 用于计算的政策、审计轨迹，以及在规则变更时重新计算余额的方式。

Maya 提交申请。她的经理正在休假，系统检查委派设置并将其路由到代理经理。代理批准。

批准时发生两件事：申请被锁定到当时使用的政策版本，并为该日期和时间窗口创建一个“ Maya - PTO（3 小时）”的日历事件。Maya 立刻看到 “已批准” 且日历状态为“已添加”。

到六月，人力在年中更新政策（例如 90 天后累计增加）。余额需重算，但已批准的历史申请不应被悄然更改。系统应从生效日期向后重算 Maya 的当前余额，并保存变更前后的审计记录。

一周后，Maya 更改了申请日期（预约改期）。由于该请假已批准，此次更改成为一个新的“变更申请”，需返回给代理审批。再次批准后，更新原有日历事件（使用相同事件 ID），而非重复创建。

在 AppMaster 中把这些建模得很容易：保持可读的工作流：一条审批路径、一次委派检查、一次日历创建/更新步骤，以及当人力需要时可运行的单独重算动作。

下一步：先发布第一个可迭代的版本

完成请假系统设计最稳妥的方式是先发布一个可被信任的小版本，然后再扩展。从一个政策（例如 PTO）和一条审批路径（员工 -> 经理）开始。一旦它变得枯燥且可靠，再添加下一个假期类型、地区或边缘案例。

在构建更多规则前，先决定真相来源在哪儿。如果你的 HR 系统是主记录，你的应用应主要做校验、路由审批并把结果同步回去。如果你的应用是主记录，就需要更清晰的审计日志，并制定当 HR 数据（新经理、部门变动、离职日期）更改时的处理计划。

一个实用的第一版计划：

• 实施一种假期类型，明确余额和单一累计规则。
• 添加一个经理审批步骤和一个人力覆核路径。
• 只为已批准的请假做简单的日历同步。
• 保留一个管理员界面，使非技术负责人能读懂政策设置。
• 添加基础报告：谁在外、即将到来的缺席。

写下 5 到 10 个真实测试用例，并在每次变更后重跑。用自己团队的真实案例，而非假设场景。例如：有人在周四为周五请假、有人在批准后修改申请、经理在不同时间区审批等。

如果使用无代码工具，可视化的可见性与功能同等重要。在 AppMaster 中，你可以把数据模型（假期类型、余额、审批）和审批工作流放在可视化编辑器里，让人力与运营确认系统实际行为。你也可以在策略演进时导出干净的源码或暴露 API，而不必在旧修补上堆砌补丁。

当第一个版本稳定后，每次只扩展一个维度：先更多的假期类型，再更多的路由规则，最后是更多集成。