70% 问题：关于 AI 辅助编码的残酷真相
文章信息
Origin url : https://addyo.substack.com/p/the-70-problem-hard-truths-about
written by Addy Osmani in 2024.12.5
translated & reprinted by Bolaxious in 2025.2.5
一份实地指南，以及为什么我们需要重新思考我们的期望
在过去几年沉浸在 AI 辅助开发中后，我注意到了一个有趣的现象。虽然工程师们报告说使用 AI 后效率显著提高，但我们日常使用的软件似乎并没有明显变得更好。这是为什么呢？
我想我知道原因，而这个答案揭示了一些我们需要面对的软件开发基本真相。让我分享我的所学。
开发者实际上是如何使用 AI 的
我观察到团队在利用 AI 进行开发时有两种不同的模式。让我们称它们为"引导者"和"迭代者"。这两种方式都在帮助工程师（甚至非技术用户）缩小从想法到执行（或 MVP）的差距。
引导者：从零到 MVP
像 Bolt、v0 和截图转代码 AI 这样的工具正在彻底改变我们引导新项目的方式。这些团队通常：
- 从设计或粗略概念开始
- 使用 AI 生成完整的初始代码库
- 在几小时或几天内（而不是几周）获得一个可工作的原型
- 专注于快速验证和迭代
结果可能令人印象深刻。我最近看到一个独立开发者使用 Bolt 在很短的时间内将 Figma 设计转换成了一个可工作的网络应用。虽然还不能用于生产环境，但足以获得最初的用户反馈。
迭代者：日常开发
第二类使用 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% 变成了一个收益递减的练习。
两步后退模式
接下来通常会发生的事情遵循一个可预测的模式：
- 你试图修复一个小 bug
- AI 建议一个看似合理的更改
- 这个修复破坏了其他东西
- 你要求 AI 修复新问题
- 这又创造了两个问题
- 如此循环
这个循环对非工程师来说特别痛苦，因为他们缺乏理解实际问题的心智模型。当有经验的开发者遇到 bug 时，他们可以基于多年的模式识别来推理潜在的原因和解决方案。没有这种背景，你实际上是在与你不完全理解的代码玩打地鼠游戏。
学习悖论的延续
这里有一个更深层的问题：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 中的计算机使用，或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是高级的自动完成——它们实际上在理解任务并主动解决问题。
想想调试：这些代理不仅仅是建议修复，它们可以：
- 主动识别潜在问题
- 启动并运行测试套件
- 检查 UI 元素并捕获截图
- 提出并实施修复
- 验证解决方案是否有效（这可能是一个重大突破）
多模态的未来
下一代工具可能不仅仅是处理代码——它们可能无缝集成：
- 视觉理解（UI 截图、模型、图表）
- 口语对话
- 环境交互（浏览器、终端、API）
这种多模态能力意味着它们可以像人类那样全面地理解和处理软件，而不仅仅是在代码层面。
自主但受引导
从使用这些工具中获得的关键见解是，未来不是关于 AI 取代开发者——而是关于 AI 成为一个越来越有能力的协作者，可以在尊重人类指导和专业知识的同时采取主动。
2025 年最有效的团队可能是那些学会：
- 为他们的 AI 代理设置清晰的边界和指导原则
- 建立代理可以在其中工作的强大架构模式
- 在人类和 AI 能力之间创建有效的反馈循环
- 在利用 AI 自主性的同时维持人类监督
英语优先的开发环境
正如 Andrej Karpathy 所说：
"英语正在成为最热门的新编程语言。"
这是我们与开发工具交互方式的根本转变。用自然语言清晰思考和精确沟通的能力变得与传统编码技能一样重要。
这种向主动式开发的转变将要求我们发展我们的技能：
- 更强的系统设计和架构思维
- 更好的需求规范和沟通
- 更关注质量保证和验证
- 增强人类和 AI 能力之间的协作
软件作为工艺的回归？
虽然 AI 使构建软件变得比以往任何时候都更容易，但我们正面临失去一些关键东西的风险——创造真正精致、消费级体验的艺术。
演示质量陷阱
这正在成为一种模式：团队使用 AI 快速构建令人印象深刻的演示。主要路径运行得很完美。投资者和社交网络都被震惊了。但当真实用户开始四处点击时？这就是问题开始显现的时候。
我亲眼目睹了这些：
- 对普通用户毫无意义的错误消息
- 导致应用崩溃的边缘情况
- 从未被清理的混乱 UI 状态
- 完全被忽视的可访问性
- 在较慢设备上的性能问题
这些不仅仅是 P2 级别的 bug——它们是人们容忍的软件和人们喜爱的软件之间的区别。
失落的精雕细琢之艺
创建真正的自助服务软件——用户永远不需要联系支持的那种——需要一种不同的思维方式：
- 对错误消息的执着追求
- 在慢速连接上测试
- 优雅地处理每个边缘情况
- 使功能易于发现
- 与真实的、通常是非技术用户一起测试
这种对细节的关注（也许）不能由 AI 生成。它来自于同理心、经验和对工艺的深切关注。
个人软件的复兴
我相信我们将看到个人软件开发的复兴。随着市场被 AI 生成的 MVP 淹没，脱颖而出的产品将是那些由以下开发者构建的：
- 以他们的工艺为荣
- 关注小细节
- 专注于完整的用户体验
- 为边缘情况构建
- 创造真正的自助服务体验
讽刺的是？AI 工具实际上可能促成这种复兴。通过处理常规编码任务，它们让开发者能够专注于最重要的事情——创造真正服务和取悦用户的软件。
结论
AI 没有使我们的软件显著变好，因为软件质量（也许）从来就不是主要受限于编码速度。软件开发的难点——理解需求、设计可维护的系统、处理边缘情况、确保安全和性能——仍然需要人类的判断。
AI 确实让我们能够更快地迭代和实验，通过更快的探索可能导致更好的解决方案。但只有在我们保持工程纪律并将 AI 作为工具而不是替代良好软件实践的情况下才能实现。记住：目标不是更快地写更多代码。而是构建更好的软件。明智地使用 AI 可以帮助我们做到这一点。但"更好"意味着什么以及如何实现它仍然取决于我们。