7 Checks to Run Before Trusting AI-Generated Code

KDnuggets

KDnuggets2026年10月19日

7 Checks to Run Before Trusting AI-Generated Code

6.9内容质量

TL;DR · AI 摘要

7 Checks to Run Before Trusting AI-Generated Code - KDnuggets publ: 19-Oct, 2026 - Blog Top Posts About - Topics AI Care...

核心要点

主题聚焦：7 Checks to Run Before Trusting AI-Generated Cod
来源：KDnuggets，建议结合原文判断细节。
AI 分析暂不可用，本条为保底评分与摘要。

#AI#编程#前端#后端#云计算

打开原文

在信任AI生成代码之前需要执行的7项检查 - KDnuggets

publ: 2026年10月19日

博客热门文章

主题 AI 职业建议计算机视觉数据工程数据科学语言模型机器学习 MLOps NLP 编程 Python SQL

数据集

活动

资源快速参考指南推荐技术简报

广告

订阅电子报

#header end

/ad_wrapper

在信任AI生成代码之前需要执行的7项检查

AI让编写代码变得便宜。验证代码仍然是你的工作。

作者：Kanwal Mehreen，KDnuggets技术编辑兼内容专家，2026年10月19日发布于人工智能领域

AI代码助手可以在几分钟内生成大量可运行的代码。这提高了生产效率，但也使它们变得危险。糟糕的AI生成代码不一定看起来糟糕。它可能能够编译、通过测试并使用清晰的变量名，但仍可能对API、授权规则、边界情况或依赖项做出错误假设。GitHub警告称AI生成代码可能存在语义错误，并建议在合并前仔细审查和测试。因此与其问"这段AI生成代码看起来好吗？"，不如运行以下7项检查。

这段AI生成代码看起来好吗？

1. 在运行任何操作前检查差异

你的第一个检查不应是ChatGPT、Copilot、Claude Code或其他模型。

它应该是Git。

当编码代理被授予整个仓库的访问权限时，有时会修改超出任务需求的范围。一个小的错误修复可能意外地变成重构、依赖项更新、配置更改和格式化清理。

从以下命令开始：

code

git status
git diff --stat
git diff

git diff --stat能立即给你一个差异范围的概览。

假设你让代理执行：

code

为电子邮件注册端点添加验证。

你预期只修改两个文件。但差异显示：

code

12 files changed, 437 insertions(+), 186 deletions(-)

在此处停止。

在检查代码是否有效之前，先询问为什么这个任务需要修改数百行代码。

在审查差异时，特别注意以下内容：

与任务无关的文件被删除的测试、禁用的验证、新增的配置值、权限变更、依赖文件变更、隐藏在功能中的大规模重构、重复的辅助函数、忽略失败的错误处理

目标很简单：确保AI解决了你给出的任务，而不是它自己发明的更大任务。

2. 让编译器、代码检查器和类型检查器来评判

人类是糟糕的编译器。

不要花十分钟视觉检查语法，而这些确定性工具可以在几秒钟内完成检查。

对于Python项目，你的首次自动化检查可能如下：

code

python -m compileall .
ruff check .
mypy .

对于JavaScript或TypeScript：

code

npm run lint
npx tsc --noEmit
npm run build

静态类型检查对AI生成代码特别有用，因为模型可能会自信地连接看似兼容但实际上不兼容的值。

例如：

code

def get_user_id(user: dict[str, str]) -> int:
    return user["id"]

这段代码看起来无害。但声明的字典包含字符串，而函数声称返回整数。类型检查器可以立即标记出这个问题。

模型有时会编造包名，这些名称看起来可能完全合理。

例如，AI可能会建议：

code

pip install fastapi-jwt-auth-plus

不要仅仅因为名称听起来合理就假设依赖项存在。

一项2025年的研究分析了576,000个大型语言模型（LLM）生成的代码样本，并记录了Python和JavaScript中的包名幻觉现象——商业模型为5.2%，开源模型为21.7%。这很重要，因为幻觉生成的包名会创造一种称为"slopsquatting"的机会：有人可以注册一个常见幻觉名称的包，并可能欺骗开发者安装它。因此，每当AI添加依赖项时，请独立验证。

