AI 编程残酷真相：70%开发者都在忽视的关键问题

calendar 2025-02-24 · 13 分钟阅读 · coding ai
AI 编程残酷真相：70%开发者都在忽视的关键问题
  • 本文编译自：The 70% problem: Hard truths about AI-assisted coding
  • 原作者 Addy Osmani
  • 原文地址： https://addyo.substack.com/p/the-70-problem-hard-truths-about
  • 视频演讲：https://youtu.be/SpKtpW9TGF0

文章主要由智谱GLM翻译， AI 对于长句子理解问题不大，但对于短句和列表要点，翻译起来就难以做到信达雅。恰巧，技术文章中经常出现列表。

为方便以中文为母语的非开发者理解，曾老师在编译的过程中进行了大量的修改，植入了非常多的私货，还调整了一些用词，并加入了一些编程相关的专有名词的介绍。

我建议所有的初级/高级开发者，以及期望学习 AI 开发的非工程师，都能认真阅读（建议使用公众号的听全文功能）这篇 6000 字左右的文章。

  • 开发者是如何使用 AI 的

  • 自举式开发者：从零到 MVP

  • 迭代器式开发者：每日开发

  • AI 速度的隐性成本

  • 知识悖论

  • 70%问题：人工智能的学习曲线悖论

  • 后退两步模式

  • 学习悖论持续存在

  • 知识差距

  • 未来影响

  • 实际上有效：实用模式

    1. AI 初稿模式
    1. 持续对话模式
    1. 信任但核实模式

  • 期待未来：人工智能的真正承诺？

  • 这对你意味着什么？

    1. 从小做起
    1. 保持模块化
    1. 信任你的经验

  • 代理软件工程的兴起

  • 从响应者到合作者

  • 多模态未来

  • 自主但引导

  • 自然语言优先的开发环境

  • 软件作为工艺的回归？

  • 演示质量陷阱

  • 遗失的艺术打磨能力

  • 个人软件的复兴

  • 底线

在过去的几年里，我一直在 AI 辅助开发中深耕，发现了一个有趣的现象。虽然工程师们报告说使用 AI 后生产力大幅提升，但我们日常使用的软件似乎并没有明显改善。这是怎么回事呢？

我觉得自己已经找到了答案，这个答案揭示了关于软件开发的一些基本真理，我们需要认真对待。 下面我就来分享。

开发者是如何使用 AI 的

我观察到团队在利用 AI 进行开发时存在两种不同的模式。我们可以称它们为“启动者”和“迭代者”。两者都在帮助工程师（甚至非技术用户）缩小从想法到执行（或 MVP）的差距。

自举式开发者：从零到 MVP

曾老师插话：什么是自举式开发者？（原文：The Bootstrappers）

自举 Bootstrap 是计算机科学中常用的概念，一般指对于一个新创建的编程语言来说，使用自己来实现自己的编译器。例如 C 语言的编译器，最早是使用汇编语言实现，而 Go 语言的编辑器，最早是使用 C 语言实现的。

语言能力发展到一定阶段之后，就可以实现自举：使用 C 语言实现 C 语言的编译器，使用 Go 语言实现 Go 语言的编译器。

来自曾老师的大脑

DeepSeek 按中学生理解力给出的解释：

盖房子时如何用脚手架升级脚手架？

‌初始阶段‌

你只有3根竹竿和绳子，搭出一个‌矮小简易的脚手架‌。
类比：编程语言初期用其他工具（如C语言）实现基础功能。

‌第一次自举‌

你站在这个矮脚手架上，用更多材料搭建出‌更高、更稳的脚手架‌。
类比：用初期版本的语言写出增强版的工具。

‌完全自举‌

拆除最初的矮脚手架，完全用新脚手架继续加高，最终盖成大楼。
类比：语言不再依赖其他工具，用自身功能持续升级。

自举的核心逻辑 ✅

‌用“不够好”创造出“更好”，再让“更好”替代“不够好”‌，类似「踩着梯子换梯子」（最后丢掉梯子）。
（附图：📏 → 📐 → 🏗️ → 🏢）

来自百度 DeepSeek-R1

曾老师插话完毕

像 Bolt.new、v0.dev ，以及截图转代码这样的 AI 工具，正在革新我们启动新项目的方式。自举式开发团队通常这样做：

  • 从设计或粗略概念开始
  • 使用 AI 生成完整的初始代码库
  • 把获得可工作原型的时间，从数周减少到数小时或数天
  • 关注快速验证和迭代

