Les ingénieurs de Google expliquent comment utiliser l'IA pour améliorer le développement de logiciels

2024 年，AI 写代码已经渗透到各行各业，深刻影响着软件的整个生命周期。那么问题来了，AI 代码工具用过的人都说好，但我们平时用的软件为什么感觉没什么进步呢？ 这难道是因为我们使用 AI 的方式不对吗？

近日，Addy Osmani，Google 的工程主管，同时也是一位亚马逊畅销书作家，为我们揭示了 AI 辅助编写代码在一线开发中的真实情况，他分享了 AI 工具在实际开发中带来的挑战与机遇。

工程师如何使用 AI？

一般来说，团队利用 AI 进行开发有两种不同的模式：「引导程序（bootstrappers）」和「迭代器（iterators）」。 两种模式都在帮助工程师（甚至是技术背景较弱的用户）缩短从想法到实际代码的距离。

Bootstrappers

这一类包括 Bolt、v0 和 screenshot-to-code 等 AI 工具，其特点为：

• 从设计图或粗略的概念开始；
• 使用 AI 生成完整的初始代码库；
• 能够在几小时或几天内获得可工作的原型；
• 专注于快速验证想法的可行性

这样的工作流程令人印象深刻。例如，一位独立开发者可以使用 Bolt，在短时间内将 Figma 设计稿转化为有效的 Web 应用程序。尽管还达不到生产级别的要求，但用来获得初步的用户反馈已经足够了。

Iterators

这一类主要负责日常开发工作流程，包括 Cursor、Cline、Copilot 和 WindSurf 等工具，它们的效果不像上面那么“炫技”，但更加实用，比如：

• 自动完成代码、提供代码建议；
• 执行复杂的代码重构任务；
• 生成测试代码和文档；
• 作为解决编程问题的“结对编程伙伴”

虽然这两种方法都可以大大加快开发速度，但正如俗话所说，“天下没有免费的午餐”。

“AI 速度”的隐性成本

高级工程师使用 Curseur peut-être Copilote 等 AI 工具，可以在几分钟内搭建出整个功能的基本框架，并完成相应的测试和文档，这简直就像变魔术一样。

但仔细观察就会发现，在参考 AI 建议的同时，资深工程师们还会进行以下工作：

• 将 AI 生成的代码重构为更小的模块；
• 添加对各种极端情况的处理；
• 优化类型定义和接口设计；
• 添加全面的错误处理机制；
• 甚至是质疑 AI 给出的架构方案

换句话说，他们正在运用多年积累的工程智慧，来塑造和限制 AI 的输出。AI 负责加速代码的实现，但人类的专业知识确保代码的可维护性，两者缺一不可。

然而，初级工程师往往会忽略这些关键步骤。他们更容易全盘接受 AI 的输出，从而导致所谓的“纸牌屋代码（house of cards code）”——表面上看起来很完整，但在真实世界的压力下很容易崩溃。

知识悖论

所以，实际上，相比于初学者，AI 反而更能帮助有经验的开发人员 —— 这多少有点反直觉。

高级工程师利用 AI 快速构建想法的原型（理解需求）、生成基本实现（方便后续改进）、探索已知问题的替代解决方案等等；

而初学者却经常直接采用 AI 给出的不正确或过时的解决方案，忽略关键的安全性和性能问题，不知道如何调试 AI 生成的代码，最终构建出一个自己不完全理解的脆弱系统。

70% 问题

使用 AI 写代码的非工程师，经常会遇到一个令人沮丧的困境：他们可以出乎意料地快速完成 70% 的工作，但最后 30% 的工作却异常痛苦。

“70% 问题”揭示了 AI 辅助开发的现状，开始时仿佛有神助，但随后却被现实狠狠地“摩擦”。

实际情况通常是：

• 尝试修复一个小的 bug ——>
• AI 提出了一个看似合理的更改 ——>
• 这个更改破坏了代码的其他部分 ——>
• 要求 AI 修复新出现的问题 ——>
• 又产生了两个新的 bug ——>
• 无限循环

这个循环对于非工程师来说尤其痛苦，因为他们缺乏专业的知识来理解真正出了什么问题。