对于Python：

code

pip index versions package-name

对于npm：

code

npm view package-name

然后检查：

包是否真的存在？这是官方包吗？由谁维护？最后更新时间？项目真的需要它吗？版本是否与代码似乎使用的文档匹配？lockfile是否突然发生重大变化？是否引入已知漏洞？

对API执行相同检查。

如果AI编写：

code

client.responses.stream_async(...)

不要假设该方法存在，因为它可能与SDK其余部分相似。

打开当前官方文档并确认：

code

class → method → parameters → return type → supported version

这对于快速变化的AI SDK、云API和JavaScript框架尤为重要。每个新引入的包和每个不熟悉的外部API都应可追溯到权威注册表或官方文档。

4. 测试行为而非实现

现在运行现有的测试套件。

code

pytest -q

但绿色的测试套件只是开始。更重要的是：

什么重要情况未被测试？

假设AI生成了：

code

def apply_discount(price, discount):
    return price - (price * discount / 100)

并生成了以下测试：

code

def test_discount():
    assert apply_discount(100, 10) == 90

很好。

但以下情况呢：

code

discount = 0
discount = 100
discount = -10
discount = 150
price = 0
price = None
price = "100"

AI经常生成正常路径，因为正常路径在示例和文档中也最突出。对于每个生成的功能，至少测试以下四类：

code

正常输入
边界输入
无效输入
失败条件

对于API端点，这可能意味着：

code

有效请求
缺失字段
字段格式错误
未授权请求
数据库/服务故障

还要确保AI没有通过删除测试或弱化断言来"修复"失败的测试。对于关键功能，考虑在向其他模型展示实现之前先编写测试。该功能应能经受住测试，验证当用户、网络、数据库、文件系统和输入数据发生意外情况时的行为。

5. 攻击安全边界

功能正确性和安全性是不同的测试。这个函数可能有效：

code

query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)

它甚至可能通过所有单元测试。

它仍然不安全。

每当AI生成的代码涉及用户控制的输入、认证、数据库、文件、shell命令或外部URL时，应从功能思维模式切换到对抗性思维模式。

在补丁中搜索涉及以下区域的内容：

code

SQL 查询
认证
授权
文件路径
子进程执行
HTML 渲染
反序列化
重定向
HTTP 请求
令牌
密码
API 密钥

提出类似的问题：

code

用户能否控制这个字符串？
他们能否访问他人的资源？
这个路径能否逃出预期的目录？
这个查询能否参数化？
这个命令能否执行任意输入？
如果这个 URL 指向内部服务会怎样？
权限检查是否在服务器端执行？

然后在适当的位置运行静态安全工具。

一个通用选项是 Semgrep :

code

semgrep scan --config auto

Semgrep 文档中说明了此配置用于自动选择相关的扫描规则。

Python 项目还可以使用 Bandit :

code

bandit -r .

Bandit 通过分析 Python 的抽象语法树来查找常见的安全问题。

使用 GitHub 的仓库可以启用 CodeQL 代码扫描，它可以在拉取请求和受保护分支上分析支持的语言。

另一个重要的检查是：搜索敏感信息。查找：

code

API 密钥
数据库密码
OAuth 令牌
私钥
云凭证
连接字符串

GitHub 的敏感信息扫描专门用于检测意外提交到仓库的凭证。AI 助手绝不应该将这种代码：

code

api_key = os.environ["API_KEY"]

转换为：

code

api_key = "sk-..."

仅仅因为它在环境或上下文中看到了凭证。任何未经信任的输入在跨越安全边界时，都必须由你明确了解其验证、转义、授权或隔离的方式。

6. 跟踪失败路径

当一切正常时，AI 生成的代码看起来往往很强大。因此，要刻意检查当一切不正常时会发生什么。

考虑这段生成的代码：

code

try:
    response = requests.get(url)
    return response.json()
