原文地址
Translate by ChatGPT o3-mini

在过去几年里，我深入参与了AI辅助开发，我注意到了一个有趣的模式。尽管工程师们报告说他们在AI的帮助下变得更为高效，但我们日常使用的软件似乎并没有明显变得更好。这是怎么回事？

我想我知道原因，而答案揭示了关于软件开发的一些基本真相，我们需要面对。让我分享一下我所学到的。

开发者如何实际使用AI

我观察到团队在使用AI进行开发时，呈现出两种截然不同的模式。我们可以称之为“自 bootstrap 模式”和“迭代模式”。两者都在帮助工程师（甚至是非技术用户）缩短从创意到执行（或最小化可行产品，MVP）的距离。

自 Bootstrap 模式：从零到 MVP

像 Bolt、v0 和 screenshot-to-code AI 这样的工具正在革新我们如何启动新项目。这些团队通常：

  • 从设计或粗略的概念开始
  • 使用AI生成完整的初始代码库
  • 在数小时或数天内得到一个可用的原型，而不是几周
  • 重点关注快速验证和迭代

结果可能令人印象深刻。最近我看到一个独立开发者使用 Bolt 将 Figma 设计转化为一个工作的网页应用，几乎没有花费多少时间。它还不是生产级别的，但足够用来收集非常初步的用户反馈。

迭代模式：日常开发

第二种模式使用像 Cursor、Cline、Copilot 和 WindSurf 这样的工具来进行日常开发工作流。这种方式虽然看起来不那么炫酷，但可能具有更大的变革潜力。这些开发者正在：

  • 使用AI进行代码补全和建议
  • 利用AI进行复杂的重构任务
  • 生成测试和文档
  • 将AI作为“配对程序员”来解决问题

但这里有个问题：尽管这两种方法都可以显著加速开发，但它们也带来了那些并不显而易见的隐性成本。

“AI速度”的隐性成本

当你看一个资深工程师使用像Cursor或Copilot这样的AI工具时，感觉就像魔法一样。他们能在几分钟内搭建整个功能，包括测试和文档。但仔细看，你会注意到一些关键的事情：他们不仅仅是在接受AI的建议。他们在不断地：

  • 将生成的代码重构成更小、更专注的模块
  • 添加AI遗漏的边界情况处理
  • 强化类型定义和接口
  • 质疑架构决策
  • 添加全面的错误处理

换句话说，他们正在应用多年来的工程智慧来塑造并约束AI的输出。AI加速了他们的实施过程，但他们的专业知识确保了代码的可维护性。

初级工程师往往忽视这些关键步骤，他们更容易接受AI的输出，导致我所谓的“纸牌屋代码”——看起来完整，但在现实世界的压力下会崩溃。

知识悖论

我发现的最具反直觉的事情是：AI工具帮助经验丰富的开发者远远超过初学者。这看起来有些不对劲——难道AI不应该使编码变得民主化吗？

实际上，AI就像是你团队中的一个非常勤奋的初级开发者。他们能迅速写出代码，但需要持续的监督和修正。你知道得越多，就能更好地引导他们。

这就创造了我所谓的“知识悖论”：

  • 资深开发者使用AI来加速他们已经知道如何做的事情
  • 初级开发者试图通过AI来学习该做什么
  • 结果差异巨大

我看到资深工程师用AI来：

  • 快速原型化他们已经理解的创意
  • 生成基本的实现，然后进行优化
  • 探索已知问题的替代解决方案
  • 自动化日常编码任务

而初级开发者通常会：

  • 接受不正确或过时的解决方案
  • 错过关键的安全性和性能考虑
  • 在调试AI生成的代码时遇到困难
  • 构建他们并不完全理解的脆弱系统

70%问题：AI的学习曲线悖论

最近有一条推文完美地捕捉了我在现场观察到的现象：非工程师使用AI进行编码时，会遇到令人沮丧的壁垒。他们可以在意想不到的时间内完成70%的工作，但最后的30%则成为一种递减回报的体验。

这个“70%问题”揭示了当前AI辅助开发的一个重要真相。最初的进展感觉像魔法——你可以描述你想要的，AI工具如v0或Bolt会生成一个看起来令人印象深刻的工作原型。但接下来，现实就来了。

