氛围编程上头，工程实践下头：自然语言编程的真问题

刘俊伟 2025-06-18 08:01 新加坡

CodeWisdom团队最新分享：“幻觉式自动化”跳跃不了“演示级生成”与“生产级落地”之间的鸿沟。

不久前，被媒体大肆吹捧为“AI写代码神器”的 Builder.ai 被曝“自动生成应用”不过是外包团队手工操作的障眼法。一时间，“AI创业”从神话跌入闹剧，令人唏嘘。然而即便如此，市面上仍不断冒出打着“AI软件工程师”旗号的新工具，几乎让人忘了，软件开发从不是一场魔术表演。自然语言编程的“奇迹时刻”真的来了，还是我们太想相信它已经来了？

为了验证这一点，我们以安卓APP开发这一具代表性的端到端复杂任务为评估场景，尝试测评了当前学术界、工业界与开源生态中呼声较高的自然语言编程工具，包括 MetaGPT、ChatDev、Bolt.new、Lovable、GPT-Engineer 等。实验结果显示，这些工具确实展现出初步的“任务驱动”能力，例如在短时间内生成可运行原型，甚至能完成一定程度的业务流程。但当面对真实开发中的架构复杂性、需求变更、模块协同等挑战时，它们往往难以为继，陷入“演示级生成”与“生产级落地”之间的鸿沟。

我们认为，这种落差的根源，在于当前自然语言编程工具过度依赖模型生成能力，却忽视了软件开发背后真正的核心：工程体系与系统认知。缺少软件工程的支撑，再强大的模型也难以摆脱“幻觉式自动化”的命运——看似惊艳，实则脆弱。自然语言编程最需要的，正是将AI能力嵌入到完整的工程闭环与协同机制之中。

VIBE CODING

“偏科”严重的开发能力

我们选择一个简单的安卓计时器APP作为开发场景，具体需求如下：

开发一个倒计时器应用程序，帮助用户有效管理时间。该应用应具备以下功能：

- 用户可以创建多个倒计时器，每个倒计时器可以自定义名称和时长。

- 启动倒计时后，应用会以全屏模式显示倒计时进度。

- 当倒计时结束时，用户会收到通知提醒。

- 倒计时器支持暂停、继续和停止操作。

- 用户可以查看以往倒计时的历史记录，并能重复使用之前的倒计时设置。

为了避免环境搭建和依赖配置等烦琐问题，我们利用Android Studio创建了一个脚手架项目作为初始代码上下文，并确保了在本地中可以顺利运行该项目。这是一个程序员进行安卓开发的典型初始场景，即具备一个可运行的项目脚手架代码和一份项目的需求说明。

随后，我们从不同渠道收集了一些常见的端到端自然语言编程工具，包括学术界工具如MetaGPT、ChatDev；闭源商业工具如Bolt.new、MGX、 Lovable; 以及开源社区工具如GPT-Engineer、Bolt.diy，介绍如下：

	MetaGPT：模拟真实软件开发团队的角色分工与协作流程，以一句话需求做输入，即可完成目标应用开发的多智能体工具。
	ChatDev：模拟软件公司的多智能体开发工具，在软件开发的每个环节，通过两个智能体的协同完成需求到最终软件的端到端开发。
	Bolt.new：Stackbliz团队构建的自然语言编程工具，可以通过Figma和GitHub导入项目，在浏览器完成提示、编码、部署的全流程。默认使用Claude 4 Sonnet模型驱动。
	MGX：全名MetaGPT X，同样是Web端的自然语言编程工具，可以输入文件和需求，并自动组建软件团队，为用户完成可视化开发流程的软件开发体验。
	Lovable：面向非专业程序员的AI自然语言编程工具，偏向于前端Web页面的设计与实现，不支持修改基模型。
	GPT-Engineer：Lovable的早期开源版本，在GitHub上有超过54k的star数，支持从头创建项目和在存量项目上进行二次开发。
	Bolt.diy：Bolt.new的开源版本，在GitHub上有超过16k的star数，主要依赖开源社区的力量维护更新，且支持配置不同基模型。

