新智元报道
编辑：alan
2024 年的 AI 编程到底什么实力？近日，谷歌的工程主管 Addy Osmani，为我们揭示了 AI 辅助编码在一线开发中的真实情况。
2024 年，AI 编程已然渗透了各行各业，影响着软件的整个生命周期。
那么问题来了，AI coding 用过都说好，但我们平时用的软件咋感觉没啥进步呢？
近日，Addy Osmani，谷歌的工程主管，同时也是一位亚马逊畅销书作家，为我们揭示了 AI 辅助编码在一线开发中的真实情况。
码农怎么用 AI？
一般来说，团队利用 AI 进行开发有两种不同的模式：「引导程序（bootstrappers）」 和 「迭代器（iterators）」。两者都在帮助工程师（甚至是非技术用户）缩小从想法到执行的差距。
Bootstrappers
这一类包括 Bolt, v0, 和 screenshot-to-code 等 AI 工具，其特点为：
从设计或粗略概念开始； 使用 AI 生成完整的初始代码库； 能够在几小时或几天内获得工作原型； 专注于快速验证和迭代
这样的工作流令人印象深刻。比如一位独立开发人员可以使用 Bolt，在短时间内将 Figma 设计转变为有效的 Web 应用程序。尽管达不到生产级别的要求，但用来获得初步的用户反馈绰绰有余。
Iterators
这一类主要负责日常开发工作流程，包括 Cursor、Cline、Copilot 和 WindSurf 等工具，效果没有上面那么浮夸，但更加实在，比如：
完成代码、提供建议； 执行复杂的重构任务； 生成测试和文档； 作为解决问题的「结对程序员」
虽然这两种方法都可以大大加快开发速度，但「天下没有免费的午餐」。
「AI 速度」的隐性成本
高级工程师使用 Cursor 或 Copilot 等 AI 工具，可以在几分钟内搭建整个功能的基架，并完成测试和文档，就像变魔术一样。
但仔细观察就会发现，在参考 AI 建议的同时，资深工程师们还会：
将生成的代码重构为更小的模块； 添加边缘情况处理； 优化类型定义和接口； 添加全面的错误处理； 甚至是质疑 AI 给出的架构
换句话说，他们正在用多年积累的工程智慧，塑造和限制 AI 的输出。AI 负责加速代码实现，但人类的专业知识确保代码的可维护性。
而初级工程师就经常错过这些关键步骤。他们更容易接受 AI 的输出，从而导致所谓的「纸牌屋代码（house of cards code）」——看起来很完整，但在现实世界的压力下会崩溃。
知识悖论
所以实际上，相比于初学者，AI 反而更能帮助有经验的开发人员，——这多少有点反直觉。
高级工程师利用 AI 快速构建想法的原型（理解）、生成基本实现（可改进）、探索已知问题的替代方法等等；
而初学者却经常接受不正确或过时的解决方案、忽略关键的安全性和性能问题、不知道如何调试 AI 生成的代码，最终构建了一个自己不完全理解的脆弱系统。
70% problem
使用 AI 进行编码的非工程师，经常遇到一个窘境： 他们可以出人意料地迅速完成 70% 的工作，但最后的 30% 就相当痛苦了。
「70% problem」揭示了 AI 辅助开发的现状，刚开始如有神助，后来被现实按在地上摩擦。
实际情况通常是：
尝试修复一个小错误——> AI 提出了一个似乎合理的更改——> 这个更改破坏了其他一些东西——> 要求 AI 修复新问题——> 又产生了两个新 bug——> 无限循环
这个循环对于非工程师来说尤其痛苦，因为他们缺乏专业知识来理解真正出了什么问题。
有经验的开发人员遇到 bug 时，可以根据多年的模式识别来推理潜在原因和解决方案。如果没有这个背景，那基本上就是在用自己不完全理解的代码「打地鼠」。
学习悖论
还有一个更深层次的问题：让非工程师使用 AI 编码工具，实际上可能会阻碍学习。
代码生成了、运行了，但「开发者」不了解基本原理，此时，他错过了学习基本模式、没有培养调试技能、无法对架构决策进行推理，而这份代码又需要维护和扩展。
于是，「开发者」不断返回 AI 来解决问题，而没有培养自己处理问题的专业能力。
非工程师使用 AI 编码工具的最好方式可能是「混合模式」：
1. 使用 AI 进行快速原型设计 2. 花点时间了解生成的代码是如何工作的 3. 学习基本的编程概念以及 AI 使用 4. 逐步建立知识基础 5. 将 AI 用作学习工具，而不仅仅是代码生成器
但这需要耐心和奉献精神，与许多人使用 AI 工具的目标恰恰相反。
「70% problem」表明，当前的 AI 还不是许多人希望的那个 AI。最后 30% 的工作（使软件可用于生产、可维护等），仍然需要真正的工程知识。
最佳实践
Addy Osmani 观察了几十个团队，总结了一些最佳实践方式：
「AI 初稿」模式
让 AI 生成基本实现；手动审查和模块化重构；添加全面的错误处理；编写全面的测试；记录关键决策。
「持续对话」模式
为每个不同的任务开始新的 AI 聊天；保持上下文集中和最小；经常查看和提交更改；保持紧密的反馈循环。
「信任但验证」模式
使用 AI 生成初始代码；手动审查所有关键路径；边缘案例的自动测试；定期安全审计。
AI 的真正前景？
尽管存在这些挑战，但作者对 AI 在软件开发中的作用持乐观态度。关键是要充分利用 AI 的真正优势：
加速已知 AI 擅长帮助实现我们已经了解的模式，就像有一个无限耐心的结对程序员，他可以非常快速地打字。
探索可能性 AI 非常适合快速构建想法原型和探索不同的方法，就像一个沙箱，我们可以在其中快速测试概念。
自动化例程 AI 大大减少了花在样板和日常编码任务上的时间，让我们可以专注于有趣的问题。
如果您刚刚开始 AI 辅助开发，作者的建议是，先从小处着手。
将 AI 用于非耦合的、定义明确的任务，查看生成的每一行代码，逐渐构建更大的功能。
过程中保持模块化：将所有内容分解为小的重点文件，在组件之间保持清晰的接口，记录模块的边界。
重要的一点是，相信自己的经验：AI 用来加速而不能取代你的判断、感觉不对劲时要质疑、时刻维护自己的工程标准。
Agent 兴起
随着我们进入 2025 年，AI 辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了原型设计和迭代方式，但我们正处于更重要转型的风口浪尖：智能体（Agent）软件工程的兴起。
智能体系统不仅可以响应提示，还将以越来越高的自主性规划、执行和迭代解决方案。
比如 Anthropic 的 Claude 能够使用计算机，或者 Cline 自动启动浏览器和运行测试的能力。
在调试过程中，智能体系统不仅给出修复 bug 的建议，还可以：
主动识别潜在问题、启动和运行测试套件、检查 UI 元素并捕获屏幕截图、提出并实施修复、验证解决方案是否有效。
下一代工具将可以无缝集成视觉理解（UI 屏幕截图、模型、图表）、口头语言对话和环境交互（浏览器、终端、API）。
未来的 AI 不是取代开发人员，而是成为一个越来越有能力的协作者，既可以采取主动，又能尊重人类的指导和专业知识。
参考资料：
https://addyo.substack.com/p/the-70-problem-hard-truths-about
