采用 AI 的挑战与解决方案

将生成式 AI 集成到工程工作流程中提供了许多好处，但也带来了新的挑战。在本节中，我们将讨论团队在采用 AI 时面临的常见陷阱，并为领导者提供实用的解决方案，以确保维持高质量标准。目标是帮助你避免 AI 采用的"坏的一面"——比如过度依赖 AI 或基本技能的退化——同时获得好处。

尽管 AI 编码工具具有令人印象深刻的能力，但它们有局限性，甚至可能误导缺乏经验的团队。领导者应该注意这些关键挑战：

• 过度依赖 AI 导致技能退化： 如果开发者过于依赖 AI 来解决问题，他们就有失去解决问题"肌肉"的风险。AI 可以在几秒钟内生成代码，这对生产力很好，但如果工程师在不理解的情况下接受解决方案，他们的成长就会停滞。这是许多教育工作者和工程师注意到的真正担忧：依赖 AI 生成的解决方案可能会绕过来自调试和试错的深度学习（AI 编码助手：对有抱负的开发者来说是双刃剑 | by Murat Aslan | Stackademic）。初级开发者尤其脆弱——如果他们对所有事情都使用 AI，他们可能会跳过学习基本算法或架构原则。作为领导者，通过设置学习护栏来解决这个问题。一个想法是实施偶尔的"无 AI 日"或编码道场，团队在没有 AI 帮助的情况下解决问题，只是为了保持技能敏锐。你还可以要求当使用 AI 时，开发者应该能够解释代码背后的推理。例如，如果初级开发者使用 Copilot 生成排序算法，让他们在审查中演示它是如何工作的。这确保他们将 AI 视为学习工具，而不仅仅是拐杖。一些组织甚至建立了指导计划，高级工程师与初级工程师一起审查 AI 辅助的工作，将这些审查变成关于为什么 AI 的解决方案是或不是最优的教学时刻。

• 盲目信任 AI 输出（质量和错误）： AI 不保证正确性。它可能产生看起来自信但实际上是微妙错误或不安全的代码。事实上，一项全球调查发现超过三分之一的专业人士不完全信任 AI 生成的代码（Google 调查称超过 75% 的开发者依赖 AI。但有一个问题 | ZDNET）（Google 调查称超过 75% 的开发者依赖 AI。但有一个问题 | ZDNET）——这是正确的，因为 AI 可能引入难以检测的错误。一个经典的错误是当工程师接受通过基本测试但在边缘情况下失败的 AI 生成解决方案时，AI（缺乏真正的理解）没有考虑到这些情况。安全漏洞是另一个风险：AI 可能建议使用过时的加密方法或忽略清理输入的解决方案，因为它在训练数据中看到了类似的代码**。解决方案：** 建立严格的**"信任但验证"**政策。明确期望所有 AI 生成的代码都要像人类编写的一样进行代码审查和测试——甚至可能需要额外的审查。领导者可以树立榜样：如果你正在审查拉取请求，并且怀疑其中一部分是 AI 生成的（它可能有明显的注释或只是来得很快），提出问题：为什么这是正确的方法？我们考虑过边缘情况 X 吗？ 这鼓励团队始终仔细检查 AI。一些团队采用的政策是，AI 建议的代码必须附带 AI 生成的测试（许多 AI 工具也可以生成单元测试），然后由人工审查者批准两者。通过将 AI 编写的代码与彻底的测试配对，你可以捕获许多问题。本质上，强调 AI 不是团队集体大脑的替代品——它是一个仍然需要监督的助手。

• "70% 问题"： 领导者观察到，AI 通常非常快速地让你完成解决方案的 70%，但最后 30%（困难的部分）仍然需要大量的人类努力。例如，AI 可能生成新功能代码的大部分，但边缘情况、集成细节和性能调优可能不完整或不正确。它擅长产生草稿，但不是精致的最终产品。这可能会产生虚假的进度感——你认为你"几乎完成了"，因为代码已经编写，但调试和改进 AI 生成的代码所需的时间与从头编写一样多。一个相关的问题是，AI 倾向于很好地处理常见情况（因为它在训练数据中见过它们），但在新颖或复杂的场景中失败**。解决方案：** 围绕这一现实校准期望和项目计划。作为领导者，在估算任务时，不要假设 AI 生成代码意味着它已经准备好投入生产。鼓励你的团队将 AI 用于样板和常规部分（那 70%），但计划在之后进行彻底的集成、测试和改进工作。一个实践是将 AI 用于它擅长的事情——例如，生成一堆模型类或 API 客户端代码——这释放了人类开发者花更多时间在棘手的集成逻辑或定制算法上。通过明确地以这种方式划分工作，你确保团队将他们的脑力集中在最需要的地方，并且你不会陷入"AI 做了，所以我们完成了"的陷阱。

