70% 困境：AI 辅助开发的残酷真相

原文链接：The 70% problem: Hard truths about AI-assisted coding

作者：Addy Osmani

作者信息：Google Chrome 团队成员，目前专注于浏览器性能领域，著作有：Learning JavaScript Design Patterns、Leading Effective Engineering Teams、Stoic Mind、Image Optimization 等

---

过去几年，我一直深度参与 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 辅助开发的一个关键点。最初的进展像魔法一样——你可以描述你想要的东西，AI 工具如 v0 或 Bolt 会生成一个看起来很令人印象深刻的工作原型。但随后你必须面对卡壳的现实。

两步回退模式

接下来通常会发生的事情一般是：

• 你试图修复一个小错误
• AI 提出一个看起来合理的更改
• 这个修复导致其他问题
• 你让 AI 修复新问题
• 这又引发了更多问题
• 如此反复

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

学习悖论的延续

这里有一个更深层次的问题：AI 编码工具对非工程师友好的特性（为你处理复杂性）实际上可能会阻碍学习。当代码”凭空出现”而你不理解背后原理时：

• 你不会精进你的 debug 技能
• 你错过了学习基本编程模式的机会
• 你无法独立做技术架构决策
• 你难以维护和改进代码

这就产生了一种依赖性，你需要不断回到 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 辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们原型和迭代的方式，但我相信我们正处于一个更重大变革的边缘：代理性（agentic）软件工程的崛起。

我所说的”代理性”是什么意思？这些系统不再只是响应提示，而是能够计划、执行和迭代解决方案，具有越来越高的自主性。

如果你对代理感兴趣，包括我对 Cursor/Cline/v0/Bolt 的看法，你可能会对我最近在 JSNation 的演讲 感兴趣。

我们已经看到了这种趋势的早期迹象：

从响应者到合作者

当前的工具大多在等待我们的命令。但看看像 Anthropic Claude 的计算机使用功能，或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是自动补全，它们实际上在理解任务并主动解决问题。

想象一下调试：这些代理不仅仅是提出修复建议，它们可以：

• 主动识别潜在问题
• 启动并运行测试套件
• 检查 UI 元素并捕获截图
• 提出并实施修复
• 验证解决方案是否有效（这可能是一个大问题）

多模态的未来

下一代工具可能不仅仅是处理代码——它们可以无缝集成：

• 视觉理解（UI 截图、原型、图表）
• 语言对话
• 环境交互（浏览器、终端、API）

这种多模态能力意味着它们可以像人类总揽全局地理解和处理软件，而不仅仅是在代码层面。

自主但受指导

我从与这些工具合作中获得的关键见解是，未来不是 AI 取代开发者，而是 AI 成为一个越来越有能力的合作者，能够在尊重人类指导和专业知识的同时采取主动行动。

2025 年最有效的团队可能是那些学会：

• 为他们的 AI 代理设定明确的边界和指南
• 建立强大的架构模式，使代理可以介入其中，一起工作
• 创建有效的人类和 AI 能力之间的反馈循环
• 在利用 AI 自主性的同时保持人类监督

英语优先的开发环境

正如 Andrej Karpathy 所指出的：

“英语正在成为最热门的新编程语言。”

这是我们与开发工具互动方式的根本转变。清晰思考和准确沟通的能力变得和传统编码技能一样重要。

这种向代理性开发的转变将要求我们升级我们的技能：

• 更强的系统设计和架构思维
• 更好的需求规范和沟通
• 更多关注质量保证和验证
• 增强的人类和 AI 能力之间的协作

软件作为技艺的回归？

虽然 AI 使得构建软件比以往任何时候都更容易，但我们有失去一些关键东西的风险——创造真正经过打磨的、高质量的艺术。

演示质量陷阱

这已经成为一种模式：团队使用 AI 快速构建令人印象深刻的演示。主干流程非常丝滑，投资者和社交网络都被惊艳到了。但当真正的用户开始点击时？那时问题就出现了。

我自己就遇到了这些情况：

• 对普通用户毫无意义的错误信息
• 导致应用崩溃的边界情况
• 从未清理的混乱 UI 状态
• 完全忽略的可访问性（Accessibility）
• 在较慢设备上的性能问题

正是这些看似低优先度的 bug 决定了用户是否喜欢这个软件。

失落的匠心

创建真正“自助”软件（用户永远不需要联系支持的那种）需要不同的思维模式：

• 认真处理所有错误信息
• 测试低速网络表现
• 优雅地处理每一个边界情况
• 使功能易于发现
• 与真正的（通常是不懂技术的）用户一起测试

这种关注细节的态度（也许）不能由 AI 生成。它来自同理心、经验和对技艺的深切关怀。

个人软件开发的复兴

我相信我们将看到个人软件开发的复兴。随着市场充斥着 AI 生成的 MVP，那些脱颖而出的产品将会是由这样的开发者构建的：

• 为他们的技艺感到自豪
• 关心细节
• 专注于完整的用户体验
• 为边界情况构建
• 创建真正的自助服务体验

但讽刺的是 AI 工具可能会促成这种复兴。通过由 AI 处理常规编码任务，让开发者能够专注于最重要的事情——创建真正服务和取悦用户的软件。

结论

AI 并没有使我们的软件质量显著提高，因为软件质量（也许）从来不是主要受编码速度限制的。软件开发的难点——理解需求、设计可维护的系统、处理边界情况、确保安全性和性能——仍然需要人类的判断。

AI 所做的是让我们更快地迭代和实验，可能通过更快速的探索导致更好的解决方案。但前提是我们保持我们的工程纪律，并将 AI 作为工具，而不是取代良好软件实践的替代品。记住：目标不是更快地编写更多代码，而是构建更好的软件。明智地使用 AI 可以帮助我们做到这一点。但最终，定义并做到”更好”的仍应是我们人类。

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