8.1. 代码审查 Skill 系统让团队效率翻倍

你需要什么

• 一个已连接到 GitHub 仓库的开发环境（本地或 CI 容器均可）
• 安装了 Claude Code 的终端，且已通过 claude login 完成认证
• 对团队使用的代码规范有基本了解（如 ESLint、Pylint、公司内部风格指南）
• 预计时间：阅读 10 分钟 + 跟随实践 30 分钟

最终成果

你将得到一个可复用的 代码审查 Skill，它能自动分析 Pull Request 的 diff，从安全性、风格、性能三个维度给出评审意见，并以行级评论的形式集成到 GitHub 中。
为什么做这个：把高级开发者的审查直觉固化为 AI 可执行的规则，让每行新增代码在合并前都经过一致的、不遗漏的检查，从而成倍降低人工 review 的重复劳动。

从手动评审到自动化检查：一个真实痛点

过去三个月，我们团队每次 code review 都要占用至少两名高级工程师各 1 小时。更糟的是，风格问题和常见反模式——比如硬编码密钥、未关闭的文件句柄、O(n²) 循环——依然会漏进 main 分支。
团队不是不认真，而是人的注意力会疲劳。于是我们决定：把那些“闭上眼睛都知道要查啥”的知识，做成一个 Claude Skill，让它替我们先筛一遍。

接下来的教程，就是我们的真实搭建过程。你可以直接复用这套结构，替换成自己团队的标准。

步骤 1：需求分析与设计

在动笔写 Skill 之前，需要先明确三件事：审查什么、怎么审查、结果怎么呈现。

审查维度定义

我们选定了三个维度，如下表所示。你可以按团队痛点增删：

工具链集成

• 使用 GitHub CLI 或 API 获取 PR diff。
• Skill 调用本地静态分析工具（如 semgrep）进行模式匹配。
• 对于工具覆盖不了的知识（如“这个变量名 data 含义模糊”），由 LLM 根据 diff 上下文给出建议。
• 最终结果通过 GitHub Review Comments API 回写到 PR 的对应行。

Skill 行为流程

1. CI 触发 claude run review-skill --pr $PR_NUMBER。
2. Skill 读取 diff，分文件切片。
3. 每个切片并行跑静态规则和 LLM 检查。
4. 收集所有 Opinion，过滤掉置信度低的结果。
5. 调用 GitHub API 发布 review comments。

预期结果：在纸上或白板上画出如上流程，团队对每个节点负责的内容达成一致。

步骤 2：实现 Skill —— 编写可执行的知识包

Claude Skills 的本质是“告诉 Claude 在特定情境下如何一步步操作”的指令集。我们将在项目根目录下创建 skills/review-skill/SKILL.md。

创建 Skill 文件

# Code Review Skill
当接收到代码审查请求时，严格按照以下流程执行：
1. 获取 diff
2. 分析 diff
3. 输出评论

## 输入参数
- `PR_NUMBER`: GitHub PR 编号
- `REPO`: 仓库路径

但你需要的不仅是 Markdown，更是一个可执行的脚本骨架。为此我们编写一个入口文件 skills/review-skill/run.sh，它会调用 Claude Code 并传递环境上下文：

#!/bin/bash
# skills/review-skill/run.sh
set -euo pipefail

PR_NUMBER="$1"
REPO="${2:-origin}"

# 获取 diff
gh pr diff "$PR_NUMBER" --repo "$REPO" > /tmp/review_diff.patch

# 使用 claude 执行 skill 内定义的审查逻辑
claude run review-skill \
  --input /tmp/review_diff.patch \
  --env PR_NUMBER="$PR_NUMBER" \
  --env REPO="$REPO"

核心审查规则配置

在 skills/review-skill/review_rules.yaml 中定义静态检查规则（示例）：

rules:
  - id: HARDCODED_SECRET
    pattern: "(api_key|password|token)\\s*=\\s*['\"][A-Za-z0-9+/=]{20,}['\"]"
    message: "疑似硬编码凭证，请使用环境变量或密钥管理服务"
    severity: CRITICAL
  - id: PRINT_STATEMENT
    pattern: "print\\("
    message: "避免提交调试用的 print 语句，应使用 logger"
    severity: WARNING

Skill 通过以下方式调用这些规则：

# 在 SKILL.md 中描述的步骤之一
grep -E -f <(yq e '.rules[].pattern' review_rules.yaml) /tmp/review_diff.patch

LLM 辅助分析

对于工具难以检测的逻辑问题，我们利用 Claude 本身的理由。在 SKILL.md 中定义提示词片段：

