大多数初创公司的 BI 项目都启动得太早、规模太大。
创始人提出一个简单的问题："从这个渠道来的用户，在第一次运行之后还会回来吗？"答案本应是一条查询语句，却往往演变成一个平台项目：接入所有数据源、搭建数据仓库、定义事件、清洗身份数据、接通仪表盘，然后等待。
这些工作迟早会有价值。但对于小团队来说，这可能是错误的第一步。产品数据库已经掌握了创始人需要了解的大部分信息：谁注册了、谁运行了什么、用了哪些功能、花了多少成本、哪里出了问题、以及他们是否回来了。
真正的问题不在于真相存放在哪里，而在于如何让 Agent 在不暴露原始生产数据库的前提下分析这些真相。
这正是我们在 VM0 采用的模式：一个脱敏的、只读的 Neon 分支，让我们的 Agent 获得足够的真实数据来运行 BI，同时不暴露那些本不该被看到的数据。
创始人的困境：问题比数据团队来得更早
早期公司不缺问题，缺的是时间。
每天，创始人团队都想知道：
- 昨天的流量有没有转化为真实用户？
- 哪些注册渠道带来的用户真正运行了产品？
- 首次运行的用户，7 天或 30 天后还会回来吗？
- 哪些付费账户正在沉默？
- 哪条模型路由在推高成本？
- 试用滥用者在转化之前消耗了多少算力？
- 产品健康状况比昨天好了还是差了？
这些问题并不复杂，它们是初创公司的日常运营节奏。
但用传统 BI 方法来回答这些问题会带来大量开销。通常你需要先把数据从产品数据库迁移到另一个系统，然后规范化数据、定义指标、重建关系、搭建仪表盘。团队最终得到了一个更整洁的分析栈，但创始人往往要等上几天甚至几周，才能得到一个本可以从一条 SQL 查询开始的答案。
对于小型初创公司来说，这种权衡可能是本末倒置的。你不需要一个完整的数据平台来回答最初的 20 个运营问题，你需要的是一种安全的方式来查询你已经拥有的真相来源。
数据库本身就是真相来源
在 VM0，产品数据库包含了许多创始人级别决策所需的关键事实：
- 组织和用户
- 注册和订阅状态
- Agent 运行记录和调度
- 积分消耗和使用事件
- 已选模型和提供商路由
- 连接器状态
- 失败状态和时间戳
这些关系已经存在于数据库中。它们比任何下游仪表盘都更新鲜，也更真实地反映了产品的实际运行方式。
这一点很重要，因为许多早期 BI 问题本质上是关系型的。创始人不只想看页面浏览量或运行次数，他们想把系统中的行为串联起来：
从这个渠道注册的用户中，有多少人在第零天就运行了产品，又有多少人在首次运行后回来了？
或者：
哪些付费组织在过去 7 天内没有任何运行记录，而他们之前看起来是活跃的？
或者：
在我们修改滥用防控策略前后，新试用账户在注册后前 6 小时内消耗了多少算力？
这些问题天然地存在于产品数据库中。一旦每个答案都要从把数据迁移到独立平台开始，问题就会变得复杂得多。
不安全的捷径：直接访问生产数据库
最诱人的捷径显而易见：直接让 Agent 查询生产数据库。
这是不可接受的。
生产数据库可能包含公司最敏感的内容：电子邮件地址、提示词、聊天内容、凭证、加密的提供商状态、日志、错误信息、API 密钥以及内部运营记录。即使 Agent 足够谨慎，原始访问权限也会带来边界问题——Agent 能看到的太多了。一次查询失误、一份报告或一张截图，都可能泄露团队从未打算公开的信息。
写权限更危险。BI 不应该能够修改生产数据。无论是人类分析师还是 Agent，都不应该只需一条错误命令就能改变用户数据。
所以问题不在于 Agent 能不能写 SQL——它当然可以。问题在于，你能否在保持隐私和安全作为硬性约束的前提下，给它足够的真实数据来发挥作用。
对我们来说，这些约束本身就是目标：
- Agent 不应看到原始提示词。
- Agent 不应看到原始电子邮件。
- Agent 不应看到凭证或密钥。
- Agent 不应看到敏感的自由文本日志。
- Agent 不应拥有对 BI 数据源的写权限。
- 创始人团队仍然应该能够快速提出实际的运营问题。
这就是我们所需要的系统形态。
安全的中间地带：脱敏的只读数据库
Neon 让一种实用的模式成为可能，因为分支是 Postgres 数据库的廉价、隔离副本。你可以创建一个类生产分支，对其进行转换，然后暴露该分支而非生产库本身。
在 VM0，我们用这种方式创建了我们称之为 MaskDB 的东西。
流程很简单：
- 从生产 Neon 父分支开始。
- 按计划创建一个新分支。
- 安装 PostgreSQL Anonymizer 和 VM0 专用脱敏辅助工具。
- 为敏感列应用安全标签。
- 在分支上执行静态匿名化处理。
- 对需要特殊处理的字段应用最终的自定义脱敏规则。
- 创建具有
SELECT权限的masked_readonly角色。 - 让 Agent 通过该角色查询，而非直接访问生产库。
重要的细节在于脱敏是静态的。敏感值在 Agent 连接之前就已经在脱敏分支上被改写。这与要求每个下游查询都记住不该选择哪些字段不同——分支本身就是边界。
在我们的 MaskDB 中，凭证和密钥被编辑删除，电子邮件和电话号码被部分遮蔽，用户内容（如提示词、聊天消息、调度提示词和 Agent 输出）被移除，错误文本被简化为错误类别而非完整的堆栈信息或消息，永远不应出现在分析中的表可以被完全删除。
与此同时，org_id、user_id、clerk_user_id 等不透明标识符保持可关联状态。这正是 BI 得以实现的关键。我们不需要 Agent 知道某人的电子邮件地址或提示词内容，但我们需要它知道同一个组织注册了、运行了任务、消耗了积分、订阅了、沉默了，或者后来又回来了。
这种平衡正是核心所在：对人类可读的敏感内容进行脱敏，同时保留关系型骨架。
边界建立后 Agent 能做什么
一旦脱敏的只读数据库就位，Agent 就能很快发挥作用。
它可以直接针对产品数据提问：
- 7 天和 30 天用户留存
- 注册到首次运行的激活率
- 以首次运行为锚点的留存
- 付费组织的沉默情况
- 订阅状态和流失监控
- 按已选模型划分的模型使用情况
- 内置路由与用户自定义提供商路由的对比
- 试用算力消耗
- 按模型划分的每次运行成本
- 按队列划分的失败率和完成率
它还可以将数据库真相与周边系统结合起来。
我们的 Morning Brief 从 Plausible、Axiom、Sentry、Google Ads、GitHub 和其他运营数据源获取数据。数据库告诉我们用户和组织做了什么，Plausible 告诉我们网站上发生了什么，PostHog 可以提供产品事件上下文，Axiom 告诉我们日志和请求路径中发生了什么，Sentry 捕获错误，Stripe 和 Clerk 帮助解释计费和身份信息，GitHub 展示工程吞吐量。
重点不是用 SQL 替代所有工具，而是让 Agent 能够将创始人真正关心的事实串联起来。
例如：
昨天付费 Google 流量超过了自然流量。这些用户真的完成了首次运行，还是在漏斗顶部就流失了？
或者：
我们修改了试用滥用防控策略。新试用账户在最初几小时内消耗的算力减少了吗？
或者：
这条模型路由每次运行更便宜。这在真实的历史聊天使用数据中有所体现，还是只停留在定价理论层面？
这些不是仪表盘问题，而是运营问题。它们每周甚至每天都在变化。一个拥有安全数据库访问权限的 Agent 可以回答这些问题，而不需要每次都让工程师新建一个视图。
真实案例一：留存与外部用户健康状况
我们的一项日常内部分析关注过去 24 小时内外部用户的健康状况。
报告从 MaskDB 开始，然后应用严格的排除集：移除 VM0 内部组织，移除被 Clerk 封禁或锁定的垃圾组织。同样的排除集被应用于所有地方，包括注册计数和留存队列，以确保分母可审计。
在此基础上，Agent 可以生成一份简洁的运营报告：
- 运行次数和活跃外部组织数
- 完成率
- 跨 Web、CLI、调度和非 Zero 路由的触发器分布
- 模型分布
- 提供商模式
- 付费组织活跃情况
- 沉默的付费组织
- 新付费注册和试用中的组织
- 流失监控
- 30 天用户分层
- 注册到运行的留存
- 首次运行留存
这正是创始人团队所需要的报告类型。它不需要原始提示词，不需要原始电子邮件，不需要生产写权限。
它需要的是正确关联产品事实的能力。
在一次运行中，Agent 发现少数活跃外部组织贡献了大部分使用量，几个付费组织已经沉默，而近期注册队列显示出明显的激活断崖——很可能是垃圾注册拉高了分母所致。这些正是创始人应该尽快看到的信息，而不是几周后在仪表盘复盘时才发现。
真实案例二：试用滥用的经济学
脱敏产品数据同样适用于那些不属于经典 BI 图表的问题。
当我们分析试用滥用时，有用的指标并不是总算力消耗。总消耗会偏向老账户，因为它们有更多时间消耗积分。更好的问题是：
新账户在注册后最初几小时内消耗了多少试用算力？
使用 MaskDB，Agent 在注册后的匹配时间窗口内测量了算力消耗，从使用事件中获取积分消耗数据，从组织元数据中获取注册时间戳，并通过订阅状态将试用经济学与付费使用区分开来。
防控策略上线后，新账户在注册后最初几小时内消耗的平均试用算力下降了 80% 以上，高消耗尾部几乎消失。在第 90 百分位，首次几小时的试用算力消耗从约 4.05 美元降至约 0.26 美元，降幅达 94%。
这个数字不只是一个分析数据点，它改变了对业务的运营判断。它告诉创始人团队，滥用不仅被检测到了，试用的单位经济学也在朝正确方向移动。
而这一切之所以成为可能，是因为数据库掌握着真相，而脱敏分支让 Agent 能够安全地分析这些真相。
真实案例三：真实产品中的模型成本
定价页面和基准测试表格有其价值，但它们无法回答创始人真正关心的问题：
这个模型在我们真实产品中、跨越真实运行的实际成本是多少？
使用 MaskDB，Agent 通过将运行记录与运行时选择的模型关联，并从使用事件中汇总计费积分，对历史聊天运行进行了比较。
这个区别很重要：不应该用用户当前的默认模型提供商来归因历史运行，因为默认值会变化。运行时选择的模型才是真相来源。
在我们的分析中，DS v4 Pro 每次聊天运行的模型积分成本中位数约为 Sonnet 的 49%。换句话说，在该路由上，真实的中位数聊天运行成本大约便宜了 51%。
同样，这是创始人级别的 BI。它将产品行为、基础设施成本和模型策略串联起来，不需要新建数据仓库，只需要对正确关系型数据的安全访问。
这不是数据仓库的永久替代方案
到了某个阶段，公司确实需要更正式的数据栈。
当指标需要强语义治理、当多个团队依赖相同的定义、当历史回填变得复杂、当仪表盘成为运营系统的一部分时，数据仓库或湖仓一体可能是正确的答案。
但许多初创公司过早地选择了这个答案。
如果你是一个小型创始人团队，你的第一个 BI 系统应该帮助你回答问题，而不是创造一个需要维护的第二个产品。脱敏数据库可以成为这座桥梁。这不是在假装数据建模不重要，而是认识到产品数据库已经包含了你做下一批决策所需的关系。
Agent 不能取代判断力，但它让分析的第一个版本变得更便宜。
创始人团队的实践模式
这个模式很简单：
- 将产品数据库视为第一真相来源。
- 永远不要将原始生产数据库暴露给 Agent。
- 使用类生产分支，而非手工构建的样本数据集。
- 在访问之前对敏感列进行静态脱敏。
- 保留不透明的关联标识符，确保分析仍然有效。
- 通过只读角色暴露分支。
- 让 Agent 在脱敏数据库和周边工具之间运行分析循环。
这让创始人团队无需先搭建完整的数据平台，就能拥有一个实用的运营系统。
它还带来了更清晰的安全态势。Agent 有明确的边界，它所看到的数据库已经过转换，它使用的角色无法写入，它生成的报告可以被限制为哈希或聚合标识符。
这就是我们在 VM0 想要的平衡：将隐私和安全作为底线而非权衡，同时让创始人团队能够更快地理解业务。
在你搭建数据湖之前，先问问自己：产品数据库的一个脱敏只读分支，能否回答团队实际面临的下 20 个问题？
对我们来说，这是通往 BI 的更快路径。
参考资料
- Neon，"使用 Neon 分支创建带脱敏生产数据的环境"：https://neon.com/blog/environments-masked-production-data
- Neon fork 的 PostgreSQL Anonymizer：https://github.com/neondatabase/postgresql_anonymizer
