AI生成的代码可能看起来正确，但仍会在边缘情况、安全性和可靠性上出问题。

在本指南中，@manishmshiva 解释了如何通过测试、黄金数据集、重复运行和人工审查来评估它。

你将学到一套实用工作流，用于捕获回归问题，并更有信心地交付 AI 辅助代码。

https://freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/…

如何评估 AI 代码质量：工程师实用指南

来源：https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/ 如何评估 AI 代码质量：工程师实用指南你让 AI 写一个函数。它给了你一个看起来正确的代码。甚至能跑通。但它真的好吗？

大多数工程师就此止步。他们看到绿色就继续前进。这个习惯会悄悄给你带来麻烦。

像 GitHub Copilot (https://github.com/features/copilot)、Cursor (https://www.cursor.com/) 和 Claude 这样的 AI 编码工具确实有用。但它们是非确定性的，意味着相同的提示在不同日子可能产生不同输出。

它们可能生成看起来合理但微妙错误的代码，或者能走通快乐路径但在边缘情况下崩溃的代码。如果没有一套系统来评估 AI 给予你的代码，你基本上就是在交付未经测试的第三方代码，并希望一切顺利。

本指南将带你了解一个实用且适合初学者的评估 AI 生成代码的方法，让你能充满信心地使用这些工具，而不是祈祷好运。

我们将涵盖：

• 为什么 AI 代码需要自己的评估规范 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-why-ai-code-needs-its-own-evaluation-discipline)
• 第一步：在生成前定义正确性 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-step-one-define-correctness-before-you-generate)
• 第二步：构建黄金数据集 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-step-two-build-a-golden-dataset)
• 第三步：衡量可靠性，而不仅仅是正确性 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-step-three-measure-reliability-not-just-correctness)
• 第四步：审查测试无法捕获的内容 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-step-four-review-for-what-tests-cant-catch)
• 第五步：将提示更改视为代码更改 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-step-five-treat-prompt-changes-like-code-changes)
• 让这套方法奏效的思维模式 (https://www.freecodecamp.org/news/how-to-evaluate-ai-code-quality-a-practical-guide-for-engineers/#heading-the-mindset-that-makes-this-work)

为什么 AI 代码需要自己的评估规范

当人类同事写代码时，你可以问他们问题。你可以查看他们的提交历史。你有上下文。

当 AI 写代码时，你什么也没有。输出是完整成形的，通常带有自信满满的注释，很容易认为它能力很强，而实际上可能并非如此。

另一个问题是，AI 模型是在大量公开代码上训练的，包括糟糕的公开代码。它们能流畅地复现反模式。它们写的代码可能通过快速阅读，但在真实负载、异常输入或安全审查下失败。

评估 AI 代码不是不信任 AI。而是对进入你代码库的任何代码应用同样的工程规范。

第一步：在生成前定义正确性

你能做的最有效的一件事是在要求 AI 写实现之前先写测试。这是测试驱动开发 (TDD (https://martinfowler.com/bliki/TestDrivenDevelopment.html)) 的精神，它完美地适用于 AI 辅助工作流。

当你提前定义正确性时，代码一到达你就有了一个客观的衡量标准。你不是在靠眼睛看。你是在针对你自己编写的契约运行它。

这里有一个简单的例子。假设你想让 AI 写一个函数，解析像 "$12.99" 这样的价格字符串并返回一个浮点数。在提示 AI 之前，先写这个：

def test_parse_price():
    assert parse_price("$12.99") == 12.99
    assert parse_price("$0.00") == 0.0
    assert parse_price("$1,299.99") == 1299.99
    assert parse_price("") is None
    assert parse_price("free") is None

现在提示 AI：“写一个 Python 函数，名为 parse_price，它接受一个像 $12.99 或 $1,299.99 这样的价格字符串并返回一个浮点数。对无效输入返回 None。”

立即运行你的测试。AI 可能通过五个中的四个。现在你确切知道要修复什么，而且你无需阅读任何一行实现代码就找到了差距。

第二步：构建黄金数据集

黄金数据集是一个小的输入集合，带有已知的正确输出。将它视为你构建的任何 AI 功能的永久测试套件。从五到十个例子开始。每当生产环境中出现问题时，就往里添加。

这将成为你的回归集。每当你调整提示、升级模型或重构流水线时，先运行黄金数据集。如果有任何东西坏了，你会立刻知道。

这是价格解析器的黄金数据集的样子。一个简单的 JSON 文件就很好：

[
  { "input": "$12.99",    "expected": 12.99,  "note": "基本案例" },
  { "input": "$1,299.99", "expected": 1299.99, "note": "千位分隔符" },
  { "input": "12.99",     "expected": 12.99,  "note": "缺少美元符号" },
  { "input": "$ 12.99",   "expected": 12.99,  "note": "符号后有空格，来自生产 bug #142" },
  { "input": "€12.99",    "expected": null,   "note": "不支持的货币" },
  { "input": "free",      "expected": null,   "note": "非数字文本" },
  { "input": "",          "expected": null,   "note": "空字符串" }
]

每个条目只是一个输入、正确的输出和一个简短说明为什么在那里。一个脚本加载文件，通过你的函数或提示运行每个输入，并比较结果。

对于代码生成用例，同样的思路可以扩展：一个输入提示文件夹，配上对应的期望输出文件，通过脚本进行差异比较。对于数据提取，一个 CSV 文件，包含样本输入和期望解析值。

那么如何决定放什么呢？三个来源覆盖了大部分情况。

首先是代表性案例：你的功能百分之九十时间处理的普通输入。其次是你预先可以预测的边界情况，比如空字符串、异常格式以及应该被拒绝的输入。第三，也是最宝贵的，真实失败。

注意上面标记了生产 bug 编号的 $ 12.99 条目。一个用户遇到了那个输入，解析器崩溃了，现在它永远留在数据集中。测试就是这样：如果一个输入曾经导致过问题，或者有可能，它就获得一个永久位置。如果只是你已经覆盖案例的微小变体，跳过它，保持数据集足够小以便每次更改都能运行。

关键纪律是：不要只修复失败的案例。将它添加到黄金数据集，修复它，并验证其他所有仍然通过。这就是阻止打地鼠问题的方法，即修复一个 AI 失败会静默破坏其他三个。

第三步：衡量可靠性，而不仅仅是正确性

AI 输出不是确定性的。一次正确不代表总是正确。如果你将 AI 嵌入到产品中，这一点尤其重要：一个 80% 时间有效的提示会在 20% 的时间让用户失败，这在生产环境中是不可接受的。

解决办法是在多个样本上运行你的评估。将同一个提示运行十次，并检查有多少输出通过了你的测试。像 promptfoo (https://promptfoo.dev/) 这样的工具可以轻松实现自动化。你在配置文件中定义测试用例，指向你的提示，它就会运行评估并报告通过率。

这是一个简单的 promptfoo 配置示例：

prompts:
  - "Parse the following price string and return only a float: {{input}}"

providers:
  - openai:gpt-4o

tests:
  - vars:
      input: "$12.99"
    assert:
      - type: equals
        value: "12.99"
  - vars:
      input: "$1,299.99"
    assert:
      - type: equals
        value: "1299.99"
  - vars:
      input: "free"
    assert:
      - type: equals
        value: "null"

在十次迭代中运行这个，你会很快发现你的提示是否脆弱。十次运行 100% 通过率给你真正的信心。70% 的通过率告诉你这个提示在接近生产环境之前需要收紧。

第四步：审查测试无法捕获的内容

测试告诉你代码是否正确。它们不会告诉你代码是否可读、可维护或安全。在自动检查通过后，对三件事进行聚焦的人工审查。

第一是安全性。AI 模型可能生成具有真实漏洞的代码，比如通过字符串拼接的 SQL 注入、缺少输入清理、以及示例中硬编码的凭据，然后 AI 忘了标记。将 AI 生成的代码通过静态分析工具运行，比如 Python 的 Bandit (https://bandit.readthedocs.io/) 或 JavaScript 的 ESLint 搭配安全插件 (https://github.com/eslint-community/eslint-plugin-security)，作为基线检查。

第二是 AI 未考虑到的边缘情况。查看你写的测试案例并问自己：我没有覆盖什么？空列表、空值、非常大的输入、并发调用等可能没有被 AI 处理。你需要推动它在边界上工作。

第三是过度工程。AI 有时会对简单问题产生复杂的解决方案。如果你要求一个检查数字是否为偶数的函数，却得到了一个带有三个方法和一个配置对象的类，那是一个危险信号。

复杂性是一种成本。优先选择你理解的简单代码，而不是你不理解的聪明代码。

第五步：将提示更改视为代码更改

如果你以可重复的方式使用 AI，比如内部工具、产品功能或你定期运行的脚本，那么你的提示是你的代码库的一部分。对它们进行版本控制。审查对它们的更改。不要只是编辑一个提示并希望最好。

实用的习惯是将提示存储在文件中而不是硬编码在行内，与你的代码一起提交到 Git，并在提示发生变化时重新运行你的黄金数据集。这大概需要十分钟来设置，并能为以后的调试节省数小时。

LangSmith (https://smith.langchain.com/) 和 Weights & Biases (https://wandb.ai/) 都提供提示版本控制和评估跟踪，如果你想要更结构化的解决方案。对于大多数小项目，仓库中的一个 prompts 文件夹和一个简单的测试运行器就足够了。

让这套方法奏效的思维模式

本指南中的每一种技术都归结为一个转变：将 AI 输出视为外部输入，而不是可信代码。

你不会在未验证其形状的情况下就将 API 响应部署到生产环境。你不会在未检查内容的情况下接受文件上传。AI 生成的代码应得到同样的怀疑，不是因为 AI 不可靠，而是因为所有外部输入都不可靠，而好的工程会考虑到这一点。

最能从 AI 工具中受益的工程师不是那些最信任它们的人。而是那些最快验证的人。先写测试。构建黄金数据集。衡量可靠性。审查自动化的遗漏。对提示进行版本控制。

持续做这五件事，你将用与代码库中其他任何东西相同的信心来交付 AI 辅助代码。

希望你喜欢这篇文章。你可以通过 LinkedIn (https://linkedin.com/in/manishmshiva) 与我联系。

免费学习编程。freeCodeCamp 的开源课程已帮助超过 40,000 人获得开发者工作。立即开始 (https://www.freecodecamp.org/learn)