我们能用一堆 HTML 文件替掉 15 万美元的 Looker 吗？

和很多公司一样，我们也付费使用 Looker。一年 15 万美元吧，这是 Looker 的平均授权费¹，大约 300 个席位。我们公司约 500 人，有 3 名数据平台工程师，一周大部分时间都花在那些不出彩的活儿上：保证 Snowflake 有数据可查，照看一个早已超过 2,000 个模型的 dbt 项目，以及维护底下那一整套 Airflow、Airbyte、DataHub 和 Kubernetes 管道。

今年 2 月，我们中有一个人顺手做了个托管 HTML 文件的小工具。花了一个下午。8 个月过去，它的周活跃用户已经和公司里的 Looker 一样多，甚至可能更多，而 Looker 的使用量掉了三分之一。

科技网红们不断发帖说软件已死，还有人说自己已经退订并 vibecode 掉了所有 SaaS 订阅。他们说 AI 会杀死 B2B SaaS。²

看来 SaaS 已死，那我们能不能换掉企业级 BI 工具？

左图：描述为“self-hosted”的新 GitHub 仓库占比。右图：Hacker News 评论中提到“slop”的占比。³

slop 变好用了

一年前，我认为大多数 AI 输出都是 slop，事实也确实如此。我们做了几个“与你的数据对话”的 demo，在只有 4 张表的玩具级 schema 上看起来很棒，但在我们的规模下从来没真正跑通过。SQL 执行没有报错，但数字是错的。这比报错糟糕得多。

后来，配合 Opus 4.5 的 Claude Code 变得非常好用。是真的非常好用。一月初，全公司的采用率暴涨。它能在我们的仓库里干活，能用我们的工具。而且，它可以在回答之前先跑一个查询核对数字。这一点比生成一个听起来很聪明的回答重要得多。几周之内，财务、运营和市场部门那些从没打开过终端的人整天都在写 prompt。一夜之间，所有人都在写 prompt，没有人再点鼠标了。

差不多同一时间，Claude 开始大量输出 HTML。你让它做个分析，拿到的就是一个带图表的单文件，说实话，其中有些页面比我们的 Looker 仪表盘还好看。问题在于，它躺在某个人的 Downloads 文件夹里。要分享，就得把它传到 Slack 上碰运气。那时 Anthropic 还没为 Team 和 Enterprise 推出可分享的 artifacts（2026 年 6 月），而我们迫切需要一种方式来分享这种新型仪表盘。

我们需要托管和分享这些 HTML slop

有一天，团队的 Maddy 说，干脆把它们全放到一台 web 服务器上，配一个内部域名。当天结束前，她就用 vibe coding 把整套东西做出来了：一个小服务，把文件存进 S3，前面挂 SSO，还有（一些）测试。我们所有东西本来就跑在 Kubernetes 上，所以部署一个服务基本上就是加一个 Terraform module 和一个 Helm chart。这些基础设施都已就位，让整件事容易了太多。

她写了一个小 Python 脚本，打包成 Claude plugin。用户让 Claude 写好 HTML，脚本把它推上去（在 SSO 后面），公司里任何人打开链接就能看。最初，文件只是普通的静态 HTML。三月我们想，何不试试，于是加了一个实时查询 API，使用查看者自己的 Snowflake OAuth token：这是今年最好的决定。

结果我们根本不需要自己写权限模型，Snowflake 早就有了。它有一套我们维护多年的角色体系：只要 Snowflake 判定你不能读销售表，仪表盘也就读不了。到四月，Snowflake OAuth 成了唯一的登录方式。

大家很喜欢它，原因对 BI 行业来说有点难堪：这些仪表盘确实好看。

Looker 的图块就是一个框子，图表类型就那么几种，配色也就那么一套，长得和所有 Looker 图块一模一样。丑，毫无个性。

去掉那些死板的固定磁贴之后，用户可以自己编写自由形式的 HTML，反复调整提示词，直到看着顺眼为止。他们很喜欢。四月上线了邮件和 Slack 导出，五月加了参数，周活跃用户从三月的 23 涨到六月的 136。高管团队开始互相发链接。用户也把这工具用出了自己的花样：找到我们根本想不到的用法，把仪表盘设成按计划自动重新生成，加按钮，做出一些 BI 工具绝不会允许的狂野设计和交互。

这个阶段的安全性很糟。是真的糟。仪表盘的 JavaScript 和你的会话跑在同一个源上，没有任何权限控制，每个员工都能读所有仪表盘。基本上就是一个大 XSS 漏洞：任何仪表盘都能以打开它的人的身份执行代码，并以那个人的名义把数据拉走。我们知道，还是照发了，因为它是内部工具，在 VPN 和 SSO 后面，而且没有别的东西能干这活。

好，那就认真做

