有限制的 Vibe Coding — 如何在 AI 時代構建應用程式

「憑感覺寫程式」(Vibe coding) 與其局限性

「憑感覺寫程式」(Vibe coding) 的概念——即向 AI 描述你的需求並讓它生成程式碼——已經深深吸引了開發者的想像力。其成果令人驚艷：只需簡單的描述就能產生功能完備的原型、無需糾結語法即可實作複雜的演算法，甚至能在不進行繁瑣 CSS 調整的情況下組裝出 UI。

然而，任何嘗試過這種方法的開發者，最終都會遇到它的侷限性。經過幾輪提示詞 (prompts) 後，原本乾淨的實作往往會變得臃腫且難以駕馭；細微的 Bug 會悄悄滲入，且變得越來越難解決。原本「毫不費力」的開發承諾，最終會演變成一種熟悉的挫折感——更糟的是，這些程式碼甚至不是你自己寫的。

2025 年的現實是，開發者仍然需要理解他們所發布的程式碼。AI 可以顯著加速開發，但它（目前）還無法取代那些使應用程式變得強健且易於維護的批判性思考與系統設計能力。

那麼，在利用這些強大新工具的同時，構建全端應用程式的最佳方法是什麼？

了解 AI 工具的層級光譜

AI 編碼工具存在於一個抽象層級的光譜上，每一層都提供不同程度的輔助與控制。該選擇哪種工具，取決於你個人的經驗與目標。

讓我們深入剖析這些抽象層級，以及熱門的 AI 軟體開發工具分別處於什麼位置。

底層：AI 輔助程式碼編寫

位於抽象層級最底端的是那些能提升程式碼編寫效率，卻不改變你基礎工作流程的工具。

• Claude Code：一個整合於終端機的 AI 助手，扮演著能以自然語言溝通的結對程式設計夥伴 (Pair Programmer) 角色。
• Windsurf/Cursor：專為 AI 輔助而建的 IDE，在改善編碼體驗的同時，讓開發者維持對程式碼的完全控制權。
• GitHub Copilot：隨 VS Code 附帶的「AI 結對程式設計夥伴」。

這些工具透過直接整合到開發者熟悉的工具鏈與工作流程中來協助編寫程式碼。它們特別適用於生成樣板程式碼、編寫膠水程式碼（如基本的 CRUD 操作或 DTO），或實作測試等場景。

中層：以提示詞為核心，並具備程式碼庫存取權

光譜的中間是由以提示詞作為主要介面，但同時允許你直接修改所生成程式碼的工具所組成。這通常透過將程式碼「匯出」(eject) 至 GitHub 儲存庫來運作，以便你在需要時進行手動變更。

這類工具的範例包括：co.dev, Lovable, v0, Replit, Bolt 等。

這些方法在將大部分工作交給 AI 與在需要時保持精確控制之間取得了平衡。

高層抽象：AI「無程式碼」(No-code) 平台

處於抽象層級最高端的是過去幾年興起的「無程式碼」應用程式建構工具的進化版。

• Bubble.io：具有 AI 輔助功能的視覺化程式設計平台。
• Glide：透過試算表建立應用程式，並結合 AI 驅動的功能。
• Gamma：透過自然語言建立互動式簡報與輕量級應用程式。

雖然這些工具能在簡單的用例中最大化生產力，例如基礎 CRUD 應用程式或定義明確的單一任務程式（如待辦事項清單、西洋棋遊戲或個人日常追蹤器），但它們不提供直接自訂程式碼的路徑，因此不適合需求較為複雜的應用程式。

程式碼與基礎設施：AI 無法協助之處

儘管 AI 在生成程式碼方面已變得非常強大，但應用程式開發中仍有一個關鍵組件是它無法取代的：你的程式碼所執行的 運算 (compute) 基礎設施，以及 儲存 (storage) 基礎設施。

無論你的 AI 生成應用程式運作得有多好，它仍然需要一個實際運行的環境。你需要：

• 能夠可靠執行你程式碼的運算資源
• 能夠提供適當保證來維護資料的儲存系統
• 能夠安全連接各組件的網路基礎設施

