Vibe Coding 正在重寫軟件開發，也正在重構數據庫

2025 年 2 月，Andrej Karpathy 在 X 上隨手寫下了"vibe coding"。不到一年，它就成了柯林斯詞典年度詞彙。同時，瑞典公司 Lovable 的 ARR 在2026年6月衝到5億美元。平臺上每週新增約100萬個項目，累計超過5000萬個，其中八成用戶沒有技術背景。Cursor 的 ARR 則從年初約 20 億美元增長到年中接近 40 億美元，短短幾個月完成翻倍。這一趨勢也幾乎同步發生在國內。螞蟻靈光、百度秒噠、騰訊"吐司"、字節 Trae幾乎成為了大廠標配。不過應用生成容易，數據庫的服務對象也跟著變了。

以前數據庫服務的是像淘寶、微信這種"少量大應用，但 coding 時代，成千上萬個應用都需要自己的數據空間。而對於 AI 生成應用來說，數據空間並不只是存儲空間，更是一份支撐應用持續運行的“記憶”。它需要保存應用的數據結構、業務狀態，並保證後續能夠被準確調用和計算。面對“海量 AI 生成應用×動態 Schema ”，這也對數據基礎設施提出新的挑戰，本文將嘗試從實際應用出發，結合螞蟻 OceanBase 的實踐，拆解這一問題以及背後的其解決思路。01 為什麼傳統數據庫方案開始失效？這股生成熱潮最終會給數據庫帶來多大壓力？先來看一組數據。

根據 Sensor Tower 的數據來看，2026年蘋果商店的上半年新增約56萬個應用，幾乎相當於2025年全年總量。全年有望突破100萬（此前紀錄為2016年的89萬）。明確歸因於 vibe coding 工具（Replit、Bolt.new 等）帶來的非專業開發者提交激增。這意味數據庫面對的不再是"一個越來越大的數據庫"，而是數千萬個彼此獨立的數據空間。以螞蟻靈光為例，上線四個月便累計生成了超過 3000 萬個閃應用。

與傳統互聯網應用不同，這些 AI 生成應用有著鮮明的新特徵：數量巨大、單體數據量小、Schema（表結構）動態生成，絕大多數應用被"搓"出來玩幾次就歸於沉寂，但用戶哪天重新點開，又必須立刻響應。一位接近項目的技術人士總結過這種負載的詭異之處——傳統的數據庫規模問題，問的是"一個庫能裝多少數據"；而這裡的問題是"一套數據庫能不能同時容納3000萬個互不相同的'小庫'"。有人或許會認為，既然 AI 能夠生成代碼，數據計算是不是也可以交給大模型完成？現實並非如此。AI 擅長生成頁面、代碼甚至業務流程，但涉及金額彙總、排序、過濾等需要絕對準確結果的計算，仍然需要數據庫完成。

以一個典型的記賬閃應用為例：用戶不僅要記下每筆收支，還要能"按月彙總支出"。而做這類精確計算的，不能是大模型——寫詩、總結它擅長，但讓它保證每一分錢都對得上，目前還做不到；也不可能是平臺——沒有任何團隊能為3000萬個結構各異的應用挨個開發計算接口。從 Agent 視角看，這些能力共同構成了應用的“運行記憶”：Schema 定義應用如何理解數據，業務數據記錄應用與用戶交互形成的狀態，應用標識劃定記憶邊界，SQL 負責對這些狀態進行準確調用和計算。

因此，靈光面對的不只是海量應用的數據存儲問題，而是海量獨立運行記憶的管理問題：每份記憶都很小，但數量極多；結構各不相同，卻必須彼此隔離，並能夠持續查詢和更新。所以每個閃應用都需要一套貨真價實的數據庫能力：定義自己的表結構、讀寫數據、執行 SQL 查詢。生成只要30秒，數據庫的承諾卻要是永久的。因此，數據庫依然承擔著持久化存儲和確定性計算的職責。只是過去數據庫的兩種典型方案，在 AI 生成應用場景下都開始失效。第一條路，是所有應用共享一張 JSON 大表。

它的優勢是物理表數量少，但代價同樣明顯，數據庫原本擅長的 SQL 聚合、過濾、排序等能力難以直接使用，很多計算只能重新回到業務層實現，多租戶場景下的數據權限隔離也變得更加複雜。這條路等於只解決了"存"，放棄了"算"。第二條路，為每個應用單獨創建一張物理表。體驗是完整的，但規模是災難性的：每創建一個應用就要對數據庫控制面發起一次 DDL 操作，3000萬次創建意味著控制面持續承壓；而這些應用大多數據量極小，開銷遠超業務數據本身。就像為一個只住了兩天的客人蓋一棟樓，樓越來越多，住的人沒幾個。螞蟻集團平臺技術事業群總架構師黃挺曾如此形容："不能讓每個人都單獨蓋一棟房子，也不能讓所有人睡一個大通鋪。

