我越来越不喜欢把 dashboard 理解成“把几个 chart 摆上去”的工作。尤其在 Agent 和 vibe-coding 时代，这种误解会被进一步放大，因为图表代码太容易生成，于是团队会误以为“能画出来”就等于“能帮助判断”。但真正难的，从来不是画图，而是把页面组织成一个能引导人理解、比较和行动的叙事界面。
vibe-coding-dashboards-best-practices 给了我一个很实用的五步框架，我会把它理解成“在让 AI 动手之前，人类先把问题定义完整”。先定义 audience、decision 和 single takeaway，再决定图表类型；先定义主题、颜色和视觉层级，再决定页面布局；先把 setup、tension、insight、action 这条叙事主线理顺，再谈筛选器和 hover 交互。这个顺序很重要，因为它实际上是在防止“交互和图表数量掩盖问题定义的空洞”。
图表选择不是审美问题，而是问题类型映射
我很认同文章里那句“chart types equal question types”。趋势、排名、分布、相关性，本来就是不同的问题，所以折线图、条形图、散点图也不是风格偏好，而是回答方式。像饼图对比角度、双 Y 轴拼接无关变量、二十多条线的 spaghetti chart，这些常见反模式之所以糟糕，不只是因为“难看”，而是因为它们让问题和表达方式失配。
这也是为什么 From Data to Viz 这类决策树很有价值。它不是替我做设计，而是逼我先说清楚：我到底在比较什么、讲变化还是讲排序、要让读者在三秒内看到什么。对 Agent 来说，这种结构化约束尤其重要，因为模型最擅长把模糊需求合理化，而不是主动提醒“你的问题还没定义完”。
页面层级和参考线，决定读者能不能真正读懂
一张图能不能被理解，很多时候不取决于图本身，而取决于上下文是否完整。KPI 卡片放最上面，是为了先给读者一个方位感；主图放左上，是因为大多数人先从那里扫视；参考线、事件标注、时间范围和数据来源，则是在阻止读者把孤立数字误读成绝对结论。
这里我会把 Tufte 和 Storytelling with Data 放在同一个工作流里理解：前者提醒我减少杂讯，后者提醒我组织注意力。减少阴影、边框和无意义色彩，是为了提升 data-ink ratio；加入阈值线、注释和叙事顺序，则是为了让页面从“可看”变成“可判断”。
交互应该回答下一个问题，而不是制造更多按钮
我很喜欢文章把交互放在第五步。很多仪表盘失败，不是因为交互太少，而是因为交互出现得太早。页面自己还没讲清主线，就已经把用户扔进了一堆地区筛选、年份切换、多图联动和 tooltip 细节里。这样做的结果往往是：看起来很强大，实际上没有人知道该从哪里开始。
更好的做法是先让静态版本成立，再问“用户看完这一屏后自然会追问什么”。如果下一个问题是“那我所在城市呢”，就加 city picker；如果问题是“这个变化是不是特定年份发生的”，就加时间切换；如果问题是“这个选择会不会影响整页判断”，就加 cross-filtering。交互应当服务叙事，而不是替代叙事。
对我的启发
这篇文章让我意识到，Agent 时代的数据产品设计并没有因为生成速度变快而变简单，反而更需要人类先给出约束。AI 可以生成一个很会取悦眼睛的 dashboard，但只有我自己能判断：这个页面究竟是在帮助理解，还是只是在制造“哇”的一瞬间。
来源：vibe-coding-dashboards-best-practices
相关页面：motherduck · duckdb · agent-first-engineering