行百里者半九十：AI辅助编程只能帮你走到70%

实践指南，以及我们为何需要调整预期

AI的能力体现在很多方面，其中最先出彩的是编码能力。只需要一句话，AI就能帮你实现。人人都是程序员的未来似乎指日可待。果真如此吗？文章来自编译。

深入研究了人工智能辅助开发几年之后，我注意到一个有趣现象。虽然工程师报告称人工智能显著提高了工作效率，但我们日常使用的软件似乎并没有明显改善。这是怎么回事呢？

我想我知道个中原因，答案揭示了一些软件开发的基本事实，这是我们需要思考的地方。

开发者实际上是怎么用AI的

我观察到团队利用 AI 开发存在两种截然不同的模式。我们称之为“自启动”（Bootstrappers）与“迭代器”Iterators）。这两种模式都可以帮助工程师（甚至是非技术用户）填补从想法到执行（或 MVP）的鸿沟。

自启动：从零到 MVP

Bolt、v0 以及屏幕截图转代码 AI 等工具正在彻底改变我们启动新项目的方式。这些团队通常：

• 从设计或粗略概念开始

• 利用人工智能生成完整的初始代码库

• 在几小时或几天内（而不是几周）做出工作原型

• 专注于快速验证和迭代

结果令人印象深刻。我最近看到一位独立开发者用 Bolt 在很短的时间内将 Figma 设计变成了可运行的 Web 应用。还没到生产级，但用来获取初步用户反馈足够了。

迭代器：日常开发

第二阵营利用 Cursor、Cline、Copilot 以及WindSurf等工具处理日常开发。这些工具没那么光鲜，但可能更具变革性。这些开发者会：

• 利用AI补全代码，获取建议

• 利用AI完成复杂的重构任务

• 生成测试和文档

• 利用AI作为“编程搭子”来解决问题

但问题是：虽然这两种方法都可以大大加速开发速度，但它们都存在一些不太明显的隐性成本。

“AI速度”的隐性成本

如果你看过高级工程师运用 Cursor 或 Copilot 等 AI 工具，你会觉得就像变魔术一样。他们可以在几分钟内搭建出整个功能，并完成测试和文档。但仔细观察，你会发现一个关键点：他们可不是接受 AI 建议就完事了。他们会不断地：

• 将生成的代码重构为更小、更聚焦的模块

• 查缺补漏，添加边缘案例

• 强化类型定义和接口

• 质疑架构性决策

• 添加全面的错误处理

换句话说，他们正在运用多年来辛苦积累下来的工程智慧来塑造和限制人工智能的输出。人工智能可加速他们的实现，但他们的专业知识才是让代码可维护的关键。

初级工程师经常会忽略掉这些关键步骤。他们更容易全盘接受人工智能的输出，导致出现我所谓的“纸牌屋代码”——看似完整，但现实压力一推即倒。

知识悖论

这是我发现的最有违直觉的一点：人工智能工具对经验丰富的开发者的帮助要大于对初学者的帮助。听起来似乎在开倒车——人工智能难道不是应该让编码大众化吗？

现实情况是，人工智能就像是你团队有一位很热心的初级开发者。他们能快速编写代码，但需要不断的监督和纠正。你懂得越多，就越能指导他们。

这就产生了我所谓的“知识悖论”：

• 资深人士在利用人工智能来加速他们已经知道怎么去做的事情

• 而初级员工则尝试用人工智能来学习该干什么

• 结果大相径庭

我亲眼见过高级工程师利用人工智能来：

• 快速制作他们已经理解的原型

• 生成基本的实现，然后进行改进

• 探索已知问题的替代方法

• 自动执行日常编码任务
• 
  

与此同时，初级员工经常会：

• 接受不正确或过时的解决方案

• 忽视关键的安全与性能方面的考虑

• 陷入人工智能生成代码的调试陷阱

• 开发自己无法完全理解的脆弱系统

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

有一条推文完美地概括了我对该领域的观察：不是工程师的人用人工智能进行编码会遇到令人沮丧的障碍。他们可以出奇地快速地完成前 70% 的工作，但最后的 30% 却是收益递减的过程。

这个“70% 问题”揭示了当前人工智能辅助开发存在的关键问题。一开始的进展让人感觉很神奇——只需描述你想要的东西，像 v0 或 Bolt 这样的人工智能工具就会生成一个看起来令人印象深刻的工作原型。但之后，现实慢慢浮出水面。

