用一堆 HTML 文件替代每年 15 万美元的 Looker：一家 500 人公司的 8 个月实践

和许多公司一样，我们为 Looker 付费。假设一年 15 万美元，这是平均的 Looker 许可证¹价格，大约 300 个席位。我们是一家约 500 人的公司，有 3 名数据平台工程师，我们一周的大部分时间都花在那些不起眼的事情上：维持 Snowflake 的数据供给、照看一个早已超过 2,000 个模型的 dbt 项目，以及运行其下的 Airflow、Airbyte、DataHub 和 Kubernetes 基础设施。

今年 2 月，我们中的一个人利用业余时间做了个托管 HTML 文件的东西。只花了一个下午。8 个月后，它的每周用户数已经和我们公司的 Looker 一样多，甚至可能更多，而 Looker 的使用量下降了三分之一。

科技网红们不断发帖说软件已死，有些人说他们已经取消并 vibe 编码掉了自己所有的 SaaS 订阅。他们说 AI 将杀死 B2B SaaS。²

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

"自托管" GitHub 仓库的占比

与此同时，Hacker News 上的"slop"

左：被描述为"自托管"的新 GitHub 仓库占比。右：说"slop"的 Hacker News 评论占比。³

slop 变好了

一年前，我认为大多数 AI 输出都是 slop，而且大部分确实如此。我们做了几个"与你的数据对话"的演示，它们在只有 4 张表的玩具级 schema 上看起来很棒，但在我们的规模下从未真正奏效。SQL 运行没有报错，但数字是错的。那要糟糕得多。

后来，搭配 Opus 4.5 的 Claude Code 变得非常出色。是真的非常出色。1 月初，全公司的采用率飙升。它能在我们的仓库里工作，并使用我们的工具。而且，它可以在回答前运行查询来核对数字。这比得到一个听起来聪明的回答重要得多。几周之内，财务、运营和营销部门那些从未打开过终端的人整天都在写提示词。突然间人人都在写提示词，没人再点鼠标了。

大约在这个时候，Claude 开始输出大量 HTML。你请求一份分析，就会得到一个包含图表的单文件，说实话，其中一些页面看起来比我们的 Looker 仪表盘还好。问题在于它会躺在某个人的下载文件夹里。要分享，他们只能在 Slack 里附上文件然后祈祷。这远早于 Anthropic 为 Team 和 Enterprise 推出可分享的 artifacts（2026 年 6 月），而我们确实需要一种方式来分享这种新型仪表盘。

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

她写了一个小的 Python 脚本，并打包成一个 Claude 插件。用户让他们的 Claude 写出 HTML，脚本会把它推送上去（在 SSO 之后），公司里任何人都能打开链接。最初，这些文件只是普通的静态 HTML。3 月我们想，何乐而不为，于是用查看者的 Snowflake OAuth token 加了一个实时查询 API：这是年度最佳决定。

事实证明，我们根本不需要自己写权限模型。Snowflake 早就有了。它有一套我们维护了多年的角色机制，如果 Snowflake 说你不能读销售表，那仪表盘也读不了。到四月，Snowflake OAuth 成了唯一的登录方式。

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

一个 Looker 磁贴就是一个框，里面是固定的图表类型列表和固定的配色，看起来和所有其他 Looker 磁贴一模一样。丑，而且毫无个性。

通过摆脱僵化的固定磁贴，我们的用户可以生成自由形式的 HTML，并不断提示调整，直到它看起来整洁为止。他们很喜欢。四月上线了邮件和 Slack 导出，五月上线了参数，周活跃查看者从三月的 23 人增长到六月的 136 人。高管团队开始互相转发链接。大家也把这个工具用出了自己的花样。他们发现了我们从未想到的用例，把仪表盘设置为按计划自动重新生成，添加按钮，还做出了一些狂野的设计和 UX，任何 BI 工具都不会允许他们这么做。

此时的安全性很糟糕。是真的非常糟糕。仪表盘的 JavaScript 与你的会话同源运行，没有任何权限控制，每个员工都能读取每个仪表盘。这基本上就是一个巨大的 XSS 漏洞：任何仪表盘都能以打开它的人的身份运行代码，并以他们的名义拉取数据。我们知道这一点，但还是上线了，因为它是内部工具，在 VPN 和 SSO 之后，而且没有别的工具能干这个活。

好，那就正经做吧

在我们团队，“干脆自己做个 BI 工具吧”成了一个反复出现的玩笑。这个玩笑持续了几个月，直到我们清楚地意识到已经陷得太深。我们把几个月的 vibe-coding 堆在了一个我们自己都不满意的安全模型上，而公司一半的人都在用它。我们不再开玩笑，认真地说：那就做个 BI 工具吧。我们站到白板前，主要是想弄清楚如何修复安全模型，并就我们不想失去的东西达成一致：同一个 S3 桶、不迁移、对已经在用的人不造成任何破坏，以及发布仍然和以前一样简单。

