深入研究了人工智能辅助开发几年之后，我注意到一个有趣现象。虽然工程师报告称人工智能显著提高了工作效率，但我们日常使用的软件似乎并没有明显改善。这是怎么回事呢？
我想我知道个中原因，答案揭示了一些软件开发的基本事实，这是我们需要思考的地方。
开发者实际上是怎么用AI的
我观察到团队利用 AI 开发存在两种截然不同的模式。我们称之为“自启动”（Bootstrappers）与“迭代器”Iterators）。这两种模式都可以帮助工程师（甚至是非技术用户）填补从想法到执行（或 MVP）的鸿沟。
自启动：从零到 MVP
Bolt、v0 以及屏幕截图转代码 AI 等工具正在彻底改变我们启动新项目的方式。这些团队通常：
结果令人印象深刻。我最近看到一位独立开发者用 Bolt 在很短的时间内将 Figma 设计变成了可运行的 Web 应用。还没到生产级，但用来获取初步用户反馈足够了。
迭代器：日常开发
第二阵营利用 Cursor、Cline、Copilot 以及WindSurf等工具处理日常开发。这些工具没那么光鲜，但可能更具变革性。这些开发者会：
但问题是：虽然这两种方法都可以大大加速开发速度，但它们都存在一些不太明显的隐性成本。
“AI速度”的隐性成本
如果你看过高级工程师运用 Cursor 或 Copilot 等 AI 工具，你会觉得就像变魔术一样。他们可以在几分钟内搭建出整个功能，并完成测试和文档。但仔细观察，你会发现一个关键点：他们可不是接受 AI 建议就完事了。他们会不断地：
换句话说，他们正在运用多年来辛苦积累下来的工程智慧来塑造和限制人工智能的输出。人工智能可加速他们的实现，但他们的专业知识才是让代码可维护的关键。
初级工程师经常会忽略掉这些关键步骤。他们更容易全盘接受人工智能的输出，导致出现我所谓的“纸牌屋代码”——看似完整，但现实压力一推即倒。
知识悖论
这是我发现的最有违直觉的一点：人工智能工具对经验丰富的开发者的帮助要大于对初学者的帮助。听起来似乎在开倒车——人工智能难道不是应该让编码大众化吗？
现实情况是，人工智能就像是你团队有一位很热心的初级开发者。他们能快速编写代码，但需要不断的监督和纠正。你懂得越多，就越能指导他们。
这就产生了我所谓的“知识悖论”：
我亲眼见过高级工程师利用人工智能来：
与此同时，初级员工经常会：
70% 问题：人工智能的学习曲线悖论
有一条推文完美地概括了我对该领域的观察：不是工程师的人用人工智能进行编码会遇到令人沮丧的障碍。他们可以出奇地快速地完成前 70% 的工作，但最后的 30% 却是收益递减的过程。
这个“70% 问题”揭示了当前人工智能辅助开发存在的关键问题。一开始的进展让人感觉很神奇——只需描述你想要的东西，像 v0 或 Bolt 这样的人工智能工具就会生成一个看起来令人印象深刻的工作原型。但之后，现实慢慢浮出水面。
进一步退两步
接下来发生的事情大概会是这样一种模式：
对于不是工程师的人来说，这种情况尤其痛苦，因为他们缺乏相应的思维模式，不知道问题出在哪里。经验丰富的开发者遇到错误时，他们可以根据多年的模式识别推断出潜在原因和解决方案。如果缺乏这种背景，基本上就相当于打地鼠游戏，你不完全理解的代码就是那些地鼠。
这个学习悖论仍在继续
这里面有一个更深层次的问题：不是工程师的人之所以能用人工智能编码工具，是因为这些工具能代为处理复杂问题，但这其实也会妨碍学习。当你不理解底层原理而代码却凭空“出现”时：
这会造成一种依赖关系，你得不断让 AI 来解决问题，而没有培养出自己处理问题的专业知识。
知识鸿沟
最成功的非工程师会用混合模式来使用人工智能编码工具：
用人工智能进行快速原型设计
花时间了解生成代码的工作原理
除了学习人工智能的使用方法外，还学习基本的编程概念
逐步掌握基础知识
将 AI 用作学习工具，而不仅仅是代码生成器
但这需要耐心，需要投入——这与许多人最初希望通过用人工智能工具来实现的目标完全相反。
对未来的影响
这个“70%的问题”表明，当前的AI编码工具最好看作是：
但它们还不是许多人所希望的编码大众化的解决方案。那最后的 30%——让软件实现生产级、可维护以及变得强大的部分——仍然需要掌握真正的工程知识。
好消息是，随着工具的改进，这个鸿沟可能会缩小。但目前，最务实的方法是用人工智能来加速学习，而不能完全取代。
真正有效的方法：实用模式
在观察了几十支团队之后，我发现以下是一直有效的做法：
1.“AI初稿”模式 2.“持续对话”模式 3.“信任但要核实”模式 展望未来：人工智能的真正未来？
尽管面临种种挑战，我仍对人工智能在软件开发中的作用持乐观态度。关键是要了解其真正用途：
加速已知的事情
人工智能擅长帮我们实现已经理解的模式。就像拥有一位无比耐心、打字速度极快的编程搭子。
探索可能性
人工智能非常适合快速开发原型，探索不同的方法。它就像一个沙箱，我们可以在里面快速测试概念。
自动化日常工作
人工智能大大减少了花在样板与常规编码任务上的时间，让我们可以专注于有趣的问题。
这对你意味着什么？
如果你刚刚开始做 AI 辅助开发，以下是我的建议：
小处做起 保持模块化 相信你的经验 智能体类软件工程的兴起
随着我们迈向 2025 年，人工智能辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们开发原型和迭代的方式，但我相信我们正处于一个更为重大的转变的风口浪尖：软件工程智能体的兴起。
我所说的“智能体”是什么意思？这些系统不仅可以响应提示，还可以愈发自主地对解决方案进行规划、执行以及迭代。
我们已经看到这种演变的早期迹象：
从响应者到合作者
当前的工具大多都要等待我们的命令。不过看看像Claude 的Anthropic计算机使用，或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是锦上添花式的自动补全功能 – 而是在理解任务并主动解决问题。
就拿调试来说吧：这些智能体不仅可以给出修复建议，还可以：
多模态的未来
下一代工具可能不仅仅能处理代码——还可以无缝集成：
这种多模态能力意味着它们可以像人类一样理解和使用软件——全面地，而不仅仅是在代码层面。
自主但有指导
使用这些工具我得到一个关键洞察是，未来不是人工智能取代开发者，而是人工智能成为一个越来越有能力的合作者，能够采取主动行动，同时仍然尊重人类的指导和专业知识。
2025 年最高效的团队也许是掌握以下技能的那些：
英语优先的开发环境
就像 Andrej Karpathy所说那样：
英语正成为最热门的新编程语言。
这是我们与开发工具交互方式的根本性转变。清晰思考以及用自然语言准确沟通的能力正变得跟传统编码技能一样重要。
这种向智能体开发的转变要求我们提高技能：
软件作为一门手艺的回归？
虽然人工智能令快速开发软件变得比以往任何时候都要容易，但我们却面临着失去某个重要东西的风险，那就是创造真正精致的、消费者品质体验的艺术。
演示级质量的陷阱
这正在成为一种模式：团队用人工智能快速开发出令人印象深刻的演示。这条通往快乐的道路似乎一路坦途。投资者和社交网络都惊叹不已。但当真正的用户开始点击时，事情才开始崩溃。
我亲眼见过这样的事：
这些不仅仅是 P2 级的bug – 那是能容忍的软件与喜爱的软件之别。
失传的精细化艺术
打造真正的自助式软件（也就是用户完全无需联系支持人员的那种软件），需要一种与众不同的思维方式：
这种对细节的关注（或许）是 AI 生成不了的。这源于共情、经验以及对这门手艺的深切热爱。
个人软件的复兴
我相信我们将看到个人软件开发的复兴。随着市场充斥着人工智能生成的 MVP，具有以下特征的开发者开发出来的产品将脱颖而出：
讽刺的是，人工智能工具其实有可能会推动这一复兴。通过接手常规编码任务，它们让开发者可以专注于最重要的事情——开发真正服务于用户并让用户满意的软件。
总结
AI 并没有让我们的软件显著变好，因为软件质量（或许）从来就不是由编码速度决定的。软件开发最困难的部分——理解需求、设计可维护的系统、处理边缘情况、确保安全性和性能——仍然需要人类的判断。
AI 真正的作用在于让我们能够更快地迭代和试验，从而通过快速探索找到更优的解决方案。但这只有在我们坚持工程规范、将 AI 视为工具而非取代良好软件实践时才能实现。
记住：目标不是更快地写出更多的代码，而是开发出更好的软件。如果合理使用，AI 确实可以帮助我们做到这一点。但最终，我们仍需要明确什么是“更好”，以及如何实现它。
译者：boxi。
还没有评论，来说两句吧...