用 AI 辅助代码审查：提交前检查什么

✍创作者：全栈弄潮儿
🏡 个人主页：全栈弄潮儿的个人主页
🏙️ 个人社区，欢迎你的加入：全栈开发社区
📙 专栏地址：AI 编程提效实战

提交代码之前，你通常会做几件事：

• 看一遍修改的代码。
• 运行项目和测试。
• 检查有没有遗漏的功能。
• 等待同事进行 Code Review。

现在，我们还可以增加一个步骤：

先让 AI 帮忙检查一遍，再提交代码。

AI 可以帮助我们发现一些容易忽略的问题，例如逻辑错误、安全风险、边界条件和代码风格问题。

但需要注意：

AI 代码审查只能作为辅助，不能代替人工评审、自动化测试和安全审计。

一、为什么提交前需要代码审查

代码能够运行，并不代表代码没有问题。

例如下面这些问题，项目启动时可能不会报错：

• 用户输入没有校验。
• 密码使用明文保存。
• SQL 语句存在注入风险。
• 普通用户可以提交管理员角色。
• 异常信息直接返回给前端。
• 空数据和重复数据没有处理。
• 修改代码影响了原有功能。
• 提交了与需求无关的文件。

这些问题有些属于功能问题，有些属于安全问题，还有一些会增加后期维护成本。

如果等到上线之后才发现，修复成本通常会更高。

因此，在提交代码之前进行一次检查是很有必要的。

二、AI 代码审查可以检查什么

1. 明显错误和逻辑问题

AI 可以帮助检查：

• 条件判断是否正确。
• 变量是否可能为空。
• 返回结果是否符合需求。
• 异步代码是否正确处理。
• 是否存在重复执行。
• 是否遗漏错误处理。
• 修改后的代码是否影响原有逻辑。

例如，需求要求“只有登录用户才能删除数据”，但代码中没有校验登录状态，这就是一个明显的逻辑问题。

2. 安全风险

安全问题通常不容易通过普通测试发现。

AI 可以协助检查：

• SQL 注入。
• XSS 注入。
• 未授权访问。
• 敏感信息泄露。
• 密码明文保存。
• 用户输入未过滤。
• 文件上传风险。
• 权限校验不完整。
• 密钥、Token 或 Cookie 被提交。

不过，涉及安全的代码，不能只依赖 AI 的判断，还应该结合团队安全规范进行人工确认。

3. 代码风格和可维护性

AI 还可以帮助检查代码是否容易阅读和维护：

• 变量命名是否清晰。
• 函数是否承担了太多职责。
• 是否存在重复代码。
• 是否使用了过于复杂的写法。
• 是否与项目现有风格一致。
• 是否缺少必要的注释。
• 是否修改了不相关的文件。

代码风格问题通常不会马上导致故障，但会影响后续开发效率。

4. 边界条件和异常处理

很多问题出现在正常流程之外。

例如：

• 用户名为空怎么办？
• 密码长度不符合要求怎么办？
• 参数类型错误怎么办？
• 数据不存在怎么办？
• 数据重复怎么办？
• 数据库连接失败怎么办？
• 用户重复点击怎么办？
• 返回数据为空怎么办？

AI 很适合帮助我们补充这些容易遗漏的场景。

三、一个需要审查的接口示例

假设我们正在开发一个创建用户的接口，技术栈是 Node.js 和 Express。

需求如下：

• 用户可以提交用户名和密码。
• 注册成功后创建普通用户。
• 用户名不能重复。
• 密码不能以明文保存。
• 注册失败时不能返回数据库内部错误。

下面是一个看起来可以运行，但存在多个问题的版本：

app.post('/api/users',async(req,res)=>{const{username,password,role}=req.body;constsql=`INSERT INTO users (username, password, role) VALUES ('${username}', '${password}', '${role}')`;try{awaitdb.query(sql);res.json({code:0,message:'创建成功'});}catch(error){res.status(500).json({code:500,message:error.message});}});

