AI 辅助编码的残酷真相：它能帮你完成70%的工作，但最后30%令人非常沮丧

一份实战指南，以及为何我们需要重新审视自己的期望

在过去几年深入参与 AI 辅助开发的过程中，我注意到一个非常有趣的现象：尽管许多工程师都表示自己在使用 AI 时生产力显著提升，但我们日常使用的软件却并没有明显变好。到底发生了什么？

我想我知道原因，而其中揭示了一些软件开发的根本事实，值得我们认真思考。让我来分享我所学到的内容。

开发者实际上是如何使用 AI 的

我观察到，团队在利用 AI 进行开发时，主要呈现两种模式——“启动者（bootstrappers）”和“迭代者（iterators）”。这两种模式都在帮助工程师（甚至非技术用户）缩小从想法到执行（或 MVP）的距离。

启动者：从零到 MVP

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

• 从一个设计或大致概念开始

• 使用 AI 生成一个完整的初始代码库

• 在数小时或数天内就能拿到一个可用的原型，而不是几周

• 专注于快速验证和迭代

成果常常令人惊叹。我最近看到一位独立开发者使用 Bolt，只花很短时间就把 Figma 设计变成了可运行的 Web 应用。虽然它还不具备生产环境所需的完备性，但足以收集最初的用户反馈。

迭代者：日常开发

第二种模式是使用像 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% 却陷入痛苦的“边际收益递减”之中。

作为一个非专业工程师，以下是我对使用AI编程的真实感受：

它能帮你完成70%的工作，但最后30%令人非常沮丧。每前进一步，就会因为新的bug和问题而后退两步。

如果我知道代码是如何运作的，也许我自己就能修复这些问题。但由于我不懂，我开始怀疑自己是否真的学到了什么。

这个“70% 问题”揭示了当前 AI 辅助开发的一个关键点。最初的进展令人惊叹——你描述你想要的功能，工具（如 v0 或 Bolt）就能生成一个看上去相当不错的原型。但接下来，现实就会浮现。

“后退两步”的模式

接下来通常会出现一个很典型的循环：

• 你想修复一个小 Bug

• AI 给出一个看似合理的修改建议

• 结果这个修改又引发了其他问题

• 你再让 AI 修复新问题

• 于是又产生更多问题

• 如此反复循环

对于非专业工程师来说，这种循环尤其痛苦，因为他们缺少必要的心智模型来理解到底哪里出了问题。当一名有经验的开发者遇到 Bug 时，他们会基于自己多年的模式识别来推测可能的原因和解决方案。但如果你没有这种背景，那就只能像打地鼠一样，不停敲击那些自己并不了解的“冒出来的错误”。

持续的学习悖论

更深层的麻烦在于：AI 工具能为你“代劳”很多复杂的事情，这恰恰使得非专业工程师更难真正学到软件开发的本质。当代码在你眼前“凭空出现”，而你并不理解它背后的原理时：

• 你不会培养调试技能

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

• 你无法对架构决策进行推理

• 你也难以维护和升级这些代码

这就造成了一种依赖——你只能不断求助于 AI 来修复问题，而不是掌握亲自解决它们的能力。

知识鸿沟

我见到最成功的非专业工程师，会采用一种“混合式”的方法：

1. 用 AI 进行快速原型

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

3. 在使用 AI 的同时学习基本的编程概念

4. 一步步打好知识基础

5. 把 AI 视为学习工具，而不仅仅是“代码生成器”

但这需要耐心和投入——而这恰恰与很多人使用 AI 工具时所期待的“省时省力”背道而驰。

对未来的启示

这个“70% 问题”说明，当前的 AI 编码工具更适合被视为：

• 对资深开发者而言，用来加速原型的工具

• 对想认真学习开发的人而言，用来辅助学习的工具

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

但它们还远不能成为“所有人都能轻松做出成熟软件”的神奇方案。最后那“至关重要的 30%”——让软件真正具备生产力、可维护性、健壮性——依然需要真正的工程知识。

