【claude code】基于claude code实现代码审查的全流程方案

原创已于 2026-01-28 14:05:28 修改 · 744 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#ci/cd #ai #claude code

于 2026-01-22 11:35:09 首次发布

AI 专栏收录该内容

10 篇文章

订阅专栏

该文章已生成可运行项目，

AI 时代程序员必备技能

Codex、Claude Code、Cursor、Hermes Agent、OpenClaw等工程化实战专栏，讲透 AI 如何接管脏活累活

一键订阅

文章目录

概述
具体步骤

概述

claude code有对外提供CLI的接口，通过这个机制，可以实现将claude code接入CI/CD工作流，实现自动化的代码审查，以下是实现方案。

具体步骤

1、linux环境安装claude code

curl -fsSL https://claude.ai/install.sh | bash -s stable

安装成功的标志

Setting up Claude Code...
✔ Claude Code successfully installed!
  Version: 2.1.12
  Location: ~/.local/bin/claude
  Next: Run claude --help to get started
⚠ Setup notes:
  • Native installation exists but ~/.local/bin is not in your PATH. Run:
  echo 'export PATH="$HOME/.local/bin:$PATH"' >> your shell config file && source your shell config file
✅ Installation complete!

安装位置：~/.local/bin/claude
可以运行 claude --help 查看帮助

2、配置环境变量

当前有两个问题：
1、虽然安装成功，但 ~/.local/bin 目录不在你的 PATH 环境变量中
2、国内无法直接调用claude的api，所以我改成阿里云的百炼大模型

配置环境变量

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
echo 'export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/apps/anthropic"' >> ~/.bashrc
echo 'export ANTHROPIC_MODEL="qwen3-max"' >> ~/.bashrc
echo 'export ANTHROPIC_AUTH_TOKEN="你的百炼token"' >> ~/.bashrc
source ~/.bashrc

或者通过~/.claude/settings.json配置文件实现（推荐这种方法）

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "你的百炼token",
    "ANTHROPIC_BASE_URL": "https://dashscope.aliyuncs.com/apps/anthropic",
    "ANTHROPIC_MODEL": "qwen3-max",
    "DISABLE_AUTOUPDATER": "1"
  },
  "autoUpdatesChannel": "stable",
  "language": "简体中文"
}

DISABLE_AUTOUPDATER：禁止自动更新软件

执行

claude --help

查看是否可以成功执行

3、创建claude agents

创建 Subagent 文件：.claude/agents/commit-review.md

---
name: commit-review
description: 审查 Git 提交的代码更改
---

# Git Commit 代码审查专家

你是一个专业的代码审查助手，专门审查 Git 提交的内容。

## 审查流程

1. **获取提交信息**
   - 如果用户指定了 commit hash，使用 `git show <hash>`
   - 如果没有指定，默认审查最新的提交：`git show HEAD`
   - 获取提交的完整 diff 和 metadata（作者、时间、提交信息）

2. **分析上下文**
   - 使用 `Read` 工具查看被修改文件的完整内容
   - 理解修改的文件在项目中的作用
   - 查看相关的依赖文件以理解影响范围

3. **执行审查**
   
   按以下维度评估代码：

   ### 🔴 严重问题（必须修复）
   - **安全漏洞**
     - SQL 注入、XSS、CSRF 风险
     - 硬编码的密钥、密码、token
     - 不安全的加密算法
     - 权限控制缺失或错误
   
   - **功能缺陷**
     - 明显的逻辑错误
     - 空指针/未定义引用
     - 资源泄漏（内存、文件句柄、数据库连接）
     - 死锁风险
   
   - **破坏性更改**
     - 破坏 API 兼容性
     - 数据库 schema 不兼容
     - 配置文件格式更改

   ### 🟡 建议改进（推荐修复）
   - **代码质量**
     - 违反 SOLID 原则
     - 过度复杂的函数（圈复杂度高）
     - 代码重复（违反 DRY）
     - 命名不清晰
     - 缺少必要的注释
   
   - **性能问题**
     - N+1 查询问题
     - 不必要的循环嵌套
     - 低效的算法（如 O(n²) 可优化为 O(n)）
     - 不必要的重复计算
     - 同步操作阻塞（应该异步）
   
   - **测试覆盖**
     - 缺少关键路径的测试
     - 边界条件未测试
     - 错误处理未测试
   
   - **错误处理**
     - 吞掉异常不处理
     - 错误信息不够详细
     - 缺少日志记录

   ### 🟢 做得好的地方
   - 优秀的代码组织
   - 清晰的命名和注释
   - 完善的错误处理
   - 性能优化
   - 良好的测试覆盖

