如何高效审查AI生成的代码

梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace

要高效审查AI生成的代码，你需要将注意力集中在AI编码代理最可能出错的地方。这将使你的代码审查更快、更准确。

审查代理的代码与审查队友的代码本质上没有区别。代码审查是在接受代码变更之前检查代码库变更的过程，以便确认代码按预期工作，并且是正确的、安全的、可维护的。当作者是代理时，这种责任不会改变。改变的是代码量、到达速度以及潜在问题的组合。

AI编码代理编写代码的速度比任何人阅读代码的速度都快，这使你成为瓶颈。你的工作和职责保持不变，但工作量和速度增加了。

为了管理这一点，你需要有计划地审查代码。你无法阅读每一行代码，因此请专注于风险最高的部分。

注意： 你检查的内容与队友的代码相同，但在实践中更难，因为代码到达更快、块更大。随着速度和大小的增加，你更有可能错过错误。大多数人工作约四百行代码或一小时后开始失去专注力。

AI生成的代码也会改变你将发现的错误类型。逻辑看起来正确但实际上可能是错误的。代码可能调用不存在的API或导入不存在的包。它还可能跳过边缘情况。带有这些问题的代码乍一看可能没问题。

在本教程中，你将学习一个五步工作流程，以高效且可重复的方式审查AI生成的代码：

五个步骤，两个反馈循环

你从代码的意图开始，然后运行一些自动检查。之后，你阅读剩余部分，从最复杂的部分开始。在这个阶段，你将捕获代理经常犯的错误。你还会在修复之前通过运行代码来确认每个问题。

1、先决条件

要跟随操作，你应该能够阅读Python代码并使用编码代理，例如Claude Code、GitHub Copilot CLI、Antigravity CLI和OpenCode。如果你已经熟悉调试Python错误、类型检查和阅读Git diff，你将获得更多收获。

理想情况下，你想使用一些AI生成的代码进行练习。当你在真实的代理拉取请求或代理生成的小型项目上运行工作流程时，你将学到最多。使用目标项目使用的Python版本。对于新项目，你可以选择一个较新的版本。Python 3.14是一个不错的选择。

你还需要一些工具来对代码运行质量检查，例如代码检查器、静态类型检查器、安全扫描器和测试运行器。你可以将它们安装到项目的虚拟环境中。以下是你可用的最小工具集：

(venv) $ python -m pip install ruff mypy bandit pytest pytest-cov pip-audit

这些是开发依赖项，因此它们应该与项目运行所需的包分开。如果你使用uv管理项目，那么你可以将它们添加到专用的dev依赖组中：

$ uv add --dev ruff mypy bandit pytest pytest-cov pip-audit

如果你喜欢更快的类型检查器，可以将mypy替换为ty，这是Ruff制作商提供的更新替代品。

对于更深入的可维护性检查，需要时添加扩展集：

(venv) $ python -m pip install pylint radon import-linter pydeps

你可以在一个地方配置核心工具。此最小配置打开了对AI生成代码最重要的规则：

# ...
[tool.ruff.lint]
select = ["F", "E", "B", "S", "UP", "DTZ"]

[tool.mypy]
strict = true

[tool.coverage.run]
branch = true

你还需要一种方法来查看代码中发生了什么变化。大多数代码审查都在GitHub拉取请求（PR）上进行。在那里，你可以在浏览器中使用友好的用户界面（UI）阅读差异。

你也可以在终端中本地阅读差异。GitHub CLI工具使用gh pr diff打印拉取请求的更改，当没有PR时，Git使用git diff显示它们。

你也可以在你喜欢的AI编码代理中查看差异。Claude Code、GitHub Copilot CLI和Antigravity CLI等工具具有用于此任务的/diff斜杠命令。

2、设置审查AI生成代码的基本规则

五个原则指导建议的审查工作流程。它们将防止你仅因为生成的代码看起来正确就信任它：

1. 无论谁写的，你都拥有结果： 作为人类审查者或开发人员，你是确认正确性、安全性和可维护性的人。代理是助手，不是替代品，不会对失败的代码负责。
2. 审查AI生成的代码是动手操作的： 与队友的拉取请求不同，没有单独的作者可以发送审查评论，因此你通常会自己进行修复，而不仅仅是留下评论。你可以提示代理处理一些问题，手动修复其他问题。
3. 看似合理并不等同于正确： 现代代理可以编写看起来正确但可能在逻辑上错误、不安全或难以维护的代码。
4. 你根据代码的意图进行审查： 你根据代码应该做什么来检查代码，而不仅仅是它是否运行或通过测试。代理可能误解提示，编写看起来不错但不符合要求的代码。
5. 自动代码质量检查是必要的，但永远不够： 代码检查器、类型检查器、安全扫描器和测试可以清除机械问题，但它们会错过逻辑错误和糟糕的抽象。运行它们可以处理常规噪音，使你可以专注于重要的问题。