除Bolt.new和Lovable不能自行配置模型外，我们选择GPT-4o作为其他工具的基模型。

在完成以上步骤后，我们开始尝试使用各个工具开发目标应用。然而不曾想，在安卓增量开发这个场景上，一大批AI软件工程师就已“出师未捷身先死”，包括ChatDev、MGX、Lovable、Bolt.diy。

ChatDev仅支持Python项目开发，且不支持预先导入存量项目，尽管它还是生成了代码，但是所有代码文件都堆在一个目录中，实际无法运行。

▲ ChatDev开发的代码堆积在同一个文件夹中

MGX仅将上传的文件作为参考，而不是在其基础上进行增量开发，尽管我们上传了Android的脚手架项目，但是它依然使用React + JavaScript + Tailwind CSS的技术栈进行Web开发。

▲ MGX上传的项目文件夹隔离在uploads中

Lovable不支持导入项目文件，因此无法实现存量项目上的增量开发。尽管不符合我们开发安卓应用的目的，我们依然尝试了使用这些工具以Web应用形式开发，在这个规模较小的应用上，这些商业工具确实开发出了实现所有需求的Web应用，展现出其出色的项目级别代码能力。

▲ MGX（左）和Lovable（右）以Web应用形式开发的计时器应用

有趣的是，当我们进一步询问是否可以转为安卓应用时，Lovable 表示其采用了 Capacitor 这一原生应用开发框架，从而能够以混合应用的形式部署至 Android 平台。这种方式也反映出当前此类工具在支持移动端应用开发方面的主流技术路径。

工业界的两个工具虽然都宣称可以进行增量开发，但是在Bolt.diy使用时遇到了一个配置的bug，项目文件没有被正确导入，最终也只能以Web应用形式进行了开发。然而，其开发的Web应用效果相较之下UI界面较为简陋，且出现了需求缺失，例如历史记录中的计时器没有重启功能，也没有全屏倒计时功能。

▲ Bolt.diy开发的Web应用，UI界面较为简陋，缺失部分功能

总结

目前的许多端到端开发工具在适用场景上存在较大局限，大部分工具只能支持Python（如ChatDev）或Web应用开发（如MGX、Lovable），此外，虽然很多工具（如MGX和Lovable）支持导入外部文件，但是这些外部文件仅被视为参考，而非在其基础上做增量开发。尽管如此，一些工具（如Lovable）可以通过一些Native APP的开发框架实现多端应用的效果，以此来扩宽所开发应用的实际可部署场景范围。

VIBE CODING

参差不齐的开发效果

我们进一步测试剩余可以支持安卓项目增量开发的工具，即MetaGPT、Bolt.new和GPT-Engineer，对目标计时器APP的开发效果。

首先是MetaGPT，其增量开发功能配置起来体验较差，尽管提供了脚手架项目，MetaGPT依然会为自己编写的代码创建单独的文件夹，我们通过阅读源码，发现为Git仓库打上一个“base”的标签就可以实现增量修改，虽然另辟蹊径，但终究是实现了增量开发。然而，开发时出现了一些较为低级的错误，例如将代码以外的文字也输出到了文件中；此外，最终开发出来的应用有多达1000多个的错误，尝试进行了几轮修复以失败告终，开发终告失败。

▲ MetaGPT开发的APP以BUG过多无法修复告终

我们较为顺利的完成了GPT-Engineer配置，尽管生成的代码存在一些报错，但是经过简单的反馈修改后，我们终于得到了一个可运行的APP，如下图所示。然而其实际的开发效果并不令人满意，经测试主页上的“Start”和“Create New Timer”按钮实际均不可用。我们进一步要求GPT-Engineer修复这一问题，然而这一次，我们发现页面只要一刷新就会有一个新的计时器被创建，通过查看源码，我们发现这是由于新增的timer创建代码错误地放置在了按钮的文本内容区域，⽽不是在 onClick 回调函数中，这导致该页面每次渲染都会重新触发添加timer的逻辑。这是一个非常简单的增量开发案例，只需要在onClick函数中添加一句创建代码即可，由于这是一处极其微小的修改，它几乎不涉及额外的上下文和知识补充，因此它暴露出大模型在增量开发的定位问题上依然存在一些根本性的逻辑问题。