倒退两步的模式

接下来通常会发生一个可预测的模式：

  • 你试图修复一个小bug
  • AI建议一个看起来合理的更改
  • 这个修复导致了其他问题
  • 你请求AI修复新的问题
  • 这又会产生更多的问题
  • 一遍又一遍地重复这个循环

对于非工程师来说，这个过程尤其痛苦，因为他们缺乏理解实际发生了什么的思维模型。当经验丰富的开发者遇到bug时，他们可以通过多年的模式识别来推测潜在原因和解决方案。没有这个背景，你实际上是在与你不完全理解的代码玩打地鼠游戏。

继续的学习悖论

这里有一个更深层次的问题：使AI编码工具对于非工程师更具可接近性的特性——它们能够代替你处理复杂性——实际上可能会妨碍学习。当代码只是“出现”而你并不理解背后的原理时：

  • 你不会培养调试技能
  • 你错过了学习基本模式
  • 你无法推理架构决策
  • 你很难维护和发展代码

这就产生了一种依赖性，你需要不断回到AI去修复问题，而不是培养自己处理问题的专业能力。

知识差距

我见过的最成功的非工程师使用AI编码工具采用了一种混合方式：

  • 使用AI进行快速原型化
  • 花时间了解生成的代码是如何工作的
  • 在使用AI的同时学习基本的编程概念
  • 逐步建立知识基础
  • 将AI作为学习工具，而不仅仅是代码生成器

但这需要耐心和奉献——正好与许多人使用AI工具时希望实现的目标相反。

对未来的影响

这个“70%问题”表明，当前的AI编码工具最好看作是：

  • 经验丰富的开发者的原型加速器
  • 对那些致力于理解开发过程的人的学习工具
  • 快速验证创意的MVP生成器

但它们还不是许多人所希望的编码民主化解决方案。最后的30%——使软件生产就绪、可维护且强大的部分——仍然需要真正的工程知识。

好消息是？随着工具的改进，这个差距可能会缩小。但现在，最务实的方法是将AI用于加速学习，而不是完全取代它。

实际有效的模式

在观察了几十个团队后，我发现以下几种方式一直有效：

  1. “AI初稿”模式

    • 让AI生成基本的实现
    • 手动审查并重构以增强模块化
    • 添加全面的错误处理
    • 编写详细的测试
    • 记录关键决策

  2. “不断对话”模式

    • 为每个独立任务启动新的AI对话
    • 保持上下文专注且简洁
    • 经常审查并提交更改
    • 保持紧密的反馈循环

  3. “信任但验证”模式

    • 使用AI进行初始代码生成
    • 对所有关键路径进行人工审查
    • 自动测试边界情况
    • 定期进行安全审计

展望未来：AI的真正承诺？

尽管存在这些挑战，我对AI在软件开发中的作用仍然持乐观态度。关键是理解它真正擅长的领域：

  • 加速已知的事情
  • 探索可能的解决方案
  • 自动化日常任务

这对你意味着什么？

如果你刚刚开始接触AI辅助开发，我的建议是：

  • 从小处做起
  • 使用AI进行孤立、定义明确的任务
  • 审查每一行生成的代码
  • 逐步构建更大的功能
  • 保持模块化
  • 将一切拆分成小而专注的文件
  • 维护清晰的组件间接口
  • 记录模块边界
  • 信任你的经验
  • 使用AI加速，而不是替代你的判断
  • 对生成的代码提出疑问
  • 维护你的工程标准

代理软件工程的崛起

随着我们迈向2025年，AI辅助开发的格局正在发生戏剧性的变化。虽然当前的工具已经改变了我们的原型制作和迭代方式，但我相信我们正站在一个更大变革的边缘：代理软件工程的崛起。

什么是“代理”？

“代理”不再只是响应命令，而是这些系统可以规划、执行并在逐步增加自主性的基础上迭代解决方案。

如果你有兴趣了解更多关于代理的信息，包括我对Cursor/Cline/v0/Bolt的看法，你可能会对我最近的JSNation演讲感兴趣。

我们已经看到了这一进化的早期迹象：

从回应者到协作者