好消息是：随着工具的进步，这个差距有望逐步缩小。但在当下，最务实的做法还是把 AI 当作加速学习的手段，而不是用来完全替代你对软件开发本质的理解。

实际可行的做法：一些成功的模式

在观察了数十个团队之后，我发现以下做法行之有效：

1. “AI 初稿”模式

• 让 AI 生成一个基础实现

• 由人工对代码进行模块化审查和重构

• 加入完备的错误处理

• 编写充分的测试

• 补充并记录关键的技术决策

2. “持续对话”模式

• 针对每个独立任务都开启一个新的 AI 对话

• 保持上下文精简、集中

• 频繁地审查和提交变更

• 建立紧凑的反馈循环

3. “信任但要验证”模式

• 用 AI 做初始代码生成

• 对关键路径进行人工审查

• 编写自动化测试，以覆盖各种边界情况

• 定期进行安全审计

展望未来：AI 的真正潜力是什么？

尽管面临这些挑战，我对 AI 在软件开发中的作用依然保持乐观。关键在于我们要明白 AI 真正擅长什么：

1. 加速我们已经知道的东西
   AI 在帮助我们实现已知的模式时非常出色，就像拥有一个永不疲倦、打字飞快的结对程序员。

2. 探索新的可能性
   AI 让我们可以快速构建原型并探索不同思路，就像在一个实验沙盒里可以极速测试各种概念。

3. 自动化常规任务
   AI 大幅减少我们在样板代码和常规任务上花费的时间，让我们可以更专注于那些真正有意思的问题。

这对你意味着什么？

如果你正准备开始使用 AI 辅助开发，我的建议是：

1. 从小处着手

   • 让 AI 先处理独立且定义清晰的小任务

   • 审查 AI 生成的每一行代码

   • 再逐步扩展到更大规模的功能

2. 保持模块化

   • 把所有东西拆分成小而专注的文件

   • 为各组件设定清晰的接口

   • 在模块边界处做好文档

3. 相信你的经验

   • 用 AI 来加速，而不是替代你的判断

   • 对那些“感觉不对劲”的生成代码保持质疑

   • 坚守你的工程规范与标准

自主型软件工程的崛起

随着我们迈向 2025，AI 辅助开发的格局正在发生巨变。虽然现有工具已经改变了我们原型设计和迭代的方式，但我相信更具革命性的转变即将到来——“自主型（agentic）软件工程”的崛起。

我所说的“自主型”，指的是这些系统将不再仅仅是应答式工具，而是能够进行规划、执行和迭代，具备越来越高的自主性。

如果你想深入了解“智能体（agents）”的相关内容，以及我对 Cursor/Cline/v0/Bolt 的观点，可以点击上方链接观看我在 JSNation 的最新演讲。

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

从应答者到协作者

目前的工具大多会等着我们下指令。但是，看看 Anthropic 在 Claude 中对“计算机使用”的新特性，或 Cline 能够自动打开浏览器并运行测试的能力——这些已经不再是“自动补全”那么简单，而是在真正理解任务并主动执行。

比如在调试中，它们可能会：

• 主动发现潜在问题

• 启动并运行测试套件

• 检查 UI 元素并截屏

• 提出并实现修复方案

• 验证修复是否有效（这可能是个重大突破）

多模态的未来

下一代的工具可能不仅能读写代码，还会无缝结合：

• 对视觉内容的理解（UI 截图、模型图、流程图）

• 对自然语言的理解与对话

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

具备多模态能力的系统，能像人类一样，从整体角度去理解和处理软件，而不只是停留在代码层面。

自主但需引导

我的实践告诉我，未来并不是要让 AI 取代开发者，而是让 AI 成为一个更强大的协作者，既能主动执行，又能尊重人类的引导与专业知识。

到 2025 年，最有效的团队或许将是那些懂得：

• 为 AI 代理设定清晰的边界和准则

