原始来源：David Lequin · 工程实践
发现渠道：Hacker News · 公开讨论
一个三人数据工程团队，能否用 AI 生成的网页取代商业 BI 报表？David Lequin 在 10 月 14 日的实践文章中给出了自己的八个月经历，近日又在 Hacker News 引发讨论。他所在的约 500 人公司已有 Snowflake 数据仓库、约 2,000 个 dbt 数据模型和身份认证等设施。新的工作是让分析师生成定制页面，并把页面安全地接到这些基础设施上。
最初的做法很简单：把 HTML 文件放进 S3，再接单点登录。后来页面通过查看者的 Snowflake OAuth 身份实时查询，沿用已有的数据权限；共享的 MCP 工具帮助生成、上传和打开草稿，由人确认发布。这样，财务和业务人员不必把需求塞进 BI 产品固定的布局，也能反复修改自己真正要用的报表。作者自报，周活跃用户从三月的 23 人升到六月的 136 人，八个月后使用量已与 Looker 相当，后者使用量下降约三分之一。
但 HTML 并不天然安全。同一来源下的脚本曾可能借用查看者身份发请求，团队随后改用独立来源的沙箱 iframe、内容安全策略和受检查的消息接口；令牌也限制到查看者、页面和短时间窗口。另有异步扫描器检查脚本目的地和 SQL。这些都是新增平台工作，不能算作一个静态文件自带的能力。
标题中的每年 15 万美元是按市场价格举的许可费例子，并非披露的公司实际账单。作者列出的八个月模型费用约 6,400 美元、AWS 约 1,900 美元，也不含三位工程师的工时。最有价值的结果，是已有数据底座让定制界面变得便宜、有人愿意用；文章尚不能证明任意团队都能以同样总成本替代 BI。
可信度 65 · 重要性 82 · 新颖度 72
技术与主题
AI 编程 · 检索与知识 · Generative UI · Semantic Layer · Sandboxing
David Lequin
作者回顾本人团队八个月实践；使用量和费用为自报。
忠实转述（非原句）：他最在意的是让业务人员不再绕开系统、下载数据后自己拼报表。每增加一道制作限制，都可能把人赶回本地文件。团队已有成熟数据底座，才选择把自由度留给页面；他并不主张所有团队都从零建 BI。
alexkbuilds
回应原帖：查看原帖上下文
对 David Lequin 文章的回复；讲述自己过去工作的相似经历，并非复核作者公司。
忠实转述（非原句）：他曾做过类似系统，困难是让每个人拿到正确的数字。即使已有语义层，使用者仍可能选错指标或组合方式；因此，生成页面并没有自动消除分析师帮助澄清问题的工作。
ekreloff
回应原帖：查看原帖上下文
同帖成本讨论；质疑比较口径，未提供独立财务审计。
忠实转述（非原句）：他希望成本比较把开发者工资和持续维护时间也算进去。便宜的模型调用是一个真实变化，但单列 API 和云账单，仍不足以比较购买软件与自己维护软件的完整代价。
编辑评读
这篇经验改变的是“什么值得定制”的判断。过去，单独给一位业务人员做页面往往不划算；生成成本下降后，贴近具体问题的布局可能比统一仪表盘更有价值。作者保留数据仓库权限与 dbt 模型，说明可自由变化的界面与共享的数据约定可以同时存在。页面数量增加，并不要求每次重造整个系统。
评论者指出的正确数字问题也不能靠沙箱解决。沙箱约束代码能碰什么，数据权限约束谁能读什么，指标口径则决定算出来的数字是什么意思。这三个问题需要不同证据。原文的用户增长支持有人愿意使用新页面，却没有给出错误指标率、事故率或全部维护工时，因此不能直接推出分析质量提高或净节省了多少。
可以借鉴的起点，是挑一类已有稳定数据模型、但展示需求多变的报表，比较交付时间、重复修订和错误数字，而不是先承诺替换全部 BI。若团队连数据定义和权限都尚未统一，购买成熟产品仍可能更合理；作者也明确表示，新团队可以考虑现成的 Claude Dashboards。这是一个有条件的构建选择，本刊未运行这项比较。