那么问题来了，AI coding用过都说好，但我们平时用的软件咋感觉没啥进步呢？

　　近日，Addy Osmani，谷歌的工程主管，同时也是一位亚马逊畅销书作家，为我们揭示了AI辅助编码在一线开发中的真实情况。

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

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

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

　　高级工程师使用Cursor或Copilot等AI工具，可以在几分钟内搭建整个功能的基架，并完成测试和文档，就像变魔术一样。

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

　　而初级工程师就经常错过这些关键步骤。他们更容易接受AI的输出，从而导致所谓的「纸牌屋代码（house of cards code）」——看起来很完整，但在现实世界的压力下会崩溃。

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

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

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

　　「70% problem」揭示了AI辅助开发的现状，刚开始如有神助，后来被现实按在地上摩擦。

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

　　有经验的开发人员遇到bug时，可以根据多年的模式识别来推理潜在原因和解决方案。如果九游娱乐 九游娱乐官方没有这个背景，那基本上就是在用自己不完全理解的代码「打地鼠」。

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

　　代码生成了、运行了，但「开发者」不了解基本原理，此时，他错过了学习基本模式、没有培养调试技能、无法对架构决策进行推理，而这份代码又需要维护和扩展。

　　于是，「开发者」不断返回AI来解决问题，而没有培养自己处理问题的专业能力。

　　「70% problem」表明，当前的AI还不是许多人希望的那个AI。最后30%的工作（使软件可用于生产、可维护等），仍然需要真正的工程知识。

　　让 AI 生成基本实现；手动审查和模块化重构；添加全面的错误处理；编写全面的测试；记录关键决策。

　　为每个不同的任务开始新的AI聊天；保持上下文集中和最小；经常查看和提交更改；保持紧密的反馈循环。

　　使用AI生成初始代码；手动审查所有关键路径；边缘案例的自动测试；定期安全审计。

　　加速已知AI擅长帮助实现我们已经了解的模式，就像有一个无限耐心的结对程序员，他可以非常快速地打字。

　　探索可能性AI非常适合快速构建想法原型和探索不同的方法，就像一个沙箱，我们可以在其中快速测试概念。

　　自动化例程AI大大减少了花在样板和日常编码任务上的时间，让我们可以专注于有趣的问题。

　　将AI用于非耦合的、定义明确的任务，查看生成的每一行代码，逐渐构建更大的功能。

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

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

　　随着我们进入2025年，AI辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了原型设计和迭代方式，但我们正处于更重要转型的风口浪尖：智能体（Agent）软件工程的兴起。

　　智能体系统不仅可以响应提九游娱乐 九游娱乐官方示，还将以越来越高的自主性规划、执行和迭代解决方案。

　　比如Anthropic的Claude能够使用计算机，或者Cline自动启动浏览器和运行测试的能力。

　　主动识别潜在问题、启动和运行测试套件、检查UI元素并捕获屏幕截图、提出并实施修复、验证解决方案是否有效。

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

　　未来的AI不是取代开发人员，而是成为一个越来越有能力的协作者，既可以采取主动，又能尊重人类的指导和专业知识。