大多數新創公司的 BI 專案，都開始得太早、規模也太大。
創辦人提出一個簡單的問題：「從這個管道來的使用者，在第一次執行後還會回來嗎？」這個問題本來只需要一個查詢就能回答，卻往往演變成一個平台建設專案：串接所有資料來源、建立資料倉儲、定義事件、清理身份識別、接好儀表板，然後等待。
這些工作終究是有價值的。但對一個小團隊來說，這可能是錯誤的第一步。產品資料庫早已掌握創辦人需要知道的大部分事實：誰註冊了、誰執行了什麼、他們用了什麼功能、花了多少成本、哪裡出了問題，以及他們有沒有回來。
真正的問題不在於真相存放在哪裡，而在於如何讓 AI 代理分析這些真相，同時又不暴露原始的生產資料庫。
這正是我們在 VM0 採用的模式：一個遮罩後的唯讀 Neon 分支，讓我們的代理擁有足夠的真相來執行 BI，同時不讓它們接觸到不該看的資料。
創辦人的困境：問題比資料團隊更早到來
早期公司不缺問題，缺的是時間。
每天，創辦人團隊都想知道：
- 昨天的流量有沒有轉化成真實使用者？
- 哪些註冊管道帶來的人真的會執行某些操作？
- 首次執行的使用者，7 天或 30 天後還會回來嗎？
- 哪些付費帳號正在沉寂？
- 哪個模型路由在推高成本？
- 試用濫用者在轉換前是否在消耗大量運算資源？
- 產品健康狀況比昨天好還是差？
這些問題一點都不稀奇，它們是新創公司的日常運營節奏。
但用傳統 BI 方法來回答這些問題，會帶來大量額外負擔。通常你得先把資料從產品資料庫搬到另一個系統，然後正規化、定義指標、重建關聯、建立儀表板。團隊最終得到了一個更整潔的分析架構，但創辦人往往要等好幾天甚至幾週，才能得到一個本來只需要一個 SQL 查詢就能回答的問題。
對小型新創公司來說，這個取捨可能是本末倒置的。你不需要一個完整的資料平台來回答最初的 20 個運營問題，你需要的是一種安全的方式來查詢你已經擁有的事實來源。
資料庫本身就是事實來源
在 VM0，產品資料庫包含了許多創辦人層級決策所需的關鍵事實：
- 組織與使用者
- 註冊與訂閱狀態
- 代理執行與排程
- 點數消耗與使用事件
- 已選模型與供應商路由
- 連接器狀態
- 失敗狀態與時間戳記
這些關聯早已存在。它們比任何下游儀表板都更即時，也更真實地反映產品的實際運作方式。
這一點很重要，因為許多早期 BI 問題本質上是關聯性的。創辦人不只想看頁面瀏覽數或執行次數，他們想要跨系統串聯行為：
從這個管道註冊的使用者中，有多少人在第零天就執行了某些操作，又有多少人在第一次執行後回來了？
或者：
哪些付費組織在過去 7 天內沒有執行任何操作，而他們之前看起來是活躍的嗎？
或者：
在我們更改濫用防護機制前後，新試用帳號在前 6 小時內消耗了多少運算資源？
這些問題天然地存在於產品資料庫中。但如果每個答案都要先把資料搬到另一個平台，就會困難許多。
不安全的捷徑：直接存取生產資料庫
最誘人的捷徑顯而易見：直接讓代理查詢生產資料庫。
這是不可接受的。
生產資料庫可能包含公司最敏感的資料：電子郵件地址、提示詞、聊天內容、憑證、加密的供應商狀態、日誌、錯誤訊息、API 金鑰，以及內部運營記錄。即使代理再謹慎，原始存取也會造成邊界問題——代理能看到太多東西。一個查詢、一份報告或一張截圖的失誤，都可能洩露團隊從未打算公開的資訊。
寫入權限更是危險。BI 不應該能夠修改生產資料。無論是人類還是 AI 分析師，都不應該只差一個錯誤指令就能改動使用者資料。
所以問題不在於代理能不能寫 SQL——它們當然可以。問題在於你能不能在保持隱私與安全作為硬性限制的前提下，給予它們足夠的真相來發揮作用。
對我們來說，這些限制本身就是重點：
- 代理不應看到原始提示詞。
- 代理不應看到原始電子郵件。
- 代理不應看到憑證或機密。
- 代理不應看到敏感的自由文字日誌。
- 代理不應擁有 BI 資料來源的寫入權限。
- 創辦人團隊仍然應該能夠快速提出實際的運營問題。
這就是我們所需要的系統形態。
安全的中間地帶：遮罩後的唯讀資料庫
Neon 讓一種實用的模式成為可能，因為分支是 Postgres 資料庫的廉價、隔離副本。你可以建立一個類似生產環境的分支，對其進行轉換，然後暴露這個分支而非生產資料庫本身。
在 VM0，我們用這個方式建立了我們稱為 MaskDB 的東西。
流程很簡單：
- 從生產 Neon 父分支開始。
- 按排程建立一個新分支。
- 安裝 PostgreSQL Anonymizer 和 VM0 專屬的遮罩輔助工具。
- 為敏感欄位套用安全標籤。
- 在分支上執行靜態匿名化。
- 對需要特殊處理的欄位套用最終自訂遮罩。
- 建立具有
SELECT權限的masked_readonly角色。 - 讓代理透過該角色查詢，而非直接存取生產資料庫。
重要的細節在於遮罩是靜態的。敏感值在代理連線之前就已在遮罩分支上被改寫。這與要求每個下游查詢都記得不要選取某些欄位的做法不同——分支本身就是邊界。
在我們的 MaskDB 中，憑證和機密會被刪除，電子郵件和電話號碼會被部分遮罩，使用者內容（如提示詞、聊天訊息、排程提示詞和代理輸出）會被移除，錯誤文字會被簡化為類別而非完整的堆疊追蹤或訊息，不應出現在分析中的資料表可以被完全刪除。
與此同時，不透明的識別碼如 org_id、user_id 和 clerk_user_id 仍然可以用於 JOIN 操作。這正是 BI 得以實現的關鍵。我們不需要代理知道某人的電子郵件地址或提示詞內容，但我們需要它知道同一個組織是否完成了註冊、執行了任務、消耗了點數、訂閱了服務、進入了休眠，或者後來又回來了。
這個平衡正是整件事的核心：遮罩人類可讀的敏感資料，保留關聯性骨架。
邊界建立後，代理能做什麼
一旦遮罩後的唯讀資料庫建立完成，代理就能很快發揮作用。
它可以直接針對產品資料提問：
- 7 天和 30 天使用者留存率
- 從註冊到首次執行的啟動率
- 以首次執行為錨點的留存率
- 付費組織的休眠狀況
- 訂閱狀態與流失監控
- 依所選模型的使用量分析
- 內建路由與使用者自訂供應商路由的比較
- 試用版運算資源消耗
- 依模型的每次執行成本
- 依群組的失敗率與完成率
它也可以將資料庫的事實與周邊系統結合起來。
我們的 Morning Brief 從 Plausible、Axiom、Sentry、Google Ads、GitHub 和其他運營資料來源取得資料。資料庫告訴我們使用者和組織做了什麼，Plausible 告訴我們網站上發生了什麼，PostHog 可以提供產品事件的背景，Axiom 告訴我們日誌和請求路徑中發生了什麼，Sentry 捕捉錯誤，Stripe 和 Clerk 幫助解釋帳單和身份識別，GitHub 顯示工程產出。
重點不是用 SQL 取代所有工具，而是讓代理能夠串聯創辦人真正關心的事實。
例如：
昨天付費 Google 流量比自然流量多。這些使用者真的到達了首次執行，還是在漏斗頂端就停下來了？
或者：
我們更改了試用濫用防護機制。新試用帳號在最初幾小時內消耗的運算資源減少了嗎？
或者：
這個模型路由每次執行更便宜。這在真實的歷史聊天使用量中有所體現，還是只停留在定價理論上？
這些不是儀表板問題，而是運營問題。它們每週、有時每天都在變化。擁有安全資料庫存取權限的代理可以回答這些問題，而不需要每次都請工程師建立新的視圖。
真實案例一：留存率與外部使用者健康狀況
我們每天的內部分析之一，是查看過去 24 小時的外部使用者健康狀況。
報告從 MaskDB 開始，然後套用嚴格的排除集：移除 VM0 內部組織，移除被 Clerk 封禁或鎖定的垃圾組織。同樣的排除集會套用到所有地方，包括註冊計數和留存群組，以確保分母保持可稽核性。
在此基礎上，代理可以產出一份簡潔的運營報告：
- 執行次數與活躍外部組織數
- 完成率
- 跨 Web、CLI、排程和非 Zero 路由的觸發組合
- 模型組合
- 供應商模式
- 付費組織活動
- 休眠的付費組織
- 新付費註冊與試用中的組織
- 流失監控
- 30 天使用者分群
- 從註冊到執行的留存率
- 首次執行留存率
這正是創辦人團隊所需要的報告類型。它不需要原始提示詞，不需要原始電子郵件，也不需要生產資料庫的寫入權限。
它需要的是正確串聯產品事實的能力。
在一次執行中，代理發現少數活躍的外部組織貢獻了大部分的使用量，幾個付費組織已經沉寂，而最近的註冊群組顯示出明顯的啟動斷崖，這很可能是垃圾註冊拉高了分母所致。這些都是創辦人應該快速看到的事情，而不是幾週後才在儀表板審查中發現。
真實案例二：試用濫用的經濟學
遮罩後的產品資料對於非傳統 BI 圖表的問題同樣有用。
當我們研究試用濫用時，有用的指標不是總運算支出。總支出會偏向較舊的帳號，因為它們有更多時間消耗點數。更好的問題是：
新帳號在註冊後最初幾小時內消耗了多少試用運算資源？
使用 MaskDB，代理在註冊後的匹配時間窗口內測量了運算資源消耗，使用了來自使用事件的點數消耗、來自組織元資料的註冊時間戳記，以及訂閱狀態來區分試用經濟學與付費使用。
防護機制上線後，新帳號在註冊後最初幾小時內消耗的平均試用運算資源下降了超過 80%。高消耗的長尾幾乎消失了。在第 90 百分位數，首幾小時的試用運算資源從約 4.05 美元降至約 0.26 美元，降幅達 94%。
這個數字不只是一個分析數據點，它改變了對業務的運營視角。它告訴創辦人團隊，濫用不只是被偵測到了，試用的單位經濟學也正在朝正確的方向移動。
而這一切之所以成為可能，是因為資料庫掌握著真相，而遮罩分支讓代理能夠安全地分析這些真相。
真實案例三：真實產品中的模型成本
定價頁面和基準測試表格很有用，但它們無法回答創辦人真正關心的問題：
這個模型在我們的真實產品中、跨越真實執行，實際花費多少？
使用 MaskDB，代理透過將執行記錄與執行時選定的模型進行 JOIN，並從使用事件中彙總計費點數，比較了歷史聊天執行的成本。
這個區別很重要：你不應該用使用者當前的預設模型供應商來歸因歷史執行，因為預設值會改變。執行時選定的模型才是事實來源。
在我們的分析中，DS v4 Pro 每次聊天執行的模型點數成本中位數，約為 Sonnet 的 49%。換句話說，在該路由上，真實的聊天執行中位數成本大約便宜了 51%。
同樣地，這是創辦人層級的 BI。它串聯了產品行為、基礎設施成本和模型策略，不需要新的資料倉儲，只需要對正確關聯資料的安全存取。
這不是資料倉儲的永久替代方案
公司終究會需要更正式的資料架構。
當指標需要強大的語義治理、當許多團隊依賴相同的定義、當歷史回填變得複雜、當儀表板成為運營系統的一部分時，資料倉儲或資料湖屋可能才是正確的答案。
但許多新創公司過早地伸手去拿那個答案。
如果你是一個小型創辦人團隊，你的第一個 BI 系統應該幫助你回答問題，而不是創造第二個需要維護的產品。遮罩資料庫可以成為橋樑。這不是在假裝資料建模不重要，而是認識到產品資料庫已經包含了你下一批決策所需的關聯關係。
代理不能取代判斷力，但它讓第一版分析的執行成本更低。
給創辦人團隊的模式
這個模式很簡單：
- 將產品資料庫視為第一個事實來源。
- 永遠不要將原始生產資料庫暴露給代理。
- 使用類似生產環境的分支，而非手工建立的樣本資料集。
- 在存取之前靜態遮罩敏感欄位。
- 保留不透明的 JOIN 識別碼，讓分析仍然可行。
- 透過唯讀角色暴露分支。
- 讓代理在遮罩資料庫和周邊工具之間執行分析循環。
這讓創辦人團隊擁有一個實用的運營系統，而無需先建立完整的資料平台。
這也創造了更清晰的安全態勢。代理有一個硬性邊界，它所看到的資料庫已經過轉換，它使用的角色無法寫入，它產出的報告可以被限制為雜湊或彙總識別碼。
這就是我們在 VM0 想要達到的平衡：以隱私和安全作為底線而非取捨，同時讓創辦人團隊能夠更快速地理解業務。
在你建立資料湖之前，先問問自己：產品資料庫的一個遮罩唯讀分支，能不能回答你的團隊實際面臨的下 20 個問題。
對我們來說，那是通往 BI 的更快路徑。
參考資料
- Neon，〈Create Environments with Masked Production Data Using Neon Branches〉：https://neon.com/blog/environments-masked-production-data
- Neon fork of PostgreSQL Anonymizer：https://github.com/neondatabase/postgresql_anonymizer
