我们用单个 Claude Code skill 替换掉了庞大的 Grafana 监控栈
我们的 Grafana 仪表盘上手工绘制了 24 张图表，积累了多年的数据。结果我们只花了一天时间，就用一个 Claude Code skill 把它整个替换掉了。
过去九个月里，我们一直在运行一套规模庞大的多区域 Grafana 监控系统。上周，我们用了一个 Claude Code skill 把整套东西替换掉了——它通过一个只读的 Postgres 副本直接查询同一份数据。
当初为什么要做 Grafana 仪表盘
如果你所在的团队有专门的数据团队或业务运营团队，而那里的某个人给你画了一张图，你会信任它。你相信他们核查过，相信他们知道哪些行没有被算进总数。你每次打开它，看到的都是同样的内容；即便它出了错，对每个看的人来说，错的方式也完全一致。
这就是预置图表的真正价值所在。它不灵活，但可靠。
想象一下，你花了一个周六来收拾屋子，大部分都整理得挺好：餐具归餐具，电池和充电器归电池和充电器。然后你收拾到最后一堆东西——一把卷尺，还有一把配不上家里任何锁的钥匙。天已经很晚了，这两样东西放不进你刚整理好的任何类别里，为两件东西硬造一个新分类又显得很滑稽。于是，它们被丢进了最底下的抽屉。
六个月后，那个抽屉变成了你最先打开的一个。
我们的仪表盘也是这么回事。总共有 24 张图表。十月份搭好的分区一直撑到现在，而之后我们好奇的大部分东西，最后都堆进了「杂项」里。
每一张图表背后都是一次 pull request。有人花时间写查询、挑图表类型、把筛选条件和旁边的图表对齐，好让同一屏上的两个数字能对得上。然后下一个问题来了，我们再来一遍。
所以，仪表盘只能回答我们十月份想到的那些问题，底下的那堆东西全是之后的积累。我们真正想要的，是一种能够随手问出新问题的方式，而不是每问一次就得造一个一年后还要有人维护的东西。
接替它的方案没那么可靠
今年五月，我们在那个 Postgres 副本前面加了一台只读服务器，开始用大白话向它提问。灵活性比原来高了一大截。以前没问过的问题现在也能问，想查某个客户某一周的数据，不用先做任何图表，直接问就行。
不过有时候它会给你一个答案，你一看就觉得不对。于是你提出来，它就说：“你说得对，我搞错了。”
这种情况出现得够频繁，不能当作没看见。我们现在还没彻底解决这个问题，凡是影响决策的结果，依然会直接拿数据库核对一遍。
但我们还是换了
原因很简单：我们本来就不看仪表盘了。
没有人会说“咱们去看看仪表盘，回答一下这个问题”。你真正想问的问题，几乎不可能对应到某一张图。你可能想看某个客户在某周的数据，或者想按账户规模筛一下趋势，又或者得上个月的数字换一种没人想过的切法。
用筛选器和日期选择器也能凑合着看。我们这么干了好几个月。能用，但太磨人，而磨人这件事本身就足以让人干脆不问了。我们现在问的大多是小问题，都是以前根本不会有人为此画一张图的那种。
有些东西还是应该主动推送给你
你不应该自己天天去查某个数字有没有过线，而且也没人会天天查。所以我们把这部分保留了下来，搬进了 Slack。每个工作日的早上会有一个定时任务跑一遍，然后把摘要发出来。查询语句都写在代码仓库里，而不是每次临时现写，这样每天问的问题一样，回来的答案格式也一样。
现在这个能力也进了产品
用 Frigade 的人也一样。你会看到一个带统计数据的面板，还有一个 Insights 页面，会把大家问的问题按主题归类，这两样都挺有用。
面板里的 Frigade Assistant 也可以直接查你的数据。问问它上周助手表现怎么样，哪些回答被人点了踩，或者你刚上线的改动有没有带来什么变化。它会返回对应的原始问题和用户链接，让你能自己点进去核实。
我们落实了严格的保护措施，让助手无法读取特定用户数据，也不能查询任何不该查的内容。所有操作都运行在只读层上，因此它无法改动数据库。
我们在内部也做了同样的取舍，原因相同：你自己产品的问题，我们永远猜不到。
这个 AI 代理既能学习你的产品，也能引导你的用户
Frigade 是一款内置于你的产品中的 AI 助手。预约演示，我们会让你看到它在真实应用上的工作状态，而不是一段泛泛的走马观花。
-
2026年5月11日 我们离开了 Framer（其他人也会这样做）
先写代码，再用 Framer 两年，然后回到代码。是什么让我们迈出这一步？为什么大多数使用无代码工具的团队也会跟随？ -
2026年4月28日 AI 代理何时应该拒绝回答
AI 代理天生就会回答问题。优秀的代理知道何时拒绝。为什么“我不知道”是最昂贵、也最被用户信任的功能？