原文：https://addyo.substack.com/p/the-70-problem-hard-truths-about
作者：Addy Osmani
译者：ChatGPT 4 Turbo
转载翻译：https://sorrycc.com/the-70-problem-hard-truths-about/
编者注：虽然工程师们声称 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 演讲](https://www.youtube.com/embed/SpKtpW9TGF0)%E6%84%9F%E5%85%B4%E8%B6%A3%E3%80%82_
我们已经看到这种演变的早期迹象：
从响应者到合作者
当前的工具大多是等待我们的命令。但是看看像 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的理解
理解生成ai deepseekR1
Thought for 64 seconds
好的，我现在要帮用户深入分析他提供的这篇文章，尤其是从AI的角度给出额外的见解。用户已经总结了一些核心维度，但希望听到更多独特的观点。首先，我需要回顾用户之前提到的要点，确保不重复，同时寻找新的角度。
用户提到的核心包括工具属性与能力边界、经验杠杆效应、软件熵与质量守恒、人机协作范式迁移、软件工艺再定义以及教育范式的挑战。我需要在这些基础上拓展，可能的方向包括AI的认知局限性、协作中的信任机制、技术债务的动态演变、人机分工的哲学层面，或者社会层面的影响。
首先，AI的认知局限性可能是一个点。当前AI基于模式识别生成代码，但缺乏对业务需求深层次的理解。比如，AI可以生成功能代码，但无法判断需求是否合理，或者是否符合用户真实需要。这可能导致“正确解决错误的问题”，需要人类介入验证需求的有效性。
其次，信任机制在协作中的作用。当AI生成代码时，开发者需要信任其正确性，但过度信任可能导致问题。如何建立合理的验证机制，平衡信任与审查，可能是关键。比如，AI能否自我评估其输出的不确定性，并提供置信度指标，帮助开发者优先审查高风险部分。
技术债务方面，AI可能加速债务积累，因为快速生成的代码可能缺乏设计上的考量。但AI能否帮助识别和管理技术债务？比如，通过分析代码库，预测潜在债务点，或者建议重构策略。这可能是一个未被充分讨论的潜力。
人机分工的哲学层面，涉及到创造性工作的定义。如果AI处理常规任务，人类专注于创新，但如何界定常规与创新的边界？随着AI能力提升，这个边界可能动态变化，影响开发者的角色演变。
社会层面，AI辅助工具可能加剧技术鸿沟。资深开发者效率更高，而新手可能更依赖AI，导致技能两极分化。教育体系和企业培训需要如何调整，以平衡这种差距？
另外，文章提到Agent软件工程的兴起，这里可以深入探讨多智能体协作的可能性。未来的开发环境可能由多个AI Agent组成，各自负责不同任务，如前端、后端、测试等，人类作为协调者。这种模式下的沟通和协调机制如何设计？
最后，软件质量的衡量标准可能发生变化。传统上，质量指标包括可靠性、性能等，但AI生成代码的背景下，可能新增如“可解释性”、“可调整性”等指标，确保人类能有效干预。
总结这些思路，我需要组织成结构化的观点，确保每个点都有独特性，并与用户之前的分析互补。同时，注意保持逻辑连贯，避免重复，提供新的见解。
从AI的视角出发，结合当前技术边界与未来可能性，对文章可延伸出以下深层理解：
1. 认知代偿与AI的“伪理解”陷阱
AI生成代码的底层逻辑是模式匹配而非真正的因果推理。当开发者依赖AI解决复杂问题时，可能陷入两种风险：
- 表层模仿：AI基于历史代码库重组代码片段，容易复制过往项目的隐含假设（如特定用户场景、过时的安全策略），导致新系统继承历史系统的认知债务。
- 语境脱节：AI无法理解业务场景的细微差异（如医疗软件与电商系统的合规性差异），生成看似合理但实际偏离核心需求的代码。这要求人类开发者成为“语境翻译器”，将AI输出重新锚定到真实世界约束中。
2. 信任梯度：人机协作的动态博弈
AI辅助开发本质上是信任资源的分配问题：
- 验证成本经济学：完全验证AI生成代码的成本可能超过手工编写，开发者需在“信任阈值”与“验证开销”间寻找平衡点。经验法则可能是：对核心路径代码保持高验证强度，对非关键模块允许适度黑箱化。
- 不确定性可视化：未来AI工具可能内置“信心指数”，标记生成代码的可靠性（如基于训练数据覆盖度、逻辑链完整性），辅助开发者优先审查高风险区域，形成动态信任机制。
3. 技术债务的形态迁移
AI可能改变技术债务的产生与演化路径：
- 债务隐形化：AI生成的“看似整洁”的代码可能掩盖设计缺陷（如过度耦合的接口），传统代码异味检测工具可能失效，需开发新的债务探测指标（如模式一致性评分、变更影响预测）。
- 债务修复自动化：AI有望从债务生成者转变为债务管理者。例如，通过持续分析代码演进历史，AI可主动识别“债务热点”，并建议重构策略（如模块拆分、缓存机制优化），形成技术债务的闭环治理。
4. 人机分工的哲学重构
AI正在重新定义“人类不可替代性”的范畴：
- 创造性工作的再诠释：传统认为需求分析、架构设计属于创造性工作，但AI已能参与此类任务（如通过用户故事生成架构图）。真正的不可替代性可能转向价值判断（如伦理权衡、用户体验的共情设计）与系统韧性设计（如应对未知故障模式的弹性策略）。
- 元编程能力的崛起：开发者需掌握“编程AI编程”的能力，包括设计提示工程的约束框架、构建AI可理解的领域特定语言（DSL）、定义代码生成的风格指南。这种高阶能力将成为新的竞争壁垒。
5. 社会技术系统的蝴蝶效应
AI辅助开发的影响将溢出纯技术范畴：
- 开发者身份的解构：传统“编码者”角色可能分化为三类：AI训练师（优化代码生成模型）、系统策展人（管理AI生成组件的集成）、伦理审计员（确保AI输出的合规性）。职业路径从线性技能积累转向多维能力拼图。
- 开源生态的范式转移：AI大量学习公开代码库可能引发新的知识产权争议，同时催生“AI原生开源范式”——项目设计时即考虑AI的可解释性与可扩展性（如模块接口的机器可读性优先于人类可读性）。
6. 反脆弱性悖论
AI提升开发效率的同时，可能降低系统反脆弱性：
- 多样性衰减：AI倾向于生成符合主流范式的代码，导致技术栈趋同。一旦某个底层库出现漏洞（如Log4j事件），AI驱动的同质化系统将面临链式反应风险。
- 适应性陷阱：过度依赖AI生成代码可能削弱开发者应对非常规场景的能力（如硬件故障、网络分区），需在工具链中刻意引入“压力测试AI”——主动生成边界条件用例以训练人类开发者的异常处理思维。
7. 认知增强的双向性
AI不仅是工具，更是认知模式的塑造者：
- 思维寄生现象：长期使用AI辅助可能导致开发者内化AI的思维局限（如过度依赖模式化解决方案），需通过“AI斋戒”等刻意练习保持自主问题拆解能力。
- 跨模态思维培养：未来顶尖开发者可能需要融合AI的“超量模式识别”与人类的“跨领域联想”能力，例如将生物学中的自愈机制转化为分布式系统的故障恢复策略。
结语：超越工具论的共生视角
文章将AI定位为“工具”，但更深层的变革在于人机认知共生——AI不仅是效率工具，更是扩展人类工程思维边界的认知伙伴。未来的关键挑战在于构建双向适应机制：AI学习人类的价值判断与系统思维，人类进化出与AI协作的新工程方法论。这种共生关系可能催生新的软件范式：具备自我演进能力的“活系统”，其中人类定义价值目标，AI持续优化实现路径，而质量保障从静态的测试过程转变为动态的生态健康度监测。