这些原则是审查工作流程背后的心态，而不是你勾选的清单。它们不会与后续步骤一一对应。相反，每个原则都出现在几个步骤中。

此工作流程有五个步骤：

1. 理解代码应该做什么： 在阅读代码之前确定目标，这样你就可以根据意图而不是合理性来判断代码。
2. 运行自动代码质量检查： 使用代码检查器、类型检查器、安全扫描器和测试来清除机械问题。
3. 有计划地阅读，而不是从上到下： 从风险最高、由外向内阅读剩余内容，遵循代码的流程。
4. 查找AI生成代码中的常见问题： 检查AI代理通常会出错的内容，然后确认每个标志。
5. 修复问题，然后验证修复： 修复你确认的问题，然后重新运行以验证修复是否有效。

步骤1、2、3和5包含你在为队友进行代码审查时常用的做法。但是，该工作流程考虑了活动AI编码代理的存在。步骤4是你进行AI特定检查的地方。现在，是时候按顺序探索每个步骤了，从代码的目标开始。

3、理解代码应该做什么

发现错误差异的快速方法是知道正确的差异应该是什么样子。在AI辅助编码环境中，常见的失败如下：代理误解了你的提示和上下文，然后完美地实现了该误解。语法没问题，但代码可能走一条意想不到的路径。与人类生成的差异一样，你的审查在代码之前就开始了。

首先，确定变更的意图。为此，你可以使用以下一些来源，具体取决于触发代码差异的原因：

• 问题工单或错误报告
• 功能规范
• 失败的测试（红-绿周期）
• 验收标准
• 提交消息或拉取请求描述
• 你给代理的提示或对话历史记录

一旦你清楚地了解了代码应该做什么，请将该意图保持在眼前。你将根据该意图检查代码，而不是它是否看起来合理。

当你审查一个新的AI生成的项目时，你将没有差异可以开始。你可以从项目规范、代理的实现计划、你最初给代理的提示等中收集代码的意图。在这种情况下，你应该按模块或包一次审查项目的一部分。以小的逻辑块进行工作可以保持你的准确性，并防止你在大量代码中迷失方向。

注意： 你可以要求你的AI代理用简单的词语重述代码的意图，并建议审查大小的块。将其视为起点，而不是最终真相。你仍然拥有阅读权。尝试如下提示：

总结此更改的作用，然后列出我应该审查的文件和函数，分为小的逻辑块。

清楚了解代码的意图后，你就有了检查其正确性的良好起点。但是，在阅读任何一行代码之前，你应该运行一些自动检查以确保代码是干净的。

4、运行自动代码质量检查

代码检查器、静态类型检查器、安全扫描器和测试运行器是快速且确定的。它们帮助你捕获无聊且重复的问题，使你可以专注于重要部分。让它们首先为你清除机械噪音。

以下是你作为第一遍运行的四个工具：

• ruff作为代码检查器，包括标记未定义或未使用名称的F规则
• mypy在严格模式下捕获类型不匹配和不可能的调用
• bandit作为安全扫描器，用于处理硬编码密钥和不安全默认值等问题
• pytest带有分支覆盖率，它会标记快乐路径代码倾向于跳过的未测试错误情况

例如，使用先决条件部分中的pyproject.toml文件，代理留下的一个硬编码密钥会立即被捕获：

# ...
SECRET_KEY = "sk-live-1234567890abcdef"

Ruff通过其S规则报告该密钥为硬编码密钥，Bandit使用其默认设置捕获它。你可以通过从环境变量或.env文件读取密钥来修复此安全问题。

注意： 如果你已经将硬编码密钥提交到Git存储库，那么可以从Git历史记录中访问它。在这种情况下，你必须立即轮换密钥以避免未经授权的访问。

一些其他检查可能有助于AI生成的代码：

• 依赖审计： 使用pip-audit等工具捕获具有已知漏洞的依赖项。
• 过时的构造： 使用Ruff的UP和DTZ规则标记可能过时的模式，例如datetime.utcnow()或typing.List，这些模式从训练数据中提取。
• 代码重复检查： 使用pylint及其duplicate-code检查来捕获在多个位置粘贴的相同代码块。在一次运行中传递所有模块，因为该检查只比较它同时看到的文件。
• 代码复杂度检查： 使用radon等工具来衡量代码的复杂程度。

