AI 编码的 70% 问题：关于 AI 辅助编程的残酷真相

原文来源：Elevate by Addy Osmani — AI 辅助编程能让工程师报告 productivity 大幅提升，但我们日常使用的软件似乎并没有因此变得更好。

过去几年深入观察 AI 辅助开发后，我发现了一个耐人寻味的现象。工程师们普遍声称 AI 让他们效率倍增，但我们每天使用的软件本身，似乎并没有因此发生质的飞跃。问题出在哪里？我认为答案揭示了软件开发中一些我们必须正视的基本真相。

开发者实际如何使用 AI

目前团队利用 AI 进行开发主要呈现两种模式，可以称之为"快速启动派"和"日常迭代派"。两者都在帮助工程师甚至非技术人员缩短从想法到可执行原型之间的距离。

快速启动派：从零到 MVP

Bolt、v0 和截图转代码等工具正在彻底改变项目启动方式。这些团队通常从设计稿或粗略概念出发，用 AI 生成完整的初始代码库，在几小时或几天内就能获得可工作的原型，而不是几周。重点是快速验证和迭代。我曾亲眼看到一位独立开发者用 Bolt 将 Figma 设计稿在极短时间内变成了可运行的 Web 应用。它并非生产就绪，但足以获取最早期的用户反馈。

日常迭代派：持续开发

另一派开发者使用 Cursor、Cline、Copilot 和 WindSurf 等工具融入日常工作流。这种方式不那么 flashy，但潜在影响更深远。他们用 AI 补全代码、处理复杂重构、生成测试和文档，把 AI 当作"结对编程伙伴"来解决问题。

但关键是：这两种方式虽然都能显著加速开发，却伴随着不那么显而易见的隐性成本。

"AI 速度"的隐性成本

当你观察资深工程师使用 Cursor 或 Copilot 时，那看起来像魔术。他们能在几分钟内搭建完整功能，附带测试和文档。但仔细看，你会发现一个关键事实：他们并非全盘接受 AI 的建议，而是在持续地做以下事情：

将生成的代码重构为更小、更聚焦的模块
补充 AI 遗漏的边界情况处理
强化类型定义和接口约束
质疑架构决策的合理性
添加全面的错误处理

换句话说，他们正在将多年积累的工程智慧应用于塑造和约束 AI 的输出。AI 加速的是实现过程，但工程师的经验才是保证代码可维护的关键。

初级工程师往往缺失这些关键步骤。他们更容易全盘接受 AI 的输出，导致我称之为"纸牌屋代码"的现象——看起来完整，但在真实压力下会崩塌。

知识悖论

我发现的最反直觉事实是：AI 工具对经验丰富的开发者帮助更大，而非初学者。这看似荒谬——AI 不是要民主化编程吗？

现实是，AI 就像一个非常积极的初级开发者。他们能快速写代码，但需要持续监督与修正。你懂的越多，引导他们的能力就越强。

这形成了我所说的"知识悖论"：

资深者用 AI 加速自己本就会做的事
初级者试图用 AI 学习自己尚不懂的事
结果天差地别

资深工程师用 AI 快速原型化已理解的想法、生成基础实现后手动精修、探索已知问题的替代方案、自动化常规编码任务。而初级工程师往往接受错误或过时的方案、忽略关键安全与性能考量、 struggle to debug AI 生成的代码、构建自己无法理解的脆弱系统。

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

一条推文精准地捕捉了我在实地观察到的现象：非工程师用 AI 编程时会撞上一堵令人沮丧的墙。他们能惊人地快速完成 70%，但最后 30% 变成了边际收益递减的折磨。

这个"70% 问题"揭示了 AI 辅助开发的当前本质。初期进展感觉像魔术——你描述想要什么，v0 或 Bolt 就会生成看起来令人印象深刻的工作原型。然后现实降临了。

"前进两步、后退两步"的循环

接下来通常遵循一个可预测的模式：

你尝试修复一个小 bug。AI 给出了看似合理的修改。这个修复却破坏了其他东西。你让 AI 修复新问题。这又引发了更多问题。如此循环往复。

这个循环对非工程师尤其痛苦，因为他们缺乏理解问题本质的心智模型。当资深开发者遇到 bug 时，他们能基于多年积累的模式识别来推理潜在原因和解决方案。没有这种背景，你基本上就是在对你无法完全理解的代码玩打地鼠。

