用 AI 快速生成全栈应用的工作流指南

"Vibe Coding" 全栈应用的结构化工作流

围绕"Vibe Coding"有很多炒作。你可能看过 AI 影响力人物声称，用几个工具和 prompt 就能在 15 分钟内构建 SaaS 应用。

但正如你可能已经猜到的，这些示例工作流相当薄弱。

是的，你可以复制一个落地页，或构建一个不错的 CRUD 应用，但你不可能用它们构建复杂的 SaaS 或内部工具。

但这并不意味着没有工作流能积极地增强你的开发流程。任何经历过不同 AI 辅助技术的人都能告诉你，这些工具中存在某种真正的魔力。

这就是为什么我花了几周时间研究最佳技术和工作流技巧，并通过构建一个功能完整的全栈应用来测试它们。

下面，你会找到我的诚实评价，以及我在使用 Cursor 和 Google 的 Gemini 2.5 Pro 以及坚实的 UI 模板时真正有效的工作流。

顺便说一句，我是通过在业余时间测试和构建全栈个人财务应用来想出这个工作流的，在整个过程中不断调整和改进。然后，在确定了一个好的模板和工作流后，我从头开始重建应用，并从开始到部署都完整录制，总共约 3 小时的 YouTube 视频（上面）。

本文是实现此工作流关键方法的总结。

第 1 步：奠定基础

现代全栈网络应用有很多活跃部分。试图让你的 LLM 连贯地将它们粘合在一起根本行不通。

这就是为什么你应该通过从坚实的基础开始并充分利用我们手中的工具来给你的 AI 助手一个帮助。

实际上，这意味着使用以下工具：

UI 组件库

样板模板

功能齐全的全栈框架

组件库和模板是给 LLM 一个已知基础来构建的好办法。它还消除了样式设计的猜测，并帮助这些样式在应用增长时保持一致。

使用功能齐全的全栈框架（如用于 JavaScript（React、Node.js、Prisma）的 Wasp 或用于 PHP 的 Laravel），可以降低拼接堆栈不同部分的复杂性。由于这些框架是有主见的，它们选择了一套能很好配合的工具，并且具有在幕后完成大量工作的好处。最终，AI 可以只专注于应用的业务逻辑。

以 Wasp 的主配置文件为例（见下文）。你或 LLM 只需定义你的后端操作，框架就会为你处理服务器设置和配置。此外，这个配置文件充当 LLM 在构建新功能时始终可以参考的中央"真实来源"。

app vibeCodeWasp {
  wasp: { version: "^0.16.3" },
  title: "Vibe Code Workflow",
  auth: {
    userEntity: User,
    methods: {
      email: {},
      google: {},
      github: {},
    },
  },
  client: {
    rootComponent: import Main from "@src/main",
    setupFn: import QuerySetup from "@src/config/querySetup",
  },
}

route LoginRoute { path: "/login", to: Login }
page Login {
  component: import { Login } from "@src/features/auth/login"
}

route EnvelopesRoute { path: "/envelopes", to: EnvelopesPage }
page EnvelopesPage {
  authRequired: true,
  component: import { EnvelopesPage } from "@src/features/envelopes/EnvelopesPage.tsx"
}

query getEnvelopes {
  fn: import { getEnvelopes } from "@src/features/envelopes/operations.ts",
  entities: [Envelope, BudgetProfile, UserBudgetProfile] // Need BudgetProfile to check ownership
}

action createEnvelope {
  fn: import { createEnvelope } from "@src/features/envelopes/operations.ts",
  entities: [Envelope, BudgetProfile, UserBudgetProfile] // Need BudgetProfile to link
}

//...

第 2 步：充分利用你的 AI 助手

一旦你有了坚实的基础，你需要为编辑器和 LLM 创建一套全面的规则。

要得到一套坚实的规则，你需要：

开始构建东西

留意 LLM（重复）未能满足你期望的时刻，并为它们定义规则

不断要求 LLM 帮助你改进工作流

不同的 IDE 和编码工具对你定义的规则有不同的命名约定，但它们的功能基本相同（我在这个项目中使用了 Cursor，所以我在这里参考 Cursor 的约定）。

Cursor 已弃用 .cursorrules 配置文件，转而使用包含多个文件的 .cursor/rules/ 目录。在这套规则中，你可以包含与编码风格相符的通用规则，以及特定于项目的规则（例如约定、操作、身份验证）。

