将人工智能生成的代码视为草稿

保持人类的关注、判断和所有权在 AI 编写的代码中心

永远不要外包阅读 - 始终审查 AI 的第一稿

AI 可以编写代码的第一版，但 人类必须进行阅读和审查 以确保意图和质量。

如果您停止审查 AI 生成的草稿，您将停止了解代码为什么有效（或是否真正有效）- 没有可靠的行为回溯到意图的追踪。换句话说，LLM 不会发布糟糕的代码，团队会。当没有人对 AI 编写的代码负责时，糟糕的代码会溜通过，因为工作流程没有要求更高的标准 [1]。

将 AI 的输出视为 不可信的输入 - 它可能在语法上是正确的，甚至可以通过测试，但在人类验证之前，它还没有获得您的信任。AI 模型经常产生 看似合理但微妙有缺陷的代码，包括幻觉函数或不安全的模式 [2]。因此，永远不要合并未经人类阅读和理解的代码。正如一位工程师所说，盲目地信任 AI 输出而不进行验证会带来立即的 bug 和 “系统地降低我们捕捉这些错误的能力”，因为验证代码所需的技能会因不使用而退化 [3]。

简而言之，始终坚持人类在循环中的存在：AI 可以草拟，但只有人类才能确保代码的行为与预期目的相符。

盲目依赖 AI 会侵蚀批判性思维和技能

工程领导者担心开发人员如果盲目接受 AI 生成的代码，将会失去批判性思维能力。

这种担忧并非虚构 - 早期研究证实了这一点。研究发现，AI 辅助工具的重度使用与 脑部参与度降低和批判性思维表现降低 相关 [4]。在实践中，依赖 AI 的开发人员可能会跳过诸如阅读文档或自己调试错误等基本任务。一位资深工程师坦白说，使用 AI 的即时答案使他“在自己的手艺上变得更糟”。

他停止阅读文档（“为什么要费心，当 LLM 可以瞬间解释它？”），甚至停止分析错误 - 相反，他会将堆栈跟踪复制到 AI 中，然后将 AI 的答案复制回代码中。“我已经成为一个人类剪贴板，”他哀叹 [5]。这种认知外包意味着开发人员不再通过问题进行推理；AI 在进行思考，而人类只是抄录。结果不仅是技能下降，还有警惕性下降 - 如果开发人员假设 AI 总是正确，他们可能会错过微妙的 bug 或安全问题，他们以前会捕捉到。事实上，AI 输出的便捷性和精致性可能会让工程师在审查期间产生一种虚假的安全感，降低他们的怀疑态度 [6]。

讽刺的是，AI 本应提高生产力，但过度依赖会使个人 变得不那么有能力。“我们并没有成为 10 倍的开发人员，而是变得对 AI 依赖 10 倍”，正如一位作者所观察到的 - 用短期的速度换取了长期的理解 [7]。结论：为了保持您的工程敏锐度，您必须保持与代码的知识参与。将 AI 用作工具，而不是拐杖 - 始终挑战和验证其解决方案，而不是盲目接受。

跳过学习过程而选择速度会损害成长

许多团队已经跳过了使用 AI 的学习和理解过程，而是直接使用 AI 进行开发。

AI 编码工具的承诺是高速度 - 生成、生成、生成 - 但这往往以开发人员真正理解他们正在构建的内容为代价。当您依赖 AI 编写您不完全理解的代码时，您正在 跳过使您成为更好的工程师的基本学习过程 [8]。

传统上伴随编码的错误、试错和研究不仅仅是障碍 - 它们是开发人员在其中发展关键技能的训练场。通过将繁重的工作外包给 AI，尤其是初级开发人员可能永远不会获得评估或改进所产生代码的知识深度。

这会产生一个恶性循环：您会因为使用 AI 而产生糟糕的代码，而您永远不会获得经验，因为您继续使用 AI [8]。正如一位评论者直言不讳地问道，如果您的角色仅仅是提示 AI 生成您不理解的代码，您又添加了什么价值？ [9]。

