氛围编程：终局
几个月前，我的AI编码工作流程大致是这样的。
Prompt.
Generate.
Copy.
Run.
Error.
Prompt again.
Generate.
Break something else.
Fix that.
Celebrate.
如果你曾经用 AI 构建过什么，你很可能经历过这个循环。
老实说，我喜欢它，现在依然喜欢。Vibe coding 让构建重新变得有趣。
曾经需要数周才能做出原型的主意，一夜之间就活了过来。我不必花几个小时搭脚手架，而是可以直接投入创造。感觉就像有一位高级工程师 24/7 坐在我身边。
有一段时间，我以为这就是软件开发的未来。
然后我尝试构建更大的东西。就在这时，一切都崩了。
无限提示
让我们快速回顾一下 vibe coding 到底是什么。
如果你曾经打开过 Claude、Codex、Gemini、Cursor、Windsurf 或你最喜欢的 AI 编码工具，然后输入类似 “给我建一个仪表盘，” 这样的内容，那么恭喜你。你正式成为一名 vibe coder。
工作流程简单得令人发指。你写一个提示词，AI 生成代码，你复制、运行，发现有点不对劲，调整提示词，再次生成，然后不断重复，直到一切看起来足够好，好到你说服自己“以后再来清理”。
剧透警告。
你以后永远不会清理。
老实说，这不是批评。这正是 vibe coding 一开始就如此受欢迎的原因。它消除了入门时无聊的部分。曾经在笔记本里待了好几个月的想法，突然在一个周末变成了可用的原型。我们不用花几个小时写样板代码，而可以直接开始构建。
那种感觉，就像是软件开发解锁了创造模式。
破碎导航栏的多元宇宙
一切都美好无比，直到项目变大。你让 AI 改一个按钮。它改了导航栏。你让它修导航栏。
现在认证崩了。你修好认证。一半样式又消失了。
到这个时候，你的聊天记录看起来不像软件开发，更像是一对情侣的治疗对话。
“我让你改一件事。”
“我知道，但我觉得这样更好。”
“我没让你做这个。”
听起来耳熟吗？
有趣的是，我怪罪AI很长时间了。然后我检查了自己的提示词。
“给我建一个项目管理应用。”
就这样。没有需求。没有架构。没有约束。只有氛围。
回想起来，我当时是期望AI能读懂我的心思。结果，它也跳过了那个功能更新。
我们需要一个更好的计划
传统软件开发从来不是从代码开始的。它始于理解问题。用户是谁？我们要构建什么？哪些功能真正重要？哪些可以等到第二版？
这正是软件开发生命周期（SDLC）一直鼓励我们做的。
在氛围编码（vibe coding）中，包括我在内的许多人意外地颠倒这个过程。我们先生成代码，然后在对话进行到一半时才弄清楚我们想要什么。
对于一个快速原型？这完全没问题。
对于一个将要持续成长的项目？裂痕就开始显现了。
我还注意到另一件事。随着对话越来越长，AI开始忘记上下文，修复一个问题又引入另一个问题，或者自信地生成我从未要求过的东西。
起初，我称之为幻觉。现在我认为那些时刻有许多是另一个原因造成的：我一开始就没有给它一个清晰的计划。
规格的崛起
随着AI生成的项目变得越来越大，开发者们自然开始将更多的工程实践带回工作流程中。
测试变得更加重要。
我们不再接受AI生成的任何东西，而是验证它、编写测试、修复问题并迭代。这使项目可靠得多，也减少了许多意料之外的bug。
第一次，感觉AI有了一张安全网。但我仍然觉得少了些什么。
测试告诉你是否正确地构建了东西。它不会告诉你是否在构建正确的东西。
我仍然是在写完代码后才做计划，而不是在这之前。那才是真正的问题。
有趣的是，我没有在哪个早晨醒来时想，
“今天，我成为了一名规格驱动的开发者。”
这是偶然发生的。
在构建我最近的一个项目时，我发现自己花了将近一个小时写下需求，然后才开始生成一行代码。我实际上需要哪些功能？哪些东西永远不应该改变？哪些组件应该是可复用的？成功到底是什么样的？
在回答了这些问题之后，我才让AI编写代码。
结果让我大吃一惊。
它并不完美。它仍然是AI，但我不再是十次重新生成同一个屏幕，而是做小幅改进，而不是完全重写。
然后我终于恍然大悟。
我的提示词并没有变得更好，而是在变长。而且它们已经不再是真正的提示词了。
它们是规格说明书。不知不觉中，我已经不再让AI替我想明白事情了。
我开始给它一份蓝图。
终局
至少在我看来，规范驱动开发并不是要取代氛围编程。
而是给氛围编程一个方向。而不是从下面这样开始：
“给我建一个个人作品集网站。”
我现在从回答问题开始。
这个作品集是为谁准备的？
它应该包含哪些页面？
它应该使用哪些技术？
哪些组件应该保持可复用？
以后哪些内容不应该更改？
一个成功的结果实际上是什么样的？
一些AI工作流会将这些决策捕获到诸如spec.md、requirements.md、tasks.md之类的文件中，或类似的规划文档中。文件名并不是重点。
重要的是思考过程。你不再要求AI把所有事情都想清楚，而是递给它一张蓝图，而不是一块空地。令人惊讶的是，当你成为更好的规划者时，AI会成为更好的开发者。
就是那时，我终于理解了这篇文章的标题。
终局不是Claude，不是Gemini，不是Codex，不是更好的提示词，甚至不是AI。
终局是在让AI替我想之前，学会自己先思考。
片尾彩蛋
如今，在我让AI编写代码之前，我通常会花时间创建或审查一份实施计划。
有时我自己写。有时我让AI生成初稿，然后我再编辑。我会删除不必要的功能，补充缺失的需求，并在生成一行代码之前定义约束条件。
讽刺的是，在编码前花更多时间反而让我更快地完成项目。我重新生成的次数更少，浪费的令牌更少，也更少花时间说：
“不……不是那样。”
而是花更多时间审查真正推动项目前进的代码。
我认为氛围编程不会消失。
老实说，我希望它不会。
它仍然是探索想法、构建产品原型和学习新技术最快、最令人愉快的方式之一。如果我在凌晨两点有个想法，我仍然会先打开AI编程工具，再打开我的IDE。
这一点没有改变。改变的是我的期望。
我不再期望AI能从一句话中神奇地理解一切。AI的能力越强，清晰的思考就越有价值。
我们已经从自己编写每一行代码演变为与AI协作。也许下一个演变并不是成为更好的提示工程师。
也许，这正是成为一位懂得如何利用AI优势的更好软件工程师的关键。
感谢阅读！
我很好奇，在过去的几个月里，你的工作流程发生变化了吗？你还在完全依赖“氛围编程”，还是已经开始在让AI生成代码之前做更多的规划？
我真的很想听听你如今是如何使用AI进行开发的。欢迎通过LinkedIn与我联系。我真的很想了解你使用AI构建项目的方式。
附言：那种“氛围感”终将回归。