在我们团队里，“干脆自己做个 BI 工具吧”一度成了个梗。这个梗持续了几个月，直到我们意识到事情已经闹大了。我们在一个自己都不好意思说的安全模型上堆了几个月的 vibe-coding，公司一半的人都在用。我们不再开玩笑，把话说正经了：做个 BI 工具吧。我们站到白板前，主要是想搞清楚怎么修安全模型，顺便统一一下哪些东西不能丢：还是同一个 S3 bucket，不迁移，已经在用的人那边不能出任何问题，发布要和以前一样简单。

所有人都同意的一点：任何人仍然可以一句话推上去任意 HTML，没有审核环节，没有模板，也没有一份可用组件的白名单。这一点我们照样会守住。

你在人和自己的仪表盘之间加的每一道限制，都会把人赶回 Downloads 文件夹。

真正要紧的治理本来就在上游完成了，在 dbt 模型和 Snowflake 角色里。所以仪表盘本身可以随人喜欢，松散、快、好看都行。

有 4 个问题要解决。

一个连接器取代一堆脚本。 上传脚本被复制到了 2 个 repo 和一个插件里，每份都略有不同。我们把它们全部换成了一个面向全公司的远程 MCP 连接器，这样 claude.ai、Claude Code、Claude in Slack 和我们自己的分析 agent 调用的都是同一套工具。连接器会把你的 Snowflake token 透传下去，API 用 SELECT CURRENT_USER() 校验你是谁。AI 上传的东西一律落成草稿，必须有人点 Publish。

假设每个仪表盘都是敌对的。 这一点我们必须真正想清楚。整个产品从设计上基本就是 XSS：任何人都能上传 JavaScript，在同事的浏览器里运行，无人审核，而这个同事可能是 CFO。我们无法封堵 XSS，因为 XSS 就是产品本身，所以我们的任务是确保它够不到任何东西。正因如此，我们的安全模型从“我们假设它是敌对的”出发。每个仪表盘都运行在独立源上的沙箱 iframe 中，拿不到 cookie，并受严格的 CSP 约束。它唯一能通信的对象是父页面，通过 postMessage 进行，父页面会校验消息的发送方，附上会话并调用 API。内容令牌有效期为一小时，只对一个仪表盘、一个查看者和一个主机有效。

沙箱保护的是浏览器。我们还单独搭建了一个元数据服务，异步读取每个仪表盘的新版本。它会提取整份 HTML 和 Snowflake 查询，检查页面加载了哪些脚本、把数据发往哪里，再由一组规则对这些事实做出判定。大多数规则只上报：标记出直接读取原始数据、没有走 dbt 模型的仪表盘，没有锁定版本的脚本，以及 90 天没人打开过的仪表盘。有些规则可以直接拦截：来自这里没人用过的包的脚本，或者 WebRTC 连接——这是 CSP 拦不住的一条外泄通道。被拦截的仪表盘不会加载，查看者会看到一条警告，必须接受之后页面才会运行。

身份和权限交给 Snowflake。 每个查询都以查看者自己的 token 执行。分享仪表盘从不等于分享数据访问权。这既是安全特性，也是省事特性：我们从不需要构建或维护数据权限，因为每个登录的人本来就有带正确角色的 Snowflake 用户。

内容管理。 这部分我们用 vibe coding 大约一周就写完了，几乎没怎么做设计。空间、文件夹和分享直接照搬 Google Drive，因为大家都熟悉 Google Drive 怎么用：viewer、editor、owner，授权沿文件夹树向下传递，权限最强的授权生效。版本按内容哈希存储，恢复某个版本得到的是一个草稿。此外还有搜索、点赞、定时导出，以及每小时从 HR 系统同步的团队。对比一下安全模型——真正动脑子的地方几乎全在那里。

开发花了几周，我们做出来了。

然后就传开了。人们开始在 Slack 线程里 @Claude，然后拿回一个仪表盘。我们的分析师 agent 会发布自己的仪表盘，有些仓库直接从 CI 发布，而大多数人只是从自己的 Claude 发布，所以每个仪表盘多少都带着制作者的样子。现在到处都是。

325 次提交，约 74,000 行代码（其中 20,000 行是测试），Claude token 花了大约 $6.4k。

这就是我们这边的全部账单：8 个月，3 名工程师业余时间做，外加几个朋友提了 PR。大部分代码是 Claude 写的。我们负责画白板、大量争论，以及审查所有东西。

每个仪表盘 $0.50，这对 BI 意味着什么？

Looker 的用量是慢慢流失的，不是一下子崩掉的。我们并没有把所有东西都搬走：有些团队还在用 Looker，它的一些仪表盘也还没有替代品。真正让人转过来用新方案的，是做一个仪表盘不再那么贵了。这让我们好奇：到底有多便宜？按 token 付费而不是按工程时间付费，好处就是更容易量化。

这里我们用分析师 agent 作为参照，因为它是一个可以精确测量的构建者。每次运行都会记录 token 和成本，每次发布都能追溯到生成它的那次运行。