我们基本上跳过了 AI 可以用作学习辅助工具或导师的阶段，而直接跳到了使用它作为自动编码器来生成输出。理想情况下，开发人员会使用 AI 来 提高理解 - 例如，要求 AI 解释一段棘手的代码，或者建议为什么某个解决方案有效 - 甚至在将代码交给他人之前进行本地“自我审查”与 AI。但在实践中，许多人只是点击“接受”建议然后继续。这样，他们可能会更快地交付功能，但对其工作原理或为什么使用某些模式只有肤浅的了解。

随着时间的推移，这种缺乏理解会积累成严重的技能差距。高级工程师担心新手能够使用 AI 辅助工具快速生成代码，但难以调试或扩展代码，因为他们从未学习了底层概念。事实上，工程领导者报告说，虽然初级开发人员现在比以往任何时候都更快地发布功能，但当出现问题时“他们难以调试自己不理解的代码” [10]。

软件工程的精髓不仅仅是产生运行的代码 - 它是关于知道为什么代码是以这种方式编写的，以及如何演化它。如果我们绕过这段旅程，我们就有可能创造出一代程序员，他们只能在 AI 的自动驾驶模式下操作。为了对抗这一点，将 AI 输出视为学习的机会：不要只是复制粘贴答案，阅读它们，质疑它们，并确保您可以向同事解释。使用 AI 来加速您的工作，而不是绕过您作为工程师的成长 [11][12]。

我听说过高级开发人员将 PR 发回给初级开发人员，很明显 AI 被使用了，但初级开发人员并没有理解自己在做什么。当初级开发人员提交一个 AI 生成的 PR 时，审查成为主要的指导场所。提出苏格拉底式的问题，迫使他们解释 AI 的输出。这确保了理解，而不仅仅是功能。审查变成了关于理解，而不仅仅是正确性。

代码审查在 AI 生成的代码下苦苦挣扎

传统的代码审查实践在应对 AI 生成的代码时苦苦挣扎，令团队们不知道如何维持质量。

代码审查一直是捕捉错误和确保代码质量的安全网。但 AI 辅助工具改变了游戏规则：AI 可以在瞬间生成 更大的 diff，通常涉及多行或多个文件，这意味着审查者面临着更多的体积和潜在的复杂性。事实上，研究发现，Copilot 生成的代码的 pull 请求平均需要 26% 更长的时间来审查，因为审查者必须解开不熟悉的模式，并为 AI 特有的错误进行双重检查 [13]。

代码审查一直是捕获错误和确保代码质量的安全网。但是，人工智能辅助改变了游戏规则：人工智能可以在瞬间产生更大的差异，通常涉及多行或多个文件，这意味着审查者面临更多的内容和潜在的复杂性。在每个拉取请求中，实际上，研究发现，拉取请求中充满了 Copilot 生成的代码，平均需要 26% 更长的时间来审查，因为审查者必须解开陌生的模式并双重检查人工智能特定的错误 [13]。

审查者还报告了一种心理效应：当检查他们没有编写的代码时，特别是如果它在语法上很完善，他们的信心会下降 - 他们需要更长时间来验证逻辑，并可能质疑他们的理解 [14]。人工智能可以生成看起来干净和现代的代码（一致的命名，适当的格式），这可以降低审查者的怀疑 [6]。很容易假设代码是可靠的，如果它“看起来专业”，这使得微妙的错误或设计缺陷更容易被忽略。

另一个复杂问题是 意图丢失。在传统的审查中，审查者可以讨论“作者想要做什么” - 有一个人类的意图来与实现进行比较。使用人工智能生成的代码，代码的作者可能不完全理解每一行代码背后的意图，因为他们没有以传统的方式编写它。给人工智能的原始提示本质上是规格，但审查者通常看不到该提示 [15]。这意味着审查者不得不猜测需求和人工智能的解决方案是否实际满足它们，而不是仅仅审查代码是否有效。

正如一份报告指出的，审查者不再评估开发人员想要做什么，而是评估模型实际做了什么 [16]。传统的代码审查清单（专注于样式，明显的逻辑错误等）是不够的，因为人工智能代码可以以非传统的方式失败 - 例如，使用过时的算法，初级开发人员不知道，或者引入边缘情况错误，这不是立即明显的。