▲ GPT-Engineer开发的计时器APP。左：按钮不可用；右：创建代码逻辑出错

最后，我们尝试了Bolt.new，不同于MGX仅将导入的文件作为参考，Bolt.new可以直接导入GitHub项目并在其基础之上实现增量开发。在我们的目标任务上，Bolt.new取得了最优的效果，通过Claude 4 Sonnet模型的加持，它耗时6分钟就完成了目标应用的开发。不过它依然存在一些逻辑问题，例如倒计时开始后，秒表数字没有减⼩。

▲ Bolt.new开发的倒计时APP

不过我们也观察到，Bolt.new主动实现了一些需求中没有提及的功能，例如它支持切换暗色模式，以及配置倒计时结束时的通知模式为“铃声/震动”。

总结

少数可以支持安卓增量开发任务的自然语言编程工具，如MetaGPT、GPT-Engineer、Bolt.new，开发的实际效果参差不齐。MetaGPT开发的APP问题较多无法运行；GPT-Engineer开发的APP虽然可以运行，但是功能基本没有实现，且多轮迭代无法修复；Bolt.new在Claude 4 Sonnet的加持下实现了令人耳目一新的开发效果，尽管存在部分功能问题，但在一两轮迭代中均可以完整解决，此外还自行添加了一些功能以优化体验。

VIBE CODING

力有不逮的软件规模

在前两轮的测试之下，只有Bolt.new经受住了所有的考验，其展现出的编程能力可以轻易完成计时器这类简单应用的开发，因此我们进一步挑战用它开发一些更加复杂的应用。

我们首先要求它开发一个茶饮点单的APP，需求如下：

为茶饮店开发一款客户端点单应用。系统预先在数据库中内置了一套产品和品类信息。使用该应用程序时，用户必须先注册并登录。用户可以按品类浏览饮品选择，也可以使用关键词搜索特定商品。每种饮品都可以通过三种选项进行定制：甜度、含冰量和额外配料。用户可以将心仪的饮品添加到购物车中，在购物车中查看商品清单和总金额。该应用程序采用“预付费代币”系统。每个用户初始获得100个代币，可用于购买。如果余额不足，支付将失败。用户还可以随时虚拟充值代币。此外，用户随时可以更改账户密码。购买成功后，用户将收到30分钟后取餐的通知。该应用程序还提供查看过往订单的功能，并且有快速重新下单之前购买的商品的选项（“重新下单”）。

经过10分钟的开发和5分钟的Debug，应用顺利开发完毕。出乎意料的是，这一相对复杂的应用（2365行，27个代码文件）对Bolt.new来说似乎也不在话下。我们甚至发现它从图库网站上搜索并提供了一些默认的图片链接，使得APP的完成度更高。

▲ Bolt.new开发的茶饮点餐APP，提供了默认图片

难道Bolt.new真的已经可以替代程序员了？我们进一步向它的开发能力发起了挑战，这一次，我们选择开发一个类多邻国的外语学习应用，我们尝试将需求表述得更笼统一些：

设计一个类似 Duolingo 的游戏化语言学习应用程序，包含以下功能：

- 用户可以注册并设置自己的个人计划（目标语言、连胜记录目标、经验值 XP目标）

- 预先编排的“语言树”路径学习技能和课程

- 完成多样化的练习（翻译、选择题、听力、口语、填空、配对）

- 通过间隔重复机制实现自适应学习

- 包含进度追踪功能（XP、每日目标、连胜记录、排行榜、徽章）

- 提供通知与提醒功能

- 支持应用内购买和订阅

- 提供阶段性的评测（小测验、分级测试）

- 拥有社交功能（添加好友、俱乐部）

- 分析仪表盘（学习进度与用户行为分析）

这一次Bolt.new花费了20分钟左右的时间进行开发，一共编写了4000多行代码，包含52个文件，APP运行的效果看起来非常棒。

▲ Bolt.new开发的类多邻国APP