结果令人印象深刻。我最近看到一个独立开发者用 Bolt 将 Figma 设计转换成生产环境的网络应用，几乎没有花费时间。，但足以获得非常初步的用户反馈。

曾老师插话：生产环境，一般指可以发布给公众的版本。

迭代器式开发者：每日开发

曾老师插话：迭代器 Iterator 也是编程领域的概念，甚至是一个设计模式。但这里作为 迭代 理解就可以了。

也可以使用 Cursor、Cline、Copilot 和 WindSurf 等工具进行日常开发工作流程。这比那些花哨的方案更有可能带来变革。迭代器式发者通常这样做：

  • 使用 AI 进行代码补全和建议
  • 利用 AI 进行复杂的重构任务
  • 生成测试和文档
  • 使用 AI 作为「代码伙伴」进行问题解决

但是这里有个问题：虽然这两种方法都可以显著加快开发速度，但它们也伴随着一些隐藏的成本，这些成本并不明显。

AI 速度的隐性成本

当你看到资深工程师使用 Cursor 或 Copilot 等 AI 工具工作时，你可能觉得他在用魔法。他们可以在几分钟内搭建起整个功能，包括测试和文档。但仔细观察，你会发现一个关键点：他们不仅仅是接受 AI 的建议。他们一直在：

  • 重构生成的代码为更小、更专注的模块
  • 添加 AI 遗漏的边缘情况处理
  • 加强类型定义和接口
  • 质疑架构决策
  • 添加全面错误处理

换句话说，他们正在将多年的工程智慧应用于 塑造和限制 AI 的输出。人工智能正在加速他们的实施，但他们的专业知识是保持代码可维护性的关键。

初级工程师常常错过这些关键步骤。他们 更容易接受 AI 的输出 ，导致我所说的「纸牌屋代码」——它看起来很完整，但在现实世界的压力下会崩溃。o

知识悖论

这里最令人意想不到的事情是我发现的：AI 工具对经验丰富的开发者帮助大于初学者。 这似乎是反直觉的——AI 不应该使编码民主化吗？

现实是，AI 就像在你的团队里有一个非常渴望的初级开发者。他们可以快速编写代码，但需要不断的监督和纠正。你知道的越多，就能更好地引导他们。

这创造了我认为的「知识悖论」：

  • 高级开发者利用 AI 加速他们已经知道如何做的事情
  • 初级开发者尝试使用 AI 来学习该做什么
  • 结果差异巨大

我已经看到高级开发者使用 AI 来：

  • 快速原型化他们已经理解的想法
  • 生成他们可以进一步优化的基本实现
  • 探索已知问题的替代方法
  • 自动化常规编码任务

同时，初级开发者经常：

  • 接受不正确或过时的解决方案
  • 忽略关键的安全性和性能考虑
  • 努力调试 AI 生成的代码
  • 构建他们不完全理解的脆弱系统

70%问题：人工智能的学习曲线悖论

一条最近引起我注意的推文完美地捕捉到了我在现场观察到的现象：非工程师使用 AI 进行编码时，发现自己遇到了令人沮丧的瓶颈。他们可以出奇地快速完成 70%的工作，但最后的 30%却变成了收益递减的练习。

作为一名非工程师，对使用 AI 进行编码的诚实反思:
它可以让你完成70%的任务，但最后的30%令人沮丧。它不断向前一步，向后退两步，不断出现新的漏洞、问题等。
如果我知道代码是如何工作的，我可能会自己修复它。但既然我不知道，我怀疑我是否真的学到了这么多。

「70%问题」揭示了关于当前 AI 辅助开发状态的关键信息。最初的进展感觉神奇——你可以描述你想要的内容，AI 工具将生成一个看起来令人印象深刻的可工作原型。但随后现实就降临了。

后退两步模式

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

  • 你尝试修复一个小错误
  • AI 建议一个看似合理的改变
  • 这个修复破坏了其他东西
  • 你要求 AI 修复新问题
  • 这又产生了两个问题
  • 重复上面的步骤

这个周期对非工程师来说尤其痛苦，因为他们缺乏理解实际发生什么问题的心理模型。当有经验的开发者遇到一个错误时，他们可以根据多年的模式识别来推理可能的成因和解决方案。没有这个背景，你实际上是在用你不完全理解的代码玩打地鼠。