这段代码的问题并不一定会在本地测试中暴露出来。

例如：

• 没有检查用户名和密码是否为空。
• 直接拼接 SQL，可能存在 SQL 注入。
• 密码直接保存，没有进行加密或哈希处理。
• role由用户提交，用户可能把自己设置为管理员。
• 数据库错误信息直接返回给前端。
• 没有处理用户名重复的情况。

接下来，就可以把需求、代码和约束一起交给 AI 审查。

四、如何向 AI 提供代码审查上下文

不要只发送一句：

帮我看看这段代码有没有问题。

这句话缺少项目背景，AI 很难判断什么才是“正确”。

可以使用下面这个 Prompt：

请帮我审查下面这次代码修改。 项目背景： 这是一个 Node.js + Express 用户注册接口。 用户可以提交用户名和密码，但只能创建普通用户。 注册成功后保存用户信息。 业务要求： 1. 用户名不能为空，长度为 3 到 20 个字符。 2. 密码不能为空，长度不能少于 8 位。 3. 密码不能以明文保存。 4. 用户不能通过请求参数修改自己的角色。 5. 用户名重复时返回明确的业务提示。 6. 不要向前端返回数据库内部错误。 请从以下四个方面审查： 1. 功能和逻辑错误 2. 安全风险 3. 边界条件和异常处理 4. 代码风格和可维护性 请严格按照下面的格式输出： - 问题位置 - 严重程度：高、中、低 - 问题说明 - 可能影响 - 修改建议 - 建议的验证方式 要求： - 先只列出问题，不要直接重写整个文件。 - 不要臆测项目中不存在的功能。 - 如果无法确定，请明确说明需要补充什么信息。 待审查代码： [粘贴代码]

这个 Prompt 有几个关键点：

• 说明了项目背景。
• 说明了真实业务规则。
• 指定了检查范围。
• 要求 AI 标注问题位置和严重程度。
• 要求先输出问题，不要直接重写代码。

五、如何阅读 AI 的审查结果

AI 可能会列出很多建议，但并不是所有建议都同样重要。

我们可以按照影响范围进行分类。

高优先级问题

这类问题应该优先修复：

• SQL 注入。
• 未授权访问。
• 密码明文保存。
• 敏感信息泄露。
• 用户可以越权修改角色。
• 可能造成数据丢失。
• 核心业务逻辑错误。

例如，允许用户通过参数提交role: "admin"，就属于严重的权限问题。

中优先级问题

这类问题通常需要在提交前处理：

• 参数校验不完整。
• 没有处理重复数据。
• 异常情况返回不明确。
• 函数职责过多。
• 关键逻辑缺少测试。
• 空数据导致页面异常。

这些问题可能不会立刻造成安全事故，但会影响功能稳定性和维护效率。

低优先级问题

这类问题可以根据项目规范处理：

• 变量命名不够清晰。
• 函数长度偏长。
• 注释不够完整。
• 格式与项目规范不一致。
• 存在少量重复代码。

低优先级不代表完全不处理，而是要根据时间和实际收益安排。

六、根据审查结果修改代码

针对前面的示例，可以进行以下修改：

app.post('/api/users',async(req,res)=>{const{username,password}=req.body;if(typeofusername!=='string'||username.length<3||username.length>20){returnres.status(400).json({code:40001,message:'用户名长度必须为 3 到 20 个字符'});}if(typeofpassword!=='string'||password.length<8){returnres.status(400).json({code:40002,message:'密码长度不能少于 8 位'});}try{constpasswordHash=awaitbcrypt.hash(password,12);awaitdb.query(`INSERT INTO users (username, password, role) VALUES (?, ?, ?)`,[username,passwordHash,'user']);returnres.json({code:0,message:'创建成功'});}catch(error){if(error.code==='DUPLICATE_USERNAME'){returnres.status(409).json({code:40003,message:'用户名已存在'});}console.error(error);returnres.status(500).json({code:500,message:'服务暂时不可用，请稍后重试'});}});

