> 本文分享一套基于 Claude Code Skill 的团队级 AI 代码审查方案：把踩坑经验写成自动化审查规则，让 AI 按统一标准自动审代码，人工 CR 只留架构决策。

在上一篇文章《五关清单吃灰3周后，我让AI自己按我的规则写代码》中，我把五关审查清单做成了 Claude Code Skill，让 AI 生成代码时自动避开并发、事务、空指针、安全这五类已知坑。

但那个阶段，Skill 只是我一个人的"外挂记忆"。真正发生变化，是我把它共享给了团队，把它变成了一个团队代码审查规范。

本文基于真实的团队实践，聊聊当四个人的 AI 都加载了同一套 AI 代码审查规则之后，PR 流程会发生什么变化。

一、从个人 Skill 到团队级 Claude Code 审查规则

我把`code-review-gate` Skill分享给了团队三位同事：老张（数据中台，十年经验）、老周（网关和权限，七年）、小何（三年经验）。

三个人看完源码后各自补充了规则：

- **老张**：数据中台批量任务冲突率不到千分之一，行锁是多余开销。在`concurrency.md`里加了批处理豁免条件。
- **老周**：`security.md`缺SSRF防御，加了host白名单和私有IP过滤检查点。
- **小何**：`null-safety.md`漏了MQ心跳包场景，`eventType`字段可能为空，用Optional兜底。

当天晚上把三个人补充合进GitHub仓库，结构不变，但每条规则标注了来源（谁加的、踩了什么坑、什么时候加的）：

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

区分规则来源很重要——规则之间如果出现冲突，知道找谁聊。

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

二、AI 自动 Code Review 的四步流程

跑了两周之后，整个 AI 代码审查流程自己定了型：

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

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

# .github/workflows/ai-review.yml（示意，按自己仓库改）
# 前提：CI 环境里已安装 Claude Code CLI，并配置 ANTHROPIC_API_KEY
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 回应非机器人账号的评论，或者限制每个 PR 的自动回复次数。否则两个 AI 检测到新回复后再互相回复，账单和服务商都会先受不了。

 第一步：写代码阶段加载审查规则

每个开发者的 Claude Code 同时加载个人 Skill 和团队 Skill。生成代码时就避开已知的坑。

 第二步：PR 前自查

提交 PR 之前，作者侧 AI 对 diff 做全量扫描。违反规则的地方自动标注。能自动修的就修，修不了的标注`[人工判断]`。

第三步：reviewer 侧 AI 扫描

reviewer 的 AI 加载团队 Skill，对 diff 再做一次全量扫描。输出格式按规则编号标注：

```markdown
## AI Review Summary
- ✅ 第一关（需求评审）：已确认
- ✅ 第二关（并发安全）：通过
- ⚠️ 第三关（事务边界）：见下方评论
- ✅ 第四关（空指针）：通过
- ✅ 第五关（安全检查）：通过
- ⚠️ 规则冲突：与老张三周前加的 `team-code-review/concurrency.md` 第2条冲突，批量RPC未记录checkpoint

### 第三关详情
文件: DeviceSyncService.java:42
规则: transaction.md 第3条
问题: ruleEngineClient.refresh() 在 @Transactional 方法体内
建议: 移入 afterCommit 回调
```

第四步：人工 CR 只看架构决策

审查者只看两样东西：AI 标出来的问题，以及涉及架构决策、AI 未覆盖的部分。

三、AI 审查规则冲突的真实案例

最有意思的一个案例发生在第三周。

老张写了一个数据同步接口：从MySQL读设备，每100条调一次RPC推送到规则引擎。代码逻辑清晰，他自己的AI也通过了——RPC在`afterCommit`里，事务边界没问题。

我的AI在审的时候报了一个新问题。它引用了老张自己两周前加的一条规则：

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

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

他自己的AI自动回复："本批次每100条一个子事务，规则已满足。"

我的AI再次回复："子事务间无checkpoint。第9个子批次失败→前8个已提交不可回滚→数据部分同步→无法断点续传。建议加checkpoint记录。"

老张最后在子批次之间加了checkpoint。不是AI替他写的方案，而是他自己的规则点出了自己的遗漏——"不能在一个事务里打穿整个批次"这句话，当初的真正的意图被checkpoint这一层逻辑补全了。

这个案例说明：**当AI开始审AI的时候，真正有用的是规则之间的冲突。** 两条规则打架，不是bug——是把隐藏的设计决策炸到表面上来。

四、自动化代码审查带来的三个变化

四周跑下来，团队代码审查规范落地后发生了三个明显变化：

**低价值评论清零。** "这里判 null""那里加锁""格式不一致"——AI 在生成阶段和 PR 扫描阶段各处理了一遍，不需要人开口。

**经验传递路径缩短。** 以前：踩坑→复盘→分享→别人记住→下次想起来（四个环节都可能断）。现在：踩坑→写一条规则→所有人的 AI 自动检查。

**CR 对话升级。** 不再讨论"代码对不对"，而是讨论"方案好不好"：

> 这个接口QPS预期5000，乐观锁重试三次对数据库QPS影响大概15%，可接受。但如果重试率超过8%，建议拆到Redis做，数据库只做最终一致落库。——老周在PR里的真实评论

五、AI 代码审查做不到的三件事

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

六、团队级 Claude Code Skill 的维护方式

极简维护流程：

```
线上炸了 → 排查 → 确认根因 → 对应reference里加一条规则
→ 标注来源和日期 → git commit + push → 所有人的AI下次自动生效
```

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

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

总结：把团队代码审查规范交给 AI

Skill 不是一个人的辅助工具，是一个团队的集体记忆。一个人踩坑自己扛是常态，一个人把坑写进 Claude Code 审查规则、所有人的 AI 从此避开——这才叫团队。

如果你正在用 AI 写代码但团队还没有统一的 AI 代码审查规范，建议从这套 Claude Code Skill 开始：把每个人踩过的坑写成自动化 Code Review 规则，让 AI 替你守住底线，人工 CR 只留在真正需要判断的架构决策上。

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

下一篇将聊一个更具体的问题：紧急需求下 AI 标了三条警告、团队最终选择"手动忽略"——这个"手动忽略"的边界该怎么定，欢迎持续关注。

---

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