曾老师说：这个周期对于程序员来轻车熟路，因为这就是程序员的日常工作模型。

我在 游戏人，要不要沉迷在技术中？ 这篇文章中提到过：编程世界中的反馈，即便是错误的，也是正反馈。

更多讨论可以看：

学习悖论持续存在

曾老师：下面这段是完全意译重写，因为我只读懂了英文，AI 翻译的中文完全看不懂。

有一个更深层次的问题：AI 编码工具对非工程师来说，最核心的部分是处理复杂性的能力。 而非工程师在这个能力上的缺乏，可能会阻碍非工程师的学习。当代码只是「出现」而你又不理解其背后的原理时：

  • 你无法培养调试技能
  • 你错过了学习基本模式
  • 您无法对架构决策进行推理
  • 你艰难地维护和推演代码

这导致了一种依赖，你需要不断回到 AI 那里去解决问题，而不是培养自己处理这些问题的专业知识。

曾老师插话：我在一个学习 AI 编程的群里，遇到的最多求助信息是这样的：

资深开发者一眼就可以看出，第一张图的提问者可能没有给 Node.js 足够的运行权限，第二张图的提问者还没有搞清楚提示 node 运行环境和 shell 提示符的区别。

在没有基础环境搭建经验的前提下，碰到这样的问题非常让人沮丧，除非远程控制，这很难做技术支持。

知识差距

我所见过的最成功的非工程师使用 AI 编码工具时采取的是混合方法：

  • 使用 AI 进行快速原型设计
  • 花时间理解生成的代码是如何工作的
  • 既学习 AI 应用，又学习基本编程概念
  • 逐步建立知识基础
  • 使用 AI 作为学习工具，而不仅仅是代码生成器

但这需要耐心和奉献——这与许多人最初希望通过使用 AI 工具实现的目标正好相反。

未来影响

这个「70%问题」表明，当前的人工智能编码工具最好被视为：

  • 原型加速器，针对经验丰富的开发者
  • 学习有助于理解发展的辅助工具
  • MVP 生成器，用于快速验证想法

曾老师：MVP （Minimum Viable Product ）通常翻译为「最小可行产品」，但这个缩写很通用，一般不翻译。

但他们还不是许多人希望看到的编码民主化解决方案。最后的 30%（使软件用于生产环境、健壮可维护的部分），仍然需要真正的工程知识。

好消息是随着工具的改进，这个差距可能会缩小。但就目前而言，最实际的方法是利用 AI 加速学习，而不是完全取代它。

实际上有效：实用模式

观察了数十个团队后，我看到了以下一直有效的方法：

1. AI 初稿模式

  • AI 生成基本实现
  • 手动审查和重构以提高模块化
  • 添加全面错误处理
  • 编写详尽的测试
  • 对关键决策文档化

2. 持续对话模式

  • 启动针对每个不同任务的 AI 聊天
  • 保持上下文集中且简洁
  • 经常审查和提交更改
  • 保持紧密的反馈循环

3. 信任但核实模式

  • 使用人工智能进行初始代码生成
  • 人工审查所有关键路径
  • 自动化测试边缘情况
  • 常规安全审计

期待未来：人工智能的真正承诺？

尽管存在这些挑战，我对人工智能在软件开发中的作用持乐观态度。关键在于理解它真正擅长的领域：

  1. 加速已知
    AI 擅长帮助我们实施我们已理解的模式。它就像有一个无限耐心的、打字速度极快的搭档程序员。
  2. 探索可能
    AI 非常适合快速原型设计和探索不同的方法。它就像一个沙盒，我们可以快速测试概念。
  3. 自动化日常事务
    AI 大幅缩短了在模板和常规编码任务上花费的时间，让我们能专注于有趣的问题。

这对你意味着什么？

如果您刚开始使用 AI 辅助开发，以下是我的建议：

1. 从小做起

  • 使用 AI 处理孤立、定义明确的任务
  • 审查每行生成的代码
  • 逐步构建更大的功能

2. 保持模块化

  • 将一切分解为小型、专注的文件
  • 保持组件间清晰的接口
  • 编写模块边界文档

3. 信任你的经验

使用 AI 加速，而不是取代，您的判断
调整与你预期不符的生成代码
保持你的工程标准

代理软件工程的兴起

人工智能辅助开发的格局正在发生巨大变化。尽管当前的工具已经改变了我们的原型设计和迭代方式，但我相信我们正站在一个更加重大的变革的边缘：代理软件工程的兴起。

