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