目前的工具大多在等待我们的命令。但看看像Anthropic的Claude中的计算机使用功能，或者Cline能自动启动浏览器并运行测试的能力。这些不仅仅是华丽的自动补全——它们实际上理解任务并主动解决问题。

考虑调试：这些代理不仅仅是建议修复，它们可以：

  • 主动识别潜在问题
  • 启动并运行测试套件
  • 检查UI元素并捕获截图
  • 提出并实施修复
  • 验证解决方案是否有效（这可能非常重要）

多模态的未来

下一代工具可能不仅仅与代码合作——它们可能无缝集成：

  • 视觉理解（UI截图、模型、图表）
  • 口头语言对话
  • 环境互动（浏览器、终端、API）

这种多模态能力意味着它们能够像人类一样全面理解和处理软件，而不仅仅停留在代码层面。

自主但受引导

我从与这些工具的合作中得到的一个关键见解是，未来并不是AI取代开发者——而是AI成为一个越来越有能力的协作者，它能够主动采取行动，同时仍然尊重人类的引导和专业知识。

2025年最有效的团队可能是那些学会了：

  • 为他们的AI代理设定明确的边界和指南
  • 建立强大的架构模式，让代理能够在其中工作
  • 在人类和AI能力之间创造有效的反馈循环
  • 在利用AI的自主性时，保持人类监督

英语优先的开发环境

正如Andrej Karpathy所说：

“英语正在成为最炙手可热的编程语言。”

这标志着我们与开发工具互动方式的根本转变。能够清晰地思考并精准地用自然语言表达，正变得和传统编码技能一样重要。

这种向代理开发转变将要求我们进化我们的技能：

  • 更强的系统设计和架构思维
  • 更好的需求规格和沟通能力
  • 更多的质量保证和验证关注
  • 增强的人类与AI能力之间的合作

软件作为工艺的回归？

虽然AI使得构建软件比以往任何时候都更加迅速，但我们面临着失去某些关键东西的风险——创造真正精致的、消费者级体验的艺术。

演示质量陷阱

这已经成了一种模式：团队利用AI快速构建令人印象深刻的演示。快乐路径运行得很顺利。投资者和社交网络都感到惊讶。但当真正的用户开始点击时？这就是事情崩溃的时刻。

我亲眼见过这样的情况：

  • 对普通用户来说毫无意义的错误消息
  • 崩溃应用的边界情况
  • 从未清理过的混乱UI状态
  • 完全忽视可访问性
  • 在较慢设备上的性能问题

这些不仅仅是P2级错误——它们是区分“用户勉强接受的软件”和“用户热爱的软件”的差异。

失去的精细打磨艺术

创造真正自助的

软件——那种用户永远不需要联系客服的软件——需要一种不同的心态：

  • 对错误消息进行过度关注
  • 在慢连接下进行测试
  • 优雅地处理每个边界情况
  • 使功能易于发现
  • 与真实的、通常是非技术的用户一起进行测试

这种注重细节的能力（也许）无法通过AI生成。它来自同理心、经验，以及对工艺的深刻关怀。

个人软件的复兴

我相信，我们将见证个人软件开发的复兴。随着市场被AI生成的MVP充斥，能够脱颖而出的产品将是那些由开发者构建的，这些开发者：

  • 为他们的工艺感到自豪
  • 关心细节
  • 专注于完整的用户体验
  • 为边界情况进行构建
  • 创建真正的自助体验

讽刺的是？AI工具实际上可能促成这一复兴。通过处理日常的编码任务，它们解放了开发者，让他们专注于最重要的事情——创造真正服务和让用户愉悦的软件。

最后结论

AI并没有让我们的软件变得更好，因为软件的质量（也许）从来不是由编码速度决定的。软件开发的难点——理解需求、设计可维护的系统、处理边界情况、确保安全性和性能——仍然需要人类的判断。

AI的确能让我们更快地进行迭代和实验，通过更迅速的探索可能导致更好的解决方案。但只有在我们保持工程纪律并把AI当作工具而非替代良好软件实践的情况下才能实现这一点。记住：目标不是写更多的代码，更快地写代码。而是构建更好的软件。明智地使用AI，我们可以做到这一点。但最终仍然是我们决定“更好”是什么意思，并知道如何实现它。