过去几年里，我一直在研究 AI 辅助开发工具，其中观察到了一个有趣的现象：虽然很多工程师称有了 AI 的帮助，他们的工作效率得到了大幅提升，但我们日常使用的软件似乎并没有因这些工程师的正反馈而在质量上有显著改进。

这是怎么回事呢？

我想我知道原因，并且这个答案揭示了一些关于软件开发的基本真相，这些是我们必须面对的。让我分享一下我的见解。


开发者实际上是如何使用 AI 的？

我观察到许多团队在开发中利用 AI 主要有两种不同的模式。我们可以称之为“引导者”和“迭代者”。两者都在帮助工程师（甚至是非技术人员）缩短从想法到执行（或最小可行产品，MVP）的时间。以下是这两种模式：


引导程序：从 0 到 MVP

像 Bolt、v0 以及截图转代码的 AI 工具正在彻底改变我们创建新项目的方式。这些团队通常：

从设计阶段或者仅有一个粗略的概念阶段就开始用 AI 工具

使用 AI 生成完整的初始代码库

在数小时或几天而不是几周内就获得可工作的程序原型

注重快速验证和迭代

结果令人印象深刻。我最近看到了一位独立开发者使用 Bolt 瞬间将一个 Figma 设计转换成了一个可工作的 Web 应用程序。虽然它还未能直接用于生产环境，但足以用来获得初步的用户反馈。

迭代者：日常开发

第二个阵营的开发者在日常开发流程中主要使用如 Cursor、Cline、Copilot 和 WindSurf 这样的工具。这虽然不如前者那么引人注目，但可能更具变革性。这些开发者：

利用 AI 进行代码补全和建议

借助 AI 完成复杂的重构任务

生成测试和文档

将 AI 作为“配对程序员”用于问题解决

然而，这里有一个陷阱：尽管这两种方法都能显著加速开发进程，但它们伴随着一些隐性成本问题。


“AI 速度”的隐性成本

当你看到资深工程师使用像 Cursor 或 Copilot 这样的 AI 工具工作时，总觉得他们会用魔法一样。他们可以在几分钟内搭建出包含测试和文档的整个功能模块。但仔细观察你会发现一个关键点：他们并不是简单地接受 AI 的建议。实际上，他们一直在：

将生成的代码重构为更小、更集中的模块

处理 AI 遗漏的边缘情况

加强类型定义和接口

审视 AI 提供的架构决策

增加全面的错误处理

换句话说，他们在应用多年积累下来的工程智慧之际进一步塑造和限制 AI 的输出。AI 加速了他们的实现过程，而他们的专业知识确保了代码的可维护性。

初级工程师往往忽略了这些重要的步骤。他们更容易接受 AI 的输出，导致我称之为“纸牌屋代码”的现象——它看似完整，但在现实压力下却不堪一击。


知识悖论

我发现最违反直觉的一件事是：AI 工具对有经验的开发者帮助更大，而非初学者。这似乎与我们的预期相反——难道 AI 不应该让编程变得更加民主化吗？

现实情况是，AI 就像团队中非常热心的初级开发人员。他们可以快速编写代码，但需要持续的监督和纠正。你了解得越多，就越能更好地指导他们。

这就产生了我所说的“知识悖论”：

资深工程师利用 AI 加速他们已经知道如何做的事情

初级工程师尝试使用 AI 来学习该做什么

因此结果大相径庭。

我目睹过很多资深工程师使用 AI 来：

快速制作他们已经理解的原型想法

生成基本实现，然后进一步优化

探索已知问题的替代方案

自动执行常规编码任务

与此同时，初级工程师常常：

接受不正确或过时的解决方案

忽略软件中关键的安全性和性能

在调试 AI 生成的代码时遇到困难

构建他们并不完全理解的脆弱系统


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

最近有一条推文完美地总结了我在这一领域观察到的现象：非工程师使用 AI 进行编程时，发现自己遇到了令人沮丧的障碍。他们能够以惊人的速度完成 70% 的工作，但最后的 30% 却变成了边际效益递减的练习。


这个“70% 问题”揭示了当前 AI 辅助开发状态下的一个关键事实。你使用时，初期的进展感觉像是魔法——你可以描述你想要的东西，像 v0 或 Bolt 这样的 AI 工具会生成一个看起来令人印象深刻的可工作程序原型。但随后很多现实问题就开始显现。

