在這兩年，「Vibe Coding (氛圍編碼)」從一個矽谷的迷因演變成了許多開發者與創作者口中的關鍵字，也讓寫不出程式的小白燃起一絲希望。有人把它理解成「用 AI 寫程式」，有人認為是「不被語法綁住，專注做出東西」。
然而隨著 AI 工具如 Cursor、Replit Agent 或 Lovable 的普及，我們開始發現一個弔詭的現象：為什麼同樣是用 AI 協作，有些人能在半天內做出一個可擴展的 SaaS 產品，而有些人卻在處理簡單功能需求時，系統就開始崩潰、出錯，最後陷入無止盡的錯誤循環？
關鍵在於：真正進入 Vibe Coding 狀態的人，幾乎一定具備扎實的資料庫思維，因為所有系統的主要目的都是正確的處理資料。只要你交給AI的需求與資料庫邏輯是正確的，就能產出正確的系統。
Vibe Coding 的本質從來不是在「寫 code」，而是在「組建系統」。
一、 範式轉移：從「語法導向」到「結構導向」
在傳統開發流程中，工程師的思維路徑通常是「由小到大」：先選擇程式語言，寫下第一個 Function (函式)，決定 Variable (變數) 命名，最後在功能快完成時，才去思考資料要怎麼存、Table Schema (資料表綱要) 要怎麼開。
但在 Vibe Coding 的狀態下，邏輯是反過來的。因為 AI 已經解決了「如何寫出語法正確的程式碼」這個低階問題。當你對著 AI 說：「幫我寫一個處理使用者登入的邏輯」，這對現在的 LLM (大型語言模型) 來說只是基本功。
真正的挑戰在於：你腦中是否先有了系統的藍圖？
高階的 Vibe Coder 在下 Prompt 之前，腦中會先浮現這三個問題：
(1) Entity (實體) 是什麼？ 誰是使用者？誰是訂單？誰是評論？
(2) Relationship (關聯性) 是什麼？ 一個使用者可以有多張訂單嗎？評論是屬於產品還是屬於使用者？
(3) Single Source of Truth (唯一事實來源) 在哪裡？
當這些結構在腦中成形後，程式碼反而變成最容易產出的部分。
AI 可以秒速生出 CRUD (增刪查改)，但它無法替你決定資料該如何「存在」。而這個「存在方式」，正是資料庫知識的核心。
二、 實例演練：同樣是「訂單系統」，設計決定了生死
讓我們舉一個具體的例子。假設你想做一個簡單的「電商訂單管理系統」。
1. 缺乏資料庫思維的 Vibe Coding (直覺式開發)
如果你只懂「下指令」，你可能會跟 AI 說：「幫我做一個訂單列表，要能紀錄客戶買了什麼、多少錢、什麼時候買的。」
AI 可能會幫你生出一個 Orders 資料表，裡面欄位長這樣：
order_id 訂單編號
customer_name 客戶名稱
product_name 產品名稱
total_price 總價
created_at 建立日期
一開始看起來完美，系統跑得很順。但當你要求增加「客戶可以修改名字」或「產品價格調整」的功能時，災難就開始了。因為客戶名字直接寫死在訂單裡，一旦客戶改名，舊訂單的名字就對不上了；或者產品漲價了，過去的訂單金額因為沒有紀錄當時的 Snapshot (快照)，導致財務報表全錯。
這就是所謂的 Data Redundancy (資料冗餘) 與 Data Integrity (資料完整性) 缺失。
2. 具備資料庫思維的 Vibe Coding (結構式開發)
一個有資料庫經驗的 Vibe Coder，會引導 AI 建立正確的 Relational Model (關聯模型)：
Users Table: 存放客戶基本資料。
Products Table: 存放產品目前的資訊。
Orders Table: 只紀錄 User ID、時間與狀態。
Order_Items Table: 紀錄當下購買的單價 (Price at purchase) 與數量。
當你下指令給 AI 時，你會說：「請幫我設計一個符合 3NF (第三正規化) 的資料結構，並確保訂單項目紀錄的是成交當下的價格。」
差別在哪？ 後者的系統，無論未來要增加「優惠券功能」、「退貨流程」還是「多幣別轉換」，其底層結構都是穩固的。
AI 寫出的程式碼將圍繞著這個穩固的 Schema (綱要) 運作，而不會因為邏輯打結而產生幻覺。
三、 AI 會寫 Code，但它不替你的「架構債」負責
很多人在使用 AI 時會遇到一個現象：專案進行到中期，AI 寫的程式碼開始變得很亂，甚至會回頭改掉原本正確的東西。
這往往不是 AI 變笨了，而是你的資料設計太爛，導致邏輯邊界模糊。
當資料庫設計不良時，你會發現以下三個後遺症：
1. 資料表肥大化與刪除恐懼
你會發現資料表欄位越來越多（例如 temp_column_1, is_deleted_2），卻沒人敢刪。因為 AI 產生的邏輯散落在各處，你不確定刪除一個欄位會不會引發連鎖崩潰。
2. 效能的隱形殺手
缺乏資料庫知識的人，不知道什麼是 Index (索引)，也不知道什麼是 N+1 Query (N+1 查詢問題)。
例子： 當你請 AI 寫一個「顯示所有使用者及其最新訂單」的頁面，AI 可能會寫出一個迴圈，先抓 100 個使用者，再對每個使用者發一次資料庫請求。在開發環境（只有 3 筆資料）很快，但一上線有 1000 個用戶時，資料庫就會直接當機。
3. Transaction (交易/事務) 的缺失
在處理金流或庫存時，如果不懂 ACID (原子性、一致性、隔離性、持久性)，你可能會寫出「錢扣了，但訂單沒產生」的程式碼。AI 不一定會主動幫你加上 Begin Transaction，除非你具備這種意識並在 Vibe 的過程中引導它。
四、 高階 Vibe Coding 的三層腦內結構
真正熟練的 Vibe Coder，在與 AI 協作時，腦中會同時運作三個層次：
第一層：Data Structure (資料結構)
這是最底層的地基，你知道 Primary Key (主鍵)、Foreign Key (外鍵) 的位置，知道哪裡該用什麼資料型態的欄位。
第二層：Data Flow (資料流)
你清楚資料從前端傳進來後，經過哪些驗證，最後落入資料庫的哪個角落。你明白 Caching (快取) 應該在哪個環節介入，以減輕資料庫負擔。
第三層：Application Logic (應用邏輯)
這是最外層的裝飾，驗證規則、UI 介面、通知信發送等。這是 AI 最擅長的部分，也是 Vibe Coding 表面上看起來最華麗的部分。
當這三層存在於腦中時，AI 就不再是「替你思考的人」，而是「替你輸出的超級打字員」。
五、 給想進入 Vibe Coding 殿堂的學習建議
如果你想讓你的 Vibe Coding 從「玩票」變成「專業開發」，你不需要成為資料庫管理員 (DBA)，但你至少要掌握以下能力：
ER Model (實體關係模型)：能把模糊的需求轉成一張張有線條連接的表格。
理解關聯差異：清楚 One-to-Many (一對多) 與 Many-to-Many (多對多) 的實作邏輯（例如：中間表的存在）。
效能基礎：知道 Query Profiling (查詢分析)，明白為什麼 SELECT * 可能是個壞習慣。
異步與一致性：理解為什麼有些資料可以慢慢更新 (Eventual Consistency)，有些資料必須死守一致。
Vibe 是靈魂，資料庫是骨架
Vibe Coding 並非讓工程變得隨興，而是讓我們能從低價值的語法糾結中解放，把精力投注在「高價值的決策」上。
而在所有決策中，資料結構永遠是最核心、最難以事後翻修的一層。
當你開始用資料庫的角度看系統，你會發現 AI 變得更聽話了，系統變得更強健了。
真正的 Vibe，不是隨便噴噴指令，而是精準地引導 AI，在正確的結構地基上，蓋出壯麗的數位建築。
如果你不知道資料會怎麼崩潰，那只是因為它還沒崩潰給你看到。
現在就開始補齊你的資料庫思維吧！
0 留言