团队还遇到了 审查过载。人工智能配对编程器可以比人类更快地生成代码，这意味着单个开发人员可以在短时间内打开非常大的拉取请求或多个拉取请求。这种“速度”可以让团队的审查容量不堪重负。它类似于代码中的杂乱 - 用大量输出淹没审查者，使得很难找出问题 [17]。在这种情况下，一些组织已经制定了新的政策：例如，如果拉取请求中有超过 30% 的代码是人工智能生成的（按行或内容），它可能会触发额外的审查或更高级的审查者 [18]。

这个想法是承认人工智能密集型代码需要 不同的 审查级别，而不是一贯的做法。另一个新兴的做法是标记人工智能贡献：在拉取请求或提交消息中明确标记“此代码由人工智能辅助”。这可以提示审查者更加警惕。确实，专家建议 标记和跟踪人工智能生成的代码 以实现问责 - 它有助于审查者知道要寻找什么，并帮助团队稍后跟踪错误（“这是人工智能编写的代码中的错误吗？”） [19]。

然而，公开标记人工智能参与带来了文化挑战：开发人员必须感到 心理安全 来披露人工智能的使用。如果人们害怕被评判使用人工智能（“我的团队会认为我懒惰或能力较差吗？”），他们可能会隐藏它 - 这对团队来说更糟糕。隐藏人工智能的使用意味着团队不知道潜在风险在哪里，无法相应地调整他们的审查 [20]。为了应对这一点，具有前瞻性思维的团队鼓励透明度而不带有耻辱感。

使用人工智能应该像使用任何工具一样 - 使用它是可以的，但你必须拥有输出。正如一份指南所述，永远不要责怪人工智能的错误 或质量问题；提交代码的工程师拥有它，毫无疑问 [21]。如果每个人都接受这种思维方式，那么说“我使用 Cursor 帮助这个模块”只是一个事实陈述，而不是罪恶的承认。这使团队能够共同确保人工智能生成的部分得到适当的关注。

目前，我们的代码审查工具和规范仍在适应这些需求。我们还没有广泛的自动检测人工智能代码的 PR 检测器，大多数差异查看器也没有显示人工智能的提示或推理。因此，我们需要依靠流程和团队协议来填补这一空白 - 明确指出人工智能编写的代码，更加严格地审查测试，并可能设置大小限制，以便在没有人工审查的情况下接受人工智能生成的代码。

如果可疑代码未经挑战地通过 PR，那么问题不仅仅是人工智能 - 它是审查过程不够强大，无法捕获这些问题 [22]。这是一个号召，代码审查实践必须随着人工智能的采用而演进。

66% 的开发人员在 Stack Overflow 调查中表示，他们对人工智能辅助工具最常见的挫败感是代码“几乎正确，但不完全正确”。45% 的开发人员在 Stack Overflow 调查中报告，他们花在调试人工智能生成代码上的时间是他们最大的时间消耗。质量门槛和验证现在是关键路径。

最佳实践：将人工智能生成的代码视为草稿

为了有效地使用人工智能编码工具，我们必须调整我们的习惯和流程。将人工智能输出视为初级开发人员的第一稿 - 有价值的，但需要仔细审查和改进。以下是一些务实的最佳实践，以确保人工智能生成的代码提高生产力而不牺牲质量或理解：

最佳实践：将 AI 生成的代码视为草稿

为了有效地使用 AI 编码工具，我们必须调整我们的习惯和流程。将 AI 输出视为 初级开发人员的初稿 – 有价值，但需要仔细审查和改进。以下是一些务实的最佳实践，以确保 AI 生成的代码提高生产力而不牺牲质量或理解：

