团队级 Code Review Skill 实践：4个人、4个AI、1套规则，CR从找bug变成做决策

上周四，我盯着一条PR评论看了三分钟。那条评论不是我同事老张写的，是他的AI自动生成的。它引用了transaction.md第三条规则，指出我代码里一个@Transactional方法内部调了Redis------建议把删除缓存挪到afterCommit回调里。更扎心的是，我还没反应过来，我自己的AI秒回："已确认，修改见commit 8f3a2b。"

两个AI替我完成了一轮Code Review。从头到尾，我只点了一次"合并"。

把个人五关审查Skill共享给团队三个人，每个人往里加了自己的规则。四周之后，PR流程自然演变成"AI审AI"：作者侧的AI预审、reviewer侧的AI全量扫描，人只看架构决策。

这篇文章聊这个流程怎么自然形成的、代码层面的具体变化、以及团队Skill仓库的维护方式。

从一个人到四个人的 Skill

前一篇《五关清单吃灰3周后，我让AI自己按我的规则写代码》写完，我把code-review-gate Skill给了团队三个同事。老张做数据中台，老周做网关和权限，小何三年经验。

三个人看完源码之后的反馈各自不同，方向非常明确：

• 老张 ：并发规则太保守，数据中台批量任务冲突率不到千分之一，行锁是多余开销，在concurrency.md加了批处理豁免条件。
• 老周 ：security.md缺SSRF防御，网关转发接口传个http://127.0.0.1:8080/actuator就能打穿内网，加了host白名单和私有IP过滤。
• 小何 ：null-safety.md漏了MQ心跳包场景------eventType字段90%有值，心跳包时为空，他线上炸过两次，用Optional.ofNullable()兜住。

当天晚上把三个人的补充合进GitHub仓库，建了team-code-review/目录。结构不变，还是五关，但每条规则后面标了来源：

## 批量RPC分批复核
- 规则: 批量RPC调用超过50条时，必须分批并记录checkpoint
- 来源: 老张, 2026-06-18
- 触发: 数据同步接口1000条批次RPC超时，全批次失败

区分规则来源很重要------规则打架时，知道找谁聊。

加载机制不用额外配置：个人Skill放 ~/.claude/skills/（跟着人走），团队Skill放项目根目录 .claude/skills/（跟着仓库走）。Claude Code两个位置都会扫，所以每个人的AI天然同时加载两套规则。

四步PR流程（自然演化，不是设计出来的）

跑了两周之后，整个流程自己定了型：

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ 写代码    │ → │ PR前自查  │ → │ AI扫描   │ → │ 人工CR   │
│ 个人Skill │    │ 作者AI审查│    │ reviewer │    │ 只看架构  │
│ 团队Skill │    │ 全量扫描  │    │ AI审查   │    │ 和决策    │
└──────────┘    └──────────┘    └──────────┘    └──────────┘

先交代胶水层：AI 怎么自动评论 PR

Claude Code 自己不会在 PR 上发评论，开头场景靠的是一层 GitHub Actions 胶水：PR 一提交，CI 就触发 headless 模式扫描 diff，输出格式化成评论。

on:
  pull_request:
    types: [opened, synchronize]
jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: AI 扫描 diff
        env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff
          claude "加载 team-code-review 规则审查 pr.diff，按'第X条规则触发，建议查看'格式输出" > review.md
      - name: 发布到 PR 评论
        env: { GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} }
        run: gh pr comment ${{ github.event.number }} --body-file review.md

关键三点：pull_request 事件触发、无交互模式扫 diff、gh pr comment 回写结果，reviewer 侧 AI 自动回复也是同一套。胶水不值钱，值钱的是它让"AI 审 AI"从手动操作变成了默认流程------落地时记得加一层保险，只让 CI 回应非机器人账号的评论，否则两个 AI 会互相回复到账单爆炸。

第一步：写代码阶段

每个开发者的AI同时加载个人Skill和团队Skill。生成代码时就避开已知坑。效果类似于新员工入职第一天背熟了全组的事故报告。

第二步：PR前自查

提交PR之前，作者侧AI对diff做全量扫描。违反规则的地方自动标注，能自动修的就修，修不了的标注[人工判断]。这一步的意义不在于"问题都能自动修"------修不了的是大多数------而在于让作者在别人看到代码之前，先知道自己违反了自己写的哪条规则。

第三步：reviewer侧AI扫描

reviewer的AI加载团队Skill，对diff再做一次全量扫描。输出格式不写"这里不好"，而是"第X条规则触发，建议查看"：

## AI Review Summary
- ✅ 第一关（需求评审）：已确认并发模型、上游输入、失败语义
- ✅ 第二关（并发安全）：设备阈值更新使用行锁，通过
- ⚠️ 第三关（事务边界）：见下方评论
- ✅ 第四关（空指针）：外部输入已判空
- ✅ 第五关（安全检查）：无SQL注入/SSRF/越权风险
- ⚠️ 规则冲突：与老张两周前加的 `team-code-review/concurrency.md` 第2条冲突，批量RPC未记录checkpoint

### 第三关详情
文件: DeviceSyncService.java:42
规则: transaction.md 第3条 --- 外部调用必须在事务提交后执行
问题: `ruleEngineClient.refresh(deviceId)` 在 @Transactional 方法体内
建议: 移入 afterCommit 回调或独立于事务生命周期

