在过去几年深入研究人工智能辅助开发后，我注意到一个有趣的现象。虽然工程师报告称人工智能显著提高了他们的工作效率，但我们日常使用的实际软件似乎并没有得到明显的改善。这是怎么回事呢？
我想我知道原因，答案揭示了我们需要考虑的一些软件开发基本事实。让我分享我所学到的东西。
我观察到团队利用 AI 进行开发的两种截然不同的模式。我们称它们为“引导者”和“迭代者”。两者都在帮助工程师（甚至是非技术用户）缩短从想法到执行（或 MVP）的差距。
Bolt、v0 和屏幕截图转代码 AI 等工具正在彻底改变我们启动新项目的方式。这些团队通常：
- 从设计或粗略概念开始
- 使用人工智能生成完整的初始代码库
- 在几小时或几天内（而不是几周）获得工作原型
- 专注于快速验证和迭代
结果令人印象深刻。我最近看到一位独立开发人员使用 Bolt 在很短的时间内将 Figma 设计转变为可运行的 Web 应用程序。它尚未投入生产，但足以获得初步的用户反馈。
第二阵营使用 Cursor、Cline、Copilot 和 WindSurf 等工具进行日常开发工作。这些工具不那么引人注目，但可能更具变革性。这些开发人员是：
- 使用人工智能进行代码完成和建议
- 利用人工智能完成复杂的重构任务
- 生成测试和文档
- 使用人工智能作为“结对程序员”来解决问题
但问题在于：虽然这两种方法都可以大大加速开发速度，但它们都有一些并不明显的隐性成本。
当你看到高级工程师使用 Cursor 或 Copilot 等 AI 工具时，你会觉得这就像变魔术一样。他们可以在几分钟内搭建整个功能，并完成测试和文档。但仔细观察，你会发现一个关键点：他们不仅仅是接受 AI 的建议。他们不断地：
- 将生成的代码重构为更小、更集中的模块
- 添加处理 AI 遗漏的边缘情况
- 加强类型定义和接口
- 质疑架构决策
- 添加全面的错误处理
换句话说，他们正在运用多年来辛苦积累的工程智慧来塑造和限制人工智能的输出。人工智能正在加速他们的实施，但他们的专业知识才是保持代码可维护的关键。
初级工程师经常会忽略这些关键步骤。他们更容易接受人工智能的输出，导致出现我所说的“纸牌屋代码”——它看似完整，但在现实压力下却崩溃了。
这是我发现的最违反直觉的事情：人工智能工具对经验丰富的开发人员的帮助比初学者更大。这似乎是倒退的——人工智能不应该使编码民主化吗？
现实情况是，人工智能就像是你的团队中有一个非常热心的初级开发人员。他们可以快速编写代码，但需要不断的监督和纠正。你知道的越多，你就越能指导他们。
这就产生了我所说的“知识悖论”：
- 老年人利用人工智能来加速他们已经知道如何做的事情
- 初级员工尝试使用人工智能来学习做什么
- 结果大相径庭
我亲眼见过高级工程师利用人工智能来：
- 快速制作他们已经理解的原型
- 生成基本的实现，然后进行改进
- 探索已知问题的替代方法
- 自动执行日常编码任务
与此同时，初级员工经常会：
- 接受不正确或过时的解决方案
- 忽略关键的安全和性能考虑
- 调试人工智能生成的代码很困难
- 构建他们无法完全理解的脆弱系统
最近引起我注意的一条推文完美地概括了我在该领域的观察：非工程师使用人工智能进行编码时会发现自己遇到了令人沮丧的障碍。他们可以出奇地快速地完成 70% 的工作，但最后的 30% 却变成了收益递减的过程。
这个“70% 问题”揭示了当前人工智能辅助开发的关键问题。最初的进展让人感觉很神奇——你可以描述你想要的东西，而像 v0 或 Bolt 这样的人工智能工具会生成一个看起来令人印象深刻的工作原型。但随后现实就开始显现。
接下来发生的事情通常遵循可预测的模式：
- 你尝试修复一个小错误
- 人工智能建议的改变似乎合理
- 此修复破坏了其他内容
- 你要求人工智能解决新问题
- 这又带来了两个问题
- 重复上述步骤
对于非工程师来说，这种循环尤其痛苦，因为他们缺乏理解问题出在哪里的思维模型。当经验丰富的开发人员遇到错误时，他们可以根据多年的模式识别推断出潜在原因和解决方案。如果没有这种背景，你基本上是在用你不完全理解的代码玩打地鼠游戏。
这里有一个更深层次的问题：让非工程师也能使用人工智能编码工具的因素——它们能够代替你处理复杂问题——实际上却会阻碍学习。当你不理解底层原理而代码只是“出现”时：
- 你没有培养调试技能
- 您想念学习基本模式
- 你无法推理架构决策
- 你很难维护和改进代码
这会造成一种依赖关系，你需要不断地回到 AI 来解决问题，而不是培养自己处理问题的专业知识。
我见过的最成功的使用 AI 编码工具的非工程师采用了混合方法：
- 使用人工智能进行快速原型设计
- 花时间了解生成的代码的工作原理
- 学习基本的编程概念以及人工智能的使用
- 逐步建立知识基础
- 将 AI 用作学习工具，而不仅仅是代码生成器
但这需要耐心和奉献精神——这与许多人最初希望通过使用人工智能工具实现的目标完全相反。
这个“70%的问题”表明，当前的AI编码工具最好被视为：
- 为经验丰富的开发人员提供原型设计加速器
- 为那些致力于理解发展的人提供的学习辅助工具
- 用于快速验证想法的 MVP 生成器
但它们还不是许多人所希望的编码民主化解决方案。最后的 30%——使软件可用于生产、可维护和强大的部分——仍然需要真正的工程知识。
好消息是，随着工具的改进，这种差距可能会缩小。但目前，最务实的方法是使用人工智能来加速学习，而不是完全取代它。
在观察了几十个团队之后，我发现以下是一直有效的方法：
- 让AI生成基本的实现
- 手动审查和重构模块化
- 添加全面的错误处理
- 编写彻底的测试
- 记录关键决策
- 为每个不同的任务启动新的 AI 聊天
- 保持上下文重点和简洁
- 经常审查并提交变更
- 保持紧密的反馈回路
- 使用 AI 进行初始代码生成
- 手动审查所有关键路径
- 边缘情况的自动测试
- 定期安全审核
尽管面临这些挑战，我仍对人工智能在软件开发中的作用持乐观态度。关键是要了解它真正有什么用处：
- 加速已知的
人工智能能够帮助我们实现我们已经了解的模式。这就像拥有一位无限耐心、打字速度极快的结对程序员。 - 探索可能的
人工智能对于快速构建原型和探索不同的方法非常有用。这就像拥有一个沙箱，我们可以在其中快速测试概念。 - 常规
人工智能的自动化大大减少了花在样板和常规编码任务上的时间，让我们能够专注于有趣的问题。
如果你刚刚开始进行 AI 辅助开发，以下是我的建议：
- 从小事做起
- 使用人工智能完成独立且定义明确的任务
- 检查生成的每行代码
- 逐步构建更大的功能
- 保持模块化
- 将所有内容分解为小的、集中的文件
- 维护组件之间清晰的接口
- 记录模块边界
- 相信你的经验
- 使用人工智能来加速而不是取代你的判断
- 问题生成的代码感觉不对
- 保持您的工程标准
随着我们迈向 2025 年，人工智能辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们制作原型和迭代的方式，但我相信我们正处于一个更为重大的转变的风口浪尖：代理软件工程的兴起。
我所说的“代理”是什么意思？这些系统不仅可以响应提示，还可以以越来越强的自主性来规划、执行和迭代解决方案。
如果您有兴趣了解有关代理的更多信息，包括我对 Cursor/Cline/v0/Bolt 的看法，您可能会对我最近的 JSNation 演讲感兴趣。
我们已经看到了这种演变的早期迹象：
当前的工具大多等待我们的命令。但看看新功能，例如 Claude 中的 Anthropic 计算机使用，或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是美化的自动完成功能 - 它们实际上是在理解任务并主动解决问题。
考虑一下调试：这些代理不仅可以建议修复，还可以：
- 主动发现潜在问题
- 启动并运行测试套件
- 检查 UI 元素并捕获屏幕截图
- 提出并实施修复
- 验证解决方案是否有效（这可能是一件大事）
下一代工具可能不仅仅能处理代码——它们可以无缝集成：
- 视觉理解（UI 截图、模型、图表）
- 口头语言对话
- 环境交互（浏览器、终端、API）
这种多模式能力意味着它们可以像人类一样理解和使用软件——整体地，而不仅仅是在代码层面。
我从使用这些工具中获得的关键见解是，未来不是人工智能取代开发人员，而是人工智能成为一个越来越有能力的合作者，能够采取主动行动，同时仍然尊重人类的指导和专业知识。
2025 年最有效的团队可能是那些学会以下技能的团队：
- 为人工智能代理设定明确的界限和指导方针
- 建立代理可以在其中工作的强大架构模式
- 在人类和人工智能能力之间建立有效的反馈循环
- 在利用人工智能自主性的同时保持人类监督
正如 Andrej Karpathy 所说：
“英语正在成为最热门的新编程语言。”
这是我们与开发工具交互方式的根本性转变。清晰思考和用自然语言准确沟通的能力正变得与传统编码技能一样重要。
这种向代理发展的转变将要求我们提高我们的技能：
- 更强的系统设计和架构思维
- 更好的需求规范和沟通
- 更加注重质量保证和验证
- 增强人类与人工智能之间的协作
虽然人工智能使得快速构建软件变得前所未有的容易，但我们却面临着失去一些重要的东西的风险，那就是创造真正精致的、消费者品质的体验的艺术。
这正在成为一种模式：团队使用人工智能快速构建令人印象深刻的演示。快乐之路运行良好。投资者和社交网络都惊叹不已。但当真正的用户开始点击时？那就是事情崩溃的时候。
我亲眼见过这样的事：
- 对于普通用户来说毫无意义的错误消息
- 导致应用程序崩溃的极端情况
- 令人困惑且从未被清理过的 UI 状态
- 完全忽视了无障碍设施
- 较慢设备上的性能问题
这些不仅仅是 P2 错误 - 它们是软件人员所能容忍的软件和软件人员所喜爱的软件之间的区别。
创建真正的自助软件（用户永远不需要联系支持的软件）需要不同的思维方式：
- 纠结于错误信息
- 在慢速连接上进行测试
- 妥善处理每一个边缘情况
- 使功能可被发现
- 与真实的、通常非技术的用户进行测试
这种对细节的关注（也许）不是人工智能能够实现的。它源自同理心、经验和对工艺的深切关注。
我相信我们将看到个人软件开发的复兴。随着市场充斥着人工智能生成的 MVP，脱颖而出的产品将是由具有以下特征的开发人员构建的产品：
- 为自己的技艺感到自豪
- 关注细节
- 注重完整的用户体验
- 为极端情况构建
- 创造真正的自助体验
讽刺的是，人工智能工具实际上可能推动这一复兴。通过处理常规编码任务，它们让开发人员可以专注于最重要的事情——开发真正服务于用户并让用户满意的软件。
人工智能并没有显著改善我们的软件，因为软件质量（也许）从未受到编码速度的主要限制。软件开发的难点——理解需求、设计可维护的系统、处理极端情况、确保安全性和性能——仍然需要人类的判断。
人工智能的作用是让我们能够更快地进行迭代和实验，从而通过更快速的探索获得更好的解决方案。但前提是我们必须保持工程纪律，将人工智能作为一种工具，而不是替代良好的软件实践。请记住：我们的目标不是更快地编写更多代码。而是构建更好的软件。如果使用得当，人工智能可以帮助我们做到这一点。但我们仍然需要知道“更好”的含义以及如何实现它。