永远不要合并你不理解的代码。如果 AI 帮助生成了一些代码，责任在于你（开发人员）阅读每一行代码并确保你理解它。你应该能够解释代码的作用和原因。如果有任何 AI 生成的代码片段你无法理解，视为红旗 – 要么改进提示，要么让 AI 解释它，要么自己重写那部分代码。一些开源项目明确要求贡献者证明他们理解提交的代码，即使是 AI 写的。在专业环境中，同样的原则适用：对提交的任何代码承担全部责任，无论谁（或什么）编写了它 [21]。在实践中，这意味着运行代码，编写或审查测试代码，并在代码进入团队仓库之前逐步执行其逻辑。
将 AI 代码视为实习生的代码 – 不要相信，核实。AI 不具备上下文或智慧；它更像一个非常快、热情的初级开发人员。它会自信地生成解决方案，但该解决方案可能过于简单，缺乏边缘情况，或者使用不适合代码库的模式。作为最佳实践，带着健康的怀疑态度对待 AI 贡献。检查边界条件，寻找 off-by-one 错误、线程安全问题或其他角落情况，这些情况可能会被经验较少的程序员忽略 [23][24]。通常，AI 会做你要求它做的事情，而不是你真正需要的东西。因此，交叉验证输出与要求。如果这是一个复杂或关键的代码段，考虑在查看 AI 草稿后手动重新实现它 – 你可能会发现 AI 忽略的细微差别。记住 AI 输出的座右铭：“不要相信。核实。” [25]
将 AI 用作编码助手，而不是作者 – 将其纳入自己的思考中。不要只是要求 AI 输出代码并盲目粘贴，而是以对话、解释的方式使用它。例如，你可以要求 AI 解释它刚刚建议的代码，或者为其生成注释。你可以让它为代码建议测试用例，然后运行它们以查看代码是否真正有效。AI 还可以通过总结大型 diff 或在 PR 中识别潜在问题区域来提供帮助（一些高级代码审查工具现在提供 AI 生成的摘要）。所有这些用途都让你（人类）掌握主动权。你正在利用 AI 来增强自己的理解，而不是取代它。推荐的做法是先审查 AI 生成的更改的测试 [26] – 确保有一个坚实的测试套件来覆盖新代码。如果测试不够或缺失，那是你编写更多测试的提示，然后再信任代码。此外，对 AI 代码使用严格的 linting 和静态分析：AI 可能不会遵循团队的惯用法，所以使用自动化工具执行样式和架构规则 [27][28]。如果 AI 建议的内容不符合通常的模式，不要犹豫地重构它。基本上，让 AI 成为你的配对程序员，编写草稿代码并提供想法，但你仍然负责所有最终的编辑和决定。
彻底测试和保护 AI 生成的代码。将与手写代码相同（或更高）级别的测试应用于 AI 编写的代码。编写单元测试和集成测试以覆盖功能。特别是寻找边缘情况和潜在的故障模式 – AI 以处理“快乐路径”而忽略不寻常的输入或错误处理而闻名。还要考虑安全性：像 SQL 注入、XSS、不安全的反序列化等常见漏洞可能会在 AI 从有缺陷的代码示例中学习时出现 [29][30]。使用安全 linter 或扫描器（如 Semgrep 或 Bandit 可以捕获明显的问题 [31])。如果 AI 生成了任何依赖项或配置，请确保您审查它们以查找机密信息或不安全的默认值。将 AI 的代码视为您雇佣的承包商的工作，您不完全信任 – 双重检查一切，因为最终您的团队将对任何错误或安全漏洞负责，无论谁编写了代码。
在寻求同行审查之前，利用 AI 进行自我审查。一个有用的模式是要求 AI 在您打开拉取请求之前批评其自己的输出。例如，在获得代码建议后，您可能会提示“您在此代码中看到哪些潜在问题？是否有边缘情况或改进？”AI 可能会指出您没有考虑到的条件或更惯用的方法。这就像逻辑的拼写检查 – 并非万无一失，但它可以捕获低垂的果实。这不能取代人类审查，但它可以帮助您清理草稿，以便您的同事不会被明显的问题分散注意力。将其视为您与 AI 合作以完善代码，然后将其交给您的团队。这样做还可以帮助您学习，因为 AI 的审查评论可以突出您需要思考的领域。只要记住要验证任何 AI 反馈；有时它可能会“编造”实际上不存在的问题，因此请使用您的判断力。
如果 AI 生成的更改太大或太混乱，请将其分解。不要让 AI 的速度迫使您合并巨大的、单一的更改。如果 Cursor 输出 500 行混合修改的代码，可能最好将其视为原型。也许运行代码以查看方法是否有效，然后以较小、可理解的部分重新实现解决方案。一个开发人员将初始 AI 生成的草稿比作 spike 解决方案 – 一个快速而简单的实现来证明概念 [32]。您不会将 spike 合并到生产环境中；您会改进它。同样，取 AI 草稿并迭代改进它：也许将大型 PR 分成多个提交或拉取请求，以便于审查。通常，第二个草稿（在获得第一个草稿的见解后编写）会更干净、更易于维护 [32]。这种有纪律的方法可以防止“gish gallop”效应，即 AI 转储太多代码，审查者无法有效地审查它。通过将其分解，您可以确保每个部分都得到充分的人类关注。
在与团队分享时，记录和标记 AI 贡献。在拉取请求描述或代码注释中，指出哪些部分是由 AI 生成的，或者如果您在解决方案中大量依赖于 AI，可能会有所帮助。例如：“使用 Gemini/Opus/GPT 生成此排序算法的初始实现；审查并修改结果。”这种透明度可以帮助审查者了解需要关注哪里。这不是为了责怪 AI 或您，而是为了背景。事实上，鼓励使用清晰的注释或注解来标记 AI 生成的代码，以创建责任感和可追溯性 [33]。如果以后出现奇怪的 bug，团队可以追溯到它并看到“哦，这个块是基于提示 X 生成的 AI 代码”，这可能会使调试更容易。当然，要在支持性的文化中这样做（见下一节） – 目标是共同保护质量，而不是指责某人。一些团队甚至保留 AI 辅助更改的日志以供审计 [33]。至少考虑与审查者分享您使用的提示，例如在 PR 注释中。这样，审查者就可以理解您要求什么，并判断 AI 的代码是否真正符合意图 [15]。这种提示作为规范的技术可以弥合意图和实现之间的差距。
永远不要合并你不理解的代码。如果人工智能（AI）帮助生成了一些代码，责任在于你（开发者）来阅读每一行代码并确保你理解它。你应该能够解释代码的功能和原因。如果有任何人工智能生成的代码片段你不能理解，应将其视为红旗——要么改进提示，要么让人工智能解释它，要么自己重写那部分代码。一些开源项目明确要求贡献者确认他们理解提交的代码，即使是人工智能编写的。在专业环境中，同样的原则适用：无论谁（或什么）编写了代码，你都应对提交的代码承担全部责任 [21]。在实践中，这意味着运行代码，编写或审查测试代码，并在代码进入团队仓库之前逐步检查其逻辑。
将人工智能代码视为实习生的代码——不要信任，必须验证。人工智能不具备上下文或智慧；它更像一个非常快、渴望学习的初级开发者。它会自信地生成解决方案，但该解决方案可能过于简单，缺乏边缘情况，或者使用不适合你的代码库的模式。作为最佳实践，应以健康的怀疑态度对待人工智能的贡献。检查边界条件，寻找偏一错误、线程安全问题或其他初级程序员可能忽略的角落情况 [23][24]。人工智能经常会做你要求它做的事情，而不是你真正需要的东西。因此，应将输出与要求进行交叉验证。如果这是一个复杂或关键的代码片段，考虑在查看人工智能的草稿后手动重新实现它——你可能会发现人工智能忽略的细微差别。记住人工智能输出的格言：“不要信任。要验证。” [25]
将人工智能用作编码助手，而不是作者——将其融入你的思考中。不要只是要求人工智能生成代码并盲目粘贴，而是以对话、解释的方式使用它。例如，你可以要求人工智能解释它刚刚建议的代码，或者为其生成注释。你可以让它为代码建议测试用例，然后运行这些测试用例以查看代码是否真正有效。人工智能还可以通过总结大型差异或识别拉取请求（PR）中的潜在问题区域来提供帮助（一些高级代码审查工具现在提供人工智能生成的摘要）。所有这些用途都让你（人类）掌控一切。你正在利用人工智能来增强你的理解，而不是取代它。一个推荐的做法是先审查人工智能生成的更改的测试 [26] —— 确保有一个可靠的测试套件来覆盖新代码。如果测试不够或缺失，这是你编写更多测试代码的提示，然后再信任代码。此外，应对人工智能代码使用严格的linting和静态分析：人工智能可能不会遵循你的团队惯用法，因此应使用自动化工具强制执行样式和架构规则 [27][28]。如果人工智能建议的内容不符合你的常用模式，不要犹豫地重构它。基本上，让人工智能成为你的配对程序员，它编写草稿代码并提供想法，但你仍然负责所有最终的编辑和决定。
彻底测试和保护人工智能生成的代码。将同等（或更高）级别的测试应用于人工智能编写的代码，就像你对手工编写的代码所做的那样。编写单元测试和集成测试以覆盖功能。特别是要寻找边缘情况和潜在的故障模式——人工智能以处理“快乐路径”而忽略不寻常的输入或错误处理而闻名。还要考虑安全性：像SQL注入、XSS、不安全的反序列化等常见漏洞可能会在人工智能从有缺陷的代码示例中学习时出现 [29][30]。使用安全linter或扫描器（如Semgrep或Bandit可以捕获明显的问题 [31])。如果人工智能生成了任何依赖项或配置，请确保你审查它们是否包含机密信息或不安全的默认设置。将人工智能的代码视为你雇佣的承包商的工作，你不完全信任它——双重检查一切，因为最终你的团队将对任何错误或安全漏洞负责，无论谁编写了代码。
在寻求同行审查之前，利用人工智能进行自我审查。一个有用的模式是要求人工智能在你打开拉取请求之前批评其自己的输出。例如，在获得代码建议后，你可能会提示：“你在这段代码中看到哪些潜在问题？有任何边缘情况或改进措施吗？”人工智能可能会指出你没有考虑到的条件或更惯用的方法。这就像一个逻辑的拼写检查器——并非万无一失，但它可以捕捉到低垂的果实。这种方法不能取代人类审查，但它可以帮助你清理草稿，以免你的同事被明显的问题分散注意力。可以把这看作你与人工智能合作来完善代码，然后将其交给你的团队。这种方法还可以帮助你学习，因为人工智能的审查评论可以突出你需要思考的领域。只要记住要验证任何人工智能反馈；有时它可能会“编造”并不存在的问题，因此要使用你的判断力。
如果人工智能生成的更改太大或太混乱，请将其分解。不要让人工智能的速度迫使你合并巨大、单一的更改。如果人工智能生成了500行混合修改的代码，可能最好将其视为原型。也许可以运行代码来查看这种方法是否有效，然后以较小、可理解的部分重新实现解决方案。一个开发者将初始人工智能生成的草稿比作尖峰解决方案——一个快速而粗糙的实现来证明一个概念 [32]。你不会将尖峰解决方案合并到生产环境中；你会改进它。同样，对于人工智能草稿，你可以迭代地改进它：也许可以将大型PR分解为更容易审查的多个提交或拉取请求。通常，第二个草稿（在获得第一个草稿的见解后编写）会更干净、更易于维护 [32]。这种有纪律的方法可以防止“鱼类奔腾”效应，即人工智能生成如此多的代码，以至于审查者无法有效地审查它。通过将其分解，你可以确保每个部分都得到充分的人类关注。
在与团队分享时，记录和标记人工智能贡献。在拉取请求描述或代码注释中，注明哪些部分是由人工智能生成的，或者你是否严重依赖人工智能来解决问题。例如：“使用Gemini/Opus/GPT生成了此排序算法的初始实现；审查并修改了结果。”这种透明度有助于审查者了解他们应该关注哪里。这不是为了责怪人工智能或你自己，而是为了提供背景。事实上，鼓励使用清晰的注释或注解来标记人工智能生成的代码，以创建责任感和可追溯性 [33]。如果以后出现奇怪的错误，团队可以追溯到错误的根源，并看到“哦，这块代码是基于提示X由人工智能生成的”，这可能会使调试更容易。当然，这应该在支持性的文化中进行（见下一节）——目标是共同保障质量，而不是指责某人。一些团队甚至会记录人工智能辅助更改以进行审计 [33]。至少，应考虑与审查者分享你使用的提示，例如在PR评论中。这使审查者了解你要求什么，并可以判断人工智能的代码是否真正符合意图 [15]。这种提示作为规范的技术可以弥合意图和实现之间的差距。