第四步：人工CR

审查者只看两样东西：AI标出来的问题，以及AI没标但涉及架构决策的部分。不再在"判空、加锁、格式"上花时间。

源码地址

五关审查Skill和团队协作模板已公开在 GitHub：wangheng19901021/skills

目录分两层：code-review-gate/ 是个人五关审查 Skill（SKILL.md + references/ + examples/），team-code-review/ 是团队级规则扩展，每个人往里加自己的坑。fork 一份，按自己团队的踩坑记录往里面加规则即可。

核心案例：老张自己加的规则，把自己审了

老张写了一个数据同步接口：从MySQL读设备，每100条调一次RPC推送到规则引擎。代码清晰，自己的AI过了------RPC在afterCommit里，transaction.md没问题。

我的AI审的时候引用了规则：

批量RPC调用超过50条时，必须做分批和失败重试，不能在一个事务里打穿整个批次。------老张，2026-06-18

老张加这条规则是因为上个月线上炸过------1000条批次RPC超时导致全批次失败。排查完当天加进去的。

他自己的AI回复："本批次每100条一个子事务，RPC失败不影响已提交子批次。规则已满足。"

我的AI再次回复："子事务间无checkpoint。第9个子批次失败→前8个已提交不可回滚→数据部分同步→无法确定断点续传。建议加checkpoint记录。每个子批次起始处写一条到本地事件表。"

老张最后加了checkpoint------不是AI替他写的方案，是他自己根据引子改的，但没有两条规则打架，这段隐患大概率会带着上线。注意：checkpoint 写在 push(batch) 之后，意味着消费端必须幂等，否则进程崩在中间会重复推送，这条已补进团队规则。

错误写法（老张最初版本）：

// 危险：没有 checkpoint，第9个子批次失败时前8个已提交，无法续传
for (int i = 0; i < devices.size(); i += 100) {
    List<Device> batch = devices.subList(i, Math.min(i + 100, devices.size()));
    ruleEngineClient.push(batch);
}

正确写法（审后版本）：

// 每个子批次成功后写 checkpoint，失败可从最近点恢复
for (int i = 0; i < devices.size(); i += 100) {
    List<Device> batch = devices.subList(i, Math.min(i + 100, devices.size()));
    ruleEngineClient.push(batch);
    checkpointService.save("device_sync", i + batch.size());
}

这个案例的核心不是"AI发现了bug"。是老张一个月前定义的规则，拦住了他一个月后写出的代码。 规则面前，人和AI平等。

代码层面：什么变了，什么没变

变了的三件事

1. PR低价值评论清零。

"这里判null""那里加锁""大括号换行"------这些评论不需要人写了。AI在生成代码时就处理了变量命名、判空、格式化；PR扫描时再兜底一次。人的注意力从"纠错"释放出来。

2. 经验传递路径缩短。

以前：踩坑 → 复盘 → 分享 → 别人记住 → 下次想起来（每个环节都可能断）。

现在：踩坑 → 写一条规则到团队Skill → 所有人的AI自动检查。

小何三年经验的MQ心跳坑，老周十年的SSRF坑，互相保护。三年帮十年，十年帮三年。

3. CR对话从"对不对"变成"好不好"。

真实PR评论摘录：

这个接口QPS预期5000，乐观锁重试三次对数据库QPS影响大概15%，可接受。但重试率超过8%的话建议拆到Redis做，改造量约两天，单独排需求。

------老周，审我的代码时写的。这段话AI写不出来。但让他有精力写出这段话的前提是：AI已经替他审完了所有该审的代码。

没变的三件事

AI能做的	AI不能做的
检查规则是否违反	判断这个功能该不该做
指出规则间冲突	评估改动在当前上下文里的连锁代价
标注风险等级	决定什么时候该违反规则

上周一个紧急需求需要绕过正常流程直接写库。AI标了三条警告，我们点了"手动忽略"。只要还能手动忽略，底线就在人手里。

团队Skill的维护：踩一个坑，加一条规则

维护方式极简：

1. 线上炸了 → 排查
2. 排查完 → 确认根因是不是Skill现有规则能兜住的
3. 不能→在对应reference文件里加一条，标注来源和日期
4. git commit + push → 所有人的AI下次自动生效

不靠Confluence，不靠周会分享，不靠"下次注意"。靠AI每次都读。

注意：新规则 push 后，已启动的 Claude Code 会话可能需要重启或手动刷新 Skill 缓存，才能在当前对话里生效。

总结：Skill = 团队的集体记忆

一个人踩坑自己扛，是常态。一个人把坑写进团队规则，所有人的AI从此避开------这才叫团队。

Skill不是辅助工具，是集体记忆。 不是帮你写代码，是帮你的团队记住所有不该再犯的错。

五关审查Skill公开在 wangheng19901021/skills。你们团队fork一份，按自己的踩坑记录慢慢养。

觉得这套团队协作思路有用，先收藏，拉团队一起落地时能直接对着抄。关注我，下一篇聊紧急需求下AI标了三条警告、我们点了"手动忽略"------"手动忽略"的边界到底该怎么定。

---

不发教程，只发踩坑记录。十年Java老兵，用代码说话。