我花了3个月与AI进行氛围编程。以下是实际发生的情况

剧透：这就像管理世界上最有才华的实习生，而这个实习生恰好完全疯了。

产品人员请注意：除了毒品之外，这是你能尝试的最令人上瘾的东西。我只能推荐它！——不是毒品部分，以防不清楚。

如果你想知道为什么我有一段时间没写了，那是因为我把所有空闲时间都献给了提示之神，更具体地说，是氛围编程。

我的氛围编程技术栈

Lovable，编码代理

我选择Lovable是因为我的低/无代码工具参考Éfrem Filho推荐了它。这是一个非常产品经理友好的工具，包括令人惊叹的一键部署功能。这意味着你可以在互联网上任何地方立即访问，而无需处理部署管道、AWS等。你点击一个按钮，它就上线了。你甚至可以通过几次点击获得自定义域名。

Lovable界面：左侧聊天，右侧预览（或代码）

对于非技术人员来说，这很神奇。考虑到AWS基础设施的产品化和可访问性，工程师可能无法完全理解为什么非工程师难以部署某些东西。但对于最多只在localhost上编码过的非技术人员来说，这很有赋能作用。

Supabase，后端

Supabase为你的项目提供真实数据库、执行后端代码的能力（与在浏览器中运行相反，这对安全性至关重要）、用于文件存储的S3桶、密钥库以及实现身份验证的简单方法。

幕后，Supabase使用AWS，数据库是Postgres。因此，如果你的应用程序起飞，理论上真正的工程师可以将其从Supabase移植到AWS以降低成本。

PS：截至今天，Lovable具有后端功能（测试版），因此当你阅读本文时，可能不需要那么多Supabase。

Claude，UI设计师

每当我需要UI设计时，我都会向Claude简要介绍。它可以在聊天界面上编写和渲染代码。Lovable设计的屏幕通常非常通用。为了绕过这种平淡，我的一个产品经理朋友给了我提示，发送具有类似氛围的截图，这样Lovable可以获得灵感。

如果你认为这很糟糕，你应该看看我在Figma中的表现。

可以构建什么？

如果它在浏览器上运行，你很可能可以构建它。Lovable特别擅长CRUD。

依赖大量精细UX的东西很棘手，但也可以构建。例如，我构建了一个简单的路线图管理工具，没有昂贵工具的所有臃肿功能：

在Lovable的Launched网站上有许多真实示例。

非技术人员能用AI构建吗？

这取决于你所说的"构建"是什么意思。

如果"构建"意味着简单的原型和内部工具，那么是的。但是生产级？可能还没有。

强调"还没有"，因为这些事物正在以惊人的速度发展。

将当前的氛围编程工具视为一个非常初级的开发人员，他拥有出色的代码语法知识，可以以极快的速度完成工作，但判断力和品味很差。Lovable和任何其他编码代理很容易混淆，进入奇怪的兔子洞，撤销它刚刚做的事情来修复错误，复制已经存在于其他地方的功能等。作为一个非技术产品经理，如果没有Stack Overflow ChatGPT，我几乎无法编写for循环，如果我能注意到这一点，我只能想象真正的工程师在探索100%氛围编码的存储库时的寒意。

所有这些意味着你必须指导工具做出明智的选择。如果你是100%非技术人员，指导AI做出必要的软件架构选择将具有挑战性。

也就是说，第一个前沿已经触手可及：替换那些感觉应该像软件但目前是电子表格的古怪内部事物。

经验教训 #1：像对待软件开发实习生一样对待它

编写PRD、带有验收标准的用户故事、展示屏幕、详细说明交互……就像你与真正的软件工程师一样。你不能只说"构建一个待办事项列表应用程序"。这与工程师一起工作不行，与AI一起工作也不行。

我经常使用Claude或ChatGPT帮助我编写PRD和提示。我也喜欢这样结构化：

目标

你希望通过更改实现什么。

上下文

描述AI应该知道的所有内容，如交互、它应该做出的决策等。

约束

它应该遵守的指令——稍后详细介绍。

经验教训 #2：图像非常有帮助

带有UI和交互以及图的图像非常有帮助。Lovable似乎在这方面表现出色。

尝试解释订阅生命周期将如何工作。

对于UI设计，我经常使用Claude。

经验教训 #3：小迭代将让你更快达到目标

大更改会混淆AI。我学会了以微小增量工作，而不是要求完整功能：先让UI结构正确，然后添加记录创建，然后编辑，然后删除。一次一个部分。再次，就像你与人类开发人员一样。

经验教训 #4：使用清洁架构

如果我让Lovable自行其是，这是它将创建的软件架构：

氛围编码的架构。唯一的区别是建筑是站立的。

它可能在技术上有效，但每次你进行更改时，所有地狱都会崩溃，包括不相关的一切都会崩溃。

但作为非工程师，你如何帮助它创建更合理的东西？

