---
date: 2026-05-14
tags: [workflow, gitea, issue-management, ai-workflow]
---

# 开工前先查 commit history，避免做"工单已 open 但代码已落地"的重复工

## 现象

接手 #316（[ai-review] D4 退出 DRY RUN 转正 → required check）准备开工。工单 open，事项列表三条（改 yml、改 Gitea 保护、同步两份 docs）看起来都没做。准备改 `.gitea/workflows/ai-review.yml` 删 `AI_REVIEW_DRY_RUN: '1'` 那行——

`grep AI_REVIEW_DRY_RUN .gitea/workflows/ai-review.yml` 结果只剩一行**注释**："如需临时回退，将 `AI_REVIEW_DRY_RUN: '1'` 加回..."。线已被删，只留注释教人怎么回退。

`git log -- .gitea/workflows/ai-review.yml` 查到 commit `2a5d35fb`（2026-05-11 15:21）"feat(ai-review): 退出 dry-run 转正为 develop required check (#171)"——**#316 工单创建当天 14:31，commit 15:21**，差 50 分钟。代码改完了，相关 docs 同步了，Gitea 保护规则 API 验证 `enable_status_check=true` + contexts 已含 ai-review，但 **#316 工单一直 open**。

如果没核查直接 `Edit` yml 会得到"old_string 找不到"错误才反应过来；更糟的是有可能不小心把无关行改错。

## 根因

1. **工作流断点**：上次执行者（commit author 是 `Chentao Jia`）做完了 D4 的全部代码工作，commit message 引用 `#171`（衍生工单）但**没引用 #316**，工单自动关闭机制（`Closes #N`）失效
2. **工单创建时机晚于实际开工**：#171 的执行者已经在动手做 D4，过程中才补建 #316 / #315 / #317 三个子工单做拆解，但工单一开就被 commit 越过去了
3. **没有"开工前先查"的硬性步骤**：AI / 人都倾向于"读工单 → 立即按事项列表干"，跳过"事项列表里的事是否已经完成"的核查

## 教训

**开工前的核查步骤（强制）**：

任何接手的工单，**动代码前**先做这 3 步：

```bash
# 1. 工单号 grep commit message
git log --all --oneline | grep -iE "#316|316\b"

# 2. 工单 body 提到的关键文件 grep 最近 commit
git log --oneline -- .gitea/workflows/ai-review.yml | head -5

# 3. 工单 body 提到的关键字符串当前状态
grep -n "AI_REVIEW_DRY_RUN" .gitea/workflows/ai-review.yml
```

任一查出"已完成"的迹象，**先停下确认**而不是直接 Edit。

**Commit message 引用工单号要全引**：commit body 如果涉及多个工单（#316 / #171 / #259），全部引用 `Closes #316`、`Refs #171, #259`，让自动关联生效；工单层级关系（衍生工单）写在 commit body 里也方便溯源。

**衍生工单要在 commit 里有交代**：拆分工单（衍生 X/Y）的目的是细化追踪，但如果实际工作合并在一个 commit 完成，commit message 要明确说"#316 + #315 + #317 三步合并在本 commit 一次推完"，否则后人会以为子工单还没动。

## 应用范围

- AI agent 接手任何 issue 时
- 团队成员准备开工前
- 跨周期接手他人未完成工单（最高发场景）

## 关联

- 本次发现的具体工单：#316（实际已在 2026-05-11 完成，2026-05-14 才发现并关闭）
- 关联 learning：[[2026-05-11-gitea-enable-status-check-stuck-false]]（同一波 D4 工作里发现的另一个工程化漏洞）