我们发现，从第一个问题到最终页面，每个仪表盘大约要消耗 agent 100 万 token。把它迁到 Opus 5.5 之后，一个仪表盘的成本从大约 $2.50\text{降}\text{到}\text{约}$0.50。agent 干的活没变，只是 token 变便宜了。这才是关键：现在做软件的成本就是 token 的成本，而这个价格还在往下走。

BI 工具本质上就是把查询变成图表的工具，而现在一张图表大约只要 $0.50 的 token 费用。为了这一部分去付 15 万美元的授权费，就越发说不过去了。

自建还是采购？

从二月第一次提交至今，整个项目的账单如下。

它现在有了自己的数据库，跑在 AWS 上一年大约 $6k\text{，}\text{再}\text{加}\text{上}\text{我}\text{们}\text{不}\text{断}\text{加}\text{功}\text{能}\text{花}\text{的}Claude\text{费}\text{用}\text{，}\text{从}7\text{月}\text{起}\text{大}\text{约}\text{是}\text{每}\text{月}$1.3k。算下来一年 $20k\text{，}\text{而}Looker\text{是}$150k，这 $20k 里大部分是我们自己在做新东西，而不是维持现状。

当初买 Looker，我们买的是四样东西：画图表的 UI、权限模型、语义层，以及托管的地方。现在 Claude 来画图表，一次一个仪表盘。

Snowflake 一直都有权限，dbt 有语义，托管几个 HTML 文件每月大约 500 美元。

把这些拿掉，剩下的就是一张 15 万美元的账单。

不止我们一家。这种事你听到的越来越多：稳健的老牌公司在取消非常昂贵的分析订阅。Amjad Masad对 Platformer讲了 Replit 的同样经历：一旦他能把数仓接到生产 Postgres 上、自己把报表做出来，他们就“取消或缩减了大部分分析产品”。

在我们这里，围绕现有技术栈自建仪表盘工具，成本只是付给 Looker 的一小部分。对我们来说，要紧的东西本来就在 dbt 和 Snowflake 里：模型、权限、数据。Looker 架在上面，把它们变成仪表盘。我们发现可以替换的正是这一层。

上面的账单还没算最大的一笔成本，也就是我们自己：3 名工程师投入 8 个月，而且是在数据平台团队本来就要做的所有事情之外——管道、dbt 项目、数仓、Kubernetes 集群、on-call。这些一样都没停。我们没法给出一个诚实的工时数字，因为这些时间分散在其他所有工作里。如果你需要专门招一个团队来做这件事，账就不一样了。

如果你已经有一个扎实的平台可以依托，也有一支熟悉它的团队，剩下的基本就是 Claude 的时间，而 Claude 的时间很便宜。

我认为分界线在规模。AWS 和 Snowflake 卖的是没人能 vibe-code 的东西：数据中心、PB 级价格的存储、因为数百万其他客户分摊而便宜的算力。BI 我觉得格外脆弱，因为它的很多价值——至少对我们而言——在于搭建和呈现仪表盘。Claude 现在几美分就能做这件事。有真正规模优势的产品是另一回事，但如果有更多公司开始自己替换掉 BI 栈的一部分，我不会感到意外。

Claude Dashboards 呢？

Anthropic 于 10 月 8 日发布了 beta 版的 Claude Dashboards，比本文上线早一周。那么问题很自然：我们是不是该等一等，直接买它？

其实等不了。我们 8 个月前就开工了，那时它还不存在。如果今天从零开始，说实话，我们大概会先看看它。它是 AI 原生的，也没有 Looker 那些渲染问题。如果你的团队现在手上什么都没有，选它多半是对的。

对我们来说，仪表盘只是其中一部分。这个工具已经接进了团队现有的工作方式：它对接我们的 agent 控制平面、分析平台和 Slack，还有一堆我们自己搭的工作流。Claude Dashboards 也许能覆盖其中一部分，但怎么把这些都接起来，还是得我们自己解决。而且一旦某个功能变了、价格涨了，我们也只能跟着应付。

所以答案还是一样。如果你需要贴合自身业务的软件，而且已经有平台来跑它、有专门的团队，那就自己造——除非你的护城河是规模。

Footnotes

1. 与 Vendr 经 Coefficient 发布的 355 笔 Looker 交易均价 15 万美元一致。 ↩

2. 其中几个帖子：AI Is Killing B2B SaaS（2026 年 2 月，729 条评论）、AI agents are starting to eat SaaS（2025 年 12 月）、SaaS is just vendor lock-in with better branding（2025 年 6 月）、Every SaaS business will become a harness around a model（2026 年 10 月），以及一篇持相反观点的 why SaaS isn't doomed（2026 年 7 月）。 ↩

3. 两条线都以 2023 年初为 1 倍起点，并做了 3 个月平滑。GitHub 这边，我们统计自称 self-hosted 的新仓库，与有真实描述的新仓库做对比，因为现在的 GitHub 上满是机器人建的空仓库。Hacker News 这边，我们统计提到 slop 的评论，与当月全部发帖做对比。 ↩