AI 辅助编程的 70% 难题：AI 辅助编程的挑战与思考
一份实地指南，以及我们为何需要重新思考对 AI 的期望
2024 年 12 月 4 日
在过去几年专注于 AI 辅助开发的过程中，我注意到一个有趣的现象。尽管工程师们报告说，在 AI 的帮助下，他们的生产力得到了显著提高，但我观察到的软件质量并没有显著改善。这是怎么回事？
我认为我已经找到了原因，它揭示了软件开发中一些必须面对的基本真相。让我分享一下我所学到的。
开发者如何实际使用 AI
我观察到团队利用 AI 进行开发时呈现出两种截然不同的模式，分别称为“引导者”和“迭代者”。这两种模式都在帮助工程师（甚至是非技术用户）更快地将想法转化为可实施的代码或最小可行产品（MVP）。
引导者：从零到 MVP
像 Bolt、v0 和 screenshot-to-code 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 生成的代码
-
构建他们不完全理解的脆弱系统
70% 难题：AI 学习曲线悖论
最近的一条 推文 准确地反映了我在该领域观察到的现象：非工程师使用 AI 进行编码时，会发现自己遇到了一堵令人沮丧的墙。他们可以非常迅速地完成 70% 的工作，但最后的 30% 却变成了收益递减的练习。
这个“70% 难题”凸显了当前 AI 辅助开发中的一个关键问题。最初的进展感觉很神奇——你可以描述你想要的东西，而像 v0 或 Bolt 这样的 AI 工具会生成一个看起来令人印象深刻的可工作原型。但随后现实就来了。
后退两步模式
接下来通常会发生的事情遵循一个可预测的模式：
-
你试图修复一个小 bug
-
AI 建议的更改看起来是合理的
-
这个修复破坏了其他东西
-
你要求 AI 修复新问题
-
这会产生更多的问题
-
不断重复
对于非工程师来说，这个循环尤其痛苦，因为他们缺乏理解实际问题的心理模型。当一位经验丰富的开发者遇到 bug 时，他们可以根据多年来对模式的识别来推断潜在的原因和解决方案。如果没有这种背景，你基本上就是在玩打地鼠游戏，而你并不完全理解这些代码。
学习悖论的延续
这里有一个更深层次的问题：使 AI 编码工具易于非工程师使用的原因——它们能够代表你处理复杂性——实际上会阻碍学习。当代码“出现”时，你并不理解其基本原理：
-
你没有培养调试技能
-
你错过了学习基本模式
-
你无法推断架构决策
-
你难以维护和发展代码
这会导致一种依赖性，使用者不得不频繁求助于 AI 来解决问题，而非逐步掌握解决这些问题的能力。例如，一个非工程师使用 AI 生成了一个网站，但当需要添加用户身份验证功能时，由于缺乏相关知识，他们不得不再次求助于 AI，即使只是一个小小的功能调整。这种依赖性使得许多用户未能掌握必要的编程技能，导致在遇到复杂问题时无法独立解决。
知识鸿沟
我所见过的最成功的使用 AI 编码工具的非工程师采用了一种混合方法：
-
使用 AI 进行快速原型设计
-
花时间理解生成的代码是如何工作的
-
在使用 AI 的同时学习基本的编程概念
-
逐步建立知识基础
-
将 AI 用作学习工具，而不仅仅是代码生成器
但这需要耐心和奉献精神，因为学习编程概念和深入理解生成代码的工作原理并非一朝一夕之功——这与许多人希望通过使用 AI 工具快速获得成果的期望相悖。
对未来的影响
这个“70% 难题”表明，当前的 AI 编码工具最好被视为：
-
经验丰富的开发者的原型加速器
-
致力于理解开发的学习辅助工具
-
快速验证想法的 MVP 生成器
但它们还不是许多人希望的编码民主化解决方案。最后的 30%——使软件达到可用于生产、可维护和健壮的水平的部分——仍然需要真正的工程知识。
值得注意的是，随着工具的改进，这个差距可能会缩小。但就目前而言，最务实的方法是使用 AI 来加速学习，而不是完全取代学习。
实际有效的方法：实用模式
在观察了数十个团队之后，以下是我看到持续有效的方法：
1. “AI 初稿”模式
-
让 AI 生成一个基本的实现
-
手动审查和重构，以实现模块化
-
添加全面的错误处理
-
编写全面的测试
-
记录关键决策
2. “持续对话”模式
-
为每个不同的任务启动新的 AI 聊天
-
保持上下文的专注和最小化
-
经常审查和提交更改
-
保持紧密的反馈循环
3. “信任但验证”模式
-
使用 AI 进行初始代码生成
-
手动审查所有关键路径
-
自动测试边界情况
-
定期进行安全审计
展望未来：AI 的真正承诺？
尽管存在这些挑战，但我对 AI 在软件开发中的作用持乐观态度。关键是要理解它真正擅长什么：
- 加速已知
AI 擅长帮助我们实现我们已经理解的模式。这就像拥有一个无限耐心的结对程序员，他们可以打字非常快。
- 探索可能性
AI 非常适合快速构建想法原型和探索不同的方法。这就像拥有一个沙箱，我们可以在其中快速测试概念。
- 自动化日常工作
AI 大大减少了在样板代码和日常编码任务上花费的时间，让我们能够专注于有趣的问题。
实践建议
对于刚刚接触 AI 辅助开发的读者，我有以下几点建议：
-
从小处着手
-
将 AI 用于孤立的、定义明确的任务
-
审查生成的每一行代码
-
逐步构建更大的功能
-
保持模块化
-
将所有内容分解为小的、专注的文件
-
保持组件之间清晰的接口
-
记录你的模块边界
-
相信你的经验
-
使用 AI 来加速，而不是取代你的判断
-
质疑感觉不正确的生成的代码
-
保持你的工程标准
智能软件工程的兴起
随着我们迈入 2025 年，AI 辅助开发的格局正迎来前所未有的变革。虽然当前的工具已经改变了我们构建原型和迭代的方式，但我相信我们正处于一个更重要的转型的前夕：智能软件工程的兴起。
我所说的“智能”是什么意思？这些系统不仅可以响应提示，还可以规划、执行和迭代解决方案，并具有越来越高的自主性。
如果你有兴趣了解更多关于智能体的信息，包括我对 Cursor/Cline/v0/Bolt 的看法，你可能会对我在 JSNation 上的演讲 感兴趣。
我们已经看到了这种演变的早期迹象：
从响应者到协作者
当前的工具大多等待我们的命令。但看看像 Anthropic 在 Claude 中的计算机使用（即AI能够像人类一样使用电脑完成复杂任务），或者 Cline 自动启动浏览器和运行测试的能力（意味着AI可以自主完成一些开发流程）等新功能。这些不仅仅是美化版的自动完成——它们实际上是在理解任务并主动解决问题。
想想调试：这些智能体不仅可以提出修复建议，还可以：
-
主动识别潜在问题
-
启动并运行测试套件
-
检查 UI 元素并捕获屏幕截图
-
提出并实施修复
-
验证解决方案是否有效（这可能意义重大）
多模态未来
下一代工具可能不仅仅是处理代码——它们可以无缝集成：
-
视觉理解（UI 屏幕截图、模型、图表）
-
口头语言对话
-
环境交互（浏览器、终端、API）
这种多模态能力意味着它们可以像人类一样理解和处理软件——整体地，而不仅仅是在代码层面。
自主但受指导
我从使用这些工具中获得的关键见解是，未来不是 AI 取代开发者——而是 AI 成为越来越有能力的协作者，他们可以在尊重人类指导和专业知识的同时主动采取行动。
2025 年最有效的团队可能是那些学会：
-
为他们的 AI 智能体设置明确的边界和指导方针
-
建立智能体可以在其中工作的强大的架构模式
-
在人类和 AI 能力之间创建有效的反馈循环
-
在利用 AI 自主性的同时保持人类监督
英语优先的开发环境
正如 Andrej Karpathy 指出的：
“英语正在成为最热门的新编程语言。” 这意味着，清晰地表达需求，并用自然语言与AI工具沟通，变得越来越重要。
这是我们与开发工具交互方式的根本转变。清晰地思考并以自然语言精确地沟通的能力正变得与传统的编码技能一样重要。
这种向智能开发的转变将要求我们发展我们的技能：
-
更强的系统设计和架构思维
-
更好的需求规范和沟通
-
更多地关注质量保证和验证
-
加强人类和 AI 能力之间的协作
软件作为工艺的回归？
虽然 AI 使构建软件比以往任何时候都更容易，但我们面临着失去一些关键的东西的风险——创造真正精致的、消费者质量体验的 艺术。
Demo 质量的陷阱
这正在成为一种模式：团队使用 AI 快速构建令人印象深刻的演示。快乐的路径运作良好。投资者和社交网络都惊叹不已。但是当真正的用户开始点击时呢？那时事情就崩溃了。
我亲眼目睹了这一点：
-
对普通用户来说毫无意义的错误消息
-
导致应用程序崩溃的边界情况
-
从未清理过的令人困惑的 UI 状态
-
完全被忽视的可访问性
-
较慢设备上的性能问题
这些不仅仅是 P2 级别的 bug——它们是人们容忍的软件和人们喜欢的软件之间的区别。
抛光艺术的失落
创建真正自助式的软件——用户永远不需要联系支持的那种——需要不同的心态：
-
痴迷于错误消息
-
在慢速连接上进行测试
-
优雅地处理每一个边界情况
-
使功能易于发现
-
与真正的、通常是非技术用户一起测试
这种对细节的关注（也许）无法由 AI 生成。它来自同情心、经验和对工艺的深刻关怀。
个人软件的复兴
我相信我们将看到个人软件开发的复兴。随着市场充斥着 AI 生成的 MVP，那些由以下开发者构建的产品将脱颖而出：
-
以他们的工艺为荣
-
关心小细节
-
专注于完整的用户体验
-
为边界情况而构建
-
创造真正自助式的体验
讽刺的是？AI 工具实际上可能会促成这场复兴。通过处理日常编码任务，它们使开发人员可以专注于最重要的事情——创建真正服务和取悦用户的软件。
总结
AI 并没有使我们的软件变得更好，因为软件质量（也许）从来没有主要受到编码速度的限制。软件开发的难点——理解需求、设计可维护的系统、处理边界情况、确保安全性和性能——仍然需要人为判断。但这仍然取决于我们知道“更好”意味着什么，例如可维护性、性能、安全性等，以及如何实现这些目标。
AI 所做的是让我们更快地迭代和实验，从而有可能通过更快速的探索来找到更好的解决方案。但这只有在我们保持我们的工程纪律并将 AI 用作工具，而不是替代良好的软件实践时才有可能。请记住：目标不是更快地编写更多代码。而是构建更好的软件。如果使用得当，AI 可以帮助我们做到这一点。但这仍然取决于我们知道“更好”意味着什么以及如何实现它。
你在 AI 辅助开发方面的经验是什么？我很乐意在评论中听到你的故事和见解。
（全文完）
作者：Addy Osmani