AI生成的代码审查训练：如何教会开发人员审核模型编写的内容

一位开发人员向助手请求编写一个函数，用于检查用户是否可以下载报告。代码编译通过，正常流程测试也通过了，提交的拉取请求看起来也很简洁。两周后，一位同事发现该函数虽然检查了用户是否已登录，但从未检查报告是否属于该用户。

这是一个示例场景，并非已记录的事件。它描述了人工智能生成的代码审查培训需要弥补的差距：即使生成的代码通过了基本检查，仍然可能包含授权或并发缺陷，审查人员需要找出这些缺陷并说明其重要性。

本指南面向工程赋能负责人和工程经理。内容涵盖如何描述性能问题、诊断差距、设计准备和实践、案例分析以及评估技能是否能应用于实际评审。它着重于培训设计。您项目中的每个缺陷、测试和评审规则都应由高级工程师和安全团队验证。

什么是AI生成的代码审查训练？

AI生成的代码审查训练教会开发者如何清晰地向助手提出问题，然后评估和审核返回的结果：代码是否正确、是否安全、在并发负载下是否稳定、是否足够高效？这并非针对特定工具的课程，而是培养一种即使工具变更也能保持不变的审查习惯。

要闻速览

1. 描述性能问题

首先，任务是：审核生成的代码，并通过测试来验证风险。审核是带着怀疑的态度阅读代码。验证则是将怀疑转化为证据，通常是通过失败的测试或重现缺陷的实例来实现。

研究表明，这需要刻意练习。在对 GitHub Copilot 的一项研究中，Pearce 及其同事针对已知的弱点类型，在 89 个场景中生成了 1,689 个程序，发现其中约 40% 存在漏洞（Pearce 及其同事，2021那是一个早期工具，针对的是一组特定的场景，所以不要将该数据视为当今助手的适用率。另一项用户研究要求参与者在有AI助手和没有AI助手的情况下编写代码。结果显示，使用助手的参与者编写的代码安全性明显更低，而且他们更倾向于认为自己的代码是安全的（Perry及其同事，2023同一项研究发现，对助手信任度较低、更积极配合助手提示的参与者表现出的脆弱性较少。

以下两点经验可用于培训设计：首先，合理的输出需要积极的审核；其次，自信并非证据，因此练习必须要求进行测试，而不是征求意见。

用一句话写出性能说明，并让工程经理检查一下：“给定一个生成的变更，开发人员列出他们看到的安全性、并发性和效率风险，并针对每一种风险描述或编写一个可以证明该风险的测试。”

2. 诊断学习和情境差距

在着手构建任何内容之前，请将任务与你现有课程的练习和评估方式进行比较。通常，以下三个问题可以区分培训差距与其他问题：

1. 目前的做法是否使用了实际任务？ 如果培训内容仅限于编写提示代码，却从不要求开发人员审查输出结果，那么就没有人真正实践过审计。如果评估方式是针对安全编码规则的多项选择题，那么它衡量的只是对规则的记忆。
2. 认知需求是什么？ 在布鲁姆修订后的分类法中，判断代码是否安全以及选择合适的测试来证明其安全性属于分析和评估层级，而设计更好的提示或修复方案则属于创造层级。我们的指南中介绍了如何将活动与这些层级相匹配。 将学习活动与布鲁姆分类法相匹配.
3. 除了技能之外，还有其他因素阻碍了你吗？ 检查审核时间、工具和负责人。如果审核人员每个拉取请求只有五分钟时间，那么没有经过培训就无法进行审核。如果流程中没有静态分析或测试框架，开发人员可能发现风险，但却无法证实。将非培训原因报告给能够解决这些问题的人员。

3. 设计准备和练习

一旦你了解培训可以弥补哪些差距，就给每个阶段分配一个明确的任务。

准备。 通过简短的诊断来检查前提条件：你的测试体系面临的常见弱点类别、测试的结构以及团队使用的复习清单。自主学习适合这个阶段。回顾检查仅用于确认前提条件。

实践。 使用基于真实生成代码构建的审计练习。每个练习都预先设置少量不同类型的缺陷，例如缺少所有权检查、两个请求之间存在竞争条件以及低效的循环，同时添加一些正常的代码。开发人员审查代码，指出每个风险，说明其严重程度，并提出能够重现该风险的测试方案。要求开发人员提供理由，而不是仅仅罗列代码行号。

反馈。 将其与决策联系起来，而不是与总分联系起来。“你标记了循环，但没有标记共享计数器上的竞争条件，而且你的测试不会发现它，因为它一次只运行一个请求”比“找到 3 个中的 2 个”更有用。

实时输入还是异步审核？ 当风险不明确时，实时反馈最具价值，开发人员可以通过聆听资深工程师解释为何会阻止合并来学习。异步评审足以将开发人员的发现与专家的注释评审进行比较。许多团队会同时采用这两种方式：先进行自主准备，然后再针对疑难案例进行引导式讨论。

4. 通过一个实际例子进行分析

举例说明。工程经理在使用前应验证案例和答案标准。

案子。 生成的端点会根据发票 ID 返回客户的发票。它会检查调用者是否拥有有效的会话，使用参数化查询，并通过基本测试。该函数还会在不加锁的情况下递增共享的下载计数器。

