原文：https://addyo.substack.com/p/the-70-problem-hard-truths-about
作者：Addy Osmani
译者：ChatGPT 4 Turbo
编者注：虽然工程师们声称 AI 大幅提高了生产力，但软件质量并未明显改善。1) AI 让开发者能快速达到 70% 的完成度，但剩下 30% 的边界场景和质量提升反而更难； 2) AI 对有经验的开发者帮助更大，他们知道如何 Review 和改进 AI 生成的代码，而初学者容易直接采用可能存在问题的代码； 3) AI 擅长加速已知模式的实现，但软件开发中最难的部分（需求理解、系统设计、安全性等）仍需要人工判断。作者认为 AI 应该被视为工具而非替代品，未来最成功的团队将是那些既善用 AI 又注重软件工艺的团队。
在过去几年深入 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% 则变成了收益递减的努力。
这个“70% 的问题”揭示了一个关于目前 AI 辅助开发状态的关键事实。最初的进展感觉像是魔法 – 你可以描述你想要的内容，像 v0 或 Bolt 这样的 AI 工具会生成一个看起来令人印象深刻的工作原型。但随后现实就降临了。
后退两步的模式
接下来通常会遵循一个可预测的模式：
- 你尝试修复一个小错误
- 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 加速决策，而不是替换你的判断
- 对感觉不对的生成代码提出疑问
- 维护你的工程标准
Agent 软件工程的兴起
随着我们走向 2025 年，AI 辅助开发的景观正在发生剧烈的变化。虽然当前的工具已经改变了我们的原型设计和迭代方式，但我相信，我们正处于一个更为重大转变的边缘：Agent 软件工程的兴起。
我说的 “Agent” 是什么意思？这些系统不仅仅是对提示做出响应，它们可以规划、执行并以增加的自主性迭代解决方案。
_如果你对 Agent 感兴趣，包括我的关于 Cursor/Cline/v0/Bolt 的看法，你可能会对我[最近的 JSNation 演讲](
我们已经看到这种演变的早期迹象：
从响应者到合作者
当前的工具大多是等待我们的命令。但是看看像 Anthropic 在 Claude 中使用计算机，或者 Cline 能够自动启动浏览器和运行测试这样的新功能。这些不仅仅是增强的自动完成——它们实际上是在理解任务并主动解决问题。
想一想调试：这些 Agent 不仅仅是提出修复方案，它们还可以：
- 主动识别潜在问题
- 启动并运行测试套件
- 检查 UI 元素并捕获屏幕截图
- 提出并实施修复方案
- 验证解决方案是否有效（这可能是一个大问题）
多模态的未来
下一代工具可能不仅仅与代码打交道 – 它们可能会无缝整合：
- 视觉理解（UI 屏幕截图、模型图、图表）
- 口头语言对话
- 环境交互（浏览器、终端、API）
这种多模态能力意味着它们可以像人类一样，全面地理解和处理软件，而不仅仅是在代码层面。
自主但受指导
我从使用这些工具中获得的关键见解是，未来并不是关于 AI 替代开发者 – 而是关于 AI 成为一个越来越能够主动采取行动的合作者，同时仍然尊重人类的指导和专业知识。
到 2025 年，最有效的团队可能是那些学会：
- 为他们的 AI Agent 设置清晰的界限和指导方针
- 建立强大的架构模式，使 Agent 可以在其中工作
- 在人类和 AI 能力之间创建有效的反馈循环
- 在利用 AI 自主性的同时保持人类的监督
英文优先的开发环境
正如 Andrej Karpathy 所指出的：
“英语正在成为最热门的新编程语言。”
这是我们与开发工具互动方式的一次根本性转变。能够清晰思考并在自然语言中准确交流的能力变得和传统的编码技能一样重要。
向着能动发展的转变将要求我们进化我们的技能：
- 更强的系统设计和架构思维
- 更好的需求说明和沟通
- 更加注重质量保证和验证
- 加强人类和 AI 能力之间的合作
软件作为手艺的回归？
虽然 AI 使得构建软件比以往更加容易，但我们正面临失去一些至关重要的东西的风险 – 创建真正精致的、消费者级体验的艺术。
演示质量陷阱
这已经成为一种模式：团队使用 AI 快速构建令人印象深刻的演示。顺利的路径运行得很完美。投资者和社交网络都被震惊了。但当真正的用户开始点击周围？那就是问题崩溃的时候。
我亲眼看到了：
- 对普通用户来说毫无意义的错误信息
- 边缘案例使得应用崩溃
- 从未被清理的混乱 UI 状态
- 完全忽视的可访问性
- 在较慢的设备上的性能问题
这些不仅仅是 P2 错误 – 它们是软件人们能忍受和软件人们喜爱之间的区别。
被遗失的打磨艺术
创建真正的自助式软件 – 那种用户永远不需要联系支持的软件 – 需要一种不同的心态：
- 对错误信息的迷恋
- 在慢速连接上进行测试
- 优雅地处理每一个边缘案例
- 使特性易于发现
- 与真实的、通常是非技术的用户进行测试
这种对细节的关注（或许）不是 AI 生成的。它来源于同理心、经验，以及对工艺的深切关怀。
个人软件的复兴
我相信我们将看到个人软件开发的复兴。随着市场被 AI 生成的 MVP（最小可行产品）淹没，那些将脱颖而出的产品是由开发者构建的，这些开发者：
- 为他们的工艺感到骄傲
- 关心细小的细节
- 专注于全面的用户体验
- 为边缘情况构建
- 创建真正的自助体验
讽刺的是？AI 工具实际上可能会促成这一复兴。通过处理常规编码任务，它们释放开发者专注于最重要的事情——创建真正服务于用户并使用户感到愉悦的软件。
底线
AI 并没有使我们的软件质量有了戏剧性的提升，因为软件质量（或许）从来就不仅仅受限于编码速度。软件开发的难点——理解需求、设计可维护的系统、处理边缘情况、确保安全性和性能——仍然需要人类的判断。
AI 能做的是让我们迭代和实验的速度更快，通过更快的探索可能导致更好的解决方案。但只有当我们保持工程纪律并将 AI 作为一种工具，而非良好软件实践的替代品时，这才有可能实现。记住：目标不是更快地写更多的代码。而是构建更好的软件。明智使用时，AI 可以帮助我们做到这一点。但知道什么是“更好”，以及如何实现“更好”，仍然取决于我们。
你和 AI 辅助开发的经验怎样？我很乐意在评论中听到你的故事和见解。