这段代码主要解决了几个问题：

• 对用户名和密码进行基础校验。
• 使用哈希值保存密码。
• 使用参数化查询，避免直接拼接 SQL。
• 不允许用户通过参数修改角色。
• 单独处理用户名重复。
• 不直接暴露数据库错误信息。

需要注意，示例中的数据库错误码和db.query写法，应该根据实际项目使用的数据库驱动进行调整。

AI 给出的修改代码也不能直接复制使用，仍然要结合项目环境进行验证。

七、提交前不要只审查代码本身

除了代码，还应该把本次修改的范围告诉 AI。

例如：

本次需求是增加用户注册接口。 修改文件： - src/routes/user.js - src/services/userService.js - test/user.test.js 没有修改： - 数据库表结构 - 登录逻辑 - 前端页面 请检查： 1. 是否修改了需求范围之外的内容。 2. 是否遗漏了接口测试。 3. 是否需要同步更新接口文档。 4. 是否可能影响已有登录功能。

这样可以帮助 AI 关注“这次提交是否完整”，而不仅仅是检查某一段代码。

如果项目使用 Git，也可以把本次修改的 diff 交给 AI：

gitdiff-- src/routes/user.js src/services/userService.js

然后将输出内容发给 AI：

下面是本次提交的代码 diff。 请检查： 1. 是否符合需求。 2. 是否引入新的功能问题。 3. 是否存在安全风险。 4. 是否遗漏测试或文档。 5. 是否包含无关修改。 请只列出需要关注的问题，不要重写整个项目。

使用 diff 审查的好处是，AI 可以重点关注“改了什么”，减少对无关代码的分析。

八、AI 代码审查的正确顺序

建议按照下面的顺序使用 AI：

明确需求和验收标准 ↓ 完成一个小范围代码修改 ↓ 自己运行代码和测试 ↓ 让 AI 审查代码或 diff ↓ 确认问题优先级 ↓ 修复问题并重新测试 ↓ 提交代码并等待人工评审

不要在代码还没有基本运行之前，就让 AI 代替你完成全部判断。

AI 更适合帮助我们发现遗漏，而不是替我们决定代码是否可以上线。

九、提交代码前检查清单

可以把下面这份清单保存下来，提交前逐项确认：

功能检查

• 是否满足原始需求。
• 正常输入是否得到正确结果。
• 失败场景是否有明确提示。
• 是否处理了空值和错误类型。
• 是否处理了重复数据。
• 是否影响已有功能。

安全检查

• 是否存在 SQL 注入风险。
• 是否存在 XSS 风险。
• 是否进行了权限校验。
• 是否可能发生越权操作。
• 密码是否以安全方式保存。
• 是否提交了密钥、Token 或 Cookie。
• 是否向前端暴露了敏感错误信息。

工程检查

• 是否补充了必要的测试。
• 是否更新了相关文档。
• 是否删除调试代码和临时日志。
• 是否修改了不相关的文件。
• 是否符合项目代码规范。
• 是否经过本地运行验证。

总结

AI 可以帮助我们在提交代码之前发现一些问题，尤其适合检查以下内容：

• 功能和逻辑错误。
• 常见安全风险。
• 边界条件和异常处理。
• 代码风格和可维护性。
• 测试、文档和修改范围。

高质量的 AI 代码审查，需要提供完整的需求、代码、技术栈和验收标准。

同时，不要把 AI 的审查结果当成最终结论。对于安全、权限、数据处理和核心业务逻辑，仍然需要开发者和团队进行人工确认。

可以记住一句话：

让 AI 帮你找问题，但由你决定问题是否真实、是否重要，以及应该如何修复。

下一篇文章将介绍：

《AI 编程中的隐私与安全：哪些信息不要提交》

✍坚持原创，求关注，点赞，收藏