过去几年里，我一直在研究AI辅助开发工具，其中观察到了一个有趣的现象：虽然很多工程师称有了AI的帮助，他们的工作效率得到了大幅提升，但我们日常使用的软件似乎并没有因这些工程师的正反馈而在质量上有显著改进。
这是怎么回事呢？
开发者实际上是如何使用AI的？
引导程序：从0到MVP
像Bolt、v0以及截图转代码的AI工具正在彻底改变我们创建新项目的方式。这些团队通常：
结果令人印象深刻。我最近看到了一位独立开发者使用Bolt瞬间将一个Figma设计转换成了一个可工作的Web应用程序。虽然它还未能直接用于生产环境，但足以用来获得初步的用户反馈。
迭代者：日常开发
第二个阵营的开发者在日常开发流程中主要使用如Cursor、Cline、Copilot和WindSurf这样的工具。这虽然不如前者那么引人注目，但可能更具变革性。这些开发者：
然而，这里有一个陷阱：尽管这两种方法都能显著加速开发进程，但它们伴随着一些隐性成本问题。
“AI速度”的隐性成本
当你看到资深工程师使用像Cursor或Copilot这样的AI工具工作时，总觉得他们会用魔法一样。他们可以在几分钟内搭建出包含测试和文档的整个功能模块。但仔细观察你会发现一个关键点：他们并不是简单地接受AI的建议。实际上，他们一直在：
换句话说，他们在应用多年积累下来的工程智慧之际进一步塑造和限制AI的输出。AI加速了他们的实现过程，而他们的专业知识确保了代码的可维护性。
初级工程师往往忽略了这些重要的步骤。他们更容易接受AI的输出，导致我称之为“纸牌屋代码”的现象——它看似完整，但在现实压力下却不堪一击。
知识悖论
我发现最违反直觉的一件事是：AI工具对有经验的开发者帮助更大，而非初学者。这似乎与我们的预期相反——难道AI不应该让编程变得更加民主化吗？
现实情况是，AI就像团队中非常热心的初级开发人员。他们可以快速编写代码，但需要持续的监督和纠正。你了解得越多，就越能更好地指导他们。
这就产生了我所说的“知识悖论”：
因此结果大相径庭。
我目睹过很多资深工程师使用AI来：
与此同时，初级工程师常常：
70%问题：AI的学习曲线悖论
最近有一条推文完美地总结了我在这一领域观察到的现象：非工程师使用AI进行编程时，发现自己遇到了令人沮丧的障碍。他们能够以惊人的速度完成70%的工作，但最后的30%却变成了边际效益递减的练习。
这个“70%问题”揭示了当前AI辅助开发状态下的一个关键事实。你使用时，初期的进展感觉像是魔法——你可以描述你想要的东西，像v0或Bolt这样的AI工具会生成一个看起来令人印象深刻的可工作程序原型。但随后很多现实问题就开始显现。
两步后退模式
接下来通常发生的事情会遵循一个可预测的模式：
对于非工程师来说，遇到这个循环尤为痛苦，因为他们缺乏理解实际发生错误的思维模型。当有经验的开发者遇到Bug时，他们可以根据多年积累的经验来推断潜在的原因和解决方案。如果没有这种技术背景知识，你基本上是在处理你不完全理解的代码，就像是在玩打地鼠游戏一样。
持续的学习悖论
这里有一个更深层次的问题：本来AI编程工具是对非工程师而言，是一个简单方便使用的东西——因为它们为你处理复杂性问题——然而，实际上它们可能会影响非工程师的自学能力。当代码只是“出现”，而你并不理解其背后的原则时：
这会产生一种依赖关系，你需要不断地将你遇到的问题提交给AI工具，不断地询问AI工具的建议，而不是自己培养处理这些问题的专业知识。
知识差距
我见过成功的非工程师使用AI编程工具的方法是采取一种混合策略：
但这需要耐心和奉献精神——这正是许多人希望通过使用AI工具所避免的东西。
对未来的影响
这个“70%的问题”表明，目前的AI编程工具最适合被看作是：
然而，它们还不是许多人所期望的编码民主化解决方案。最后的30%——使软件达到生产就绪、可维护和健壮的部分——仍然需要真正的工程知识。
好消息是，随着工具的进步，这一差距很可能会缩小。但现在最务实的方法是利用AI来加速学习，而不是完全取代它。
实际有效的方法：使用AI工具的实用模式
在观察了数十个团队之后，我发现以下方法始终奏效：
1.“AI初稿”模式
2.“持续对话”模式
3.“信任与验证”模式
展望未来：AI的真正前景？
尽管存在这些挑战，我对AI在软件开发中的角色持乐观态度。关键是了解它的真正优势所在：
这对你而言，意味着什么？
如果你刚开始尝试使用AI辅助开发，这里有几点建议：
代理软件工程的兴起
随着我们迈向2025年，AI辅助开发的格局正在发生剧烈变化。目前的工具已经改变了我们原型开发和迭代的方式，但我相信我们正站在一个更大变革的门槛上：代理软件工程的兴起。
我所说的“代理”是什么意思？这些系统不仅可以响应提示，还可以以越来越高的自主性来规划、执行和迭代解决方案。
我们已经看到了这种演进的初步迹象：
从响应者到协作者
当前的大多数工具主要是在等待我们的指令。然而，看看一些新功能，比如Anthropic的Claude中的计算机使用能力，或Cline自动启动浏览器并运行测试的功能。这些工具不仅仅是“高级自动补全”，它们实际上能够理解任务并主动解决问题。
以调试为例，与其只是建议修复方案，这些智能体还可以：
多模态的未来
下一代工具可能不仅仅限于代码合作，它们可能会无缝整合：
这种多模态能力意味着工具可以像人类一样以整体视角理解并处理软件，而不仅仅局限于代码层面。
自主但可引导
从与这些工具的合作中，我获得的一个关键见解是，未来并不是AI取代开发者，而是AI成为一个能力日益增强的协作者——它能够主动承担任务，同时仍尊重人类的引导和专业知识。
2025年最有效的团队或许是那些能够做到以下几点的团队：
“英语优先”的开发环境
正如AndrejKarpathy所言：
这标志着我们与开发工具互动方式的根本性转变。清晰思考和精确表达自然语言的能力正变得与传统的编程技能同样重要。
这种面向智能体开发的转变要求我们不断提升自身技能：
软件回归匠艺？
虽然AI让软件开发的速度前所未有地加快，但我们可能正在失去某些重要的东西——打造真正精致、符合消费者需求的软件体验的艺术。
“Demo质量”陷阱
如今，这似乎已成一种模式：
团队利用AI快速构建出令人印象深刻的演示产品。理想路径运行得完美无缺，投资者和社交媒体赞不绝口。但当真实用户开始使用时呢？问题随之而来：
这些问题不仅仅是优先级较低的“小bug”，它们决定了软件是让用户“勉强接受”还是“深深喜爱”。
精致的失落艺术
要创建真正的自动化的软件——用户无需联系支持即可顺畅使用的软件——需要开发团队以一种全新的心态来对待：
个人软件开发的复兴
我相信，个人软件开发即将迎来复兴。随着市场充斥着由AI生成的最低可行产品（MVP），那些脱颖而出的将是由以下开发者打造的产品：
核心观点
AI之所以没有显著提升软件质量，是因为软件质量的限制（或许）从来就不在编码速度上。
软件开发中真正困难的部分——理解需求、设计可维护的系统、处理边界场景、确保安全性和性能——这些依然需要人类的判断力。
AI的作用在于让我们更快地迭代和实验，从而通过更快速的探索找到更好的解决方案。但这只有在我们保持工程纪律、将AI作为工具而非替代品的前提下才能实现。请记住：目标不是更快地写出更多代码，而是构建更好的软件。
如果运用得当，AI可以帮助我们实现这一目标。但最终，我们仍需明确什么才是“更好”，以及如何实现它。