「氛圍編碼」被大肆炒作。您可能已經看到 AI 影響者聲稱只需幾個工具和提示即可在 15 分鐘內建立 SaaS 應用程式。

但是，正如您可能已經猜到的那樣，這些範例工作流程非常脆弱。

是的，您可以複製登入頁面，或建立一個不錯的 CRUD 應用程式，但您無法使用它們來建立複雜的 SaaS 或內部工具。

但這並不意味著沒有可以積極增強您的開發工作流程的工作流程。任何嘗試過不同人工智慧輔助技術的人都會告訴你，這些工具確實具有魔力。

這就是為什麼我花了幾週時間研究最佳技術和工作流程技巧，並透過建立功能齊全的全端應用程式對它們進行測試。

下面，您將看到我的真實評論以及我發現在使用 Cursor 與 Google 的 Gemini 2.5 Pro 以及可靠的 UI 模板時確實有效的工作流程。

https://www.youtube.com/watch?v=WYzEROo7reY

順便說一句，我正在業餘時間測試和建立一個全端個人理財應用程式，並在整個過程中調整和改進流程，從而想出了這個工作流程。然後，在找到一個好的模板和工作流程後，我再次重建了該應用程式，並將其從啟動到部署的完整過程錄製在一個約 3 小時長的 YouTube 影片中（上文）。

本文總結了實現此工作流程的關鍵方法。

第一步：奠定基礎

現代全端 Web 應用程式中有很多活動部件。試圖讓你的LLMs將所有東西緊密地結合在一起是行不通的。

這就是為什麼您應該從堅實的基礎開始並利用我們現有的工具來為您的 AI 助理提供幫助。

從實際意義上講，這意味著使用以下內容：

1. UI 元件庫

2. 樣板模板

3. 包含電池的全端框架

元件庫和範本是給 LLM 已知基礎的好方法。它還可以消除樣式設計中的猜測，並幫助這些樣式隨著應用程式的成長保持一致。

使用功能齊全的全端框架，例如用於 JavaScript 的Wasp （React、Node.js、Prisma）或用於 PHP 的Laravel ，可以消除將堆疊的不同部分拼湊在一起的複雜性。由於這些框架都是有主見的，所以他們選擇了一套能夠很好地協同工作的工具，並且還具有在後台完成大量工作的額外好處。最終，人工智慧可以只專注於應用程式的業務邏輯。

以 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 助手

一旦你有了堅實的基礎，你就需要為你的編輯和LLMs建立一套全面的規則。

要製定一套可靠的規則，您需要：

1. 開始建立一些東西

2. 注意LLMs（反覆）不符合你期望的情況，並為其製定規則

3. 不斷要求LLMs幫你改善工作流程

定義規則

不同的 IDE 和編碼工具對您定義的規則有不同的命名約定，但它們的功能大致相同（我在這個專案中使用了 Cursor，因此在這裡我將參考 Cursor 的約定）。

Cursor 棄用了其.cursorrules設定文件，轉而採用包含多個文件的.cursor/rules/目錄。在這組規則中，您可以包含符合您的編碼風格的通用規則，以及特定於專案的規則（例如約定、操作、授權）。

這裡的關鍵是為 LLM 提供結構化的背景，以便它不必依賴更廣泛的知識。

這到底是什麼意思？這意味著告訴 LLM 你將要建立的當前專案和範本、它應該使用什麼約定以及它應該如何處理常見問題（例如上面的範例圖，取自教學影片附帶的 repo ）。

您也可以將一般策略新增至規則檔案中，以便在聊天視窗中手動引用。例如，我經常喜歡告訴LLMs「考慮 3 種不同的策略/方法，選擇最好的一種，並說明你選擇它的理由。」因此我為它建立了一個規則， 7-possible-solutions-thinking.mdc ，每當我想使用它時我都會將它傳入，這樣就不用一遍又一遍地輸入相同的內容。

使用人工智慧來批評和改進您的工作流程

除此之外，我將規則集視為流動的物件。當我開發我的應用程式時，我從一組規則開始，並對它們進行迭代以獲得我想要的輸出。這意味著新增規則來處理 LLM 引入的常見錯誤，或克服不符合 LLM 一般期望的專案特定問題。