• 建立强大的架构模式，供 AI 代理在其中工作

• 建立人机之间高效的反馈回路

• 在利用 AI 的自主性的同时，保持人类的审查与监督

“英语优先”的开发环境

Andrej Karpathy 曾指出：

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

这句话反映了我们与开发工具交互方式的根本转变——清晰的思考和精确的自然语言表达，正变得与传统的编码技能一样重要。

迈向自主型开发的道路需要我们提升以下能力：

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

• 更好的需求规范和沟通技巧

• 更专注于质量保证和验证

• 更流畅的人机协作能力

软件手艺的回归？

尽管 AI 让我们比以往更容易快速构建软件，但我们也面临一个风险：我们可能会失去软件创作的那份“艺术感”，或者说“工匠精神”。有些人 认为，这种对打造“真正优质的消费级体验”的追求，恰恰是目前最容易被忽视的部分。

现在软件可以很快地被开发出来，但要让它实现自助服务且达到消费级质量，却正在成为一门失传的艺术。

你必须打磨所有边角，修复所有P2级别的bug，而不是仅仅关注演示路径。

今年，个人软件将会强势回归。

（注：P2通常指优先级2级的bug，在软件开发中属于比较重要需要修复的问题，仅次于最高优先级P1）

演示质量的陷阱

一个越来越常见的现象是：团队们用 AI 快速做出一个令人惊艳的 Demo，在“幸福路径”下表现得很棒，投资人和社交媒体都称赞不已。但当真正的用户来使用时，就会暴露出各种问题：

• 提示信息根本不符合普通用户的理解

• 稍微超出预期的操作就会导致程序崩溃

• 混乱的 UI 状态从未被真正梳理过

• 无人关注的可访问性问题（Accessibility）

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

这些问题不仅仅是“优先级 2 的 Bug”。它们往往决定了软件是被用户“勉强接受”还是“真心喜爱”。

被遗忘的打磨过程

要想让软件真正做到“自助式”（用户无需随时联系客服），需要完全不同的思维方式：

• 对错误信息孜孜不倦地打磨

• 在糟糕的网络条件下测试

• 在所有边界情况都做优雅的处理

• 让功能“能被发现”并易于使用

• 和真正的、常常不那么懂技术的用户一起测试

这种对细节的关注（也许）无法单纯靠 AI 生成。它更来自于对用户的共情、丰富的实践经验，以及对软件打磨的极致追求。

个人软件时代的复兴

我相信，我们将会看到一个“个人软件开发”重新崛起的时代。随着市场上充斥着大量“AI 生成的 MVP”，真正能脱颖而出的，往往是那些由开发者精心雕琢的产品，他们：

• 以工匠般的态度审视自己的作品

• 在意那些“看似微小却不可或缺”的细节

• 真正从用户体验全局出发

• 重视各种极端使用场景

• 努力让软件实现“真正自助”

有意思的是，AI 工具或许能推动这种新“工匠精神”的发展。因为 AI 可以处理许多繁琐的基础工作，从而让开发者有更多时间和精力来打磨用户体验和细节。

结语

AI 并没有让我们的软件“质的飞跃”，或许是因为软件质量本就不是由“开发速度”来决定的。软件开发中最艰难的部分——理解需求、设计可维护的系统、处理各种边界情况、兼顾安全和性能——依然需要人类的判断力。

AI 真正的价值在于让我们迭代、试验得更快，通过加速探索让我们可能找到更好的解决方案。但这只有在我们保持良好的工程实践、并将 AI 当作工具而非“万能替代品”时才能实现。请记住：我们的目标不是“更快地写更多代码”，而是要“构建更好的软件”。如果使用得当，AI 可以帮助我们实现这一目标。但要知道，如何定义“更好”以及如何达成，仍掌握在我们自己手中。

你在使用 AI 辅助开发方面有什么经验或见解吗？欢迎在评论区分享你的故事和想法。