AI 编程工作流终极版

探索为什么大型项目会崩溃

几个月前，我的 AI 编码工作流看起来像这样。

Prompt.
Generate.
Copy.
Run.
Error.
Prompt again.
Generate.
Break something else.
Fix that.
Celebrate.

如果你曾经用 AI 构建过什么，你可能经历过这个循环。

说实话，我喜欢它，现在仍然喜欢。随性编码让构建变得有趣起来。

曾经需要我花几周时间才能实现原型的想法，突然间在一个晚上就活了过来。与其花几个小时搭建样板代码，我可以直接跳到创建阶段。感觉就像有一个资深工程师 24/7 坐在我身边。

有一段时间，我认为这就是软件开发的未来。

然后我尝试构建一些更大的东西。那时一切都崩溃了。

让我们快速回顾一下 vibe coding 实际上是什么。

如果你曾经打开 Claude、Codex、Gemini、Cursor、Windsurf 或你最喜欢的 AI 编码工具，然后输入类似"给我构建一个仪表板"的内容，恭喜。你正式成为一个随性编码者。

工作流非常简单。你写一个 prompt，AI 生成代码，你复制它，运行它，注意到有点不对劲的地方，调整 prompt，再生成一次，重复直到一切看起来足够好，以至于你说服自己你会"稍后清理一下"。

你永远不会在稍后清理。

说实话，这不是批评。这正是 vibe coding 首先变得如此受欢迎的原因。它消除了开始时的无聊部分。曾经在笔记本里躺了好几个月的想法，突然间在一个周末就变成了工作原型。与其花数小时编写样板代码，我们可以直接跳到构建。

这真的感觉像软件开发解锁了创意模式。

破损导航栏的多元宇宙

一切都很棒，直到项目变大。你让 AI 改一个按钮。它改了导航栏。你让它修复导航栏。

现在身份验证坏了。你修复了身份验证。一半的样式消失了。

到了这个时刻，你的聊天历史看起来不像软件开发，更像是一对夫妻的治疗会话。

"我让你改一件事。"

"我知道，但我以为这样会更好。"

"我从没要求过这个。"

有趣的是，我很长时间都责怪 AI。然后我看了看我的 prompt。

"给我构建一个项目管理应用。"

就这样。没有需求。没有架构。没有约束。只有想法。

回顾起来，我期望 AI 能读懂我的想法。事实证明，它也错过了那个功能更新。

我们需要一个更好的计划

传统软件开发从来没有从代码开始。它从理解问题开始。用户是谁？我们在构建什么？哪些功能真正重要？哪些可以等到第二版？

这就是软件开发生命周期（SDLC）一直鼓励我们做的事。

在 vibe coding 中，包括我在内的很多人意外地颠倒了这个过程。我们先生成代码，然后在对话进行到一半时才弄清楚自己想要什么。

对于快速原型？那完全没问题。

对于一个会增长的项目？那就是裂缝开始出现的地方。

我还注意到了另一件事。随着对话变长，AI 开始忘记上下文，修复一个问题时引入另一个问题，或者信心十足地生成我从未要求的东西。

起初，我称之为幻觉。现在我认为那些时刻中的许多有另一个原因。我一开始就没有给它一个清晰的计划。

随着 AI 生成的项目变得更大，开发者自然地开始将更多的工程实践带回工作流。

测试变得更加重要。

与其接受 AI 生成的任何东西，我们会验证它、编写测试、修复问题并迭代。这让项目更加可靠，减少了很多意外的 bug。

第一次，感觉 AI 有了一张安全网。但我仍然觉得缺少什么。

测试告诉你是否正确地构建了这个东西。它不会告诉你是否在构建正确的东西。

我仍然在写代码后进行规划，而不是在之前。那才是真正的问题。

有趣的是，我没有某个早晨醒来并想，

"今天就是我成为 spec 驱动开发者的日子。"

这是意外发生的。

在构建我最近的一个项目时，我发现自己在生成一行代码之前，花了将近一个小时来写下需求。我实际上需要哪些功能？什么应该永远不变？哪些组件应该是可重用的？成功是什么样子？

只有在回答了这些问题之后，我才让 AI 写代码。

结果让我吃惊。

它不完美。仍然是 AI，但与其重新生成相同的屏幕十次，我反而在进行小的改进而不是完全重写。

然后它终于点醒了我。

我的 prompt 没有变得更好。它们变得更长了。而且它们根本不再是 prompt 了。

它们是规格说明。我没有意识到，我已经停止要求 AI 为我弄清楚。

我开始给它一个蓝图。

至少从我的角度来看，Spec-Driven Development 不是关于替代 vibe coding。

它是关于给 vibe coding 一个方向。与其从以下开始：

"给我构建一个作品集网站。"

我现在开始回答问题。

这个作品集是为谁的？

它应该包含哪些页面？

它应该使用什么技术？

哪些组件应该保持可重用？

什么以后不应该被改变？

成功的结果实际上是什么样子？

一些 AI 工作流在 spec.md、requirements.md、tasks.md 或类似的规划文档中捕获这些决策。文件名不是重要的部分。

重要的是思考。你不再要求 AI 弄清楚一切。你给它一个蓝图，而不是一块空地。令人惊讶的是，当你成为一个更好的规划者时，AI 会成为一个更好的开发者。

那时这篇文章的标题终于对我有了意义。

终局不是 Claude。不是 Gemini。不是 Codex。不是一个更好的 prompt。甚至不是 AI。

终局是学会在让 AI 为我思考之前先自己思考。

这些天，在我让 AI 写代码之前，我通常花时间创建或审查一个实现计划。

有时候我自己写。有时候我让 AI 生成第一稿，然后我编辑它。我删除不必要的功能，添加缺失的需求，在生成任何代码之前定义约束。

讽刺的是，在编码前花费更多时间让我完成项目更快。我重新生成得更少。我浪费的 token 更少。我花更少的时间说，

"不...不是这样。"

花更多时间审查实际推动项目前进的代码。

我不认为 vibe coding 会消失。

说实话，我希望它不会。

它仍然是探索想法、快速制作产品原型和学习新技术最快最有趣的方式之一。如果我在凌晨 2 点有了一个想法，我仍然会在打开 IDE 之前打开一个 AI 编码工具。

那没有改变。改变的是我的期望。

我不再期望 AI 从一句话就神奇地理解一切。AI 变得越有能力，清晰思考就变得越有价值。

我们已经从自己写每一行代码发展到与 AI 合作。也许下一个演变不是成为一个更好的 prompt 工程师。

也许它是成为一个更好的软件工程师，知道如何利用 AI 为自己服务。

我很好奇最近几个月你的工作流是否改变了？你仍然完全在做 vibe coding，还是开始在让 AI 生成代码前进行更多规划？

我非常想听听你最近是如何用 AI 构建的。可以在 LinkedIn 上与我联系。我真的很想听听你是如何用 AI 构建的。

P.S. 随性的感觉会回来的。

某些评论可能只对登录用户可见。登录以查看所有评论。

关于进一步的操作，你可能考虑屏蔽这个人和/或举报滥用