當我修改這些規則時，我也會花時間使用 LLM 作為回饋來源，要求它批評我目前的工作流程並找到改進的方法。

這意味著將我的規則文件連同計劃和自述文件等其他文件一起傳遞到上下文中，並要求它尋找可以改進的領域，並使用過去的聊天會話作為上下文。

很多時候，這只是意味著向LLMs詢問類似這樣的問題：

你能評論一下嗎為了廣度和清晰度，並考慮一些必要時可以改進的方法。請記住，這些文件將用作 AI 輔助編碼工作流程的上下文。

步驟 3：定義「什麼」和「如何」（PRD 和計畫）

所有這一切中極其重要的一步是用於指導生成產品需求文件 (PRD) 以及從中建立的逐步可行計劃的初始提示。

PRD 基本上只是有關應用程式的外觀和行為的詳細指南，以及有關如何實現的一些指南。

產生 PRD 後，我們要求 LLM 產生一個可操作的逐步計劃，該計劃將使用適合 LLM 輔助開發的改進垂直切片方法分階段實施應用程式。

垂直切片實作很重要，因為它指示 LLM 以全端「切片」形式（從 DB 到 UI）開發應用程式，並且複雜性不斷增加。這可能看起來像在早期階段開發全端功能的超級簡單版本，然後在後期階段為該功能加入更多複雜性。

這種方法突顯了此工作流程中一個常見的主題：建立一個簡單、堅實的基礎，並在重點部分中增加附加的複雜性

在最初產生每個文件之後，我經常會要求 LLM 審查自己的工作，並根據專案結構和用於輔助編碼的事實尋找改進文件的可能方法。有時它會發現看似有趣的改進，或者至少它會發現可以刪除的冗餘資訊。

以下是生成分步計畫的範例提示（演練影片中使用的所有範例提示都可以在隨附的 repo中找到）：

從這個 PRD 出發，使用適合 LLM 輔助編碼的修改後的垂直切片實現方法建立可操作的、循序漸進的計劃。在製定計劃之前，請考慮幾種適合該專案的不同計劃樣式和實施樣式，然後選擇最佳的樣式。請說明您認為我們應該使用這種計劃風格的理由。請記住，我們將不斷參考該計劃來指導我們的編碼實施，因此它應該結構良好、簡潔且可操作，同時仍提供足夠的資訊來指導 LLM。

覺得本教學有趣嗎？

Wasp團隊正在努力建立這樣的內容，更不用說建立一個現代的開源 React/NodeJS 框架。

表達支持最簡單的方法就是為 Wasp repo 加星號！ 🐝 但是如果您能查看存儲庫（以做出貢獻，或者只是測試產品），我們將不勝感激。點擊下面的按鈕給 Wasp 一顆星星並表示支持！

https://github.com/wasp-lang/wasp ⭐️ 感謝您的支持 💪

步驟 4：建構端對端 - 垂直切片的實際應用

如上所述，垂直切片方法非常適合使用全端框架進行建置，因為它們可以為您和 LLM 完成繁重的工作。

例如，這種方法不是嘗試從一開始就定義所有資料庫模型，而是單獨處理全端功能的最簡單形式，然後在後續階段在此基礎上進行建置。這意味著，在早期階段，我們可能只定義身份驗證所需的資料庫模型，然後定義其相關的伺服器端功能，以及它的 UI，例如登入表單和頁面。

在我的 Wasp 專案中，實作階段/功能的流程看起來很像：

-> 僅為該功能在schema.prisma中定義必要的 DB 實體

-> 在main.wasp檔案中定義操作

-> 編寫伺服器操作邏輯

-> 在main.wasp檔案中定義頁面/路由

-> src/features 或 src/components UI

-> 透過 Wasp 鉤子和其他函式庫鉤子和模組（react-router-dom、recharts、tanstack-table）連接事物。

這為我和 LLM 帶來了巨大的優勢，能夠逐步建立應用程式，而不會因複雜性而陷入困境。

一旦這些功能的基礎運作順利，我們就可以提高它們的複雜性，並加入其他子功能，幾乎不會出現任何問題！