有经验的开发人员在遇到 bug 时，可以根据多年的经验和模式识别来推断潜在的原因和解决方案。如果没有这些背景知识，那就基本上是在用自己不完全理解的代码“打地鼠”，问题层出不穷。

学习悖论

还有一个更深层次的问题：让非工程师使用 AI 写代码工具，实际上可能会阻碍他们的学习。

代码是生成了，也能运行，但“开发者”却不了解背后的基本原理。此时，他们错过了学习基本编程模式、培养调试技能、对架构决策进行推理的机会，而这些代码将来还需要维护和扩展。

于是，“开发者”不断求助于 AI 来解决问题，而没有培养自己独立处理问题的专业能力。

非工程师使用 AI 写代码工具的最好方式可能是“混合模式”：

1. 使用 AI 进行快速原型设计
2. 花一些时间来理解生成的代码是如何工作的
3. 学习基本的编程概念以及 AI 的使用方法
4. 逐步建立自己的知识基础
5. 将 AI 用作学习工具，而不仅仅是代码生成器

但这需要耐心和投入，与许多人使用 AI 工具的初衷恰恰相反，他们只想快速解决问题。

“70% 问题”表明，目前的 AI 还不是许多人期望的那个“完美 AI”。最后 30% 的工作（使软件能够用于生产环境、可维护等），仍然需要真正的工程知识，无法被 AI 完全取代。

meilleures pratiques

Addy Osmani 在观察了数十个团队后，总结出了一些最佳实践方式：

• “AI 初稿”模式
  让 AI 生成代码的基本实现；手动审查并进行模块化重构；添加全面的错误处理；编写全面的测试用例；记录关键的决策。
• “持续对话”模式
  为每个不同的任务开始新的 AI 对话；保持上下文的集中和简洁；经常查看和提交更改；保持紧密的反馈循环。
• “信任但验证”模式
  使用 AI 生成初始代码；手动审查所有关键路径；对各种边界情况进行自动化测试；定期进行安全审计。

AI 的真正前景？

尽管存在这些挑战，但作者对 AI 在软件开发中的作用持乐观态度。关键是要充分利用 AI 的真正优势：

• 加速已知
  AI 擅长帮助我们实现已经了解的模式，就像一个无限耐心且打字速度飞快的结对编程伙伴。
• 探索可能性
  AI 非常适合快速构建想法原型并探索不同的方法，就像一个沙箱，我们可以在其中快速测试各种概念。
• 自动化例程
  AI 大大减少了我们花在样板代码和日常编程任务上的时间，使我们可以专注于更有趣的问题。

如果您刚开始尝试 AI 辅助开发，作者的建议是，先从小处着手：将 AI 用于那些非耦合的、定义明确的任务，仔细查看生成的每一行代码，然后逐渐构建更大的功能。

在开发过程中保持模块化：将所有内容分解为小的、重点明确的文件，在组件之间保持清晰的接口，记录模块的边界。

重要的一点是，相信自己的经验：AI 用来加速开发，但不能取代你的判断；当感觉不对劲时要勇于质疑；时刻维护自己的工程标准。

Agent 兴起

随着我们进入 2025 年，AI 辅助开发的格局正在发生巨大的变化。虽然目前的工具已经改变了我们进行原型设计和迭代的方式，但我们正处于一个更重要转型的开端：AI 代理（Agent）软件工程的兴起。AI 代理不仅可以响应指令，还将在越来越高的自主性下规划和执行解决方案。

比如 Anthropique (utilisé comme expression nominale) Claude 能够直接使用计算机，或者 Cline 可以自动启动浏览器并运行测试。

在调试过程中，AI 代理系统不仅给出修复 bug 的建议，还可以：主动识别潜在的问题、启动和运行测试套件、检查 UI 元素并捕获屏幕截图、提出并实施修复方案、并验证解决方案是否有效。

下一代工具将可以无缝整合视觉理解（UI 屏幕截图、模型、图表）、口头语言对话和环境交互（浏览器、终端、API）。

未来的 AI 不是要取代开发人员，而是要成为一个越来越强大的协作伙伴，既可以主动承担任务，又能尊重人类的指导和专业知识。