這個問題幾乎在我每一場帶有懷疑態度的示範中都會出現。有人看到 AI 建構器在幾分鐘內建出一個可運作的應用程式,一開始「哇,真快」的驚訝退去之後,他們的第一個實質問題大概會是:好,但這裡面真的有資料庫嗎,還是只是用假的?這是個合理的問題。以下是隨著一個人的懷疑逐漸深入,大致會依序浮現的那些問題。
這裡真的有資料庫,還是示範只是用範例資料假裝出來的?
確實有真正的資料庫。變化的地方在於是哪一種,而這個差異正是在你打算長期維護任何東西之前值得先弄清楚的部分。以「在九十秒內展示成果」為優化目標的原型型 AI 建構器,通常會選用 SQLite——磁碟上的單一檔案,零設定,完全足以支撐單一使用者的真實應用程式運作。而以「能承受實際流量與多租戶考驗」為優化目標的建構器,則會選用 Postgres,因為一旦超過一個處理程序需要同時寫入,SQLite 的檔案鎖定模型就會開始出問題。你可以問清楚自己拿到的是哪一種。這是一個完全合理、可以拿去問銷售頁面或客服聊天的問題,如果沒有人能明確回答,這本身就說明了一些事。
它實際上使用的是哪種資料庫引擎?
對於任何超越玩具等級的用途,在這類平台上通常是 Postgres。這是個乏味但正確的答案,而這裡你要的正是「乏味」。Postgres 提供資料列層級安全性(row-level security),即使應用程式碼有漏洞,租戶 A 的資料列也不會被租戶 B 的查詢看到;它也有真正的外鍵、真正的交易,以及二十年來「已經有人踩過這個邊界情況並修正過」的累積經驗。真正有趣的失敗模式不在於「用哪種 SQL 方言」,而在於為了求快而先用 SQLite 起步、隨著用量成長卻始終沒有遷移的建構器,因為遷移一個已經有使用者在用的線上資料庫是件吃力不討好的工作,很容易被一再往後延。如果你在評估一個打算用上好幾年的建構器,要問清楚當應用程式的使用者從一位成長起來時,資料庫會發生什麼事。誠實的答案會涉及一條遷移路徑;迴避的答案則只會不斷重複「可擴展」這個詞,卻毫無具體內容。
我能看到自己的資料嗎,還是它被鎖在一個黑盒子裡?
你應該要能看到,毫無疑問。表格瀏覽器、查詢主控台、匯出按鈕——總要有某種方式,能讓你不透過應用程式本身的介面就查看資料列。這與其說是技術問題,不如說是信任問題。一個產生你無法檢視的資料結構(schema)的 AI 建構器,是在要求你信任一段自己沒寫、也無法稽核的程式碼,這比「相信我,這個按鈕能用」要大得多的要求。做得好的工具,預設就把底層資料視為屬於你的東西,而不是他們要保護你、不讓你看到的實作細節。
當我要求新增功能時,它會處理資料結構(schema)變更嗎?
這正是真正困難、也是許多 AI 建構器悄悄力有未逮的地方。新增一個欄位很簡單。但要新增一個欄位、為既有資料列回填合理的預設值、更新每一個涉及該表格的查詢,並且在過程中不遺失既有資料——這就是「資料庫遷移(migration)」,而遷移正是少數幾個「AI 寫出能編譯的程式碼」不等於「AI 寫出能安全套用到正式環境資料上的程式碼」的地方之一。值得使用的建構器,會把資料結構變更當成一個獨立、可被檢視的步驟,而不是悄悄地被包進更大的功能需求裡。如果你要求「幫任務加上截止日期」,結果拿到的差異只動到了前端,那就該起疑了——資料庫顯然沒收到通知。
它能妥善建模資料關聯,還是把所有東西都攤平塞進一個大的 JSON 物件裡?
兩種模式都存在,而你拿到哪一種,重要程度遠超過大多數人一開始的想像。關聯式資料結構——使用者、訂單、訂單項目分別建表,透過外鍵連結——讓你能問出應用程式原始介面從未預料到的問題:「哪些顧客同時買了 X 和 Y」、「按產品類別劃分,我們的退款率是多少」。而每筆紀錄都是單一非正規化 JSON 物件的做法,生成速度較快,對於真正簡單的應用程式也還算堪用,但它會讓未來每一個「就加個報表而已」的需求,都變成一次重新架構。要求查看資料結構本身,而不只是看正在運作的應用程式。如果每張表看起來都可疑地像 `{ id, data jsonb }`,那你面對的就是一個為求快速上畫面而優化、卻沒真正做好資料建模的建構器。
| 模式 | 擅長之處 | 崩潰之處 |
|---|---|---|
| 正規的關聯式資料結構(分開的資料表、外鍵) | 報表、資料表關聯查詢、資料完整性,以及你目前還沒想到的未來功能 | 前期生成時間稍長;單純的提示詞較難在第一次就準確生成 |
| 每筆紀錄一個 JSON 物件 | 快速做出第一個示範、單一實體的簡單應用程式(記事工具、基本表單) | 任何跨紀錄的查詢、任何資料關聯、任何報表——全都變成應用程式碼裡的權宜之計,而不是 SQL |
| 混合式(核心欄位用資料表欄位,彈性額外資訊放進 jsonb 欄位) | 具有穩定核心結構、外加使用者自訂欄位的應用程式 | 要求建構器懂得何時該用哪一種——做得馬虎的版本會把所有東西都塞進 jsonb 欄位 |
如果我的資料量超出它原本設計的規模,會發生什麼事?
這完全取決於底層引擎一開始是否是為並行處理而設計的。這其實還是 SQLite 對 Postgres 的問題,只是換了個面貌出現。在 SQLite 上、為單一使用者處理幾百筆資料的應用程式,感覺跟在 Postgres 上處理相同負載的應用程式一模一樣——差異只有在你加入並行寫入者、更大的資料量,或需要靠索引與查詢規劃來受益的分析型查詢時才會顯現出來。如果你的應用程式永遠都是真正的單一使用者、低流量,這問題可能永遠不會找上你。如果你正在建構一個希望有客戶的產品,請在遇到問題之前先問清楚擴展性的問題,而不是等到客服工單教會你答案。
在共享平台上,我的資料真的和其他使用者隔離開來嗎?
這是我會最用力追問的一點,因為它在出問題之前是隱形的。把所有人的資料存放在同一個資料庫中的多租戶平台,需要一道真正的隔離邊界——由資料庫本身強制執行的資料列層級安全性政策,而不只是靠應用程式碼記得在每個查詢裡加上 `WHERE user_id = ?` 這種條件。這個差異之所以重要,是因為靠應用程式碼做隔離的失敗方式是無聲無息的:只要有一個端點漏掉一個過濾條件,租戶 A 就可能突然看到租戶 B 的資料列。而由資料庫強制執行的隔離,失敗方式則是很明顯的,因為即使應用程式碼忘了加過濾條件,查詢也只會回傳空結果。要具體問清楚:租戶隔離是在資料庫層強制執行的,還是完全交由應用程式碼負責。大多數詢問「它能不能處理真實資料庫」的人,其實是在問這個問題,只是還不知道該用什麼詞彙來表達。
如果我想離開,能把所有東西都匯出嗎?
你應該要能取得自己實際資料的完整匯出——不是你應用程式的畫面截圖,也不是報表的 PDF,而是可以載入到其他地方使用、格式化過的底層資料列。如果一個建構器讓這件事變得困難,那就透露出它如何看待這段關係。「AI 建構器」這個說法的誠實意涵,應該是指平台代替你生成了程式碼與資料結構;它從來就不應該意味著,資料一旦進入一個你並非親自建立的資料表,就不再屬於你了。
資料庫是沒人會拿來示範的那個部分,而這正是為什麼在你答應任何合作之前,它是最值得問清楚的部分。
這一切都不是什麼特殊的工程學問。這跟你在選擇任何後端即服務(backend-as-a-service)或代管方案時該做的盡職調查是一樣的——只是「AI」這個要素讓人很容易忘記要問這些問題,因為示範做得太好,把底層的管線都藏起來了。問清楚用的是哪種引擎,要求看資料結構,問清楚遷移機制,問清楚隔離方式。如果答案具體明確,你大概就沒問題。