然而，经过与需求的对比，我们发现它实际只实现了部分的功能需求，有接近75%的功能需求被完全忽视，如用户注册、商店内购、阶段评测、社交功能等，此外，在APP的开发过程中，尽管我给出的需求如此模糊，例如我并没有提及内购功能应该包含哪些道具，但AI并没有与我沟通任何需求的细节，而且是凭借自己对功能的理解实现了所有内容。这虽然使得这次APP的开发流程非常快速，但也导致作为用户的我数次出现了“惊讶时刻”。

总结

尽管Bolt.new实现了效果非常不错的安卓APP开发效果，但通过适当增加APP难度，还是轻易触及了其能力边界，使其出现了需求遗漏的问题，此外，也暴露了其完全不包含任何需求澄清步骤的问题。这些都导致用户在面对已经开发部署完的APP时，频频出现一些疑惑和惊讶的时刻。

VIBE CODING

隐患重重的代码质量

我们进一步对已开发的部分进行检查，发现这个APP光鲜亮丽的外表下实际存在着诸多问题。概括下来主要有以下四类：

（1）数据缺失问题：例如数据库中缺少对应习题数据，导致课程无法启动；

（2）数据绑定问题：页面上很多数据只是写死在页面状态中的静态数据，没有绑定数据库，也不会发生任何更新；

（3）无效功能：一些页面跳转和功能按钮实际并不生效。

（4）功能逻辑错误：例如答案错误时无法给出正解；单词匹配问题却给了选择题的UI界面等。

▲ 类多邻国APP的问题示意图1

▲ 类多邻国APP的问题示意图2

我们进一步查看源码来了解这些问题背后的原因，结果发现，AI生成的代码存在的质量问题着实不少。例如对于数据相关问题，一般是由于AI将数据写死在了临时的页面状态数据中，尽管相关的数据库文件它已经创建，却没有真的从数据库中进行数据读取；而在代码实现上，我们发现了大量待补全代码，例如，即使Profile页面已经创建，但是AI还是忘记了编写跳转到Profile页面的代码。这些都体现出模型在全局代码生成能力上的不足，当项目规模增加后，依然会出现顾头不顾尾的情况。

▲ 页面显示的实际上只是写死的静态数据

▲ 许多功能逻辑均空缺

此外，项目中也存在着一些重复代码、未进行错误处理或将错误代码直接抛在UI上的质量问题。这些问题虽然通过简单的反馈就能修复正确，然而把它们挨个找出来也消耗了大量的时间。此外，人力检查也始终无法保证功能验证的完整性，然而我们观察到，整个APP的开发过程中没有编写过任何测试代码，整个系统的实现更像是靠着模型的编码能力强行撑起，这让人对它所生成的软件质量更加忐忑。

不过，单单从演示的角度来说，它确实完整呈现了应用各个页面的实际样式和跳转逻辑，结合前面发现的功能缺陷和数据遗漏问题，我们越发觉得，相较于一个真实可用的应用产品，它更像是一个APP的演示原型。

总结

尽管Bolt.new生成了一个看似完成度很高的应用，但是实际存在诸多的质量问题。在功能实现上，它存在数据和逻辑上的实现错误；在代码质量上，它存在重复代码、错误处理等问题；此外，整个编码过程未编写任何测试代码，进行任何质量保障。因此，相较于一个成熟的应用，Bolt.new开发的APP更像是一个功能更完善的演示原型。

VIBE CODING

将错就错的迭代开发

我们进一步尝试补齐第一轮开发中被遗忘的功能，以“社交”功能为例，Bolt.new额外花费了20分钟，再次生成了2000余行增量代码。然而，我们发现在这次迭代中，AI在没有与我沟通任何关于这个“社交”功能细节的情况下，便设计了好友对话、社群发帖、学习挑战等功能，然而实际上我对“社交”功能的实现是像真实的多邻国应用一样，虽然支持添加好友，但好友之间无法对话；用户只能看到其他人更新的学习状态，而非主动发帖；学习挑战则更是一个完全杜撰的功能。

▲ Bolt.new迭代开发的“社交”需求