像 Vercel 這類平台提供了運算基礎設施，讓應用程式的部署變得簡單——然而，你的應用程式仍然需要與資料庫進行通訊。

在重型作業系統上執行的傳統資料庫，由於資源消耗高、配置負擔重以及冷啟動緩慢，已不適合 AI 輔助軟體開發的現代需求。

Prisma Postgres：專為 AI 開發時代設計的資料庫

這正是像 Prisma Postgres 這類解決方案展現獨特價值之處！Prisma Postgres 是首個基於高效率 Unikernel 建構的無伺服器 (serverless) 資料庫，專為在單一機器上運行數千個實例而設計。

它提供了開發者所需的可靠性，同時消除了 AI 無法抽象化的營運複雜性。當 AI 協助你加快程式碼生成速度時，你需要基礎設施能同步跟上——即可擴展、按需分配且配置要求最小化。

要試用 Prisma Postgres，只需在終端機執行以下指令：

Prisma Postgres 也透過模型上下文協定 (Model Context Protocol, MCP) 直接與你喜愛的 LLM 和 AI 編碼環境整合。

只需使用此 JSON 片段將其加入你所用 AI 工具的 MCP 配置中即可：

欲了解更多資訊，請參考 Prisma Postgres 文件。

何時該使用 AI？

雖然 AI 在編寫程式碼方面變得非常強大，但它（目前）並未取代開發者。理解 AI 的優勢所在以及人類專業知識仍不可或缺的地方，是有效利用 AI 工具的關鍵。

讓我們看看一些 AI 工具在較低抽象層級（如 Cursor、Windsurf、GitHub Copilot 等）表現良好的使用場景。

日常單調任務與膠水程式碼

諸如實作 CRUD 操作、設定身分驗證流程或建立標準 API 端點等任務，都遵循著 AI 可以可靠地重現的既定模式。這些是委派給 AI 助手的完美任務，讓你騰出時間專注於開發中更具創造性的部分。

依規格進行編碼

當你有清晰的需求與規格時，AI 可以高效地將其轉化為可運行的實作。對於輸入、輸出和行為定義明確的功能，這一點尤為明顯。

快速原型製作

AI 在快速建立功能性原型以演示概念與驗證想法方面表現非常出色。在探索點子或與使用者測試新功能時，即使你計劃稍後重構以用於生產環境，或是僅建立一個帶有「拋棄式程式碼」的初始版本，AI 生成的程式碼都能顯著加速回饋循環。

你（暫時）仍需理解你的程式碼！

AI 代表了程式設計抽象階梯上的下一個階段——從機器碼到組合語言、高階語言、框架，現在進展到了自然語言介面。過去轉換過程中所遵循的規則，同樣適用於此：

• 更高的抽象可以提升生產力： 以自然語言描述功能比逐行編寫程式碼更快。
• 但抽象是有「漏洞」的： 當事情出錯時（這遲早會發生），理解抽象層之下發生了什麼變得至關重要。
• 除錯的複雜度並未消失： 當你定義的內容與實際實作之間的差距擴大時，除錯的複雜度往往會隨之增加。

最強大的開發者將 AI 視為一種強大的工具，而非理解力的替代品。他們利用 AI 加速開發，同時保持對生成程式碼的足夠認知，以便日後能對其進行除錯、優化與維護。

結論

在 AI 時代構建全端應用程式，不是盲目地透過提示詞生成程式碼，而是要在 AI 加速與人類監督之間找到正確的平衡。

在這個新時代，最成功的開發者將是那些能夠：

• 在適當任務中善用 AI，同時保持對架構的控制權
• 選擇與 AI 加速開發相輔相成的基礎設施
• 理解他們發布的程式碼，即便其中並非每一行都是自己親手編寫的
• 使用如 Prisma ORM 這樣具備型別安全的工具，為人類與 AI 編寫的程式碼提供安全護欄

隨著 AI 能力持續進化，這種平衡也會隨之改變。但就目前而言，制勝的方法結合了兩者的優點：人類開發者的創造力與判斷力，以及 AI 助手的速度與模式識別能力。