关键是为 LLM 提供结构化的上下文，这样它就不必依赖更广泛的知识。

这具体意味着什么？这意味着告诉 LLM 你当前的项目和你将要构建的模板、它应该使用的约定，以及它应该如何处理常见问题（例如上面的例子图，取自教程视频的附带仓库）。

你也可以将通用策略添加到规则文件中，你可以在聊天窗口中手动参考。例如，我经常喜欢告诉 LLM"思考 3 个不同的策略/方法，选择最好的一个，并给出为什么选择它的理由"。所以我为它创建了一个规则，7-possible-solutions-thinking.mdc，每当我想使用它时就传入，省去我一遍遍输入相同内容的麻烦。

使用 AI 来评判和改进你的工作流

除此之外，我将这套规则视为一个流动的对象。在开发应用时，我从一套规则开始，并对其进行迭代以获得我寻找的输出类型。这意味着添加新规则来处理 LLM 会引入的常见错误，或克服不符合 LLM 的一般期望的特定项目问题。

当我修改这些规则时，我也会花时间使用 LLM 作为反馈来源，要求它批判我当前的工作流并找到改进的方式。

这意味着将我的规则文件传入上下文，以及其他文档（如计划和 README），并要求它查找可以改进的地方，同时也使用过去的聊天会话作为上下文。

很多时候，这只是意味着像这样询问 LLM：

你能从广度和清晰度方面进行审查，并思考一些可能的改进方式吗？请记住，这些文档是用作 AI 辅助编码工作流的上下文。

第 3 步：定义"什么"和"如何"（PRD & 计划）

这一切中一个极其重要的步骤是你用来指导产品需求文档（PRD）生成和由其创建的分步可行计划的初始 prompt。

PRD 基本上只是一份详细的指南，说明应用应该如何看起来和行为，以及关于如何实现它的一些指南。

生成 PRD 后，我们要求 LLM 生成一份分步可行计划，将使用适合 LLM 辅助开发的改进垂直切片方法分阶段实现应用。

垂直切片实现很重要，因为它指示 LLM 以全栈"切片"方式开发应用——从数据库到 UI——以逐步增加复杂性。这可能看起来像在早期阶段开发一个超简单版本的全栈功能，然后在后期向该功能添加更多复杂性。

这种方法突出了该工作流中的一个常见反复出现的主题：构建简单、坚实的基础，然后在有针对性的块中逐步增加复杂性。

在每个文档的初始生成之后，我经常要求 LLM 审查它自己的工作，并根据项目结构和它将被用于辅助编码这一事实寻找改进文档的可能方式。有时它找到了一些有趣的改进，或者至少找到了可以删除的冗余信息。

这是一个生成分步计划的示例 prompt（演练视频中使用的所有示例 prompt 都可以在附带的仓库中找到）：

从这个 PRD，使用适合 LLM 辅助编码的改进垂直切片实现方法创建一份可行的分步计划。在创建计划之前，思考一些适合该项目和实现风格的不同计划风格，然后选择最好的一个。给出你认为我们应该使用这个计划风格的理由。请记住，我们会不断参考这个计划来指导我们的编码实现，所以它应该结构良好、简洁、可行，同时仍提供足够的信息来指导 LLM。

找这个教程有趣吗？

Wasp 团队正在努力创建像这样的内容，更不用说构建一个现代的开源 React/NodeJS 框架。

显示你的支持的最简单方式就是给 Wasp 仓库点星！🐝 但如果你能看一下仓库（为了贡献或简单地测试产品），我们会非常感激。点击下面的按钮给 Wasp 点星并显示你的支持！

⭐️ 感谢你的支持 💪

第 4 步：端到端构建——垂直切片实践

如上所述，垂直切片方法因全栈框架的大量工作能力而对其构建很有帮助。

例如，与其尝试从一开始就定义所有数据库模型，这种方法单独处理最简单形式的全栈功能，然后在后期构建它们。这意味着在早期阶段，我们可能只定义身份验证所需的数据库模型，然后定义其相关的服务器端函数，以及登录表单和页面等 UI。

在我的 Wasp 项目中，实现一个阶段/功能的流程看起来像：-> 在 schema.prisma 中为该功能定义必要的 DB 实体 -> 在主 main.wasp 文件中定义操作 -> 编写服务器操作逻辑 -> 在 main.wasp 文件中定义页面/路由 -> src/features 或 src/components UI -> 通过 Wasp hooks 和其他库 hooks 和模块（react-router-dom、recharts、tanstack-table）连接东西。