进一步退两步

接下来发生的事情大概会是这样一种模式：

• 你试着修复一个小bug

• 人工智能给出变更建议似乎挺合理

• 按下葫芦浮起瓢，修复了这个bug之后，别的地方出问题了

• 你要求人工智能解决这个新问题

• 结果又引起了两个问题

• 诸如此类，周而复始

对于不是工程师的人来说，这种情况尤其痛苦，因为他们缺乏相应的思维模式，不知道问题出在哪里。经验丰富的开发者遇到错误时，他们可以根据多年的模式识别推断出潜在原因和解决方案。如果缺乏这种背景，基本上就相当于打地鼠游戏，你不完全理解的代码就是那些地鼠。

这个学习悖论仍在继续

这里面有一个更深层次的问题：不是工程师的人之所以能用人工智能编码工具，是因为这些工具能代为处理复杂问题，但这其实也会妨碍学习。当你不理解底层原理而代码却凭空“出现”时：

• 你没法培养出自己的调试技能

• 你错过了学习基本模式的机会

• 你没法论证架构决策的对错优劣

• 你很难维护和改进代码

这会造成一种依赖关系，你得不断让 AI 来解决问题，而没有培养出自己处理问题的专业知识。

知识鸿沟

最成功的非工程师会用混合模式来使用人工智能编码工具：

1.用人工智能进行快速原型设计

2.花时间了解生成代码的工作原理

3.除了学习人工智能的使用方法外，还学习基本的编程概念

4.逐步掌握基础知识

5.将 AI 用作学习工具，而不仅仅是代码生成器

但这需要耐心，需要投入——这与许多人最初希望通过用人工智能工具来实现的目标完全相反。

对未来的影响

这个“70%的问题”表明，当前的AI编码工具最好看作是：

• 为经验丰富的开发者提供原型设计加速器

• 为那些有志于了解开发的人提供的学习辅助工具

• 用于快速验证想法的 MVP 生成器

但它们还不是许多人所希望的编码大众化的解决方案。那最后的 30%——让软件实现生产级、可维护以及变得强大的部分——仍然需要掌握真正的工程知识。

好消息是，随着工具的改进，这个鸿沟可能会缩小。但目前，最务实的方法是用人工智能来加速学习，而不能完全取代。

真正有效的方法：实用模式

在观察了几十支团队之后，我发现以下是一直有效的做法：

1.“AI初稿”模式

• 让AI生成基本的实现

• 人工审查，模块化重构

• 添加全面的错误处理

• 编写彻底的测试

• 记录关键决策

2.“持续对话”模式

• 新的任务要启动新的 AI 聊天线程

• 上下文要保持聚焦和简洁

• 经常审查并提交变更

• 保持紧密的反馈回环

3.“信任但要核实”模式

• 用 AI 生成初始代码

• 人工审查所有的关键路径

• 自动测试边缘案例

• 定期进行安全审计

展望未来：人工智能的真正未来？

尽管面临种种挑战，我仍对人工智能在软件开发中的作用持乐观态度。关键是要了解其真正用途：

加速已知的事情

人工智能擅长帮我们实现已经理解的模式。就像拥有一位无比耐心、打字速度极快的编程搭子。

探索可能性

人工智能非常适合快速开发原型，探索不同的方法。它就像一个沙箱，我们可以在里面快速测试概念。

自动化日常工作

人工智能大大减少了花在样板与常规编码任务上的时间，让我们可以专注于有趣的问题。

这对你意味着什么？

如果你刚刚开始做 AI 辅助开发，以下是我的建议：

小处做起

• 用人工智能完成独立且定义明确的任务

• 检查生成的每行代码

• 逐步开发更大的功能

保持模块化

• 将所有内容分解为小的、集中的文件

• 组件之间保持接口清晰

• 记录模块边界

相信你的经验

• 用人工智能来加速而不是取代你的判断

• 质疑感觉不对的生成代码

• 维持你对工程的要求

智能体类软件工程的兴起

随着我们迈向 2025 年，人工智能辅助开发的格局正在发生巨大变化。虽然当前的工具已经改变了我们开发原型和迭代的方式，但我相信我们正处于一个更为重大的转变的风口浪尖：软件工程智能体的兴起。