总而言之，将人工智能代码视为草稿意味着应用与你对待人类新手代码相同的严谨性：你深入审查它，彻底测试它，并且在没有证据之前不假设任何事情都是正确的。人工智能可以大大加快编写样板代码的速度，甚至可以建议解决方案，但你是工程师——你必须负责地将这些建议整合到代码库中。

总而言之，将人工智能（AI）代码视为草稿意味着对其进行与对待人类新手代码相同的严格审查:您需要深入审查、彻底测试，并且在没有证明其正确性之前，不应假设任何内容都是正确的。人工智能可以大大加快编写样板代码的速度，甚至可以提出解决方案，但您是工程师 - 您必须负责地将这些建议整合到代码库中。

建立团队协议以处理人工智能生成的代码

为了成功地将人工智能集成到开发中，团队应该制定明确的指南 - 本质上是一份“合同” - 以规定如何处理人工智能生成的代码。这是一个新的领域，不一致可能会导致摩擦或质量问题。团队协议可能包括规则、职责和围绕人工智能使用的文化规范。以下是一些团队正在采用的关键元素：

确保责任不被忽视。明确规定，谁将人工智能生成的代码整合到代码库中，就由谁负责，毫无例外。不准指责人工智能。如果引入了错误，就像对待其他任何错误一样处理。该原则得到了行业指南的支持，规定开发人员必须对他们提交的任何代码承担全部责任，无论谁编写了它，并且要像测试自己的代码一样彻底地测试人工智能生成的代码 [21]。管理层应该强调，使用人工智能不能成为降低质量的借口。代码审查员和批准者也共担责任 - 如果您批准了更改，则意味着您对其进行了担保。基本上，人工智能不会改变“代码所有者”的定义。
定义人工智能的使用方式和时机。作为一个团队，讨论哪些任务适合人工智能辅助。例如，您可能会同意人工智能非常适合生成单元测试、样板代码、脚手架或探索多种方法 - 但您可能会避免在没有额外审查的情况下使用它来编写核心复杂算法。一些团队可能禁止在没有高级工程师密切监督的情况下使用人工智能来编写安全敏感代码或关键算法。其他团队可能会说，只要遵循其他规则（了解它、测试它等），就可以使用人工智能来完成任何事情。关键是要设定期望。这也与道德和法律考虑有关（例如，确保人工智能输出不包含复制的许可代码，或者不引入偏见），但那是另一篇文章的内容。关键是，协议可以防止误解，例如一个开发人员合并了大量人工智能编写的代码，而其他人并不舒服。
强调透明度和心理安全。团队协议应该鼓励开发人员公开人工智能的参与。例如，指南可能是：“如果人工智能在更改中起到了重要作用，请在PR中提及它。”领导者必须营造一种环境，让这种承认被视为积极的（作为尽职调查），而不是消极的。缺乏透明度可能会导致代码库中的“影子人工智能” - 即没有人意识到是人工智能编写的代码，这使得调试和维护更加困难 [20]。为了避免这种情况，应使透明度成为常态。一个实践是添加一个简单的注释，例如 // 代码由人工智能辅助生成，或在PR中使用标签。团队还可能同意在项目维基或代码审查中记录提示，以便日后参考 [33]。如果有人觉得自己不完全理解人工智能生成的部分，他们应该感到安全地提出问题并请求帮助或额外审查 [33]。坦率地说“我不100%确定Copilot在这里产生的内容”比假装一切都没问题要好。心理安全确保人们发言，这最终保护了代码质量和开发人员的成长。
将人工智能意识融入审查过程。团队应该更新代码审查清单或完成定义，以考虑人工智能。例如，审查清单可能会添加类似“如果代码由人工智能生成，作者是否提供了提示或描述了意图？”或“对于人工智能生成的代码，双重检查常见问题（边缘情况、安全性、样式一致性）”的项目。一些组织通过要求额外的审查来正式化这一点，如前所述 [34]。培训课程也可以帮助 - 一个团队可能会举办一个关于“典型人工智能错误”的研讨会，以便所有审查员知道要注意什么（例如，不必要的复杂性、缺少空检查等）。团队还可以采用工具来协助，例如人工智能驱动的代码分析，用于标记可能存在问题的代码模式。最终，整个审查文化可能会转变为以更严格的态度对待人工智能贡献。作为一个共同的规则，您可能会说：没有经过彻底的人类审查，就不允许合并人工智能生成的代码，没有例外。这似乎很明显，但明确这一点可以设定基调，即速度不会以牺牲质量为代价。
支持持续学习和技能发展。为了解决批判性思维萎缩的问题，团队协议可以明确鼓励保持技能敏锐的做法。例如，配对编程会话，其中一个人不使用人工智能并解释他们的思维过程，或者在没有人工智能的情况下轮流解决具有挑战性的错误。或者，简单地鼓励开发人员偶尔以“硬”方式实现事情，然后使用人工智能进行优化。一些公司甚至跟踪人工智能如何影响调试时间，并确保员工仍然知道如何在没有工具的情况下进行故障排除 [10]。协议可能是：“我们使用人工智能来加快常规任务的速度，但我们仍然期望工程师能够理解和手动处理复杂的部分。”通过在团队原则中承认这一点，您可以验证人类专业知识的重要性。领导者和经理尤其应该以身作则 - 在代码审查中展示他们对人工智能生成的代码进行同样严格的审查，并提出有意义的问题。初级开发人员会从中吸取教训，并了解人工智能不是一种免于思考的免费通行证。

