AI 代码审查

OpenClaw 当你的 Senior Engineer —— 7×24 在线,每一行代码都认真看

Code Review 的现实

等 Review 等到花都谢了

提了 PR,Senior 在忙别的项目。过了两天终于 Review 了,就留了句「LGTM」。要么等太久,要么根本没认真看 —— 你说这 Review 有什么用?

更头疼的是团队里每个人标准不一样。张三觉得这么写没问题,李四说必须改。到底听谁的?统一标准?开三次会也定不下来。

OpenClaw:7×24 在线的 Senior Engineer

把代码丢给 OpenClaw,它会按业界最佳实践逐行审查:安全漏洞、性能瓶颈、可维护性、边界情况,全部覆盖。

不用排队,不用看人脸色,不会因为「太忙」就随便 LGTM。而且每次审查的标准完全一致 —— 再也不用在群里吵「这到底算不算问题」了。

3 条 Review Prompt,复制就能用

从安全审查到设计原则,按需选用。

Review PR:安全 + 性能专项审查 黄金指令
请 Review 以下代码变更(PR diff),重点关注:

1. 安全漏洞:SQL 注入、XSS、CSRF、敏感信息泄露、不安全的反序列化
2. 性能问题:N+1 查询、不必要的内存分配、未加索引的查询、阻塞操作
3. 边界情况:空值处理、并发竞争、超大数据量场景

对每个问题给出:
- 严重等级(Critical / Warning / Suggestion)
- 具体位置(文件名 + 行号)
- 修复建议和示例代码

最后给出整体评价和是否建议合并。
这条适合提交 PR 前自己先过一遍,能抓到大部分常见安全问题。建议用 Claude Opus 4.6,它对跨文件的安全风险理解更准。
SOLID 原则合规检查 进阶技巧
请检查以下代码是否符合 SOLID 原则:

- S(单一职责):这个类/函数是不是干了太多事?
- O(开闭原则):新增功能需要改现有代码吗?
- L(里氏替换):子类能安全替换父类吗?
- I(接口隔离):接口是不是太胖了?
- D(依赖倒置):高层模块直接依赖了底层实现吗?

对每个违反的原则:
1. 说明具体违反了什么,在哪里
2. 为什么这是个问题
3. 给出重构方案和代码示例
这条适合 Review 核心业务逻辑或者基础架构代码。日常的 CRUD 小接口没必要上这个。
数据库查询 N+1 问题排查 黄金指令
请分析以下代码中的数据库查询:

1. 找出所有 N+1 查询问题:
   - 标出循环中触发的查询
   - 计算最坏情况下的查询次数
2. 给出优化方案:
   - 哪些可以用 JOIN 合并
   - 哪些可以用 eager loading / preload
   - 哪些需要加缓存
3. 写出优化后的代码
4. 估算优化前后的性能差异

ORM 框架是 [你的框架,如 SQLAlchemy / Prisma / ActiveRecord]。
N+1 是最常见的性能杀手之一,列表页一慢先查这个。记得把 ORM 框架名替换成你实际用的。

代码审查:OpenClaw vs GitHub Copilot

都能 Review 代码,但方式完全不同。

OpenClaw
  • 能看到整个项目的上下文,跨文件理解业务逻辑
  • Prompt 完全自定义,按你的团队规范来审查
  • 可以切换模型:简单 Review 用 GPT-4o,复杂架构用 Opus 4.6
  • Review 结果可以导出、存档、作为团队知识库
VS
GitHub Copilot Code Review
  • 集成在 GitHub PR 界面,触发方便
  • 审查范围主要是 diff 内容,跨文件理解有限
  • 模型固定,无法自定义审查规则
  • 对中文注释和变量名的理解偶尔翻车

真实场景

创业团队:两个后端扛全部代码
团队就俩后端,互相 Review 经常漏掉问题,上线后出 Bug 才发现。
OpenClaw 方案
提 PR 前先用 OpenClaw 做一轮安全 + 性能审查,把明显问题过滤掉,人工 Review 只需要关注业务逻辑。上线事故率降了一半,Review 时间从平均 2 天缩到半天。
纯人工方案
两个人互相 Review,忙的时候只能 LGTM。代码标准全靠口头约定,新人来了又得重新培训一遍。

几点实用建议

💡 别把整个项目一次性丢给 AI Review。按模块分批来,每次聚焦一个关注点(比如安全、性能、可读性),效果更好。
🎯 AI Review 不是替代人工 Review,是在人工之前先过一遍。让机器抓格式和常见问题,让人关注设计和业务逻辑。
这篇案例对你有帮助吗?