我所说的“智能体”是什么意思？这些系统不仅可以响应提示，还可以愈发自主地对解决方案进行规划、执行以及迭代。

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

从响应者到合作者

当前的工具大多都要等待我们的命令。不过看看像Claude 的Anthropic计算机使用，或 Cline 自动启动浏览器和运行测试的能力。这些不仅仅是锦上添花式的自动补全功能 – 而是在理解任务并主动解决问题。

就拿调试来说吧：这些智能体不仅可以给出修复建议，还可以：

• 主动发现潜在问题

• 启动并运行测试套件

• 检查 UI 元素并捕获屏幕截图

• 提出并实施修复

• 验证解决方案是否有效（也许意义重大）

多模态的未来

下一代工具可能不仅仅能处理代码——还可以无缝集成：

• 视觉理解能力（UI 截图、模型、图表）

• 口头语言对话

• 与环境（浏览器、终端、API）交互

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

自主但有指导

使用这些工具我得到一个关键洞察是，未来不是人工智能取代开发者，而是人工智能成为一个越来越有能力的合作者，能够采取主动行动，同时仍然尊重人类的指导和专业知识。

2025 年最高效的团队也许是掌握以下技能的那些：

• 为人工智能智能体设定明确界限和指导方针

• 建立起强大的架构模式，让智能体可以在其中发挥作用

• 在人类和AI能力之间建立有效的反馈循环

• 在利用人工智能自主性的同时保持人类监督

英语优先的开发环境

就像 Andrej Karpathy所说那样：

英语正成为最热门的新编程语言。

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

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

• 要有更强的系统设计和架构思维

• 更好的需求规范和沟通

• 更加注重质量保证和验证

• 增强人类与人工智能之间的协作
• 
  

软件作为一门手艺的回归？

虽然人工智能令快速开发软件变得比以往任何时候都要容易，但我们却面临着失去某个重要东西的风险，那就是创造真正精致的、消费者品质体验的艺术。

演示级质量的陷阱

这正在成为一种模式：团队用人工智能快速开发出令人印象深刻的演示。这条通往快乐的道路似乎一路坦途。投资者和社交网络都惊叹不已。但当真正的用户开始点击时，事情才开始崩溃。

我亲眼见过这样的事：

• 对普通用户毫无意义的错误消息

• 导致应用崩溃的边缘案例

• 令人困惑且从未被清理过的 UI 状态

• 完全忽视了无障碍设置

• 在较慢设备上会出现性能问题

这些不仅仅是 P2 级的bug – 那是能容忍的软件与喜爱的软件之别。

失传的精细化艺术

打造真正的自助式软件（也就是用户完全无需联系支持人员的那种软件），需要一种与众不同的思维方式：

• 对错误消息精益求精

• 在慢速网络环境下测试

• 优雅地处理每一种边缘情况

• 让发现功能变得更容易

• 用真实的、往往是非技术背景的用户进行测试

这种对细节的关注（或许）是 AI 生成不了的。这源于共情、经验以及对这门手艺的深切热爱。

个人软件的复兴

我相信我们将看到个人软件开发的复兴。随着市场充斥着人工智能生成的 MVP，具有以下特征的开发者开发出来的产品将脱颖而出：

• 为自己的技艺感到自豪

• 关注细节

• 注重完整的用户体验

• 考虑极端案例

• 创造真正的自助体验

讽刺的是，人工智能工具其实有可能会推动这一复兴。通过接手常规编码任务，它们让开发者可以专注于最重要的事情——开发真正服务于用户并让用户满意的软件。

总结

AI 并没有让我们的软件显著变好，因为软件质量（或许）从来就不是由编码速度决定的。软件开发最困难的部分——理解需求、设计可维护的系统、处理边缘情况、确保安全性和性能——仍然需要人类的判断。

AI 真正的作用在于让我们能够更快地迭代和试验，从而通过快速探索找到更优的解决方案。但这只有在我们坚持工程规范、将 AI 视为工具而非取代良好软件实践时才能实现。

记住：目标不是更快地写出更多的代码，而是开发出更好的软件。如果合理使用，AI 确实可以帮助我们做到这一点。但最终，我们仍需要明确什么是“更好”，以及如何实现它。

文章来自于“神译局”，作者“boxi”。