代码审查 Skill：建立 AI 辅助 Code Review 流程

这个 Skill 解决什么问题

AI 代码审查 Skill 可以在提交代码前发现常见问题，帮助开发者建立更稳定的自查流程。它不是替代人工 Review，而是让 AI 先按固定维度检查一遍，减少低级 Bug、安全遗漏和测试缺口。

它适合这些场景：

• 提交 PR 前自查 diff。
• 重构代码后检查是否改变已有行为。
• 上线前审查权限、输入校验和异常分支。
• 为新同事提供 Review 清单和反馈格式。
• 针对某类高风险代码做专项审查，例如支付、登录、文件上传。

输入要求

• 代码 diff：最好提供变更前后差异，而不是只贴最终代码。
• 相关文件上下文：被调用函数、类型定义、路由、配置等。
• 预期行为：这次变更原本要解决什么问题。
• 测试结果：运行了哪些测试，哪些没跑。
• 关注重点：正确性、安全性、性能、可维护性、兼容性等。
• 风险边界：是否涉及支付、权限、用户数据或外部接口。

使用方法

第一步：先说明变更意图

AI 如果不知道代码为什么改，很容易只做表面格式点评。先说明目标和预期行为。

第二步：提供 diff 和上下文

只贴一段函数通常不够。至少补充调用方、数据结构和关键配置。

第三步：要求按严重程度输出

Review 结果必须区分“必须修复”“建议修复”“可优化项”，避免把风格问题和真实 Bug 混在一起。

第四步：要求给出可复现条件

每个问题最好包含触发场景、影响范围和修复方向。没有具体触发条件的问题，应降级为建议。

推荐 Prompt 模板

你是一个代码审查 Skill。请审查以下代码变更。

变更目标：
预期行为：
代码 diff：
相关上下文：
已运行测试：
关注重点：
风险边界：

请按以下要求输出：
1. 只报告真实可能发生的问题，不要泛泛而谈
2. 每个问题说明触发条件、影响和建议修复方式
3. 按严重程度排序
4. 单独列出测试缺口
5. 如果信息不足，请标记需要补充的上下文

输出格式

## 必须修复

## 建议修复

## 可优化项

## 测试建议

## 需要补充的上下文

最小可复用 Skill 配置

下面的配置可以作为团队起点。它只规定稳定的审查规则，不写入具体仓库名称、密钥或业务数据。

name: code-review
purpose: 审查提交前的代码 diff，并按严重程度输出可验证问题
gates:
  - 每个问题必须包含文件位置或代码引用
  - 每个问题必须说明触发条件和影响
  - 无法从上下文确认时标记为待验证
  - 风格建议不得列为必须修复
required_inputs:
  - 变更目标
  - 预期行为
  - 代码 diff
  - 已运行测试
output_sections:
  - 必须修复
  - 建议修复
  - 测试建议
  - 需要补充的上下文

团队可以再补充语言、框架和测试命令，但不要把生产凭据、客户数据或私有源码样例写进共享配置。

Prompt、Skill 和 Agent 的选择边界

• 一次性 Prompt：适合审查单个 diff，规则会随任务变化，复制代码审查 Prompt即可开始。
• 可复用 Skill：适合团队反复使用相同的严重程度、检查维度和输出格式，便于维护统一规范。
• 持续 Agent：适合需要读取多文件上下文、追踪多轮修改或自动执行检查的任务，可参考 AI 代码审查 Agent。Agent 权限应按最小范围配置，不能默认读取或修改整个仓库。
• 完整工作流：如果还要覆盖准备上下文、二次验证和提交前检查，使用用 AI 做代码审查的工作流串联各步骤。

使用案例一：审查支付回调处理

场景

团队修改了支付回调逻辑，需要在上线前检查是否存在重复处理、签名校验和状态流转问题。

输入示例

变更目标：重构支付回调处理函数。
预期行为：收到支付平台回调后校验签名，更新订单状态，并触发发货。
关注重点：幂等、签名校验、异常重试、日志。
代码：
[粘贴 diff]

预期输出方向

AI 应先理解回调流程，再按严重程度输出问题。例如：是否先校验签名再处理订单、是否用交易号做幂等、重复回调是否会重复发货、失败重试是否会造成状态错乱。

复核清单

• 问题是否能定位到具体代码？
• 是否有真实触发条件？
• 修复建议是否影响现有业务？
• 是否需要补充单元测试或集成测试？

使用案例二：审查权限变更

场景

后台管理系统新增“编辑内容”权限，前端按钮和后端接口都做了调整。你需要检查是否存在越权访问。

输入示例

变更目标：新增内容编辑权限
预期行为：只有 admin 和 editor 可以编辑文章，viewer 只能查看
关注重点：前后端权限一致性、接口鉴权、错误提示
代码 diff：[粘贴相关 diff]

使用建议

权限类 Review 不能只看前端按钮是否隐藏。应要求 AI 同时检查后端接口、路由中间件、角色枚举、默认权限和测试覆盖。

常见审查维度

• 正确性：边界条件、空值、状态流转、并发、幂等。
• 安全性：权限、输入校验、敏感信息、文件上传、外部回调。
• 性能：重复查询、循环调用、缓存失效、大数据量场景。
• 可维护性：命名、职责拆分、重复逻辑、隐式依赖。
• 测试缺口：正常路径、异常路径、权限路径、回归用例。

失败边界与人工复核

• 误报：AI 可能忽略调用方已有校验，重复报告已被处理的问题。先沿调用链确认，再决定是否修改。
• 仓库上下文不足：只提供局部 diff 时，AI 无法可靠判断跨模块状态、数据库约束或部署配置。信息不足应输出“待验证”，不能补写结论。
• 敏感代码：密钥、生产配置、客户代码和个人数据不得上传到未经批准的服务。必要时先脱敏，或使用团队批准的本地环境。
• 不可代替的检查：编译、静态分析、测试和安全扫描应实际运行；不能把 AI 建议当作“已通过测试”。

人工复核时，对高严重度问题逐项确认代码位置、触发输入、影响范围和复现结果。支付、权限、认证等变更还应由对应模块负责人审核，无法复现的问题降级为待验证。

注意事项

不要把 AI 审查当作唯一质量门禁。复杂业务逻辑仍需要熟悉上下文的工程师复核。AI 提出的每个问题都应验证是否能在真实输入和真实状态下触发。