## 提示词：分析 diff
你是一个严格的代码审查员，请根据以下 diff 片段指出：
- 是否引入了明显的性能问题（如不必要的循环嵌套）
- 变量命名是否清晰
- 错误处理是否充分

对每个发现，输出 JSON 格式：{"file": "...", "line": ..., "body": "..."}

随后在 run.sh 中用 claude code 模式执行该提示词。

预期结果：运行 ./run.sh 42 后，终端输出一系列建议 JSON，并可以通过管道发给下一步。

步骤 3：测试与调试 —— 真实 PR 跑起来

准备一个专门用于测试的 PR，其中故意包含一些典型问题：

• 添加了 password = "123456" 的行
• 留了一个 print("debug")
• 写了一个不必要的双层循环

第一次运行与踩坑

当我们第一次执行时，Skill 给出了大量评论，包括很多误报。比如 grep 把注释里的伪代码也匹配了。注意：务必将上下文过滤完善。

踩坑记录：

• 多行匹配失败：diff 中有换行的语句，grep 无法跨行匹配。改用 awk 或分段后交给 LLM 处理。
• LLM 超时：对大 PR 一次性提交整个 diff 可能超出上下文窗口，需要分割为不超过 200 行的 chunk。
• 评论重复发布：GitHub API Review Comments 是幂等性较弱的，需自行维护“已评论行号”状态文件，避免重复发送。

我们加入了一个简单的去重逻辑，记录已评论的 commit_sha:file:line 三元组到 /tmp/reviewed_lines.txt，每次发评论前检查。

# 去重片段
COMMENT_KEY="${GITHUB_SHA}:${file}:${line}"
if grep -qF "$COMMENT_KEY" /tmp/reviewed_lines.txt; then
  continue
fi
echo "$COMMENT_KEY" >> /tmp/reviewed_lines.txt

预期结果：再次运行后，误报减少，且不会重复评论。

步骤 4：部署到 CI —— 成为合并门禁

现在将 Skill 集成到 GitHub Actions 工作流中，使每个 PR 自动触发审查。

GitHub Actions 配置

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Claude Code
        run: |
          npm install -g @anthropic/claude-code
          echo "$CLAUDE_API_KEY" | claude login --api-key
        env:
          CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
      - name: Run Review Skill
        run: ./skills/review-skill/run.sh ${{ github.event.pull_request.number }} ${{ github.repository }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

弹性与高可用考虑

回顾上一章的内容，这个 Skill 的规则和审查历史可以持久化到一个独立存储（如 S3 或数据库），并在 Skill 启动时加载。如果 CI 运行中断，Skill 可以从最后一个检查点恢复，避免重复处理已审查的文件。

我们在 Skill 中加入了一个简单的状态文件：

# 记录每个 PR 的审查进度
echo "{\"pr\": $PR_NUMBER, \"last_processed_commit\": \"$GITHUB_SHA\", \"files_done\": $DONE_FILES}" > /tmp/review_progress.json

预期结果：在非生产环境模拟 CI 中断后重新运行，可以看到 Skill 跳过了已完成的部分，实现了快速恢复。

回顾与行动清单

我们做了什么

• 分析了团队 code review 中的低效环节，确定了自动化审查的三个维度。
• 创建了一个 Claude Skill，它读取 GitHub PR diff，运行静态规则和 LLM 分析，并回写行级评论。
• 解决了跨行匹配、重复评论等实际集成问题。
• 将 Skill 嵌入 GitHub Actions 成为 CI 检查项，并加入了基础的高可用进度恢复机制。

从初次构思到在正式仓库跑通，大约花了 2 个下午。现在，每个 PR 都会自动收到 10-20 条机器先行的审查建议，高级开发者的时间只花在复杂架构决策上。

接下来你可以做的 5 件事

1. 定制规则库：根据你们语言和框架，补充专用 Semgrep 或 ESLint 规则。
2. 接入告警：当 Skill 发现安全严重问题时，主动发送 Slack 通知。
3. 建立反馈循环：让 reviewer 对机械评论给出“有用/无用”的反馈，用于微调 LLM 提示词。
4. 性能优化：缓存静态分析结果，加速大仓库的审查。
5. 阅读下一章——“知识库问答机器人可以零代码定制”，看如何把同样的 Skill 思路延伸到内部文档问答，让非研发岗也能用上 AI。

你会发现，这种“把团队隐性知识写成可执行指令”的方式，正是 Skills 体系的核心价值。