這樣做的另一個好處是，如果我意識到以後我想加入一組尚未存在於計劃中的功能，我可以要求 LLM 審查該計劃並找到實施該計劃的最佳時間/階段。有時那個時間就是當時的時間，有時它會給予很好的建議，將新功能的想法推遲到以後。如果是這樣，我們會相應地更新計劃。

第五步：閉環——AI輔助文件

文件常常被擱置。但在人工智慧輔助的工作流程中，追蹤事物以某種方式建構的原因以及當前的實施方式變得更加重要。

除非您提供，否則人工智慧不會固有地「記住」三個階段之前的背景。因此我們讓 LLM 來提供它：）

在完成計劃中定義的重要階段或功能片段後，我養成了讓 AI 記錄我們剛剛建立的內容的習慣。我什至為這項任務建立了一個規則文件以使其更容易。

過程大致如下：

• 收集與實作功能相關的關鍵檔案（例如，main.wasp、schema.prisma、operations.ts 檔案、UI 元件檔案的相關部分）。

• 提供 PRD 和描述該特徵的規劃的相關部分。

• 使用 Doc 建立任務引用規則文件

• 讓其審查文件的廣度和清晰度

重要的是讓它專注於核心邏輯、不同部分如何連接（資料庫->伺服器->客戶端）以及做出的任何關鍵決策，並參考可以找到實施細節的特定檔案。

然後，AI 會在ai/docs/目錄中產生一個 markdown 檔案（或更新現有檔案），這有兩個好處：

1. 對於人類：它為入職或未來開發建立了清晰的、人類可讀的功能記錄。

2. 對於人工智慧：它在專案內部建立了一個知識庫，可以在後期回饋到人工智慧的環境中。這有助於保持一致性，並減少人工智慧忘記先前的決定或實施的機會。

這個「閉環」步驟將文件從一件苦差事轉變為一種維護工作流程有效性的清晰方法。

結論：相信炒作…但不要全部相信

那麼，您能在短短幾個小時內編寫出一個複雜的 SaaS 應用程式嗎？嗯，有點，但可能會很無聊。

但您可以做的是利用人工智慧來顯著增強您的開發流程，加快建置速度，更有效地處理複雜性，並在您的全端專案中維護更好的結構。

經過數週的測試，我最終確定的「Vibe Coding」工作流程可以歸結為以下核心原則：

• 強勢開局：使用堅實的基礎，如全端框架（Wasp）和 UI 庫（Shadcn-admin），以減少樣板並限制 AI 的問題空間。

• 教你的人工智慧：建立明確、詳細的規則（.cursor/rules/）來指導人工智慧了解專案慣例、特定技術和常見的陷阱。不要僅僅依賴它的常識。

• 建構對話：使用共享工件（如 PRD 和逐步計劃（與 AI 協作開發））來協調意圖並分解工作。

• 垂直切片：以可管理的增量切片方式端到端實現功能，逐步增加複雜度。

持續記錄：使用 AI 在建立功能時幫助記錄功能，為人類和 AI 合作者維護專案知識。

• 迭代和改進：將規則、計劃和工作流程本身視為活文件，使用人工智慧來幫助批評和改進流程。

遵循這種結構化方法確實取得了良好的效果，並且我能夠在創紀錄的時間內實現功能。透過這個工作流程，我可以比以前快 20-50 倍建立複雜的應用程式。

事實上，你還有一個擁有豐富知識的同伴，可以幫助你完善想法和測試假設，這也是很神奇的

儘管您無需親自接觸程式碼即可做很多事情，但仍需要您（開發人員）來指導、審查和理解程式碼。但它是一種與 Cursor 中的 Gemini 2.5 Pro 等 AI 助理協作的現實有效的方式，超越簡單的提示，高效地建置全功能應用程式。

如果您想從頭到尾了解此工作流程的運作情況，請查看完整約 3 小時的 YouTube 示範和範本庫。如果您還有我遺漏的任何其他提示，請在評論中告訴我:)

原文出處：https://dev.to/wasp/a-structured-workflow-for-vibe-coding-full-stack-apps-352l