except Exception:
    return {}

它似乎很健壮，因为它包含错误处理。但实际上，它可能隐藏：

超时
连接失败
认证错误
无效 JSON
HTTP 500 错误
编程错误

而所有这些情况都会返回：

code

{}

这会使调试变得困难得多。寻找这种广泛模式：

code

except Exception:
    pass

code

catch (e) {
  console.log(e);
}

或：

code

return None

被用于处理多个不相关的失败。

还要检查以下内容：

#### 重试机制

AI 是否会无限重试？

code

while True:
    try:
        ...
    except Exception:
        continue

#### 超时设置

网络请求是否有超时？

code

requests.get(url, timeout=10)

#### 事务

如果第三个操作失败，前两个操作是否会回滚？

#### 异步代码

任务是否被正确等待？

#### 共享状态

两个请求是否可能同时修改相同的数据？

#### 资源清理

在发生错误后，数据库连接、临时文件、套接字和锁是否被释放？

一个有用的测试是故意破坏每个外部依赖项。例如：

code

关闭数据库。
让 API 返回 HTTP 500。
提供损坏的 JSON。
移除文件权限。
强制请求超时。
同时提交相同的请求两次。

观察你的应用程序会如何响应。问题不是：

code

它是否会失败？

而是：

code

它是否会以可预测、安全且明显的方式失败？

7. 质疑代码是否应该存在

最后的检查往往是开发者容易忽略的。假设 AI 生成了以下代码：

code

def transform_items(items):
    output = []

    for item in items:
        transformed_item = transform_single_item(item)
        output.append(transformed_item)

    return output

和：

code

def transform_single_item(item):
    return item["name"]

整个过程可以简化为：

code

[item["name"] for item in items]

这并非单纯追求代码简洁。AI编码代理可能会生成不必要的：

包装器、类和辅助函数
配置层和抽象层
注释、后备逻辑和重复的实用工具

在合并前，请自问：

code

这个功能是否引入了新的抽象层？
现有函数是否已经可以完成此任务？
我们是否为标准库已具备的功能添加了新库？
AI是否复制了已有的辅助函数？
能否在不损失清晰度的前提下将实现减少30%？
六个月后我是否还能理解这段代码？

但不要以最小化行数作为优化目标。

应以最小必要新增复杂度来解决问题为目标。

这也是人类理解成为最终关卡的地方。

选取生成的最重要函数，尝试不借助AI进行解释。

如果你无法解释：

code

输入是什么
输出是什么
状态发生了哪些变化
哪些情况可能导致失败
为何选择这种实现方式

那么你尚未准备好在生产环境中负责这段代码。

最后思考

AI编码工具显著降低了代码生成的成本。但它们并未降低证明代码正确性的成本。错误的应对方式是怀疑AI生成的每一行代码。

因此，最佳的AI编码工作流程不是“生成并信任”，

而是“生成并验证”。

AI可以是你团队中最快的程序员。你的职责是确保它仍需通过与其他成员相同的审核标准。

Kanwal Mehreen 是一名机器学习工程师和技术作家，对数据科学以及AI与医学的交叉领域充满热情。她合著了电子书《利用ChatGPT最大化生产力》。作为2022年APAC地区谷歌新一代学者，她倡导多样性和学术卓越。她还被认定为Teradata科技多样性学者、Mitacs Globalink研究学者以及哈佛WeCode学者。Kanwal是变革的坚定倡导者，她创立了FEMCodes组织，致力于赋能STEM领域的女性。

7 Checks to Run Before Trusting AI-Generated Code

TL;DR · AI 摘要

核心要点

在信任AI生成代码之前需要执行的7项检查 - KDnuggets

在信任AI生成代码之前需要执行的7项检查

1. 在运行任何操作前检查差异

2. 让编译器、代码检查器和类型检查器来评判

4. 测试行为而非实现

5. 攻击安全边界

6. 跟踪失败路径

7. 质疑代码是否应该存在

最后思考

更多相关内容

最新文章

热门文章