这给我和 LLM 带来了巨大的优势，能够增量地构建应用而不会被大量的复杂性所拖累。

一旦这些功能的基础平稳工作，我们就可以提高它们的复杂性，并添加其他子功能，几乎没有任何问题！

这的另一个优势是，如果我意识到有一个功能集我想稍后添加但计划中尚不存在，我可以要求 LLM 审查计划并找到实现它的最佳时间/阶段。有时候那个时间是当下，有时候它给了很好的建议推迟新功能想法直到以后。如果是这样，我们会相应地更新计划。

文档——关键的遗漏

文档经常被推到后台。但在 AI 辅助工作流中，跟踪为什么以某种方式构建事物以及当前实现如何工作变得更加重要。

AI 不会自然地"记住"来自三个阶段前的上下文，除非你提供它。所以我们让 LLM 为自己提供它 :)

完成计划中定义的重要阶段或功能切片后，我养成了要求 AI 记录我们刚刚构建的内容的习惯。我甚至为这个任务创建了一个规则文件以使其更容易。

流程看起来像这样：

收集与实现功能相关的关键文件（例如，main.wasp、schema.prisma、operations.ts 文件、UI 组件文件的相关部分）。

提供 PRD 和计划中描述该功能的相关部分。

使用规则文件和 Doc 创建任务进行参考

让它审查文档的广度和清晰度

重要的是让它专注于核心逻辑、不同部分如何连接（数据库 -> 服务器 -> 客户端），以及做出的任何关键决定，参考可以找到实现细节的特定文件。

AI 然后会在 ai/docs/ 目录中生成一个 markdown 文件（或更新现有的），这很好有两个原因：

对于人类：它为入职或未来开发创建了功能的清晰、人类可读的记录。

对于 AI：它在项目中构建了一个知识库，可以在后期被反馈到 AI 的上下文中。这有助于保持一致性，并降低 AI 忘记之前决定或实现的可能性。

这个"闭合循环"步骤将文档从琐事变成了维护工作流有效性的一个干净方式。

结论：相信炒作……只是不要全部相信

那么，你能在短短几小时内"Vibe Code"一个复杂的 SaaS 应用吗？嗯，有点，但它可能会很无聊。

但你可以做的是利用 AI 显著增强你的开发流程、更快地构建、更有效地处理复杂性，以及在全栈项目中保持更好的结构。

我在几周测试后得到的"Vibe Coding"工作流归结为这些核心原则：

从强大开始：使用坚实的基础，如全栈框架（Wasp）和 UI 库（Shadcn-admin），以减少样板代码并为 AI 约束问题空间。

教导你的 AI：创建明确、详细的规则（.cursor/rules/）来指导 AI 关于项目约定、特定技术和常见陷阱。不要仅依赖它的通用知识。

构建对话：使用共享的工件（如 PRD 和分步计划）（与 AI 协作开发）来协调意图并分解工作。

垂直切片：以可管理的、增量的切片实现端到端功能，逐步增加复杂性。

持续文档化：使用 AI 来帮助在构建功能时记录它们，为人类和 AI 协作者保持项目知识。

迭代和优化：将规则、计划和工作流本身视为活文档，使用 AI 来帮助批判和改进流程。

遵循这个结构化方法取得了非常好的结果，我能够在创纪录的时间内实现功能。使用这个工作流，我能够以我之前速度快 20-50 倍的速度构建复杂应用。

拥有一个具有庞大知识集的同伴，帮助你完善想法和测试假设这一事实也很了不起。

虽然你可以在不触及代码的情况下做很多事情，但它仍然需要你，开发人员，来指导、审查和理解代码。但这是一个与 Cursor 中的 Gemini 2.5 Pro 等 AI 助手协作的现实、有效的方式，超越简单 prompt 来高效地构建功能完整的应用。

如果你想看到这个工作流从开始到结束的运作，请查看完整的约 3 小时 YouTube 演练和模板仓库。如果你有任何其他我遗漏的技巧，请在评论中告诉我 :)

一些评论可能仅对登录访问者可见。登录以查看所有评论。

有关进一步的操作，你可能会考虑屏蔽此人和/或报告滥用