"要知道數據庫行業過去幾十年的優化方向，無論是單機性能還是分佈式擴展，瞄準的都是"少量、穩定、巨型"的庫表；而 AI 時代的負載第一次呈現出"海量、動態、長尾"的形態。所以 AI 時代真正需要的，是一條介於兩者之間的新路徑。02 OceanBase：每人一間辦公室，共享一棟樓既然"獨立"和"共享"無法二選一，那麼 OceanBase 則是在兩者之間找到一條新的路徑：將應用的數據模型與底層物理存儲解耦：每個應用保持獨立的數據模型和訪問邊界，底層則共享存儲和計算資源。

OceanBase 產品部總經理韓富晟把這個方案比作一棟寫字樓："每家公司都有自己獨立的辦公室，按自己的風格裝修、存放文件，但整棟樓共享水電和物業。放到數據庫裡，對應的是一種新的設計思路：邏輯獨立，物理共享。每一個 AI 應用看到的，仍然是一張屬於自己的數據表；而在底層，它們共享的是同一套物理存儲資源。開發者不需要感知底層如何組織數據，依舊按照熟悉的方式定義 Schema、編寫 SQL，但數據庫內部已經換了一種組織方式。為了做到這一點，OceanBase 首先把"表"拆成了兩層。一層負責記錄每個應用的數據結構，也就是 Schema；另一層負責保存真正的數據內容。

所有應用的數據最終都會寫入共享的數據表中，並以 JSON 形式存儲，而各自的表結構則單獨維護。無論平臺新增多少應用，物理表的數量都不會再隨著應用數量線性增長。不過把數據統一存成 JSON，只解決了一半的問題。如果數據庫只能存，不能算，那麼開發者最終還是需要把數據取出來，在業務層重新完成聚合、過濾、排序等計算，這恰恰又回到了第一部分提到的那條"共享 JSON 大表"老路。因此，OceanBase 又增加了一層"翻譯"能力。可以把它理解成一位同聲傳譯。

開發者依然編寫標準 SQL，不需要關心底層數據是否以 JSON 形式保存；數據庫會通過 JSON Table SDK 將這些 SQL 自動轉換成對共享存儲的訪問方式，再利用 JSON_TABLE() 將 JSON 數據映射成關係表，繼續完成聚合、過濾、統計等計算。對於開發者來說，數據庫的使用方式幾乎沒有變化；變化發生在數據庫內部。共享資源之後，另一個必須回答的問題是隔離。3000萬個應用共享一套存儲，如何防止 SQL 越界串門？方案是，在 SQL 執行過程中，每條語句都會自動附帶應用標識等限制條件，並結合白名單機制約束可執行範圍。

開發者看到的是一張屬於自己的邏輯表，數據庫真正執行時，則會自動完成訪問邊界的控制。這種設計還帶來了另一個好處。絕大多數 AI 生成應用生命週期短、訪問量低，共享資源能夠顯著降低運行成本；而當某個應用逐漸成長為高頻業務時，又可以平滑遷移到獨立物理表，而無需重新設計數據結構。從技術實現來看，這套方案重新定義數據庫組織海量 AI 應用數據的方法：邏輯上保持獨立，物理上儘可能共享；計算仍然留在數據庫完成，而不是重新回到業務層。這也是 OceanBase 希望解決的核心問題——AI 數據平臺如何以可控成本，承載數千萬個持續增長的數據空間。

03 數據庫成為 AI 應用的"基礎設施"據彭博社援引知情人士報道，外界曾將 OceanBase 看作中國的 Databricks 。兩家公司雖然起點不同——前者從分佈式數據庫內核出發，後者從數據分析和 AI 平臺起步。但最終都在回答同一個問題：AI 應用大規模湧現之後，數據基礎設施應該如何演進。OceanBase 在靈光項目中的實踐，給出的並不是某一項技術，而是一種新的數據組織思路：物理資源共享、邏輯邊界獨立、確定性計算留在數據庫。將靈光的案例放在更大的座標系裡看，它重新定義了數據庫的"規模"。

互聯網時代，人們討論數據庫，關注的是單庫容量、事務處理能力和性能；AI 時代，新的挑戰變成了如何以有限資源承載千萬級動態數據空間，同時兼顧數據隔離、確定性計算和資源成本。同時數據庫承擔的角色也開始發生變化。過去，它主要回答"數據怎麼存、怎麼算"；如今，隨著越來越多應用和數據訪問由 Agent 自動完成，它還需要回答" AI 如何持續、安全地使用數據"，以及如何組織資源、服務開發者和 Agent。當應用生成成本不斷趨近於零，競爭開始從"如何生成應用"轉向"如何承載應用"。對於 AI 應用開發者而言，模型決定了應用能做什麼，而數據基礎設施則決定了應用能否真正跑起來、跑得穩。

這或許也是靈光案例最大的啟發：AI改變了軟件開發，也重新定義了數據庫。韓富晟表示說，“ OceanBase 會持續探索，搭建面向 Agent 的數據底座，為下一代 AI 應用構建真正可依賴的數據基礎設施。”3000萬個閃應用只是這場探索的第一站，當創建應用的門檻趨近於零，數據層的競爭才真正開始。（）