所有人都同意的一点：任何人仍然可以在一次提示中推送任意 HTML，没有审核步骤，没有模板，也没有已批准组件的列表。这一点我们仍然会坚持。

你在人和他们的仪表盘之间设置的每一道限制，都会把他们赶回 Downloads 文件夹。

真正重要的治理已经在上游完成了，在 dbt 模型和 Snowflake 角色里。所以仪表盘本身可以保持人们想要的那么松散、那么快、那么好看。

有 4 个问题需要解决。

一个连接器取代一个脚本。 上传脚本曾被复制到 2 个仓库和一个插件里，每个副本都略有不同。我们用面向全公司的一个远程 MCP 连接器替换了所有这些，这样 claude.ai、Claude Code、Slack 中的 Claude 以及我们自己的分析师 agent 都调用同一套工具。连接器会传递你的 Snowflake token，API 通过 SELECT CURRENT_USER() 校验你的身份。AI 上传的任何内容都会成为草稿，必须由人点击发布。

假设每个仪表盘都是敌对的。这是我们必须认真思考的部分。整个产品基本上从设计上就是 XSS：任何人都可以上传在同事浏览器中运行的 JavaScript，没有人审查它，而这位同事可能是 CFO。我们无法阻止 XSS，因为 XSS 就是产品本身，所以我们的工作是确保它无法触及任何东西。正因如此，我们的安全模型始于“我们假设它是敌对的”。每个仪表盘都在自己源上的沙盒 iframe 中运行，该 iframe 不获得任何 cookie，并带有严格的 CSP。它唯一能通信的对象是父页面，通过 postMessage 进行，父页面会检查消息发送者、附加会话并调用 API。内容令牌有效期为 1 小时，且仅对一个仪表盘、一个查看者和一个主机有效。

沙盒保护浏览器。我们还创建了一个独立的元数据服务，异步读取每个仪表盘的新版本。它会提取整个 HTML 和 Snowflake 查询。它检查页面加载的脚本以及数据发送的目的地。然后一组规则对这些事实进行判定。大多数规则只报告。它们会标记读取原始数据而非 dbt 模型的仪表盘、未固定到某个版本的脚本，或 90 天内无人打开的仪表盘。有些规则可以阻止仪表盘：来自此处无人使用过的包的脚本，或 WebRTC 连接——这是 CSP 无法阻止的唯一出路。被阻止的仪表盘不会加载。查看者会看到警告，必须接受后页面才会运行。

让 Snowflake 处理身份和权限。每个查询都以查看者自己的令牌运行。共享仪表盘从不共享数据访问权限。这既是一项安全特性，也是一项省事特性：我们从来不需要构建或维护数据权限，因为每个登录的人都已经拥有具有正确角色的 Snowflake 用户。

内容管理。这部分我们大约用了一周时间凭感觉编码完成，几乎不需要任何设计。对于空间、文件夹和共享，我们照搬了 Google Drive，因为每个人都已经知道 Google Drive 如何工作：查看者、编辑者和所有者，授权沿文件夹树向下流动，最强的授权获胜。版本按内容哈希存储，恢复某个版本会给你一个草稿。然后是搜索、点赞、定时导出，以及每小时从 HR 系统同步的团队。相比之下，安全模型才是几乎所有真正思考所在的地方。

开发花了几周时间，我们做到了。

然后它传播开来。人们开始在 Slack 线程中标记 Claude 并得到一个仪表盘。我们的分析师代理发布自己的仪表盘，一些仓库直接从 CI 发布，而大多数人只是从自己的 Claude 发布，所以每个仪表盘最终都看起来有点像制作它的人。如今它无处不在。

325 次提交，约 74,000 行代码（其中 20,000 行是测试），以及大约 6,400 美元的 Claude token 费用。

这就是我们这边的全部账单：8 个月，3 名工程师兼职完成，外加几位提交 PR 的朋友。Claude 编写了大部分代码。我们做了白板设计，争论了很多，并审查了一切。

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

每周使用它的人

Looker 的使用量是悄悄流失的，而不是断崖式下跌。我们并没有把所有东西都迁走：有些团队还在用 Looker，它的一些仪表盘也还没有替代品。让人们转而使用这个而不是 Looker 的原因是，构建仪表盘不再昂贵了。这让我们好奇：到底有多便宜？用 token 而不是工程时间来付费的好处是，它更容易衡量。

我们在这里用分析师 agent 作为代理，因为它是一个我们可以精确衡量的构建者。每次运行都会记录其 token 和成本，每次发布都会链接回产生它的那次运行。

