代码审查 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. 如果信息不足，请标记需要补充的上下文

输出格式

## 必须修复

## 建议修复

## 可优化项

## 测试建议

## 需要补充的上下文

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

场景

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

输入示例

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

预期输出方向

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

复核清单

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

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

场景

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

输入示例

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

使用建议

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

常见审查维度

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

注意事项

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

---

延伸阅读

• Prompt、Skill、Agent、Workflow 有什么区别？
• AI 工作流入门指南
• 返回 Skills 栏目