本质上，团队的人工智能代码协议是关于维护质量、清晰度和信任。每个人都应该知道人工智能如何被使用，并就其输出必须满足的标准达成一致。这种“合同”可能是一个不断演变的活文档，因为您获得了经验。目标是防止人工智能悄悄地降低代码库或工程师技能的质量。相反，通过建立规则，人工智能可以成为一种强大的加速器带有防护栏。它迫使我们现在讨论以前被认为是隐含的主题（例如“您是否理解提交的内容？”）- 现在我们使其显式化。

结论：人工智能不是理解的替代品

人工智能编码工具已经出现，它们擅长生成草稿 - 脚手架、样板代码，甚至复杂的代码，人类可能需要更长时间才能从头开始编写。接受它们可以带来巨大的生产力提升，并让开发人员摆脱单调的工作。但是，我们开始将人工智能生成的代码视为“开火并忘记”的那一刻，我们就破坏了我们所期望的好处。

人工智能在软件工程中的真正价值在于我们将其速度与自己的判断力结合起来。**这意味着始终以批判的眼光审查人工智能的输出，保持对代码工作原理的好奇心，并坚持清晰度和正确性。**当您将人工智能生成的代码视为草稿时，您承认它是一个正在进行的工作 - 需要通过人类的洞察力来完善。

通过保持高标准的代码质量和开发人员教育，我们可以确保人工智能成为一种增强我们能力而不是萎缩我们能力的工具。即使“什么”被呈现给我们，我们也保持了“为什么”和“如何”的关注。在实际操作中：不要停止阅读代码。

无论是由实习生、人工智能还是经验丰富的同事编写的代码，只有理解了代码才能信任它。如果您从不将阅读和思考外包，您就保留了将代码的行为与其背后的意图联系起来的能力 - 这是软件工程的本质。

使用人工智能来加快速度，当然可以，但是请始终把手放在方向盘上。

生产环境中的代码应该始终有一个人类的眼睛（和心）在背后。这样，我们就能同时获得两全其美的效果：人工智能生成的第一稿的效率和人类审查的可靠性。

我很高兴地分享，我已经与O'Reilly合作发布了一本新的人工智能辅助工程书。如果您感兴趣，可以在书籍网站上找到一些免费的提示。