我们发现，每个仪表盘大约要消耗 agent 100 万个 token，从第一个问题到最终页面。现在我们已经把它迁移到 Opus 5.5，一个仪表盘的成本从大约 $2.50 降到了大约 $0.50。agent 做的工作是一样的；只是 token 变便宜了。这才是真正的故事：现在构建软件的成本就是 token 的成本，而这个价格还在不断下降。

BI 工具主要就是把查询变成图表的工具，而一张图表现在大约只要 $0.50 的 token。这样一来，为这部分付 $150k 的许可证费用就很难说得通了。

每周仪表盘成本

那么，自建还是购买？

这是整件事的账单，从二月的第一次提交到现在。

8 个月，2026 年 2 月到 10 月

我们自己构建：我们的全部花费

$8.3k少 12 倍

Looker 许可证：8 个月，按 $150k 平均值计算

$100k

Claude token $6.4kAWS $1.9k

现在它有了自己的数据库，在 AWS 上运行每年大约花费 $6k，再加上我们为持续添加功能而花费的 Claude 费用，自七月以来大约每月 $1.3k。算下来一年 $20k，而 Looker 是 $150k，而且这 $20k 大部分是我们在构建新东西，而不是维持运转。

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

Snowflake 一直都有权限，dbt 有语义，而托管一些 HTML 文件每月大约花费 $500。

把这些拿掉，剩下的就是一张 $150k 的发票。

也不只是我们。你越来越常听到：稳健的老牌企业正在取消非常昂贵的分析订阅。Amjad Masad 告诉 Platformer 关于 Replit 的同样故事：一旦他能把仓库连接到生产 Postgres 并自己构建报告，他们就“取消或缩减了大部分[他们的]分析产品”。

在我们的案例中，围绕现有技术栈构建一个仪表盘工具的成本，只是我们为 Looker 支付费用的一小部分。对我们来说，重要的部分已经在 dbt 和 Snowflake 中：模型、权限和数据。Looker 坐在这之上，把它们变成仪表盘。我们发现这部分是可以替代的。

上面的账单还漏掉了最大的成本，那就是我们自己：3 名工程师花了 8 个月在这上面，而且是在数据平台团队所做的其他一切之上：管道、dbt 项目、仓库、Kubernetes 集群、值班。这些都没有停止。我们无法给出一个诚实的工时数字，因为它们分散在我们做的其他所有事情中。如果你需要雇一个团队来构建这个，算法就不一样了。

如果你已经有一个稳固的平台可以构建，并且有一个熟悉它的团队，那么剩下的主要就是 Claude 的时间，而 Claude 的时间很便宜。

我认为分界线在于规模。AWS 和 Snowflake 卖的是没人能靠 vibe-coding 做出来的东西：数据中心、按 PB 计价的对象存储、因为数百万其他客户分摊而变得便宜的算力。我认为 BI 尤其容易受冲击，因为它的很多价值——至少对我们来说——在于构建和呈现仪表盘。Claude 现在花几分钱就能做到这一点。拥有真正规模优势的产品则是另一回事，但如果更多公司开始自己替换掉 BI 技术栈的一部分，我也不会感到意外。

那 Claude Dashboards 呢？

Anthropic 于 10 月 8 日发布了测试版 Claude Dashboards，比这篇文章上线早一周。所以显而易见的问题是：我们是不是应该干脆等一等，直接买它？

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

对我们来说，仪表盘只是其中一部分。这个工具已经接入我们团队现有的工作方式：它对接我们的 agent 控制平面、分析平台和 Slack，还有一堆我们自己搭建的工作流。Claude Dashboards 也许能覆盖其中一部分，但我们仍然得想办法把这一切连接起来。而且如果某个功能变了或者涨价了，我们也得应对。

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

1. 这与 Vendr 经 Coefficient 报道的 355 笔 Looker 交易平均 15 万美元一致。↩
2. 其中几个帖子：AI 正在杀死 B2B SaaS（2026 年 2 月，729 条评论）、AI agent 开始蚕食 SaaS（2025 年 12 月）、SaaS 不过是包装更好的供应商锁定（2025 年 6 月）、每家 SaaS 公司都会变成模型的 harness（2026 年 10 月），以及为了平衡，还有为什么 SaaS 并非注定灭亡（2026 年 7 月）。↩
3. 两条线都从 2023 年初的 1× 开始，并按 3 个月做平滑处理。对 GitHub，我们统计自称“self-hosted”的新仓库，并与有真实描述的新仓库对比，因为 GitHub 现在满是机器人创建的空仓库。对 Hacker News，我们统计提到“slop”的评论，并与当月所有发帖对比。↩