学习悖论的持续

这里有一个更深层次的问题：让 AI 编码工具对非工程师如此 accessible 的特性——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 辅助开发的格局正在剧烈转变。虽然当前工具已经改变了原型和迭代方式，我相信我们正处于更重大变革的前夜：智能体软件工程的崛起。

"智能体"指的是：这些系统不仅能响应提示，还能规划、执行并以越来越高的自主性迭代解决方案。

我们已经在看到这个演变的早期迹象：

从响应者到协作者

当前工具大多等待我们的命令。但看看 Anthropic 的 Computer Use 或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是 glorified 自动补全——它们实际上理解任务并主动采取解决问题的行动。

想想调试：这些智能体不仅能建议修复，还能主动识别潜在问题、启动并运行测试套件、检查 UI 元素并截图、提议并实施修复、验证解决方案有效。

多模态未来

下一代工具可能不仅处理代码，还能无缝整合视觉理解（UI 截图、线框图、图表）、自然语言对话、环境交互（浏览器、终端、API）。这种多模态能力意味着它们能像人类一样 holistically 理解软件，而不仅仅在代码层面。

自主但受引导

我与这些工具合作获得的关键洞察是：未来不在于 AI 替代开发者，而在于 AI 成为能力越来越强的协作者，能在尊重人类指导和专业知识的同时主动采取行动。

2025 年最有效的团队可能是那些学会为 AI 智能体设定清晰边界和指南、建立智能体能在其中工作的强架构模式、创建人类与 AI 能力间有效反馈循环、在利用 AI 自主性的同时保持人类监督的团队。

英语优先的开发环境

正如 Andrej Karpathy 所言："英语正在成为最热门的新编程语言。"

这是与开发工具交互的根本性转变。用自然语言清晰思考和精确沟通的能力，正变得与传统编码技能同等重要。

这种向智能体开发的转变要求我们进化技能：

更强的系统设计和架构思维
更好的需求规格和沟通能力
更聚焦质量保证和验证
增强人类与 AI 能力的协作

软件作为手艺的回归？

虽然 AI 让快速构建软件变得前所未有的容易，但我们正处于失去某种关键东西的风险中——创造真正精致、消费者级体验的艺术。

Demo 质量陷阱

一个模式正在形成：团队用 AI 快速构建令人印象深刻的 Demo。Happy path 运行完美。投资者和社交网络被震撼。但当真实用户开始四处点击时？事情就崩了。

我亲眼见过：对普通用户毫无意义的错误信息、导致应用崩溃的边界情况、从未清理的混乱 UI 状态、完全被忽视的无障碍性、慢速设备上的性能问题。这些不只是 P2 bug——它们是人们容忍的软件与人们喜爱的软件之间的分水岭。

失落的打磨艺术

创造真正的自助服务软件——那种用户永远不需要联系支持的软件——需要不同的心态：

痴迷于错误信息的质量
在慢速连接下测试
优雅处理每一个边界情况
让功能可被发现
用真实的、通常是非技术的用户测试

这种对细节的专注（可能）无法被 AI 生成。它来自同理心、经验和对工艺的深度关怀。

个人软件的复兴

我相信我们将看到个人软件开发的复兴。当市场被 AI 生成的 MVP 淹没时，脱颖而出的产品将来自那些：

对自己的工艺感到自豪
关注小细节
聚焦完整用户体验
为边界情况构建
创造真正自助服务的体验

讽刺的是？AI 工具实际上可能促成这种复兴。通过处理常规编码任务，它们解放了开发者去专注于最重要的事——创造真正服务并愉悦用户的软件。

底线

AI 并没有让我们的软件戏剧性地变好，因为软件质量（可能）从来就不主要受编码速度限制。软件开发的难点——理解需求、设计可维护的系统、处理边界情况、确保安全与性能——仍然需要人类判断。

AI 真正做的是让我们更快地迭代和实验，通过更快速的探索潜在地导向更好的解决方案。但这只有在当我们维持工程纪律、把 AI 当作工具而非良好实践的替代品时才能实现。

记住：目标不是更快地写更多代码。而是构建更好的软件。明智地使用，AI 能帮助我们做到。但知道什么是"更好"以及如何实现它，仍然取决于我们自己。