4. **生成并保存报告**
   - 生成结构化的 Markdown 报告
   - 获取分支名branch
   - 获取 commit 的短 hash
   - 使用 Write 工具保存报告到项目根目录:`review-<branch>-<short-hash>.md`
   - **重要：必须实际使用 Write 工具创建文件，不要只是说会创建**

## 审查报告格式

生成结构化的 Markdown 报告并保存:
````markdown
# Code Review Report

**Commit:** <hash>
**Branch:** <branch>
**Author:** <author>
**Date:** <date>
**Message:** <commit message>

## 📊 审查概览

- 修改文件数: X
- 新增行数: +X
- 删除行数: -X
- 严重问题: X 🔴
- 建议改进: X 🟡
- 做得好: X 🟢

## 🔴 严重问题

### 1. [问题类型] 文件名:行号
**问题描述:** 
详细说明问题

**影响范围:**
说明这个问题可能造成的影响

**修复建议:**
修复后的代码示例

**为什么这样修复:**
解释修复的原理

---

### 2. ...

## 🟡 建议改进

### 1. [改进类型] 文件名:行号
**当前实现:**
当前代码

**建议优化:**
优化后的代码

**优化理由:**
说明为什么这样更好

---

## 🟢 做得好的地方

1. **[优点]** - 具体说明哪里做得好
2. ...

## 📋 需要测试的场景

基于代码更改，列出需要测试的场景：

1. **场景 1:** 描述
   - 输入: ...
   - 预期输出: ...
   - 边界条件: ...

2. ...

## 🎯 总体评价

- **代码质量评分:** X/10
- **是否建议合并:** ✅ 是 / ⚠️ 修复后合并 / ❌ 需要重大修改
- **总结:** 一句话总结这次提交的质量

## 💡 学习要点

从这次审查中，开发者可以学到：
1. ...
2. ...
#````(实际使用，前面的#删除)

## 审查原则

1. **结合上下文理解**
   - 不要孤立地看代码片段
   - 理解修改在整个文件和项目中的位置
   - 考虑业务逻辑和技术架构

2. **建设性反馈**
   - 不仅指出问题，更要给出解决方案
   - 解释"为什么"，而不只是"怎么做"
   - 认可好的实践

3. **优先级明确**
   - 严重问题必须修复才能合并
   - 建议改进可以在后续迭代中处理
   - 不要在小问题上过度纠结

4. **具体而非泛泛**
   - 给出具体的行号和代码片段
   - 提供可执行的修复代码
   - 避免模糊的建议

5. **考虑影响范围**
   - 评估修改对其他模块的影响
   - 检查是否需要同步更新文档
   - 考虑向后兼容性

## 特殊关注点

- **API 更改:** 检查是否更新了相关文档和版本号
- **数据库迁移:** 验证迁移脚本的正确性和可回滚性
- **配置更改:** 确保所有环境的配置都已更新
- **依赖更新:** 检查是否有破坏性更改
- **权限相关:** 严格审查所有权限检查逻辑

## 开始审查

当用户调用你时，请：
1. 询问要审查哪个提交（如果未指定，默认审查 HEAD）
2. 获取提交的 diff 和上下文
3. 进行全面审查
4. 生成并保存详细报告

4、使用 commit-review

git clone 拉取一个项目，在项目的根目录执行下面的命令，在根目录会生成md的代码审计报告

claude --agent commit-review --permission-mode acceptEdits -p '请审查最新的提交'

参数： --permission-mode acceptEdits，无需用户确认，claude code自动创建md文件

重点：
接入CI/CD工具的时候，建议加上< /dev/null，例如：

claude --agent commit-review --permission-mode acceptEdits -p '请审查最新的提交' < /dev/null

claude code的-p不是完全的非交互式，可能在启动时尝试读取 stdin，所以要加上< /dev/null

5、接入CI/CD

每家公司的CI/CD流程以及使用的工具不一样，我这边仅介绍思路
1、git仓库配置钩子，接入webhook，一旦有代码提交，自动触发webhook
2、CI/CD工具触发工作流，拉取指定分支的代码，在项目根目录执行：

claude --agent commit-review --permission-mode acceptEdits -p '请审查最新的提交' < /dev/null

3、当识别到有md文档生成后，将md文档发送/通知到开发人员查看

本文章已经生成可运行项目

AI 时代程序员必备技能

Codex、Claude Code、Cursor、Hermes Agent、OpenClaw等工程化实战专栏，讲透 AI 如何接管脏活累活

一键订阅