两步后退模式

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

你尝试修复一个小 bug

AI 给出了一个看似合理的更改建议

但这个修复却破坏了其他东西

你再请求 AI 修复新出现的问题

这又产生了其他两个新的问题

如此循环往复

对于非工程师来说，遇到这个循环尤为痛苦，因为他们缺乏理解实际发生错误的思维模型。当有经验的开发者遇到 Bug 时，他们可以根据多年积累的经验来推断潜在的原因和解决方案。如果没有这种技术背景知识，你基本上是在处理你不完全理解的代码，就像是在玩打地鼠游戏一样。

持续的学习悖论

这里有一个更深层次的问题：本来 AI 编程工具是对非工程师而言，是一个简单方便使用的东西——因为它们为你处理复杂性问题——然而，实际上它们可能会影响非工程师的自学能力。当代码只是“出现”，而你并不理解其背后的原则时：

你不会培养出调试技能

你错过了学习基本模式的机会

你无法推理架构决策

你在维护和演化代码方面会遇到重重困难

这会产生一种依赖关系，你需要不断地将你遇到的问题提交给 AI 工具，不断地询问 AI 工具的建议，而不是自己培养处理这些问题的专业知识。

知识差距

我见过成功的非工程师使用 AI 编程工具的方法是采取一种混合策略：

使用 AI 进行快速原型设计

花时间理解生成的代码如何工作

在使用 AI 的同时学习基本编程概念

逐步建立知识基础

将 AI 作为学习工具，而不仅仅是代码生成器

但这需要耐心和奉献精神——这正是许多人希望通过使用 AI 工具所避免的东西。

对未来的影响

这个“70% 的问题”表明，目前的 AI 编程工具最适合被看作是：

有经验的开发者的原型加速器

对于那些致力于理解开发的人来说的学习辅助工具

快速验证想法的 MVP 生成器

然而，它们还不是许多人所期望的编码民主化解决方案。最后的 30%——使软件达到生产就绪、可维护和健壮的部分——仍然需要真正的工程知识。

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


实际有效的方法：使用 AI 工具的实用模式

在观察了数十个团队之后，我发现以下方法始终奏效：

1. “AI 初稿”模式

让 AI 生成一个基本实现

手动审查并重构模块化

添加全面的错误处理

编写详尽的测试

文档化关键决策

2. “持续对话”模式

为每个不同的任务开始新的 AI 聊天

保持上下文聚焦且最小化

经常审查和提交更改

维持紧密的反馈循环

3. “信任与验证”模式

使用 AI 进行初始代码生成

所有关键路径的手动审查

边缘情况的自动化测试

定期的安全审计


展望未来：AI 的真正前景？

尽管存在这些挑战，我对 AI 在软件开发中的角色持乐观态度。关键是了解它的真正优势所在：

加速已知的事物

AI 擅长帮助我们实现已经理解的模式。就像拥有一个可以快速打字且很有耐心的配对程序员。

探索可能性

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

自动化常规事务

AI 大大减少了花费在样板代码和常规编码任务上的时间，让我们能够专注于有趣的问题。


这对你而言，意味着什么？

如果你刚开始尝试使用 AI 辅助开发，这里有几点建议：

从小处着手

将 AI 用于孤立的、定义清晰的任务。

仔细审查每一行生成的代码。

逐步扩展到更大的功能。

保持模块化

将所有内容分解为小型、专注的文件。

在组件之间保持清晰的接口。

为模块边界撰写文档。

相信你的经验

使用 AI 来加速而非替代你的判断力。

对那些“感觉不对”的生成代码保持质疑。

始终坚持你的工程标准。


代理软件工程的兴起

随着我们迈向 2025 年，AI 辅助开发的格局正在发生剧烈变化。目前的工具已经改变了我们原型开发和迭代的方式，但我相信我们正站在一个更大变革的门槛上：代理软件工程的兴起。


我所说的“代理”是什么意思？这些系统不仅可以响应提示，还可以以越来越高的自主性来规划、执行和迭代解决方案。

我们已经看到了这种演进的初步迹象：

从响应者到协作者