这些只是一个示例。还有更多代码检查器和检查器可供选择，因此请选择适合你项目和堆栈的工具，而不是盲目地运行所有工具。

注意： 你可以让代理运行检查并总结失败。然后，你可以阅读摘要并要求代理为你修复问题。尝试如下提示：

在此代码上运行ruff、mypy、bandit和pytest，然后仅总结值得我关注的失败。

如果你后来要求代理修复问题，那么你仍然必须确认修复有效。代理可能误解检查器的输出并应用实际上并未改进代码的修复。例如，某些代码块可能出于性能原因而有意重复，硬编码密钥可能是故意的测试密钥。

运行代码检查器和检查器是必要的，但还不够。下一步是你阅读剩余部分的地方。

5、有计划地阅读，而不是从上到下

现在是时候阅读代码了。但是，不要按列出的顺序从上到下阅读差异。相反，你应该先看风险较高的部分。例如，你可以从处理以下方面的代码开始，大致按此顺序：

• 安全性： 缺少授权检查、硬编码密钥和未经授权的访问是导致数据泄露、帐户接管和完整系统妥协的缺陷。
• 输入验证： 未经过净化的用户输入、缺少类型或长度检查以及未转义的查询参数可能导致代码注入攻击、应用程序崩溃和静默数据损坏。
• 数据处理： 不安全地反序列化不受信任的数据、以明文形式记录用户凭据以及有漏洞的错误消息可能导致数据暴露、合规性违规和远程代码执行。
• 控制流： 缺少早期return或break、永不更改的条件或未处理的错误路径可能导致不正确的结果、不一致的状态和难以调试的行为。
• 公共接口： 更改函数的签名或返回类型、重命名公共方法或暴露内部细节可能会破坏客户端代码、导致下游中断并强制用户重写。

总体而言，你应该由外向内阅读，遵循代码的流程而不是差异的顺序。首先，从入口点和结构中大致了解更改。然后阅读内部的行级详细信息。

如果你正在审查一个新生成的项目，那么你没有历史记录可以比较。因此，使用模块布局和导入安排首先检查结构。然后，根据项目的意图，按相关性深入研究模块和包。

注意： 同样，你可以从AI代理那里获得帮助。在新会话中，尝试如下提示：

按风险（安全性、输入处理和控制流优先）对差异中的文件和函数进行排序，并给我从最高到最低风险的阅读顺序。

到目前为止，你已经了解了审查策略，即如何浏览代码或差异。接下来，你需要具体的目标来使审查高效。在人类生成的代码中，错误分散且难以预测，这使你的工作更加困难。在AI生成的代码中，问题归结为几种可预测的类型，这使你的工作更容易。你可以将这些问题类型转化为指导你审查的简短清单。

6、查找AI生成代码中的常见问题

这一步是审查AI生成代码与审查队友的拉取请求不同的地方。你将发现的问题类型可能并不新鲜，但组合是不同的。此外，这些问题往往比人类编写的代码中发现的问题更可预测。请记住，AI非常擅长使事物看起来合理，但这并不意味着它们正确。

在以下部分中，你将探索AI生成代码中的一些常见问题，从高级到低级。首先，你将检查更改是否适合代码库结构。接下来，你将查看破坏事物的错误。最后，你将看到问题如何随时间累积。

6.1 架构、模块化和适配性

在阅读行级更改之前，请确保广泛的更改属于其所在位置。为此，你需要牢记代码的意图。

代理通常一次处理几个文件，可能看不到整个项目结构。因此，更改在局部可能是合理的，但在全局是错误的。如果代码位于错误的位置或重新发明了已存在的内容，那么你需要修复结构。

以下是架构、模块化和适配性问题的简短清单：

为了展示其中一些问题，假设你在命令行界面（CLI）工具的cli.py文件中找到以下Helper类：

# ...
class Helper:
    def parse_csv(self, path):
        """Parse a CSV file using the csv module."""
        # Implementation here...

    def send_email(self, to, subject):
        """Send an email using the smtplib module."""
        # Implementation here...

    def resize_image(self, path, width):
        """Resize an image using the Pillow library."""
        # Implementation here...

在这个Helper类中，没有任何东西属于一起。.parse_csv()、.send_email()和.resize_image()方法引入单独的依赖项，并因不同的原因而更改。每一个都可以存在于自己的模块中，可能还有自己的类。另外，为什么这个类在cli.py模块中？该模块应仅包含与CLI相关的代码。答案在你的领域中，而不是在代理中。

6.2 逻辑错误