我发现的技巧是使用Uncle Bob作为角色。我通常在我的提示约束中添加类似这样的内容：

你是Uncle Bob，总是计划和实施清洁架构、SOLID、DRY和其他最佳系统设计实践。

不要通过黑客方式实现更改。分析更改和当前代码，如果会使系统设计更健壮、可维护且易于将来更改，则重构/从头开始。

不要为实现目标而进行不必要或不相关的更改，除非它们会改进系统设计以实现目标。

不要对UI、UX、功能或行为进行不相关的更改。

记住删除未使用或已弃用的代码。

避免使事物"向后兼容"，因为这通常是一种逃避机制，用于系统不100%按预期行为的情况。

PS：Uncle Bob写了最有影响力的软件开发书籍之一《清洁代码：敏捷软件工艺手册》（2008），并且是软件工程中形式化SOLID原则的人。

这不能确保任何事情，因为LLM倾向于撒谎（“当然当然，我当然使用了SOLID原则”）。但至少它们更可能创建比萨尔瓦多·达利患有痴呆症想象的纸牌屋更好的基础。

经验教训 #5：当要求时进行重构

随着文件变大，Lovable将提示重构（通常只是将大文件分解为较小文件）。这至关重要。总是这样做。

但是……总是测试前后，因为Lovable可能通过这样做破坏功能，包括更改完全不相关的事物，如UI外观。

经验教训 #6：对大多数更改从聊天模式开始

Lovable有构建器模式和聊天模式。在构建器模式中，你提示，它编写代码，一次性完成。这通常会出错。我发现的最佳方法是使用聊天模式。在聊天模式中，它不更改代码，因此你可以使用它讨论更改。是的，你为此付费，但相信我，与尝试修复它通过一次性错误造成的问题相比，这种方式使用的积分更少。

在聊天模式中，我要求它制定计划并提出澄清问题。

我也强烈推荐使用聊天模式识别错误的根本原因。如果你不这样做，它将只是选择一个随机向量，并在每次你反馈错误仍然存在时加倍努力。

经验教训 #7：清除缓存以测试

有时你进行更改，然后尝试测试它，而……什么都没有改变。更多时候我发现浏览器缓存了系统的旧版本。

转到浏览器的开发工具并清除缓存：

清除站点数据以测试

PS：Spengler教育我有一种更简单的方法。转到"网络"选项卡并点击"禁用缓存"。

经验教训 #8：使用详细日志记录进行调试

如果你只给出你看到的错误效果，Lovable在调试方面会做得很差。要求它在有错误的功能上添加日志，然后将其粘贴回它以进行调试。

有时我也用ChatGPT这样做，但我发现当前版本的Lovable表现更好，我越来越少需要用另一个LLM做这个。我得到的一个建议，我还没有测试，是使用ChatGPT o3进行深入研究，因为它可以访问相同的GitHub存储库。然后从ChatGPT获取指令并将其粘贴到Lovable的聊天模式中。

经验教训 #9：使用Given/When/Then进行调试

描述问题和期望状态的有用格式：

问题：无法在空团队选择字段中用键盘选择团队

当前行为

给定团队选择模态打开且输入中当前未选择团队， 当通过键盘箭头导航+输入选择团队时， 然后团队未在团队输入中选择，团队输入保持为空。

期望行为

给定团队选择模态打开且输入中当前未选择团队， 当通过键盘箭头导航+输入选择团队时， 然后团队在团队输入中选择。

经验教训 #10：恢复到以前的工​​作版本

与人类软件工程相反，编写代码是过程中最便宜的部分。不要害怕丢弃代码，恢复最新的工作版本，然后重新开始。这比陷入错误死亡螺旋要便宜得多：

发生得太频繁了。

我使用的一种模式是：进行代码更改。 我测试更改。如果我对进展满意（例如，它完全按预期工作），我将该提交保存到历史记录（更改旁边的小标志）。 如果我不断更改事物并难以使其正确，我回到历史记录中最新保存的提交并恢复它。然后我重新开始，这次对潜在问题有更多了解，这导致我相应地更改我的提示。

氛围编程对产品开发的影响

当编写代码变成廉价部分，AI编写代码不需要技术专业知识时，有些人可能认为软件工程师将消失。甚至有一些团队要求产品经理与工程师的比例更高，而不仅仅是一个人。

但我的看法恰恰相反：工程师可能会承担一些产品管理职责，而产品经理和UX设计师将需要学习一些工程学才能独立交付。在某种程度上，我们正在从许多事物需要发现的流程过渡到可以更轻松地在生产中测试和迭代的流程。从某种意义上说，许多被丢弃的实验可以发布，仅仅因为编码部分变得快得多。因此，从待完成工作的角度来看，氛围编程将与"不做"竞争激烈。

如果你是产品人员，你还在等什么？开始构建。如果你不习惯这些，你可能会发现自己在未来处于困境。

在评论中留下你一直想构建但直到现在还没有资源的东西。