我所指的「代理化」是什么意思？这些系统不仅仅是对提示做出响应，它们还可以规划、执行并在不断增长的自主性基础上迭代解决方案。

如果您想了解更多关于代理的信息，包括我对 Cursor/Cline/v0/Bolt 的看法，您可能会对我的最近 JSNation 演讲感兴趣（复制下方链接访问，需要魔法上网）

https://youtu.be/SpKtpW9TGF0

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

从响应者到合作者

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

思考调试：这些代理不仅可以提出修复建议，还可以：

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

多模态未来

下一代工具可能不仅限于与代码协同工作——它们可能实现无缝集成：

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

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

自主但引导

从使用这些工具的工作中，我获得的关键洞见是，未来不是关于 AI 取代开发者——而是 AI 成为一个越来越有能力的合作伙伴， 它可以在尊重人类指导和专业知识的同时采取主动。

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

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

自然语言优先的开发环境

曾老师：原标题为 The English-first development environment

正如安德烈·卡帕西所说：

"English is becoming the hottest new programming language."

Andrej Karpathy

曾老师插话：这里作者关于 English 的本意不是专指英语，而是指 「自然语言」，是相对于编程语言（Programming language）来说的。在中文语境下，我们也可以这么说：

中文正成为最热门的新编程语言。请大家锻炼把中文讲清楚的能力。

胡扯游戏的曾老师

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

这一向代理发展的转变将需要我们提升我们的技能：

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

软件作为工艺的回归？

尽管 AI 让快速构建软件变得比以往任何时候都容易，但我们面临着失去一些至关重要的东西——那就是创造真正精致、消费者级体验的艺术。

许多软件现在可以快速构建，但要真正使其具有自助服务和消费者质量，这正在成为一门失传的艺术。
你必须打磨所有的边缘并修复P2错误，而不是只关注演示路径。
今年，个人软件将被迫回归。

演示质量陷阱

它已成为一种模式：团队利用 AI 快速构建令人印象深刻的演示。这条路径运作得非常完美。投资者和社交网络都为之惊叹。但当真实用户开始点击操作时，就是事情开始分崩离析的时候。

我亲眼所见：

  • 错误信息对普通用户来说毫无意义
  • 边缘情况导致应用程序崩溃
  • 界面状态混乱且从未清理
  • 无障碍性完全被忽视（曾老师：这个在中文世界更严重）
  • 性能问题在较慢的设备上

这不是简单的 P2 错误——这是人们忍受的软件和人们喜爱的软件之间的区别。

遗失的艺术打磨能力

打造真正自助服务的软件——用户无需联系支持的软件——需要不同的思维方式：

  • 关注错误信息，直到沉迷其中
  • 在慢速连接上做测试
  • 优雅处理每个边缘情况
  • 制作可发现的功能
  • 面向非技术用户做真实测试

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

个人软件的复兴

我相信我们将见证个人软件开发的新生。随着市场上充斥着 AI 生成的 MVP 产品，脱颖而出的将是那些由开发者构建的产品：

  • 以他们的工艺为荣
  • 关心细节
  • 关注完整用户体验
  • 为边缘情况构建
  • 创建真正自助式体验

人工智能工具实际上可能促成这场复兴。通过处理日常编码任务，它们让开发者能够专注于最重要的事情——创造真正服务于并取悦用户的软件。

底线

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

AI 所做的就是让我们能够更快地迭代和实验，可能通过更快的探索带来更好的解决方案。但前提是我们保持我们的工程纪律，将 AI 作为工具，而不是替代良好软件实践的替代品。

记住：目标不是更快地编写更多代码，而是构建更好的软件。 如果使用得当，AI 可以帮助我们做到这一点。但最终，我们还需要知道「更好」意味着什么以及如何实现它。

您的 AI 辅助开发经验如何？欢迎在评论中分享您的故事和见解。

胡扯 AI 群，匹配游戏小团队创业，关注 AI 嵌入游戏工作流

当听到地铁上有人聊 ChatGPT，当 DeepSeek 把 OpenIAI 和 Gemini 卷到打骨折，当百度开源文心一言，我知道，将 AI 全面嵌入工作流的时机已经成熟了。

曾老师会持续专注于将 AI 深度整合进入工作流，有兴趣折腾的朋友可扫描下方二维码，一起在游戏创业路上持续精进。