• 初级开发者超越他们的理解： 轶事上，许多高级工程师注意到一个模式：AI 使新手开发者看起来比他们真正的生产力更高。 初级开发者可以在 AI 帮助下突然产生大量代码，但在这种输出之下，他们的理解可能是肤浅的。例如，初级开发者可以使用 AI 助手在新编程语言中快速完成整个模块——这通常需要他们数周的学习——但如果出现错误，他们可能难以调试，因为他们不完全掌握代码的工作原理。这有时被称为知识悖论：AI 帮助有知识的人走得更快（因为他们可以判断 AI 的输出），但它实际上可能阻碍没有知识的人（因为他们无法区分好的和坏的输出）。解决方案： 特别强调对经验较少的开发者的指导和代码审查。坚持解释：当初级开发者提出包含大量 AI 编写代码的 PR 时，让他们注释或向团队展示，解释每个部分。这将很快揭示他们是否不理解某些东西（这是一个教学机会）。另一个解决方案是以不同的方式将初级开发者与 AI 配对——例如，让他们使用 AI 生成建议，但与可以立即提供这些建议反馈的高级开发者结对编程（"是的，看起来不错"或"不，这不是我们在系统中处理错误的方式"）。这样，初级开发者学习上下文和原因，而不仅仅是什么。还值得让初级开发者轮换执行不适合 AI 的任务（如与客户交谈以了解需求，或编写设计文档），以确保他们发展全面的技能。

• 代码一致性和风格： AI 工具在来自不同作者的数百万代码片段上训练，可能以各种风格生成代码——其中一些可能与你团队的标准不匹配。如果没有指导，AI 可能使用与你的指南规定的不同的命名约定、代码模式或项目结构。如果代码库的一部分主要由 AI 编写，另一部分由人类编写，则可能会出现不一致。解决方案： 大多数 AI 助手可以通过注释或关于风格的配置来指导。例如，你可以在提示中提供编码风格的示例，或者一些工具允许设置风格指南。领导者应确保团队的风格指南和 linting 工具是最新的，并且在 AI 世界中可能更严格。自动化的 linter 或格式化程序可以在生成后捕获许多风格问题。此外，教育团队在提示中包含要求（例如，"使用函数式编程风格"或"遵循我们的 XYZ API 约定"）。随着 AI 集成到 IDE 中，如果给予正确的钩子，我们可能会看到它自动符合项目的风格——但在那之前，由团队来执行这一点。在代码审查中，不要忽视 AI 编写的部分——将它们保持在相同的一致性标准。随着时间的推移，随着模型从你的存储库中学习（一些工具在你的代码库上进行微调），这个问题应该会减少，但最初需要有意识的努力。

• 数据隐私和 IP 风险： 这更多是一个组织挑战，但至关重要。许多 AI 编码工具在云中运行，这意味着代码（可能是专有代码）被发送到模型提供商的服务器。这在一些公司引起了警报：例如，三星在 2023 年禁止员工使用 ChatGPT，因为一名工程师不小心将敏感源代码泄露到提示中（三星在 4 月内部数据泄露后禁止使用 ChatGPT 等生成式 AI 工具...）。此外，在开源代码上训练的 AI 模型面临法律问题（例如，有诉讼声称 Copilot 可能在没有归属的情况下复制许可代码）。作为领导者，你必须应对这些担忧**。解决方案：** 与你的法律/安全团队合作制定明确的政策。确定哪些类型的数据可以或不可以放入 AI 工具。许多公司最初不允许将 ChatGPT 等工具用于任何代码，直到出现企业选项。如果你在具有严格 IP 或合规性的领域（金融、医疗保健等），你可能会选择内部运行的自托管 AI 模型，这样就不会有任何东西离开你的环境。供应商正在响应——我们现在有"Copilot for Business"，承诺不在你的代码上训练，以及你可以在内部部署的开源模型。确保开发者理解政策：例如，"不要将客户数据或专有算法粘贴到任何外部 AI 服务中。"另一方面，为了解决知识产权风险，确保任何 AI 生成的代码都经过许可证合规性审查（有些情况下 AI 逐字复制了一段著名的代码）。使用 AI 并不能免除团队遵守开源许可证的责任。一种方法是将 AI 用作建议工具，但让开发者自己实现关键部分，或交叉检查他们没有编写的不寻常代码。随着时间的推移，我怀疑法律框架将澄清这些问题，但在 2025 年，这仍然是一个有点灰色的区域，所以领导者必须保持知情并谨慎行事，以保护公司的资产。

总结本节：在工程中采用 AI 并非没有陷阱，但所有陷阱都可以通过有意识的领导和流程调整来克服。 解决方案的共同线索是人类监督和持续学习。如果你保持一种文化，其中 AI 是一个工具，而不是自动驾驶仪，你可以避免大多数问题。鼓励你的团队将 AI 建议视为正是这样——要评估的建议，而不是盲目接受的真理。强调即使我们使用这些新工具，也要保持核心技能和理解。通过设定明确的期望（代码必须被理解、审查、测试等）并调整你的流程（更多指导、更新的代码审查指南、明确的 AI 使用政策），你可以确保 AI 加速你的团队而不降低你的标准。记住，目标是让 AI 放大你团队的能力，而不是取代他们的思考。通过正确的方法，挑战可以得到管理，你的团队可以享受生成式 AI 提供的生产力提升和创造性可能性。