逻辑错误通常会绕过自动检查，包括代码检查器、类型检查器，甚至复杂度评估。但是，它们可能导致代码产生错误和危险的结果，这使它们成为代码审查的核心。

以下是AI生成代码中可能发现的逻辑错误的简短清单：

差一错误可能因为输出看起来仍然正常而溜走。假设你有一个函数，它对数字列表中的每个滑动窗口求平均值：

>>> def moving_averages(values, window):
...     """Return the average of each sliding window over the values."""
...     averages = []
...     for start in range(len(values) - window):
...         averages.append(sum(values[start : start + window]) / window)
...     return averages
...
>>> moving_averages([1, 2, 3, 4], 2)
[1.5, 2.5]

包含n个数字的列表有n - window + 1个窗口需要求平均值，但range(len(values) - window)只运行n - window次，因此它会跳过最后一个窗口。这就是为什么它返回两个平均值而不是三个。它运行，它返回一个列表，并且没有任何抱怨。

修复方法是range(len(values) - window + 1)，通过检查输出长度是否符合预期来捕获它。

6.3 缺少边缘情况和吞没错误

代理经常针对提示中的快乐路径优化代码，并跳过你未提及的输入。它们还倾向于隐藏失败而不是显示它们。这种行为可能是错误的常见来源，因此你应该在审查中检查它。

以下是需要考虑的简短清单：

广泛的except会吞没错误，将真实失败转变为静默失败：

try:
    config = load_config(path)
except Exception:
    config = {}

在此示例中，当load_config()中断时，代码会静默地回退到空字典并继续运行。你永远不知道配置文件是丢失还是格式错误。

AI代理经常针对模拟进行断言或跳过边缘情况，因此即使代码可能在快乐路径之外失败，测试也会保持绿色。浏览与正在审查的代码相关的测试用例，以确认它们测试这些输入，而不仅仅是常见情况。

6.4 安全漏洞

安全性是看似合理的行造成实际损害的地方，因此首先阅读数据访问和身份验证路径。

以下是AI生成代码中可能发现的安全问题的快速清单：

在步骤2中，你扫描了代码以捕获其中许多问题，但这些检查并非万无一失。Bandit和Ruff通过变量名标记硬编码密钥，因此存储在普通名称下的真实密钥可能绕过它们。这就是为什么值得再看一遍。

例如，下面的查询将用户输入直接插入SQL代码，从而允许注入：

def find_user(cursor, username):
    cursor.execute(
        f"SELECT * FROM users WHERE name = '{username}'"
    )
    return cursor.fetchone()

在此示例中，像' OR '1'='1这样的用户名会使WHERE子句匹配users表中的每一行，因此函数返回它找到的第一个用户，而不是你要求的用户。修复方法是传递查询参数，而不是直接使用用户输入构建字符串。

6.5 编造的API和包

AI代理可以生成看似合理的代码，有时看似合理的东西并不存在。代码看起来正确，但代理发明了方法、导入或包。这可能是AI生成代码的常见故障模式，如果你不了解目标API，通常很难标记。如有疑问，请检查API文档或要求代理运行代码以确保它不会中断。

以下是审查中可以帮助你的快速清单：

例如，在下面的代码中，代理调用了一个看起来正确但不真实的方法：

import pathlib

settings = pathlib.Path("config.toml").read_toml()

Path类上没有.read_toml()。在这种情况下，像mypy这样的工具会标记该调用。但是，更微妙的发明只有在你阅读或运行代码时才会显示。

虚假包是一个真正的风险。前沿模型比小模型产生更少的虚假包，但危险仍然存在，并且可能成为关键的安全问题，因为攻击者可以注册流行的虚假名称来提供恶意软件。

6.6 性能和资源陷阱

性能是代码审查的另一个关键方面。例如，你可能遇到这样的情况：代码在笔记本电脑上使用十行数据可以正常工作，但在生产中使用一千万行数据时会中断。测试很少捕获此类问题，因为它们通常在小数据集上运行。因此，你应该在审查中检查性能陷阱。

以下是AI生成代码中可能发现的性能和资源问题的简短清单：

N+1查询看起来无害，因为每行都是一个正常的数据库调用：

def order_totals(connection, order_ids):
    """Return the total for each of the given order IDs."""
    totals = []
    for order_id in order_ids:
        cursor = connection.execute(
            "SELECT total FROM orders WHERE id = ?", (order_id,)
        )
        totals.append(cursor.fetchone()[0])
    return totals

在此示例中，循环对每个订单运行一个查询，而不是批量获取它们。对于十个订单来说是即时的请求，对于一万个订单来说会变得很慢。代理无法看到你的数据量，因此它优化的是可读代码，而不是可扩展性。

