CHENGWAY.WANG制造业企业用排班制考勤，但排班这件事在客户那里经常不发生：班组长在产线上没空进系统，HR 离产线几十公里。员工的打卡记录是全的，班次是空的——考勤和工资都算不出来。
旧版自动对班已经在做这件事，但它按单个班次逐条打分：能覆盖白班、长白班、夜班这些常规组合，一涉及跨天和多班段衔接就断。这已经造成客户丢单和退款。
这次重构把匹配单位换成"多班段组成的候选链路"，同时改了输出方式和确认机制。2025 年 9 月上线。
| 角色 | 产品 + 项目负责人 |
|---|---|
| 周期 | 2025.06 – 2025.09 |
| 团队 | 6 人研发团队，4 个月立项到上线 |
| 范围 | 对班规则重构、结果确认机制、打卡记录展示、考勤组设置与通知 |
1. 重构前：单班次打分，跨过 0 点就断
旧版的做法是三条优先级判据逐条筛：
- 打卡是否落在班次的有效打卡时段内
- 首末打卡的时段跨度与班次起止的匹配度
- 打卡点与上下班时间的接近程度
比完一个班次就算完，没有"多个班段串成一条链路"的概念。
问题集中在跨天和多班段衔接——过了 0 点，系统按新的一天算，一个班次的上半段和下半段被拆到两天里。
跨天和复杂班次算不对，直接影响客户的采购决策和交付验收。
另外两处也在放大风险：取最高分直接生效，几乎不需要审核；得分并列时随机取一个。
2. 四步规则，把"为什么是这个班次"讲清楚
反推班次的难点在于一笔打卡可能匹配多个班段，跨天班次的归属日有三种可能，同一归属日还可能有多条都成立的路径。规则要能回答"为什么是它"。
方案分四步：
- 取卡：取近 4 天的打卡记录，为近 3 天匹配班次，排除已排班、已确认和已审批调班的时段。
- 候选匹配：按班次里各班段的规则匹配打卡记录；跨天班次分别尝试计入前一天、当天和后一天。
- 生成链路：把属于同一班次、计入同一天的候选记录组合起来，要求班段编号不往回跳，并排除缺卡的组合。
- 择优：对计入同一天的组合评分，选出最优结果。
评分规则写在方案里，可审计：正常卡加分，迟到、早退扣分，打卡时间越贴近班次得分越高；具体权重见方案文档。得分并列时不随机选一个，判为"无匹配班次"，把排名靠前的作为备选交给确认人。
从每次打卡就计算，改为每日四次更新
旧版每次打卡都会触发计算，员工能立即看到班次，但打卡还没完成时，结果也可能继续变化。对于后续要核对考勤的 HR，这样的即时反馈反而增加了判断负担。
我将自动对班改为每天 02:00、10:00、15:00、20:30 四次更新，员工打卡时不再实时显示推算班次，并在结果页标明更新时间。这样，员工知道结果何时更新，HR 也能判断眼前的结果是否已经包含最新打卡。定时更新不能消除缺卡等问题，仍需要结合提示和确认机制处理。
保留当次打卡快照，让异常有据可查
发现班次不对时，HR 需要知道系统当时用了哪些打卡，而不只是看到一个班次名称。我在打卡明细抽屉中展示当次对班的历史快照：每笔卡的日期、时间、正常或异常状态，以及匹配到哪个班段的上班或下班，同时标明结果更新时间。
后续打卡被修改或删除，也需要保留解释原结果的依据：下次对班有结果时更新快照，没有新结果时继续展示原快照；被删除的卡标记“已删除”。HR 可以据此核对，是打卡数据发生了变化，还是原来的班次匹配需要调整。
3. 自动化不等于免检
推出来的班次直接影响打卡取值和工资核算。新版在"自动"后面加了一道确认：结果推送给确认人和 HR，人工核对后生效，3 天未操作则系统自动确认。确认只影响后续取哪段打卡参与核算，不反向改写排班表——这条边界在方案里写死，避免"确认"被理解成二次排班。
确认有三个入口：HR 在后台批量处理，确认人在 PC 端逐人核对，也可以在移动端利用零散时间处理。备选班次按评分给前三名，其余班次放在下一组，确认人能看到"系统还想选什么"。
4. 边界分三层摆在明面上
对班结果连着工资，已知问题不能收在发布说明的角落。这些问题分三处说明：
- 结果列表顶部：提示容易算错的情况——缺卡、员工尚未下班就匹配班次、开启弹性打卡。"无匹配班次"的提示直接引导去检查缺卡。
- 开通弹窗：说明三个使用前提——先手动排昨天或今天的班、班次别开弹性设置、请假外出出差要提前手动排班。
- 功能限制：本期不支持弹性设置；上下班重复打卡会被判成迟到卡；班次匹配与考勤核算的执行频率不同，部分展示会滞后。低频场景保持逻辑简单，不加特判。
分级标准只有一条：会直接算错工资的边界，必须出现在用的人眼前；只影响展示节奏的，留在文档里。
5. 结果
上线 4 个月累计完成 89.5 万次自动对班；结果正确率 98.84%；在 1,156 家排班活跃企业中，实际使用的企业从上线前约 10 家增长到 277 家，覆盖率约 24%。
班次判定采用确定性规则：规则虽然复杂，但判断条件明确，出错会直接影响工资核算，这部分没有采用 AI。
AI 主要用于研发验证。研发对可行性存疑时，先用 AI 辅助推演规则，再用 AI Coding 跑通排班算法原型，推动 6 人团队 4 个月完成立项到上线。
这套"AI 辅助方案 → 原型验证 → 研发交付"的方法，后来复用到了 AI 入职和 AI 员工助手。
6. 可迁移的判断
这个项目里，我需要一起设计的，是班次怎么匹配、什么时候更新、出错后如何核对和修正。定时更新让结果的变化有预期，历史快照保留判断依据，备选班次和确认入口帮助人继续处理。以后遇到考勤、薪酬或对账这类结果影响资金的场景，我会先明确这些环节，再判断哪些交给规则处理、哪些需要人工介入，以及 AI 能在哪一步提供帮助。
需求界定同理：先确认客户说的是事前分配（排班）还是事后归属（对班），再谈方案。排班发生在事前，决定"人该上哪个班"；对班发生在事后，决定"这笔卡属于哪个班"。这个项目只做后一层。