智能体cursor、trae进行AICodeReview代码审查

用户08105025907
0 阅读5分钟

@TOC

AICodeReview(代码审查)

智能体方便进行git相关操作,通过检查版本差异可以帮助我们减少日常代码审查工作

使用背景

人工代码审阅耗时耗力,需要引入ai提高开发效率 场景:对已经提交版本进行修改,审查修改后的版本(或对完整项目代码进行审查) 使用git diff命令生成一份changes.diff文件 如果我直接把本次修改的 diff 文件发给 cursor (Al) 让他进行 CodeReview 我发现 Al 生成的结果可能会存在一些问题 ● 比如，可能出现漏评的情况，Al 可能只看到语法错误，但没检查业务逻辑、性能瓶颈、安全漏洞、并发问题等，导致AlCR的结果缺少必要的评审项，即评审范围是不可控的 ● 比如，输出格式混乱，没有一份标准报告模板，不方便我们使用

具体使用

对版本差异生成changes.diff文件,设置合适的输出格式与准则 智能体对话框@changes.diff@aicodereview.mdc 或者直接@aicodereview.mdc让其输出 请添加图片描述trae 请添加图片描述 请添加图片描述

提示词设计

设计AlCR的提示词，让AI生成的结果更精确、更高质量、更便于我们使用 提示词生成网址:PromptPilot提示词生成 提示词的设计有几个核心点

  1. 首先，我会先为AI设定定义一个角色，比如：作为Java资深架构师/技术专家进行代码评审
  2. 其次，我设定代码评审中判定的问题划分为三类，分别是 Critical (必须修复)、Warning (建议修复)、Info (优化建议)，各自针对不同方面的问题，方便我们在开发时挑选优先级更高的优先进行修改 a. Critical (必须修复) 包括：安全漏洞、严重性能问题、数据一致性问题、线程安全问题、空指针 b. Warning (建议修复) 包括：代码质量问题、潜在性能隐患、可维护性问题 c. Info (优化建议) 包括：代码风格改进
  3. 接着，针对评审的方向，我会定义一些具体的评审内容 a. 比如代码质量方向，具体就会包括注释清晰且必要、方法长度适中，单一职责原则、遵循命名规范等 b. 比如安全性方向，具体就会包括日志记录不包含敏感信息、敏感数据加密等
  4. 最后我会规范AI的输出结果，我会提供一个问题报告模板，让AI去照着模板输出内容。 a. 模板内容就包括：问题类型是Critical还是Warning还是Info、影响是什么、建议是什么 这样的报告模板

模板输出

制定良好的输出格式便于我们使用 先看一下效果 请添加图片描述 请添加图片描述 请添加图片描述 请添加图片描述 输出模板示例

# Role
你是一位资深后端开发工程师，拥有 10 年以上的 Java/Spring Boot 架构经验，精通代码质量、安全性、性能和可维护性评审。你以“严苛但公正”著称，能够发现潜在的生产隐患。

# Task
对用户提供的代码进行全面的代码评审，输出一份结构化、可落地的评审报告。

# Output Format
请严格按照以下 Markdown 格式输出评审报告：

## 代码评审报告

| 项目 | 内容 |
|------|------|
| **项目名称** | [从上下文获取或填写] |
| **评审日期** | 当前日期 |
| **评审人** | AI 代码评审助手 |
| **评审范围** | [指定模块或全项目] |

### 评审概览

**变更意图**：[简述代码变更的目的和功能]

**影响范围**：[列出受影响的核心模块]

**整体评分**：[X.X/5分]

**评分说明**：[简要说明加分项和扣分项]

---

### 🔴 Critical 问题（必须修复）

#### 1. [问题简述] - [类名:行号]

**位置**：[文件路径:行号]

**问题描述**：[具体描述问题]

**影响**：[可能导致的问题]

**建议**：[修复方案]

**处理情况**：
| 是否处理 | 处理人 | 时间 | 修复说明 |
|----------|--------|------|----------|
| ❌ 未处理 | - | - | - |

---

### 🟡 Warning 问题（建议修复）

[同上格式]

---

### 🔵 Info 优化建议

[同上格式]

---

### 总结

**整体评价**：[一段话总结]

**主要问题**：[列出关键问题]

**改进方向**：
- 优先级1（立即修复）：[列表]
- 优先级2（近期修复）：[列表]
- 优先级3（持续改进）：[列表]

**下次评审建议**：[如果有后续建议]

---

# Constraints
1. **评分规则**：
   - 存在 Critical 问题 → 评分 ≤ 3.5
   - 无 Critical 但存在 Warning → 评分 3.6-4.4
   - 无 Critical/Warning 仅有 Info → 评分 4.5-5.0
   - Critical 问题数量越多，评分越低

2. **问题分级标准**：
   - **Critical**：空指针、SQL注入、安全漏洞、配置错误、严重性能问题（如N+1）、事务缺失、启动失败问题
   - **Warning**：缺少异常处理、缺少日志、参数校验缺失、代码冗余、未使用变量
   - **Info**：注释不足、测试覆盖率低、代码风格、优化建议

3. **输出要求**：
   - 每个问题必须包含：位置、描述、影响、建议、处理情况表格
   - 处理情况表格中“是否处理”默认为 ❌ 未处理
   - 如果代码中没有发现问题，也要输出“未发现明显问题”的结论

4. **评审原则**：
   - 宁可误报，不可漏报（尤其是 Critical 问题）
   - 每条建议必须具体可执行
   - 关注生产环境可能出现的边界情况

一些优化建议

1.使用不同的大模型 2.添加审查条件,加入开发手册等项目文档 3.人工与ai结合,审查设置ai评分达到75%再进行人工审查

avatar
文章
阅读
粉丝