70% 完成度陷阱：AI 辅助编码的最后 30% 挑战

在过去几年深入参与 AI 辅助开发后，我注意到一个有趣的现象。尽管工程师们报告说使用 AI 大幅提高了生产力，但我们日常使用的实际软件似乎并没有明显改善。这是怎么回事？

我想我知道原因，答案揭示了我们需要面对的关于软件开发的一些基本事实。让我分享一下我的发现。

开发人员如何实际使用 AI

我观察到团队在利用 AI 进行开发时有两种不同的模式。我们称它们为“引导者”和“迭代者”。两者都在帮助工程师 (甚至非技术用户) 缩小从想法到执行 (或 MVP) 的差距。

引导者：从零到 MVP

像 Bolt、v0 和 screenshot-to-code 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 生成的代码
• 构建他们并不完全理解的脆弱系统

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

最近引起我注意的一条推文完美地捕捉了我在该领域观察到的情况：使用 AI 进行编码的非工程师发现自己遇到了令人沮丧的障碍。他们可以以惊人的速度完成 70%，但最后 30% 变成了收益递减的练习。

这个“70% 问题”揭示了关于 AI 辅助开发当前状态的一些关键信息。最初的进展感觉很神奇——你可以描述你想要什么，像 v0 或 Bolt 这样的 AI 工具会生成一个看起来令人印象深刻的工作原型。但随后现实开始了。

两步倒退模式

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

• 你尝试修复一个小错误
• AI 建议了一个看起来合理的更改
• 这个修复破坏了其他东西
• 你要求 AI 修复新问题
• 这又产生了两个问题
• 如此反复

这个循环对于非工程师来说尤其痛苦，因为他们缺乏理解实际上出了什么问题的思维模型。当有经验的开发人员遇到错误时，他们可以根据多年的模式识别来推断潜在的原因和解决方案。如果没有这种背景，你本质上是在玩你不完全理解的代码的打地鼠游戏。

学习悖论的延续

这里有一个更深层次的问题：使 AI 编码工具对非工程师易于使用的东西——它们代表你处理复杂性的能力——实际上会阻碍学习。当代码“出现”而你不理解底层原理时：

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

这造成了一种依赖性，你需要不断地回到 AI 来解决问题，而不是发展自己处理这些问题的专业知识。

知识差距

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

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

但这需要耐心和奉献精神——这与许多人希望通过使用 AI 工具实现的目标恰恰相反。

对未来的影响

这个“70% 问题”表明当前的 AI 编码工具最好被视为：

• 经验丰富的开发人员的原型加速器
• 致力于理解开发的人员的学习辅助工具
• 快速验证想法的 MVP 生成器

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

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

实际有效的方法：实用模式

在观察了数十个团队后，以下是我看到的一贯有效的方法：

1. “AI 初稿”模式

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

2. “持续对话”模式

• 为每个不同的任务启动新的 AI 聊天
• 保持上下文专注和最小化
• 经常审查和提交更改
• 保持紧密的反馈循环

3. “信任但验证”模式

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

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

尽管存在这些挑战，但我对 AI 在软件开发中的作用持乐观态度。关键是要了解它真正擅长什么：

1. 加速已知
   AI 擅长帮助我们实现我们已经理解的模式。这就像有一个无限耐心的结对程序员，他可以非常快地打字。
2. 探索可能
   AI 非常适合快速原型化想法和探索不同的方法。这就像有一个沙盒，我们可以在其中快速测试概念。
3. 自动化常规
   AI 极大地减少了花在样板和常规编码任务上的时间，让我们专注于有趣的问题。

这对你意味着什么？

如果你刚刚开始使用 AI 辅助开发，以下是我的建议：

1. 从小处着手
   • 将 AI 用于孤立的、定义明确的任务
   • 审查每一行生成的代码
   • 逐步构建更大的功能
2. 保持模块化
   • 将所有内容分解为小的、专注的文件
   • 在组件之间保持清晰的接口
   • 记录你的模块边界
3. 相信你的经验
   • 使用 AI 来加速，而不是取代你的判断
   • 质疑感觉不对的生成代码
   • 保持你的工程标准

代理软件工程的兴起

当我们进入 2025 年时，AI 辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们原型化和迭代的方式，但我相信我们正处于一个更重要的转变的风口浪尖：代理软件工程的兴起。

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

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

我们已经看到了这种演变的早期迹象：

从响应者到协作者

当前的工具主要等待我们的命令。但看看更新的功能，比如 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 可以帮助我们做到这一点。但了解“更好”的含义以及如何实现它仍然取决于我们。

你在 AI 辅助开发方面的经验如何？我很想在评论中听到你的故事和见解。