任务。 开发人员列出了他们看到的每项风险，对风险进行了排名，并描述了可以证实每项风险的测试。

第一次尝试。 “看起来没问题。查询语句已参数化，测试也通过了。” 开发人员将测试通过视为万无一失，而没有追问测试遗漏了哪些内容。

反馈并重试。 审核人员要求开发人员说明会话检查证明了什么，又没有证明什么。重试要求他们考虑两个不同的客户和两个同时发生的请求。

一次更有力的尝试。 “会话检查只能证明是谁在打电话，并不能证明发票是他们的。我会编写一个测试，让客户 A 请求客户 B 的发票 ID，并预期会被拒绝。计数器在没有同步的情况下递增，因此两个同时请求可能会导致更新丢失。我会运行一个并发测试并比较计数。查询本身是参数化的，所以我不会在这方面花费时间。” 请注意，此答案对风险进行了排序，并将每项风险与一个测试联系起来。

解释每种回应的合理性或不足之处。 评判每项内容都应依据既定标准，而非评审者的个人偏好。第一次尝试往往出于习惯，却忽略了证据。而更有效的尝试则应具体明确、分清轻重缓急且可验证。

5. 评估能力并制定转移计划

能力证明体现在学习者完成一项之前未曾接触过的新练习中。评分标准包括质量验证和相关缺陷的识别。一个简单的评分细则采用0到2分的等级制，每个标准对应一个评分标准：

评分标准：0 分表示缺失或不支持，1 分表示部分缺失相关内容，2 分表示完整且符合既定标准。请单独定义关键错误，例如批准具有未保护访问路径的代码，以确保总分不会掩盖此类错误。本评分标准仅为建议，并非已验证的就绪标准：请与工程经理共同调整并进行试点。请参阅我们的指南。 设计具有实用反馈的互动练习 展示了如何撰写与决策相关的反馈意见。

精心计划代码移交。练习结束后，让每位开发人员与一个包含生成代码的真实拉取请求配对，并共同审查他们的发现，或者对最近一次遗漏之处的审查进行简短的回顾。

互动式教学有助于

交互式格式有助于确保每个人在小组会议开始前就做出承诺。在实时会议中，主持人可以展示一段生成的代码片段，要求每位开发人员输入他们看到的风险以及他们将要编写的测试，然后在讨论之前公布结果。同样的练习也可以以自学模式进行，以便进行准备。AhaSlides 支持交互式学习，并可在实时和自学模式之间灵活切换。它是一个演示和学习工具，而不是代码运行平台，因此请在您自己的环境中运行代码练习。请将您计划使用的任何特定创作、反馈或报告功能与您自己的工作流程进行核对。有关选择格式的指导，请参阅我们关于……的文章。 何时使用自适应、交互式和实时学习.

衡量发生了哪些变化

预先确定哪些指标能够证明开发人员胜任该任务。将未见过的练习的验证质量和缺陷识别情况与基准进行比较。明确参与人员、分母和时间节点。如果结果有所改进，在将改进归功于培训之前，请检查同一时期内还有哪些其他变化，例如新的静态分析规则、修订的审查清单或助理的更换。

可能存在的限制

• 复习时间。 审计比粗略浏览花费的时间更长，而截止日期又促使人们倾向于粗略浏览。
• 工具。 如果没有测试装置或管道扫描，风险很难得到证实。
• 更换工具。 助手更换很快，所以练习应该围绕评价习惯展开，而不是针对某个产品。
• 案件承保范围。 一项练习展示了几种缺陷类型。评分并不能反映开发人员的总体判断。
• 转让。 研讨会上的表现与繁忙的评审队列上的表现并不相同。

尽早将这些问题告知赞助商，并制定单独的解决方案。培训可以提高开发人员发现和验证问题的能力，但并不能节省时间或创造工具。

常见问题

什么是AI生成的代码审查训练？

它教会开发人员如何提示、评估和审核 AI 助手生成的代码，找出安全性、并发性和效率问题，并用测试来验证每个问题。

系统生成的代码比人类编写的代码安全性更低吗？

研究表明存在风险，但结果取决于工具、任务和研究设计。一项用户研究发现，有助手协助的参与者编写的代码安全性较低，但却对自己的代码更有信心，这说明培养代码审查习惯很有必要。

如何评估开发人员是否能够审核生成的代码？

布置一项新的代码练习，并根据既定标准对代码质量和缺陷识别进行评分。安全编码规则测验仅用于确认是否满足前提条件。

你们需要用于培训的代码沙箱吗？

你需要一个地方来进行练习，通常是你自己的环境。在使用任何工具之前，请务必确认它能满足你的需求。

从哪儿开始

选择代码库中一种常见的变更类型。编写性能说明，请工程经理验证预设缺陷及其对应的测试用例，并拟定一个包含三个标准的评分细则（0 到 2 分制）以及一份关键错误列表。在正式推广之前，先在一小群人中进行试点。

要了解如何让审计练习在您自己的团队中实时进行，并在之后以自定进度重复使用，请探索 AhaSlides。