---
date: 2026-05-08
module: dingtalk / employee-management
type: pattern
---

# 司龄/年假这类业务规则：先跟 HR 对口径，再写代码

## 现象

司龄计算口径在 48 小时内被改了两次：

- 2026-05-07 PR #241：在 AI 自查"为什么停薪不扣司龄"后，把代码改成"停薪扣司龄"，并写入文档、加了 5 个 L1 测试锁公式。
- 2026-05-08：用户与 HR 二次确认，**停薪计入司龄**才是正确口径。整 PR 回退（本 PR）。

两次方向都"看起来合理"，但**正确答案只有 HR 知道**。

## 根因

把"钉钉自带的司龄字段扣停薪"当成业务规则的事实源——这是钉钉 app 实现，不是公司 HR 规则。两者可以不同。

AI 在没有可信业务来源时，倾向用"上游系统怎么做"或"代码注释怎么写"作为锚点；这些都不是 HR 规则的事实源。

## 应对

业务规则类改动（司龄、年假、加班、考勤、薪酬…）开工前必须满足之一：

1. `docs/modules/{module}/` 文档里**写明规则 + 来源（HR / 制度文件 / 确认日期）**；
2. 用户在本次会话里明确确认；
3. 没有以上两条 → **停下问用户**，不要自己从代码现状推断"应该是什么"。

锁公式的集成测试也只有在规则被确认后才有意义——否则测试会把错误口径锁死，下次改方向时同样要回退。

## 二阶教训

**先 fetch develop 再回答**。本次 AI 第一轮回答是基于本地分支的旧代码，没看到 PR #241 已合并，导致结论与现状脱节。CLAUDE.md 已加规则："所有处理之前先检查是否拉的最新代码"。