Google 엔지니어가 소프트웨어 개발을 개선하기 위해 AI를 사용하는 방법을 설명합니다.

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 和 윈드서핑 等工具，它们的效果不像上面那么“炫技”，但更加实用，比如：

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

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

“AI 速度”的隐性成本

高级工程师使用 커서 어쩌면 부조종사 等 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 完全取代。

모범 사례

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

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

AI 的真正前景？

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

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

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

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

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

Agent 兴起

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

예를 들어 인류학 (명목식 형태로 사용됨) Claude 能够直接使用计算机，或者 Cline 可以自动启动浏览器并运行测试。

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

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

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