如果说之前它在计时器补齐中添加的暗色模式以及“铃声/震动”提醒是一些正向提升，这次开发补充的功能则更让人觉得“自以为是”。而这样的“自以为是”，正是由于和用户缺乏需求问题的沟通。需求工程作为软件工程的一个重要分支，在软件开发的过程中有其关键承载了确定目标业务的关键功能，但是在当前的自然语言编程工具中，这一问题依然没有得到重视。

此外，我们也注意到，已开发功能中的问题并没有得到解决，新功能的开发在原有上下文的基础上将错就错。例如，代码中实际没有注册功能，这意味着不会出现其他用户，社交自然无从谈起。此外，更新的“学习挑战”实际上并不会随着学习发生任何的进度更新，它同样只采用了样本数据进行了简单的UI展示。从这些问题中不难看出，Bolt.new实际对现有项目的开发情况缺少了解，它也没有建立其新功能和已有功能之间的逻辑联系，导致增量生成的代码只是将错就错，进一步完成了一个精致但不可用的原型。

总结

Bolt.new支持在原有应用上进行增量开发维护，但这样的开发实际上缺少对软件全局的视野，这使得它意识不到新开发的功能实际不可用（例如没有注册不可能社交），也没有建立起新功能和原有功能的逻辑关系（例如学习挑战的进度不会随着学习而更新），归根结底，这样的迭代开发只是在错上加错，终究会导致程序的崩溃。

VIBE CODING

写在最后

总的来看，自然语言编程工具的快速迭代和令人惊艳的代码生成能力，确实展现了AI在软件开发领域的巨大潜力。对于工程师来说，这无疑是一项有力的赋能工具，让他们将更多精力投入到更高层次的设计与决策、需求的表达与结果的验收中。但我们也必须理性认识到，当前的自然语言编程仍停留在“高生成效率，低工程成熟度”的阶段，其在多个关键维度上暴露出值得深思的短板。

首先，当前工具的适配性仍较为有限，主要集中在 Python 脚本和 Web 前端等标准化场景，对于如 Android App 等生态复杂的平台型开发，仍存在较大适配障碍。此外，这类工具普遍不支持“增量式开发”，更偏向一次性生成，难以在已有代码基础上进行局部修改和功能扩展，不利于真实项目中的迭代演进。

更值得警惕的是，即便在表现最优的工具中，若缺乏对软件工程方法论的系统融入，其开发能力也极易触及瓶颈。

首先，当前自然语言编程在需求理解方面存在严重脱节。一方面，它常常“自动忽略”用户的一些需求，导致应用功能不完整；另一方面，它又常常“自动补全”用户未明确指定的功能行为——有些结果令人惊喜，但有些时候却是偏离预期，导致沟通成本上升。本质上，这是因为模型缺乏“需求确认”，其行为建立在概率驱动而非语义共识之上。

另一方面，当前自然语言编程工具在大量生成代码时依然缺乏有效的质量控制和保障手段。实际代码中不仅没有测试，而且逻辑漏洞频出，注定难以承担关键业务系统的开发责任，更适合作为原型工具而非正式交付。另一方面，在检查功能实现时，用户往往仍需频繁打开黑盒环境以查看源码，以理解AI做出的设计决策。这种“回头看源码”的模式本身就违背了自然语言编程追求“无需理解代码即可开发”的初衷。

最后，当前自然语言编程工具在处理增量开发、需求变更与版本演进等方面普遍缺乏“系统视角”，无法建立起项目级的上下文管理机制。这种“局部生成，全局割裂”的开发方式，极易在复杂系统中形成错误传播和语义失真，最终导致“错上加错”的技术风险。

归根结底，代码生成能力≠开发能力，更不等于交付能力。软件开发从来不是单点智能的展示，而是对架构设计、需求理解、模块协同与工程实践的系统整合。当前的自然语言编程工具，恰恰缺乏对软件工程复杂性的深度认知与融合能力，这正是其技术天花板的根本所在。

因此，我们在享受“氛围编程”所带来的效率快感的同时，更应回归理性，认识到AI必须在软件工程框架内完成深度嵌入，才能实现从“演示工具”到“生产平台”的跃迁。唯有将大模型的生成力与工程化的系统力深度耦合，AI编程工具才能真正迈入“可靠交付”的未来。