当前的大多数工具主要是在等待我们的指令。然而，看看一些新功能，比如 Anthropic 的 Claude 中的计算机使用能力，或 Cline 自动启动浏览器并运行测试的功能。这些工具不仅仅是“高级自动补全”，它们实际上能够理解任务并主动解决问题。

以调试为例，与其只是建议修复方案，这些智能体还可以：

主动识别潜在问题

启动并运行测试套件

检查 UI 元素并捕获截图

提出并实施修复方案

验证解决方案是否有效（这可能是个重大突破）

多模态的未来

下一代工具可能不仅仅限于代码合作，它们可能会无缝整合：

视觉理解（UI 截图、原型图、流程图）

语言交流（与人类的自然语言对话）

环境交互（浏览器、终端、API）

这种多模态能力意味着工具可以像人类一样以整体视角理解并处理软件，而不仅仅局限于代码层面。

自主但可引导

从与这些工具的合作中，我获得的一个关键见解是，未来并不是 AI 取代开发者，而是 AI 成为一个能力日益增强的协作者——它能够主动承担任务，同时仍尊重人类的引导和专业知识。


2025 年最有效的团队或许是那些能够做到以下几点的团队：

为 AI 智能体设定清晰的边界和指导原则

建立强大的架构模式，为智能体提供规范框架

创建有效的反馈循环，实现人类与 AI 能力的协同提升

在利用 AI 自主性的同时，保持人类的监督

“英语优先”的开发环境

正如 Andrej Karpathy 所言：

“英语正在成为最热门的新编程语言。”
这标志着我们与开发工具互动方式的根本性转变。清晰思考和精确表达自然语言的能力正变得与传统的编程技能同样重要。

这种面向智能体开发的转变要求我们不断提升自身技能：

更强的系统设计和架构思维

更好的需求规范和沟通能力

更加关注质量保障和验证

更注重人类与 AI 协作的优化


软件回归匠艺？

虽然 AI 让软件开发的速度前所未有地加快，但我们可能正在失去某些重要的东西——打造真正精致、符合消费者需求的软件体验的艺术。


“Demo 质量”陷阱

如今，这似乎已成一种模式：

团队利用 AI 快速构建出令人印象深刻的演示产品。理想路径运行得完美无缺，投资者和社交媒体赞不绝口。但当真实用户开始使用时呢？问题随之而来：

错误信息让普通用户完全无法理解

边界场景导致程序崩溃

混乱的 UI 状态没有清理干净

可访问性被完全忽略

在低性能设备上的运行问题

这些问题不仅仅是优先级较低的“小 bug”，它们决定了软件是让用户“勉强接受”还是“深深喜爱”。

精致的失落艺术

要创建真正的自动化的软件——用户无需联系支持即可顺畅使用的软件——需要开发团队以一种全新的心态来对待：

对错误信息的极致关注

在慢速网络连接上测试性能

优雅地处理每一个边界场景

确保功能易于发现

与真实用户（尤其是非技术用户）进行测试

这种对细节的关注（或许）是 AI 无法生成的。这源于同理心、经验，以及对工艺的深切热爱。

个人软件开发的复兴

我相信，个人软件开发即将迎来复兴。随着市场充斥着由 AI 生成的最低可行产品（MVP），那些脱颖而出的将是由以下开发者打造的产品：

为工艺感到自豪

注重每一个细节

聚焦于完整的用户体验

考虑到各种边界场景

打造真正的自助型体验

讽刺的是，AI 工具可能正是促成这种复兴的关键。通过处理常规编码任务，AI 为开发者腾出时间专注于最重要的事情——创建真正能服务并取悦用户的软件。


核心观点

AI 之所以没有显著提升软件质量，是因为软件质量的限制（或许）从来就不在编码速度上。

软件开发中真正困难的部分——理解需求、设计可维护的系统、处理边界场景、确保安全性和性能——这些依然需要人类的判断力。

AI 的作用在于让我们更快地迭代和实验，从而通过更快速的探索找到更好的解决方案。但这只有在我们保持工程纪律、将 AI 作为工具而非替代品的前提下才能实现。请记住：目标不是更快地写出更多代码，而是构建更好的软件。

如果运用得当，AI 可以帮助我们实现这一目标。但最终，我们仍需明确什么才是“更好”，以及如何实现它。

最后，你在 AI 辅助开发中有什么样的经验？