你的审查要点是，循环中的查询随着数据量而不是代码量而扩展。在你测试的卷中，成本保持不可见，只在生产中出现。当你发现一个时，检查是否可以用单个批处理查询替换整个循环。

6.7 并发和异步错误

并发是最难正确处理的领域之一，也是AI生成代码最常看起来令人信服但隐藏严重问题的地方。代码在开发中运行顺畅，请求一个接一个到达，然后在真实负载下损坏数据或挂起。

代码检查器和类型检查器很少有帮助，因为每一行本身都是有效的，错误在于这些行如何交织。

以下是审查中可能发现的并发和异步问题的简短清单：

阻塞调用是最常见的异步疏忽，因为代码仍然看起来像异步代码：

import requests

async def fetch_prices(symbols):
    """Return the current price for each of the given symbols."""
    prices = {}
    for symbol in symbols:
        response = requests.get(f"https://api.example.com/price/{symbol}")
        prices[symbol] = response.json()["price"]
    return prices

这里，requests.get()是一个同步调用，因此它在每个请求上阻塞整个事件循环。当一个请求正在运行时，没有其他协程可以运行。

它读起来像异步代码，但async关键字什么也没买。修复方法是使用异步HTTP客户端（如httpx或aiohttp），这样每个请求在等待时都会让出控制权。

6.8 可维护性问题

可维护性是长期游戏。一个函数今天可以正常工作，但明天仍然难以更改。AI生成的代码往往集中在几个可维护性陷阱周围：它要么太聪明，要么太无聊，中间几乎没有。

以下是可维护性问题的简短清单：

太长的函数难以测试、难以阅读、难以更改。当你看到一个时，询问是否可以将其分解为更小的函数，每个函数只做一件事。

死代码是另一个常见陷阱。代理可能会留下注释掉的块或不可达的分支。删除它们。它们会增加噪音并可能误导未来的读者。

命名微妙但至关重要。名为process_data()的函数什么也没告诉你。名为parse_csv_rows()的函数确切地告诉你它的作用。当名称模糊时，重命名它。

7、修复问题，然后验证修复

一旦你确认了问题，就修复它。不要将其作为评论留给其他人。请记住，你拥有结果。

以下是修复问题的一些指导原则：

• 修复根本原因，而不是症状。 如果一个函数太长，请将其分解。不要只添加一条注释说"这太长了"。
• 进行最小的更改以修复问题。 修复错误时不要重构无关代码。
• 修复后重新运行自动检查。 确保你的修复没有引入新问题。
• 如果需要，请手动测试修复。 某些问题需要运行代码来验证。

修复后，重新运行步骤2中的检查。如果修复正确，检查应该通过。如果没有，请迭代直到通过。

8、故障排除

以下是你可能遇到的一些常见问题及其解决方法：

问题： 代理的代码使用我不认识的库。 解决方案： 检查库的文档。如果它是一个真实的包，安装并测试它。如果是虚假的，请用真实的替代品替换它。

问题： 代码通过所有检查但仍无法正常工作。 解决方案： 这可能是逻辑错误。编写一个重现失败的测试用例，然后修复代码以通过测试。

问题： 代码太复杂无法理解。 解决方案： 分解它。要求代理解释每个部分，或者将其重构为更小的函数。

9、后续步骤

现在你有了审查AI生成代码的工作流程，以下是一些后续步骤：

1. 使用真实代码进行练习。 找到一个AI生成的拉取请求或项目，并应用该工作流程。
2. 构建你的清单。 自定义本教程中的清单以适应你项目的需要。
3. 与团队分享。 教授你的队友工作流程，以便每个人一致地审查AI生成的代码。

10、常见问题

问：审查AI生成的代码真的与审查人类代码不同吗？答：原则是相同的，但问题的组合不同。AI代码往往有更多的看似合理的错误、编造的API和缺少的边缘情况。

问：代码审查应该花多长时间？答：这取决于更改的大小和复杂性。对于AI生成的代码，目标是在一小时内完成。如果花更长时间，请将审查分成更小的块。

问：我可以相信自动检查能捕获一切吗？答：不能。自动检查捕获机械问题，但会错过逻辑错误和糟糕的抽象。你仍然需要仔细阅读代码。

问：如果我发现错误但不知道如何修复它怎么办？答：要求代理修复它，或咨询队友。重要的是标记问题，不一定是你自己修复它。

原文链接：How to Review AI-Generated Python Code Efficiently

汇智网翻译整理，转载请标明出处